Re: ath0 no longer attaches, cardbus problems?

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