Guys,
I just added the patches that let brcmsmac use bcma, and tested the TX and RX
rates using netperf. The results are
Driver RX TX
brcmsmac 21.7 6.2
b43 15.0 6.0
wl 43.5 73.5
The AP is running in 802.11n mode and has throughput of 40-60 Mbps in both
directions with an RTL8192CE, thus both open-source drivers have room for
improvement.
I am using the following firmware:
b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
With b43 and mac80211 debugging turned on, I see a lot of
wlan13: detected beacon loss from AP - sending probe request
Larry
On 12/09/2011 07:17 PM, Larry Finger wrote:
> Arend,
>
> I got a little further. The error message was modified as below:
>
> /* scan for cores */
> if (socitype == SOCI_AI) {
> SI_MSG("Found chip type AI (0x%08x)\n", w);
> /* pass chipc address instead of original core base */
> ai_scan(&sii->pub, pbus);
> } else {
> /* Found chip of unknown type */
> pr_err("Found chip of type %d, chipid is 0x%x\n", socitype, w);
> return NULL;
> }
>
> This one logs "brcmsmac: Found chip of type 4, chipid is 0x4bf80001". That is a
> very strange chip ID.
>
> Larry
>
Indeed. What is more strange is that this looks like value from
enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
It seems the BAR window is wrong. Can you read PCI_BAR window in the
ai_doattach() before reading the chip id.
Gr. AvS
On 12/09/2011 01:46 AM, Larry Finger wrote:
> Guys,
>
> I just added the patches that let brcmsmac use bcma, and tested the TX and RX
> rates using netperf. The results are
>
> Driver RX TX
>
> brcmsmac 21.7 6.2
> b43 15.0 6.0
> wl 43.5 73.5
>
> The AP is running in 802.11n mode and has throughput of 40-60 Mbps in both
> directions with an RTL8192CE, thus both open-source drivers have room for
> improvement.
>
> I am using the following firmware:
> b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)
>
>
> With b43 and mac80211 debugging turned on, I see a lot of
>
> wlan13: detected beacon loss from AP - sending probe request
>
> Larry
>
Hi Larry
Thanks for trying. I used iperf for my throughput testing. It has two
biderectional flavours: simultaneous (-d) and individual (-r):
-d: 39 Mbps
-r: 65 Mbps
There are some more bcma related patches to be sent out, but I don't
expect that it will change your benchmark results (as mine were similar
if not identical at each commit).
Gr. AvS
On 12/09/2011 01:31 PM, Arend van Spriel wrote:
>
> That is an unexpected code path especially as brcmsmac is probed from
> bcma so SoC interface type should be AI (aka. AMBA AXI). Checked with
> the proprietary driver and there is no type 4.
>
> Can you provide the bcma_device_id information that bcma has collected
> and the bcma_chipinfo for your device?
The bcma core scan provides:
bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)
b43 reports:
b43-phy0: Broadcom 43224 WLAN found (core revision 23)
b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 6
brcmsmac shows:
brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
I hope this provides what you need. I did not see anything else in the logs.
Larry
On 12/10/2011 10:18 AM, Rafał Miłecki wrote:
> 2011/12/9 Larry Finger <[email protected]>:
>> On 12/09/2011 02:04 PM, Arend van Spriel wrote:
>>>
>>>
>>> Indeed. What is more strange is that this looks like value from
>>> enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
>>> It seems the BAR window is wrong. Can you read PCI_BAR window in the
>>> ai_doattach() before reading the chip id.
>>
>>
>> I would like a hint on how to do this. I tried some things that failed.
>
> Have you tried
> u32 value;
> pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN, &value);
> pr_info();
> pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN2, &value);
> pr_info();
>
> You should also hack bcma_bus_scan to display addr and wrap.
> pr_info("Core %d addr: 0x%X, wrap 0x%X\n", core->core_index,
> core->addr, core->wrap);
> (put is inside the while, after existing pr_info)
>
Obviously it should be a pci_read_config_dword(). I found out that I can
reproduce the problem over here so I added the print statements:
[61359.893254] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
[61359.897801] core[2] id=0x820 addr=18002000 wrap=18102000
[61359.897808] core[1] id=0x812 addr=18001000 wrap=18101000
[61359.897814] core[0] id=0x800 addr=18000000 wrap=18100000
[61359.897822] PCI_BAR0_WIN=18107000
Not sure how it got programmed to this value, but it definitely is wrong.
Gr. AvS
On 12/09/2011 06:57 PM, Larry Finger wrote:
> On 12/09/2011 11:32 AM, Arend van Spriel wrote:
>
>> With the submitted patches brcmsmac claims any revision of 802.11 cores.
>> Not sure what b43 claims. I have a patch internally to claim only
>> revisions 23 and 24, which are used in bcm43224, bcm43225, and bcm4313.
>
> The problem is that ai_doattach() is returning NULL. I added pr_err() statements
> to each of the places that this could happen and found that the error in in this
> fragment:
>
> /* scan for cores */
> if (socitype == SOCI_AI) {
> SI_MSG("Found chip type AI (0x%08x)\n", w);
> /* pass chipc address instead of original core base */
> ai_scan(&sii->pub, pbus);
> } else {
> /* Found chip of unknown type */
> pr_err("Found chip of type %d\n", socitype);
> return NULL;
> }
>
> This one logs "brcmsmac: Found chip of type 4". As SOC_AI is the only SOCI_XX
> that is defined, I am not sure that I will be able to get further.
>
> Larry
>
That is an unexpected code path especially as brcmsmac is probed from
bcma so SoC interface type should be AI (aka. AMBA AXI). Checked with
the proprietary driver and there is no type 4.
Can you provide the bcma_device_id information that bcma has collected
and the bcma_chipinfo for your device?
Gr. AvS
2011/12/9 Larry Finger <[email protected]>:
> On 12/09/2011 02:04 PM, Arend van Spriel wrote:
>>
>>
>> Indeed. What is more strange is that this looks like value from
>> enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
>> It seems the BAR window is wrong. Can you read PCI_BAR window in the
>> ai_doattach() before reading the chip id.
>
>
> I would like a hint on how to do this. I tried some things that failed.
Have you tried
u32 value;
pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN, &value);
pr_info();
pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN2, &value);
pr_info();
You should also hack bcma_bus_scan to display addr and wrap.
pr_info("Core %d addr: 0x%X, wrap 0x%X\n", core->core_index,
core->addr, core->wrap);
(put is inside the while, after existing pr_info)
--
Rafał
On 12/09/2011 02:04 PM, Arend van Spriel wrote:
>
> Indeed. What is more strange is that this looks like value from
> enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
> It seems the BAR window is wrong. Can you read PCI_BAR window in the
> ai_doattach() before reading the chip id.
I would like a hint on how to do this. I tried some things that failed.
Larry
Arend,
I got a little further. The error message was modified as below:
/* scan for cores */
if (socitype == SOCI_AI) {
SI_MSG("Found chip type AI (0x%08x)\n", w);
/* pass chipc address instead of original core base */
ai_scan(&sii->pub, pbus);
} else {
/* Found chip of unknown type */
pr_err("Found chip of type %d, chipid is 0x%x\n", socitype, w);
return NULL;
}
This one logs "brcmsmac: Found chip of type 4, chipid is 0x4bf80001". That is a
very strange chip ID.
Larry
On 12/09/2011 05:44 PM, Larry Finger wrote:
> On 12/09/2011 04:27 AM, Arend van Spriel wrote:
>>
>> Hi Larry
>>
>> Could you perform your benchmark test on brcmsmac without the bcma
>> patches. It kind of surprises me that we are that far off compared to
>> the wl driver.
>
> I wondered about that myself. Upon investigation, my test with bcma/brcmsmac
> never worked. Without the patches, my netperf numbers for brcmsmac are RX 40.0
> and TX 59.7 Mbps.In all cases, the reported number is the maximum of 10 tries of
> 3 sec each.
Hi, Larry
That numbers do make more sense. Thanks for testing.
> With the patches, my dmesg contains the following:
>
> [ 908.282281] bcma: Bus registered
> [ 908.353242] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
> [ 908.380164] ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
> [ 908.380184] ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
> [ 908.380192] ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
> [ 908.380316] ieee80211 phy0: brcmsmac: attach() failed with code 11
> [ 908.380379] brcmsmac: brcms_bcma_probe: brcms_attach failed!
> [ 908.381715] brcms_module_init: register returned 0
That is too bad. I thought all individual commits were ok, but I
reordered some. It could be the srom code failing, which will likely
become redundant as bcma can provide the info.
> As b43 is also loaded, which may be a second problem, it is run instead of brcmsmac.
With the submitted patches brcmsmac claims any revision of 802.11 cores.
Not sure what b43 claims. I have a patch internally to claim only
revisions 23 and 24, which are used in bcm43224, bcm43225, and bcm4313.
Gr. AvS
On 12/10/2011 05:04 AM, Arend van Spriel wrote:
>
> Obviously it should be a pci_read_config_dword(). I found out that I can
> reproduce the problem over here so I added the print statements:
>
> [61359.893254] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
> [61359.897801] core[2] id=0x820 addr=18002000 wrap=18102000
> [61359.897808] core[1] id=0x812 addr=18001000 wrap=18101000
> [61359.897814] core[0] id=0x800 addr=18000000 wrap=18100000
> [61359.897822] PCI_BAR0_WIN=18107000
>
> Not sure how it got programmed to this value, but it definitely is wrong.
I put pr_info() and dump_stack() at every place where PCI_BAR_WIN0 is changed.
The one place in drivers/bcma/host_pci.c is never called - only the location in
drivers/bcma/scan.c.
The logged data is
[ 813.683905] bcma: BCMA_PCI_BAR0_WIN set to 0x18000000
[ 813.683910] Pid: 8989, comm: work_for_cpu Tainted: G O
3.2.0-rc4-wl+ #146
[ 813.683913] Call Trace:
[ 813.683926] [<ffffffffa0389af6>]
bcma_scan_switch_core.isra.9.part.10+0x36/0x40 [bcma]
[ 813.683933] [<ffffffffa0389bde>] bcma_init_bus+0x6e/0x70 [bcma]
[ 813.683940] [<ffffffffa0389c04>] bcma_bus_scan+0x24/0x210 [bcma]
[ 813.683946] [<ffffffff81028f11>] ? __ioremap_caller+0x2b1/0x390
[ 813.683951] [<ffffffff811dded0>] ? pci_iomap+0x80/0xc0
[ 813.683958] [<ffffffffa0389209>] bcma_bus_register+0x19/0x2e0 [bcma]
[ 813.683964] [<ffffffffa038b800>] bcma_host_pci_probe+0x120/0x1c0 [bcma]
[ 813.683970] [<ffffffff810636b0>] ? cwq_activate_first_delayed+0x110/0x110
[ 813.683976] [<ffffffff811f17b2>] local_pci_probe+0x12/0x20
[ 813.683980] [<ffffffff810636c3>] do_work_for_cpu+0x13/0x30
[ 813.683984] [<ffffffff8106bb07>] kthread+0x87/0x90
[ 813.683990] [<ffffffff81384f74>] kernel_thread_helper+0x4/0x10
[ 813.683995] [<ffffffff8138269d>] ? retint_restore_args+0xe/0xe
[ 813.683999] [<ffffffff8106ba80>] ? __init_kthread_worker+0x70/0x70
[ 813.684041] [<ffffffff81384f70>] ? gs_change+0xb/0xb
[ 813.684048] bcma: BCMA_PCI_BAR0_WIN set to 0x18107000
The stack trace is identical for the second entry. It is never remapped, which
is why it is wrong in brcmsmac.
Question: Don't you need to change the R_REG macro to use bcma? It is still
doing read{b,w,l} operations, and is not checking the mapping.
Larry
On 12/09/2011 11:32 AM, Arend van Spriel wrote:
> With the submitted patches brcmsmac claims any revision of 802.11 cores.
> Not sure what b43 claims. I have a patch internally to claim only
> revisions 23 and 24, which are used in bcm43224, bcm43225, and bcm4313.
The problem is that ai_doattach() is returning NULL. I added pr_err() statements
to each of the places that this could happen and found that the error in in this
fragment:
/* scan for cores */
if (socitype == SOCI_AI) {
SI_MSG("Found chip type AI (0x%08x)\n", w);
/* pass chipc address instead of original core base */
ai_scan(&sii->pub, pbus);
} else {
/* Found chip of unknown type */
pr_err("Found chip of type %d\n", socitype);
return NULL;
}
This one logs "brcmsmac: Found chip of type 4". As SOC_AI is the only SOCI_XX
that is defined, I am not sure that I will be able to get further.
Larry
On 12/09/2011 01:46 AM, Larry Finger wrote:
> Guys,
>
> I just added the patches that let brcmsmac use bcma, and tested the TX and RX
> rates using netperf. The results are
>
> Driver RX TX
>
> brcmsmac 21.7 6.2
> b43 15.0 6.0
> wl 43.5 73.5
>
Hi Larry
Could you perform your benchmark test on brcmsmac without the bcma
patches. It kind of surprises me that we are that far off compared to
the wl driver.
Gr. AvS
On 12/09/2011 04:27 AM, Arend van Spriel wrote:
>
> Hi Larry
>
> Could you perform your benchmark test on brcmsmac without the bcma
> patches. It kind of surprises me that we are that far off compared to
> the wl driver.
I wondered about that myself. Upon investigation, my test with bcma/brcmsmac
never worked. Without the patches, my netperf numbers for brcmsmac are RX 40.0
and TX 59.7 Mbps.In all cases, the reported number is the maximum of 10 tries of
3 sec each.
With the patches, my dmesg contains the following:
[ 908.282281] bcma: Bus registered
[ 908.353242] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
[ 908.380164] ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
[ 908.380184] ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
[ 908.380192] ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
[ 908.380316] ieee80211 phy0: brcmsmac: attach() failed with code 11
[ 908.380379] brcmsmac: brcms_bcma_probe: brcms_attach failed!
[ 908.381715] brcms_module_init: register returned 0
As b43 is also loaded, which may be a second problem, it is run instead of brcmsmac.
Larry
On 12/10/2011 08:49 PM, Larry Finger wrote:
> On 12/10/2011 05:04 AM, Arend van Spriel wrote:
>>
>> Obviously it should be a pci_read_config_dword(). I found out that I can
>> reproduce the problem over here so I added the print statements:
>>
>> [61359.893254] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
>> [61359.897801] core[2] id=0x820 addr=18002000 wrap=18102000
>> [61359.897808] core[1] id=0x812 addr=18001000 wrap=18101000
>> [61359.897814] core[0] id=0x800 addr=18000000 wrap=18100000
>> [61359.897822] PCI_BAR0_WIN=18107000
>>
>> Not sure how it got programmed to this value, but it definitely is wrong.
>
> I put pr_info() and dump_stack() at every place where PCI_BAR_WIN0 is changed.
> The one place in drivers/bcma/host_pci.c is never called - only the location in
> drivers/bcma/scan.c.
>
> The logged data is
>
> [ 813.683905] bcma: BCMA_PCI_BAR0_WIN set to 0x18000000
> [ 813.683910] Pid: 8989, comm: work_for_cpu Tainted: G O
> 3.2.0-rc4-wl+ #146
> [ 813.683913] Call Trace:
> [ 813.683926] [<ffffffffa0389af6>]
> bcma_scan_switch_core.isra.9.part.10+0x36/0x40 [bcma]
> [ 813.683933] [<ffffffffa0389bde>] bcma_init_bus+0x6e/0x70 [bcma]
> [ 813.683940] [<ffffffffa0389c04>] bcma_bus_scan+0x24/0x210 [bcma]
> [ 813.683946] [<ffffffff81028f11>] ? __ioremap_caller+0x2b1/0x390
> [ 813.683951] [<ffffffff811dded0>] ? pci_iomap+0x80/0xc0
> [ 813.683958] [<ffffffffa0389209>] bcma_bus_register+0x19/0x2e0 [bcma]
> [ 813.683964] [<ffffffffa038b800>] bcma_host_pci_probe+0x120/0x1c0 [bcma]
> [ 813.683970] [<ffffffff810636b0>] ? cwq_activate_first_delayed+0x110/0x110
> [ 813.683976] [<ffffffff811f17b2>] local_pci_probe+0x12/0x20
> [ 813.683980] [<ffffffff810636c3>] do_work_for_cpu+0x13/0x30
> [ 813.683984] [<ffffffff8106bb07>] kthread+0x87/0x90
> [ 813.683990] [<ffffffff81384f74>] kernel_thread_helper+0x4/0x10
> [ 813.683995] [<ffffffff8138269d>] ? retint_restore_args+0xe/0xe
> [ 813.683999] [<ffffffff8106ba80>] ? __init_kthread_worker+0x70/0x70
> [ 813.684041] [<ffffffff81384f70>] ? gs_change+0xb/0xb
> [ 813.684048] bcma: BCMA_PCI_BAR0_WIN set to 0x18107000
>
> The stack trace is identical for the second entry. It is never remapped, which
> is why it is wrong in brcmsmac.
Great you found it.
> Question: Don't you need to change the R_REG macro to use bcma? It is still
> doing read{b,w,l} operations, and is not checking the mapping.
In the end the R_REG/W_REG macros will be removed and only
bcma_read/bcma_write are used. That will be in the next patch series.
> Larry
>
Gr. AvS