[Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.

[Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.

[Rob Landley]

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:

Here's what 2.6.20 does during boot:

> Loading iSCSI transport class v2.0-724.
> PCI: enabling device 0000:00:0c.0 (0140 -> 0143)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 27
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> scsi 0:0:0:0: Direct-Access     QEMU     QEMU HARDDISK    0.9. PQ: 0 ANSI:
> 3 target0:0:0: tagged command queuing enabled, command queue depth 16.
> target0:0:0: Beginning Domain Validation
>  target0:0:0: Domain Validation skipping write tests
>  target0:0:0: Ending Domain Validation
> scsi 0:0:2:0: CD-ROM            QEMU     QEMU CD-ROM      0.9. PQ: 0 ANSI:
> 3 target0:0:2: tagged command queuing enabled, command queue depth 16.
> target0:0:2: Beginning Domain Validation
>  target0:0:2: Domain Validation skipping write tests
>  target0:0:2: Ending Domain Validation
> SCSI device sda: 524288 512-byte hdwr sectors (268 MB)
> sda: Write Protect is off
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA SCSI device sda: 524288 512-byte hdwr sectors (268 MB)
> sda: Write Protect is off
> SCSI device sda: write cache: enabled, read cache: enabled, doesn't support
> DPO or FUA sda: unknown partition table
> sd 0:0:0:0: Attached scsi disk sda
> sr0: scsi3-mmc drive: 16x/50x cd/rw xa/form2 cdda tray
> Uniform CD-ROM driver Revision: 3.20
> mice: PS/2 mouse device common for all mice
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> All bugs added by David S. Miller <davem@redhat.com>
> VFS: Mounted root (ext2 filesystem).
> Freeing init memory: 100K
> sh-2.05b#


And here's what 2.6.21 does:

> Loading iSCSI transport class v2.0-724.
> PCI: enabling device 0000:00:0c.0 (0140 -> 0143)
> sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 0
> sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
> sym0: SCSI BUS has been reset.
> scsi0 : sym-2.2.3
> scsi 0:0:0:0: ABORT operation started.
> scsi 0:0:0:0: ABORT operation timed-out.
> scsi 0:0:0:0: DEVICE RESET operation started.
> scsi 0:0:0:0: DEVICE RESET operation timed-out.
> scsi 0:0:0:0: BUS RESET operation started.
> scsi 0:0:0:0: BUS RESET operation timed-out.
> scsi 0:0:0:0: HOST RESET operation started.
> sym0: SCSI BUS has been reset.
> scsi 0:0:0:0: HOST RESET operation timed-out.
> scsi 0:0:0:0: scsi: Device offlined - not ready after error recovery
> scsi 0:0:1:0: ABORT operation started.
> scsi 0:0:1:0: ABORT operation timed-out.
> scsi 0:0:1:0: DEVICE RESET operation started.
> scsi 0:0:1:0: DEVICE RESET operation timed-out.
> scsi 0:0:1:0: BUS RESET operation started.
> scsi 0:0:1:0: BUS RESET operation timed-out.
> scsi 0:0:1:0: HOST RESET operation started.
> sym0: SCSI BUS has been reset.

[ Skip lots of the same... ]

> scsi 0:0:14:0: HOST RESET operation started.
> sym0: SCSI BUS has been reset.
> scsi 0:0:14:0: HOST RESET operation timed-out.
> scsi 0:0:14:0: scsi: Device offlined - not ready after error recovery
> scsi 0:0:15:0: ABORT operation started.
> scsi 0:0:15:0: ABORT operation timed-out.
> scsi 0:0:15:0: DEVICE RESET operation started.
> scsi 0:0:15:0: DEVICE RESET operation timed-out.
> scsi 0:0:15:0: BUS RESET operation started.
> scsi 0:0:15:0: BUS RESET operation timed-out.
> scsi 0:0:15:0: HOST RESET operation started.
> sym0: SCSI BUS has been reset.
> scsi 0:0:15:0: HOST RESET operation timed-out.
> scsi 0:0:15:0: scsi: Device offlined - not ready after error recovery
> mice: PS/2 mouse device common for all mice
> TCP cubic registered
> NET: Registered protocol family 1
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
> All bugs added by David S. Miller <davem@redhat.com>
> VFS: Cannot open root device "sda" or unknown-block(0,0)
> Please append a correct "root=" boot option; here are the available
> partitions: Kernel panic - not syncing: VFS: Unable to mount root fs on
> unknown-block(0,0) Rebooting in 1 seconds..

I am _totally_ out of my depth trying to debug this.  I continue to poke at 
it, but it was brought to my attention that the list doesn't know about it...

Rob
-- 
The Google cluster became self-aware at 2:14am EDT August 29, 2007...

Re: [Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.

[andrzej zaborowski]

On 07/06/07, Rob Landley <rob@landley.net> 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):
diff --git a/hw/lsi53c895a.c b/hw/lsi53c895a.c
index 19bf2a1..eedbc1d 100644
--- a/hw/lsi53c895a.c
+++ b/hw/lsi53c895a.c
@@ -1845,6 +1845,7 @@ void *lsi_scsi_init(PCIBus *bus, int devfn)
     s->pci_dev.config[0x02] = 0x12;
     s->pci_dev.config[0x03] = 0x00;
     s->pci_dev.config[0x0b] = 0x01;
+    s->pci_dev.config[0x3c] = 0x01; /* ugly workaround */
     s->pci_dev.config[0x3d] = 0x01; /* interrupt pin 1 */

     s->mmio_io_addr = cpu_register_io_memory(0, lsi_mmio_readfn,

Regards

Re: [Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore.

[Rob Landley]

On Tuesday 26 June 2007 10:41:32 andrzej zaborowski wrote:
> On 07/06/07, Rob Landley <rob@landley.net> 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.