Re: ath0 issue

Lamont Granquist wrote:

i did the same thing with running:

while(1)
echo foo
sleep 1
end

in a window ssh'd into the machine with the ath0 driver, but with the
kernel recompiled with ATH_DEBUG and sysctl dev.ath.0.debug=0xffffffff
-- there should be packets sent every second while doing this.

Not usually a good idea to enable so much debugging. The console
printfs will alter operation.


i saw the same behavior where tx packets would tend to spool up and
buffer. here's the output of one second where a bunch of spooled up
packets were sent alont with the previous second and following second
and with a note on how long it had been before any ath*tx* routine had
been called. hopefully this is useful for debugging -- i've got copious
amounts of debugging logs, so let me know if i've guessed wrongly about
what is relevant...

this is the previous debugging notice for ath*tx* which i believe
indicates nothing
sent out on the interface since 11:17:36:

If tx stops in ap mode you need to figure out whether the h/w tx q is
stalled or something else "above" is blocking outbound traffic. The
usual things to check are:

1. are there resources in the driver to send a packet (e.g. buffers on
the queue); if the tx q is full then the OACTIVE bit will be marked on
the interface and visible with ifconfig
2. if packets are queued to the h/w and not going out then you need to
identify whether a higher priority frame is blocking them; this is
harder but can occur when something like a beacon frame fails to go out
or if there is cabq traffic q'd up behind the beacon frame that doesn't
make it out
3. if none of the above is blocking traffic then h/w may consider the
media busy; this can happen if your ap is operating in a busy
environment and things like protection are being used heavily, or if you
have an overlapping BSS that is operating in 11b

Often problems such as this are most easily understood by sniffing
traffic from another station and looking for traffic patterns coincident
with the event on the ap. More useful information can be found in the
statistics collected by the driver (use athstats).

Sam
_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Filter Hook
    ... the callback routine is been invoked at DISPATCH_LEVEL. ... If you really have to keep such a queue for the packets, then the IP filter driver is not suitable for your needs since you have to process all the packets in the callback routine without any wait actionand return it to the tcpip driver immediately when the callback routine returns. ... What IRQL are you running at when you crash, ...
    (microsoft.public.development.device.drivers)
  • Re: MAC bridging and sniffing packets with specific Ethertype
    ... That is, the Ethernet adapters are bound to the Mbridge driver (which, since ... Mbridge handles the bridging of packets between the adapters. ...
    (microsoft.public.windowsce.embedded)
  • Re: WIN32
    ... There isn't a lot we could do about the requirement of a second computer for debugging. ... the debugger run on one machine and the target driver run on another. ... describe the only scenario Microsoft supports for debugging. ... another newsgroup as to whether or not it is even possible to debug a device driver under ...
    (microsoft.public.vc.mfc)
  • Re: Degradation of TCP connection
    ... and running ifconfigon the target does indeed show ... the huge number of dropped Rx packets, ... RX stall (possibly due to mishandled RX overrun in the driver) ... RX interrupts have stopped firing ...
    (comp.os.vxworks)
  • Re: Degradation of TCP connection
    ... "Each of our boards will have an ethernet driver specific ... once you get a target into a failed state, ... when the VxWorks box stops ACKing packets sent from the Windows box. ...
    (comp.os.vxworks)