Date: Thu, 8 Sep 2011 13:59:56 -0400 From: John Baldwin <jhb@freebsd.org> To: Daniel Eischen <deischen@freebsd.org> Cc: adrian@freebsd.org, freebsd-current@freebsd.org, Warner Losh <imp@freebsd.org> Subject: Re: ath0 no longer attaches, cardbus problems? Message-ID: <201109081359.56584.jhb@freebsd.org> In-Reply-To: <Pine.GSO.4.64.1109081243320.10252@sea.ntplx.net> References: <Pine.GSO.4.64.1108242007100.23746@sea.ntplx.net> <201109080942.03413.jhb@freebsd.org> <Pine.GSO.4.64.1109081243320.10252@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, September 08, 2011 1:19:23 pm Daniel Eischen wrote: > On Thu, 8 Sep 2011, John Baldwin wrote: > > > On Wednesday, September 07, 2011 5:48:01 pm Daniel Eischen wrote: > >> On Wed, 7 Sep 2011, John Baldwin wrote: > >> > >>> On Wednesday, September 07, 2011 4:18:25 pm Daniel Eischen wrote: > >>>> > >>>> Setting debug.acpi.disabled=hostres in /boot/loader.conf > >>>> did not help. I tried this with a recent kernel from HEAD. > >>> > >>> Did it remove the 'pcib0: decoding ....' lines from a verbose dmesg? > >> > >> I don't see that line in a verbose dmesg. The hostres verbose > >> dmesg is here: > >> > >> http://people.freebsd.org/~deischen/ath_dmesg_hostres.txt > > > > Ok, that exonerates those changes then. > > > >> I'm using a local CVS repo, so the a -D date means (I guess) > >> the beginning of the day. So the commit that actually broke > >> the kernel for me occurred on Mar 31. According to: > >> > >> cvs diff -u -D"31 Mar 2011" -D"1 Apr 2011" > >> > >> there were a lot of sys/dev/pci changes. > > > > There was one commit: > > > > Author: jhb > > Date: Thu Mar 31 13:22:12 2011 > > New Revision: 220195 > > URL: http://svn.freebsd.org/changeset/base/220195 > > > > Log: > > Explicitly track the state of all known BARs for each PCI device. The PCI > > bus driver will now remember the size of a BAR obtained during the initial > > bus scan and use that size when doing lazy resource allocation rather than > > resizing the BAR. The bus driver will now also report unallocated BARs to > > userland for display by 'pciconf -lb'. Psuedo-resources that are not BARs > > (such as the implicit I/O port resources for master/slave ATA controllers) > > will no longer be listed as BARs in 'pciconf -lb'. During resume, BARs are > > restored from their new saved state instead of having the raw registers > > saved and restored across resume. This also fixes restoring BARs at > > unusual loactions if said BAR has been allocated by a driver. > > > > Add a constant for the offset of the ROM BIOS BAR in PCI-PCI bridges and > > properly handle ROM BIOS BARs in PCI-PCI bridges. The PCI bus now also > > properly handles the lack of a ROM BIOS BAR in a PCI-Cardbus bridge. > > > > Tested by: jkim > > > > Modified: > > head/sys/dev/pci/pci.c > > head/sys/dev/pci/pci_user.c > > head/sys/dev/pci/pcireg.h > > head/sys/dev/pci/pcivar.h > > > > Can you get a verbose dmesg from just after this change (you will need the > > patch from earlier to fix the panic you saw)? > > > > The output of pciconf -lb from both before and after would also be good. > > I can't build r220194 (just before); it seems to rely on r220195. > But r220195 builds, and I've applied the patch from earlier to > fix the panic. > > I suspect you don't really need the pciconf -lb from before r220195 > because r220195 works - ath attaches and is at the correct base > address (0x88000000). So the commit that broke ath/cardbus must > be after r220195. > > The verbose dmesg and pciconf -lb are here: > > http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt > http://people.freebsd.org/~deischen/ath/dmesg.r220195.txt > > I've noticed that in the non-working kernels, pcib2/cbb0 > are at address 0xf8f00000, and cbb1 is at 0xf8f01000. > When the PCI configuration space is printed (in the > verbose boot), offset 0x10 shows 0xf8f00000 and > 0xf8f01000. In the working kernel, they are at 0x8000000 > and 0x80001000. It seems like kernels post Mar 31 constrain > the cardbus address range to be within the PCI bridge > range. Yes. You can test if that is all that causes the problem by turning off 'NEW_PCIB' in your kernel config. > Also, I noticed that pcib2 fails to allocate a memory window > in post Mar 31 kernels: > > pcib2: <ACPI PCI-PCI bridge> at device 30.0 on pci0 > pcib2: failed to allocate initial I/O port window: 0xe000-0xffff > pcib2: failed to allocate initial memory window: 0xf4000000-0xfbffffff > > whereas in previous kernels the allocation succeeds. That is due to the hostres stuff. Your BIOS says that the Host-PCI bridge doesn't decode those full ranges meaning they aren't available for use by downstream PCI-PCI bridges. > Just curious, how would this all work for a PCI-VME > bridge where you could have a very large memory windows > onto a 32(or even 64)-bit address space? That should work just fine, but the PCI-PCI bridge needs to reserve its windows from its parent so that other devices on the same bus as the bridge don't try to use conflicting resources. In the case of your laptop your pcib2 bridge is a subtractively decoded bridge. I don't know if for some reason the cardbus card wants to specifically use resources that are only subtractively decoded. Was waiting for Warner to comment on that. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201109081359.56584.jhb>