**** BEGIN LOGGING AT Sat May 01 03:00:43 2021 May 01 03:11:04 Build [#72](https://buildbot.openwrt.org/master/images/#builders/55/builds/72) of `malta/be` failed. May 01 03:29:40 Build [#72](https://buildbot.openwrt.org/master/images/#builders/14/builds/72) of `bcm63xx/generic` failed. May 01 03:36:48 Build [#77](https://buildbot.openwrt.org/master/images/#builders/22/builds/77) of `ipq40xx/generic` failed. May 01 03:44:56 Build [#73](https://buildbot.openwrt.org/master/images/#builders/28/builds/73) of `octeontx/generic` failed. May 01 04:22:08 Build [#82](https://buildbot.openwrt.org/master/images/#builders/45/builds/82) of `bcm47xx/legacy` failed. May 01 04:33:31 Build [#72](https://buildbot.openwrt.org/master/images/#builders/70/builds/72) of `bcm47xx/mips74k` failed. May 01 04:52:40 Build [#75](https://buildbot.openwrt.org/master/images/#builders/54/builds/75) of `ramips/mt7620` failed. May 01 05:30:05 Build [#73](https://buildbot.openwrt.org/master/images/#builders/23/builds/73) of `mpc85xx/p2020` failed. May 01 06:42:07 Build [#67](https://buildbot.openwrt.org/master/images/#builders/36/builds/67) of `mediatek/mt7629` failed. May 01 06:52:59 Build [#73](https://buildbot.openwrt.org/master/images/#builders/27/builds/73) of `mpc85xx/p1020` failed. May 01 06:53:00 Build [#72](https://buildbot.openwrt.org/master/images/#builders/31/builds/72) of `layerscape/armv8_64b` failed. May 01 07:04:14 Build [#70](https://buildbot.openwrt.org/master/images/#builders/56/builds/70) of `kirkwood/generic` failed. May 01 07:08:11 Build [#78](https://buildbot.openwrt.org/master/images/#builders/15/builds/78) of `armvirt/64` failed. May 01 07:23:07 Build [#77](https://buildbot.openwrt.org/master/images/#builders/47/builds/77) of `bcm27xx/bcm2710` failed. May 01 07:23:37 Build [#70](https://buildbot.openwrt.org/master/images/#builders/42/builds/70) of `ramips/mt76x8` failed. May 01 07:43:24 Build [#75](https://buildbot.openwrt.org/master/images/#builders/63/builds/75) of `ath79/tiny` failed. May 01 07:46:17 Build [#75](https://buildbot.openwrt.org/master/images/#builders/24/builds/75) of `ramips/rt288x` failed. May 01 08:01:30 Build [#71](https://buildbot.openwrt.org/master/images/#builders/13/builds/71) of `lantiq/xway_legacy` failed. May 01 08:21:44 Build [#75](https://buildbot.openwrt.org/master/images/#builders/39/builds/75) of `ath79/nand` failed. May 01 08:24:33 Build [#75](https://buildbot.openwrt.org/master/images/#builders/48/builds/75) of `bcm47xx/generic` failed. May 01 08:25:19 Build [#76](https://buildbot.openwrt.org/master/images/#builders/16/builds/76) of `ath79/mikrotik` failed. May 01 09:19:37 Build [#68](https://buildbot.openwrt.org/master/images/#builders/10/builds/68) of `bcm63xx/smp` failed. May 01 09:43:55 Build [#70](https://buildbot.openwrt.org/master/images/#builders/57/builds/70) of `octeon/generic` failed. May 01 09:57:38 Build [#73](https://buildbot.openwrt.org/master/images/#builders/21/builds/73) of `bcm27xx/bcm2709` failed. May 01 10:10:42 Build [#78](https://buildbot.openwrt.org/master/images/#builders/12/builds/78) of `bcm53xx/generic` failed. May 01 10:17:38 Build [#69](https://buildbot.openwrt.org/master/images/#builders/19/builds/69) of `ramips/mt7621` failed. May 01 10:28:24 My ISP is wierd.. Apparently, they have the DHCP TTL set to.. 291 hours.. (12d,3hr).. What? May 01 10:37:12 zorun: ping? May 01 10:42:20 f00b4r0: pong May 01 10:42:27 zorun: Baptiste, right? May 01 10:42:32 yup :) May 01 10:42:50 ok :) May 01 10:43:08 interesting hard_config, right? May 01 10:43:17 there are two ways to "fix" what you describe. I just quickly checked my rb_hardconfig code and it will handle a small-in-large hard config no problem May 01 10:44:02 yes, we never know the exact size in advance anyway May 01 10:44:12 so you can either "fix" this globally, by applying the following patch: https://paste2.org/9jyd1Wjc; or you can override size for the hap-ac2 DTS only May 01 10:44:35 the patch basically makes hard_config extend up to the next declared partition. May 01 10:44:44 ah, nice May 01 10:45:10 The "minor" issue is that to be on hte safe side, this needs to be tested on all existing devices ;P May 01 10:45:16 yeah :/ May 01 10:45:31 I think I'll go with the DTS solution May 01 10:45:33 off the top of my head it will work; but of course until proven wrong May 01 10:45:58 but we also need to increase various buffers in the rb_hardconfig driver (I'm working on it but still not working) May 01 10:46:35 which buffers? There's only one hard-coded one and that's the ART_SIZE May 01 10:47:11 the code assumes that the decompressed / decoded output will fit in 4K (a single block) May 01 10:47:14 which is not the case here May 01 10:48:34 hmm May 01 10:48:42 I don't see that. Can you point me at the code line? May 01 10:49:32 the decompression buffer is 0x10000, not 0x1000 May 01 10:50:11 https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/generic/files/drivers/platform/mikrotik/rb_hardconfig.c#l649 May 01 10:50:23 yes. Tha'ts 65k. Not 4k May 01 10:50:46 64* May 01 10:50:57 hmmm, right May 01 10:51:10 there's no other hardcoded size here, I made sure of that :) May 01 10:51:39 when reading /sys/firmware/mikrotik/hard_config/wlan_data with cat it's always 4K, which is why I thought it was because of this May 01 10:51:47 no wonder increasing the buffer size didn't help :p May 01 10:52:02 the "size" reported by the system isn't the actual data size May 01 10:52:09 this is a sysfs attribute, not a regular file. May 01 10:52:20 if there's out of space issue it will show up in dmesg. May 01 10:52:29 yeah the reported size is 0, I read it with cat /sys/.../wlan_data > /tmp/wlan_data May 01 10:52:44 ah May 01 10:53:18 btw the actual root issue that got me on that journey is that the ath10k driver fails to load the firmware May 01 10:53:32 4k is PAGE_SIZE too, and we've seen truncation with busybox' dd in the past. That shouldn't affect cat however. May 01 10:54:07 do check dmesg with debug log level. The driver is verbose. May 01 10:54:16 it will tell you if something goes wrong. May 01 10:54:23 not that verbose actually ;) but I did add some debug May 01 10:54:36 I get the "LZOR: LZO EOF before buffer end - this may be harmless" but that's kind of expected May 01 10:54:38 certainly verbose enough to report all errors though May 01 10:54:45 yes May 01 10:55:39 i'm assuming that you're doing these tests with size correctly set in DTS? May 01 10:55:58 yes May 01 10:58:00 try reading from wlan_data with dd if=wlan_data iflag=fullblock May 01 10:58:08 that's what we use in package/base-files/files/lib/functions/caldata.sh May 01 10:59:12 "7+1 records in/out" (strange), but still 4K May 01 11:00:06 I'm adding debug to the bin_read function May 01 11:00:11 pipe it to hexdump (avoid writing it to /tmp) May 01 11:01:45 btw do the content make sense (i.e. look like truncated calib data)? May 01 11:02:45 builds should be fixed again May 01 11:06:18 it does look like calibration data (not-so-nice ASCII art ;) ), but truncated, I don't know May 01 11:08:12 I don't get it: after LZO decompression, the size is 15216 bytes, but after RLE decoding it's only 4050 bytes May 01 11:08:45 which is exactly the size of the generated wlan_data "file" (4050 and not 4096, I should have checked) May 01 11:09:08 so I guess everything is generated as expected and there is no truncation May 01 11:09:52 and here you were blaming *MY BABY* :D May 01 11:10:17 RLE decode shorter than the input is very odd though May 01 11:10:34 eh :) May 01 11:10:47 ah, in between, there's the TLV tag May 01 11:10:58 ah right May 01 11:11:20 found tag id 0x0001 (offset=4, length=1710) May 01 11:11:45 so it's consistent with the final size May 01 11:11:53 indeed May 01 11:12:05 and yet your device still doesn't load caldata? May 01 11:12:11 but we have a 15216-bytes buffer that only contains 1710 bytes worth of data? strange May 01 11:12:47 yes: https://paste.debian.net/hidden/d19efd9b/ May 01 11:12:53 yeah don't ask me. I've been flying blind since day one on this crap :P May 01 11:13:56 I checked that hc_wlan_data_bin_read() is called just before these errors May 01 11:14:48 hmm May 01 11:14:54 that's not a caldata load failure May 01 11:14:57 that's a BRD load failure May 01 11:15:03 if I read this right May 01 11:15:15 ah... I don't get the difference May 01 11:15:42 hold on May 01 11:15:49 https://paste.debian.net/hidden/771dc1b4/ May 01 11:16:18 yes; but if the provided board file does not contain a matching id for your device, it won't load. I wonder if that's what we seeing here May 01 11:17:17 hmm May 01 11:19:17 though the caldata still looks weirdly small. May 01 11:19:25 I don't have my ac2 at hand right now so can' compare May 01 11:21:02 zorun: i have to run. If you pore through PR#3037 comments you will find details about BRD and how it can normally even be extracted from wlan_data (which makes me think again that what you're seing is too short) May 01 11:35:38 sure, I'm catching up May 01 11:35:41 thanks for the help May 01 11:48:31 zorun: you might want to get robimarko involved, AIUI he's using these devices in a commercial way, and he has more insight about the actual contents of the compressed data (which I don't) May 01 11:49:03 also fyi, I wrote a small tool to parse hard/soft config, it's here: https://gist.github.com/f00b4r0/8e97de73f3abe80ed67feded529f27ce May 01 11:50:54 me too ;) https://github.com/zorun/openwrt-hacking/tree/master/tools May 01 11:50:56 yes, good idea May 01 12:04:47 looks like the board-id is wrong: the driver tries to load bmi-board-id=20, while the board-2.bin file contains 16 and 17 May 01 12:05:01 Build [#81](https://buildbot.openwrt.org/master/images/#builders/6/builds/81) of `lantiq/xway` completed successfully. May 01 12:07:34 zorun: there you go. I'm not surprised. ISTR I mentioned something like this could eventually happen, which is why in #3037 I tried to offer a way to dynamically extract board data from the flash (it's there) May 01 12:08:22 I'll reply on the m-l with a quick run down on rb_hardconfig and the one-line patch I mentioned earlier, just "for the record" May 01 12:10:45 zorun: done. This being May 1st and the weather being nice here, I think I'll be off now. Feel free to ping me over email later though. I hope we can find a robust way to deal with Mikrotik's shenanigans ;) May 01 12:12:34 Build [#91](https://buildbot.openwrt.org/master/images/#builders/1/builds/91) of `ath79/generic` completed successfully. May 01 12:20:54 Build [#94](https://buildbot.openwrt.org/master/images/#builders/7/builds/94) of `armvirt/32` completed successfully. May 01 13:39:08 Build [#75](https://buildbot.openwrt.org/master/images/#builders/51/builds/75) of `ramips/rt3883` completed successfully. May 01 14:22:17 Build [#72](https://buildbot.openwrt.org/master/images/#builders/40/builds/72) of `ipq40xx/mikrotik` completed successfully. May 01 14:34:35 Build [#75](https://buildbot.openwrt.org/master/images/#builders/46/builds/75) of `ath25/generic` completed successfully. May 01 14:54:26 Build [#87](https://buildbot.openwrt.org/master/images/#builders/2/builds/87) of `layerscape/armv7` completed successfully. May 01 15:06:35 i have a custom package using automake, is there a good way within the openwrt build system to get it to build in a subdirectory? May 01 15:11:59 do you mean https://openwrt.org/docs/guide-developer/packages#building_in_a_subdirectory_of_the_source ? May 01 15:12:11 or do you mean 'mkdir build; cd build; ../configure' ? May 01 15:24:30 Build [#82](https://buildbot.openwrt.org/master/images/#builders/26/builds/82) of `apm821xx/sata` completed successfully. May 01 15:42:20 Build [#76](https://buildbot.openwrt.org/master/images/#builders/53/builds/76) of `bcm27xx/bcm2711` completed successfully. May 01 15:42:54 Habbie: the latter May 01 15:43:27 russell--, ah, then I got nothing other than 'override the step' May 01 15:52:23 Build [#75](https://buildbot.openwrt.org/master/images/#builders/44/builds/75) of `mediatek/mt7622` completed successfully. May 01 16:06:22 leaving this here "grub-mkimage: error: Decompressor is too big." getting this error when using binutils 2.36_1 May 01 16:26:09 Build [#73](https://buildbot.openwrt.org/master/images/#builders/55/builds/73) of `malta/be` completed successfully. May 01 16:45:33 Build [#74](https://buildbot.openwrt.org/master/images/#builders/28/builds/74) of `octeontx/generic` completed successfully. May 01 17:33:52 Build [#83](https://buildbot.openwrt.org/master/images/#builders/45/builds/83) of `bcm47xx/legacy` completed successfully. May 01 17:41:35 hmmm... if I run valgrind with --track-origins=yes it's exits with 137... if I don't use that, it runs fine... May 01 17:43:34 nbd: any ideas? this is on ath79 (archer a7 v5) May 01 17:51:02 Build [#73](https://buildbot.openwrt.org/master/images/#builders/14/builds/73) of `bcm63xx/generic` completed successfully. May 01 17:53:53 PaulFertser: ping May 01 17:58:23 Build [#73](https://buildbot.openwrt.org/master/images/#builders/70/builds/73) of `bcm47xx/mips74k` completed successfully. May 01 18:02:54 Build [#78](https://buildbot.openwrt.org/master/images/#builders/22/builds/78) of `ipq40xx/generic` completed successfully. May 01 18:12:38 philipp64: pong May 01 18:13:07 philipp64: I haven't ever tried running valgrind on mips, sorry May 01 18:14:07 philipp64: usually same issues (highlighted by valgrind) can be reproduced on x86 too. May 01 18:14:16 okay. what's required to make source line numbers work? to build a package with -g -O0 and leave it unstripped? May 01 18:15:16 philipp64: source line numbers work with -O2 or -Os (or any other optimisation level) too. Yes, I think valgrind needs debug info so -g and unstripped would be certainly needed. May 01 18:15:48 I don't want code reordering screwing up debugging... May 01 18:16:27 Do I need to modify the package's Makefile's to enable those, or is there a top-level way to do this? May 01 18:18:02 philipp64: https://openwrt.org/docs/guide-developer/gdb has related things May 01 18:28:38 Build [#76](https://buildbot.openwrt.org/master/images/#builders/54/builds/76) of `ramips/mt7620` completed successfully. May 01 18:58:09 /nick Grommish May 01 18:58:20 Silly client May 01 19:19:58 Build [#74](https://buildbot.openwrt.org/master/images/#builders/23/builds/74) of `mpc85xx/p2020` completed successfully. May 01 20:37:42 Build [#71](https://buildbot.openwrt.org/master/images/#builders/56/builds/71) of `kirkwood/generic` completed successfully. May 01 20:46:11 Build [#74](https://buildbot.openwrt.org/master/images/#builders/27/builds/74) of `mpc85xx/p1020` completed successfully. May 01 21:08:59 Build [#78](https://buildbot.openwrt.org/master/images/#builders/47/builds/78) of `bcm27xx/bcm2710` completed successfully. May 01 21:19:16 Build [#79](https://buildbot.openwrt.org/master/images/#builders/15/builds/79) of `armvirt/64` completed successfully. May 01 21:35:24 Build [#73](https://buildbot.openwrt.org/master/images/#builders/31/builds/73) of `layerscape/armv8_64b` completed successfully. May 01 22:29:05 Build [#71](https://buildbot.openwrt.org/master/images/#builders/42/builds/71) of `ramips/mt76x8` completed successfully. May 01 22:51:25 Build [#76](https://buildbot.openwrt.org/master/images/#builders/24/builds/76) of `ramips/rt288x` completed successfully. May 01 23:12:01 Build [#76](https://buildbot.openwrt.org/master/images/#builders/63/builds/76) of `ath79/tiny` completed successfully. May 01 23:18:52 Build [#72](https://buildbot.openwrt.org/master/images/#builders/13/builds/72) of `lantiq/xway_legacy` completed successfully. May 02 00:28:34 Build [#76](https://buildbot.openwrt.org/master/images/#builders/48/builds/76) of `bcm47xx/generic` completed successfully. May 02 00:58:13 Build [#77](https://buildbot.openwrt.org/master/images/#builders/16/builds/77) of `ath79/mikrotik` completed successfully. May 02 01:53:14 Build [#69](https://buildbot.openwrt.org/master/images/#builders/10/builds/69) of `bcm63xx/smp` completed successfully. May 02 02:50:43 Build [#71](https://buildbot.openwrt.org/master/images/#builders/57/builds/71) of `octeon/generic` completed successfully. **** ENDING LOGGING AT Sun May 02 02:59:56 2021