| 00:10.00 | ant_home | afais 0xe1cc00d0 -> __setrlimit or 0xe1cc00d8 -> readdir |
| 00:10.25 | ant_home | the latter |
| 00:11.24 | ant_home | readdir could explain the alignment traps in the log |
| 00:12.14 | ant_home | ..but the alignment is 8 afais.. |
| 00:12.16 | ant_home | <PROTECTED> |
| 00:12.40 | ant_home | sigh 2 o' clock here... |
| 00:12.43 | ant_home | have to go |
| 00:13.15 | ant_home | gn |
| 00:19.12 | *** join/#oe infobot (ibot@208.53.50.136) |
| 00:19.12 | *** topic/#oe is OpenEmbedded Developer Lounge | Web: http://openembedded.org | Repositories: http://git.openembedded.org/ | Primary Repo Mirrors: https://github.com/openembedded | This is not a distro or machine support channel |
| 00:51.43 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 01:45.45 | tlwoerner | khem: here's the error: https://pastebin.com/j5Eaazky |
| 01:46.03 | tlwoerner | as you can see, the build of the kernel itself completes fine |
| 01:46.28 | tlwoerner | it's the compile of the dt tools that fails |
| 01:46.49 | tlwoerner | linux-stable-4.17.1 compiles just fine, so i'll just update to 4.17.1 and consider it done :-) |
| 01:53.17 | khem | tlwoerner: I think gcc is not finding standard compiler headers |
| 01:56.57 | tlwoerner | khem: which is weird (?), it's obviously finding it for everything else |
| 01:57.16 | tlwoerner | i.e. other non-kernel C programs |
| 02:09.30 | *** join/#oe jkridner|pd (~jkridner@pdpc/supporter/active/jkridner) |
| 02:42.43 | *** join/#oe falk0n (~falk0n@a109-49-51-30.cpe.netcabo.pt) |
| 02:46.25 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 03:04.08 | khem | tlwoerner: igts possible that they are using -ffreestanding or some such option to ask gcc to ignore internal header search paths |
| 03:43.09 | khem | 3 |
| 04:04.44 | *** join/#oe paulg_ (~paulg@128.224.252.2) |
| 04:30.34 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 05:15.59 | *** join/#oe armpit (~armpit@2601:202:4000:1184:b845:47c4:6228:cb1c) |
| 05:31.33 | *** join/#oe yegorich (~yegorich@mail.visionsystems.de) |
| 05:34.38 | *** join/#oe Jybz (~jibz@2a02:8071:9289:5900:4a51:b7ff:fe84:99e6) |
| 05:44.09 | *** join/#oe t0mmy (~tprrt@217.114.201.133) |
| 06:17.43 | *** join/#oe ao2 (~ao2@host102-86-dynamic.13-79-r.retail.telecomitalia.it) |
| 06:58.26 | *** join/#oe jkridner|afk (~jkridner@pdpc/supporter/active/jkridner) |
| 06:58.30 | *** join/#oe fl0v0 (~fvo@mue-88-130-109-203.dsl.tropolys.de) |
| 07:08.03 | *** join/#oe cpriouzeau (~cpriouzea@164.129.115.76) |
| 07:11.06 | *** join/#oe ant_work (~ant__@host254-202-dynamic.51-79-r.retail.telecomitalia.it) |
| 07:12.38 | *** join/#oe JaMa (~martin@217.30.68.212) |
| 07:17.11 | *** join/#oe diego_r (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 07:18.23 | *** join/#oe jkridner|afk (~jkridner@pdpc/supporter/active/jkridner) |
| 07:53.37 | *** join/#oe AndersD (~anders@194.237.220.218) |
| 08:11.00 | ant_work | khem, I am bothering #gcc people and I got confirmation of my amateurish findings |
| 08:11.02 | ant_work | <apmorton> ant_work, it is indeed readdir causing the alignment fault |
| 08:11.10 | ant_work | <apmorton> although given the values in the trap information I can't see _why_ - the values given for the fault address are word aligned |
| 08:11.16 | ant_work | heh |
| 08:19.35 | ant_work | khem: he got it :) |
| 08:19.39 | ant_work | apmorton> ah, sorry - i missed the D at the end of those instructions |
| 08:19.49 | ant_work | <apmorton> Prior to ARMv6, doubleword (LDRD/STRD) accesses to memory, where the address is not doubleword-aligned, |
| 08:19.58 | ant_work | <apmorton> are UNPREDICTABLE |
| 08:20.07 | ant_work | <apmorton> the instruction its faulting at is an LDRD (doubleword load), and the address given in the trap is only 4 byte aligned |
| 08:23.29 | ant_work | apmorton> whatever compiled readdir is assuming some member of the DIR structure it gets passed is aligned to allow a LDRD instruction, and its not |
| 08:23.55 | ant_work | <apmorton> that, or the compiler is generating incorrect code |
| 08:39.57 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 09:28.13 | *** join/#oe eduardas_m (~eduardas@213.197.143.19) |
| 09:29.13 | ant_work | khem, there have been binutils upgrades as well... |
| 09:33.04 | *** join/#oe morphis (~morphis@pD9ED7149.dip0.t-ipconnect.de) |
| 10:10.09 | *** join/#oe eduardas_m (~eduardas@213.197.143.19) |
| 10:10.47 | *** join/#oe diego_ (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 11:35.24 | *** join/#oe ldnunes (~ldnunes_@187.23.153.102) |
| 11:48.53 | *** join/#oe diego_r (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 11:53.01 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-xnpuakdfhcasfjsm) |
| 12:05.29 | *** join/#oe yann (~yann@AMontsouris-681-1-111-231.w90-87.abo.wanadoo.fr) |
| 12:49.25 | *** join/#oe willdye (~willdye@rrcs-67-48-47-162.sw.biz.rr.com) |
| 13:03.13 | *** join/#oe marka (~masselst@184.175.21.48) |
| 13:03.30 | *** join/#oe eduardas_m (~eduardas@213.197.143.19) |
| 13:32.46 | khem | ant_work: I can see the bug |
| 13:33.00 | ant_work | I am compiling gdb-cross-arm |
| 13:33.05 | ant_work | gm |
| 13:35.01 | khem | the problem seems to be that gcc is doing an optimization to combine an arrat of two longs into a single load |
| 13:35.10 | khem | Can you try somethin ? |
| 13:35.15 | ant_work | sure |
| 13:35.30 | ant_work | I have the device here with serial |
| 13:35.36 | Crofton|work | | ../../../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/libgfortran/runtime/backtrace.c:36:10: fatal error: backtrace-supported.h: No such file or directory |
| 13:35.36 | Crofton|work | | #include "backtrace-supported.h" |
| 13:35.36 | Crofton|work | | ^~~~~~~~~~~~~~~~~~~~~~~ |
| 13:35.36 | Crofton|work | | compilation terminated. |
| 13:35.36 | Crofton|work | | make[1]: *** [Makefile:2310: backtrace.lo] Error 1 |
| 13:35.38 | Crofton|work | | make[1]: *** Waiting for unfinished jobs.... |
| 13:35.46 | Crofton|work | on rocko with pi bsp |
| 13:37.21 | khem | ant_work: what is -march/-mcpu value passed when compiling musl |
| 13:38.59 | ant_work | no thumb, is -march=armv5e -marm |
| 13:39.48 | khem | ant_work: OK do you know the part name ? |
| 13:40.11 | LetoThe2nd | Crofton|work: have you checked that you include the fortran fixes by ricardo? |
| 13:40.21 | khem | ant_work: can you add -fno-store-merging to CFLAGS in musl recipe |
| 13:40.39 | ant_work | ok |
| 13:40.51 | khem | ant_work: and then compile musl and dump libc.so and search for same patterns |
| 13:41.11 | ant_work | okay |
| 13:41.17 | khem | ant_work: I would like to understand why thumb is disabled in your case |
| 13:41.24 | khem | whats the board you have |
| 13:41.56 | ant_work | well, there are a few compiled w/out thumb, in core-image-bse I see |
| 13:41.58 | Crofton|work | LetoThe2nd, this is on rcoko, master is OK. Sounds liek there are some backports maybe |
| 13:42.14 | ant_work | glib-2.0 gmp icu musl |
| 13:42.21 | Crofton|work | wonders why he always ends up in weird palces :) |
| 13:42.36 | khem | ant_work: as I said yesterday non t variant of v5 is going out of support in gcc |
| 13:42.45 | ant_work | under armv5e-oe- .. |
| 13:42.59 | ant_work | well, maybe is set in the recipe ? |
| 13:43.58 | ant_work | see glib.2 |
| 13:43.59 | ant_work | ARM_INSTRUCTION_SET_armv4 = "arm" |
| 13:43.59 | ant_work | ARM_INSTRUCTION_SET_armv5 = "arm" |
| 13:44.30 | Crofton|work | LetoThe2nd, feels like rocko has them |
| 13:44.56 | ant_work | khem, same for musl |
| 13:44.59 | ant_work | # thumb1 is unsupported |
| 13:44.59 | ant_work | ARM_INSTRUCTION_SET_armv5 = "arm" |
| 13:44.59 | ant_work | ARM_INSTRUCTION_SET_armv4 = "arm" |
| 13:46.05 | Crofton|work | ah, but not RP's |
| 13:46.31 | ant_work | khem, should I first try to build using thumb? |
| 13:47.12 | ant_work | or go with the -fno-store-merging ? |
| 13:47.14 | khem | Crofton|work: I think these patches are not in rocko yet |
| 13:47.40 | khem | ant_work: no try to build with that option -fno-store-merging |
| 13:47.44 | khem | and just build musl |
| 13:47.46 | ant_work | ok |
| 13:47.50 | khem | and see if it changes |
| 13:47.54 | Crofton|work | 2c2f20a9756eccafac776e45e319af7666e6da96 is the one needed for rocko |
| 13:48.02 | Crofton|work | biulding now |
| 13:55.43 | khem | ant_work: does your build for musl shows up -mcpu used as well ? |
| 13:57.06 | ant_work | no |
| 14:03.58 | *** join/#oe lpotter (~quassel@2001:8003:645f:c300:ba27:ebff:febb:59b) |
| 14:05.51 | ant_work | khem, od https://filebin.net/g17niupvztps17d2 |
| 14:06.03 | ant_work | I am rebuilding the image to run-test meanwhile |
| 14:06.59 | khem | ant_work: whats your board CPU I would like to know I think we can avoid the bug |
| 14:07.07 | khem | I am not sure if someone will fix it for us |
| 14:07.15 | ant_work | pxa25x |
| 14:07.29 | ant_work | iirc same on pxa27x |
| 14:08.44 | ant_work | khem, the assembler didn't change, isn't :/ |
| 14:10.33 | ant_work | so you mean it is aligned for the shorter thumb instructions? |
| 14:12.16 | ant_work | abelloni, do you still have verstile around? Do you see align traps? |
| 14:13.07 | *** join/#oe stephano (~stephano@134.134.139.74) |
| 14:14.10 | *** join/#oe stephano2 (stephano@nat/intel/x-nvvjhdzegrhcgzbc) |
| 14:19.43 | abelloni | I didn't see any report |
| 14:20.32 | ant_work | qemuarm does not show them, I see only on real hw |
| 14:21.16 | ant_work | so it is again som elittle diff between arm926j and pxa |
| 14:21.27 | abelloni | probably |
| 14:21.49 | abelloni | the armv5 socs from atmel are plain arm9ejs |
| 14:22.18 | abelloni | arm926ejs |
| 14:23.03 | ant_work | khem, I see suggestion for using -march=native and even -mcpu... |
| 14:23.55 | ant_work | I wouldn't do that now |
| 14:34.32 | khem | ant_work: ah pxa, pxa25x is lubbock and pxa27x is codename bulverde these are intel xscale+iwmmxt cpus |
| 14:35.21 | ant_work | there is still life in LAKML |
| 14:36.51 | ant_work | even for assabet/neponset, the sa100 toys of RMK |
| 14:36.53 | khem | ant_work: so you can avoid this issue by changing your defaulttune |
| 14:38.19 | ant_work | hmso avoid require conf/machine/include/tune-xscale.inc |
| 14:38.22 | khem | ant_work: in your machine conf include conf/machine/include/tune-xscale.inc |
| 14:38.45 | khem | ant_work: and set DEFAULTTUNE = "xscale" |
| 14:38.57 | ant_work | http://cgit.openembedded.org/meta-handheld/tree/conf/machine |
| 14:39.01 | ant_work | see c7x0 |
| 14:39.19 | ant_work | the inc forces ARM_INSTRUCTION_SET = "thumb" |
| 14:40.00 | ant_work | I added that a while ago |
| 14:40.09 | khem | ant_work: yeah the difference is now you set DEFAULTTUNE = "xscale" |
| 14:40.44 | khem | ant_work: yeah thumb1 is kind of pushed to corner but should work mostly |
| 14:41.45 | abelloni | ant_work: if at some point, you have 5 minutes, can you confirm that the RTC driver was broken in v4.3 ? :) |
| 14:41.54 | ant_work | so the tune-xscale.inc must be fixed? |
| 14:41.58 | ant_work | it is now DEFAULTTUNE ?= "armv5te" |
| 14:43.29 | ant_work | Iìll try that right now |
| 14:43.45 | ant_work | abelloni, no real rtc on Zaurus, just the sa1100 ip |
| 14:43.57 | ant_work | afair pxa just borrowed |
| 14:44.00 | abelloni | I'm interested in that one |
| 14:44.05 | ant_work | ok then |
| 14:44.21 | abelloni | the fact is that two drivers will be loaded for the same ip |
| 14:44.22 | ant_work | I have 4.4 as oldest ;) must summon the other kernels |
| 14:44.29 | abelloni | rtc-sa1100 and rtc-pxa |
| 14:44.44 | ant_work | at one point I did enable both on pxa27x |
| 14:44.53 | ant_work | then smthg broke in kernel |
| 14:45.07 | ant_work | I'll check, sure |
| 14:45.56 | abelloni | ant_work: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e4302aec8a0646828a701443e303eb5ef48b37f5 |
| 14:48.28 | khem | ant_work: although I think gcc should be fixed for this in the end, we might need a small reproducer |
| 14:49.01 | ant_work | I am pretty sure gcc7.2 was ok in this regard |
| 14:49.02 | khem | ant_work: other option is to try use armv5 ( without 'e') as defaulttune |
| 14:49.21 | khem | ant_work: its possible something regressed |
| 14:50.02 | ant_work | it was after the 0051-ARM-PR-82445-suppress-32-bit-aligned-ldrd-strd-peeph.patch |
| 14:50.15 | ant_work | there I could boot again \o/ |
| 14:51.58 | ant_work | and it was november, patch was in limbo for months |
| 14:52.13 | ant_work | http://lists.openembedded.org/pipermail/openembedded-core/2017-December/145293.html |
| 14:52.56 | ant_work | so I'd say the binaries were okay back then |
| 14:55.51 | ant_work | abelloni, fwiw 4.4.latest does not yet build with gcc8.1 so I doubt 4.3 will do any better |
| 15:01.40 | khem | ant_work: that patch is already in gcc8 |
| 15:03.21 | khem | ant_work: I suppose you are trying gcc8 here right ? |
| 15:05.36 | ant_work | 8.1 |
| 15:05.41 | ant_work | master-next |
| 15:06.31 | ant_work | last year kernel moving from gcc6 to gcc7 kernel did not decompress until that patch was committed |
| 15:06.49 | ant_work | err.. yea |
| 15:07.10 | ant_work | on xscale |
| 15:14.23 | *** join/#oe AbleBacon (~AbleBacon@unaffiliated/ablebacon) |
| 15:15.49 | *** join/#oe diego_ (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 15:20.25 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-tolpxnliniurcopr) |
| 15:21.43 | ant_work | <PROTECTED> |
| 15:22.16 | ant_work | still building |
| 15:36.03 | ant_work | khem: assembler is slightly different https://filebin.net/2a3jbz7azrsk4coj |
| 15:36.12 | ant_work | image still cooking |
| 15:37.29 | abelloni | ant_work: well, you can try v4.17-rc1 vs linux-next |
| 15:37.52 | ant_work | yea, but last 'good' is 4.14 |
| 15:38.01 | ant_work | for these deevices |
| 15:39.58 | abelloni | ant_work: then 4.14 and 4.14 with the patch ;) |
| 15:40.10 | ant_work | is cornered |
| 15:40.11 | abelloni | it's not like the rtc driver is moving a lot |
| 15:40.40 | ant_work | I remember at one point there have been issues after 4.2 |
| 15:40.48 | ant_work | but we moved to 4.4 |
| 15:42.07 | abelloni | I didn't see any complain though :) |
| 15:42.35 | ant_work | you see, we had a nice spi bug killing the lcd and backlight..all dark :) |
| 15:42.47 | ant_work | a bad backport to stable |
| 15:43.09 | ant_work | we have now gpio changes and keyboard mappings are wrong |
| 15:43.20 | ant_work | so rtc is the last of the pile :) |
| 15:44.19 | ant_work | we have fixed sound and partition parser at least |
| 15:44.43 | ant_work | I think support for these device will end someday |
| 15:44.54 | ant_work | will have to |
| 15:50.34 | ant_work | ouch gcc-runtime fails to build...I'll have to bother khem again |
| 15:52.09 | abelloni | I think boris and miquel were thinking about ripping the nand driver out of the kernel |
| 15:52.28 | abelloni | it is pretty difficult to find boards to test |
| 15:53.03 | abelloni | we actually bought one but the bootloader only want to boot windows ce |
| 15:53.06 | abelloni | so meh.. |
| 15:53.08 | *** join/#oe JPEW (cc4da337@gateway/web/freenode/ip.204.77.163.55) |
| 15:53.12 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 15:54.10 | ant_work | ouch -mcpu=xscale switch conflicts with -march=armv5te switch |
| 15:57.14 | ant_work | khem, now gcc-runtime fails to build, libstdc++/compatibility.cc |
| 15:58.21 | ant_work | undefines symbol _ZNSt13basic |
| 15:58.52 | ant_work | and expansion of _GLIBCXX_3_4_5_SYMVER |
| 15:59.48 | ant_work | and _GLIBCXX_APPLY_SYMVER |
| 16:00.36 | ant_work | doest it ring a bell? maybe the warning about conflicting switches? |
| 16:05.17 | ant_work | abelloni, you can still find some cheap NOR around |
| 16:05.30 | ant_work | but very small |
| 16:06.15 | ant_work | https://www.ebay-kleinanzeigen.de/s-anzeige/sharp-zaurus-5500-g/876684449-168-3467 |
| 16:06.20 | ant_work | 10 euro |
| 16:07.17 | *** join/#oe diego_r (~diego@host57-224-static.7-79-b.business.telecomitalia.it) |
| 16:08.43 | ant_work | bbl |
| 16:26.00 | khem | ah yes that march/mcpu mix I really hate |
| 16:26.14 | khem | we should just remove march when we know we want to use -mcpu |
| 16:26.18 | khem | atleast for arm |
| 16:27.29 | *** join/#oe Nilesh___ (uid116340@gateway/web/irccloud.com/x-iyzxiwsixkysjymr) |
| 16:33.43 | *** join/#oe yann (~yann@AMontsouris-681-1-111-231.w90-87.abo.wanadoo.fr) |
| 17:00.39 | *** join/#oe ant_home (~ant__@host3-210-dynamic.54-79-r.retail.telecomitalia.it) |
| 17:02.12 | ant_home | khem, ok, I am guinea-pigging at home |
| 17:08.15 | *** join/#oe joeythesaint (~joe@vegas.deserted.net) |
| 17:34.27 | khem | ant_home: it might be that you have to use DEFAULTTUNE = "armv5" |
| 17:34.41 | khem | ant_home: see if that works with everything else remaining same |
| 17:53.02 | *** join/#oe Jybz (~jibz@2a02:8071:9289:5900:4a51:b7ff:fe84:99e6) |
| 18:00.00 | *** join/#oe khem (~khem@unaffiliated/khem) |
| 18:29.44 | *** join/#oe DJWillis (~djwillis@cpc123798-trow7-2-0-cust28.18-1.cable.virginm.net) |
| 18:35.26 | *** join/#oe gbritton (~Adium@209.6.40.118) |
| 18:38.55 | *** join/#oe armpit (~armpit@64.2.3.196.ptr.us.xo.net) |
| 18:44.26 | *** join/#oe florian (~florian_k@Maemo/community/contributor/florian) |
| 18:46.13 | *** join/#oe yann (~yann@LFbn-1-9167-222.w86-238.abo.wanadoo.fr) |
| 18:56.47 | *** join/#oe joeythesaint (~joe@vegas.deserted.net) |
| 18:59.38 | ant_home | khem, okm then I comment out the ARM_INSTRUCTION:SET="thumb" |
| 19:01.02 | *** join/#oe wto (~wto@h-136-128.A336.priv.bahnhof.se) |
| 19:09.47 | *** join/#oe wto (~wto@h-136-128.A336.priv.bahnhof.se) |
| 19:13.08 | *** join/#oe AbleBacon_ (~AbleBacon@unaffiliated/ablebacon) |
| 19:27.50 | *** join/#oe ntl (~nathanl@136.62.102.203) |
| 19:45.12 | khem | ant_home: yes |
| 19:56.05 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 20:04.15 | *** join/#oe christner (~dchristne@70-91-95-105-washington.dc.hfc.comcastbusiness.net) |
| 20:49.39 | *** join/#oe diego_r (~diego@31.159.42.177) |
| 20:50.55 | *** join/#oe georgem_home (uid210681@gateway/web/irccloud.com/x-eqvcklagsqhzsver) |
| 20:58.07 | ant_home | khem, then no alignment traps |
| 20:58.09 | ant_home | :) |
| 20:58.13 | ant_home | this is od https://filebin.net/p7y19db5nvxle5e8/zz2?t=h2fsyfzb |
| 20:58.54 | ant_home | TUNE_FEATURES = "arm armv5" |
| 20:59.06 | ant_home | so thumb and dsp are lost |
| 21:01.22 | ant_home | now trying with armv5e |
| 21:08.32 | ant_home | ok, this gives TUNE_FEATURES = "arm armv5 dsp" |
| 21:09.14 | ant_home | but I see readdir seems bad again: https://filebin.net/6tamgu3tsmda06f9/zz3?t=yjwgwhoq |
| 21:09.24 | ant_home | khem, so it is the 'e' |
| 21:13.54 | *** join/#oe diego_r (~diego@151.38.33.78) |
| 21:26.05 | *** join/#oe ntl (~nathanl@65-36-80-8.dyn.grandenetworks.net) |
| 21:47.49 | ant_home | yes, align trap |
| 21:50.46 | ant_home | trying now with TUNE_FEATURES = "arm armv5 thumb" and forcing instruction set to use thumb |
| 21:55.57 | ant_home | musl does not change, vaid readdir |
| 21:56.03 | ant_home | *valid |
| 22:50.05 | *** join/#oe ntl (~nathanl@65-36-80-8.dyn.grandenetworks.net) |
| 23:14.48 | *** join/#oe morphis_ (~morphis@pD9ED7275.dip0.t-ipconnect.de) |
| 23:24.45 | *** join/#oe armpit (~armpit@2601:202:4000:1184:b845:47c4:6228:cb1c) |