**** BEGIN LOGGING AT Tue Oct 23 02:59:59 2018 Oct 23 06:30:20 morning Oct 23 07:25:59 morning Oct 23 07:27:36 morning Oct 23 07:48:41 good morning mother lovers! :-) Oct 23 07:50:36 Did any one see my patch I sent to the email list? I sent a v2 but don't know if I got it rite or not. Oct 23 07:51:25 I am going to send a PR next time. I don't like not knowing if it sent properly. Oct 23 07:51:51 The SOB is jonathan lancett Oct 23 07:52:32 It was to bump mwlwifi to latest Oct 23 08:06:11 build #129 of ramips/rt305x is complete: Failure [failed images] Build details are at http://release-builds.openwrt.org/18.06/images/builders/ramips%2Frt305x/builds/129 blamelist: Kevin Darbyshire-Bryant Oct 23 08:26:10 Tapper: i'll check it later Oct 23 08:26:35 do we have Koen on an IRC? Oct 23 08:26:45 stintel: do you have an idea? Oct 23 08:38:59 rmilecki: you mean me? Oct 23 08:39:30 xback: are you Koen Vandeputte? ;) Oct 23 08:39:39 using /whois xback doesn't hel Oct 23 08:39:39 yes Oct 23 08:39:47 web version ;) Oct 23 08:39:58 xback: 47f68ca58615fa71d7905130fb28d3ffe51effa2 ("kernel: bump 4.14 to 4.14.77") Oct 23 08:40:01 you missed bcm53xx Oct 23 08:40:06 http://release-builds.openwrt.org/18.06/images/grid Oct 23 08:40:19 Harden the branch predictor against aliasing attacks (HARDEN_BRANCH_PREDICTOR) [Y/n/?] (NEW) aborted! Oct 23 08:40:28 I recall that one Oct 23 08:40:34 contains 3 subtargets iirc Oct 23 08:40:52 bcm53xx? it's a simple target with no subtargets Oct 23 08:41:04 it's arm, so it probably needs HARDEN_BRANCH_PREDICTOR just like the others Oct 23 08:41:13 checking .. Oct 23 08:49:40 rmilecki: damnit! you're right .. (as expected ;) ) Oct 23 08:49:52 no worries :) Oct 23 08:50:07 xback: would you take a care of a patch? Oct 23 08:51:12 already made. pushing in 30 sec Oct 23 08:51:29 double checking everything .. Oct 23 08:51:47 thanks! Oct 23 08:53:04 no, thank you :) Oct 23 08:53:33 same mistake in master Oct 23 08:53:52 ah, right Oct 23 09:35:43 'lo Oct 23 09:42:12 ldir: ping Oct 23 09:42:39 Could this be related to your ghost issue mentioned yesterday? https://pastebin.com/2eUh1YMm Oct 23 09:42:46 seeing this once in a while .. Oct 23 09:43:16 uh, that looks like fun Oct 23 09:46:30 xback: maybe - it's a 'once in a while' very rare event for me, non reproducible. Who knows :-/ Oct 23 09:47:05 on my dozens of devices out there .. i'm seeing this once a month or so Oct 23 09:47:19 for the past .. 2 years .. Oct 23 09:47:41 sunspots! ;-) Oct 23 09:47:43 never was able to make a serial log of it .. as all devices are on remote desolate locations Oct 23 09:48:12 specific arch only? e.g. mips ? Oct 23 09:48:27 no Oct 23 09:48:34 arm & mips Oct 23 09:48:54 that's good news in a way Oct 23 09:51:54 git a folder full of unsolved crash logs :) If someone likes a challenge .. Oct 23 09:52:07 got* Oct 23 09:52:28 xback: would be interesting to trigger that relocation issue Oct 23 09:52:51 i.e. can it be provoked by fiddling with env Oct 23 09:53:03 or by clobbering argv[-1] etc. Oct 23 09:53:10 jow: the big issue is that I'm not seeing a pattern currently in it. Oct 23 09:53:53 is there any kind of ASLR on the affected systems? Oct 23 09:54:12 ASLR? Oct 23 09:54:41 https://lwn.net/Articles/569635/ Oct 23 09:54:51 memory location randomization Oct 23 09:55:42 any comments on my patch series for the new mesongx target? sent it to the list last Friday. if no comments, how long do I wait until I add it to master? Oct 23 09:56:01 or maybe musl's ldso fails to mmap the libraries due to memroy pressure Oct 23 09:56:06 I haven't altered any options which would impact this, so I'm following OpenWrt default here Oct 23 09:56:24 I personally am suspecting musl Oct 23 09:57:02 the device has 256MB of ram, currently 100MB free Oct 23 09:58:01 if someone is interested, I could pastebin all my unsolved crashlogs seen in the field Oct 23 09:58:34 stintel: two weeks without feedback can be seen as implicit ack - imho Oct 23 09:58:52 it's amazing how many mac80211 bugs pop up when using wifi at 50km at the verge of disconnection :) Oct 23 09:58:54 having at least one acked-by would look better Oct 23 10:02:50 jow: alright, thanks Oct 23 10:04:52 maybe I should get a tested-by, there should at least be one person here with an odroid c2 iirc Oct 23 10:06:28 I've got one, but it's not free fro experiments I'm afraid. Oct 23 10:20:53 no worries :) Oct 23 10:23:45 jow: http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c?id=8084d6ab57cdb0b8f328d3cdbad3b9d09eaaee04#n345 Oct 23 10:24:08 ill add some prints here locally to figure out why it fails .. Oct 23 13:17:57 jow: ping Oct 23 13:27:27 xback: pong Oct 23 13:27:56 jow: I'm currently fixing all ar71xx build errors 1by1 Oct 23 13:28:09 Currently working on target ap91-5G Oct 23 13:28:16 where I see this: MTDPARTS := spi0.0:256k(u-boot)ro,64k(u-boot-env),6144k(rootfs),1600k(kernel),64k(config)ro,64k(art)ro,7744k@0x50000(firmware) Oct 23 13:28:23 kernel and rootfs are swapped Oct 23 13:28:50 If this one gets dynamic partitioning .. does it impact kernel discovery on boot (as the entrypoint changes) ? Oct 23 13:48:04 xback: sadly I don't really know. However ap91 sounds like a reference board, in doubt simply deactivate it (comment out) Oct 23 13:50:09 jow: any idea about compile failure I posted yesterday (sorry I got disconnected after I sent you the link and didn't get to see your response, if any) Oct 23 14:03:31 abenz: unfortuantely no, would need to investigate the configure script to figure out whats wrong Oct 23 14:03:45 I suppose it got misgenerated Oct 23 14:03:55 I see Oct 23 14:14:07 xback: mvebu is still broken since your kernel bump: https://github.com/openwrt/openwrt/blob/master/target/linux/mvebu/cortexa9/config-default Oct 23 14:31:10 mangix: care to elaborate? buildbot seem to be happy Oct 23 15:19:51 mangix: I just testcompiled mvebu (cortex-a9) targets. Not seeing any error here? Oct 23 15:22:58 Did I do OK with my patch? https://patchwork.ozlabs.org/patch/987769/ Oct 23 15:24:02 You can remove v1 as I messed up the formatting Oct 23 16:11:04 jow: was failing for me. with my patch on patchwork, it builds fine. maybe my config is old. anyway, that file should not be there Oct 23 16:18:01 mangix: mvebu target consists of a 32bit version and 64 bit version of the soc. Oct 23 16:18:29 the 64bit version already contained this keyword: see --> linux/mvebu/cortexa53/config-default Oct 23 16:19:08 i'm on the 32 bit one Oct 23 16:19:38 i build for the turris omnia specifically Oct 23 16:20:04 ill give it a try and will come back to you. fair enough? :) Oct 23 16:20:24 lol ok Oct 23 16:20:45 Feel free to private mail me the buildlog which is failing Oct 23 16:31:15 mangix: why should the file not be there? Oct 23 16:32:14 anyone working on Compex HK01 by chance? Oct 23 16:36:45 build #120 of bcm53xx/generic is complete: Success [build successful] Build details are at http://release-builds.openwrt.org/18.06/images/builders/bcm53xx%2Fgeneric/builds/120 Oct 23 16:51:09 greearb_: I'm not but they look like fun Oct 23 16:53:44 wow, they do indeed Oct 23 16:55:21 I mean, .11ax is all a pack of lies for the moment, but.. Oct 23 16:55:40 I have not seen any firmware or driver support for QCA 11ax at this point Oct 23 16:56:25 See? Pack of lies! :) Oct 23 16:57:00 supposedly APs ship Q4, so *someone* has some firmware/driver Oct 23 16:57:19 It wouldn't be the first time this stuff ships non-working Oct 23 16:58:56 shipping working stuff would be a first ;) Oct 23 17:33:20 what's that expected to cost? $300 or something? Oct 23 17:34:20 probably more Oct 23 17:34:37 12 antennas? that's going to be pretty Oct 23 17:36:32 hedgehog Oct 23 17:36:50 or porcupine Oct 23 17:41:19 we're going to end up with spikey death stars in the end. Oct 23 17:43:00 karlp: that's the cost http://www.compexshop.com/product_info.php/cPath/63/products_id/229 :) Oct 23 17:48:30 I'd quite like that board without wireless :D Oct 23 17:48:39 and for a lot less, lol Oct 23 18:30:31 4GB ram.. Oct 23 18:31:03 would be feasable to run gcc on that Oct 23 18:31:09 with enough swap :) Oct 23 18:37:18 most manufacturers offer broadcom based now.. I see less and less qualcomm Oct 23 18:37:44 looking at current tplink models for example Oct 23 18:47:58 yeah Oct 23 18:48:08 qualcomm never had any decent chips Oct 23 18:48:16 but it looks like they've pulled their finger out now Oct 23 18:48:19 with the new IPQ stuff Oct 23 19:50:27 xback: why didn't you add HARDEN_BRANCH_PREDICTOR to the generic config? Oct 23 20:23:42 Hauke: was it you that was experimenting with 4.19 kernel? Oct 23 20:25:12 no Oct 23 20:25:35 stintel: there is a pull request on github with kernel 4.19 support Oct 23 20:25:42 but I haven't looked into the details yet Oct 23 20:25:44 oh Oct 23 20:25:50 from sartura? Oct 23 20:25:53 yes Oct 23 20:26:34 maybe i should try that with mesongx and see if odroid c2 has working hdmi with it (it should) Oct 23 20:27:21 what's our opinion about accepting 4.19 support atm? Oct 23 20:28:01 I think we should integarte it, but not use it as a default on any target till the release is branched off Oct 23 20:28:25 the next release should be done on 4.14 only Oct 23 20:28:56 I would like to get rid of some of the out of tree patches for 4.19 Oct 23 20:29:40 to reduce our maintainace efforts Oct 23 20:29:43 ok in that case I'll do mesongx as-is unless I get NAK within 10d Oct 23 20:30:14 ok Oct 23 20:30:43 I have not added any patches to it Oct 23 20:31:00 Felix added most of them ;-) Oct 23 20:31:37 I mean to target/linux/mesongx/patches Oct 23 20:31:57 ah ok Oct 23 20:34:10 I was looking at libre computer la frite kickstarter Oct 23 20:36:22 would nice to have another board that is compatible with the mesongx target Oct 23 20:37:54 tmn505: yeah, nuh, that's crazy much :) Oct 23 21:05:39 stintel: i was testing 4.19 Oct 23 21:05:55 i need to track some SPI controller driver regression AFAIR Oct 23 21:06:09 Hauke: i'd like to port all patches first and then start dropping them Oct 23 21:06:28 Hauke: so it's easy to say if something is broken because of: 1) kernel update 2) dropped patches Oct 23 21:06:42 Hauke: or start dropping them from 4.14 which I'm fine with too Oct 23 21:07:02 Hauke: maybe just send PATCHes for dropping patches so people can revie Oct 23 21:08:57 rmilecki: yes this should be at least different commits Oct 23 21:09:28 yes probably do it in an unrelated patch Oct 23 22:11:20 greearb_: if you need it, the serial console is a bit easier to get to on the zyxel nbg6817 (https://openwrt.org/toh/zyxel/nbg6817#serial) than on the netgear r7800 (https://openwrt.org/toh/netgear/r7800#serial), otherwise both are very similar and both have a robust push-button tftp recovery; the nbg6817 has a dualboot setup with two independet partition sets though Oct 23 22:11:52 pkgadd, thanks for that info. I'd pay extra for one that had a serial port built in :P Oct 23 22:12:25 I'm trying to get cross-compile working first...got two netgear on order Oct 23 22:12:33 fortunately it's built in on both, including the soldered on serial header - just a bit easier to reach on the nbg6817 Oct 23 22:14:13 https://github.com/pkgadd/nbg6817#4-gib-internal-emmc-kingston-s10004 that's the partition map on the eMMC Oct 23 22:14:28 pkgadd, I mean like with a nice DB9 port easily accessible, but indeed, not having to solder is a big step up! Oct 23 22:15:05 on the nbg6817 you just have to remove the 4 rubber feet to get to the screws beneath them Oct 23 22:16:17 if I want to resell this hardware with my product on it, and if there are any crashes in the field, then only a patient customer would take it apart and add a serial port Oct 23 22:16:27 disclaimer, I own the nbg6817, but not the r7800 Oct 23 22:16:58 both have very reliable tftp push-button recovery, the r7800 acts as tftp server, the nbg6817 as tftp client Oct 23 22:17:25 that will help dev process for sure. Oct 23 22:17:42 And, just maybe there is a way to store last panic info in RAM so it can be found on reboot? Oct 23 22:18:52 the nbg6817 has two flash chips, a small 4 MB spi-nor, with the bootloader, ART and that kind of stuff - and the actual firmware (header, kernel, rootfs) on the big 4 GB eMMC - the spi-nor never needs to be touched (other than for toggling the bootflag) Oct 23 22:19:14 hmm, never tried that Oct 23 22:22:35 with a bad kernel crash, that last panic output on serial console is vital for debugging Oct 23 22:23:28 CONFIG_CRASHLOG=y and CONFIG_CRASH_DUMP=y are enabled by default on ipq806x Oct 23 22:23:38 nice, will have to try that Oct 23 22:23:44 never used it before Oct 23 22:24:11 I'm pretty happy with mine Oct 23 22:24:29 but both devices are virtually identical Oct 23 23:25:22 is there a typical way to determine if a component didn't pass Q/A? for instance if a flash chip has a slash written on it in pen Oct 23 23:28:27 what makes you believe there'd be any kind of reliable standard for that? Oct 23 23:29:19 a marking (often a blobs of paint) is often used to distinguish programmed flash chips from empty ones, but that's about it Oct 24 00:15:08 just curious is all, nice to know Oct 24 00:16:13 you can read the flash contents multiple times and see if you always get the same result Oct 24 00:18:13 i have one that seems to have bit the dust right at the beginning of the bathtub curve (normal, but unfortunate), i flashed it maybe 3 or 4 times, then it started crashing during operation, and now it can't even boot Oct 24 00:19:27 it hangs in uboot saying "relocating code to memory address M", which is slightly different each time Oct 24 00:20:06 have you tried another power supply? Oct 24 00:21:41 actually, no because i don't really have the means to at the moment Oct 24 00:22:08 but i have a copy of the board using the same power supply and it has no issues Oct 24 00:23:03 but i'll try to see if i can get another one of those power adaptors made up in the workshop **** ENDING LOGGING AT Wed Oct 24 03:00:00 2018