On 28 June 2013 08:01, Rob Landley <r...@landley.net> wrote: > Now that the next kernel's about to come out, I'm trying to get my arm > versatile image to work under qemu 1.5.0. The old kernel doesn't work, and > the current vanilla kernel doesn't work. This change broke it. > > I'm testing current linux-git both with and without this patch: > > --- linux/arch/arm/mach-versatile/pci.c 2013-04-28 19:36:01.000000000 -0500 > +++ linux.bak/arch/arm/mach-versatile/pci.c 2013-04-29 > 19:09:44.857097553 -0500 > @@ -333,7 +333,7 @@ > * 26 1 IRQ_SIC_PCI2 > * 27 1 IRQ_SIC_PCI3 > */ > - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > + irq = 59; //IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); > > return irq; > } > > With the patch, qemu 1.2.0 works, but qemu 1.5 versatile does not work with > or without the patch.
The "with the patch" case is uninteresting, because it's not actually a fix for anything, it's just a change that happened to work with old QEMU, and it's not a change that is in upstream Linux. > Here's a test image to demonstrate the problem: it works fine under qemu > 1.2.0, but doesn't under 1.5.0: > > http://landley.net/aboriginal/bin/system-image-armv5l.tar.bz2 > > Extract it and ./run-emulator.sh. You get a shell prompt from 1.2.0, from > 1.5.0 it never gets a scsi interrupt, and after a timeout goes into an > abort/reset loop. Is this an image with your patch or without it? Does it work if you use the -global option to force legacy IRQ mapping? >> >> This version of the patchset avoids breaking legacy Linux guests >> >> by automatically detecting those broken kernels and switching back >> >> to the old mapping. > > > As testing with the above image confirms: it does not. I tested with several separate variants of the Linux kernel. >> >> This works by looking at the values the kernel >> >> writes to the PCI_INTERRUPT_LINE register in the config space, which >> >> is effectively the interrupt number the kernel expects the device >> >> to be using. If this doesn't match reality we use the broken mapping. >> >> (Thanks to Michael S. Tsirkin for this suggestion.) > > > Define "reality". "would work on real hardware". > The kernel changed what irqs it was expecting _three_times_ last year, and > as far as I can tell none of them were what they were _trying_ to do. > > Here's my blog entry and the source control comments where I diagnosed this > stuff to show that the kernel guys have no flipping CLUE how an arm > versatile board actually works: I agree that the kernel has made a bit of a mess in this area, so we don't need to have that argument again. > The kernel code in this area is CRAP, has changed multiple times in > semi-random ways, has obviously NEVER been tested on real hardware, and if > you've implemented what the actual versatile documentation says it's clearly > not what the kernel is doing. I tested these changes against a patchset which Arnd wrote which I can guarantee was tested on real hardware because I did the testing myself. > Do you have a kernel that runs under current qemu arm versatile emulation? I > can poke around and figure out which irqs it expects _now_, but it's not > "right" and presumably you're just going to change it again when you realize > what qemu is doing and what the unpatched kernel is doing don't match. The ones on http://people.debian.org/~aurel32/qemu/armel/ should work. -- PMM
