From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 21 17:26:50 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 80C95BAD for ; Tue, 21 Jan 2014 17:26:50 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 58BD313E6 for ; Tue, 21 Jan 2014 17:26:50 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 4E4DEB945; Tue, 21 Jan 2014 12:26:49 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: Atom Board ACPI API MOPNV10J failing since 9.1 Date: Tue, 21 Jan 2014 12:15:21 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20130906; KDE/4.5.5; amd64; ; ) References: <52CF850A.9060906@erdgeist.org> <201401140823.00259.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201401211215.22021.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 21 Jan 2014 12:26:49 -0500 (EST) Cc: David Shane Holden X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2014 17:26:50 -0000 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: 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