On Tuesday 26 June 2007 10:41:32 andrzej zaborowski wrote: > On 07/06/07, Rob Landley <[EMAIL PROTECTED]> wrote: > > In the 2.6.21 kernel the sym53c8xx_2 SCSI controller changed in a way > > that QEMU's virtual SCSI controller doesn't handle this properly: > > I spent some time yesterday trying to find out what was happening and > the results are below. > > QEMU's virtual SCSI controller does handle it properly and the kernel > sym53c8xx_2 driver changes are not at fault. > > The first surprising fact, and one which took me long to figure out, > was that all the SCSI errors are a result of a case of simple > interrupts from the controller not reaching the SCSI driver, hence the > timeouts and whatnot. The sym53c8xx_2 driver gets irq 0 instead of 27, > from the tiwsted PCI irq number assignment logic. This was because the > VersatilePB PCI driver was reading the irq pin number from a wrong > address in the scsi controller's (which is a pci device) config > structure, and the read always returned a 0 which normally means that > the device uses no interrupts (actually all 8-bit accesses were > broken). I corrected the versatile PCI code and sent a patch to linux. > However, the funny part is that this code had not changed since > 2.6.18, so how did it break in 2.6.21? Well, it was broken all the > time, but there was a bug in generic PCI code in > drivers/pci/setup-irq.c, which effectively caused the value read from > the device's supplied config, to be discarded, which got fixed in > 2.6.21. > > If you definitely must use 2.6.21, this qemu workaround also works > (need to do the same for any other PCI device you want to use):
I got the Linux kernel patch from the ARM guys: http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=4454/1 Confirmed it fixed it for me, and pestered the kernel guys in hope this gets into 2.6.22. Thanks, Rob -- "One of my most productive days was throwing away 1000 lines of code." - Ken Thompson.
