Linux wireless drivers development
 help / color / mirror / Atom feed
From: Jouni Malinen <jouni.malinen@atheros.com>
To: Peter Stuge <peter@stuge.se>
Cc: "ath9k-devel@lists.ath9k.org" <ath9k-devel@lists.ath9k.org>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [ath9k-devel] ath9k tx lockup, ath: received PCI FATAL interrupt
Date: Sat, 8 Jan 2011 01:08:34 +0200	[thread overview]
Message-ID: <1294441714.12213.75.camel@jm-desktop> (raw)
In-Reply-To: <20110107215549.4053.qmail@stuge.se>

On Fri, 2011-01-07 at 13:55 -0800, Peter Stuge wrote:
> I normally never use wpa_supplicant. I don't accept that it would be
> required for a working connection and so far noone has really
> explained why that would be the case. Only ath9k (ie. neither ipw2200
> nor ath5k) has ever made a difference between wpa_supplicant running
> or not.

You won't need wpa_supplicant for an open network that has only a single
AP and if you never get disconnected (which could happen, e.g., if you
leave the range for a moment). mac80211 will not be reconnecting to the
network on its own automatically, so you need something like
wpa_supplicant to do it for you.

> The above identifies at least two issues:
> 
> 1. ath: received PCI FATAL interrupt
> 
> How can I find out more about the reason for this?

Have you looked at enabling debugging in ath9k? This is described at
http://wireless.kernel.org/en/users/Drivers/ath9k/debug
For the PCI fatal interrupt, it would be useful to have at least
interrupt and fatal levels included. If the output is still readable
(i.e., you can still find the PCI fatal message), enabling more of these
could end up providing more details, too.

Have you happened to test that WLAN card in any other system or with any
other driver? It could be useful to make sure it is known to be working
reliably before spending huge amount of work trying to figure out why it
doesn't work properly with ath9k..

> 2. Unworking association without wpa_supplicant after power cycle
> 
> How can I find out more about the reason for this?

The part where the dmesg output had "direct probe to <BSSID> timed out"
could potentially be caused by card RX not working properly. I've seen
that happen in some cases (with rmmod + modprobe ath9k being one way of
recovering from that state). Looking at the RX interrupt counters in
ath9k debugfs and checking whether they increment could be of use here.
In general, verifying RX registers (filter, descriptors) would likely
follow in getting more details.

- Jouni



  parent reply	other threads:[~2011-01-07 23:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-07 21:55 ath9k tx lockup, ath: received PCI FATAL interrupt Peter Stuge
2011-01-07 22:09 ` [ath9k-devel] " Brian Prodoehl
2011-01-07 22:47   ` Peter Stuge
2011-01-07 23:08 ` Jouni Malinen [this message]
2011-01-07 23:42   ` Peter Stuge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1294441714.12213.75.camel@jm-desktop \
    --to=jouni.malinen@atheros.com \
    --cc=ath9k-devel@lists.ath9k.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=peter@stuge.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox