Date: Tue, 21 Jan 2014 12:15:21 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-hackers@freebsd.org Cc: David Shane Holden <dpejesh@yahoo.com> Subject: Re: Atom Board ACPI API MOPNV10J failing since 9.1 Message-ID: <201401211215.22021.jhb@freebsd.org> In-Reply-To: <lb518g$i3h$1@ger.gmane.org> References: <52CF850A.9060906@erdgeist.org> <201401140823.00259.jhb@freebsd.org> <lb518g$i3h$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, January 14, 2014 11:02:36 pm David Shane Holden wrote: > On 01/14/14 08:23, John Baldwin wrote: > > > > It's a resource conflict in the BIOS-assigned resources. > > > > It would be really handy if you could get the output of 'devinfo -u' > > and 'devinfo -rv' when it works, and a verbose dmesg when it is > > broken. > > > > I don't see how this would cause all the pcib allocation failures though > that are in the dmesg output. You mention that it's a resource conflict > in the BIOS, but I'm not seeing where it could be. Could these > allocation failures also explain why my Atheros card doesn't get > assigned an irq? Resources are not just IRQs. Looking at the dmesg diff: @@ -416,11 +417,12 @@ pcib0: allocated type 4 (0x1800-0x18ff) for rid 1c of pcib1 pcib1: allocating non-ISA range 0x1c00-0x1cff pcib0: allocated type 4 (0x1c00-0x1cff) for rid 1c of pcib1 -pcib1: failed to allocate initial prefetch window: 0xe0000000-0xe00fffff +pcib0: allocated type 3 (0xf0000000-0xf00fffff) for rid 24 of pcib1 pcib1: domain 0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0x1000-0x1fff +pcib1: prefetched decode 0xf0000000-0xf00fffff pcib1: special decode ISA pci1: <ACPI PCI bus> on pcib1 pci1: domain=0, physical bus=1 This means that the pcib1 device was assigned a range by the BIOS at 0xe0000000 that was already assigned to another device. In this case it was assigned to agp0: -pcib0: allocated type 3 (0xe0000000-0xe0000fff) for rid 64 of agp0 -agp0: Allocated flush page phys 0xe0000000 virt 0xfffff800e0000000 And later on it was also assigned to re0: pcib1: allocated I/O port range (0x1000-0x10ff) for rid 10 of pci0:1:0:0 - map[18]: type Prefetchable Memory, range 64, base 0xe0004000, size 12, enabled -pcib1: failed to allocate initial prefetch window (0xe0004000-0xe0004fff,0x1000) -pcib1: failed to allocate initial memory window (0xe0004000-0xe0004fff,0x1000) -pci1: pci0:1:0:0 bar 0x18 failed to allocate - map[20]: type Prefetchable Memory, range 64, base 0xe0000000, size 14, memory disabled -pcib1: failed to allocate initial prefetch window (0xe0000000-0xe0003fff,0x4000) -pcib1: failed to allocate initial memory window (0xe0000000-0xe0003fff,0x4000) -pci1: pci0:1:0:0 bar 0x20 failed to allocate Hmm, I think I see the issue, and I might have a fix for it in the works already. The problem is that we haven't reserved pcib1's windows when agp probes, so agp0 steals a resource that is already in use. The change I have that might fix this isn't trivial though, so I don't have a patch I can just give you to test right now. :( Also, this isn't a BIOS issue per se. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201401211215.22021.jhb>