Re: ath0 no longer attaches, cardbus problems?

On Thu, 25 Aug 2011, Daniel Eischen wrote:

> On Thu, 25 Aug 2011, John Baldwin wrote:
>
>> On Wednesday, August 24, 2011 8:19:42 pm Daniel Eischen wrote:
>>> Hello,
>>> 
>>> I have an older Dell 4150 laptop that takes forever to build
>>> world, so I don't update it that often.  The last time I
>>> updated it was March 1, 2010.  I just updated the system
>>> yesterday and ath0 (a Linksys PCCard) no longer attaches.
>>> 
>>> The interesting thing is that ath0 is detected at different
>>> addresses between the working kernel and the non-working
>>> kernel:
>>>
>>>    March 1, 2010 kernel
>>>    --------------------
>>>    ath0: <Atheros 5212> mem 0x88000000-0x8800ffff irq 11
>>>        at device 0.0 on  cardbus0
>>>    ath0: [ITHREAD]
>>>    ath0: AR5212 mac 5.9 RF5112 phy 4.3
>>> 
>>>
>>>    Aug 23, 2011 kernel
>>>    -------------------
>>>    ath0: <Atheros 5212> mem 0xf8f10000-0xf8f1ffff irq 11
>>>        at device 0.0 on  cardbus0
>>> 
>>> 
>>> I've tried forcing successful returns from
>>> ar5212SetPowerModeAwake() and ar5212SetResetReg()
>>> but it doesn't help (diffs below).
>>> 
>>> Any suggestions on how to get this to work?
>>> Full dmesg from working and non-working kernels at
>>>
>>>    http://people.freebsd.org/~deischen/ath/ath.dmesg
>> 
>> You can try setting 'debug.acpi.disable=hostres' at the loader prompt as a
>> test.  If that doesn't work, a verbose dmesg from the broken case as well 
>> as
>> devinfo -u and devinfo -r output from the working and broken cases would be
>> most useful.
>
> Setting debug.acpi.disable=hostres did not work.  Strange thing is
> that ath0 is now at mem 0x88000000-0x8800ffff for both working
> and non-working kernels (with and without debug.acpi.disable=hostres).
> ath0 still doesn't attach, but it seems funny that the memory
> address changes.  These are all soft reboots, not hard reboots,
> after a working kernel.
>
> All the information you requested is here:
>
>  http://people.freebsd.org/~deischen/ath/
>
> There are verbose boots and devinfo -u/-r output for the
> working kernel and the non-working kernel (with and without
> debug.acpi.disable=hostres).
>
> Anything else you'd like me to try?

Any hopes of getting this cardbus problem fixed?

-- 
DE