**** BEGIN LOGGING AT Sun Jul 21 02:59:57 2019 Jul 21 06:24:24 ldir: I'm not expert either, but that strncpy should be memcpy because the compiler rightfully complains about it, and doing this kind of fixes leads even to more problems Jul 21 06:25:05 ldir: take for example at mkrtn56uimg.c around line 172 there is following `strncpy((char *)&hdr->tail.asus.productid, "RT-N56U", IH_PRODLEN);` Jul 21 06:25:48 I've changed it to correct `memcpy(&hdr->tail.asus.productid, "RT-N56U", IH_PRODLEN);` Jul 21 06:26:10 and now compiler spots the problem: string_fortified.h:34:10: error: ‘__builtin_memcpy’ forming offset [9, 23] is out of the bounds [0, 8] [-Werror=array-bounds] Jul 21 06:26:29 :] Jul 21 06:28:55 BTW your otherOS formatting fixes like %ld -> %lld are going to bomb out again on !otherOS, if we find such issues, we probably need to use portable string formats from inttypes.h like in ff7909f69ef8f178501797ea9599a0add3f2cbd5 Jul 21 07:23:49 s/%lld/%" PRIu64 "/g Jul 21 08:35:00 Morning - I think I should start again on the fixes, hopefully doing it properly this time. Jul 21 08:38:44 and this time I'll have your alpha sort commit in there so I can start a->z Jul 21 08:49:00 re-done my first - commit message much better - fix is memcpy instead of strncpy Jul 21 08:49:48 actually it would be more sane to subtract one from size Jul 21 08:51:57 I'm not happy with that either. Jul 21 08:52:41 there's a leak from beyond end argv[1] Jul 21 09:01:23 a hopefully better & correct fix Jul 21 09:33:03 do we plan to pick mac80211 update to 19.07? mac80211: Update to version 5.2-rc7 Jul 21 09:33:13 Hauke ynezz jow ? Jul 21 09:33:33 no opinion here, just asking Jul 21 10:01:37 rmilecki: I would like to update it to 4.19.47 or something like that Jul 21 10:02:04 I do not know if 5.2-c7 is stable enought Jul 21 10:56:44 Is there any timeline when 19.07 will be released at least to RC? Jul 21 11:14:29 I'm trying to patch the linux kernel to make my device compatible. Currently it just crashes with an exception. Is there an easy way to get a stacktrace? Currently I'm adding printk lines until I've found the problem Jul 21 11:32:02 someoner: it crashes before the kernel installed its own exception handlers, which are needed for stacktraces Jul 21 11:32:47 oh too bad. Jul 21 11:33:15 Then I'll continue with printk and while(1){} Jul 21 11:33:42 ah, good old infinite loop debugging Jul 21 11:34:25 yep, I'm suspecting that the kernel is also messing with my serial port Jul 21 11:38:02 in what way? Jul 21 11:43:40 I've assigned the cores statically. Then it runs into `ssb_mipscore_init` (https://elixir.bootlin.com/linux/v4.20.17/source/drivers/ssb/driver_mipscore.c#L293 ). There suddenly printk stops working (I guess around here: https://elixir.bootlin.com/linux/v4.20.17/source/drivers/ssb/driver_mipscore.c#L321 ). and then there is this exception Jul 21 11:44:04 (there is a very good chance I did something wrong with the static core assignment...) Jul 21 11:44:44 exception https://pastebin.com/01y4dJAq Jul 21 11:45:17 someoner: the ssb_mipscore_init also calls ssb_mips_serial_init(mcore) Jul 21 11:45:26 could be that this is wrong and breaks your serial Jul 21 11:45:55 yes, I've already seen this. But the serial appears to be broken before. Jul 21 11:46:14 and the crash is also more early Jul 21 11:47:45 Btw. couldn't I use this JTAG to debug the code? I'm kind of annoyed by the current procedure Jul 21 11:48:34 (compile, copy to tftp server, reboot device, stop bootloader, assign ip address, boot from tfpt server) Jul 21 11:54:58 someoner: a1 ($05) = B8005F18 - this is SSB_TPSFLAG of the mips core; maybe it doesn't like accesses to the ssb regs (0xf00~) of the mips core at all Jul 21 11:57:29 strange device. I'll take a look at the ecos sources to see what they are doing Jul 21 11:58:34 How do you read these exception handlers? Are you just looking at all registers and try to find a useful address? Jul 21 11:59:49 a0~a3 are defined as function arguments, v0~v1 are return value(s), ra is the return address (from where the current function was called) Jul 21 12:01:08 defined by whom? the mips platform? the linux kernel? The compiler? Jul 21 12:01:35 you should be able to load the vmlinux into gdb and tell it to show you the code at 0x8027A97C (EPC = Error Program Counter, i.e. the place where the exception occured) Jul 21 12:01:56 it's the MIPS32 ABI Jul 21 12:03:14 Thanks! This sounds super super useful. I'll try this Jul 21 12:03:15 someoner: https://en.wikipedia.org/wiki/Calling_convention#MIPS (OABI) Jul 21 12:04:10 great, I'll take a closer look at it Jul 21 12:13:43 It looks like using gdb with the EPC works ( https://pastebin.com/xQaLVjKq ), but it isn't that useful :D Jul 21 12:13:57 But I'll keep it in mind for other problems Jul 21 12:39:01 I have kept digging into the ath9k-issue from yesterday. It seems there is ... something with the calibration data. I see that the opFlags byte has the value 0x08, while the only legal values I can find looking at the driver is 0x1, 0x2 and 0x3. Think I will send a mail to linux-wireless and ask Jul 21 12:46:54 kristrev: maybe wrong endianess? Jul 21 12:47:51 someoner: check the value from ra, the return address (or rather ra-8) Jul 21 12:53:04 KanjiMonster: good idea, but still to early in the call stack. ( https://pastebin.com/iuipQCqB ) Anyway I guess that the crash occurs here: https://elixir.bootlin.com/linux/v4.20.17/source/drivers/ssb/driver_mipscore.c#L77 Jul 21 12:54:12 KanjiMonster: Yeah, I was also thinking about that, but when comparing with the caldata from another device that works then the content match Jul 21 12:55:30 However, it seems that loading calibration data from file does not care about endianess, while loading from eeprom triggers some endianess-checks Jul 21 12:55:38 I will take a second look, thanks Jul 21 13:00:13 ynezz: ping Jul 21 13:01:38 my problem with the strncpy -> memcpy switch is what happens when the source string is shorter than the length parameter? Jul 21 13:03:37 strncpy is guaranteed to fill the bigger destination with null, whereas memcpy will 'happily' copy 'n' bytes from the source to the destination even if the source isn't long enough. Jul 21 13:10:16 "SEC_ERROR_EXPIRED_CERTIFICATE" on bugs.openwrt.org Jul 21 13:10:26 jow: ^ Jul 21 13:10:47 LE cert seems to be non-automated Jul 21 13:53:18 hm, I don't think the problem is endianess. If endianess was wrong, the opFlags should have the value 0x1. 0x1 is the value of AR5416_OPFLAGS_11A, which enabled 5GHz. My card is only 2.4 :( Jul 21 14:00:21 I guess I will wait a bit before I submit my patch, an outdoor AP without wifi is a bit pointless (even though it is possible to insert another wifi card) Jul 21 14:59:00 I just removed the acces to SSB_TPSFLAG and now it boots further. Then suddenly I can't read anything at the serial terminal. Could it be that the baud rate changes?f Jul 21 15:02:31 too bad that I don't have an osci or logic analyzer close by Jul 21 15:16:29 I mean this boot log isn't too bad: https://pastebin.com/YdUa3qC5 Jul 21 15:17:03 not sure why it does ttyS0 at MMIO 0xb8000300 (irq = 8, base_baud = 5500000) Jul 21 15:18:16 actually 5.5MBaud sounds a little bit high Jul 21 15:19:16 actually it is too high for my usb adapter Jul 21 15:20:46 someoner: this looks good Jul 21 15:21:36 it should use the same baud rate as before, so probably 112500 Jul 21 15:21:46 it was 9600 before Jul 21 15:22:02 hi, where can I find kmod-wireguard in the package feed? Jul 21 15:22:20 I actually tried to switch to 112500 and it seems wrong Jul 21 15:22:49 mwarning: in the main repo at package/network/services/wireguard Jul 21 15:58:57 could someone runing an ipq806x device (pref r7800) and kernel 4.14 pastebin the output of Jul 21 15:59:18 cat /sys/devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00 Jul 21 15:59:20 .0/resourcey Jul 21 16:00:17 cat /sys/devices/platform/soc/1b700000.pci/pci0001:00/0001:00:00.0/resource Jul 21 16:13:06 will be afk for a time... but I'll check back Jul 21 16:15:04 back for more Jul 21 16:35:55 actually, nvmd, need to go off line... Jul 21 17:45:09 I'm still trying to figure out what is happening with the serial port. There must be some reason it suddenly only shows stange characters (best guess the baud rate changes) Jul 21 17:45:15 I've found the ssb_chipco_serial_init Jul 21 17:45:38 https://elixir.bootlin.com/linux/v4.20.17/source/drivers/ssb/driver_chipcommon.c#L601 Jul 21 17:46:46 here it runs into /* Fixed internal backplane clock */. I already tried to set baud_base to 133000000 (like ecos), but that didn't fix the problem Jul 21 17:47:35 ( https://github.com/fvollmer/GS108Tv2-ecos-2.0/blob/5ea37b8732c52c9178722f430062332f48b4db0f/packages/hal/mips/bcm953710/v2_0/src/sbmips.c#L265 ) Jul 21 17:51:35 rotanid: thanks. It actually was automated, not sure what broke this time Jul 21 17:51:51 switched to DNS based verification while I repaired the cert anyway Jul 21 18:36:38 ping 192.168.5.1 Jul 21 18:36:40 ops Jul 21 18:57:18 * ldir plods through compiler warnings Jul 21 19:03:26 someoner: 115200 Jul 21 19:05:55 or, attach one of these and measure the baud rate: https://www.ebay.com/itm/USB-Logic-Analyzer-Device-Set-USB-Cable-24MHz-8CH-24MHz-for-ARM-FPGA-M100-M434/173667694978 Jul 21 19:06:04 or an oscilloscope Jul 21 19:06:57 * Slimey crosses fingers on xigmanas upgrade Jul 21 19:11:50 russell--: I have one of these, but I can't access it right now Jul 21 19:12:09 I have to wait until Monday evening Jul 21 19:35:56 someoner: sigrok's pulseview is a lot of fun ;-) Jul 21 19:36:46 yes, this should identify whatever is going on Jul 21 20:17:38 hmm. my dir860l-b1 is panic'ing during boot, tried a make-dirclean-world build, booting initramfs from u-boot Jul 21 20:20:26 It seems like the kernel tries to switch from the early console? If I comment out this line https://elixir.bootlin.com/linux/v4.20.17/source/drivers/tty/serial/serial_core.c#L2365 the baud rate change happens later. I guess the ssb chipcommon uart is somewhat wrong configures(?). Is there a way to continue to use the early print console for everyth Jul 21 20:20:27 ing? Jul 21 20:51:56 Hmm, after some trail and error it looks like the baud rate is 90k ?! Jul 21 20:52:24 heh Jul 21 20:53:05 new bootlog: https://pastebin.com/g0jd1ckv (The strange symbols are due to manually switching to 90kBaud) Jul 21 20:54:20 It sems to just hang after this Jul 21 20:56:50 shouldn't I get a promt or something? Jul 21 20:58:40 I guess this is the problem: "Initrd not found or empty - disabling initrd" ? Jul 21 21:07:18 Isn't vmlinux-initramfs.elf the file I need to boot? Jul 21 21:15:12 updated openwrt/upstream, https://sdwalker.github.io/uscan/index.html Jul 21 21:24:14 dir860l snapshot doesn't include the wireless driver? Jul 21 21:26:29 russell--: according to https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ramips/image/mt7621.mk;h=73ded64e7449fa418c50a5596689687347ecb216;hb=HEAD#l139 kmod-mt76x2 should be preinstalled, unless explicitly overriden in a custom build Jul 21 21:28:27 pkgadd: it is not in https://downloads.openwrt.org/snapshots/targets/ramips/mt7621/openwrt-ramips-mt7621-dlink_dir-860l-b1-initramfs-kernel.bin Jul 21 21:29:35 ah, initramfs - I don't really know if that differs Jul 21 21:38:34 pkgadd: yeah, confirmed the sysupgrade snapshot is broken too Jul 21 21:39:17 [ 14.654604] [<86f7b5c8>] mt76_eeprom_override+0x38/0xdc [mt76] Jul 21 21:39:17 [ 14.666214] [<8715c378>] mt76x2_eeprom_init+0x270/0x56c [mt76x2_common] Jul 21 21:39:20 [ 14.679385] [<86f5d058>] mt76x2_register_device+0x1ac/0x590 [mt76x2e] Jul 21 21:43:02 is mt7615e capable of wave2? Jul 21 21:50:15 the hardware, afaik yes - the driver, I have no idea (I think it's currently reaching top speeds, based on the reports) Jul 21 21:52:55 top speeds of the hardware, you mean? Jul 21 22:00:50 the current level of mt7615e support in the mt76 apparently isn't that fast yet, the hardware could do 802.11ac/ wave2 with 4x4 Jul 22 00:04:19 russell--: You need a patch to cover the latest mac80211 changes, it's.. an arse to figure out Jul 22 00:04:41 russell--: Someone beat me to it by about two hours: https://github.com/openwrt/mt76/pull/298 Jul 22 00:06:15 Monkeh: dankeschön Jul 22 00:09:58 I'm hoping nbd will catch that tomorrow for us Jul 22 01:06:25 rmilecki: looks like you were the one who did the device tree bindings for mtdsplit, but i'm not sure how to work around the fact that if more than one partition has the bindings, they are separately split with duplicate names **** ENDING LOGGING AT Mon Jul 22 03:02:02 2019