From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I3CEa-0005b2-A8 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 10:41:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I3CEZ-0005aO-G7 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 10:41:35 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I3CEZ-0005aI-C6 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 10:41:35 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I3CEY-0004qx-K9 for qemu-devel@nongnu.org; Tue, 26 Jun 2007 10:41:35 -0400 Received: by ug-out-1314.google.com with SMTP id a2so100090ugf for ; Tue, 26 Jun 2007 07:41:33 -0700 (PDT) Message-ID: Date: Tue, 26 Jun 2007 16:41:32 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] Linux 2.6.21 doesn't work with qemu-arm SCSI controller anymore. In-Reply-To: <200706071721.55061.rob@landley.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200706071721.55061.rob@landley.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 07/06/07, Rob Landley 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