[resent with compressed dmesg(<40k) and removed one Cc:, sorry for the spam]
Hi,
I have two[1] (seemingly) identical mini pcie RT5390 wireless cards. One
works, the other doesn't.
By "doesn't" work, I mean it can't receive any network further than 1m(at
least it's still "wireless" ;-)). Scan is empty, except if I put the AP
right next to the laptop.
I'm using the rt2800pci in-kernel driver. Support for this card was added
in 2.6.39. To make sure there was no regression, I tested the following
kernels: 2.6.39.4, 3.0.8, 3.2.5, 3.3.1 and wireless-next as of today.
I'm also using the latest firmware rt2860.bin version 34 from official
linux-firmware git tree.
Behaviour is reproduced with or without plugging the antenna. Behaviour
follows the card, if I put on another motherboard.
Markings on the chips are identical whether it's working or not:
- Ralink RT5390RL NAF8590109 1133STA1
lspci[3] doesn't change (except mac address) whether it's working or not.
dmesg (attached) with rt2x00 debug output doesn't show anything special.
I've tried rt5390sta[2], and it doesn't help. Working card is working,
non-working is not.
Last, but not least, it works on windows.
- if we reboot from windows, it works
- if we halt the hardware, and power it on, it doesn't work.
Which means that the windows driver does something that rt2800pci
doesn't, and that the state is preserved as long as we don't cut power.
Regards,
Anisse
[1] I have many of both, in RT5390(rev 1502) and RT5390F(rev 0502) models. All non working are rev 1502, even if some rev 1502 are working.
[2] https://build.opensuse.org/package/files?package=rt5390sta&project=driver%3Awireless with 2.6.38
[3] lspci -vv:
02:00.0 Network controller: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe
Subsystem: Ralink corp. RT5390 Wireless 802.11n 1T/1R PCIe
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at febf0000 (32-bit, non-prefetchable) [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <512ns, L1 unlimited
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency L0 <512ns, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-, Selectable De-emphasis: -6dB
Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Device Serial Number 00-00-d4-0c-02-15-c1-00
Kernel driver in use: rt2800pci
[4] "iw phy0 info" difference:
--- iwphydump-working 2012-04-13 11:26:18.000000000 +0200
+++ iwphydump-notworking 2012-04-13 11:26:09.000000000 +0200
@@ -28,7 +28,7 @@
* 2457 MHz [10] (0.0 dBm)
* 2462 MHz [11] (0.0 dBm)
* 2467 MHz [12] (0.0 dBm) (passive scanning, no IBSS)
- * 2472 MHz [13] (0.0 dBm)
+ * 2472 MHz [13] (0.0 dBm) (passive scanning, no IBSS)
* 2484 MHz [14] (0.0 dBm) (passive scanning, no IBSS)
Bitrates (non-HT):
* 1.0 Mbps
On Mon, 16 Apr 2012 09:06:09 +0200, Anisse Astier <[email protected]> wrote :
> On Mon, 16 Apr 2012 16:22:36 +1000, Julian Calaby <[email protected]> wrote :
>
> > Hi Anisse,
> >
> > On Mon, Apr 16, 2012 at 15:57, Anisse Astier <[email protected]> wrote:
> > > On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <[email protected]> wrote:
> > >> Hi Anisse,
> > >>
> > >> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
> > >>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> 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
On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <[email protected]> wrote:
> Hi Anisse,
>
> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> wrote:
>>>
>>> [1] I have many of both, in RT5390(rev 1502) and RT5390F(rev 0502) models. All non working are rev 1502, even if some rev 1502 are working.
>>
>> To clarify, Revs 0502, marked RT5390L are all working, and can be
>> ignored for the purpose of this discussion.
>>
>> The only non-working revs are 1502, which is the model marked
>> "RT5390RL". This model has zero google results apart from this
>> discussion, so I'm guessing it might be new, hence not much tested and
>> not supported.
>
> This is likely to be the case, I'm sure that the rt2x00 developers
> will probably have support in the driver once RaLink gives them the
> code / info needed.
>
>> 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.
>
> In general, the kernel developers only add support for a card once
> it's been released.
Indeed, and once someone reports they exist ;-)
>
> Thanks,
>
> --
> Julian Calaby
>
> Email: [email protected]
> Profile: http://www.google.com/profiles/julian.calaby/
> .Plan: http://sites.google.com/site/juliancalaby/
On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> wrote:
>
> [1] I have many of both, in RT5390(rev 1502) and RT5390F(rev 0502) models. All non working are rev 1502, even if some rev 1502 are working.
To clarify, Revs 0502, marked RT5390L are all working, and can be
ignored for the purpose of this discussion.
The only non-working revs are 1502, which is the model marked
"RT5390RL". This model has zero google results apart from this
discussion, so I'm guessing it might be new, hence not much tested and
not supported.
Why some cards work and others don't is a mystery.
--
Anisse
Hi Anisse,
On Mon, Apr 16, 2012 at 15:57, Anisse Astier <[email protected]> wrote:
> On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <[email protected]> wrote:
>> Hi Anisse,
>>
>> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
>>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> 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
- "RT5390RL" cards, PCI revision 1502 which work
- "RT5390RL" cards, PCI revision 1502 which don't work with the
symptoms described above.
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.
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)
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
Hi again,
On Fri, 13 Apr 2012 14:23:52 +0200, Anisse Astier <[email protected]> wrote :
> [resent with compressed dmesg(<40k) and removed one Cc:, sorry for the spam]
>
> Hi,
>
> I have two[1] (seemingly) identical mini pcie RT5390 wireless cards. One
> works, the other doesn't.
> By "doesn't" work, I mean it can't receive any network further than 1m(at
> least it's still "wireless" ;-)). Scan is empty, except if I put the AP
> right next to the laptop.
>
> I'm using the rt2800pci in-kernel driver. Support for this card was added
> in 2.6.39. To make sure there was no regression, I tested the following
> kernels: 2.6.39.4, 3.0.8, 3.2.5, 3.3.1 and wireless-next as of today.
> I'm also using the latest firmware rt2860.bin version 34 from official
> linux-firmware git tree.
>
> Behaviour is reproduced with or without plugging the antenna. Behaviour
> follows the card, if I put on another motherboard.
>
> Markings on the chips are identical whether it's working or not:
> - Ralink RT5390RL NAF8590109 1133STA1
>
> lspci[3] doesn't change (except mac address) whether it's working or not.
> dmesg (attached) with rt2x00 debug output doesn't show anything special.
>
> I've tried rt5390sta[2], and it doesn't help. Working card is working,
> non-working is not.
>
>
> Last, but not least, it works on windows.
> - if we reboot from windows, it works
> - if we halt the hardware, and power it on, it doesn't work.
> Which means that the windows driver does something that rt2800pci
> doesn't, and that the state is preserved as long as we don't cut power.
>
>
> Regards,
>
> Anisse
>
>
[...]
Ok, I've found a solution.
After looking into the latest ralink release, for chipset 5572, I saw
that rt5390 support was updated. And that support for the chip with rev
1502 was added, named RT5390R.
The only difference with "normal" 5390 is that this one supports hardware
antenna diversity, so the driver should tell the card which antenna to
use by default (the main one in my case).
This is replicated in the patch below, which has been tested on both
working and non-working 1502s, and is proving to work quite well.
I still don't know how to integrate this properly with rt2800pci's
antenna diversity code, since this is the first chipset to have hardware
antenna diversity in the rt2800 family (others had it in rt61 and rt73
for example).
I'll look into it over the next two weeks, and send a patch if no one
does before.
From: Anisse Astier <[email protected]>
Date: Tue, 17 Apr 2012 12:23:21 +0200
Subject: [PATCH] rt2800: add chipset RT5390R support
This is for testing Only !! Please don't merge !
---
drivers/net/wireless/rt2x00/rt2800.h | 1 +
drivers/net/wireless/rt2x00/rt2800lib.c | 12 ++++++++++++
2 files changed, 13 insertions(+)
diff --git a/drivers/net/wireless/rt2x00/rt2800.h b/drivers/net/wireless/rt2x00/rt2800.h
index 063bfa8..1ce2634 100644
--- a/drivers/net/wireless/rt2x00/rt2800.h
+++ b/drivers/net/wireless/rt2x00/rt2800.h
@@ -83,6 +83,7 @@
#define REV_RT3090E 0x0211
#define REV_RT3390E 0x0211
#define REV_RT5390F 0x0502
+#define REV_RT5390R 0x1502
/*
* Signal information.
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index bd19802..e94661f 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -3928,6 +3928,18 @@ static int rt2800_init_rfcsr(struct rt2x00_dev *rt2x00dev)
rt2800_rfcsr_write(rt2x00dev, 30, rfcsr);
}
+ if (rt2x00_rt_rev_gte(rt2x00dev, RT5390, REV_RT5390R)) {
+ rt2x00dev->default_ant.tx = ANTENNA_HW_DIVERSITY;
+ rt2x00dev->default_ant.rx = ANTENNA_HW_DIVERSITY;
+ rt2x00dev->default_ant.rx_chain_num = 0;
+ rt2x00dev->default_ant.tx_chain_num = 0;
+
+ rt2800_bbp_write(rt2x00dev, 150, 0);
+ rt2800_bbp_write(rt2x00dev, 151, 0);
+ rt2800_bbp_write(rt2x00dev, 154, 0);
+ rt2800_bbp_write(rt2x00dev, 152, 0x80);
+ }
+
return 0;
}
--
1.7.9.4
Hi Anisse
On Mon, Apr 16, 2012 at 18:40, Anisse Astier <[email protected]> wrote:
> On Mon, 16 Apr 2012 09:06:09 +0200, Anisse Astier <[email protected]> wrote :
>
>> On Mon, 16 Apr 2012 16:22:36 +1000, Julian Calaby <[email protected]> wrote :
>>
>> > Hi Anisse,
>> >
>> > On Mon, Apr 16, 2012 at 15:57, Anisse Astier <[email protected]> wrote:
>> > > On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <[email protected]> wrote:
>> > >> Hi Anisse,
>> > >>
>> > >> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
>> > >>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> 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).
I don't think it really matters either way - and as you said before,
they're irrelevant to this particular issue.
>> > ?- "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 .
I must have picked up the "PCI" bit when you mentioned they were PCI
cards elsewhere, either way, as far as the driver, etc. is concerned,
they're identical.
>> > 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.
Thanks for the dmesgs, however it's kinda annoying that there's no
real differences between them.
>> 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.
You shouldn't be having any regulatory issues connecting to an AP on
channel 6. In general, it's channels above 11 (I think) that are
occasionally masked by different regulatory settings.
> 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
Not quite, it seems that CRDA never got sent the request, which is
odd, however this is on the working card so it doesn't explain the
non-working ones.
>> > 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.
That sounds right.
I'm at a loss to explain it any further, which is annoying. At this
point, I'm guessing that there's some subtle hardware difference, or
something like that. It could be something as complicated as incorrect
or broken components, or something as simple as a dry solder join on
the antenna connection.
Where did you get the cards?
Does anyone else who's more knowledgeable than me have any idea what's
happening here?
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On Mon, 16 Apr 2012 20:11:45 +1000, Julian Calaby <[email protected]> wrote :
> Hi Anisse
>
[...]
> >> > 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.
>
> Thanks for the dmesgs, however it's kinda annoying that there's no
> real differences between them.
>
> >> 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.
>
> You shouldn't be having any regulatory issues connecting to an AP on
> channel 6. In general, it's channels above 11 (I think) that are
> occasionally masked by different regulatory settings.
>
> > 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
>
> Not quite, it seems that CRDA never got sent the request, which is
> odd, however this is on the working card so it doesn't explain the
> non-working ones.
>
> >> > 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.
>
> That sounds right.
>
> I'm at a loss to explain it any further, which is annoying. At this
> point, I'm guessing that there's some subtle hardware difference, or
> something like that. It could be something as complicated as incorrect
> or broken components, or something as simple as a dry solder join on
> the antenna connection.
>
> Where did you get the cards?
I got them inside netbooks we bought from our provider in China. Is that
really relevant? They're on the market anyway.
I can provide a photo of the chip if anyone is interested (I posted the
markings in the first message of the discussion).
>
> Does anyone else who's more knowledgeable than me have any idea what's
> happening here?
>
> Thanks,
>
Hi Anisse,
On Wed, Apr 18, 2012 at 00:37, Anisse Astier <[email protected]> wrote:
> Ok, I've found a solution.
>
> After looking into the latest ralink release, for chipset 5572, I saw
> that rt5390 support was updated. And that support for the chip with rev
> 1502 was added, named RT5390R.
> The only difference with "normal" 5390 is that this one supports hardware
> antenna diversity, so the driver should tell the card which antenna to
> use by default (the main one in my case).
> This is replicated in the patch below, which has been tested on both
> working and non-working 1502s, and is proving to work quite well.
That would explain it - I'm guessing the non-working 1502s have their
antennas set up "wrongly" by default.
> I still don't know how to integrate this properly with rt2800pci's
> antenna diversity code, since this is the first chipset to have hardware
> antenna diversity in the rt2800 family (others had it in rt61 and rt73
> for example).
I think the patch you sent is a reasonable workaround (with an
appropriate comment explaining what's happening) while proper antenna
diversity support is added.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/
On Mon, 16 Apr 2012 16:22:36 +1000, Julian Calaby <[email protected]> wrote :
> Hi Anisse,
>
> On Mon, Apr 16, 2012 at 15:57, Anisse Astier <[email protected]> wrote:
> > On Mon, Apr 16, 2012 at 1:38 AM, Julian Calaby <[email protected]> wrote:
> >> Hi Anisse,
> >>
> >> On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
> >>> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> 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.
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.
>
> 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
Hi Anisse,
On Mon, Apr 16, 2012 at 03:33, Anisse Astier <[email protected]> wrote:
> On Fri, Apr 13, 2012 at 2:23 PM, Anisse Astier <[email protected]> wrote:
>>
>> [1] I have many of both, in RT5390(rev 1502) and RT5390F(rev 0502) models. All non working are rev 1502, even if some rev 1502 are working.
>
> To clarify, Revs 0502, marked RT5390L are all working, and can be
> ignored for the purpose of this discussion.
>
> The only non-working revs are 1502, which is the model marked
> "RT5390RL". This model has zero google results apart from this
> discussion, so I'm guessing it might be new, hence not much tested and
> not supported.
This is likely to be the case, I'm sure that the rt2x00 developers
will probably have support in the driver once RaLink gives them the
code / info needed.
> 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.
In general, the kernel developers only add support for a card once
it's been released.
Thanks,
--
Julian Calaby
Email: [email protected]
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/