Re: Problems with ath at kern.hz=100

On Tue, 10 Feb 2009, Sam Leffler wrote:
 > Ian Smith wrote:
 > > On Mon, 9 Feb 2009, Bengt Ahlgren wrote:
 > > 
 > >  > I was changing kern.hz to 100 on my IBM X40 (Pentium-M) laptop to see
 > >  > whether that saves some battery, but ran into problems with ath not
 > >  > working properly.  At first I thought that my hardware was failing,
 > >  > but changing hz back to 1000 solved the problem.  I am running
 > >  > 7.1-RELEASE-p1 and have the following Atheros chip:
 > >  >  > Feb  9 11:13:10 P142 kernel: ath_hal: 0.9.20.3 (AR5210, AR5211,
 > > AR5212, RF5111, RF5112, RF2413, RF5413)
 > >  > Feb  9 11:13:10 P142 kernel: ath0: <Atheros 5212> mem
 > > 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2
 > >  > Feb  9 11:13:10 P142 kernel: ath0: [ITHREAD]
 > >  > Feb  9 11:13:10 P142 kernel: ath0: WARNING: using obsoleted if_watchdog
 > > interface
 > >  > Feb  9 11:13:10 P142 kernel: ath0: Ethernet address: 00:05:4e:4e:1f:c7
 > >  > Feb  9 11:13:10 P142 kernel: ath0: mac 5.6 phy 4.1 5ghz radio 1.7 2ghz
 > > radio 2.3
 > > 
 > > There's an order of magnitude room to move between 100 and 1000 Hz.  You
 > > could also try with maybe 250 or 500?
 > > 
 > > What speed is your Pentium-M?  Are you using powerd?  If so, what minimum
 > > CPU freq does it drop back to (sysctl debug.cpufreq.lowest)?
 > > 
 > > Sam has talked of a problem with ath (and maybe other) interrupt rates
 > > overwhelming slow CPUs to the extent that userland (ie powerd) doesn't get
 > > a look-in for a while, as I understand it.  A fast CPU clocked back to less
 > > than say 300MHz IS a slow CPU, until powerd gets to crank it up.
 > >   
 > 
 > If powerd starvation were happening you'd see livelock not slow traffic.  The
 > problem was that MIB overflow interrupts from the card were pounding the host
 > but since the cpu clock was lowered they were not serviced fast enough.
 > 
 > FWIW I believe the MIB interrupt storm issue is fixed in head.  I posted a
 > patch to stable@ to enable backmerge of the necessary code but received ~zero
 > feedback in >1 month so RELENG_7 will continue to rot w/ old code.

Thanks for the clarification, Sam.

I did see your patch but due to ongoing Severe Weather Events here I've 
not had enough (solar) power to even upgrade my thinkpad to RELENG_7 for 
months, and the nearest access point is kilometres away, so I've had to 
shelve wireless dreaming until I can move house.  Lame excuses i know ..

[..]

 > You can use tcpdump to monitor traffic at multiple levels in the hierarchy:
 > 
 > tcpdump -i ath0 -n   # tap at 802.3 level
 > tcpdump -i ath0 -n -y IEEE802_11   # tap at 802.11 level
 > tcpdump -i ath0 -n -y IEEE802_11_RADIO   # tap at driver level
 > 
 > and/or you can check statistics using athstats and wlanstats or you can turn
 > on debugging msgs in net80211 or the ath driver using wlandebug and athdebug.
 > Some of these may require you to build your kernel w/ debug options (e.g.
 > ATH_DEBUG).

All filed for now.

cheers, Ian
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-mobile
To unsubscribe, send any mail to "[email protected]"