Re: ath0 no longer attaches, cardbus problems?

From: John Baldwin <jhb_at_freebsd.org>
Date: Tue, 6 Sep 2011 11:45:20 -0400
On Friday, September 02, 2011 12:27:02 pm Daniel Eischen wrote:
> 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?

Hmm, the dmesg for the 'hostres' case shows the 'hostres' code as still
being active.  (And it does look like that is the root cause in your
case perhaps.)  Granted, we are asking for resources that your BIOS says
work just fine, so I'm not sure why it is failing in the first place.

Looks like I had a typo in my original e-mail, try "debug.acpi.disabled=hostres"
rather than "debug.acpi.disable=hostres".

-- 
John Baldwin
Received on Tue Sep 06 2011 - 13:45:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:17 UTC