From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N9Pb2-0008Fo-O1 for qemu-devel@nongnu.org; Sat, 14 Nov 2009 15:51:48 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N9Pay-0008DN-5g for qemu-devel@nongnu.org; Sat, 14 Nov 2009 15:51:48 -0500 Received: from [199.232.76.173] (port=50885 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N9Pax-0008DC-RK for qemu-devel@nongnu.org; Sat, 14 Nov 2009 15:51:43 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:46567) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N9Paw-0003Cv-PV for qemu-devel@nongnu.org; Sat, 14 Nov 2009 15:51:43 -0500 Received: by yxe26 with SMTP id 26so3708257yxe.4 for ; Sat, 14 Nov 2009 12:51:35 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <78FF0801-D8AA-4A6B-9238-3035301AA9C1@suse.de> References: <78FF0801-D8AA-4A6B-9238-3035301AA9C1@suse.de> From: Blue Swirl Date: Sat, 14 Nov 2009 22:51:15 +0200 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: ppc64 target broken List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org On Tue, Nov 10, 2009 at 8:04 PM, Alexander Graf 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=3D1, ns=3D1) on /pci@f2000000/pci@d/mac-io@10 > <4>OF: translating address: 00040000 > <6>OF: parent bus is pci (na=3D3, ns=3D2) on /pci@f2000000/pci@d > <6>OF: walking ranges... > <6>OF: default map, cp=3D0, s=3D80000, da=3D40000 > <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=3D3, ns=3D2) 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=3D1, ns=3D1) 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=3D1024 NUMA PowerMac > <4>Modules linked in: > <4>Supported: Yes > <4>NIP: c0000000007449a8 LR: c0000000007449a0 CTR: 0000000000000000 > <4>REGS: c0000000009a3b40 TRAP: 0700 =C2=A0 Not tainted =C2=A0(2.6.27.7-k= vm) > <4>MSR: 8000000000021032 =C2=A0CR: 22000088 =C2=A0XER: 2000000= 0 > <4>TASK =3D 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 MP= IC > device. I'm not sure. One previously working revision > (9d479c119b42b8a548f8d79a8e5a1c1ce2932d91) gives the following guest trac= e: > > <6>OF: ** translation for device > /pci@5800/mac-io@f/interrupt-controller@40000 ** > <6>OF: bus is default (na=3D1, ns=3D1) on /pci@5800/mac-io@f > <4>OF: translating address: 00040000 > <6>OF: parent bus is pci (na=3D3, ns=3D2) on /pci@5800 > <6>OF: walking ranges... > <6>OF: default map, cp=3D0, s=3D80000, da=3D40000 > <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=3D1, ns=3D1) 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.