From: Bruno Randolf <br1@einfach.org>
To: "Luis R. Rodriguez" <lrodriguez@atheros.com>,
"Lukáš Turek" <8an@praha12.net>
Cc: "ath5k-devel@lists.ath5k.org" <ath5k-devel@lists.ath5k.org>,
"linux-wireless" <linux-wireless@vger.kernel.org>
Subject: Re: [ath5k-devel] Race condition in CRDA calls?
Date: Thu, 17 Jun 2010 13:47:58 +0900 [thread overview]
Message-ID: <201006171347.58712.br1@einfach.org> (raw)
In-Reply-To: <20100526214658.GB10931@tux>
hi!
are there any news on that? i think i hit the same bug, now...
thanks,
bruno
On Thu May 27 2010 06:46:58 Luis R. Rodriguez wrote:
> Just FYI, you want to use linux-wireless for reporting such things,
> not ath5k-devel. Also I have been real busy in March (and stil am but
> just trying to reply) so if I do not reply maybe others can. In
> linux-wireless you'll likely get much more review/help than ath5k-devel
> for this.
>
> More below.
>
> On Thu, Mar 25, 2010 at 10:01:54AM -0700, Lukáš Turek wrote:
> > Hi,
> >
> > I've been testing current vanilla 2.6.34 from git today on a computer
> > with three Atheros PCI cards and noticed a strange behavior: although
> > all the cards have the same regulatory domain (0x36), only the last one
> > (phy2) had the correct channels enabled, the other two (phy0 and phy1)
> > stayed in US regulatory domain with channels 52-140 disabled.
> >
> > It seems the reply from CRDA for the first request gets into the kernel
> > after the last card is detected and all the replies get mixed up some
> > way:
> >
> > ath5k 0000:02:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
> > ath5k 0000:02:01.0: registered as 'phy0'
> > ath: EEPROM regdomain: 0x36
> > ath: EEPROM indicates we should expect a direct regpair map
> > ath: Country alpha2 being used: CZ
> > ath: Regpair used: 0x36
> > udev: renamed network interface eth0 to eth2
> > udev: renamed network interface eth1_rename to eth0
> > phy0: Selected rate control algorithm 'minstrel'
> > ath5k phy0: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> > ath5k 0000:02:02.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> > ath5k 0000:02:02.0: registered as 'phy1'
> > ath: EEPROM regdomain: 0x36
> > ath: EEPROM indicates we should expect a direct regpair map
> > ath: Country alpha2 being used: CZ
> > ath: Regpair used: 0x36
> > cfg80211: Calling CRDA for country: CZ
> > phy1: Selected rate control algorithm 'minstrel'
> > ath5k phy1: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> > ath5k 0000:02:03.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
> > ath5k 0000:02:03.0: registered as 'phy2'
> > ath: EEPROM regdomain: 0x36
> > ath: EEPROM indicates we should expect a direct regpair map
> > ath: Country alpha2 being used: CZ
> > ath: Regpair used: 0x36
> > cfg80211: Calling CRDA for country: CZ
> > udev: renamed network interface wlan1 to wlan3
> > phy2: Selected rate control algorithm 'minstrel'
> > ath5k phy2: Atheros AR5414 chip found (MAC: 0xa5, PHY: 0x61)
> > cfg80211: Calling CRDA for country: CZ
> > udev: renamed network interface wlan1 to wlan2
> > cfg80211: Current regulatory domain intersected:
> > (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> > (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> > (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > cfg80211: Current regulatory domain intersected:
> > (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> > (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> > (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > cfg80211: Current regulatory domain intersected:
> > (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
> > (2402000 KHz - 2472000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> > (2457000 KHz - 2482000 KHz @ 20000 KHz), (N/A, 2000 mBm)
> > (2474000 KHz - 2483500 KHz @ 9500 KHz), (N/A, 2000 mBm)
> > (5170000 KHz - 5250000 KHz @ 40000 KHz), (N/A, 2000 mBm)
> >
> > Another reason might be udev messing up with device names. I will try to
> > debug this, but any hints would be greatly appreciated, because there's
> > not much info about the CRDA <-> kernel interaction.
>
> You forgot to supply the kernel log of when cfg80211 loads, that
> would have been helpful. After cfg80211 loads then leave a window
> open with 'iw event -t' running. Then load ath5k, and if you want to
> debug udev you can use udevadm, for example to debug only
> kernel messages:
>
> udevadm monitor --environment kernel
>
> In short cfg80211 will do an intersection if the core had a regulatory
> domain set for some reason and then a driver suggested to use another
> country. If cfg80211 was world roaming and a driver then just used
> a request for CZ then it shuld stick to CZ. If a second device comes
> up with CZ then -EALREADY should be expected IIRC, if this is not happening
> it smells like a bug.
>
> Luis
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2010-06-17 4:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201003251801.57951.8an@praha12.net>
2010-05-26 21:46 ` [ath5k-devel] Race condition in CRDA calls? Luis R. Rodriguez
2010-06-17 4:47 ` Bruno Randolf [this message]
2010-06-17 5:05 ` Luis R. Rodriguez
2010-10-08 7:57 ` Bruno Randolf
2010-10-11 18:13 ` Lukáš Turek
2010-10-11 18:50 ` Luis R. Rodriguez
2010-06-17 10:04 ` Lukáš Turek
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=201006171347.58712.br1@einfach.org \
--to=br1@einfach.org \
--cc=8an@praha12.net \
--cc=ath5k-devel@lists.ath5k.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lrodriguez@atheros.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).