* [Qemu-devel] Re: ppc64 target broken
2009-11-10 18:04 [Qemu-devel] ppc64 target broken Alexander Graf
@ 2009-11-10 21:00 ` Blue Swirl
2009-11-11 13:17 ` [Qemu-devel] " Laurent Vivier
2009-11-14 20:51 ` [Qemu-devel] " Blue Swirl
2 siblings, 0 replies; 5+ messages in thread
From: Blue Swirl @ 2009-11-10 21:00 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel
On Tue, Nov 10, 2009 at 8:04 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi list,
>
> For quite some time the PPC64 target (-M mac99 -cpu 970fx) is broken in
> early init code:
>
> <6>OF: ** translation for device
> /pci@f2000000/pci@d/mac-io@10/interrupt-controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@f2000000/pci@d/mac-io@10
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000/pci@d
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82008010 00000000 c0000000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82008010 00000000 c0040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000 00000000 00000000
> <6>OF: with offset: c0040000
> <4>OF: one level translation: 00000000 00000000 c0040000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: walking ranges...
> <6>OF: not found !
> <0>------------[ cut here ]------------
> <2>kernel BUG at arch/powerpc/platforms/powermac/pic.c:530!
> <4>Oops: Exception in kernel mode, sig: 5 [#1]
> <4>SMP NR_CPUS=1024 NUMA PowerMac
> <4>Modules linked in:
> <4>Supported: Yes
> <4>NIP: c0000000007449a8 LR: c0000000007449a0 CTR: 0000000000000000
> <4>REGS: c0000000009a3b40 TRAP: 0700 Not tainted (2.6.27.7-kvm)
> <4>MSR: 8000000000021032 <ME,IR,DR> CR: 22000088 XER: 20000000
> <4>TASK = c0000000008e83c0[0] 'swapper' THREAD: c0000000009a0000 CPU: 0
> <6>GPR00: c0000000007449a0 c0000000009a3dc0 c0000000009952c0
> 0000000000000001
> <6>GPR04: c00000000092fd20 ffffffffffffffff 0000000000000010
> d000080080107230
> <6>GPR08: c0000000008c4488 c00000000fffc400 0000000000000000
> 0000000000000f72
> <6>GPR12: 0000000022000082 c000000000a62c80 c000000000773638
> c00000000068b9b0
> <6>GPR16: 0000000001773570 0000000000000000 c000000000773570
> 000000000f7fff20
> <6>GPR20: c000000000773588 c00000000068d02a c0000000007787d4
> 000000000f7fff20
> <6>GPR24: 0000000005483224 00000000000000bb c000000000ae77a8
> c000000000694bef
> <6>GPR28: c00000000fffebd0 0000000000000000 c000000000914868
> 0000000000000000
> <4>NIP [c0000000007449a8] .pmac_pic_init+0xec/0x1a8
> <4>LR [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> <4>Call Trace:
> <4>[c0000000009a3dc0] [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> (unreliable)
> <4>[c0000000009a3e60] [c00000000073503c] .init_IRQ+0x3c/0x54
> <4>[c0000000009a3ee0] [c000000000730a00] .start_kernel+0x254/0x554
> <4>[c0000000009a3f90] [c000000000008568] .start_here_common+0x3c/0x54
>
>
>
>
> So the problem seems to be the "ranges" property or the address of the MPIC
> device. I'm not sure. One previously working revision
> (9d479c119b42b8a548f8d79a8e5a1c1ce2932d91) gives the following guest trace:
>
> <6>OF: ** translation for device
> /pci@5800/mac-io@f/interrupt-controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@5800/mac-io@f
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@5800
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82007810 00000000 80880000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82007810 00000000 808c0000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000
> <6>OF: with offset: 808c0000
> <4>OF: one level translation: 808c0000
> <6>OF: reached root node
>
> As you can see there is only one pci host device.
> I don't see how the old offset would have matched the new "ranges"
> parameters of the pci@f2000000 device though:
>
> http://imagebin.org/71215
>
>
> So I'm really puzzled on this. When removing the "ranges" property of the
> pci@f20000000 (so we're on 1:1 translation) Linux breaks in the PCI
> detection code.
>
> The first commit where the mac99 worked with again at all is blue swirl's
> qdev conversion, so maybe he's got an idea?
Maybe macio device (106b:0022, not converted to qdev yet) is broken,
the mapped address is different.
Host bridge is somehow now 106b:001f vs. 106b:0020 in the old one and
VGA has a BAR6, but those could be OK. I kept the OpenBIOS version
fixed so only QEMU changes.
QEMU 0.10.0 monitor - type 'help' for more information
(qemu) info pci
Bus 0, device 11, function 0:
Host bridge: PCI device 106b:0020
Bus 0, device 12, function 0:
VGA controller: PCI device 1234:1111
BAR0: 32 bit memory at 0x80000000 [0x807fffff].
Bus 0, device 13, function 0:
Ethernet controller: PCI device 10ec:8029
IRQ 9.
BAR0: I/O at 0x0400 [0x04ff].
Bus 0, device 14, function 0:
IDE controller: PCI device 1095:0646
IRQ 10.
BAR0: I/O at 0x0500 [0x0507].
BAR1: I/O at 0x0580 [0x0583].
BAR2: I/O at 0x0600 [0x0607].
BAR3: I/O at 0x0680 [0x0683].
BAR4: I/O at 0x0700 [0x070f].
Bus 0, device 15, function 0:
Class ff00: PCI device 106b:0022
IRQ 11.
BAR0: 32 bit memory at 0x80800000 [0x8087ffff].
Bus 0, device 16, function 0:
USB controller: PCI device 106b:003f
IRQ 8.
BAR0: 32 bit memory at 0x80880000 [0x808800ff].
QEMU 0.11.50 monitor - type 'help' for more information
(qemu) info pci
Bus 0, device 11, function 0:
Host bridge: PCI device 106b:001f
id ""
Bus 0, device 12, function 0:
VGA controller: PCI device 1234:1111
BAR0: 32 bit prefetchable memory at 0x80000000 [0x807fffff].
BAR6: 32 bit prefetchable memory at 0xffffffffffffffff [0x0ffffffe].
id ""
Bus 0, device 13, function 0:
Host bridge: PCI device 106b:0020
id ""
Bus 0, device 14, function 0:
Ethernet controller: PCI device 10ec:8029
IRQ 10.
BAR0: I/O at 0x0400 [0x04ff].
id ""
Bus 0, device 15, function 0:
IDE controller: PCI device 1095:0646
IRQ 11.
BAR0: I/O at 0x0500 [0x0507].
BAR1: I/O at 0x0580 [0x0583].
BAR2: I/O at 0x0600 [0x0607].
BAR3: I/O at 0x0680 [0x0683].
BAR4: I/O at 0x0700 [0x070f].
id ""
Bus 0, device 16, function 0:
Class ff00: PCI device 106b:0022
IRQ 8.
BAR0: 32 bit memory at 0xa0000000 [0xa007ffff].
id ""
Bus 0, device 17, function 0:
USB controller: PCI device 106b:003f
IRQ 9.
BAR0: 32 bit memory at 0xa0080000 [0xa00800ff].
id ""
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Qemu-devel] ppc64 target broken
2009-11-10 18:04 [Qemu-devel] ppc64 target broken Alexander Graf
2009-11-10 21:00 ` [Qemu-devel] " Blue Swirl
@ 2009-11-11 13:17 ` Laurent Vivier
2009-11-13 18:07 ` Blue Swirl
2009-11-14 20:51 ` [Qemu-devel] " Blue Swirl
2 siblings, 1 reply; 5+ messages in thread
From: Laurent Vivier @ 2009-11-11 13:17 UTC (permalink / raw)
To: Alexander Graf; +Cc: Blue Swirl, qemu-devel
qemu-system-ppc is also broken.
A bisect gives me:
c169998802505c244b8bcad562633f29de7d74a4 is first bad commit
commit c169998802505c244b8bcad562633f29de7d74a4
Author: Glauber Costa <glommer@redhat.com>
Date: Thu Nov 5 16:05:15 2009 -0200
v3: don't call reset functions on cpu initialization
There is absolutely no need to call reset functions when initializing
devices. Since we are already registering them, calling qemu_system_reset()
should suffice. Actually, it is what happens when we reboot the machine,
and using the same process instead of a special case semantics will even
allow us to find bugs easier.
Furthermore, the fact that we initialize things like the cpu quite early,
leads to the need to introduce synchronization stuff like qemu_system_cond.
This patch removes it entirely. All we need to do is call qemu_system_reset()
only when we're already sure the system is up and running
I tested it with qemu (with and without io-thread) and qemu-kvm, and it
seems to be doing okay - although qemu-kvm uses a slightly different patch.
[ v2: user mode still needs cpu_reset, so put it in ifdef. ]
[ v3: leave qemu_system_cond for now. ]
Signed-off-by: Glauber Costa <glommer@redhat.com>
Signed-off-by: Blue Swirl <blauwirbel@gmail.com>
:040000 040000 0eb9d44c103057883acd6dcd76c306795bec4cca 8bd8c30125188ad9d346c953ccf2e56b1c289ebc M hw
:040000 040000 24f0e2cb42ae95c248fb6874797fa53fbc2b1cba 6dffa9f36e0350fd48fc5f4a5d4191c5a5cc6e26 M target-i386
:100644 100644 e57f58fea0df3ab4ade42fce4cf86d9d2a60a1e2 9031911c513eb2fc15564ec3cd37e8b274c65cc8 M vl.c
Le mardi 10 novembre 2009 à 19:04 +0100, Alexander Graf a écrit :
> Hi list,
>
> For quite some time the PPC64 target (-M mac99 -cpu 970fx) is broken
> in early init code:
>
> <6>OF: ** translation for device /pci@f2000000/pci@d/mac-io@10/
> interrupt-controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@f2000000/pci@d/mac-io@10
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000/pci@d
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82008010 00000000 c0000000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82008010 00000000 c0040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000 00000000 00000000
> <6>OF: with offset: c0040000
> <4>OF: one level translation: 00000000 00000000 c0040000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: walking ranges...
> <6>OF: not found !
> <0>------------[ cut here ]------------
> <2>kernel BUG at arch/powerpc/platforms/powermac/pic.c:530!
> <4>Oops: Exception in kernel mode, sig: 5 [#1]
> <4>SMP NR_CPUS=1024 NUMA PowerMac
> <4>Modules linked in:
> <4>Supported: Yes
> <4>NIP: c0000000007449a8 LR: c0000000007449a0 CTR: 0000000000000000
> <4>REGS: c0000000009a3b40 TRAP: 0700 Not tainted (2.6.27.7-kvm)
> <4>MSR: 8000000000021032 <ME,IR,DR> CR: 22000088 XER: 20000000
> <4>TASK = c0000000008e83c0[0] 'swapper' THREAD: c0000000009a0000 CPU: 0
> <6>GPR00: c0000000007449a0 c0000000009a3dc0 c0000000009952c0
> 0000000000000001
> <6>GPR04: c00000000092fd20 ffffffffffffffff 0000000000000010
> d000080080107230
> <6>GPR08: c0000000008c4488 c00000000fffc400 0000000000000000
> 0000000000000f72
> <6>GPR12: 0000000022000082 c000000000a62c80 c000000000773638
> c00000000068b9b0
> <6>GPR16: 0000000001773570 0000000000000000 c000000000773570
> 000000000f7fff20
> <6>GPR20: c000000000773588 c00000000068d02a c0000000007787d4
> 000000000f7fff20
> <6>GPR24: 0000000005483224 00000000000000bb c000000000ae77a8
> c000000000694bef
> <6>GPR28: c00000000fffebd0 0000000000000000 c000000000914868
> 0000000000000000
> <4>NIP [c0000000007449a8] .pmac_pic_init+0xec/0x1a8
> <4>LR [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> <4>Call Trace:
> <4>[c0000000009a3dc0] [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> (unreliable)
> <4>[c0000000009a3e60] [c00000000073503c] .init_IRQ+0x3c/0x54
> <4>[c0000000009a3ee0] [c000000000730a00] .start_kernel+0x254/0x554
> <4>[c0000000009a3f90] [c000000000008568] .start_here_common+0x3c/0x54
>
>
>
>
> So the problem seems to be the "ranges" property or the address of the
> MPIC device. I'm not sure. One previously working revision
> (9d479c119b42b8a548f8d79a8e5a1c1ce2932d91) gives the following guest
> trace:
>
> <6>OF: ** translation for device /pci@5800/mac-io@f/interrupt-
> controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@5800/mac-io@f
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@5800
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82007810 00000000 80880000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82007810 00000000 808c0000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000
> <6>OF: with offset: 808c0000
> <4>OF: one level translation: 808c0000
> <6>OF: reached root node
>
> As you can see there is only one pci host device.
> I don't see how the old offset would have matched the new "ranges"
> parameters of the pci@f2000000 device though:
>
> http://imagebin.org/71215
>
>
> So I'm really puzzled on this. When removing the "ranges" property of
> the pci@f20000000 (so we're on 1:1 translation) Linux breaks in the
> PCI detection code.
>
> The first commit where the mac99 worked with again at all is blue
> swirl's qdev conversion, so maybe he's got an idea?
>
>
> Thanks!
>
> Alex
>
>
--
--------------------- laurent@vivier.eu ----------------------
"Tout ce qui est impossible reste à accomplir" Jules Verne
"Things are only impossible until they're not" Jean-Luc Picard
^ permalink raw reply [flat|nested] 5+ messages in thread* [Qemu-devel] Re: ppc64 target broken
2009-11-10 18:04 [Qemu-devel] ppc64 target broken Alexander Graf
2009-11-10 21:00 ` [Qemu-devel] " Blue Swirl
2009-11-11 13:17 ` [Qemu-devel] " Laurent Vivier
@ 2009-11-14 20:51 ` Blue Swirl
2 siblings, 0 replies; 5+ messages in thread
From: Blue Swirl @ 2009-11-14 20:51 UTC (permalink / raw)
To: Alexander Graf; +Cc: qemu-devel
On Tue, Nov 10, 2009 at 8:04 PM, Alexander Graf <agraf@suse.de> wrote:
> Hi list,
>
> For quite some time the PPC64 target (-M mac99 -cpu 970fx) is broken in
> early init code:
>
> <6>OF: ** translation for device
> /pci@f2000000/pci@d/mac-io@10/interrupt-controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@f2000000/pci@d/mac-io@10
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000/pci@d
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82008010 00000000 c0000000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82008010 00000000 c0040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@f2000000
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000 00000000 00000000
> <6>OF: with offset: c0040000
> <4>OF: one level translation: 00000000 00000000 c0040000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: walking ranges...
> <6>OF: not found !
> <0>------------[ cut here ]------------
> <2>kernel BUG at arch/powerpc/platforms/powermac/pic.c:530!
> <4>Oops: Exception in kernel mode, sig: 5 [#1]
> <4>SMP NR_CPUS=1024 NUMA PowerMac
> <4>Modules linked in:
> <4>Supported: Yes
> <4>NIP: c0000000007449a8 LR: c0000000007449a0 CTR: 0000000000000000
> <4>REGS: c0000000009a3b40 TRAP: 0700 Not tainted (2.6.27.7-kvm)
> <4>MSR: 8000000000021032 <ME,IR,DR> CR: 22000088 XER: 20000000
> <4>TASK = c0000000008e83c0[0] 'swapper' THREAD: c0000000009a0000 CPU: 0
> <6>GPR00: c0000000007449a0 c0000000009a3dc0 c0000000009952c0
> 0000000000000001
> <6>GPR04: c00000000092fd20 ffffffffffffffff 0000000000000010
> d000080080107230
> <6>GPR08: c0000000008c4488 c00000000fffc400 0000000000000000
> 0000000000000f72
> <6>GPR12: 0000000022000082 c000000000a62c80 c000000000773638
> c00000000068b9b0
> <6>GPR16: 0000000001773570 0000000000000000 c000000000773570
> 000000000f7fff20
> <6>GPR20: c000000000773588 c00000000068d02a c0000000007787d4
> 000000000f7fff20
> <6>GPR24: 0000000005483224 00000000000000bb c000000000ae77a8
> c000000000694bef
> <6>GPR28: c00000000fffebd0 0000000000000000 c000000000914868
> 0000000000000000
> <4>NIP [c0000000007449a8] .pmac_pic_init+0xec/0x1a8
> <4>LR [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> <4>Call Trace:
> <4>[c0000000009a3dc0] [c0000000007449a0] .pmac_pic_init+0xe4/0x1a8
> (unreliable)
> <4>[c0000000009a3e60] [c00000000073503c] .init_IRQ+0x3c/0x54
> <4>[c0000000009a3ee0] [c000000000730a00] .start_kernel+0x254/0x554
> <4>[c0000000009a3f90] [c000000000008568] .start_here_common+0x3c/0x54
>
>
>
>
> So the problem seems to be the "ranges" property or the address of the MPIC
> device. I'm not sure. One previously working revision
> (9d479c119b42b8a548f8d79a8e5a1c1ce2932d91) gives the following guest trace:
>
> <6>OF: ** translation for device
> /pci@5800/mac-io@f/interrupt-controller@40000 **
> <6>OF: bus is default (na=1, ns=1) on /pci@5800/mac-io@f
> <4>OF: translating address: 00040000
> <6>OF: parent bus is pci (na=3, ns=2) on /pci@5800
> <6>OF: walking ranges...
> <6>OF: default map, cp=0, s=80000, da=40000
> <4>OF: parent translation for: 82007810 00000000 80880000
> <6>OF: with offset: 40000
> <4>OF: one level translation: 82007810 00000000 808c0000
> <6>OF: parent bus is default (na=1, ns=1) on /
> <6>OF: no ranges, 1:1 translation
> <4>OF: parent translation for: 00000000
> <6>OF: with offset: 808c0000
> <4>OF: one level translation: 808c0000
> <6>OF: reached root node
>
> As you can see there is only one pci host device.
> I don't see how the old offset would have matched the new "ranges"
> parameters of the pci@f2000000 device though:
>
> http://imagebin.org/71215
>
>
> So I'm really puzzled on this. When removing the "ranges" property of the
> pci@f20000000 (so we're on 1:1 translation) Linux breaks in the PCI
> detection code.
>
> The first commit where the mac99 worked with again at all is blue swirl's
> qdev conversion, so maybe he's got an idea?
FYI: 9391e4b8828a6ebcde843a2012f0fae4b601b302 was the last working commit.
^ permalink raw reply [flat|nested] 5+ messages in thread