SCSI bus failures with qemu-arm in kernel 3.8+

SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: SCSI bus failures with qemu-arm in kernel 3.8+

[Paul Gortmaker]

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
> 

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Paul Gortmaker]

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
> 

SCSI bus failures with qemu-arm in kernel 3.8+

[Paul Gortmaker]

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
> 

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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?

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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?

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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?

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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);

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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);

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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);

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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;
 }

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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;
 }

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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;
 }

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Rob Landley]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Rob Landley]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Rob Landley]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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.

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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...

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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...

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Russell King - ARM Linux]

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...

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] memory reads and writes

[Herbei Dacian]

[-- 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 --]

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Peter Maydell]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

Re: [Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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

[Qemu-devel] SCSI bus failures with qemu-arm in kernel 3.8+

[Guenter Roeck]

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