On Mon, 16 Apr 2012 09:06:09 +0200, Anisse Astier <anisse@xxxxxxxxx> wrote : > On Mon, 16 Apr 2012 16:22:36 +1000, Julian Calaby <julian.calaby@xxxxxxxxx> wrote : > > > Hi Anisse, > > > > On Mon, Apr 16, 2012 at 15:57, Anisse Astier <anisse@xxxxxxxxx> wrote: > > > On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <julian.calaby@xxxxxxxxx> wrote: > > >> Hi Anisse, > > >> > > >> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <anisse@xxxxxxxxx> wrote: > > >>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <anisse@xxxxxxxxx> wrote: > > >>> Why some cards work and others don't is a mystery. > > >> > > >> Not really, old cards generally work, current cards that have been out > > >> for a little while generally work, and bleeding edge, > > >> just-released-yesterday cards tend not to. > > > What I meant is that in the set of RT5390RL cards, some work, some > > > don't, consistently, and I cannot find any difference between them. > > > > Sorry, I misinterpreted what you meant. > > > > So, to clarify, am I right in saying that you have: > > - "RT5390R" cards, PCI revision 0502 which all work > It's marked "RT5390L" (not R) and has revision 0502. And in the code it's > referred as REV_RT5390F (yes it's different). > > > - "RT5390RL" cards, PCI revision 1502 which work > Correct. > > - "RT5390RL" cards, PCI revision 1502 which don't work with the > > symptoms described above. > Correct, except revisions are *not* visible in PCI revision. These are only > visible in driver output when debug is enabled, with this printf: > INFO(rt2x00dev, > "Chipset detected - rt: %04x, rf: %04x, rev: %04x.\n", > rt2x00dev->chip.rt, rt2x00dev->chip.rf, rt2x00dev->chip.rev); > > Which gets it by reading register MAC_CSR0_REVISION . > > > > > Ok, so let's look at this a bit closer: the "iw info" diff you > > provided before makes me think that there is some form of regulatory > > setting difference between the working and non-working cards. I would > > guess that this would be visible in the dmesg output, could you boot > > with a working card, save the dmesg, then boot with a non-working > > card, save the dmesg, diff them and reply with that diff? I'm guessing > > that there would be some lines in there about CRDA or regulatory which > > would be different. > I don't think this is related, but I'll try to provide the two dmesg, > with today's wireless-next. Full dmesgs are in attachment. I booted both machines with module rt2800pci blacklisted, and then loaded it manually with modprobe, so the interesting parts should be at the end. > This might be polluted by the fact that the "working" card succeded in > connecting(on channel 6), which then changed the regulatory domain. I'll > try to get unpolluted results. Almost. The cause was that passive scanning brought a beacon on channel 13, and this beacon caused regulatory domain change: --- 1604-dmesg-NOWORKI-truncated 2012-04-16 10:26:03.000000000 +0200 +++ 1604-dmesg-WORKI-truncated 2012-04-16 10:26:04.000000000 +0200 @@ -45,4 +45,6 @@ phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 2 - CWmin: 5, CWmax: 10, Aifs: 3, TXop: 0. phy0 -> rt2x00mac_conf_tx: Info - Configured TX queue 3 - CWmin: 5, CWmax: 10, Aifs: 7, TXop: 0. ADDRCONF(NETDEV_UP): wlan0: link is not ready +cfg80211: Found new beacon on frequency: 2472 MHz (Ch 13) on phy0 +cfg80211: Pending regulatory request, waiting for it to be processed... EXT3-fs (sda5): using internal journal > > > > > Also, what channel is your AP on and what region of the world are you > > in? (I'm guessing Europe from your email address, but which country > > specifically) > I'm in France, but using another wireless card, I can scan APs on > channels 1,2,3,6,8,10,11,13. > > > Regards, > > Anisse
Attachment:
dmesg-working-20120416.gz
Description: GNU Zip compressed data
Attachment:
dmesg-notworking-20120416.gz
Description: GNU Zip compressed data
