* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-11 15:54 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-11 15:54 UTC (permalink / raw) To: linux-arm-kernel; +Cc: linux-kernel, Paul Gortmaker, Russell King Hi, trying to boot arm versatile images with qemu results in the following error if I try to boot with a disk image. sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 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. [...] Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail (I did not check if/how earlier kernels are affected). Tracking this down shows that the problem is known and has been fixed with commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. Would it be possible to submit this patch for inclusion into affected upstream kernels ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-11 15:54 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-11 15:54 UTC (permalink / raw) To: linux-arm-kernel Hi, trying to boot arm versatile images with qemu results in the following error if I try to boot with a disk image. sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 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. [...] Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail (I did not check if/how earlier kernels are affected). Tracking this down shows that the problem is known and has been fixed with commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. Would it be possible to submit this patch for inclusion into affected upstream kernels ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-11 15:54 ` Guenter Roeck @ 2013-08-11 22:04 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-11 22:04 UTC (permalink / raw) To: Guenter Roeck; +Cc: linux-arm-kernel, Paul Gortmaker, linux-kernel On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: > Hi, > > trying to boot arm versatile images with qemu results in the following error > if I try to boot with a disk image. > > sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 > 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. > [...] > > Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail > (I did not check if/how earlier kernels are affected). > > Tracking this down shows that the problem is known and has been fixed with > commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the > Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. > > Would it be possible to submit this patch for inclusion into affected upstream kernels ? It could be that it's qemu's PCI routing is wrong - it's not the first time that qemu has got something wrong. Unfortunately, the PCI routing is totally undocumented, and as I understand it, there's very few backplanes out there now that finding out their real routing is virtually impossible. I'm loathed to change it unless someone can point to a definitive source of information on this. ^ permalink raw reply [flat|nested] 104+ messages in thread
* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-11 22:04 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-11 22:04 UTC (permalink / raw) To: linux-arm-kernel On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: > Hi, > > trying to boot arm versatile images with qemu results in the following error > if I try to boot with a disk image. > > sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 > 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. > [...] > > Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail > (I did not check if/how earlier kernels are affected). > > Tracking this down shows that the problem is known and has been fixed with > commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the > Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. > > Would it be possible to submit this patch for inclusion into affected upstream kernels ? It could be that it's qemu's PCI routing is wrong - it's not the first time that qemu has got something wrong. Unfortunately, the PCI routing is totally undocumented, and as I understand it, there's very few backplanes out there now that finding out their real routing is virtually impossible. I'm loathed to change it unless someone can point to a definitive source of information on this. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-11 22:04 ` Russell King - ARM Linux (?) @ 2013-08-12 0:40 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 0:40 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-arm-kernel, Paul Gortmaker, linux-kernel, qemu-devel On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >> Hi, >> >> trying to boot arm versatile images with qemu results in the following error >> if I try to boot with a disk image. >> >> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >> 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. >> [...] >> >> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >> (I did not check if/how earlier kernels are affected). >> >> Tracking this down shows that the problem is known and has been fixed with >> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >> >> Would it be possible to submit this patch for inclusion into affected upstream kernels ? > > It could be that it's qemu's PCI routing is wrong - it's not the first > time that qemu has got something wrong. > > Unfortunately, the PCI routing is totally undocumented, and as I understand > it, there's very few backplanes out there now that finding out their real > routing is virtually impossible. I'm loathed to change it unless someone > can point to a definitive source of information on this. > Maybe Paul can comment, as he wrote the patch. If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, and qemu 1.5.2 from the qemu repository. Copying qemu-devel to increase the audience. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 0:40 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 0:40 UTC (permalink / raw) To: linux-arm-kernel On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >> Hi, >> >> trying to boot arm versatile images with qemu results in the following error >> if I try to boot with a disk image. >> >> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >> 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. >> [...] >> >> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >> (I did not check if/how earlier kernels are affected). >> >> Tracking this down shows that the problem is known and has been fixed with >> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >> >> Would it be possible to submit this patch for inclusion into affected upstream kernels ? > > It could be that it's qemu's PCI routing is wrong - it's not the first > time that qemu has got something wrong. > > Unfortunately, the PCI routing is totally undocumented, and as I understand > it, there's very few backplanes out there now that finding out their real > routing is virtually impossible. I'm loathed to change it unless someone > can point to a definitive source of information on this. > Maybe Paul can comment, as he wrote the patch. If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, and qemu 1.5.2 from the qemu repository. Copying qemu-devel to increase the audience. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 0:40 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 0:40 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >> Hi, >> >> trying to boot arm versatile images with qemu results in the following error >> if I try to boot with a disk image. >> >> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >> 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. >> [...] >> >> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >> (I did not check if/how earlier kernels are affected). >> >> Tracking this down shows that the problem is known and has been fixed with >> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >> >> Would it be possible to submit this patch for inclusion into affected upstream kernels ? > > It could be that it's qemu's PCI routing is wrong - it's not the first > time that qemu has got something wrong. > > Unfortunately, the PCI routing is totally undocumented, and as I understand > it, there's very few backplanes out there now that finding out their real > routing is virtually impossible. I'm loathed to change it unless someone > can point to a definitive source of information on this. > Maybe Paul can comment, as he wrote the patch. If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, and qemu 1.5.2 from the qemu repository. Copying qemu-devel to increase the audience. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 0:40 ` [Qemu-devel] " Guenter Roeck (?) @ 2013-08-12 16:24 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 16:24 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. QEMU 1.5 has had its Versatile PCI routing code rewritten to correspond with the hardware (cross-tested versus Arnd Bergmann's patchset http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 which was run on real versatilePB backplane hardware and could handle a PCI SATA card). I believe it to be correct, and I spent a fairly long time wading through the various bits of documentation and testing those kernel patches on h/w. (It also includes a back-compatibility fudge so that old kernels which assumed the old broken QEMU behaviour will continue to work; it does not attempt to fix up the problems with kernels from commit 1bc39ac5d to present which don't work properly on either QEMU or real hardware. A fixed kernel can force-disable the fudge.) http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/versatile.c has the current PCI code, which includes comments about what the routing is (in particular tables at lines 321 and 340). >> Unfortunately, the PCI routing is totally undocumented, and as I >> understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. The Versatile boards have TRMs on infocenter.arm.com; the backplane's wiring is documented in the circuit diagrams which were distributed on the CD which came with the board (ie they are non-confidential information, just difficult to lay your hands on). It's also possible to just test the hardware, which is what Arnd and I did to confirm that his patchset was OK. If somebody would like to fix the kernel I am happy to locate the PCI backplane and test everything (again). I would suggest that producing some patches which work with QEMU 1.5 or later would be a good start; then we can test on h/w as confirmation before they are applied. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 16:24 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 16:24 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. QEMU 1.5 has had its Versatile PCI routing code rewritten to correspond with the hardware (cross-tested versus Arnd Bergmann's patchset http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 which was run on real versatilePB backplane hardware and could handle a PCI SATA card). I believe it to be correct, and I spent a fairly long time wading through the various bits of documentation and testing those kernel patches on h/w. (It also includes a back-compatibility fudge so that old kernels which assumed the old broken QEMU behaviour will continue to work; it does not attempt to fix up the problems with kernels from commit 1bc39ac5d to present which don't work properly on either QEMU or real hardware. A fixed kernel can force-disable the fudge.) http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/versatile.c has the current PCI code, which includes comments about what the routing is (in particular tables at lines 321 and 340). >> Unfortunately, the PCI routing is totally undocumented, and as I >> understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. The Versatile boards have TRMs on infocenter.arm.com; the backplane's wiring is documented in the circuit diagrams which were distributed on the CD which came with the board (ie they are non-confidential information, just difficult to lay your hands on). It's also possible to just test the hardware, which is what Arnd and I did to confirm that his patchset was OK. If somebody would like to fix the kernel I am happy to locate the PCI backplane and test everything (again). I would suggest that producing some patches which work with QEMU 1.5 or later would be a good start; then we can test on h/w as confirmation before they are applied. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 16:24 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 16:24 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-kernel, qemu-devel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. QEMU 1.5 has had its Versatile PCI routing code rewritten to correspond with the hardware (cross-tested versus Arnd Bergmann's patchset http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 which was run on real versatilePB backplane hardware and could handle a PCI SATA card). I believe it to be correct, and I spent a fairly long time wading through the various bits of documentation and testing those kernel patches on h/w. (It also includes a back-compatibility fudge so that old kernels which assumed the old broken QEMU behaviour will continue to work; it does not attempt to fix up the problems with kernels from commit 1bc39ac5d to present which don't work properly on either QEMU or real hardware. A fixed kernel can force-disable the fudge.) http://git.qemu.org/?p=qemu.git;a=blob;f=hw/pci-host/versatile.c has the current PCI code, which includes comments about what the routing is (in particular tables at lines 321 and 340). >> Unfortunately, the PCI routing is totally undocumented, and as I >> understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. The Versatile boards have TRMs on infocenter.arm.com; the backplane's wiring is documented in the circuit diagrams which were distributed on the CD which came with the board (ie they are non-confidential information, just difficult to lay your hands on). It's also possible to just test the hardware, which is what Arnd and I did to confirm that his patchset was OK. If somebody would like to fix the kernel I am happy to locate the PCI backplane and test everything (again). I would suggest that producing some patches which work with QEMU 1.5 or later would be a good start; then we can test on h/w as confirmation before they are applied. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 16:24 ` Peter Maydell (?) @ 2013-08-12 16:45 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 16:45 UTC (permalink / raw) To: Peter Maydell Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > >> It could be that it's qemu's PCI routing is wrong - it's not the first > >> time that qemu has got something wrong. > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > correspond with the hardware (cross-tested versus Arnd Bergmann's > patchset > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > which was run on real versatilePB backplane hardware and > could handle a PCI SATA card). I believe it to be correct, > and I spent a fairly long time wading through the various bits > of documentation and testing those kernel patches on h/w. The documentation is totally useless - I've been through it several times and it just doesn't give the necessary information to work out what the routing actually is. The only place that's documented is in the circuits, which are impossible to get hold of (even asking ARM for them doesn't get anywhere: basically, all information has been destroyed.) > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. If someone is willing to send me some definitive information, then the kernel will get fixed. All the time that there is no definitive information, there is no point what so ever changing the kernel. In other words, if you have the circuit diagrams or other documentation which definitively identifies the wiring, then please send it to me. ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 16:45 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 16:45 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > >> It could be that it's qemu's PCI routing is wrong - it's not the first > >> time that qemu has got something wrong. > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > correspond with the hardware (cross-tested versus Arnd Bergmann's > patchset > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > which was run on real versatilePB backplane hardware and > could handle a PCI SATA card). I believe it to be correct, > and I spent a fairly long time wading through the various bits > of documentation and testing those kernel patches on h/w. The documentation is totally useless - I've been through it several times and it just doesn't give the necessary information to work out what the routing actually is. The only place that's documented is in the circuits, which are impossible to get hold of (even asking ARM for them doesn't get anywhere: basically, all information has been destroyed.) > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. If someone is willing to send me some definitive information, then the kernel will get fixed. All the time that there is no definitive information, there is no point what so ever changing the kernel. In other words, if you have the circuit diagrams or other documentation which definitively identifies the wiring, then please send it to me. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 16:45 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 16:45 UTC (permalink / raw) To: Peter Maydell Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > >> It could be that it's qemu's PCI routing is wrong - it's not the first > >> time that qemu has got something wrong. > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > correspond with the hardware (cross-tested versus Arnd Bergmann's > patchset > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > which was run on real versatilePB backplane hardware and > could handle a PCI SATA card). I believe it to be correct, > and I spent a fairly long time wading through the various bits > of documentation and testing those kernel patches on h/w. The documentation is totally useless - I've been through it several times and it just doesn't give the necessary information to work out what the routing actually is. The only place that's documented is in the circuits, which are impossible to get hold of (even asking ARM for them doesn't get anywhere: basically, all information has been destroyed.) > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. If someone is willing to send me some definitive information, then the kernel will get fixed. All the time that there is no definitive information, there is no point what so ever changing the kernel. In other words, if you have the circuit diagrams or other documentation which definitively identifies the wiring, then please send it to me. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 16:45 ` Russell King - ARM Linux (?) @ 2013-08-12 17:33 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:33 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: >> On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> >> time that qemu has got something wrong. >> >> QEMU 1.5 has had its Versatile PCI routing code rewritten to >> correspond with the hardware (cross-tested versus Arnd Bergmann's >> patchset >> http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 >> which was run on real versatilePB backplane hardware and >> could handle a PCI SATA card). I believe it to be correct, >> and I spent a fairly long time wading through the various bits >> of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several times > and it just doesn't give the necessary information to work out what the > routing actually is. I agree that the TRMs are rather unhelpful. > The only place that's documented is in the circuits, > which are impossible to get hold of (even asking ARM for them doesn't get > anywhere: basically, all information has been destroyed.) The circuit diagrams are definitely not lost or destroyed; the PDF is on my monitor as I type (and as I say I checked against it when I was doing the QEMU patches and helping Arnd test his patches. > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I may have been misremembering their confidential/non-confidential status; I will check. In the meantime, Figure D2 in HBI-0140: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Babddfca.html#BABHICAG has labels which give an interrupt wiring of the backplane which matches the schematics I have (though the wires that have been drawn between them are obviously wrong). To interpret the diagram you have to know that the four points on each slot that the PCI_nINT* signals there attach to the slot correspond to the usual arrangement of the INT pins on a PCI slot: http://en.wikipedia.org/wiki/Conventional_PCI#Connector_pinout ie the left side ones are B7 and B8, the right ones A6 and A7. The board connects to slot C, which is enough to validate the table I give in the QEMU code for the EB/1176: /* Slot to IRQ mapping for RealView EB and PB1176 backplane * name slot IntA IntB IntC IntD * A 31 IRQ50 IRQ51 IRQ48 IRQ49 * B 30 IRQ49 IRQ50 IRQ51 IRQ48 * C 29 IRQ48 IRQ49 IRQ50 IRQ51 * Slot C is for the host bridge; A and B the peripherals. * Our output irqs 0..3 correspond to the baseboard's 48..51. */ ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). and so on round. The 926's routing is one extra round of swizzling because the board itself connects FPGA P_nINTA to its edge connector's INTB (B7) pin rather than INTA (A6) as the EB/1176 do. (This isn't even hinted at in the documentation, you need to either experiment or look at the 926 board schematic.) This is validated by the fact that if you make the kernel assume the swizzling is like this then it can successfully drive PCI cards on hardware, whereas if you don't then it won't. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 17:33 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:33 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: >> On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> >> time that qemu has got something wrong. >> >> QEMU 1.5 has had its Versatile PCI routing code rewritten to >> correspond with the hardware (cross-tested versus Arnd Bergmann's >> patchset >> http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 >> which was run on real versatilePB backplane hardware and >> could handle a PCI SATA card). I believe it to be correct, >> and I spent a fairly long time wading through the various bits >> of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several times > and it just doesn't give the necessary information to work out what the > routing actually is. I agree that the TRMs are rather unhelpful. > The only place that's documented is in the circuits, > which are impossible to get hold of (even asking ARM for them doesn't get > anywhere: basically, all information has been destroyed.) The circuit diagrams are definitely not lost or destroyed; the PDF is on my monitor as I type (and as I say I checked against it when I was doing the QEMU patches and helping Arnd test his patches. > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I may have been misremembering their confidential/non-confidential status; I will check. In the meantime, Figure D2 in HBI-0140: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Babddfca.html#BABHICAG has labels which give an interrupt wiring of the backplane which matches the schematics I have (though the wires that have been drawn between them are obviously wrong). To interpret the diagram you have to know that the four points on each slot that the PCI_nINT* signals there attach to the slot correspond to the usual arrangement of the INT pins on a PCI slot: http://en.wikipedia.org/wiki/Conventional_PCI#Connector_pinout ie the left side ones are B7 and B8, the right ones A6 and A7. The board connects to slot C, which is enough to validate the table I give in the QEMU code for the EB/1176: /* Slot to IRQ mapping for RealView EB and PB1176 backplane * name slot IntA IntB IntC IntD * A 31 IRQ50 IRQ51 IRQ48 IRQ49 * B 30 IRQ49 IRQ50 IRQ51 IRQ48 * C 29 IRQ48 IRQ49 IRQ50 IRQ51 * Slot C is for the host bridge; A and B the peripherals. * Our output irqs 0..3 correspond to the baseboard's 48..51. */ ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). and so on round. The 926's routing is one extra round of swizzling because the board itself connects FPGA P_nINTA to its edge connector's INTB (B7) pin rather than INTA (A6) as the EB/1176 do. (This isn't even hinted at in the documentation, you need to either experiment or look at the 926 board schematic.) This is validated by the fact that if you make the kernel assume the swizzling is like this then it can successfully drive PCI cards on hardware, whereas if you don't then it won't. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 17:33 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:33 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: >> On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> >> time that qemu has got something wrong. >> >> QEMU 1.5 has had its Versatile PCI routing code rewritten to >> correspond with the hardware (cross-tested versus Arnd Bergmann's >> patchset >> http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 >> which was run on real versatilePB backplane hardware and >> could handle a PCI SATA card). I believe it to be correct, >> and I spent a fairly long time wading through the various bits >> of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several times > and it just doesn't give the necessary information to work out what the > routing actually is. I agree that the TRMs are rather unhelpful. > The only place that's documented is in the circuits, > which are impossible to get hold of (even asking ARM for them doesn't get > anywhere: basically, all information has been destroyed.) The circuit diagrams are definitely not lost or destroyed; the PDF is on my monitor as I type (and as I say I checked against it when I was doing the QEMU patches and helping Arnd test his patches. > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I may have been misremembering their confidential/non-confidential status; I will check. In the meantime, Figure D2 in HBI-0140: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Babddfca.html#BABHICAG has labels which give an interrupt wiring of the backplane which matches the schematics I have (though the wires that have been drawn between them are obviously wrong). To interpret the diagram you have to know that the four points on each slot that the PCI_nINT* signals there attach to the slot correspond to the usual arrangement of the INT pins on a PCI slot: http://en.wikipedia.org/wiki/Conventional_PCI#Connector_pinout ie the left side ones are B7 and B8, the right ones A6 and A7. The board connects to slot C, which is enough to validate the table I give in the QEMU code for the EB/1176: /* Slot to IRQ mapping for RealView EB and PB1176 backplane * name slot IntA IntB IntC IntD * A 31 IRQ50 IRQ51 IRQ48 IRQ49 * B 30 IRQ49 IRQ50 IRQ51 IRQ48 * C 29 IRQ48 IRQ49 IRQ50 IRQ51 * Slot C is for the host bridge; A and B the peripherals. * Our output irqs 0..3 correspond to the baseboard's 48..51. */ ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). and so on round. The 926's routing is one extra round of swizzling because the board itself connects FPGA P_nINTA to its edge connector's INTB (B7) pin rather than INTA (A6) as the EB/1176 do. (This isn't even hinted at in the documentation, you need to either experiment or look at the 926 board schematic.) This is validated by the fact that if you make the kernel assume the swizzling is like this then it can successfully drive PCI cards on hardware, whereas if you don't then it won't. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 17:33 ` Peter Maydell (?) @ 2013-08-12 20:06 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 20:06 UTC (permalink / raw) To: Peter Maydell Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > /* Slot to IRQ mapping for RealView EB and PB1176 backplane > * name slot IntA IntB IntC IntD > * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > * Slot C is for the host bridge; A and B the peripherals. > * Our output irqs 0..3 correspond to the baseboard's 48..51. > */ > > ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > > and so on round. > > The 926's routing is one extra round of swizzling because the > board itself connects FPGA P_nINTA to its edge connector's > INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > (This isn't even hinted at in the documentation, you need to > either experiment or look at the 926 board schematic.) Okay, so the above just adds to the confusion, because you appear to be mistaking "slot" for the AD signal which the IDSEL pin is connected to. As I'm seeing a report of a card appearing in slot 0x0d at the top of this thread, this doesn't match your numbering above. So, is slot 0x0d slot A or slot B? If we assume that slot A is indeed has IDSEL connected to AD31, then that surely makes it slot 20 (AD11 + 20 = 31) and slot B = 19. So why do we apparantly have a card in a non-existent slot at 13? Now, it looks to me like we have the rotation in the right direction, it's just a matter of ensuring that we have the right starting point. That's where we need to know what slot number Linux believes slot A and slot B actually are. ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:06 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 20:06 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > /* Slot to IRQ mapping for RealView EB and PB1176 backplane > * name slot IntA IntB IntC IntD > * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > * Slot C is for the host bridge; A and B the peripherals. > * Our output irqs 0..3 correspond to the baseboard's 48..51. > */ > > ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > > and so on round. > > The 926's routing is one extra round of swizzling because the > board itself connects FPGA P_nINTA to its edge connector's > INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > (This isn't even hinted at in the documentation, you need to > either experiment or look at the 926 board schematic.) Okay, so the above just adds to the confusion, because you appear to be mistaking "slot" for the AD signal which the IDSEL pin is connected to. As I'm seeing a report of a card appearing in slot 0x0d at the top of this thread, this doesn't match your numbering above. So, is slot 0x0d slot A or slot B? If we assume that slot A is indeed has IDSEL connected to AD31, then that surely makes it slot 20 (AD11 + 20 = 31) and slot B = 19. So why do we apparantly have a card in a non-existent slot at 13? Now, it looks to me like we have the rotation in the right direction, it's just a matter of ensuring that we have the right starting point. That's where we need to know what slot number Linux believes slot A and slot B actually are. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:06 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 20:06 UTC (permalink / raw) To: Peter Maydell Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > /* Slot to IRQ mapping for RealView EB and PB1176 backplane > * name slot IntA IntB IntC IntD > * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > * Slot C is for the host bridge; A and B the peripherals. > * Our output irqs 0..3 correspond to the baseboard's 48..51. > */ > > ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > > and so on round. > > The 926's routing is one extra round of swizzling because the > board itself connects FPGA P_nINTA to its edge connector's > INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > (This isn't even hinted at in the documentation, you need to > either experiment or look at the 926 board schematic.) Okay, so the above just adds to the confusion, because you appear to be mistaking "slot" for the AD signal which the IDSEL pin is connected to. As I'm seeing a report of a card appearing in slot 0x0d at the top of this thread, this doesn't match your numbering above. So, is slot 0x0d slot A or slot B? If we assume that slot A is indeed has IDSEL connected to AD31, then that surely makes it slot 20 (AD11 + 20 = 31) and slot B = 19. So why do we apparantly have a card in a non-existent slot at 13? Now, it looks to me like we have the rotation in the right direction, it's just a matter of ensuring that we have the right starting point. That's where we need to know what slot number Linux believes slot A and slot B actually are. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 20:06 ` Russell King - ARM Linux (?) @ 2013-08-12 20:49 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:49 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 12 August 2013 21:06, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> * name slot IntA IntB IntC IntD >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> * Slot C is for the host bridge; A and B the peripherals. >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> */ >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> and so on round. >> >> The 926's routing is one extra round of swizzling because the >> board itself connects FPGA P_nINTA to its edge connector's >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> (This isn't even hinted at in the documentation, you need to >> either experiment or look at the 926 board schematic.) > > Okay, so the above just adds to the confusion, because you appear to be > mistaking "slot" for the AD signal which the IDSEL pin is connected to. The board TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html says that "slot position" and "AD signal connected to IDSEL" are the same thing: "The slot positions for PCI cards are numbered from 11 to 31. The numbering is based on the address bit that is connected to the IDSEL line." > As I'm seeing a report of a card appearing in slot 0x0d at the top of > this thread, this doesn't match your numbering above. So, is slot > 0x0d slot A or slot B? Slot 0xd is where the second PCI card QEMU emulates appears. It doesn't correspond to either A or B in real hardware. That trace output is the result of running the kernel on QEMU. On QEMU we put the host at slot 11 (lowest possible) and then cards at 12, 13, ... because generally people want to be able to plug in more than two cards. It also improves our backward-compatiliity with old kernels which assume old broken QEMU behaviour. This is kind of like modelling a rather extended (but admittedly fictitious) backplane. On real hardware the physical "slot A" and "slot B" on the backplane are 'slot' 31 and 30, and the host appears at 29. I don't currently have the h/w set up, but digging in my email archives, when we were running the kernel on the real PB926 h/w and backplane it was indeed reporting the PCI core (ie "slot C") as 29, and the other two as 30 and 31: [ 128.920150] PCI core found (slot 29) [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] (that's from two years ago, a 2.6.35.6+ kernel with Arnd's patchset applied, detecting a SATA card in slot 31). -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:49 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:49 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 21:06, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> * name slot IntA IntB IntC IntD >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> * Slot C is for the host bridge; A and B the peripherals. >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> */ >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> and so on round. >> >> The 926's routing is one extra round of swizzling because the >> board itself connects FPGA P_nINTA to its edge connector's >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> (This isn't even hinted at in the documentation, you need to >> either experiment or look at the 926 board schematic.) > > Okay, so the above just adds to the confusion, because you appear to be > mistaking "slot" for the AD signal which the IDSEL pin is connected to. The board TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html says that "slot position" and "AD signal connected to IDSEL" are the same thing: "The slot positions for PCI cards are numbered from 11 to 31. The numbering is based on the address bit that is connected to the IDSEL line." > As I'm seeing a report of a card appearing in slot 0x0d at the top of > this thread, this doesn't match your numbering above. So, is slot > 0x0d slot A or slot B? Slot 0xd is where the second PCI card QEMU emulates appears. It doesn't correspond to either A or B in real hardware. That trace output is the result of running the kernel on QEMU. On QEMU we put the host at slot 11 (lowest possible) and then cards at 12, 13, ... because generally people want to be able to plug in more than two cards. It also improves our backward-compatiliity with old kernels which assume old broken QEMU behaviour. This is kind of like modelling a rather extended (but admittedly fictitious) backplane. On real hardware the physical "slot A" and "slot B" on the backplane are 'slot' 31 and 30, and the host appears at 29. I don't currently have the h/w set up, but digging in my email archives, when we were running the kernel on the real PB926 h/w and backplane it was indeed reporting the PCI core (ie "slot C") as 29, and the other two as 30 and 31: [ 128.920150] PCI core found (slot 29) [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] (that's from two years ago, a 2.6.35.6+ kernel with Arnd's patchset applied, detecting a SATA card in slot 31). -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:49 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:49 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 12 August 2013 21:06, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> * name slot IntA IntB IntC IntD >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> * Slot C is for the host bridge; A and B the peripherals. >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> */ >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> and so on round. >> >> The 926's routing is one extra round of swizzling because the >> board itself connects FPGA P_nINTA to its edge connector's >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> (This isn't even hinted at in the documentation, you need to >> either experiment or look at the 926 board schematic.) > > Okay, so the above just adds to the confusion, because you appear to be > mistaking "slot" for the AD signal which the IDSEL pin is connected to. The board TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html says that "slot position" and "AD signal connected to IDSEL" are the same thing: "The slot positions for PCI cards are numbered from 11 to 31. The numbering is based on the address bit that is connected to the IDSEL line." > As I'm seeing a report of a card appearing in slot 0x0d at the top of > this thread, this doesn't match your numbering above. So, is slot > 0x0d slot A or slot B? Slot 0xd is where the second PCI card QEMU emulates appears. It doesn't correspond to either A or B in real hardware. That trace output is the result of running the kernel on QEMU. On QEMU we put the host at slot 11 (lowest possible) and then cards at 12, 13, ... because generally people want to be able to plug in more than two cards. It also improves our backward-compatiliity with old kernels which assume old broken QEMU behaviour. This is kind of like modelling a rather extended (but admittedly fictitious) backplane. On real hardware the physical "slot A" and "slot B" on the backplane are 'slot' 31 and 30, and the host appears at 29. I don't currently have the h/w set up, but digging in my email archives, when we were running the kernel on the real PB926 h/w and backplane it was indeed reporting the PCI core (ie "slot C") as 29, and the other two as 30 and 31: [ 128.920150] PCI core found (slot 29) [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] (that's from two years ago, a 2.6.35.6+ kernel with Arnd's patchset applied, detecting a SATA card in slot 31). -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 20:49 ` Peter Maydell (?) @ 2013-08-12 21:21 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 21:21 UTC (permalink / raw) To: Peter Maydell Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: > On 12 August 2013 21:06, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane > >> * name slot IntA IntB IntC IntD > >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > >> * Slot C is for the host bridge; A and B the peripherals. > >> * Our output irqs 0..3 correspond to the baseboard's 48..51. > >> */ > >> > >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > >> > >> and so on round. > >> > >> The 926's routing is one extra round of swizzling because the > >> board itself connects FPGA P_nINTA to its edge connector's > >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > >> (This isn't even hinted at in the documentation, you need to > >> either experiment or look at the 926 board schematic.) > > > > Okay, so the above just adds to the confusion, because you appear to be > > mistaking "slot" for the AD signal which the IDSEL pin is connected to. > > The board TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html > says that "slot position" and "AD signal connected to IDSEL" > are the same thing: That's realview, not versatile. Are you saying that both are exactly the same wrt this? > I don't currently have the h/w set up, but digging in my email > archives, when we were running the kernel on the real PB926 > h/w and backplane it was indeed reporting the PCI core (ie > "slot C") as 29, and the other two as 30 and 31: > [ 128.920150] PCI core found (slot 29) > [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] > [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] > [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] > [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] > [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] > [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] > [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] With realview or versatile? ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 21:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 21:21 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: > On 12 August 2013 21:06, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane > >> * name slot IntA IntB IntC IntD > >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > >> * Slot C is for the host bridge; A and B the peripherals. > >> * Our output irqs 0..3 correspond to the baseboard's 48..51. > >> */ > >> > >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > >> > >> and so on round. > >> > >> The 926's routing is one extra round of swizzling because the > >> board itself connects FPGA P_nINTA to its edge connector's > >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > >> (This isn't even hinted at in the documentation, you need to > >> either experiment or look at the 926 board schematic.) > > > > Okay, so the above just adds to the confusion, because you appear to be > > mistaking "slot" for the AD signal which the IDSEL pin is connected to. > > The board TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html > says that "slot position" and "AD signal connected to IDSEL" > are the same thing: That's realview, not versatile. Are you saying that both are exactly the same wrt this? > I don't currently have the h/w set up, but digging in my email > archives, when we were running the kernel on the real PB926 > h/w and backplane it was indeed reporting the PCI core (ie > "slot C") as 29, and the other two as 30 and 31: > [ 128.920150] PCI core found (slot 29) > [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] > [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] > [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] > [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] > [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] > [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] > [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] With realview or versatile? ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 21:21 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 21:21 UTC (permalink / raw) To: Peter Maydell Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: > On 12 August 2013 21:06, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: > >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane > >> * name slot IntA IntB IntC IntD > >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 > >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 > >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 > >> * Slot C is for the host bridge; A and B the peripherals. > >> * Our output irqs 0..3 correspond to the baseboard's 48..51. > >> */ > >> > >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB > >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). > >> > >> and so on round. > >> > >> The 926's routing is one extra round of swizzling because the > >> board itself connects FPGA P_nINTA to its edge connector's > >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. > >> (This isn't even hinted at in the documentation, you need to > >> either experiment or look at the 926 board schematic.) > > > > Okay, so the above just adds to the confusion, because you appear to be > > mistaking "slot" for the AD signal which the IDSEL pin is connected to. > > The board TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html > says that "slot position" and "AD signal connected to IDSEL" > are the same thing: That's realview, not versatile. Are you saying that both are exactly the same wrt this? > I don't currently have the h/w set up, but digging in my email > archives, when we were running the kernel on the real PB926 > h/w and backplane it was indeed reporting the PCI core (ie > "slot C") as 29, and the other two as 30 and 31: > [ 128.920150] PCI core found (slot 29) > [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] > [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] > [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] > [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] > [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] > [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] > [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] With realview or versatile? ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 21:21 ` Russell King - ARM Linux (?) @ 2013-08-12 21:36 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 21:36 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 12 August 2013 22:21, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: >> On 12 August 2013 21:06, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> >> * name slot IntA IntB IntC IntD >> >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> >> * Slot C is for the host bridge; A and B the peripherals. >> >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> >> */ >> >> >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> >> >> and so on round. >> >> >> >> The 926's routing is one extra round of swizzling because the >> >> board itself connects FPGA P_nINTA to its edge connector's >> >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> >> (This isn't even hinted at in the documentation, you need to >> >> either experiment or look at the 926 board schematic.) >> > >> > Okay, so the above just adds to the confusion, because you appear to be >> > mistaking "slot" for the AD signal which the IDSEL pin is connected to. >> >> The board TRM: >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html >> says that "slot position" and "AD signal connected to IDSEL" >> are the same thing: > > That's realview, not versatile. Are you saying that both are exactly > the same wrt this? On this point, yes. Equivalent bit from the PB926 TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html (There are differences between the PCI controllers on the different boards. Differences I know of are: * size of the three memory mapped regions * whether the top bits of the PCI address come from the top or bottom of the IMAP* registers I believe (based on some experimentation and an educated guess) that these both changed at the same point, but some of the board TRMs claim to be part one way part the other, presumably due to copy and paste error. In particular PB1176's TRM has a mangled description of the IMAP* registers which didn't match what the h/w actually did in my testing.) >> I don't currently have the h/w set up, but digging in my email >> archives, when we were running the kernel on the real PB926 >> h/w and backplane it was indeed reporting the PCI core (ie >> "slot C") as 29, and the other two as 30 and 31: >> [ 128.920150] PCI core found (slot 29) >> [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] >> [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] >> [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] >> [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] >> [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] >> [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] >> [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] > > With realview or versatile? Versatile (PB926). This one's Realview (PB1176), card in slot B: [ 35.619169] PCI core found (slot 29) [ 35.620294] PCI: bus0: Fast back to back transfers enabled [ 35.621041] PCI new map irq: slot 30, pin 1, devslot 30, irq: 76 [ 35.621173] pci 0000:00:1e.0: BAR 6: assigned [mem 0x68000000-0x6800ffff pref] [ 35.621251] pci 0000:00:1e.0: BAR 5: assigned [io 0x1000-0x10ff] [ 35.621329] pci 0000:00:1e.0: BAR 5: set to [io 0x1000-0x10ff] (PCI address [0x1000-0x10ff] [ 35.621406] pci 0000:00:1e.0: BAR 4: assigned [io 0x1400-0x141f] [ 35.621479] pci 0000:00:1e.0: BAR 4: set to [io 0x1400-0x141f] (PCI address [0x1400-0x141f] [ 35.621556] pci 0000:00:1e.0: BAR 0: assigned [io 0x1420-0x142f] [ 35.621628] pci 0000:00:1e.0: BAR 0: set to [io 0x1420-0x142f] (PCI address [0x1420-0x142f] [ 35.621706] pci 0000:00:1e.0: BAR 1: assigned [io 0x1430-0x143f] [ 35.621779] pci 0000:00:1e.0: BAR 1: set to [io 0x1430-0x143f] (PCI address [0x1430-0x143f] [ 35.621856] pci 0000:00:1e.0: BAR 2: assigned [io 0x1440-0x144f] [ 35.621929] pci 0000:00:1e.0: BAR 2: set to [io 0x1440-0x144f] (PCI address [0x1440-0x144f] [ 35.622007] pci 0000:00:1e.0: BAR 3: assigned [io 0x1450-0x145f] [ 35.622079] pci 0000:00:1e.0: BAR 3: set to [io 0x1450-0x145f] (PCI address [0x1450-0x145f] [nb that this is from trace from a buggy kernel, the irq is wrong and the card doesn't work.] -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 21:36 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 21:36 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 22:21, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: >> On 12 August 2013 21:06, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> >> * name slot IntA IntB IntC IntD >> >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> >> * Slot C is for the host bridge; A and B the peripherals. >> >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> >> */ >> >> >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> >> >> and so on round. >> >> >> >> The 926's routing is one extra round of swizzling because the >> >> board itself connects FPGA P_nINTA to its edge connector's >> >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> >> (This isn't even hinted at in the documentation, you need to >> >> either experiment or look at the 926 board schematic.) >> > >> > Okay, so the above just adds to the confusion, because you appear to be >> > mistaking "slot" for the AD signal which the IDSEL pin is connected to. >> >> The board TRM: >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html >> says that "slot position" and "AD signal connected to IDSEL" >> are the same thing: > > That's realview, not versatile. Are you saying that both are exactly > the same wrt this? On this point, yes. Equivalent bit from the PB926 TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html (There are differences between the PCI controllers on the different boards. Differences I know of are: * size of the three memory mapped regions * whether the top bits of the PCI address come from the top or bottom of the IMAP* registers I believe (based on some experimentation and an educated guess) that these both changed at the same point, but some of the board TRMs claim to be part one way part the other, presumably due to copy and paste error. In particular PB1176's TRM has a mangled description of the IMAP* registers which didn't match what the h/w actually did in my testing.) >> I don't currently have the h/w set up, but digging in my email >> archives, when we were running the kernel on the real PB926 >> h/w and backplane it was indeed reporting the PCI core (ie >> "slot C") as 29, and the other two as 30 and 31: >> [ 128.920150] PCI core found (slot 29) >> [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] >> [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] >> [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] >> [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] >> [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] >> [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] >> [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] > > With realview or versatile? Versatile (PB926). This one's Realview (PB1176), card in slot B: [ 35.619169] PCI core found (slot 29) [ 35.620294] PCI: bus0: Fast back to back transfers enabled [ 35.621041] PCI new map irq: slot 30, pin 1, devslot 30, irq: 76 [ 35.621173] pci 0000:00:1e.0: BAR 6: assigned [mem 0x68000000-0x6800ffff pref] [ 35.621251] pci 0000:00:1e.0: BAR 5: assigned [io 0x1000-0x10ff] [ 35.621329] pci 0000:00:1e.0: BAR 5: set to [io 0x1000-0x10ff] (PCI address [0x1000-0x10ff] [ 35.621406] pci 0000:00:1e.0: BAR 4: assigned [io 0x1400-0x141f] [ 35.621479] pci 0000:00:1e.0: BAR 4: set to [io 0x1400-0x141f] (PCI address [0x1400-0x141f] [ 35.621556] pci 0000:00:1e.0: BAR 0: assigned [io 0x1420-0x142f] [ 35.621628] pci 0000:00:1e.0: BAR 0: set to [io 0x1420-0x142f] (PCI address [0x1420-0x142f] [ 35.621706] pci 0000:00:1e.0: BAR 1: assigned [io 0x1430-0x143f] [ 35.621779] pci 0000:00:1e.0: BAR 1: set to [io 0x1430-0x143f] (PCI address [0x1430-0x143f] [ 35.621856] pci 0000:00:1e.0: BAR 2: assigned [io 0x1440-0x144f] [ 35.621929] pci 0000:00:1e.0: BAR 2: set to [io 0x1440-0x144f] (PCI address [0x1440-0x144f] [ 35.622007] pci 0000:00:1e.0: BAR 3: assigned [io 0x1450-0x145f] [ 35.622079] pci 0000:00:1e.0: BAR 3: set to [io 0x1450-0x145f] (PCI address [0x1450-0x145f] [nb that this is from trace from a buggy kernel, the irq is wrong and the card doesn't work.] -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 21:36 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 21:36 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 12 August 2013 22:21, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 09:49:54PM +0100, Peter Maydell wrote: >> On 12 August 2013 21:06, Russell King - ARM Linux >> <linux@arm.linux.org.uk> wrote: >> > On Mon, Aug 12, 2013 at 06:33:28PM +0100, Peter Maydell wrote: >> >> /* Slot to IRQ mapping for RealView EB and PB1176 backplane >> >> * name slot IntA IntB IntC IntD >> >> * A 31 IRQ50 IRQ51 IRQ48 IRQ49 >> >> * B 30 IRQ49 IRQ50 IRQ51 IRQ48 >> >> * C 29 IRQ48 IRQ49 IRQ50 IRQ51 >> >> * Slot C is for the host bridge; A and B the peripherals. >> >> * Our output irqs 0..3 correspond to the baseboard's 48..51. >> >> */ >> >> >> >> ie IRQ48 == board's PCI0 == slot C connector A6 (IntA) == PCI_nINTB >> >> == Slot B connector B8 (IntD) == Slot A connector A7 (IntC). >> >> >> >> and so on round. >> >> >> >> The 926's routing is one extra round of swizzling because the >> >> board itself connects FPGA P_nINTA to its edge connector's >> >> INTB (B7) pin rather than INTA (A6) as the EB/1176 do. >> >> (This isn't even hinted at in the documentation, you need to >> >> either experiment or look at the 926 board schematic.) >> > >> > Okay, so the above just adds to the confusion, because you appear to be >> > mistaking "slot" for the AD signal which the IDSEL pin is connected to. >> >> The board TRM: >> http://infocenter.arm.com/help/topic/com.arm.doc.dui0411d/Cacdijji.html >> says that "slot position" and "AD signal connected to IDSEL" >> are the same thing: > > That's realview, not versatile. Are you saying that both are exactly > the same wrt this? On this point, yes. Equivalent bit from the PB926 TRM: http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html (There are differences between the PCI controllers on the different boards. Differences I know of are: * size of the three memory mapped regions * whether the top bits of the PCI address come from the top or bottom of the IMAP* registers I believe (based on some experimentation and an educated guess) that these both changed at the same point, but some of the board TRMs claim to be part one way part the other, presumably due to copy and paste error. In particular PB1176's TRM has a mangled description of the IMAP* registers which didn't match what the h/w actually did in my testing.) >> I don't currently have the h/w set up, but digging in my email >> archives, when we were running the kernel on the real PB926 >> h/w and backplane it was indeed reporting the PCI core (ie >> "slot C") as 29, and the other two as 30 and 31: >> [ 128.920150] PCI core found (slot 29) >> [ 128.920875] pci 0000:00:1f.0: reg 10: [io 0x0af0-0x0aff] >> [ 128.920958] pci 0000:00:1f.0: reg 14: [io 0x0a70-0x0a7f] >> [ 128.921032] pci 0000:00:1f.0: reg 18: [io 0x01f0-0x01ff] >> [ 128.921103] pci 0000:00:1f.0: reg 1c: [io 0x0170-0x017f] >> [ 128.921173] pci 0000:00:1f.0: reg 20: [io 0xcc00-0xcc1f] >> [ 128.921244] pci 0000:00:1f.0: reg 24: [io 0x8c00-0x8cff] >> [ 128.921320] pci 0000:00:1f.0: reg 30: [mem 0xffff0000-0xffffffff pref] > > With realview or versatile? Versatile (PB926). This one's Realview (PB1176), card in slot B: [ 35.619169] PCI core found (slot 29) [ 35.620294] PCI: bus0: Fast back to back transfers enabled [ 35.621041] PCI new map irq: slot 30, pin 1, devslot 30, irq: 76 [ 35.621173] pci 0000:00:1e.0: BAR 6: assigned [mem 0x68000000-0x6800ffff pref] [ 35.621251] pci 0000:00:1e.0: BAR 5: assigned [io 0x1000-0x10ff] [ 35.621329] pci 0000:00:1e.0: BAR 5: set to [io 0x1000-0x10ff] (PCI address [0x1000-0x10ff] [ 35.621406] pci 0000:00:1e.0: BAR 4: assigned [io 0x1400-0x141f] [ 35.621479] pci 0000:00:1e.0: BAR 4: set to [io 0x1400-0x141f] (PCI address [0x1400-0x141f] [ 35.621556] pci 0000:00:1e.0: BAR 0: assigned [io 0x1420-0x142f] [ 35.621628] pci 0000:00:1e.0: BAR 0: set to [io 0x1420-0x142f] (PCI address [0x1420-0x142f] [ 35.621706] pci 0000:00:1e.0: BAR 1: assigned [io 0x1430-0x143f] [ 35.621779] pci 0000:00:1e.0: BAR 1: set to [io 0x1430-0x143f] (PCI address [0x1430-0x143f] [ 35.621856] pci 0000:00:1e.0: BAR 2: assigned [io 0x1440-0x144f] [ 35.621929] pci 0000:00:1e.0: BAR 2: set to [io 0x1440-0x144f] (PCI address [0x1440-0x144f] [ 35.622007] pci 0000:00:1e.0: BAR 3: assigned [io 0x1450-0x145f] [ 35.622079] pci 0000:00:1e.0: BAR 3: set to [io 0x1450-0x145f] (PCI address [0x1450-0x145f] [nb that this is from trace from a buggy kernel, the irq is wrong and the card doesn't work.] -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 21:36 ` Peter Maydell (?) @ 2013-08-12 22:12 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 22:12 UTC (permalink / raw) To: Peter Maydell Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > On this point, yes. Equivalent bit from the PB926 TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > (There are differences between the PCI controllers on > the different boards. Differences I know of are: > * size of the three memory mapped regions > * whether the top bits of the PCI address come from the top > or bottom of the IMAP* registers > I believe (based on some experimentation and an educated guess) > that these both changed at the same point, but some of the board > TRMs claim to be part one way part the other, presumably due to > copy and paste error. In particular PB1176's TRM has a mangled > description of the IMAP* registers which didn't match what the > h/w actually did in my testing.) Bah, updated TRMs since my version. Right, so if I've traced everything correctly, this should work: /* * Slot INTA INTB INTC INTD * 31 PCI1 PCI2 PCI3 PCI0 * 30 PCI0 PCI1 PCI2 PCI3 * 29 PCI3 PCI0 PCI1 PCI2 */ return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 22:12 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 22:12 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > On this point, yes. Equivalent bit from the PB926 TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > (There are differences between the PCI controllers on > the different boards. Differences I know of are: > * size of the three memory mapped regions > * whether the top bits of the PCI address come from the top > or bottom of the IMAP* registers > I believe (based on some experimentation and an educated guess) > that these both changed at the same point, but some of the board > TRMs claim to be part one way part the other, presumably due to > copy and paste error. In particular PB1176's TRM has a mangled > description of the IMAP* registers which didn't match what the > h/w actually did in my testing.) Bah, updated TRMs since my version. Right, so if I've traced everything correctly, this should work: /* * Slot INTA INTB INTC INTD * 31 PCI1 PCI2 PCI3 PCI0 * 30 PCI0 PCI1 PCI2 PCI3 * 29 PCI3 PCI0 PCI1 PCI2 */ return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 22:12 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-12 22:12 UTC (permalink / raw) To: Peter Maydell Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > On this point, yes. Equivalent bit from the PB926 TRM: > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > (There are differences between the PCI controllers on > the different boards. Differences I know of are: > * size of the three memory mapped regions > * whether the top bits of the PCI address come from the top > or bottom of the IMAP* registers > I believe (based on some experimentation and an educated guess) > that these both changed at the same point, but some of the board > TRMs claim to be part one way part the other, presumably due to > copy and paste error. In particular PB1176's TRM has a mangled > description of the IMAP* registers which didn't match what the > h/w actually did in my testing.) Bah, updated TRMs since my version. Right, so if I've traced everything correctly, this should work: /* * Slot INTA INTB INTC INTD * 31 PCI1 PCI2 PCI3 PCI0 * 30 PCI0 PCI1 PCI2 PCI3 * 29 PCI3 PCI0 PCI1 PCI2 */ return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 22:12 ` Russell King - ARM Linux (?) @ 2013-08-12 22:48 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 22:48 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > Assuming this is what you mean, I added the above code to versatile_map_irq(). It does not work, unfortunately, at least not in qemu 1.4.0. This is what the kernel reports for interrupt numbers: kernel irq result -------------------------------------- 3.10.6: 92 fails 3.10.6+above change: 94 fails 3.10.6+Paul's patch: 91 works Now is this a qemu problem or a kernel problem ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 22:48 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 22:48 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > Assuming this is what you mean, I added the above code to versatile_map_irq(). It does not work, unfortunately, at least not in qemu 1.4.0. This is what the kernel reports for interrupt numbers: kernel irq result -------------------------------------- 3.10.6: 92 fails 3.10.6+above change: 94 fails 3.10.6+Paul's patch: 91 works Now is this a qemu problem or a kernel problem ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 22:48 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 22:48 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, qemu-devel, linux-kernel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > Assuming this is what you mean, I added the above code to versatile_map_irq(). It does not work, unfortunately, at least not in qemu 1.4.0. This is what the kernel reports for interrupt numbers: kernel irq result -------------------------------------- 3.10.6: 92 fails 3.10.6+above change: 94 fails 3.10.6+Paul's patch: 91 works Now is this a qemu problem or a kernel problem ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 22:12 ` Russell King - ARM Linux (?) @ 2013-08-12 23:04 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 23:04 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > I tried the above with qemu 1.5.2. Success! Hacked diff is below. Can I write that up as clean patch and submit it, or do we need a test on real hardware ? Thanks, Guenter --- diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..53b4208 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -333,7 +333,11 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ +#if 0 irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); +#else + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); +#endif return irq; } ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 23:04 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 23:04 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > I tried the above with qemu 1.5.2. Success! Hacked diff is below. Can I write that up as clean patch and submit it, or do we need a test on real hardware ? Thanks, Guenter --- diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..53b4208 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -333,7 +333,11 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ +#if 0 irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); +#else + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); +#endif return irq; } ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 23:04 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-12 23:04 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, qemu-devel, linux-kernel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 11:12:50PM +0100, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 10:36:17PM +0100, Peter Maydell wrote: > > On this point, yes. Equivalent bit from the PB926 TRM: > > http://infocenter.arm.com/help/topic/com.arm.doc.dui0224i/Cacdijji.html > > > > (There are differences between the PCI controllers on > > the different boards. Differences I know of are: > > * size of the three memory mapped regions > > * whether the top bits of the PCI address come from the top > > or bottom of the IMAP* registers > > I believe (based on some experimentation and an educated guess) > > that these both changed at the same point, but some of the board > > TRMs claim to be part one way part the other, presumably due to > > copy and paste error. In particular PB1176's TRM has a mangled > > description of the IMAP* registers which didn't match what the > > h/w actually did in my testing.) > > Bah, updated TRMs since my version. > > Right, so if I've traced everything correctly, this should work: > > /* > * Slot INTA INTB INTC INTD > * 31 PCI1 PCI2 PCI3 PCI0 > * 30 PCI0 PCI1 PCI2 PCI3 > * 29 PCI3 PCI0 PCI1 PCI2 > */ > return IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); > I tried the above with qemu 1.5.2. Success! Hacked diff is below. Can I write that up as clean patch and submit it, or do we need a test on real hardware ? Thanks, Guenter --- diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..53b4208 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -333,7 +333,11 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) * 26 1 IRQ_SIC_PCI2 * 27 1 IRQ_SIC_PCI3 */ +#if 0 irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); +#else + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); +#endif return irq; } ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 23:04 ` Guenter Roeck (?) @ 2013-08-14 10:33 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 10:33 UTC (permalink / raw) To: Guenter Roeck Cc: Peter Maydell, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > Hacked diff is below. Can I write that up as clean patch and submit it, > or do we need a test on real hardware ? Well, if we want to ensure that it is really correct, the sensible thing to do is to try it on real hardware, otherwise we're risking yet another change to this. Earlier in this thread, some people said that they have the hardware, so it shouldn't be that difficult to get it tested on real stuff. ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 10:33 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 10:33 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > Hacked diff is below. Can I write that up as clean patch and submit it, > or do we need a test on real hardware ? Well, if we want to ensure that it is really correct, the sensible thing to do is to try it on real hardware, otherwise we're risking yet another change to this. Earlier in this thread, some people said that they have the hardware, so it shouldn't be that difficult to get it tested on real stuff. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 10:33 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 10:33 UTC (permalink / raw) To: Guenter Roeck Cc: Peter Maydell, qemu-devel, linux-kernel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > Hacked diff is below. Can I write that up as clean patch and submit it, > or do we need a test on real hardware ? Well, if we want to ensure that it is really correct, the sensible thing to do is to try it on real hardware, otherwise we're risking yet another change to this. Earlier in this thread, some people said that they have the hardware, so it shouldn't be that difficult to get it tested on real stuff. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-14 10:33 ` Russell King - ARM Linux (?) @ 2013-08-14 12:44 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:44 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 14 August 2013 11:33, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >> Hacked diff is below. Can I write that up as clean patch and submit it, >> or do we need a test on real hardware ? > > Well, if we want to ensure that it is really correct, the sensible thing > to do is to try it on real hardware, otherwise we're risking yet another > change to this. > > Earlier in this thread, some people said that they have the hardware, so > it shouldn't be that difficult to get it tested on real stuff. Yes, I definitely think we should test on the hardware before we land yet another change to this PCI code that hasn't really been thoroughly tested on anything. I have the board/backplane on my desk but it'll be later in the week before I can do the testing (currently still messing with uboot config to get it to actually boot a kernel). thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:44 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:44 UTC (permalink / raw) To: linux-arm-kernel On 14 August 2013 11:33, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >> Hacked diff is below. Can I write that up as clean patch and submit it, >> or do we need a test on real hardware ? > > Well, if we want to ensure that it is really correct, the sensible thing > to do is to try it on real hardware, otherwise we're risking yet another > change to this. > > Earlier in this thread, some people said that they have the hardware, so > it shouldn't be that difficult to get it tested on real stuff. Yes, I definitely think we should test on the hardware before we land yet another change to this PCI code that hasn't really been thoroughly tested on anything. I have the board/backplane on my desk but it'll be later in the week before I can do the testing (currently still messing with uboot config to get it to actually boot a kernel). thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:44 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:44 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 14 August 2013 11:33, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >> Hacked diff is below. Can I write that up as clean patch and submit it, >> or do we need a test on real hardware ? > > Well, if we want to ensure that it is really correct, the sensible thing > to do is to try it on real hardware, otherwise we're risking yet another > change to this. > > Earlier in this thread, some people said that they have the hardware, so > it shouldn't be that difficult to get it tested on real stuff. Yes, I definitely think we should test on the hardware before we land yet another change to this PCI code that hasn't really been thoroughly tested on anything. I have the board/backplane on my desk but it'll be later in the week before I can do the testing (currently still messing with uboot config to get it to actually boot a kernel). thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-14 12:44 ` Peter Maydell (?) @ 2013-08-14 12:49 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 12:49 UTC (permalink / raw) To: Peter Maydell Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > >> Hacked diff is below. Can I write that up as clean patch and submit it, > >> or do we need a test on real hardware ? > > > > Well, if we want to ensure that it is really correct, the sensible thing > > to do is to try it on real hardware, otherwise we're risking yet another > > change to this. > > > > Earlier in this thread, some people said that they have the hardware, so > > it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). Realview or Versatile? I still need to sort out Realview. The alternative is - I have both the Realview EB and Versatile PB926 here, but no backplane (it wasn't deemed to be necessary for me to have such a thing.) If someone wants to donate a backplane... ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:49 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 12:49 UTC (permalink / raw) To: linux-arm-kernel On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > >> Hacked diff is below. Can I write that up as clean patch and submit it, > >> or do we need a test on real hardware ? > > > > Well, if we want to ensure that it is really correct, the sensible thing > > to do is to try it on real hardware, otherwise we're risking yet another > > change to this. > > > > Earlier in this thread, some people said that they have the hardware, so > > it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). Realview or Versatile? I still need to sort out Realview. The alternative is - I have both the Realview EB and Versatile PB926 here, but no backplane (it wasn't deemed to be necessary for me to have such a thing.) If someone wants to donate a backplane... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:49 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-14 12:49 UTC (permalink / raw) To: Peter Maydell Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: > >> Hacked diff is below. Can I write that up as clean patch and submit it, > >> or do we need a test on real hardware ? > > > > Well, if we want to ensure that it is really correct, the sensible thing > > to do is to try it on real hardware, otherwise we're risking yet another > > change to this. > > > > Earlier in this thread, some people said that they have the hardware, so > > it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). Realview or Versatile? I still need to sort out Realview. The alternative is - I have both the Realview EB and Versatile PB926 here, but no backplane (it wasn't deemed to be necessary for me to have such a thing.) If someone wants to donate a backplane... ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-14 12:49 ` Russell King - ARM Linux (?) @ 2013-08-14 12:56 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:56 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 14 August 2013 13:49, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: >> Yes, I definitely think we should test on the hardware before we >> land yet another change to this PCI code that hasn't really been >> thoroughly tested on anything. I have the board/backplane on my >> desk but it'll be later in the week before I can do the testing >> (currently still messing with uboot config to get it to actually >> boot a kernel). > > Realview or Versatile? I still need to sort out Realview. PB926, so versatile. Let's get that one straightened out first, since at the moment the kernel has no realview PCI support at all. I should be able to get a PB1176 to go in the backplane for testing that, though. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:56 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:56 UTC (permalink / raw) To: linux-arm-kernel On 14 August 2013 13:49, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: >> Yes, I definitely think we should test on the hardware before we >> land yet another change to this PCI code that hasn't really been >> thoroughly tested on anything. I have the board/backplane on my >> desk but it'll be later in the week before I can do the testing >> (currently still messing with uboot config to get it to actually >> boot a kernel). > > Realview or Versatile? I still need to sort out Realview. PB926, so versatile. Let's get that one straightened out first, since at the moment the kernel has no realview PCI support at all. I should be able to get a PB1176 to go in the backplane for testing that, though. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 12:56 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-14 12:56 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 14 August 2013 13:49, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > On Wed, Aug 14, 2013 at 01:44:44PM +0100, Peter Maydell wrote: >> Yes, I definitely think we should test on the hardware before we >> land yet another change to this PCI code that hasn't really been >> thoroughly tested on anything. I have the board/backplane on my >> desk but it'll be later in the week before I can do the testing >> (currently still messing with uboot config to get it to actually >> boot a kernel). > > Realview or Versatile? I still need to sort out Realview. PB926, so versatile. Let's get that one straightened out first, since at the moment the kernel has no realview PCI support at all. I should be able to get a PB1176 to go in the backplane for testing that, though. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-14 12:44 ` Peter Maydell (?) @ 2013-08-14 14:41 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-14 14:41 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 08/14/2013 05:44 AM, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >>> Hacked diff is below. Can I write that up as clean patch and submit it, >>> or do we need a test on real hardware ? >> >> Well, if we want to ensure that it is really correct, the sensible thing >> to do is to try it on real hardware, otherwise we're risking yet another >> change to this. >> >> Earlier in this thread, some people said that they have the hardware, so >> it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my Agreed. > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). > That would be great. Thanks a lot for your help! Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 14:41 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-14 14:41 UTC (permalink / raw) To: linux-arm-kernel On 08/14/2013 05:44 AM, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >>> Hacked diff is below. Can I write that up as clean patch and submit it, >>> or do we need a test on real hardware ? >> >> Well, if we want to ensure that it is really correct, the sensible thing >> to do is to try it on real hardware, otherwise we're risking yet another >> change to this. >> >> Earlier in this thread, some people said that they have the hardware, so >> it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my Agreed. > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). > That would be great. Thanks a lot for your help! Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-14 14:41 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-14 14:41 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, qemu-devel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 08/14/2013 05:44 AM, Peter Maydell wrote: > On 14 August 2013 11:33, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: >> On Mon, Aug 12, 2013 at 04:04:08PM -0700, Guenter Roeck wrote: >>> Hacked diff is below. Can I write that up as clean patch and submit it, >>> or do we need a test on real hardware ? >> >> Well, if we want to ensure that it is really correct, the sensible thing >> to do is to try it on real hardware, otherwise we're risking yet another >> change to this. >> >> Earlier in this thread, some people said that they have the hardware, so >> it shouldn't be that difficult to get it tested on real stuff. > > Yes, I definitely think we should test on the hardware before we > land yet another change to this PCI code that hasn't really been > thoroughly tested on anything. I have the board/backplane on my Agreed. > desk but it'll be later in the week before I can do the testing > (currently still messing with uboot config to get it to actually > boot a kernel). > That would be great. Thanks a lot for your help! Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] memory reads and writes 2013-08-14 14:41 ` Guenter Roeck (?) (?) @ 2013-08-14 15:26 ` Herbei Dacian -1 siblings, 0 replies; 104+ messages in thread From: Herbei Dacian @ 2013-08-14 15:26 UTC (permalink / raw) To: qemu-devel [-- Attachment #1: Type: text/plain, Size: 344 bytes --] Hello all, my name is Dacian and I'm new on this mailing list. I would like to visualize during execution the addresses of the instruction currently been executed, the address of the memory being read and being written by the same execution if it applies. has anyone tried this before maybe is already implemented. best regards, dacian [-- Attachment #2: Type: text/html, Size: 1846 bytes --] ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 16:45 ` Russell King - ARM Linux (?) @ 2013-08-12 17:48 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:48 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I've just checked and the schematics are provided on the CDROM "Versatile Family Product Support CD" (version 3.0) which I think we shipped a copy of with every board... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 17:48 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:48 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I've just checked and the schematics are provided on the CDROM "Versatile Family Product Support CD" (version 3.0) which I think we shipped a copy of with every board... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 17:48 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 17:48 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 12 August 2013 17:45, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > In other words, if you have the circuit diagrams or other documentation > which definitively identifies the wiring, then please send it to me. I've just checked and the schematics are provided on the CDROM "Versatile Family Product Support CD" (version 3.0) which I think we shipped a copy of with every board... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 16:45 ` Russell King - ARM Linux (?) @ 2013-08-13 8:37 ` Rob Landley -1 siblings, 0 replies; 104+ messages in thread From: Rob Landley @ 2013-08-13 8:37 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 08/12/2013 11:45:49 AM, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > > >> It could be that it's qemu's PCI routing is wrong - it's not the > first > > >> time that qemu has got something wrong. > > > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > > correspond with the hardware (cross-tested versus Arnd Bergmann's > > patchset > > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > > which was run on real versatilePB backplane hardware and > > could handle a PCI SATA card). I believe it to be correct, > > and I spent a fairly long time wading through the various bits > > of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several > times > and it just doesn't give the necessary information to work out what > the > routing actually is. The only place that's documented is in the > circuits, > which are impossible to get hold of (even asking ARM for them doesn't > get > anywhere: basically, all information has been destroyed.) We had this argument on the qemu list. See this and Peter's reply message to it: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01202.html I got my images working by setting a magic value to a register to convince current qemu that it was running an old kernel, and then using the IRQ mapping of the old kernel before Linux went through multiple different random things that didn't work on the emulator _or_ any hardware. Peter says he knows somebody who knows somebody who dug some instance of this hardware out of some landfill or something. Me, I want to get something that works on new qemu _and_ last year's qemu, and that's what I got. I think that's far more interesting since the point of qemu's versatile emulation is really just "an arm board QEMU can stick a PCI bus in and thus attach arbitrary devices like network cards and hard drives to in a somewhat flexible way". > > If somebody would like to fix the kernel I am happy to > > locate the PCI backplane and test everything (again). > > I would suggest that producing some patches which work > > with QEMU 1.5 or later would be a good start; then we > > can test on h/w as confirmation before they are applied. > > If someone is willing to send me some definitive information, then > the kernel will get fixed. All the time that there is no definitive > information, there is no point what so ever changing the kernel. Because working with old and new qemu, like it used to before everybody fiddled with it to not actually match hardware nobody _has_, is definitely not an interesting goal. If it was, I'd point you to: http://landley.net/hg/aboriginal/rev/c756b708583f Rob ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 8:37 ` Rob Landley 0 siblings, 0 replies; 104+ messages in thread From: Rob Landley @ 2013-08-13 8:37 UTC (permalink / raw) To: linux-arm-kernel On 08/12/2013 11:45:49 AM, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > > >> It could be that it's qemu's PCI routing is wrong - it's not the > first > > >> time that qemu has got something wrong. > > > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > > correspond with the hardware (cross-tested versus Arnd Bergmann's > > patchset > > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > > which was run on real versatilePB backplane hardware and > > could handle a PCI SATA card). I believe it to be correct, > > and I spent a fairly long time wading through the various bits > > of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several > times > and it just doesn't give the necessary information to work out what > the > routing actually is. The only place that's documented is in the > circuits, > which are impossible to get hold of (even asking ARM for them doesn't > get > anywhere: basically, all information has been destroyed.) We had this argument on the qemu list. See this and Peter's reply message to it: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01202.html I got my images working by setting a magic value to a register to convince current qemu that it was running an old kernel, and then using the IRQ mapping of the old kernel before Linux went through multiple different random things that didn't work on the emulator _or_ any hardware. Peter says he knows somebody who knows somebody who dug some instance of this hardware out of some landfill or something. Me, I want to get something that works on new qemu _and_ last year's qemu, and that's what I got. I think that's far more interesting since the point of qemu's versatile emulation is really just "an arm board QEMU can stick a PCI bus in and thus attach arbitrary devices like network cards and hard drives to in a somewhat flexible way". > > If somebody would like to fix the kernel I am happy to > > locate the PCI backplane and test everything (again). > > I would suggest that producing some patches which work > > with QEMU 1.5 or later would be a good start; then we > > can test on h/w as confirmation before they are applied. > > If someone is willing to send me some definitive information, then > the kernel will get fixed. All the time that there is no definitive > information, there is no point what so ever changing the kernel. Because working with old and new qemu, like it used to before everybody fiddled with it to not actually match hardware nobody _has_, is definitely not an interesting goal. If it was, I'd point you to: http://landley.net/hg/aboriginal/rev/c756b708583f Rob ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 8:37 ` Rob Landley 0 siblings, 0 replies; 104+ messages in thread From: Rob Landley @ 2013-08-13 8:37 UTC (permalink / raw) To: Russell King - ARM Linux Cc: Peter Maydell, qemu-devel, linux-kernel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 08/12/2013 11:45:49 AM, Russell King - ARM Linux wrote: > On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: > > On 12 August 2013 01:40, Guenter Roeck <linux@roeck-us.net> wrote: > > > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: > > >> It could be that it's qemu's PCI routing is wrong - it's not the > first > > >> time that qemu has got something wrong. > > > > QEMU 1.5 has had its Versatile PCI routing code rewritten to > > correspond with the hardware (cross-tested versus Arnd Bergmann's > > patchset > > http://marc.info/?l=linux-arm-kernel&m=128707282403376&w=2 > > which was run on real versatilePB backplane hardware and > > could handle a PCI SATA card). I believe it to be correct, > > and I spent a fairly long time wading through the various bits > > of documentation and testing those kernel patches on h/w. > > The documentation is totally useless - I've been through it several > times > and it just doesn't give the necessary information to work out what > the > routing actually is. The only place that's documented is in the > circuits, > which are impossible to get hold of (even asking ARM for them doesn't > get > anywhere: basically, all information has been destroyed.) We had this argument on the qemu list. See this and Peter's reply message to it: http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg01202.html I got my images working by setting a magic value to a register to convince current qemu that it was running an old kernel, and then using the IRQ mapping of the old kernel before Linux went through multiple different random things that didn't work on the emulator _or_ any hardware. Peter says he knows somebody who knows somebody who dug some instance of this hardware out of some landfill or something. Me, I want to get something that works on new qemu _and_ last year's qemu, and that's what I got. I think that's far more interesting since the point of qemu's versatile emulation is really just "an arm board QEMU can stick a PCI bus in and thus attach arbitrary devices like network cards and hard drives to in a somewhat flexible way". > > If somebody would like to fix the kernel I am happy to > > locate the PCI backplane and test everything (again). > > I would suggest that producing some patches which work > > with QEMU 1.5 or later would be a good start; then we > > can test on h/w as confirmation before they are applied. > > If someone is willing to send me some definitive information, then > the kernel will get fixed. All the time that there is no definitive > information, there is no point what so ever changing the kernel. Because working with old and new qemu, like it used to before everybody fiddled with it to not actually match hardware nobody _has_, is definitely not an interesting goal. If it was, I'd point you to: http://landley.net/hg/aboriginal/rev/c756b708583f Rob ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-13 8:37 ` Rob Landley (?) @ 2013-08-13 9:12 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-13 9:12 UTC (permalink / raw) To: Rob Landley Cc: Russell King - ARM Linux, Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On 13 August 2013 09:37, Rob Landley <rob@landley.net> wrote: > Peter says he knows somebody who knows somebody who dug some instance of > this hardware out of some landfill or something. No, I personally myself had the hardware. Really. > Me, I want to get something that works on new qemu _and_ last year's > qemu, and that's what I got. Note that in general hoping that current mainline kernel will always work with ancient QEMU is a losing proposition -- it is always possible that a kernel improvement will trigger a latent model bug in QEMU. (To pick a random example, some while ago fixes to how the kernel dealt with BGR and RGB pixel formats on the versatile board broke QEMU because we weren't modelling it right; that was just a QEMU bug for which the fix is "get a newer QEMU".) The back-compat in the PCI code is so that the older kernels (2.6.x) will continue to work, which is not quite the same thing. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 9:12 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-13 9:12 UTC (permalink / raw) To: linux-arm-kernel On 13 August 2013 09:37, Rob Landley <rob@landley.net> wrote: > Peter says he knows somebody who knows somebody who dug some instance of > this hardware out of some landfill or something. No, I personally myself had the hardware. Really. > Me, I want to get something that works on new qemu _and_ last year's > qemu, and that's what I got. Note that in general hoping that current mainline kernel will always work with ancient QEMU is a losing proposition -- it is always possible that a kernel improvement will trigger a latent model bug in QEMU. (To pick a random example, some while ago fixes to how the kernel dealt with BGR and RGB pixel formats on the versatile board broke QEMU because we weren't modelling it right; that was just a QEMU bug for which the fix is "get a newer QEMU".) The back-compat in the PCI code is so that the older kernels (2.6.x) will continue to work, which is not quite the same thing. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 9:12 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-13 9:12 UTC (permalink / raw) To: Rob Landley Cc: Russell King - ARM Linux, linux-kernel, qemu-devel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On 13 August 2013 09:37, Rob Landley <rob@landley.net> wrote: > Peter says he knows somebody who knows somebody who dug some instance of > this hardware out of some landfill or something. No, I personally myself had the hardware. Really. > Me, I want to get something that works on new qemu _and_ last year's > qemu, and that's what I got. Note that in general hoping that current mainline kernel will always work with ancient QEMU is a losing proposition -- it is always possible that a kernel improvement will trigger a latent model bug in QEMU. (To pick a random example, some while ago fixes to how the kernel dealt with BGR and RGB pixel formats on the versatile board broke QEMU because we weren't modelling it right; that was just a QEMU bug for which the fix is "get a newer QEMU".) The back-compat in the PCI code is so that the older kernels (2.6.x) will continue to work, which is not quite the same thing. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-13 8:37 ` Rob Landley (?) @ 2013-08-13 11:30 ` Russell King - ARM Linux -1 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-13 11:30 UTC (permalink / raw) To: Rob Landley Cc: Peter Maydell, Guenter Roeck, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote: > Because working with old and new qemu, like it used to before everybody > fiddled with it to not actually match hardware nobody _has_, is > definitely not an interesting goal. It appears that people *do* have the hardware. What is also "not interesting" is to have bugs reported, I state that I won't fix it unless we know what the hardware is supposed to be, and then for everything to go quiet, and qemu to have patches put in to "work around" the problem. Software emulators are exactly that: they are software. They contain bugs, just like any other bit of software. With the lack of clear documentation about the hardware, and comments in the code written by ARM Ltd when this stuff was first created, the only thing which can be taken as definitive is the comments, which is exactly what I did. Then to have people using qemu report that something is broken - sorry, but software emulation doesn't matter in that regard. Especially when we've had reports that "the kernel is broken" wrt timers and it turns out to be a bug in qemu not emulating them correctly. Think about it - how do we know whether the kernel is buggy or the software emulation is buggy. Without going back to the hardware or pointing at documentation, we can't answer that question. So it's safer to leave things as-is. It seems that the documentation over the years from ARM Ltd has improved to the point that it is now possible to figure out some of the details, if you're prepared to spend a lot of time finding it in the latest documentation and tracing circuit diagrams. (ARMs documentation site is pretty horrid to find documents on.) Well, that has now finally happened, so we can be finally be confident what the correct answer is to this. This is all something which should have happened yonks ago. ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 11:30 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-13 11:30 UTC (permalink / raw) To: linux-arm-kernel On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote: > Because working with old and new qemu, like it used to before everybody > fiddled with it to not actually match hardware nobody _has_, is > definitely not an interesting goal. It appears that people *do* have the hardware. What is also "not interesting" is to have bugs reported, I state that I won't fix it unless we know what the hardware is supposed to be, and then for everything to go quiet, and qemu to have patches put in to "work around" the problem. Software emulators are exactly that: they are software. They contain bugs, just like any other bit of software. With the lack of clear documentation about the hardware, and comments in the code written by ARM Ltd when this stuff was first created, the only thing which can be taken as definitive is the comments, which is exactly what I did. Then to have people using qemu report that something is broken - sorry, but software emulation doesn't matter in that regard. Especially when we've had reports that "the kernel is broken" wrt timers and it turns out to be a bug in qemu not emulating them correctly. Think about it - how do we know whether the kernel is buggy or the software emulation is buggy. Without going back to the hardware or pointing at documentation, we can't answer that question. So it's safer to leave things as-is. It seems that the documentation over the years from ARM Ltd has improved to the point that it is now possible to figure out some of the details, if you're prepared to spend a lot of time finding it in the latest documentation and tracing circuit diagrams. (ARMs documentation site is pretty horrid to find documents on.) Well, that has now finally happened, so we can be finally be confident what the correct answer is to this. This is all something which should have happened yonks ago. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 11:30 ` Russell King - ARM Linux 0 siblings, 0 replies; 104+ messages in thread From: Russell King - ARM Linux @ 2013-08-13 11:30 UTC (permalink / raw) To: Rob Landley Cc: Peter Maydell, qemu-devel, linux-kernel, Paul Gortmaker, Guenter Roeck, Arnd Bergmann, linux-arm-kernel On Tue, Aug 13, 2013 at 03:37:31AM -0500, Rob Landley wrote: > Because working with old and new qemu, like it used to before everybody > fiddled with it to not actually match hardware nobody _has_, is > definitely not an interesting goal. It appears that people *do* have the hardware. What is also "not interesting" is to have bugs reported, I state that I won't fix it unless we know what the hardware is supposed to be, and then for everything to go quiet, and qemu to have patches put in to "work around" the problem. Software emulators are exactly that: they are software. They contain bugs, just like any other bit of software. With the lack of clear documentation about the hardware, and comments in the code written by ARM Ltd when this stuff was first created, the only thing which can be taken as definitive is the comments, which is exactly what I did. Then to have people using qemu report that something is broken - sorry, but software emulation doesn't matter in that regard. Especially when we've had reports that "the kernel is broken" wrt timers and it turns out to be a bug in qemu not emulating them correctly. Think about it - how do we know whether the kernel is buggy or the software emulation is buggy. Without going back to the hardware or pointing at documentation, we can't answer that question. So it's safer to leave things as-is. It seems that the documentation over the years from ARM Ltd has improved to the point that it is now possible to figure out some of the details, if you're prepared to spend a lot of time finding it in the latest documentation and tracing circuit diagrams. (ARMs documentation site is pretty horrid to find documents on.) Well, that has now finally happened, so we can be finally be confident what the correct answer is to this. This is all something which should have happened yonks ago. ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 16:24 ` Peter Maydell (?) @ 2013-08-13 3:40 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-13 3:40 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, qemu-devel, Arnd Bergmann On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: [ ... ] > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. > Ok, putting a stake in the ground. Patch tested and working with qemu 1.5.2, using the configuration file from the yocto project. Patch applied on top of kernel version 3.11-rc5. Guenter --- >From 1e07521e935267f2d63ed3635fb93c7e325e0936 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux@roeck-us.net> Date: Mon, 12 Aug 2013 16:20:18 -0700 Subject: [PATCH] arm: Fix map_irq function for ARM versatile hardware Booting the ARM versatile in qemu fails with the SCSI controller timing out as follows: ------------ sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 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 ------------ Bisecting gives commit 1bc39ac5dab265b76ce6e20d6c85f900539fd190 ("ARM: PCI: versatile: fix PCI interrupt setup") -- specifically the change to use common swizzle instead of NULL. Further analysis shows that interrupt mapping is wrong for the versatile hardware. Thanks to Paul Gortmaker for bisecting the problem and finding an initial solution, to Russell King for providing the correct interrupt mapping, and to Peter Maydell for tracking down board information. Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- arch/arm/mach-versatile/pci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..f435267 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -327,13 +327,13 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) { int irq; - /* slot, pin, irq - * 24 1 IRQ_SIC_PCI0 - * 25 1 IRQ_SIC_PCI1 - * 26 1 IRQ_SIC_PCI2 - * 27 1 IRQ_SIC_PCI3 + /* + * Slot INTA INTB INTC INTD + * 31 PCI1 PCI2 PCI3 PCI0 + * 30 PCI0 PCI1 PCI2 PCI3 + * 29 PCI3 PCI0 PCI1 PCI2 */ - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); return irq; } -- 1.7.9.7 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 3:40 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-13 3:40 UTC (permalink / raw) To: linux-arm-kernel On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: [ ... ] > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. > Ok, putting a stake in the ground. Patch tested and working with qemu 1.5.2, using the configuration file from the yocto project. Patch applied on top of kernel version 3.11-rc5. Guenter --- >From 1e07521e935267f2d63ed3635fb93c7e325e0936 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux@roeck-us.net> Date: Mon, 12 Aug 2013 16:20:18 -0700 Subject: [PATCH] arm: Fix map_irq function for ARM versatile hardware Booting the ARM versatile in qemu fails with the SCSI controller timing out as follows: ------------ sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 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 ------------ Bisecting gives commit 1bc39ac5dab265b76ce6e20d6c85f900539fd190 ("ARM: PCI: versatile: fix PCI interrupt setup") -- specifically the change to use common swizzle instead of NULL. Further analysis shows that interrupt mapping is wrong for the versatile hardware. Thanks to Paul Gortmaker for bisecting the problem and finding an initial solution, to Russell King for providing the correct interrupt mapping, and to Peter Maydell for tracking down board information. Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- arch/arm/mach-versatile/pci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..f435267 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -327,13 +327,13 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) { int irq; - /* slot, pin, irq - * 24 1 IRQ_SIC_PCI0 - * 25 1 IRQ_SIC_PCI1 - * 26 1 IRQ_SIC_PCI2 - * 27 1 IRQ_SIC_PCI3 + /* + * Slot INTA INTB INTC INTD + * 31 PCI1 PCI2 PCI3 PCI0 + * 30 PCI0 PCI1 PCI2 PCI3 + * 29 PCI3 PCI0 PCI1 PCI2 */ - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); return irq; } -- 1.7.9.7 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-13 3:40 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-13 3:40 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, qemu-devel, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Mon, Aug 12, 2013 at 05:24:50PM +0100, Peter Maydell wrote: [ ... ] > If somebody would like to fix the kernel I am happy to > locate the PCI backplane and test everything (again). > I would suggest that producing some patches which work > with QEMU 1.5 or later would be a good start; then we > can test on h/w as confirmation before they are applied. > Ok, putting a stake in the ground. Patch tested and working with qemu 1.5.2, using the configuration file from the yocto project. Patch applied on top of kernel version 3.11-rc5. Guenter --- >From 1e07521e935267f2d63ed3635fb93c7e325e0936 Mon Sep 17 00:00:00 2001 From: Guenter Roeck <linux@roeck-us.net> Date: Mon, 12 Aug 2013 16:20:18 -0700 Subject: [PATCH] arm: Fix map_irq function for ARM versatile hardware Booting the ARM versatile in qemu fails with the SCSI controller timing out as follows: ------------ sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 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 ------------ Bisecting gives commit 1bc39ac5dab265b76ce6e20d6c85f900539fd190 ("ARM: PCI: versatile: fix PCI interrupt setup") -- specifically the change to use common swizzle instead of NULL. Further analysis shows that interrupt mapping is wrong for the versatile hardware. Thanks to Paul Gortmaker for bisecting the problem and finding an initial solution, to Russell King for providing the correct interrupt mapping, and to Peter Maydell for tracking down board information. Signed-off-by: Guenter Roeck <linux@roeck-us.net> --- arch/arm/mach-versatile/pci.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-versatile/pci.c b/arch/arm/mach-versatile/pci.c index e92e5e0..f435267 100644 --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -327,13 +327,13 @@ static int __init versatile_map_irq(const struct pci_dev *dev, u8 slot, u8 pin) { int irq; - /* slot, pin, irq - * 24 1 IRQ_SIC_PCI0 - * 25 1 IRQ_SIC_PCI1 - * 26 1 IRQ_SIC_PCI2 - * 27 1 IRQ_SIC_PCI3 + /* + * Slot INTA INTB INTC INTD + * 31 PCI1 PCI2 PCI3 PCI0 + * 30 PCI0 PCI1 PCI2 PCI3 + * 29 PCI3 PCI0 PCI1 PCI2 */ - irq = IRQ_SIC_PCI0 + ((slot - 24 + pin - 1) & 3); + irq = IRQ_SIC_PCI0 + ((slot + 2 + pin - 1) & 3); return irq; } -- 1.7.9.7 ^ permalink raw reply related [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-13 3:40 ` Guenter Roeck (?) @ 2013-08-15 16:45 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 16:45 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > Patch tested and working with qemu 1.5.2, using the configuration file > from the yocto project. Patch applied on top of kernel version 3.11-rc5. OK, I tested this on PB926+PCI backplane hardware, and it is definitely better than current mainline, in that the test USB card that I have no longer causes the kernel to generate this sort of backtrace: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci 0000:00:1e.2: EHCI Host Controller ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd usb usb1: SerialNumber: 0000:00:1e.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-pci: OHCI PCI platform driver ohci-pci 0000:00:1e.0: OHCI PCI host controller ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 irq 93: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] (show_stack+0x10/0x14) [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] (__report_bad_irq+0x24/0xb8) [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] (note_interrupt+0x1cc/0x230) [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] (handle_irq_event+0x28/0x38) [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] (handle_level_irq+0x80/0xd4) [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] (fpga_irq_handle+0x3c/0x50) [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] (handle_IRQ+0x30/0x84) [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829cc8 to 0xc7829d10) 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 9d00: c0025f38 c0025fa8 20000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829d80 to 0xc7829dc8) 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 9dc0: 40000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] (request_threaded_irq+0xb4/0x138) [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] (pci_device_probe+0x68/0x90) [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] (driver_probe_device+0x78/0x200) [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] (__driver_attach+0x8c/0x90) [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] (bus_for_each_dev+0x58/0x88) [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] (bus_add_driver+0xd8/0x220) [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] (driver_register+0x78/0x144) [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] (do_one_initcall+0x94/0x154) [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] (kernel_init+0x8/0xe4) [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) handlers: [<c01f7e48>] usb_hcd_irq Disabling IRQ #93 However it still doesn't seem to reliably detect the USB harddisk plugged into the card, so I think there may be further issues, possibly some subset of those Arnd identified and fixed with this patch: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 so I'd like to continue testing. The other thing this patch should (IMHO) have is the line in pci_versatile_setup() which tells QEMU that the kernel really does expect hardware-like behaviour: --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data *sys) __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); /* + * For many years the kernel and QEMU were symbiotically buggy + * in that they both assumed the same broken IRQ mapping. + * QEMU therefore attempts to auto-detect old broken kernels + * so that they still work on newer QEMU as they did on old + * QEMU. Since we now use the correct (ie matching-hardware) + * IRQ mapping we write a definitely different value to a + * PCI_INTERRUPT_LINE register to tell QEMU that we expect + * real hardware behaviour and it need not be backwards + * compatible for us. This write is harmless on real hardware. + */ + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); + + /* * Do not to map Versatile FPGA PCI device into memory space */ pci_slot_ignore |= (1 << myslot); I appreciate that QEMU-specific code in the kernel is a bit ugly, but (a) 99.9% of the people running this code are going to be running it on QEMU (b) the bugs in this area have been extremely long-standing in both the kernel and QEMU and so there are a lot of legacy kernel images out there that worked just fine with QEMU (c) it's rather less code than I have in QEMU as the QEMU-side part of this backwards-compatibility autodetection. (Without this line QEMU will guess whether the kernel is broken or not and will get it right most but not necessarily all of the time.) thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 16:45 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 16:45 UTC (permalink / raw) To: linux-arm-kernel On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > Patch tested and working with qemu 1.5.2, using the configuration file > from the yocto project. Patch applied on top of kernel version 3.11-rc5. OK, I tested this on PB926+PCI backplane hardware, and it is definitely better than current mainline, in that the test USB card that I have no longer causes the kernel to generate this sort of backtrace: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci 0000:00:1e.2: EHCI Host Controller ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd usb usb1: SerialNumber: 0000:00:1e.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-pci: OHCI PCI platform driver ohci-pci 0000:00:1e.0: OHCI PCI host controller ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 irq 93: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] (show_stack+0x10/0x14) [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] (__report_bad_irq+0x24/0xb8) [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] (note_interrupt+0x1cc/0x230) [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] (handle_irq_event+0x28/0x38) [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] (handle_level_irq+0x80/0xd4) [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] (fpga_irq_handle+0x3c/0x50) [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] (handle_IRQ+0x30/0x84) [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829cc8 to 0xc7829d10) 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 9d00: c0025f38 c0025fa8 20000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829d80 to 0xc7829dc8) 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 9dc0: 40000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] (request_threaded_irq+0xb4/0x138) [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] (pci_device_probe+0x68/0x90) [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] (driver_probe_device+0x78/0x200) [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] (__driver_attach+0x8c/0x90) [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] (bus_for_each_dev+0x58/0x88) [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] (bus_add_driver+0xd8/0x220) [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] (driver_register+0x78/0x144) [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] (do_one_initcall+0x94/0x154) [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] (kernel_init+0x8/0xe4) [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) handlers: [<c01f7e48>] usb_hcd_irq Disabling IRQ #93 However it still doesn't seem to reliably detect the USB harddisk plugged into the card, so I think there may be further issues, possibly some subset of those Arnd identified and fixed with this patch: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 so I'd like to continue testing. The other thing this patch should (IMHO) have is the line in pci_versatile_setup() which tells QEMU that the kernel really does expect hardware-like behaviour: --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data *sys) __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); /* + * For many years the kernel and QEMU were symbiotically buggy + * in that they both assumed the same broken IRQ mapping. + * QEMU therefore attempts to auto-detect old broken kernels + * so that they still work on newer QEMU as they did on old + * QEMU. Since we now use the correct (ie matching-hardware) + * IRQ mapping we write a definitely different value to a + * PCI_INTERRUPT_LINE register to tell QEMU that we expect + * real hardware behaviour and it need not be backwards + * compatible for us. This write is harmless on real hardware. + */ + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); + + /* * Do not to map Versatile FPGA PCI device into memory space */ pci_slot_ignore |= (1 << myslot); I appreciate that QEMU-specific code in the kernel is a bit ugly, but (a) 99.9% of the people running this code are going to be running it on QEMU (b) the bugs in this area have been extremely long-standing in both the kernel and QEMU and so there are a lot of legacy kernel images out there that worked just fine with QEMU (c) it's rather less code than I have in QEMU as the QEMU-side part of this backwards-compatibility autodetection. (Without this line QEMU will guess whether the kernel is broken or not and will get it right most but not necessarily all of the time.) thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 16:45 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 16:45 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > Patch tested and working with qemu 1.5.2, using the configuration file > from the yocto project. Patch applied on top of kernel version 3.11-rc5. OK, I tested this on PB926+PCI backplane hardware, and it is definitely better than current mainline, in that the test USB card that I have no longer causes the kernel to generate this sort of backtrace: ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-pci: EHCI PCI platform driver ehci-pci 0000:00:1e.2: EHCI Host Controller ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: EHCI Host Controller usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd usb usb1: SerialNumber: 0000:00:1e.2 hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver ohci-pci: OHCI PCI platform driver ohci-pci 0000:00:1e.0: OHCI PCI host controller ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 irq 93: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] (show_stack+0x10/0x14) [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] (__report_bad_irq+0x24/0xb8) [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] (note_interrupt+0x1cc/0x230) [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] (handle_irq_event+0x28/0x38) [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] (handle_level_irq+0x80/0xd4) [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] (fpga_irq_handle+0x3c/0x50) [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] (generic_handle_irq+0x2c/0x40) [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] (handle_IRQ+0x30/0x84) [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829cc8 to 0xc7829d10) 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 9d00: c0025f38 c0025fa8 20000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) Exception stack(0xc7829d80 to 0xc7829dc8) 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 9dc0: 40000013 ffffffff [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] (request_threaded_irq+0xb4/0x138) [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] (pci_device_probe+0x68/0x90) [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] (driver_probe_device+0x78/0x200) [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] (__driver_attach+0x8c/0x90) [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] (bus_for_each_dev+0x58/0x88) [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] (bus_add_driver+0xd8/0x220) [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] (driver_register+0x78/0x144) [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] (do_one_initcall+0x94/0x154) [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] (kernel_init+0x8/0xe4) [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) handlers: [<c01f7e48>] usb_hcd_irq Disabling IRQ #93 However it still doesn't seem to reliably detect the USB harddisk plugged into the card, so I think there may be further issues, possibly some subset of those Arnd identified and fixed with this patch: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 so I'd like to continue testing. The other thing this patch should (IMHO) have is the line in pci_versatile_setup() which tells QEMU that the kernel really does expect hardware-like behaviour: --- a/arch/arm/mach-versatile/pci.c +++ b/arch/arm/mach-versatile/pci.c @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct pci_sys_data *sys) __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); /* + * For many years the kernel and QEMU were symbiotically buggy + * in that they both assumed the same broken IRQ mapping. + * QEMU therefore attempts to auto-detect old broken kernels + * so that they still work on newer QEMU as they did on old + * QEMU. Since we now use the correct (ie matching-hardware) + * IRQ mapping we write a definitely different value to a + * PCI_INTERRUPT_LINE register to tell QEMU that we expect + * real hardware behaviour and it need not be backwards + * compatible for us. This write is harmless on real hardware. + */ + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); + + /* * Do not to map Versatile FPGA PCI device into memory space */ pci_slot_ignore |= (1 << myslot); I appreciate that QEMU-specific code in the kernel is a bit ugly, but (a) 99.9% of the people running this code are going to be running it on QEMU (b) the bugs in this area have been extremely long-standing in both the kernel and QEMU and so there are a lot of legacy kernel images out there that worked just fine with QEMU (c) it's rather less code than I have in QEMU as the QEMU-side part of this backwards-compatibility autodetection. (Without this line QEMU will guess whether the kernel is broken or not and will get it right most but not necessarily all of the time.) thanks -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 16:45 ` Peter Maydell (?) @ 2013-08-15 17:54 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 17:54 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > > Patch tested and working with qemu 1.5.2, using the configuration file > > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > > OK, I tested this on PB926+PCI backplane hardware, and it is > definitely better than current mainline, in that the test USB > card that I have no longer causes the kernel to generate this sort of > backtrace: > Do you mean my patch fixes the traceback below as a side effect ? Would be great ... it would be one more reason to get it applied. > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ehci-pci: EHCI PCI platform driver > ehci-pci 0000:00:1e.2: EHCI Host Controller > ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 > ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 > ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: EHCI Host Controller > usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd > usb usb1: SerialNumber: 0000:00:1e.2 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > ohci-pci: OHCI PCI platform driver > ohci-pci 0000:00:1e.0: OHCI PCI host controller > ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 > irq 93: nobody cared (try booting with the "irqpoll" option) > CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 > [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] > (show_stack+0x10/0x14) > [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] > (__report_bad_irq+0x24/0xb8) > [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] > (note_interrupt+0x1cc/0x230) > [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] > (handle_irq_event_percpu+0xac/0x1c4) > [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] > (handle_irq_event+0x28/0x38) > [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] > (handle_level_irq+0x80/0xd4) > [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] > (fpga_irq_handle+0x3c/0x50) > [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] > (handle_IRQ+0x30/0x84) > [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829cc8 to 0xc7829d10) > 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 > 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 > 9d00: c0025f38 c0025fa8 20000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) > [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) > [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) > [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829d80 to 0xc7829dc8) > 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 > 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 > 9dc0: 40000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) > [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] > (request_threaded_irq+0xb4/0x138) > [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] > (usb_add_hcd+0x4f0/0x6f0) > [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] > (usb_hcd_pci_probe+0x200/0x36c) > [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] > (pci_device_probe+0x68/0x90) > [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] > (driver_probe_device+0x78/0x200) > [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] > (__driver_attach+0x8c/0x90) > [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] > (bus_for_each_dev+0x58/0x88) > [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] > (bus_add_driver+0xd8/0x220) > [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] > (driver_register+0x78/0x144) > [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] > (do_one_initcall+0x94/0x154) > [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] > (kernel_init_freeable+0xec/0x1b0) > [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] > (kernel_init+0x8/0xe4) > [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) > handlers: > [<c01f7e48>] usb_hcd_irq > Disabling IRQ #93 > > However it still doesn't seem to reliably detect the USB harddisk > plugged into the card, so I think there may be further issues, possibly > some subset of those Arnd identified and fixed with this patch: > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > Does it get better if you apply Arnd's patch ? > so I'd like to continue testing. > > The other thing this patch should (IMHO) have is the > line in pci_versatile_setup() which tells QEMU that the > kernel really does expect hardware-like behaviour: > > --- a/arch/arm/mach-versatile/pci.c > +++ b/arch/arm/mach-versatile/pci.c > @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct > pci_sys_data *sys) > __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); > > /* > + * For many years the kernel and QEMU were symbiotically buggy > + * in that they both assumed the same broken IRQ mapping. > + * QEMU therefore attempts to auto-detect old broken kernels > + * so that they still work on newer QEMU as they did on old > + * QEMU. Since we now use the correct (ie matching-hardware) > + * IRQ mapping we write a definitely different value to a > + * PCI_INTERRUPT_LINE register to tell QEMU that we expect > + * real hardware behaviour and it need not be backwards > + * compatible for us. This write is harmless on real hardware. > + */ > + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); > + > + /* > * Do not to map Versatile FPGA PCI device into memory space > */ > pci_slot_ignore |= (1 << myslot); > > I appreciate that QEMU-specific code in the kernel is a bit ugly, but > (a) 99.9% of the people running this code are going to be running it on QEMU > (b) the bugs in this area have been extremely long-standing in both > the kernel and QEMU and so there are a lot of legacy kernel images > out there that worked just fine with QEMU > (c) it's rather less code than I have in QEMU as the QEMU-side part > of this backwards-compatibility autodetection. > > (Without this line QEMU will guess whether the kernel is broken > or not and will get it right most but not necessarily all of the time.) > Might make sense, but I think it should be a separate patch. If I understand correctly, my patch fixes the SCSI problem. Is that correct ? If so, can we get it applied to mainline ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 17:54 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 17:54 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > > Patch tested and working with qemu 1.5.2, using the configuration file > > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > > OK, I tested this on PB926+PCI backplane hardware, and it is > definitely better than current mainline, in that the test USB > card that I have no longer causes the kernel to generate this sort of > backtrace: > Do you mean my patch fixes the traceback below as a side effect ? Would be great ... it would be one more reason to get it applied. > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ehci-pci: EHCI PCI platform driver > ehci-pci 0000:00:1e.2: EHCI Host Controller > ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 > ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 > ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: EHCI Host Controller > usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd > usb usb1: SerialNumber: 0000:00:1e.2 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > ohci-pci: OHCI PCI platform driver > ohci-pci 0000:00:1e.0: OHCI PCI host controller > ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 > irq 93: nobody cared (try booting with the "irqpoll" option) > CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 > [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] > (show_stack+0x10/0x14) > [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] > (__report_bad_irq+0x24/0xb8) > [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] > (note_interrupt+0x1cc/0x230) > [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] > (handle_irq_event_percpu+0xac/0x1c4) > [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] > (handle_irq_event+0x28/0x38) > [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] > (handle_level_irq+0x80/0xd4) > [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] > (fpga_irq_handle+0x3c/0x50) > [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] > (handle_IRQ+0x30/0x84) > [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829cc8 to 0xc7829d10) > 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 > 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 > 9d00: c0025f38 c0025fa8 20000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) > [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) > [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) > [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829d80 to 0xc7829dc8) > 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 > 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 > 9dc0: 40000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) > [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] > (request_threaded_irq+0xb4/0x138) > [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] > (usb_add_hcd+0x4f0/0x6f0) > [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] > (usb_hcd_pci_probe+0x200/0x36c) > [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] > (pci_device_probe+0x68/0x90) > [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] > (driver_probe_device+0x78/0x200) > [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] > (__driver_attach+0x8c/0x90) > [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] > (bus_for_each_dev+0x58/0x88) > [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] > (bus_add_driver+0xd8/0x220) > [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] > (driver_register+0x78/0x144) > [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] > (do_one_initcall+0x94/0x154) > [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] > (kernel_init_freeable+0xec/0x1b0) > [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] > (kernel_init+0x8/0xe4) > [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) > handlers: > [<c01f7e48>] usb_hcd_irq > Disabling IRQ #93 > > However it still doesn't seem to reliably detect the USB harddisk > plugged into the card, so I think there may be further issues, possibly > some subset of those Arnd identified and fixed with this patch: > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > Does it get better if you apply Arnd's patch ? > so I'd like to continue testing. > > The other thing this patch should (IMHO) have is the > line in pci_versatile_setup() which tells QEMU that the > kernel really does expect hardware-like behaviour: > > --- a/arch/arm/mach-versatile/pci.c > +++ b/arch/arm/mach-versatile/pci.c > @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct > pci_sys_data *sys) > __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); > > /* > + * For many years the kernel and QEMU were symbiotically buggy > + * in that they both assumed the same broken IRQ mapping. > + * QEMU therefore attempts to auto-detect old broken kernels > + * so that they still work on newer QEMU as they did on old > + * QEMU. Since we now use the correct (ie matching-hardware) > + * IRQ mapping we write a definitely different value to a > + * PCI_INTERRUPT_LINE register to tell QEMU that we expect > + * real hardware behaviour and it need not be backwards > + * compatible for us. This write is harmless on real hardware. > + */ > + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); > + > + /* > * Do not to map Versatile FPGA PCI device into memory space > */ > pci_slot_ignore |= (1 << myslot); > > I appreciate that QEMU-specific code in the kernel is a bit ugly, but > (a) 99.9% of the people running this code are going to be running it on QEMU > (b) the bugs in this area have been extremely long-standing in both > the kernel and QEMU and so there are a lot of legacy kernel images > out there that worked just fine with QEMU > (c) it's rather less code than I have in QEMU as the QEMU-side part > of this backwards-compatibility autodetection. > > (Without this line QEMU will guess whether the kernel is broken > or not and will get it right most but not necessarily all of the time.) > Might make sense, but I think it should be a separate patch. If I understand correctly, my patch fixes the SCSI problem. Is that correct ? If so, can we get it applied to mainline ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 17:54 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 17:54 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > > Patch tested and working with qemu 1.5.2, using the configuration file > > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > > OK, I tested this on PB926+PCI backplane hardware, and it is > definitely better than current mainline, in that the test USB > card that I have no longer causes the kernel to generate this sort of > backtrace: > Do you mean my patch fixes the traceback below as a side effect ? Would be great ... it would be one more reason to get it applied. > ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver > ehci-pci: EHCI PCI platform driver > ehci-pci 0000:00:1e.2: EHCI Host Controller > ehci-pci 0000:00:1e.2: new USB bus registered, assigned bus number 1 > ehci-pci 0000:00:1e.2: irq 91, io mem 0x50002000 > ehci-pci 0000:00:1e.2: USB 2.0 started, EHCI 1.00 > usb usb1: New USB device found, idVendor=1d6b, idProduct=0002 > usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 > usb usb1: Product: EHCI Host Controller > usb usb1: Manufacturer: Linux 3.10.0+ ehci_hcd > usb usb1: SerialNumber: 0000:00:1e.2 > hub 1-0:1.0: USB hub found > hub 1-0:1.0: 3 ports detected > ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver > ohci-pci: OHCI PCI platform driver > ohci-pci 0000:00:1e.0: OHCI PCI host controller > ohci-pci 0000:00:1e.0: new USB bus registered, assigned bus number 2 > irq 93: nobody cared (try booting with the "irqpoll" option) > CPU: 0 PID: 1 Comm: swapper Not tainted 3.10.0+ #9 > [<c00187d4>] (unwind_backtrace+0x0/0xf0) from [<c0015b48>] > (show_stack+0x10/0x14) > [<c0015b48>] (show_stack+0x10/0x14) from [<c0054cac>] > (__report_bad_irq+0x24/0xb8) > [<c0054cac>] (__report_bad_irq+0x24/0xb8) from [<c005511c>] > (note_interrupt+0x1cc/0x230) > [<c005511c>] (note_interrupt+0x1cc/0x230) from [<c005363c>] > (handle_irq_event_percpu+0xac/0x1c4) > [<c005363c>] (handle_irq_event_percpu+0xac/0x1c4) from [<c005377c>] > (handle_irq_event+0x28/0x38) > [<c005377c>] (handle_irq_event+0x28/0x38) from [<c00558c8>] > (handle_level_irq+0x80/0xd4) > [<c00558c8>] (handle_level_irq+0x80/0xd4) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c016bf38>] > (fpga_irq_handle+0x3c/0x50) > [<c016bf38>] (fpga_irq_handle+0x3c/0x50) from [<c0052fb4>] > (generic_handle_irq+0x2c/0x40) > [<c0052fb4>] (generic_handle_irq+0x2c/0x40) from [<c0013e8c>] > (handle_IRQ+0x30/0x84) > [<c0013e8c>] (handle_IRQ+0x30/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829cc8 to 0xc7829d10) > 9cc0: 00000001 0000000a 00000100 20000013 00000002 00000024 > 9ce0: c7828000 c0476980 3fb96c1c c0443950 c04693c0 00000001 c0456a50 c7829d10 > 9d00: c0025f38 c0025fa8 20000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0025fa8>] (__do_softirq+0x80/0x1b4) > [<c0025fa8>] (__do_softirq+0x80/0x1b4) from [<c00263a4>] (irq_exit+0x54/0x90) > [<c00263a4>] (irq_exit+0x54/0x90) from [<c0013e90>] (handle_IRQ+0x34/0x84) > [<c0013e90>] (handle_IRQ+0x34/0x84) from [<c0008750>] (vic_handle_irq+0x5c/0x9c) > [<c0008750>] (vic_handle_irq+0x5c/0x9c) from [<c00165c0>] (__irq_svc+0x40/0x4c) > Exception stack(0xc7829d80 to 0xc7829dc8) > 9d80: 00000000 0000005d 20000000 00000000 c79bb7e0 c0446990 60000013 c79c0000 > 9da0: 0000005d 00000000 c04469c4 00000001 00000000 c7829dc8 c00555c8 c0054460 > 9dc0: 40000013 ffffffff > [<c00165c0>] (__irq_svc+0x40/0x4c) from [<c0054460>] (__setup_irq+0x1f4/0x3f0) > [<c0054460>] (__setup_irq+0x1f4/0x3f0) from [<c00548ac>] > (request_threaded_irq+0xb4/0x138) > [<c00548ac>] (request_threaded_irq+0xb4/0x138) from [<c01fa7a8>] > (usb_add_hcd+0x4f0/0x6f0) > [<c01fa7a8>] (usb_add_hcd+0x4f0/0x6f0) from [<c0206bdc>] > (usb_hcd_pci_probe+0x200/0x36c) > [<c0206bdc>] (usb_hcd_pci_probe+0x200/0x36c) from [<c017467c>] > (pci_device_probe+0x68/0x90) > [<c017467c>] (pci_device_probe+0x68/0x90) from [<c01b3a80>] > (driver_probe_device+0x78/0x200) > [<c01b3a80>] (driver_probe_device+0x78/0x200) from [<c01b3c94>] > (__driver_attach+0x8c/0x90) > [<c01b3c94>] (__driver_attach+0x8c/0x90) from [<c01b2288>] > (bus_for_each_dev+0x58/0x88) > [<c01b2288>] (bus_for_each_dev+0x58/0x88) from [<c01b29e8>] > (bus_add_driver+0xd8/0x220) > [<c01b29e8>] (bus_add_driver+0xd8/0x220) from [<c01b4258>] > (driver_register+0x78/0x144) > [<c01b4258>] (driver_register+0x78/0x144) from [<c0410820>] > (do_one_initcall+0x94/0x154) > [<c0410820>] (do_one_initcall+0x94/0x154) from [<c04109cc>] > (kernel_init_freeable+0xec/0x1b0) > [<c04109cc>] (kernel_init_freeable+0xec/0x1b0) from [<c0323104>] > (kernel_init+0x8/0xe4) > [<c0323104>] (kernel_init+0x8/0xe4) from [<c00130b0>] (ret_from_fork+0x14/0x24) > handlers: > [<c01f7e48>] usb_hcd_irq > Disabling IRQ #93 > > However it still doesn't seem to reliably detect the USB harddisk > plugged into the card, so I think there may be further issues, possibly > some subset of those Arnd identified and fixed with this patch: > http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > Does it get better if you apply Arnd's patch ? > so I'd like to continue testing. > > The other thing this patch should (IMHO) have is the > line in pci_versatile_setup() which tells QEMU that the > kernel really does expect hardware-like behaviour: > > --- a/arch/arm/mach-versatile/pci.c > +++ b/arch/arm/mach-versatile/pci.c > @@ -295,6 +295,19 @@ int __init pci_versatile_setup(int nr, struct > pci_sys_data *sys) > __raw_writel(PHYS_OFFSET, local_pci_cfg_base + PCI_BASE_ADDRESS_2); > > /* > + * For many years the kernel and QEMU were symbiotically buggy > + * in that they both assumed the same broken IRQ mapping. > + * QEMU therefore attempts to auto-detect old broken kernels > + * so that they still work on newer QEMU as they did on old > + * QEMU. Since we now use the correct (ie matching-hardware) > + * IRQ mapping we write a definitely different value to a > + * PCI_INTERRUPT_LINE register to tell QEMU that we expect > + * real hardware behaviour and it need not be backwards > + * compatible for us. This write is harmless on real hardware. > + */ > + __raw_writel(0, VERSATILE_PCI_VIRT_BASE+PCI_INTERRUPT_LINE); > + > + /* > * Do not to map Versatile FPGA PCI device into memory space > */ > pci_slot_ignore |= (1 << myslot); > > I appreciate that QEMU-specific code in the kernel is a bit ugly, but > (a) 99.9% of the people running this code are going to be running it on QEMU > (b) the bugs in this area have been extremely long-standing in both > the kernel and QEMU and so there are a lot of legacy kernel images > out there that worked just fine with QEMU > (c) it's rather less code than I have in QEMU as the QEMU-side part > of this backwards-compatibility autodetection. > > (Without this line QEMU will guess whether the kernel is broken > or not and will get it right most but not necessarily all of the time.) > Might make sense, but I think it should be a separate patch. If I understand correctly, my patch fixes the SCSI problem. Is that correct ? If so, can we get it applied to mainline ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 17:54 ` Guenter Roeck (?) @ 2013-08-15 18:05 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 18:05 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > Patch tested and working with qemu 1.5.2, using the configuration file >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. >> >> OK, I tested this on PB926+PCI backplane hardware, and it is >> definitely better than current mainline, in that the test USB >> card that I have no longer causes the kernel to generate this sort of >> backtrace: >> > Do you mean my patch fixes the traceback below as a side effect ? > Would be great ... it would be one more reason to get it applied. Yes, exactly -- the kernel currently has the wrong irq mapping, which causes the traceback (ie h/w asserts irq 93 but the kernel is listening on something else). That the patch fixes this confirms that it is the behaviour of hardware as well as of QEMU. >> However it still doesn't seem to reliably detect the USB harddisk >> plugged into the card, so I think there may be further issues, possibly >> some subset of those Arnd identified and fixed with this patch: >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 >> > Does it get better if you apply Arnd's patch ? Arnd's patch is ancient and won't apply as is (due to intervening changes and also because some of the things it fixes were fixed in later patches); I'm currently trying to extract the relevant parts. If you want you can confirm that I/O port PCI access is broken on QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so the driver uses PCI IO rather than MMIO and you'll see QEMU's SCSI device doesn't work any more. >> so I'd like to continue testing. >> >> The other thing this patch should (IMHO) have is the >> line in pci_versatile_setup() which tells QEMU that the >> kernel really does expect hardware-like behaviour: >> (Without this line QEMU will guess whether the kernel is broken >> or not and will get it right most but not necessarily all of the time.) >> > Might make sense, but I think it should be a separate patch. It needs to go in the same patch, because a kernel with the fixed irq remapping must also tell QEMU it is fixed; if you split the two then at the point between the two patches the kernel is broken for bisection purposes. > If I understand correctly, my patch fixes the SCSI problem. > Is that correct ? If so, can we get it applied to mainline ? I'd rather get to a point where I have the hardware definitely completely working first. There's no real hurry, this has been broken for months and months. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 18:05 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 18:05 UTC (permalink / raw) To: linux-arm-kernel On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > Patch tested and working with qemu 1.5.2, using the configuration file >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. >> >> OK, I tested this on PB926+PCI backplane hardware, and it is >> definitely better than current mainline, in that the test USB >> card that I have no longer causes the kernel to generate this sort of >> backtrace: >> > Do you mean my patch fixes the traceback below as a side effect ? > Would be great ... it would be one more reason to get it applied. Yes, exactly -- the kernel currently has the wrong irq mapping, which causes the traceback (ie h/w asserts irq 93 but the kernel is listening on something else). That the patch fixes this confirms that it is the behaviour of hardware as well as of QEMU. >> However it still doesn't seem to reliably detect the USB harddisk >> plugged into the card, so I think there may be further issues, possibly >> some subset of those Arnd identified and fixed with this patch: >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 >> > Does it get better if you apply Arnd's patch ? Arnd's patch is ancient and won't apply as is (due to intervening changes and also because some of the things it fixes were fixed in later patches); I'm currently trying to extract the relevant parts. If you want you can confirm that I/O port PCI access is broken on QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so the driver uses PCI IO rather than MMIO and you'll see QEMU's SCSI device doesn't work any more. >> so I'd like to continue testing. >> >> The other thing this patch should (IMHO) have is the >> line in pci_versatile_setup() which tells QEMU that the >> kernel really does expect hardware-like behaviour: >> (Without this line QEMU will guess whether the kernel is broken >> or not and will get it right most but not necessarily all of the time.) >> > Might make sense, but I think it should be a separate patch. It needs to go in the same patch, because a kernel with the fixed irq remapping must also tell QEMU it is fixed; if you split the two then at the point between the two patches the kernel is broken for bisection purposes. > If I understand correctly, my patch fixes the SCSI problem. > Is that correct ? If so, can we get it applied to mainline ? I'd rather get to a point where I have the hardware definitely completely working first. There's no real hurry, this has been broken for months and months. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 18:05 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 18:05 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: >> > Patch tested and working with qemu 1.5.2, using the configuration file >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. >> >> OK, I tested this on PB926+PCI backplane hardware, and it is >> definitely better than current mainline, in that the test USB >> card that I have no longer causes the kernel to generate this sort of >> backtrace: >> > Do you mean my patch fixes the traceback below as a side effect ? > Would be great ... it would be one more reason to get it applied. Yes, exactly -- the kernel currently has the wrong irq mapping, which causes the traceback (ie h/w asserts irq 93 but the kernel is listening on something else). That the patch fixes this confirms that it is the behaviour of hardware as well as of QEMU. >> However it still doesn't seem to reliably detect the USB harddisk >> plugged into the card, so I think there may be further issues, possibly >> some subset of those Arnd identified and fixed with this patch: >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 >> > Does it get better if you apply Arnd's patch ? Arnd's patch is ancient and won't apply as is (due to intervening changes and also because some of the things it fixes were fixed in later patches); I'm currently trying to extract the relevant parts. If you want you can confirm that I/O port PCI access is broken on QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so the driver uses PCI IO rather than MMIO and you'll see QEMU's SCSI device doesn't work any more. >> so I'd like to continue testing. >> >> The other thing this patch should (IMHO) have is the >> line in pci_versatile_setup() which tells QEMU that the >> kernel really does expect hardware-like behaviour: >> (Without this line QEMU will guess whether the kernel is broken >> or not and will get it right most but not necessarily all of the time.) >> > Might make sense, but I think it should be a separate patch. It needs to go in the same patch, because a kernel with the fixed irq remapping must also tell QEMU it is fixed; if you split the two then at the point between the two patches the kernel is broken for bisection purposes. > If I understand correctly, my patch fixes the SCSI problem. > Is that correct ? If so, can we get it applied to mainline ? I'd rather get to a point where I have the hardware definitely completely working first. There's no real hurry, this has been broken for months and months. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 18:05 ` Peter Maydell (?) @ 2013-08-15 18:39 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 18:39 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > > > If I understand correctly, my patch fixes the SCSI problem. > > Is that correct ? If so, can we get it applied to mainline ? > > I'd rather get to a point where I have the hardware definitely > completely working first. There's no real hurry, this has been > broken for months and months. > Ok with me, if it doesn't get lost. Until it gets fixed, arm status on 3.10 kernels will show as "failed" for qemu test runs. Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 18:39 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 18:39 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > > > If I understand correctly, my patch fixes the SCSI problem. > > Is that correct ? If so, can we get it applied to mainline ? > > I'd rather get to a point where I have the hardware definitely > completely working first. There's no real hurry, this has been > broken for months and months. > Ok with me, if it doesn't get lost. Until it gets fixed, arm status on 3.10 kernels will show as "failed" for qemu test runs. Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 18:39 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 18:39 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > > > If I understand correctly, my patch fixes the SCSI problem. > > Is that correct ? If so, can we get it applied to mainline ? > > I'd rather get to a point where I have the hardware definitely > completely working first. There's no real hurry, this has been > broken for months and months. > Ok with me, if it doesn't get lost. Until it gets fixed, arm status on 3.10 kernels will show as "failed" for qemu test runs. Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 18:05 ` Peter Maydell (?) @ 2013-08-15 20:50 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 20:50 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > Thinking about it - is that really true ? My image with the patch applied works just fine under qemu 1.5.2, and unless I am missing something it won't work with qemu 1.4 anyway. So what exactly is broken ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 20:50 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 20:50 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > Thinking about it - is that really true ? My image with the patch applied works just fine under qemu 1.5.2, and unless I am missing something it won't work with qemu 1.4 anyway. So what exactly is broken ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 20:50 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 20:50 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: > On 15 August 2013 18:54, Guenter Roeck <linux@roeck-us.net> wrote: > > On Thu, Aug 15, 2013 at 05:45:42PM +0100, Peter Maydell wrote: > >> On 13 August 2013 04:40, Guenter Roeck <linux@roeck-us.net> wrote: > >> > Patch tested and working with qemu 1.5.2, using the configuration file > >> > from the yocto project. Patch applied on top of kernel version 3.11-rc5. > >> > >> OK, I tested this on PB926+PCI backplane hardware, and it is > >> definitely better than current mainline, in that the test USB > >> card that I have no longer causes the kernel to generate this sort of > >> backtrace: > >> > > Do you mean my patch fixes the traceback below as a side effect ? > > Would be great ... it would be one more reason to get it applied. > > Yes, exactly -- the kernel currently has the wrong irq mapping, > which causes the traceback (ie h/w asserts irq 93 but the kernel > is listening on something else). That the patch fixes this confirms > that it is the behaviour of hardware as well as of QEMU. > > >> However it still doesn't seem to reliably detect the USB harddisk > >> plugged into the card, so I think there may be further issues, possibly > >> some subset of those Arnd identified and fixed with this patch: > >> http://permalink.gmane.org/gmane.linux.ports.arm.kernel/93397 > >> > > Does it get better if you apply Arnd's patch ? > > Arnd's patch is ancient and won't apply as is (due to intervening > changes and also because some of the things it fixes were fixed > in later patches); I'm currently trying to extract the relevant parts. > > If you want you can confirm that I/O port PCI access is broken on > QEMU too -- disable CONFIG_SCSI_SYM53C8XX_MMIO so > the driver uses PCI IO rather than MMIO and you'll see QEMU's > SCSI device doesn't work any more. > > >> so I'd like to continue testing. > >> > >> The other thing this patch should (IMHO) have is the > >> line in pci_versatile_setup() which tells QEMU that the > >> kernel really does expect hardware-like behaviour: > > >> (Without this line QEMU will guess whether the kernel is broken > >> or not and will get it right most but not necessarily all of the time.) > >> > > Might make sense, but I think it should be a separate patch. > > It needs to go in the same patch, because a kernel with the fixed > irq remapping must also tell QEMU it is fixed; if you split the > two then at the point between the two patches the kernel is > broken for bisection purposes. > Thinking about it - is that really true ? My image with the patch applied works just fine under qemu 1.5.2, and unless I am missing something it won't work with qemu 1.4 anyway. So what exactly is broken ? Thanks, Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 20:50 ` Guenter Roeck (?) @ 2013-08-15 21:49 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 21:49 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >> It needs to go in the same patch, because a kernel with the fixed >> irq remapping must also tell QEMU it is fixed; if you split the >> two then at the point between the two patches the kernel is >> broken for bisection purposes. >> > Thinking about it - is that really true ? My image with the > patch applied works just fine under qemu 1.5.2, and unless > I am missing something it won't work with qemu 1.4 anyway. > So what exactly is broken ? You're OK unless the kernel happens to pick the same interrupt number to write to PCI_INTERRUPT_LINE as one of the previous broken kernel versions did (in which case QEMU will incorrectly assume you're a broken kernel). This can't happen with the way the kernel is currently picking interrupt numbers (ie with a straightforward relationship between h/w irqs and values written), but as I understand from Arnd there is a plan to move to a different approach ("sparse irqs") at which point this won't hold: http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html So it's better for the kernel to make sure it gets the behaviour it wants rather than getting unpleasant surprises later. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 21:49 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 21:49 UTC (permalink / raw) To: linux-arm-kernel On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >> It needs to go in the same patch, because a kernel with the fixed >> irq remapping must also tell QEMU it is fixed; if you split the >> two then at the point between the two patches the kernel is >> broken for bisection purposes. >> > Thinking about it - is that really true ? My image with the > patch applied works just fine under qemu 1.5.2, and unless > I am missing something it won't work with qemu 1.4 anyway. > So what exactly is broken ? You're OK unless the kernel happens to pick the same interrupt number to write to PCI_INTERRUPT_LINE as one of the previous broken kernel versions did (in which case QEMU will incorrectly assume you're a broken kernel). This can't happen with the way the kernel is currently picking interrupt numbers (ie with a straightforward relationship between h/w irqs and values written), but as I understand from Arnd there is a plan to move to a different approach ("sparse irqs") at which point this won't hold: http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html So it's better for the kernel to make sure it gets the behaviour it wants rather than getting unpleasant surprises later. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 21:49 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 21:49 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: > On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >> It needs to go in the same patch, because a kernel with the fixed >> irq remapping must also tell QEMU it is fixed; if you split the >> two then at the point between the two patches the kernel is >> broken for bisection purposes. >> > Thinking about it - is that really true ? My image with the > patch applied works just fine under qemu 1.5.2, and unless > I am missing something it won't work with qemu 1.4 anyway. > So what exactly is broken ? You're OK unless the kernel happens to pick the same interrupt number to write to PCI_INTERRUPT_LINE as one of the previous broken kernel versions did (in which case QEMU will incorrectly assume you're a broken kernel). This can't happen with the way the kernel is currently picking interrupt numbers (ie with a straightforward relationship between h/w irqs and values written), but as I understand from Arnd there is a plan to move to a different approach ("sparse irqs") at which point this won't hold: http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html So it's better for the kernel to make sure it gets the behaviour it wants rather than getting unpleasant surprises later. -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 21:49 ` Peter Maydell (?) @ 2013-08-15 22:18 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 22:18 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 08/15/2013 02:49 PM, Peter Maydell wrote: > On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: >> On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >>> It needs to go in the same patch, because a kernel with the fixed >>> irq remapping must also tell QEMU it is fixed; if you split the >>> two then at the point between the two patches the kernel is >>> broken for bisection purposes. >>> >> Thinking about it - is that really true ? My image with the >> patch applied works just fine under qemu 1.5.2, and unless >> I am missing something it won't work with qemu 1.4 anyway. >> So what exactly is broken ? > > You're OK unless the kernel happens to pick the same interrupt > number to write to PCI_INTERRUPT_LINE as one of the previous > broken kernel versions did (in which case QEMU will incorrectly > assume you're a broken kernel). This can't happen with the way > the kernel is currently picking interrupt numbers (ie with a > straightforward relationship between h/w irqs and values written), > but as I understand from Arnd there is a plan to move to a > different approach ("sparse irqs") at which point this won't hold: > http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html > So it's better for the kernel to make sure it gets the > behaviour it wants rather than getting unpleasant surprises > later. > But doesn't that mean that there is _currently_ no problem ? If so, we can introduce the additional code when the problem really shows up. Being Preemptive is good, but if it is not really needed today I would rather have today's problems resolved and bother about tomorrow's when they show up. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 22:18 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 22:18 UTC (permalink / raw) To: linux-arm-kernel On 08/15/2013 02:49 PM, Peter Maydell wrote: > On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: >> On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >>> It needs to go in the same patch, because a kernel with the fixed >>> irq remapping must also tell QEMU it is fixed; if you split the >>> two then at the point between the two patches the kernel is >>> broken for bisection purposes. >>> >> Thinking about it - is that really true ? My image with the >> patch applied works just fine under qemu 1.5.2, and unless >> I am missing something it won't work with qemu 1.4 anyway. >> So what exactly is broken ? > > You're OK unless the kernel happens to pick the same interrupt > number to write to PCI_INTERRUPT_LINE as one of the previous > broken kernel versions did (in which case QEMU will incorrectly > assume you're a broken kernel). This can't happen with the way > the kernel is currently picking interrupt numbers (ie with a > straightforward relationship between h/w irqs and values written), > but as I understand from Arnd there is a plan to move to a > different approach ("sparse irqs") at which point this won't hold: > http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html > So it's better for the kernel to make sure it gets the > behaviour it wants rather than getting unpleasant surprises > later. > But doesn't that mean that there is _currently_ no problem ? If so, we can introduce the additional code when the problem really shows up. Being Preemptive is good, but if it is not really needed today I would rather have today's problems resolved and bother about tomorrow's when they show up. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 22:18 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 22:18 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 08/15/2013 02:49 PM, Peter Maydell wrote: > On 15 August 2013 21:50, Guenter Roeck <linux@roeck-us.net> wrote: >> On Thu, Aug 15, 2013 at 07:05:22PM +0100, Peter Maydell wrote: >>> It needs to go in the same patch, because a kernel with the fixed >>> irq remapping must also tell QEMU it is fixed; if you split the >>> two then at the point between the two patches the kernel is >>> broken for bisection purposes. >>> >> Thinking about it - is that really true ? My image with the >> patch applied works just fine under qemu 1.5.2, and unless >> I am missing something it won't work with qemu 1.4 anyway. >> So what exactly is broken ? > > You're OK unless the kernel happens to pick the same interrupt > number to write to PCI_INTERRUPT_LINE as one of the previous > broken kernel versions did (in which case QEMU will incorrectly > assume you're a broken kernel). This can't happen with the way > the kernel is currently picking interrupt numbers (ie with a > straightforward relationship between h/w irqs and values written), > but as I understand from Arnd there is a plan to move to a > different approach ("sparse irqs") at which point this won't hold: > http://lists.gnu.org/archive/html/qemu-devel/2013-03/msg04579.html > So it's better for the kernel to make sure it gets the > behaviour it wants rather than getting unpleasant surprises > later. > But doesn't that mean that there is _currently_ no problem ? If so, we can introduce the additional code when the problem really shows up. Being Preemptive is good, but if it is not really needed today I would rather have today's problems resolved and bother about tomorrow's when they show up. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 22:18 ` Guenter Roeck (?) @ 2013-08-15 22:23 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 22:23 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > But doesn't that mean that there is _currently_ no problem ? If so, > we can introduce the additional code when the problem really shows up. > Being Preemptive is good, but if it is not really needed today > I would rather have today's problems resolved and bother about tomorrow's > when they show up. Conceptually the two parts go together: rely on correct irq routing, tell qemu we rely on correct irq routing. It's only one extra line... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 22:23 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 22:23 UTC (permalink / raw) To: linux-arm-kernel On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > But doesn't that mean that there is _currently_ no problem ? If so, > we can introduce the additional code when the problem really shows up. > Being Preemptive is good, but if it is not really needed today > I would rather have today's problems resolved and bother about tomorrow's > when they show up. Conceptually the two parts go together: rely on correct irq routing, tell qemu we rely on correct irq routing. It's only one extra line... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 22:23 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-15 22:23 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > But doesn't that mean that there is _currently_ no problem ? If so, > we can introduce the additional code when the problem really shows up. > Being Preemptive is good, but if it is not really needed today > I would rather have today's problems resolved and bother about tomorrow's > when they show up. Conceptually the two parts go together: rely on correct irq routing, tell qemu we rely on correct irq routing. It's only one extra line... -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 22:23 ` Peter Maydell (?) @ 2013-08-15 23:25 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 23:25 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On 08/15/2013 03:23 PM, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: >> But doesn't that mean that there is _currently_ no problem ? If so, >> we can introduce the additional code when the problem really shows up. >> Being Preemptive is good, but if it is not really needed today >> I would rather have today's problems resolved and bother about tomorrow's >> when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Ok if Russel accepts it ... Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 23:25 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 23:25 UTC (permalink / raw) To: linux-arm-kernel On 08/15/2013 03:23 PM, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: >> But doesn't that mean that there is _currently_ no problem ? If so, >> we can introduce the additional code when the problem really shows up. >> Being Preemptive is good, but if it is not really needed today >> I would rather have today's problems resolved and bother about tomorrow's >> when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Ok if Russel accepts it ... Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-15 23:25 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-15 23:25 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On 08/15/2013 03:23 PM, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: >> But doesn't that mean that there is _currently_ no problem ? If so, >> we can introduce the additional code when the problem really shows up. >> Being Preemptive is good, but if it is not really needed today >> I would rather have today's problems resolved and bother about tomorrow's >> when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Ok if Russel accepts it ... Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-15 22:23 ` Peter Maydell (?) @ 2013-08-19 15:26 ` Guenter Roeck -1 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-19 15:26 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, Paul Gortmaker, linux-kernel, linux-arm-kernel, QEMU Developers, Arnd Bergmann On Thu, Aug 15, 2013 at 11:23:58PM +0100, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > > But doesn't that mean that there is _currently_ no problem ? If so, > > we can introduce the additional code when the problem really shows up. > > Being Preemptive is good, but if it is not really needed today > > I would rather have today's problems resolved and bother about tomorrow's > > when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Possibly, but the lack of progress suggests that by tying both parts together we might get neither accepted. Old saying - surgery successful, patient dead. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-19 15:26 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-19 15:26 UTC (permalink / raw) To: linux-arm-kernel On Thu, Aug 15, 2013 at 11:23:58PM +0100, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > > But doesn't that mean that there is _currently_ no problem ? If so, > > we can introduce the additional code when the problem really shows up. > > Being Preemptive is good, but if it is not really needed today > > I would rather have today's problems resolved and bother about tomorrow's > > when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Possibly, but the lack of progress suggests that by tying both parts together we might get neither accepted. Old saying - surgery successful, patient dead. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-19 15:26 ` Guenter Roeck 0 siblings, 0 replies; 104+ messages in thread From: Guenter Roeck @ 2013-08-19 15:26 UTC (permalink / raw) To: Peter Maydell Cc: Russell King - ARM Linux, linux-kernel, QEMU Developers, Paul Gortmaker, Arnd Bergmann, linux-arm-kernel On Thu, Aug 15, 2013 at 11:23:58PM +0100, Peter Maydell wrote: > On 15 August 2013 23:18, Guenter Roeck <linux@roeck-us.net> wrote: > > But doesn't that mean that there is _currently_ no problem ? If so, > > we can introduce the additional code when the problem really shows up. > > Being Preemptive is good, but if it is not really needed today > > I would rather have today's problems resolved and bother about tomorrow's > > when they show up. > > Conceptually the two parts go together: rely on correct > irq routing, tell qemu we rely on correct irq routing. > It's only one extra line... > Possibly, but the lack of progress suggests that by tying both parts together we might get neither accepted. Old saying - surgery successful, patient dead. Guenter ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 0:40 ` [Qemu-devel] " Guenter Roeck (?) @ 2013-08-12 19:02 ` Paul Gortmaker -1 siblings, 0 replies; 104+ messages in thread From: Paul Gortmaker @ 2013-08-12 19:02 UTC (permalink / raw) To: Guenter Roeck Cc: Russell King - ARM Linux, linux-arm-kernel, linux-kernel, qemu-devel, peter.maydell On 13-08-11 08:40 PM, Guenter Roeck wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >>> Hi, >>> >>> trying to boot arm versatile images with qemu results in the following error >>> if I try to boot with a disk image. >>> >>> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >>> 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. >>> [...] >>> >>> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >>> (I did not check if/how earlier kernels are affected). >>> >>> Tracking this down shows that the problem is known and has been fixed with >>> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >>> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >>> >>> Would it be possible to submit this patch for inclusion into affected upstream kernels ? >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. >> >> Unfortunately, the PCI routing is totally undocumented, and as I understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. >> > > Maybe Paul can comment, as he wrote the patch. If I recall correctly, I'd showed the patch to Russell at the time (via IRC, I believe) and he'd told me essentially the same thing as the above paragraph, which is why I didn't put it in the patch system, and why the commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does (i.e. it is unclear what the real swizzle is). If docs appear that help clarify where the real issue is, then great. Paul. -- > > If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, > and qemu 1.5.2 from the qemu repository. > > Copying qemu-devel to increase the audience. > > Guenter > ^ permalink raw reply [flat|nested] 104+ messages in thread
* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 19:02 ` Paul Gortmaker 0 siblings, 0 replies; 104+ messages in thread From: Paul Gortmaker @ 2013-08-12 19:02 UTC (permalink / raw) To: linux-arm-kernel On 13-08-11 08:40 PM, Guenter Roeck wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >>> Hi, >>> >>> trying to boot arm versatile images with qemu results in the following error >>> if I try to boot with a disk image. >>> >>> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >>> 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. >>> [...] >>> >>> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >>> (I did not check if/how earlier kernels are affected). >>> >>> Tracking this down shows that the problem is known and has been fixed with >>> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >>> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >>> >>> Would it be possible to submit this patch for inclusion into affected upstream kernels ? >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. >> >> Unfortunately, the PCI routing is totally undocumented, and as I understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. >> > > Maybe Paul can comment, as he wrote the patch. If I recall correctly, I'd showed the patch to Russell at the time (via IRC, I believe) and he'd told me essentially the same thing as the above paragraph, which is why I didn't put it in the patch system, and why the commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does (i.e. it is unclear what the real swizzle is). If docs appear that help clarify where the real issue is, then great. Paul. -- > > If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, > and qemu 1.5.2 from the qemu repository. > > Copying qemu-devel to increase the audience. > > Guenter > ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 19:02 ` Paul Gortmaker 0 siblings, 0 replies; 104+ messages in thread From: Paul Gortmaker @ 2013-08-12 19:02 UTC (permalink / raw) To: Guenter Roeck Cc: peter.maydell, Russell King - ARM Linux, linux-kernel, linux-arm-kernel, qemu-devel On 13-08-11 08:40 PM, Guenter Roeck wrote: > On 08/11/2013 03:04 PM, Russell King - ARM Linux wrote: >> On Sun, Aug 11, 2013 at 08:54:43AM -0700, Guenter Roeck wrote: >>> Hi, >>> >>> trying to boot arm versatile images with qemu results in the following error >>> if I try to boot with a disk image. >>> >>> sym0: <895a> rev 0x0 at pci 0000:00:0d.0 irq 92 >>> 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. >>> [...] >>> >>> Yocto's 3.8 kernel images work, upstream kernels 3.8 and later fail >>> (I did not check if/how earlier kernels are affected). >>> >>> Tracking this down shows that the problem is known and has been fixed with >>> commit 351d1339 (arm: add dummy swizzle for versatile with qemu) in the >>> Yocto 3.8 kernel at git://git.yoctoproject.org/linux-yocto-3.8. >>> >>> Would it be possible to submit this patch for inclusion into affected upstream kernels ? >> >> It could be that it's qemu's PCI routing is wrong - it's not the first >> time that qemu has got something wrong. >> >> Unfortunately, the PCI routing is totally undocumented, and as I understand >> it, there's very few backplanes out there now that finding out their real >> routing is virtually impossible. I'm loathed to change it unless someone >> can point to a definitive source of information on this. >> > > Maybe Paul can comment, as he wrote the patch. If I recall correctly, I'd showed the patch to Russell at the time (via IRC, I believe) and he'd told me essentially the same thing as the above paragraph, which is why I didn't put it in the patch system, and why the commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does (i.e. it is unclear what the real swizzle is). If docs appear that help clarify where the real issue is, then great. Paul. -- > > If it helps, I tried with qemu 1.4.0 from Ubuntu 13.4, qemu 1.4.0 from Poky 1.4.0-1, > and qemu 1.5.2 from the qemu repository. > > Copying qemu-devel to increase the audience. > > Guenter > ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: SCSI bus failures with qemu-arm in kernel 3.8+ 2013-08-12 19:02 ` [Qemu-devel] " Paul Gortmaker (?) @ 2013-08-12 20:58 ` Peter Maydell -1 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:58 UTC (permalink / raw) To: Paul Gortmaker Cc: Guenter Roeck, Russell King - ARM Linux, linux-arm-kernel, linux-kernel, qemu-devel On 12 August 2013 20:02, Paul Gortmaker <paul.gortmaker@windriver.com> wrote: > > If I recall correctly, I'd showed the patch to Russell at the time (via > IRC, I believe) and he'd told me essentially the same thing as the above > paragraph, which is why I didn't put it in the patch system, and why the > commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does > (i.e. it is unclear what the real swizzle is). That patch reads like "make the kernel work with old (pre 1.5) QEMU behaviour" (where every IRQ for every PCI card was always IRQ27). I'm committing to making QEMU continue to support that for backward compatibility, as well as to "work like hardware" (our autodetect hack is based on what the kernel writes to PCI_INTERRUPT_LINE), so in that sense it's a stable and well defined[*] thing to write to, but for mainline I imagine the kernel will want to just go for the 'work on real h/w' approach. [*] by which I mean "not written down outside the QEMU source code but I will write it up if you need it" :-) -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:58 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:58 UTC (permalink / raw) To: linux-arm-kernel On 12 August 2013 20:02, Paul Gortmaker <paul.gortmaker@windriver.com> wrote: > > If I recall correctly, I'd showed the patch to Russell at the time (via > IRC, I believe) and he'd told me essentially the same thing as the above > paragraph, which is why I didn't put it in the patch system, and why the > commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does > (i.e. it is unclear what the real swizzle is). That patch reads like "make the kernel work with old (pre 1.5) QEMU behaviour" (where every IRQ for every PCI card was always IRQ27). I'm committing to making QEMU continue to support that for backward compatibility, as well as to "work like hardware" (our autodetect hack is based on what the kernel writes to PCI_INTERRUPT_LINE), so in that sense it's a stable and well defined[*] thing to write to, but for mainline I imagine the kernel will want to just go for the 'work on real h/w' approach. [*] by which I mean "not written down outside the QEMU source code but I will write it up if you need it" :-) -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
* Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ @ 2013-08-12 20:58 ` Peter Maydell 0 siblings, 0 replies; 104+ messages in thread From: Peter Maydell @ 2013-08-12 20:58 UTC (permalink / raw) To: Paul Gortmaker Cc: qemu-devel, Russell King - ARM Linux, linux-arm-kernel, Guenter Roeck, linux-kernel On 12 August 2013 20:02, Paul Gortmaker <paul.gortmaker@windriver.com> wrote: > > If I recall correctly, I'd showed the patch to Russell at the time (via > IRC, I believe) and he'd told me essentially the same thing as the above > paragraph, which is why I didn't put it in the patch system, and why the > commit log of the yocto patch (http://goo.gl/riEZXY) reads as it does > (i.e. it is unclear what the real swizzle is). That patch reads like "make the kernel work with old (pre 1.5) QEMU behaviour" (where every IRQ for every PCI card was always IRQ27). I'm committing to making QEMU continue to support that for backward compatibility, as well as to "work like hardware" (our autodetect hack is based on what the kernel writes to PCI_INTERRUPT_LINE), so in that sense it's a stable and well defined[*] thing to write to, but for mainline I imagine the kernel will want to just go for the 'work on real h/w' approach. [*] by which I mean "not written down outside the QEMU source code but I will write it up if you need it" :-) -- PMM ^ permalink raw reply [flat|nested] 104+ messages in thread
end of thread, other threads:[~2013-08-19 15:26 UTC | newest] Thread overview: 104+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-08-11 15:54 SCSI bus failures with qemu-arm in kernel 3.8+ Guenter Roeck 2013-08-11 15:54 ` Guenter Roeck 2013-08-11 22:04 ` Russell King - ARM Linux 2013-08-11 22:04 ` Russell King - ARM Linux 2013-08-12 0:40 ` Guenter Roeck 2013-08-12 0:40 ` Guenter Roeck 2013-08-12 0:40 ` [Qemu-devel] " Guenter Roeck 2013-08-12 16:24 ` Peter Maydell 2013-08-12 16:24 ` Peter Maydell 2013-08-12 16:24 ` Peter Maydell 2013-08-12 16:45 ` Russell King - ARM Linux 2013-08-12 16:45 ` Russell King - ARM Linux 2013-08-12 16:45 ` Russell King - ARM Linux 2013-08-12 17:33 ` Peter Maydell 2013-08-12 17:33 ` Peter Maydell 2013-08-12 17:33 ` Peter Maydell 2013-08-12 20:06 ` Russell King - ARM Linux 2013-08-12 20:06 ` Russell King - ARM Linux 2013-08-12 20:06 ` Russell King - ARM Linux 2013-08-12 20:49 ` Peter Maydell 2013-08-12 20:49 ` Peter Maydell 2013-08-12 20:49 ` Peter Maydell 2013-08-12 21:21 ` Russell King - ARM Linux 2013-08-12 21:21 ` Russell King - ARM Linux 2013-08-12 21:21 ` Russell King - ARM Linux 2013-08-12 21:36 ` Peter Maydell 2013-08-12 21:36 ` Peter Maydell 2013-08-12 21:36 ` Peter Maydell 2013-08-12 22:12 ` Russell King - ARM Linux 2013-08-12 22:12 ` Russell King - ARM Linux 2013-08-12 22:12 ` Russell King - ARM Linux 2013-08-12 22:48 ` Guenter Roeck 2013-08-12 22:48 ` Guenter Roeck 2013-08-12 22:48 ` Guenter Roeck 2013-08-12 23:04 ` Guenter Roeck 2013-08-12 23:04 ` Guenter Roeck 2013-08-12 23:04 ` Guenter Roeck 2013-08-14 10:33 ` Russell King - ARM Linux 2013-08-14 10:33 ` Russell King - ARM Linux 2013-08-14 10:33 ` Russell King - ARM Linux 2013-08-14 12:44 ` Peter Maydell 2013-08-14 12:44 ` Peter Maydell 2013-08-14 12:44 ` Peter Maydell 2013-08-14 12:49 ` Russell King - ARM Linux 2013-08-14 12:49 ` Russell King - ARM Linux 2013-08-14 12:49 ` Russell King - ARM Linux 2013-08-14 12:56 ` Peter Maydell 2013-08-14 12:56 ` Peter Maydell 2013-08-14 12:56 ` Peter Maydell 2013-08-14 14:41 ` Guenter Roeck 2013-08-14 14:41 ` Guenter Roeck 2013-08-14 14:41 ` Guenter Roeck 2013-08-14 15:26 ` [Qemu-devel] memory reads and writes Herbei Dacian 2013-08-12 17:48 ` [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+ Peter Maydell 2013-08-12 17:48 ` Peter Maydell 2013-08-12 17:48 ` Peter Maydell 2013-08-13 8:37 ` Rob Landley 2013-08-13 8:37 ` Rob Landley 2013-08-13 8:37 ` Rob Landley 2013-08-13 9:12 ` Peter Maydell 2013-08-13 9:12 ` Peter Maydell 2013-08-13 9:12 ` Peter Maydell 2013-08-13 11:30 ` Russell King - ARM Linux 2013-08-13 11:30 ` Russell King - ARM Linux 2013-08-13 11:30 ` Russell King - ARM Linux 2013-08-13 3:40 ` Guenter Roeck 2013-08-13 3:40 ` Guenter Roeck 2013-08-13 3:40 ` Guenter Roeck 2013-08-15 16:45 ` Peter Maydell 2013-08-15 16:45 ` Peter Maydell 2013-08-15 16:45 ` Peter Maydell 2013-08-15 17:54 ` Guenter Roeck 2013-08-15 17:54 ` Guenter Roeck 2013-08-15 17:54 ` Guenter Roeck 2013-08-15 18:05 ` Peter Maydell 2013-08-15 18:05 ` Peter Maydell 2013-08-15 18:05 ` Peter Maydell 2013-08-15 18:39 ` Guenter Roeck 2013-08-15 18:39 ` Guenter Roeck 2013-08-15 18:39 ` Guenter Roeck 2013-08-15 20:50 ` Guenter Roeck 2013-08-15 20:50 ` Guenter Roeck 2013-08-15 20:50 ` Guenter Roeck 2013-08-15 21:49 ` Peter Maydell 2013-08-15 21:49 ` Peter Maydell 2013-08-15 21:49 ` Peter Maydell 2013-08-15 22:18 ` Guenter Roeck 2013-08-15 22:18 ` Guenter Roeck 2013-08-15 22:18 ` Guenter Roeck 2013-08-15 22:23 ` Peter Maydell 2013-08-15 22:23 ` Peter Maydell 2013-08-15 22:23 ` Peter Maydell 2013-08-15 23:25 ` Guenter Roeck 2013-08-15 23:25 ` Guenter Roeck 2013-08-15 23:25 ` Guenter Roeck 2013-08-19 15:26 ` Guenter Roeck 2013-08-19 15:26 ` Guenter Roeck 2013-08-19 15:26 ` Guenter Roeck 2013-08-12 19:02 ` Paul Gortmaker 2013-08-12 19:02 ` Paul Gortmaker 2013-08-12 19:02 ` [Qemu-devel] " Paul Gortmaker 2013-08-12 20:58 ` Peter Maydell 2013-08-12 20:58 ` Peter Maydell 2013-08-12 20:58 ` [Qemu-devel] " Peter Maydell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.