Date: Thu, 8 Sep 2011 13:19:23 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: John Baldwin <jhb@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: <Pine.GSO.4.64.1109081243320.10252@sea.ntplx.net> In-Reply-To: <201109080942.03413.jhb@freebsd.org> References: <Pine.GSO.4.64.1108242007100.23746@sea.ntplx.net> <201109071735.34593.jhb@freebsd.org> <Pine.GSO.4.64.1109071740280.5474@sea.ntplx.net> <201109080942.03413.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. 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? -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1109081243320.10252>