On Sat, Apr 23, 2022 at 12:04:31AM +0200, Arnd Bergmann wrote: > On Fri, Apr 22, 2022 at 10:55 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > On 4/22/22 12:16, Arnd Bergmann wrote: > > > On Fri, Apr 22, 2022 at 7:05 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > > > > > > Which machine did you hit this on? Is this on hardware or in qemu? > > > > > qemu, as always. borzoi, spitz, terrier, tosa, z2, and sx1 fail. > > Also, I just noticed that the failure is not always the same. > > z2 fails to boot from initrd, and sx1 fails to boot completely. > > That's a lot of machines failing, I hope at least we got the same bugs more > than once here. > > For the I/O space, I found now that PXA was not using the standard > virtual I/O address yet, but instead used a NULL-based offset. > > I'm not entirely happy with this patch, but this is an outline of what > I think we need to fix that: https://pastebin.com/3nVgQsEw > This one is probably incomplete, at least it breaks sa1100 for now, > and it adds a bogus CONFIG_PCI dependency. I'm also not sure > in what way the last patch in the series triggers it, rather than the > one that removed mach/io.h. > > I had sx1 booting in qemu at least, with the omap1 multiplatform series only. > If you have a custom config for this one, make sure you get the right > DEBUG_LL address. > > > I'll do another round of bisects. > So ... z2 bisect points to the same patch, but the error is different. As mentioned, it does not recognize the initrd. Oddly enough, booting from initrd works for the other platforms. The sx1 boot failure seems to be unrelated to your patch series. It boots fine if built from the tip of your branch, but fails to boot in -next. That will require a bisect from -next. Guenter
