[+cc linux-pci] On Mon, Nov 04, 2019 at 05:04:54PM +0100, Carlo Pisani wrote: > > > > It sounds like the firmware fails to even load v4.11? If that's the > > > > case, it's probably not a problem with the kernel itself, since it > > > > hasn't even started executing. Possibly a kernel size problem? Maybe > > > > the v4.11 kernel is larger than v4.4, v4.9, etc? Does v4.11 boot if > > > > you strip out non-essential drivers? > > kernel v4.11 is 7.5Mbyte and doesn't boot from the TFTboot option > offered by the firmware, it claims "out of range", which makes no > sense > > out of range in what? too big? bad initialized? who knows .... > > > Is the v4.11 kernel image bigger than the v4.4 kernel that boots? > > everything bigger than 7Mbyte seems to be bad for the firmware. You should be able to test this by adding built-in drivers to your v4.4 kernel so it becomes larger than 7 MB. If the kernel size is the problem, a large v4.4 kernel should fail the same way the v4.11 kernel does. > anyway, I post here to hear if someone is on the RB532A (Mikrotik), > should I also open a ticket to OpenWrt? I guess it wouldn't hurt to open an OpenWrt ticket because maybe more people there have experience with the RB532A. But if the problem is simply that the RB532A has broken Rhine devices that don't correctly support PCI MMIO access, the only fix is to work around it by using I/O port access instead. Your matrix at [1] seems to show that the only reliable "stable for 48h" combination is the one with PCI MMIO access disabled. If there's some way to identify that broken device or the platform, e.g., RB532A, somebody could write a quirk to automatically disable PCI MMIO in the driver. But the comment in the driver already mentions that, so I guess it's not trivial to identify those cases. [1] http://www.downthebunker.com/reloaded/space/viewtopic.php?f=79&p=2755
