linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Frans Pop <elendil@planet.nl>
Cc: Bob Copeland <me@bobcopeland.com>,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [.32-rc1/2] ath5k: has become unreliable with .32-rc1
Date: Thu, 1 Oct 2009 00:27:37 +0200	[thread overview]
Message-ID: <200910010027.37892.rjw@sisk.pl> (raw)
In-Reply-To: <200909302349.05614.elendil@planet.nl>

On Wednesday 30 September 2009, Frans Pop wrote:
> On Wednesday 30 September 2009, Bob Copeland wrote:
> > On Wed, Sep 30, 2009 at 09:52:27AM +0200, Frans Pop wrote:
> > > This is on a laptop I don't use much, but with .31 wireless has always
> > > been (and still is) reliable (.31-rc5 is the last kernel I built for
> > > it). On my other laptop wireless (iwlagn) works fine with .32-rc1.
> >
> > Although iwlagn works, I would think this kind of thing:
> > > ath0: authenticated
> > > ath0: associate with AP 00:14:c1:38:e5:15 (try 1)
> > > ath0: RX ReassocResp from 00:14:c1:38:e5:15 (capab=0x411 status=0 aid=2)
> > > ath0: associated 
> > > ath0: deauthenticating by local choice (reason=3)
> >
> > ...is some kind of issue with userspace or wext rather than the driver.
> > Ath5k only had a dozen or so patches this time around, so it should be
> > easy to bisect if it's a problem in the driver.  One possibility is
> > hardware CCMP support but I've been using it here for some time.
> 
> I doubt it's a userspace issue, but it does look like the regression was
> not triggered by the ath5k driver itself. In the mean time I did a bisect
> on the drivers/net/wireless/ath directory without any results.
> 
> > By the way, name it what you will, but the standard is wlan0 these days
> > :)
> 
> Yep. A leftover from the days I used madwifi :-) I kind of like it though
> given its similarity to eth0.
> 
> > > So the difference looks to be how I boot: if I do a *cold* boot
> > > directly into .32, wireless fails; if I *reboot* from .31 into .32,
> > > wireless comes up correctly. Reboot from .32 to .32 fails too.
> >
> > Is that repeatable?
> 
> Yes, 100%. Weird heh? That's what made me think it must be an ath5k
> driver issue as it looks like a hardware initialization problem. Could
> be PCI or PCMCIA though, although I don't see anything suspicious in
> dmesg.
> 
> > Rafael J. Wysocki has a patch floating around to fix PCMCIA resume,
> > linked here: http://bugzilla.kernel.org/show_bug.cgi?id=13092

Already in the Linus' tree.

Thanks,
Rafael

  reply	other threads:[~2009-09-30 22:26 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30  7:52 [.32-rc1/2] ath5k: has become unreliable with .32-rc1 Frans Pop
2009-09-30 12:24 ` Bob Copeland
2009-09-30 21:49   ` Frans Pop
2009-09-30 22:27     ` Rafael J. Wysocki [this message]
2009-10-01  0:35 ` [SOLVED][.32-rc1/2] " Frans Pop
2009-10-01  8:52   ` Johannes Berg

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=200910010027.37892.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=elendil@planet.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=me@bobcopeland.com \
    /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;
as well as URLs for NNTP newsgroup(s).