Performance of BCM43224 (14e4:4353)

Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Rafał Miłecki]

2011/12/9 Larry Finger <Larry.Finger@lwfinger.net>:
> 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ł

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

On 12/10/2011 10:18 AM, Rafał Miłecki wrote:
> 2011/12/9 Larry Finger <Larry.Finger@lwfinger.net>:
>> 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

Re: Performance of BCM43224 (14e4:4353)

[Larry Finger]

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

Re: Performance of BCM43224 (14e4:4353)

[Arend van Spriel]

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