chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

Hi,

the wlan daughterboard on a nintendo wii stopped working with current master.
Building from the v3.4 tag gives me a working device.

I bisected this to:

commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
Author: Johannes Berg <johannes.berg@intel.com>

The hw queues fail the check in ieee80211_check_queues(). When I hack
that function to always "return 0;" wlan works again.

These 2 printk()s:

diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c
index d4c19a7..246fc04 100644
--- a/net/mac80211/iface.c
+++ b/net/mac80211/iface.c
@@ -154,7 +154,9 @@ static int ieee80211_check_queues(struct
ieee80211_sub_if_data *sdata)
    int n_queues = sdata->local->hw.queues;
    int i;

+   printk("n_queues=%d\n", n_queues);
    for (i = 0; i < IEEE80211_NUM_ACS; i++) {
+       printk("sdata->vif.hw_queue[%d]=%d\n", i, sdata->vif.hw_queue[i]);
        if (WARN_ON_ONCE(sdata->vif.hw_queue[i] ==
                 IEEE80211_INVAL_HW_QUEUE))
            return -EINVAL;

end in:
[   11.873077] n_queues=1
[   11.897066] sdata->vif.hw_queue[0]=0
[   11.900451] sdata->vif.hw_queue[1]=1

The surrounding dmesg output is:
[    0.270900] sdhci: Secure Digital Host Controller Interface driver
[    0.274159] sdhci: Copyright(c) Pierre Ossman
[    0.286360] sdhci-pltfm: SDHCI platform and OF driver helper
[    0.318739] mmc0: SDHCI controller on d070000.sd [d070000.sd] using DMA
[    0.358650] mmc1: SDHCI controller on d080000.sdio [d080000.sdio] using DMA
[    0.366951] TCP: cubic registered
[    0.370514] NET: Registered protocol family 17
[    0.374265] Bluetooth: RFCOMM TTY layer initialized
[    0.386710] Bluetooth: RFCOMM socket layer initialized
[    0.390129] Bluetooth: RFCOMM ver 1.11
[    0.393466] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[    0.396794] Bluetooth: BNEP filters: protocol multicast
[    0.400096] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[    0.403386] initlevel:7=late, 14 registered initcalls
[    0.408372] Waiting for root device /dev/mmcblk0p2...
[    0.425466] mmc0: new high speed SD card at address f181
[    0.429456] mmcblk0: mmc0:f181 SD02G 1.87 GiB
[    0.434311]  mmcblk0: p1 p2 p3
[    0.461667] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.467214] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
[    0.471669] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.485751] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
[    0.493260] mmc1: queuing unknown CIS tuple 0x80 (10 bytes)
[    0.496433] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.499543] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    0.502583] mmc1: queuing unknown CIS tuple 0x80 (5 bytes)
[    0.505491] mmc1: queuing unknown CIS tuple 0x80 (4 bytes)
[    0.508130] mmc1: new SDIO card at address 0001
[    0.520378] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    0.523595] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[    0.557528] ssb: chipcommon status is 0x0
[    0.561271] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    0.643432] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
[    0.770220] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    0.786605] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    0.795436] Freeing unused kernel memory: 144k freed
[    5.339710] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.789283] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
[   10.919815] b43-phy0: Loading OpenSource firmware version 410.31754
[   10.936408] b43-phy0: Hardware crypto acceleration not supported by firmware
[   10.943866] b43-phy0: QoS not supported by firmware
[   11.873077] n_queues=1
[   11.897066] sdata->vif.hw_queue[0]=0
[   11.900451] sdata->vif.hw_queue[1]=1
[   11.903763] ------------[ cut here ]------------
[   11.906987] WARNING: at /home/andre/devel-temp/linux/net/mac80211/iface.c:164
[   11.913314] NIP: c039e248 LR: c039e1f4 CTR: 00000000
[   11.916488] REGS: d3019cb0 TRAP: 0700   Not tainted  (3.5.0-rc1-wii+)
[   11.919674] MSR: 00029032 <EE,ME,IR,DR,RI>  CR: 28888428  XER: 00000000
[   11.926211] TASK = d3020270[1221] 'wpa_supplicant' THREAD: d3018000
[   11.926211] GPR00: 00000001 d3019d60 d3020270 00000018 00001032
d3019c48 ffffffff 00000000
[   11.926211] GPR08: d38e5220 c04f0000 00000000 000000a5 22888428
100f2a98 10015603 00000027
[   11.926211] GPR16: ffffffff 100d8200 100d1bd4 100f0000 100eaa84
100eaa84 bfe0ce1e d3b8bccc
[   11.926211] GPR24: 00000000 d3019e28 00000001 c049ced3 00000001
d3bb3402 00000002 d3bb3400
[   11.957761] NIP [c039e248] ieee80211_check_queues+0xb0/0x188
[   11.961435] LR [c039e1f4] ieee80211_check_queues+0x5c/0x188
[   11.965097] Call Trace:
[   11.968754] [d3019d60] [c039e1f4] ieee80211_check_queues+0x5c/0x188
(unreliable)
[   11.976391] [d3019d80] [c039fef0] ieee80211_do_open+0x548/0xb88
[   11.980396] [d3019db0] [c02c0300] __dev_open+0xc4/0x120
[   11.984400] [d3019dd0] [c02bd0ec] __dev_change_flags+0xe0/0x174
[   11.988397] [d3019df0] [c02c01f0] dev_change_flags+0x24/0x70
[   11.992413] [d3019e10] [c030f618] devinet_ioctl+0x2bc/0x77c
[   11.996500] [d3019e80] [c0310df4] inet_ioctl+0xd8/0x114
[   12.000568] [d3019e90] [c02a9728] sock_ioctl+0x1fc/0x248
[   12.004555] [d3019eb0] [c00d9170] do_vfs_ioctl+0x688/0x730
[   12.008466] [d3019f10] [c00d9268] sys_ioctl+0x50/0x90
[   12.012333] [d3019f40] [c000f668] ret_from_syscall+0x0/0x38
[   12.016134] --- Exception: c01 at 0xfbe0058
[   12.016134]     LR = 0xfbdffbc
[   12.023526] Instruction dump:
[   12.027091] 68000001 0f000000 2f800000 41be00d4 38000001 3d20c04f
9809712f 480000c4
[   12.034244] 41b8002c 3d20c04f 88097130 68000001 <0f000000> 2f800000
41be00a8 38000001
[   12.041393] ---[ end trace 5b1ec0526600d1ae ]---
[   13.343824] b43-phy0: Loading OpenSource firmware version 410.31754
[   13.347591] b43-phy0: Hardware crypto acceleration not supported by firmware
[   13.354286] b43-phy0: QoS not supported by firmware
[   14.299915] n_queues=1
[   14.303012] sdata->vif.hw_queue[0]=0
[   14.306058] sdata->vif.hw_queue[1]=1
[   15.643819] b43-phy0: Loading OpenSource firmware version 410.31754
[   15.647501] b43-phy0: Hardware crypto acceleration not supported by firmware
[   15.654225] b43-phy0: QoS not supported by firmware
[   16.584720] n_queues=1
[   16.587757] sdata->vif.hw_queue[0]=0
[   16.590721] sdata->vif.hw_queue[1]=1

Any ideas?

Thanks,
Andre

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> Hi,
> 
> the wlan daughterboard on a nintendo wii stopped working with current master.
> Building from the v3.4 tag gives me a working device.
> 
> I bisected this to:
> 
> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> Author: Johannes Berg <johannes.berg@intel.com>
> 
> The hw queues fail the check in ieee80211_check_queues(). When I hack
> that function to always "return 0;" wlan works again.

There's a fix for this on the way since Larry had also reported the bug,
but I don't know where it is right now.

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> Hi,
> 
> the wlan daughterboard on a nintendo wii stopped working with current master.
> Building from the v3.4 tag gives me a working device.
> 
> I bisected this to:
> 
> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> Author: Johannes Berg <johannes.berg@intel.com>
> 
> The hw queues fail the check in ieee80211_check_queues(). When I hack
> that function to always "return 0;" wlan works again.

There's a fix for this on the way since Larry had also reported the bug,
but I don't know where it is right now.

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
>> Hi,
>>
>> the wlan daughterboard on a nintendo wii stopped working with current master.
>> Building from the v3.4 tag gives me a working device.
>>
>> I bisected this to:
>>
>> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
>> Author: Johannes Berg <johannes.berg@intel.com>
>>
>> The hw queues fail the check in ieee80211_check_queues(). When I hack
>> that function to always "return 0;" wlan works again.
>
> There's a fix for this on the way since Larry had also reported the bug,
> but I don't know where it is right now.

Okay, nice. Then I won't go hunting and just try the next -rc.

Thanks,
Andre

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
>> Hi,
>>
>> the wlan daughterboard on a nintendo wii stopped working with current master.
>> Building from the v3.4 tag gives me a working device.
>>
>> I bisected this to:
>>
>> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
>> Author: Johannes Berg <johannes.berg@intel.com>
>>
>> The hw queues fail the check in ieee80211_check_queues(). When I hack
>> that function to always "return 0;" wlan works again.
>
> There's a fix for this on the way since Larry had also reported the bug,
> but I don't know where it is right now.

Okay, nice. Then I won't go hunting and just try the next -rc.

Thanks,
Andre

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> >> Hi,
> >>
> >> the wlan daughterboard on a nintendo wii stopped working with current master.
> >> Building from the v3.4 tag gives me a working device.
> >>
> >> I bisected this to:
> >>
> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> >> Author: Johannes Berg <johannes.berg@intel.com>
> >>
> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
> >> that function to always "return 0;" wlan works again.
> >
> > There's a fix for this on the way since Larry had also reported the bug,
> > but I don't know where it is right now.
> 
> Okay, nice. Then I won't go hunting and just try the next -rc.

Found the commit now:

commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon May 7 17:45:29 2012 +0200

    mac80211: fix single queue drivers


johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> >> Hi,
> >>
> >> the wlan daughterboard on a nintendo wii stopped working with current master.
> >> Building from the v3.4 tag gives me a working device.
> >>
> >> I bisected this to:
> >>
> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> >> Author: Johannes Berg <johannes.berg@intel.com>
> >>
> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
> >> that function to always "return 0;" wlan works again.
> >
> > There's a fix for this on the way since Larry had also reported the bug,
> > but I don't know where it is right now.
> 
> Okay, nice. Then I won't go hunting and just try the next -rc.

Found the commit now:

commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
Author: Johannes Berg <johannes.berg@intel.com>
Date:   Mon May 7 17:45:29 2012 +0200

    mac80211: fix single queue drivers


johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
>> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
>> >> Hi,
>> >>
>> >> the wlan daughterboard on a nintendo wii stopped working with current master.
>> >> Building from the v3.4 tag gives me a working device.
>> >>
>> >> I bisected this to:
>> >>
>> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
>> >> Author: Johannes Berg <johannes.berg@intel.com>
>> >>
>> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
>> >> that function to always "return 0;" wlan works again.
>> >
>> > There's a fix for this on the way since Larry had also reported the bug,
>> > but I don't know where it is right now.
>>
>> Okay, nice. Then I won't go hunting and just try the next -rc.
>
> Found the commit now:
>
> commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
> Author: Johannes Berg <johannes.berg@intel.com>
> Date:   Mon May 7 17:45:29 2012 +0200
>
>    mac80211: fix single queue drivers

Just checked again, that commit was already part of my tree, so I
still run into this issue.

A couple of printk()'s report that local->hw.queues is 4 in
ieee80211_set_default_queues() while n_queues in
ieee80211_check_queues() is 1...

Thanks,
Andre

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
>> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
>> >> Hi,
>> >>
>> >> the wlan daughterboard on a nintendo wii stopped working with current master.
>> >> Building from the v3.4 tag gives me a working device.
>> >>
>> >> I bisected this to:
>> >>
>> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
>> >> Author: Johannes Berg <johannes.berg@intel.com>
>> >>
>> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
>> >> that function to always "return 0;" wlan works again.
>> >
>> > There's a fix for this on the way since Larry had also reported the bug,
>> > but I don't know where it is right now.
>>
>> Okay, nice. Then I won't go hunting and just try the next -rc.
>
> Found the commit now:
>
> commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: ? Mon May 7 17:45:29 2012 +0200
>
> ? ?mac80211: fix single queue drivers

Just checked again, that commit was already part of my tree, so I
still run into this issue.

A couple of printk()'s report that local->hw.queues is 4 in
ieee80211_set_default_queues() while n_queues in
ieee80211_check_queues() is 1...

Thanks,
Andre

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 2014 bytes --]

On Thu, 7 Jun 2012 17:24:51 +0200
Andre Heider <a.heider@gmail.com> wrote:

> On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> >> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> >> <johannes@sipsolutions.net> wrote:
> >> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> >> >> Hi,
> >> >>
> >> >> the wlan daughterboard on a nintendo wii stopped working with current master.
> >> >> Building from the v3.4 tag gives me a working device.
> >> >>
> >> >> I bisected this to:
> >> >>
> >> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> >> >> Author: Johannes Berg <johannes.berg@intel.com>
> >> >>
> >> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
> >> >> that function to always "return 0;" wlan works again.
> >> >
> >> > There's a fix for this on the way since Larry had also reported the bug,
> >> > but I don't know where it is right now.
> >>
> >> Okay, nice. Then I won't go hunting and just try the next -rc.
> >
> > Found the commit now:
> >
> > commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
> > Author: Johannes Berg <johannes.berg@intel.com>
> > Date:   Mon May 7 17:45:29 2012 +0200
> >
> >    mac80211: fix single queue drivers
> 
> Just checked again, that commit was already part of my tree, so I
> still run into this issue.
> 
> A couple of printk()'s report that local->hw.queues is 4 in
> ieee80211_set_default_queues() while n_queues in
> ieee80211_check_queues() is 1...

b43 messes with the queue count at runtime. I guess that's the reason.
I don't know if this can be fixed now, though. The problem is that we
first need to load the firmware before we know the queue count.
There seem to have been some firmware loading changes, but I didn't
track those too closely. So I don't know whether they allow fixing the
situation or not...

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Thu, 7 Jun 2012 17:24:51 +0200
Andre Heider <a.heider@gmail.com> wrote:

> On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> >> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> >> <johannes@sipsolutions.net> wrote:
> >> > On Wed, 2012-06-06 at 21:10 +0200, Andre Heider wrote:
> >> >> Hi,
> >> >>
> >> >> the wlan daughterboard on a nintendo wii stopped working with current master.
> >> >> Building from the v3.4 tag gives me a working device.
> >> >>
> >> >> I bisected this to:
> >> >>
> >> >> commit 3a25a8c8b75b430c4f4022918e26fa51d557ecde
> >> >> Author: Johannes Berg <johannes.berg@intel.com>
> >> >>
> >> >> The hw queues fail the check in ieee80211_check_queues(). When I hack
> >> >> that function to always "return 0;" wlan works again.
> >> >
> >> > There's a fix for this on the way since Larry had also reported the bug,
> >> > but I don't know where it is right now.
> >>
> >> Okay, nice. Then I won't go hunting and just try the next -rc.
> >
> > Found the commit now:
> >
> > commit a9d3c05cca51d80ef2b9eddabf794c9458e36c2c
> > Author: Johannes Berg <johannes.berg@intel.com>
> > Date: ? Mon May 7 17:45:29 2012 +0200
> >
> > ? ?mac80211: fix single queue drivers
> 
> Just checked again, that commit was already part of my tree, so I
> still run into this issue.
> 
> A couple of printk()'s report that local->hw.queues is 4 in
> ieee80211_set_default_queues() while n_queues in
> ieee80211_check_queues() is 1...

b43 messes with the queue count at runtime. I guess that's the reason.
I don't know if this can be fixed now, though. The problem is that we
first need to load the firmware before we know the queue count.
There seem to have been some firmware loading changes, but I didn't
track those too closely. So I don't know whether they allow fixing the
situation or not...

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120607/c4f169fb/attachment.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 11:03 AM, Michael Büsch wrote:
>
> b43 messes with the queue count at runtime. I guess that's the reason.
> I don't know if this can be fixed now, though. The problem is that we
> first need to load the firmware before we know the queue count.
> There seem to have been some firmware loading changes, but I didn't
> track those too closely. So I don't know whether they allow fixing the
> situation or not...

The only change in firmware loading is that the probe routine places a initiates 
an item on a work queue with the firmware loading routine as the callback. 
Previously, the fw load routines were called directly from the probe routine.

There is a bug in the new implementation that I am fixing. It results in the 
inability to load firmware whenever b43 is built in; however, as long as b43 is 
a module, it works fine.

I do not understand what is different about your system than mine. I have a 
Cardbus version of the BCM4318 running kernel 3.5-rc1 from mainline. The host 
computer is a PowerBook G4 Titanium (PPC). The chip has four hardware queues and 
never had the problem that was fixed with a9d3c05. When I had trouble, it was 
with a BCM4301, which does only have a single queue.

Is it possible that Nintendo uses a special version of the BCM4318 that only 
contains a single transmit queue?

I'm building 3.5-rc1 from wireless-testing, but that will take a while. That Mac 
is not very fast.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 11:03 AM, Michael B?sch wrote:
>
> b43 messes with the queue count at runtime. I guess that's the reason.
> I don't know if this can be fixed now, though. The problem is that we
> first need to load the firmware before we know the queue count.
> There seem to have been some firmware loading changes, but I didn't
> track those too closely. So I don't know whether they allow fixing the
> situation or not...

The only change in firmware loading is that the probe routine places a initiates 
an item on a work queue with the firmware loading routine as the callback. 
Previously, the fw load routines were called directly from the probe routine.

There is a bug in the new implementation that I am fixing. It results in the 
inability to load firmware whenever b43 is built in; however, as long as b43 is 
a module, it works fine.

I do not understand what is different about your system than mine. I have a 
Cardbus version of the BCM4318 running kernel 3.5-rc1 from mainline. The host 
computer is a PowerBook G4 Titanium (PPC). The chip has four hardware queues and 
never had the problem that was fixed with a9d3c05. When I had trouble, it was 
with a BCM4301, which does only have a single queue.

Is it possible that Nintendo uses a special version of the BCM4318 that only 
contains a single transmit queue?

I'm building 3.5-rc1 from wireless-testing, but that will take a while. That Mac 
is not very fast.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Thu, 07 Jun 2012 12:25:07 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> I do not understand what is different about your system than mine.

I think the difference is that he runs opensource firmware, for which the queuenumber
patching comes into effect. You should be able to reproduce even with standard
firmware by disabling QOS with the module parameter.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Thu, 07 Jun 2012 12:25:07 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> I do not understand what is different about your system than mine.

I think the difference is that he runs opensource firmware, for which the queuenumber
patching comes into effect. You should be able to reproduce even with standard
firmware by disabling QOS with the module parameter.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120607/bacb44b3/attachment.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 12:30 PM, Michael Büsch wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> I do not understand what is different about your system than mine.
>
> I think the difference is that he runs opensource firmware, for which the queuenumber
> patching comes into effect. You should be able to reproduce even with standard
> firmware by disabling QOS with the module parameter.

Loading b43 with the qos=0 option works, but using the open-source firmware does 
fail.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 12:30 PM, Michael B?sch wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> I do not understand what is different about your system than mine.
>
> I think the difference is that he runs opensource firmware, for which the queuenumber
> patching comes into effect. You should be able to reproduce even with standard
> firmware by disabling QOS with the module parameter.

Loading b43 with the qos=0 option works, but using the open-source firmware does 
fail.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 7:30 PM, Michael Büsch <m@bues.ch> wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> I do not understand what is different about your system than mine.
>
> I think the difference is that he runs opensource firmware, for which the queuenumber
> patching comes into effect. You should be able to reproduce even with standard
> firmware by disabling QOS with the module parameter.

As far as I can tell openfwwf is the only working firmware for this chip.
It's 'special': http://www.gc-linux.org/wiki/Wii:WLAN

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 7:30 PM, Michael B?sch <m@bues.ch> wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> I do not understand what is different about your system than mine.
>
> I think the difference is that he runs opensource firmware, for which the queuenumber
> patching comes into effect. You should be able to reproduce even with standard
> firmware by disabling QOS with the module parameter.

As far as I can tell openfwwf is the only working firmware for this chip.
It's 'special': http://www.gc-linux.org/wiki/Wii:WLAN

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 18:03 +0200, Michael Büsch wrote:


> > >    mac80211: fix single queue drivers
> > 
> > Just checked again, that commit was already part of my tree, so I
> > still run into this issue.
> > 
> > A couple of printk()'s report that local->hw.queues is 4 in
> > ieee80211_set_default_queues() while n_queues in
> > ieee80211_check_queues() is 1...
> 
> b43 messes with the queue count at runtime. I guess that's the reason.

Oh, right, I forgot all about that, bugger. That would seem to be the
reason since setting it to 4 initially will create the mapping 0->0,
1->1, 2->2, 3->3 and then if it's 1 later, the expected mapping would be
0,1,2,3->0 instead.

> I don't know if this can be fixed now, though. The problem is that we
> first need to load the firmware before we know the queue count.

Yes it can (and I think it should) be: The firmware is now requested
from the probe routines, and b43_request_firmware() only registers with
mac80211 when the firmware has successfully loaded from disk. The only
problem is that b43_request_firmware() doesn't actually bring the core
up before registering since that wasn't necessary until now. It would've
been easier if the firmware packaging contained the flag instead of the
SHM :-)

However, it's also possible to actually *use* the new mac80211 feature.
That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
may be quicker.

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 18:03 +0200, Michael B?sch wrote:


> > >    mac80211: fix single queue drivers
> > 
> > Just checked again, that commit was already part of my tree, so I
> > still run into this issue.
> > 
> > A couple of printk()'s report that local->hw.queues is 4 in
> > ieee80211_set_default_queues() while n_queues in
> > ieee80211_check_queues() is 1...
> 
> b43 messes with the queue count at runtime. I guess that's the reason.

Oh, right, I forgot all about that, bugger. That would seem to be the
reason since setting it to 4 initially will create the mapping 0->0,
1->1, 2->2, 3->3 and then if it's 1 later, the expected mapping would be
0,1,2,3->0 instead.

> I don't know if this can be fixed now, though. The problem is that we
> first need to load the firmware before we know the queue count.

Yes it can (and I think it should) be: The firmware is now requested
from the probe routines, and b43_request_firmware() only registers with
mac80211 when the firmware has successfully loaded from disk. The only
problem is that b43_request_firmware() doesn't actually bring the core
up before registering since that wasn't necessary until now. It would've
been easier if the firmware packaging contained the flag instead of the
SHM :-)

However, it's also possible to actually *use* the new mac80211 feature.
That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
may be quicker.

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:

> However, it's also possible to actually *use* the new mac80211 feature.
> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> may be quicker.

This might do it, I haven't tested it at all:

http://p.sipsolutions.net/3c6b003bb06e5298.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:

> However, it's also possible to actually *use* the new mac80211 feature.
> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> may be quicker.

This might do it, I haven't tested it at all:

http://p.sipsolutions.net/3c6b003bb06e5298.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 03:56 PM, Johannes Berg wrote:
> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>
>> However, it's also possible to actually *use* the new mac80211 feature.
>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>> may be quicker.
>
> This might do it, I haven't tested it at all:
>
> http://p.sipsolutions.net/3c6b003bb06e5298.txt

With that patch, the driver never loads the firmware. I have not yet found the 
reason.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/07/2012 03:56 PM, Johannes Berg wrote:
> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>
>> However, it's also possible to actually *use* the new mac80211 feature.
>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>> may be quicker.
>
> This might do it, I haven't tested it at all:
>
> http://p.sipsolutions.net/3c6b003bb06e5298.txt

With that patch, the driver never loads the firmware. I have not yet found the 
reason.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/07/2012 03:56 PM, Johannes Berg wrote:
>>
>> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>>
>>> However, it's also possible to actually *use* the new mac80211 feature.
>>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>>> may be quicker.
>>
>>
>> This might do it, I haven't tested it at all:
>>
>> http://p.sipsolutions.net/3c6b003bb06e5298.txt
>
>
> With that patch, the driver never loads the firmware. I have not yet found
> the reason.

Same here.

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/07/2012 03:56 PM, Johannes Berg wrote:
>>
>> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>>
>>> However, it's also possible to actually *use* the new mac80211 feature.
>>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>>> may be quicker.
>>
>>
>> This might do it, I haven't tested it at all:
>>
>> http://p.sipsolutions.net/3c6b003bb06e5298.txt
>
>
> With that patch, the driver never loads the firmware. I have not yet found
> the reason.

Same here.

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
> On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 06/07/2012 03:56 PM, Johannes Berg wrote:
> >>
> >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
> >>
> >>> However, it's also possible to actually *use* the new mac80211 feature.
> >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> >>> may be quicker.
> >>
> >>
> >> This might do it, I haven't tested it at all:
> >>
> >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
> >
> >
> > With that patch, the driver never loads the firmware. I have not yet found
> > the reason.
> 
> Same here.

It doesn't start any interfaces, right?

The patch was incomplete -- it has to register all 5 queues not but
might not use them, please try this:
http://p.sipsolutions.net/69a78bbb83cd6421.txt

(and if it still fails, please let me know how far it gets)

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
> On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > On 06/07/2012 03:56 PM, Johannes Berg wrote:
> >>
> >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
> >>
> >>> However, it's also possible to actually *use* the new mac80211 feature.
> >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> >>> may be quicker.
> >>
> >>
> >> This might do it, I haven't tested it at all:
> >>
> >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
> >
> >
> > With that patch, the driver never loads the firmware. I have not yet found
> > the reason.
> 
> Same here.

It doesn't start any interfaces, right?

The patch was incomplete -- it has to register all 5 queues not but
might not use them, please try this:
http://p.sipsolutions.net/69a78bbb83cd6421.txt

(and if it still fails, please let me know how far it gets)

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 08:27 +0200, Johannes Berg wrote:
> On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
> > On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > > On 06/07/2012 03:56 PM, Johannes Berg wrote:
> > >>
> > >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
> > >>
> > >>> However, it's also possible to actually *use* the new mac80211 feature.
> > >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> > >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> > >>> may be quicker.
> > >>
> > >>
> > >> This might do it, I haven't tested it at all:
> > >>
> > >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
> > >
> > >
> > > With that patch, the driver never loads the firmware. I have not yet found
> > > the reason.
> > 
> > Same here.
> 
> It doesn't start any interfaces, right?
> 
> The patch was incomplete -- it has to register all 5 queues not but
> might not use them, please try this:
> http://p.sipsolutions.net/69a78bbb83cd6421.txt

No, this was wrong too, I forgot to correct the condition in
add_interface, this should be right:

http://p.sipsolutions.net/854d460da251f9d6.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 08:27 +0200, Johannes Berg wrote:
> On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
> > On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> > > On 06/07/2012 03:56 PM, Johannes Berg wrote:
> > >>
> > >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
> > >>
> > >>> However, it's also possible to actually *use* the new mac80211 feature.
> > >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
> > >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
> > >>> may be quicker.
> > >>
> > >>
> > >> This might do it, I haven't tested it at all:
> > >>
> > >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
> > >
> > >
> > > With that patch, the driver never loads the firmware. I have not yet found
> > > the reason.
> > 
> > Same here.
> 
> It doesn't start any interfaces, right?
> 
> The patch was incomplete -- it has to register all 5 queues not but
> might not use them, please try this:
> http://p.sipsolutions.net/69a78bbb83cd6421.txt

No, this was wrong too, I forgot to correct the condition in
add_interface, this should be right:

http://p.sipsolutions.net/854d460da251f9d6.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 8:41 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 08:27 +0200, Johannes Berg wrote:
>> On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
>> > On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > > On 06/07/2012 03:56 PM, Johannes Berg wrote:
>> > >>
>> > >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>> > >>
>> > >>> However, it's also possible to actually *use* the new mac80211 feature.
>> > >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>> > >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>> > >>> may be quicker.
>> > >>
>> > >>
>> > >> This might do it, I haven't tested it at all:
>> > >>
>> > >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
>> > >
>> > >
>> > > With that patch, the driver never loads the firmware. I have not yet found
>> > > the reason.
>> >
>> > Same here.
>>
>> It doesn't start any interfaces, right?
>>
>> The patch was incomplete -- it has to register all 5 queues not but
>> might not use them, please try this:
>> http://p.sipsolutions.net/69a78bbb83cd6421.txt
>
> No, this was wrong too, I forgot to correct the condition in
> add_interface, this should be right:
>
> http://p.sipsolutions.net/854d460da251f9d6.txt

Sorry, still not loading any firmware.

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 8:41 AM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 08:27 +0200, Johannes Berg wrote:
>> On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
>> > On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
>> > > On 06/07/2012 03:56 PM, Johannes Berg wrote:
>> > >>
>> > >> On Thu, 2012-06-07 at 20:36 +0200, Johannes Berg wrote:
>> > >>
>> > >>> However, it's also possible to actually *use* the new mac80211 feature.
>> > >>> That would also help with IEEE80211_TX_CTL_SEND_AFTER_DTIM, you could
>> > >>> ask mac80211 to use a separate HW queue for it (for tx_ring_mcast.) This
>> > >>> may be quicker.
>> > >>
>> > >>
>> > >> This might do it, I haven't tested it at all:
>> > >>
>> > >> http://p.sipsolutions.net/3c6b003bb06e5298.txt
>> > >
>> > >
>> > > With that patch, the driver never loads the firmware. I have not yet found
>> > > the reason.
>> >
>> > Same here.
>>
>> It doesn't start any interfaces, right?
>>
>> The patch was incomplete -- it has to register all 5 queues not but
>> might not use them, please try this:
>> http://p.sipsolutions.net/69a78bbb83cd6421.txt
>
> No, this was wrong too, I forgot to correct the condition in
> add_interface, this should be right:
>
> http://p.sipsolutions.net/854d460da251f9d6.txt

Sorry, still not loading any firmware.

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 15:49 +0200, Andre Heider wrote:

> > http://p.sipsolutions.net/854d460da251f9d6.txt
> 
> Sorry, still not loading any firmware.

So you're going to have to tell me what happens :-)

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 15:49 +0200, Andre Heider wrote:

> > http://p.sipsolutions.net/854d460da251f9d6.txt
> 
> Sorry, still not loading any firmware.

So you're going to have to tell me what happens :-)

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 4:52 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 15:49 +0200, Andre Heider wrote:
>
>> > http://p.sipsolutions.net/854d460da251f9d6.txt
>>
>> Sorry, still not loading any firmware.
>
> So you're going to have to tell me what happens :-)

Well, nothing ;)

I just see this in dmesg:

[    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[    1.096506] ssb: chipcommon status is 0x0
[    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)

Hence the device doesn't get up and there's no way for me to interact
with the system.

With my "return 0;" hack instead of your patch I get:

[    0.863883] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    0.881444] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    0.897382] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    0.943958] devtmpfs: mounted
[    0.958308] Freeing unused kernel memory: 148k freed
[    0.996678] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
<30>[    1.897025] udevd[111]: starting version 175
[    4.818395] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
extents:1 across:152552k SS
[    4.932077] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.300479] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
[    9.197482] b43-phy0: Loading OpenSource firmware version 410.31754
[    9.210490] b43-phy0: Hardware crypto acceleration not supported by firmware
[    9.224923] b43-phy0: QoS not supported by firmware

This is a kernel without module and initramfs support.

Regards,
Andre

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 4:52 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 15:49 +0200, Andre Heider wrote:
>
>> > http://p.sipsolutions.net/854d460da251f9d6.txt
>>
>> Sorry, still not loading any firmware.
>
> So you're going to have to tell me what happens :-)

Well, nothing ;)

I just see this in dmesg:

[    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[    1.096506] ssb: chipcommon status is 0x0
[    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)

Hence the device doesn't get up and there's no way for me to interact
with the system.

With my "return 0;" hack instead of your patch I get:

[    0.863883] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    0.881444] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    0.897382] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    0.943958] devtmpfs: mounted
[    0.958308] Freeing unused kernel memory: 148k freed
[    0.996678] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
<30>[    1.897025] udevd[111]: starting version 175
[    4.818395] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
extents:1 across:152552k SS
[    4.932077] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    5.300479] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
[    9.197482] b43-phy0: Loading OpenSource firmware version 410.31754
[    9.210490] b43-phy0: Hardware crypto acceleration not supported by firmware
[    9.224923] b43-phy0: QoS not supported by firmware

This is a kernel without module and initramfs support.

Regards,
Andre

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:

> >> > http://p.sipsolutions.net/854d460da251f9d6.txt
> >>
> >> Sorry, still not loading any firmware.
> >
> > So you're going to have to tell me what happens :-)
> 
> Well, nothing ;)
> 
> I just see this in dmesg:
> 
> [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> [    1.096506] ssb: chipcommon status is 0x0
> [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> 
> Hence the device doesn't get up and there's no way for me to interact
> with the system.

Ok, well, bugger :-)

Can you go to main.c and print out the return value of
ieee80211_register_hw()? I have a feeling that's where the failure is
though I don't really know why.

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:

> >> > http://p.sipsolutions.net/854d460da251f9d6.txt
> >>
> >> Sorry, still not loading any firmware.
> >
> > So you're going to have to tell me what happens :-)
> 
> Well, nothing ;)
> 
> I just see this in dmesg:
> 
> [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> [    1.096506] ssb: chipcommon status is 0x0
> [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> 
> Hence the device doesn't get up and there's no way for me to interact
> with the system.

Ok, well, bugger :-)

Can you go to main.c and print out the return value of
ieee80211_register_hw()? I have a feeling that's where the failure is
though I don't really know why.

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
> 
> > >> > http://p.sipsolutions.net/854d460da251f9d6.txt
> > >>
> > >> Sorry, still not loading any firmware.
> > >
> > > So you're going to have to tell me what happens :-)
> > 
> > Well, nothing ;)
> > 
> > I just see this in dmesg:
> > 
> > [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> > [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> > [    1.096506] ssb: chipcommon status is 0x0
> > [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> > 
> > Hence the device doesn't get up and there's no way for me to interact
> > with the system.
> 
> Ok, well, bugger :-)
> 
> Can you go to main.c and print out the return value of
> ieee80211_register_hw()? I have a feeling that's where the failure is
> though I don't really know why.

No, wait, I do know why. Sorry!

Try this new version of the patch:
http://p.sipsolutions.net/3f75b09af68fd455.txt

If my hunch is right then we need to figure out how to not allow
off-channel or something.

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
> 
> > >> > http://p.sipsolutions.net/854d460da251f9d6.txt
> > >>
> > >> Sorry, still not loading any firmware.
> > >
> > > So you're going to have to tell me what happens :-)
> > 
> > Well, nothing ;)
> > 
> > I just see this in dmesg:
> > 
> > [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> > [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> > [    1.096506] ssb: chipcommon status is 0x0
> > [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> > 
> > Hence the device doesn't get up and there's no way for me to interact
> > with the system.
> 
> Ok, well, bugger :-)
> 
> Can you go to main.c and print out the return value of
> ieee80211_register_hw()? I have a feeling that's where the failure is
> though I don't really know why.

No, wait, I do know why. Sorry!

Try this new version of the patch:
http://p.sipsolutions.net/3f75b09af68fd455.txt

If my hunch is right then we need to figure out how to not allow
off-channel or something.

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
>> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
>>
>> > >> > http://p.sipsolutions.net/854d460da251f9d6.txt
>> > >>
>> > >> Sorry, still not loading any firmware.
>> > >
>> > > So you're going to have to tell me what happens :-)
>> >
>> > Well, nothing ;)
>> >
>> > I just see this in dmesg:
>> >
>> > [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> > [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
>> > [    1.096506] ssb: chipcommon status is 0x0
>> > [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> >
>> > Hence the device doesn't get up and there's no way for me to interact
>> > with the system.
>>
>> Ok, well, bugger :-)
>>
>> Can you go to main.c and print out the return value of
>> ieee80211_register_hw()? I have a feeling that's where the failure is
>> though I don't really know why.
>
> No, wait, I do know why. Sorry!
>
> Try this new version of the patch:
> http://p.sipsolutions.net/3f75b09af68fd455.txt
>
> If my hunch is right then we need to figure out how to not allow
> off-channel or something.

Now we do have a firmware, but still no working device ;)

[    0.553905] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    0.561166] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[    0.568378] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
[    0.582703] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09,
vendor 0x4243)
[    0.597831] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
[    0.613445] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
[    0.629924] ssb: chipcommon status is 0x0
[    0.638689] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    0.651588] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    0.668126] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    0.688275] devtmpfs: mounted
[    0.698550] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
[    0.709359] Freeing unused kernel memory: 148k freed
[    0.719464] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
0x2050, Revision 8
[    0.775832] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
<30>[    1.691732] udevd[110]: starting version 175
[    3.438357] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    4.274918] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
extents:1 across:152552k SS
[    4.402116] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    4.813161] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
[    8.880236] b43-phy0: Loading OpenSource firmware version 410.31754
[    8.897893] b43-phy0: Hardware crypto acceleration not supported by firmware
[    8.915844] b43-phy0: QoS not supported by firmware
[    9.292779] b43-phy0 debug: Chip initialized
[    9.312654] b43-phy0 debug: PIO initialized
[    9.323317] b43-phy0 debug: QoS disabled
[    9.512150] b43-phy0 debug: Wireless interface started
[    9.654251] b43-phy0 debug: Adding Interface type 2
[   11.371154] b43-phy0 ERROR: MAC suspend failed
[   11.811166] b43-phy0 ERROR: MAC suspend failed
[   12.235095] b43-phy0 ERROR: MAC suspend failed
[   12.639094] b43-phy0 ERROR: MAC suspend failed
[   13.043095] b43-phy0 ERROR: MAC suspend failed
[   13.447165] b43-phy0 ERROR: MAC suspend failed
[   13.851095] b43-phy0 ERROR: MAC suspend failed
[   14.255095] b43-phy0 ERROR: MAC suspend failed
[   14.655095] b43-phy0 ERROR: MAC suspend failed
[   15.055095] b43-phy0 ERROR: MAC suspend failed
[   16.383095] net_ratelimit: 2 callbacks suppressed
[   16.389679] b43-phy0 ERROR: MAC suspend failed
[   16.859094] b43-phy0 ERROR: MAC suspend failed
[   17.207095] b43-phy0 ERROR: MAC suspend failed
[   17.535095] b43-phy0 ERROR: MAC suspend failed
[   21.863095] b43-phy0 ERROR: MAC suspend failed
[   22.191095] b43-phy0 ERROR: MAC suspend failed
[   22.527096] b43-phy0 ERROR: MAC suspend failed
[   22.919095] b43-phy0 ERROR: MAC suspend failed
[   23.319095] b43-phy0 ERROR: MAC suspend failed
[   23.719094] b43-phy0 ERROR: MAC suspend failed
[   24.119094] b43-phy0 ERROR: MAC suspend failed
[   24.519095] b43-phy0 ERROR: MAC suspend failed
[   24.919095] b43-phy0 ERROR: MAC suspend failed
[   25.267095] b43-phy0 ERROR: MAC suspend failed
[   27.207095] net_ratelimit: 4 callbacks suppressed
[   27.210643] b43-phy0 ERROR: MAC suspend failed
[   27.675094] b43-phy0 ERROR: MAC suspend failed
[   28.139094] b43-phy0 ERROR: MAC suspend failed
[   28.607095] b43-phy0 ERROR: MAC suspend failed
[   28.951095] b43-phy0 ERROR: MAC suspend failed
[   29.275094] b43-phy0 ERROR: MAC suspend failed
[   33.615095] b43-phy0 ERROR: MAC suspend failed
[   33.939095] b43-phy0 ERROR: MAC suspend failed
[   34.275095] b43-phy0 ERROR: MAC suspend failed
[   34.663095] b43-phy0 ERROR: MAC suspend failed
[   35.059095] b43-phy0 ERROR: MAC suspend failed
[   35.455095] b43-phy0 ERROR: MAC suspend failed
[   35.851095] b43-phy0 ERROR: MAC suspend failed
[   36.247095] b43-phy0 ERROR: MAC suspend failed
[   36.643095] b43-phy0 ERROR: MAC suspend failed
[   37.039095] b43-phy0 ERROR: MAC suspend failed
[   39.087095] net_ratelimit: 4 callbacks suppressed
[   39.089274] b43-phy0 ERROR: MAC suspend failed
[   39.555111] b43-phy0 ERROR: MAC suspend failed
[   40.023095] b43-phy0 ERROR: MAC suspend failed
[   40.367094] b43-phy0 ERROR: MAC suspend failed
[   40.691159] b43-phy0 ERROR: MAC suspend failed
[   40.868103] b43-phy0 ERROR: Firmware watchdog: The firmware died!
[   40.870979] b43-phy0: Controller RESET (Firmware watchdog) ...
[   41.195093] b43-phy0 ERROR: MAC suspend failed
[   41.198361] b43-phy0 debug: Wireless interface stopped
[   42.204236] b43-phy0: Loading OpenSource firmware version 410.31754
[   42.208043] b43-phy0: Hardware crypto acceleration not supported by firmware
[   42.215386] b43-phy0: QoS not supported by firmware
[   42.588772] b43-phy0 debug: Chip initialized
[   42.603881] b43-phy0 debug: PIO initialized
[   42.610060] b43-phy0 debug: QoS disabled
[   42.794869] b43-phy0 debug: Wireless interface started
[   42.818522] b43-phy0: Controller restarted
[   45.107095] b43-phy0 ERROR: MAC suspend failed
[   45.507095] b43-phy0 ERROR: MAC suspend failed

I let it retry the load/die cycle >5 times, seems to repeat endlessly.

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
>> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
>>
>> > >> > http://p.sipsolutions.net/854d460da251f9d6.txt
>> > >>
>> > >> Sorry, still not loading any firmware.
>> > >
>> > > So you're going to have to tell me what happens :-)
>> >
>> > Well, nothing ;)
>> >
>> > I just see this in dmesg:
>> >
>> > [ ? ?1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>> > [ ? ?1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
>> > [ ? ?1.096506] ssb: chipcommon status is 0x0
>> > [ ? ?1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>> >
>> > Hence the device doesn't get up and there's no way for me to interact
>> > with the system.
>>
>> Ok, well, bugger :-)
>>
>> Can you go to main.c and print out the return value of
>> ieee80211_register_hw()? I have a feeling that's where the failure is
>> though I don't really know why.
>
> No, wait, I do know why. Sorry!
>
> Try this new version of the patch:
> http://p.sipsolutions.net/3f75b09af68fd455.txt
>
> If my hunch is right then we need to figure out how to not allow
> off-channel or something.

Now we do have a firmware, but still no working device ;)

[    0.553905] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
[    0.561166] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[    0.568378] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
[    0.582703] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09,
vendor 0x4243)
[    0.597831] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
[    0.613445] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
[    0.629924] ssb: chipcommon status is 0x0
[    0.638689] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
[    0.651588] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
data mode. Opts: (null)
[    0.668126] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[    0.688275] devtmpfs: mounted
[    0.698550] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
[    0.709359] Freeing unused kernel memory: 148k freed
[    0.719464] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
0x2050, Revision 8
[    0.775832] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
<30>[    1.691732] udevd[110]: starting version 175
[    3.438357] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[    4.274918] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
extents:1 across:152552k SS
[    4.402116] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
[    4.813161] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
[    8.880236] b43-phy0: Loading OpenSource firmware version 410.31754
[    8.897893] b43-phy0: Hardware crypto acceleration not supported by firmware
[    8.915844] b43-phy0: QoS not supported by firmware
[    9.292779] b43-phy0 debug: Chip initialized
[    9.312654] b43-phy0 debug: PIO initialized
[    9.323317] b43-phy0 debug: QoS disabled
[    9.512150] b43-phy0 debug: Wireless interface started
[    9.654251] b43-phy0 debug: Adding Interface type 2
[   11.371154] b43-phy0 ERROR: MAC suspend failed
[   11.811166] b43-phy0 ERROR: MAC suspend failed
[   12.235095] b43-phy0 ERROR: MAC suspend failed
[   12.639094] b43-phy0 ERROR: MAC suspend failed
[   13.043095] b43-phy0 ERROR: MAC suspend failed
[   13.447165] b43-phy0 ERROR: MAC suspend failed
[   13.851095] b43-phy0 ERROR: MAC suspend failed
[   14.255095] b43-phy0 ERROR: MAC suspend failed
[   14.655095] b43-phy0 ERROR: MAC suspend failed
[   15.055095] b43-phy0 ERROR: MAC suspend failed
[   16.383095] net_ratelimit: 2 callbacks suppressed
[   16.389679] b43-phy0 ERROR: MAC suspend failed
[   16.859094] b43-phy0 ERROR: MAC suspend failed
[   17.207095] b43-phy0 ERROR: MAC suspend failed
[   17.535095] b43-phy0 ERROR: MAC suspend failed
[   21.863095] b43-phy0 ERROR: MAC suspend failed
[   22.191095] b43-phy0 ERROR: MAC suspend failed
[   22.527096] b43-phy0 ERROR: MAC suspend failed
[   22.919095] b43-phy0 ERROR: MAC suspend failed
[   23.319095] b43-phy0 ERROR: MAC suspend failed
[   23.719094] b43-phy0 ERROR: MAC suspend failed
[   24.119094] b43-phy0 ERROR: MAC suspend failed
[   24.519095] b43-phy0 ERROR: MAC suspend failed
[   24.919095] b43-phy0 ERROR: MAC suspend failed
[   25.267095] b43-phy0 ERROR: MAC suspend failed
[   27.207095] net_ratelimit: 4 callbacks suppressed
[   27.210643] b43-phy0 ERROR: MAC suspend failed
[   27.675094] b43-phy0 ERROR: MAC suspend failed
[   28.139094] b43-phy0 ERROR: MAC suspend failed
[   28.607095] b43-phy0 ERROR: MAC suspend failed
[   28.951095] b43-phy0 ERROR: MAC suspend failed
[   29.275094] b43-phy0 ERROR: MAC suspend failed
[   33.615095] b43-phy0 ERROR: MAC suspend failed
[   33.939095] b43-phy0 ERROR: MAC suspend failed
[   34.275095] b43-phy0 ERROR: MAC suspend failed
[   34.663095] b43-phy0 ERROR: MAC suspend failed
[   35.059095] b43-phy0 ERROR: MAC suspend failed
[   35.455095] b43-phy0 ERROR: MAC suspend failed
[   35.851095] b43-phy0 ERROR: MAC suspend failed
[   36.247095] b43-phy0 ERROR: MAC suspend failed
[   36.643095] b43-phy0 ERROR: MAC suspend failed
[   37.039095] b43-phy0 ERROR: MAC suspend failed
[   39.087095] net_ratelimit: 4 callbacks suppressed
[   39.089274] b43-phy0 ERROR: MAC suspend failed
[   39.555111] b43-phy0 ERROR: MAC suspend failed
[   40.023095] b43-phy0 ERROR: MAC suspend failed
[   40.367094] b43-phy0 ERROR: MAC suspend failed
[   40.691159] b43-phy0 ERROR: MAC suspend failed
[   40.868103] b43-phy0 ERROR: Firmware watchdog: The firmware died!
[   40.870979] b43-phy0: Controller RESET (Firmware watchdog) ...
[   41.195093] b43-phy0 ERROR: MAC suspend failed
[   41.198361] b43-phy0 debug: Wireless interface stopped
[   42.204236] b43-phy0: Loading OpenSource firmware version 410.31754
[   42.208043] b43-phy0: Hardware crypto acceleration not supported by firmware
[   42.215386] b43-phy0: QoS not supported by firmware
[   42.588772] b43-phy0 debug: Chip initialized
[   42.603881] b43-phy0 debug: PIO initialized
[   42.610060] b43-phy0 debug: QoS disabled
[   42.794869] b43-phy0 debug: Wireless interface started
[   42.818522] b43-phy0: Controller restarted
[   45.107095] b43-phy0 ERROR: MAC suspend failed
[   45.507095] b43-phy0 ERROR: MAC suspend failed

I let it retry the load/die cycle >5 times, seems to repeat endlessly.

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 10:25 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
>>> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
>>>
>>>>>>> http://p.sipsolutions.net/854d460da251f9d6.txt
>>>>>>
>>>>>> Sorry, still not loading any firmware.
>>>>>
>>>>> So you're going to have to tell me what happens :-)
>>>>
>>>> Well, nothing ;)
>>>>
>>>> I just see this in dmesg:
>>>>
>>>> [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
>>>> [    1.096506] ssb: chipcommon status is 0x0
>>>> [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>>>>
>>>> Hence the device doesn't get up and there's no way for me to interact
>>>> with the system.
>>>
>>> Ok, well, bugger :-)
>>>
>>> Can you go to main.c and print out the return value of
>>> ieee80211_register_hw()? I have a feeling that's where the failure is
>>> though I don't really know why.
>>
>> No, wait, I do know why. Sorry!
>>
>> Try this new version of the patch:
>> http://p.sipsolutions.net/3f75b09af68fd455.txt
>>
>> If my hunch is right then we need to figure out how to not allow
>> off-channel or something.
>
> Now we do have a firmware, but still no working device ;)
>
> [    0.553905] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [    0.561166] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> [    0.568378] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> [    0.582703] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09,
> vendor 0x4243)
> [    0.597831] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> [    0.613445] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> [    0.629924] ssb: chipcommon status is 0x0
> [    0.638689] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> [    0.651588] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [    0.668126] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
> [    0.688275] devtmpfs: mounted
> [    0.698550] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
> [    0.709359] Freeing unused kernel memory: 148k freed
> [    0.719464] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
> 0x2050, Revision 8
> [    0.775832] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> <30>[    1.691732] udevd[110]: starting version 175
> [    3.438357] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [    4.274918] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
> extents:1 across:152552k SS
> [    4.402116] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> [    4.813161] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
> [    8.880236] b43-phy0: Loading OpenSource firmware version 410.31754
> [    8.897893] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    8.915844] b43-phy0: QoS not supported by firmware
> [    9.292779] b43-phy0 debug: Chip initialized
> [    9.312654] b43-phy0 debug: PIO initialized
> [    9.323317] b43-phy0 debug: QoS disabled
> [    9.512150] b43-phy0 debug: Wireless interface started
> [    9.654251] b43-phy0 debug: Adding Interface type 2
> [   11.371154] b43-phy0 ERROR: MAC suspend failed
> [   11.811166] b43-phy0 ERROR: MAC suspend failed
> [   12.235095] b43-phy0 ERROR: MAC suspend failed
> [   12.639094] b43-phy0 ERROR: MAC suspend failed
> [   13.043095] b43-phy0 ERROR: MAC suspend failed
> [   13.447165] b43-phy0 ERROR: MAC suspend failed
> [   13.851095] b43-phy0 ERROR: MAC suspend failed
> [   14.255095] b43-phy0 ERROR: MAC suspend failed
> [   14.655095] b43-phy0 ERROR: MAC suspend failed
> [   15.055095] b43-phy0 ERROR: MAC suspend failed
> [   16.383095] net_ratelimit: 2 callbacks suppressed
> [   16.389679] b43-phy0 ERROR: MAC suspend failed
> [   16.859094] b43-phy0 ERROR: MAC suspend failed
> [   17.207095] b43-phy0 ERROR: MAC suspend failed
> [   17.535095] b43-phy0 ERROR: MAC suspend failed
> [   21.863095] b43-phy0 ERROR: MAC suspend failed
> [   22.191095] b43-phy0 ERROR: MAC suspend failed
> [   22.527096] b43-phy0 ERROR: MAC suspend failed
> [   22.919095] b43-phy0 ERROR: MAC suspend failed
> [   23.319095] b43-phy0 ERROR: MAC suspend failed
> [   23.719094] b43-phy0 ERROR: MAC suspend failed
> [   24.119094] b43-phy0 ERROR: MAC suspend failed
> [   24.519095] b43-phy0 ERROR: MAC suspend failed
> [   24.919095] b43-phy0 ERROR: MAC suspend failed
> [   25.267095] b43-phy0 ERROR: MAC suspend failed
> [   27.207095] net_ratelimit: 4 callbacks suppressed
> [   27.210643] b43-phy0 ERROR: MAC suspend failed
> [   27.675094] b43-phy0 ERROR: MAC suspend failed
> [   28.139094] b43-phy0 ERROR: MAC suspend failed
> [   28.607095] b43-phy0 ERROR: MAC suspend failed
> [   28.951095] b43-phy0 ERROR: MAC suspend failed
> [   29.275094] b43-phy0 ERROR: MAC suspend failed
> [   33.615095] b43-phy0 ERROR: MAC suspend failed
> [   33.939095] b43-phy0 ERROR: MAC suspend failed
> [   34.275095] b43-phy0 ERROR: MAC suspend failed
> [   34.663095] b43-phy0 ERROR: MAC suspend failed
> [   35.059095] b43-phy0 ERROR: MAC suspend failed
> [   35.455095] b43-phy0 ERROR: MAC suspend failed
> [   35.851095] b43-phy0 ERROR: MAC suspend failed
> [   36.247095] b43-phy0 ERROR: MAC suspend failed
> [   36.643095] b43-phy0 ERROR: MAC suspend failed
> [   37.039095] b43-phy0 ERROR: MAC suspend failed
> [   39.087095] net_ratelimit: 4 callbacks suppressed
> [   39.089274] b43-phy0 ERROR: MAC suspend failed
> [   39.555111] b43-phy0 ERROR: MAC suspend failed
> [   40.023095] b43-phy0 ERROR: MAC suspend failed
> [   40.367094] b43-phy0 ERROR: MAC suspend failed
> [   40.691159] b43-phy0 ERROR: MAC suspend failed
> [   40.868103] b43-phy0 ERROR: Firmware watchdog: The firmware died!
> [   40.870979] b43-phy0: Controller RESET (Firmware watchdog) ...
> [   41.195093] b43-phy0 ERROR: MAC suspend failed
> [   41.198361] b43-phy0 debug: Wireless interface stopped
> [   42.204236] b43-phy0: Loading OpenSource firmware version 410.31754
> [   42.208043] b43-phy0: Hardware crypto acceleration not supported by firmware
> [   42.215386] b43-phy0: QoS not supported by firmware
> [   42.588772] b43-phy0 debug: Chip initialized
> [   42.603881] b43-phy0 debug: PIO initialized
> [   42.610060] b43-phy0 debug: QoS disabled
> [   42.794869] b43-phy0 debug: Wireless interface started
> [   42.818522] b43-phy0: Controller restarted
> [   45.107095] b43-phy0 ERROR: MAC suspend failed
> [   45.507095] b43-phy0 ERROR: MAC suspend failed
>
> I let it retry the load/die cycle >5 times, seems to repeat endlessly.
>

I got the same result as Andre when using open-source firmware - endless MAC 
suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
module parameter.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 10:25 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Fri, 2012-06-08 at 17:14 +0200, Johannes Berg wrote:
>>> On Fri, 2012-06-08 at 17:04 +0200, Andre Heider wrote:
>>>
>>>>>>> http://p.sipsolutions.net/854d460da251f9d6.txt
>>>>>>
>>>>>> Sorry, still not loading any firmware.
>>>>>
>>>>> So you're going to have to tell me what happens :-)
>>>>
>>>> Well, nothing ;)
>>>>
>>>> I just see this in dmesg:
>>>>
>>>> [    1.012107] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
>>>> [    1.018765] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
>>>> [    1.096506] ssb: chipcommon status is 0x0
>>>> [    1.105314] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
>>>>
>>>> Hence the device doesn't get up and there's no way for me to interact
>>>> with the system.
>>>
>>> Ok, well, bugger :-)
>>>
>>> Can you go to main.c and print out the return value of
>>> ieee80211_register_hw()? I have a feeling that's where the failure is
>>> though I don't really know why.
>>
>> No, wait, I do know why. Sorry!
>>
>> Try this new version of the patch:
>> http://p.sipsolutions.net/3f75b09af68fd455.txt
>>
>> If my hunch is right then we need to figure out how to not allow
>> off-channel or something.
>
> Now we do have a firmware, but still no working device ;)
>
> [    0.553905] b43-sdio mmc1:0001:1: Chip ID 14e4:4318
> [    0.561166] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
> [    0.568378] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
> [    0.582703] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09,
> vendor 0x4243)
> [    0.597831] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
> [    0.613445] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
> [    0.629924] ssb: chipcommon status is 0x0
> [    0.638689] b43-phy0: Broadcom 4318 WLAN found (core revision 9)
> [    0.651588] EXT4-fs (mmcblk0p2): mounted filesystem with ordered
> data mode. Opts: (null)
> [    0.668126] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
> [    0.688275] devtmpfs: mounted
> [    0.698550] b43-phy0 debug: Found PHY: Analog 3, Type 2, Revision 7
> [    0.709359] Freeing unused kernel memory: 148k freed
> [    0.719464] b43-phy0 debug: Found Radio: Manuf 0x17F, Version
> 0x2050, Revision 8
> [    0.775832] ssb: Sonics Silicon Backplane found on SDIO device mmc1:0001:1
> <30>[    1.691732] udevd[110]: starting version 175
> [    3.438357] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
> [    4.274918] Adding 152552k swap on /dev/mmcblk0p3.  Priority:-1
> extents:1 across:152552k SS
> [    4.402116] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> [    4.813161] EXT4-fs (mmcblk0p2): re-mounted. Opts: discard,errors=remount-ro
> [    8.880236] b43-phy0: Loading OpenSource firmware version 410.31754
> [    8.897893] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    8.915844] b43-phy0: QoS not supported by firmware
> [    9.292779] b43-phy0 debug: Chip initialized
> [    9.312654] b43-phy0 debug: PIO initialized
> [    9.323317] b43-phy0 debug: QoS disabled
> [    9.512150] b43-phy0 debug: Wireless interface started
> [    9.654251] b43-phy0 debug: Adding Interface type 2
> [   11.371154] b43-phy0 ERROR: MAC suspend failed
> [   11.811166] b43-phy0 ERROR: MAC suspend failed
> [   12.235095] b43-phy0 ERROR: MAC suspend failed
> [   12.639094] b43-phy0 ERROR: MAC suspend failed
> [   13.043095] b43-phy0 ERROR: MAC suspend failed
> [   13.447165] b43-phy0 ERROR: MAC suspend failed
> [   13.851095] b43-phy0 ERROR: MAC suspend failed
> [   14.255095] b43-phy0 ERROR: MAC suspend failed
> [   14.655095] b43-phy0 ERROR: MAC suspend failed
> [   15.055095] b43-phy0 ERROR: MAC suspend failed
> [   16.383095] net_ratelimit: 2 callbacks suppressed
> [   16.389679] b43-phy0 ERROR: MAC suspend failed
> [   16.859094] b43-phy0 ERROR: MAC suspend failed
> [   17.207095] b43-phy0 ERROR: MAC suspend failed
> [   17.535095] b43-phy0 ERROR: MAC suspend failed
> [   21.863095] b43-phy0 ERROR: MAC suspend failed
> [   22.191095] b43-phy0 ERROR: MAC suspend failed
> [   22.527096] b43-phy0 ERROR: MAC suspend failed
> [   22.919095] b43-phy0 ERROR: MAC suspend failed
> [   23.319095] b43-phy0 ERROR: MAC suspend failed
> [   23.719094] b43-phy0 ERROR: MAC suspend failed
> [   24.119094] b43-phy0 ERROR: MAC suspend failed
> [   24.519095] b43-phy0 ERROR: MAC suspend failed
> [   24.919095] b43-phy0 ERROR: MAC suspend failed
> [   25.267095] b43-phy0 ERROR: MAC suspend failed
> [   27.207095] net_ratelimit: 4 callbacks suppressed
> [   27.210643] b43-phy0 ERROR: MAC suspend failed
> [   27.675094] b43-phy0 ERROR: MAC suspend failed
> [   28.139094] b43-phy0 ERROR: MAC suspend failed
> [   28.607095] b43-phy0 ERROR: MAC suspend failed
> [   28.951095] b43-phy0 ERROR: MAC suspend failed
> [   29.275094] b43-phy0 ERROR: MAC suspend failed
> [   33.615095] b43-phy0 ERROR: MAC suspend failed
> [   33.939095] b43-phy0 ERROR: MAC suspend failed
> [   34.275095] b43-phy0 ERROR: MAC suspend failed
> [   34.663095] b43-phy0 ERROR: MAC suspend failed
> [   35.059095] b43-phy0 ERROR: MAC suspend failed
> [   35.455095] b43-phy0 ERROR: MAC suspend failed
> [   35.851095] b43-phy0 ERROR: MAC suspend failed
> [   36.247095] b43-phy0 ERROR: MAC suspend failed
> [   36.643095] b43-phy0 ERROR: MAC suspend failed
> [   37.039095] b43-phy0 ERROR: MAC suspend failed
> [   39.087095] net_ratelimit: 4 callbacks suppressed
> [   39.089274] b43-phy0 ERROR: MAC suspend failed
> [   39.555111] b43-phy0 ERROR: MAC suspend failed
> [   40.023095] b43-phy0 ERROR: MAC suspend failed
> [   40.367094] b43-phy0 ERROR: MAC suspend failed
> [   40.691159] b43-phy0 ERROR: MAC suspend failed
> [   40.868103] b43-phy0 ERROR: Firmware watchdog: The firmware died!
> [   40.870979] b43-phy0: Controller RESET (Firmware watchdog) ...
> [   41.195093] b43-phy0 ERROR: MAC suspend failed
> [   41.198361] b43-phy0 debug: Wireless interface stopped
> [   42.204236] b43-phy0: Loading OpenSource firmware version 410.31754
> [   42.208043] b43-phy0: Hardware crypto acceleration not supported by firmware
> [   42.215386] b43-phy0: QoS not supported by firmware
> [   42.588772] b43-phy0 debug: Chip initialized
> [   42.603881] b43-phy0 debug: PIO initialized
> [   42.610060] b43-phy0 debug: QoS disabled
> [   42.794869] b43-phy0 debug: Wireless interface started
> [   42.818522] b43-phy0: Controller restarted
> [   45.107095] b43-phy0 ERROR: MAC suspend failed
> [   45.507095] b43-phy0 ERROR: MAC suspend failed
>
> I let it retry the load/die cycle >5 times, seems to repeat endlessly.
>

I got the same result as Andre when using open-source firmware - endless MAC 
suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
module parameter.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:25 +0200, Andre Heider wrote:


> [    9.654251] b43-phy0 debug: Adding Interface type 2
> [   11.371154] b43-phy0 ERROR: MAC suspend failed

That doesn't make much sense to me, the code paths related to that
shouldn't have changed, unless somehow some frame goes to the wrong
queue which would seem strange ...

Maybe you could print out what queues the frames go to or something ...
I don't even know what's happening in those seconds between those two
messages so I can't really help you much.

Regardless, I fixed some bugs in my patch related to mcast:
http://p.sipsolutions.net/4e1aec97842e0f72.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:25 +0200, Andre Heider wrote:


> [    9.654251] b43-phy0 debug: Adding Interface type 2
> [   11.371154] b43-phy0 ERROR: MAC suspend failed

That doesn't make much sense to me, the code paths related to that
shouldn't have changed, unless somehow some frame goes to the wrong
queue which would seem strange ...

Maybe you could print out what queues the frames go to or something ...
I don't even know what's happening in those seconds between those two
messages so I can't really help you much.

Regardless, I fixed some bugs in my patch related to mcast:
http://p.sipsolutions.net/4e1aec97842e0f72.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:

> I got the same result as Andre when using open-source firmware - endless MAC 
> suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> module parameter.

I just noticed one more bug -- I need to number the ACs the other way
around, changing
	vif->hw_queue[i] = i;
to
	vif->hw_queue[i] = 3 - i;

in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
mac80211.

http://p.sipsolutions.net/449d71a3c76656f1.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:

> I got the same result as Andre when using open-source firmware - endless MAC 
> suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> module parameter.

I just noticed one more bug -- I need to number the ACs the other way
around, changing
	vif->hw_queue[i] = i;
to
	vif->hw_queue[i] = 3 - i;

in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
mac80211.

http://p.sipsolutions.net/449d71a3c76656f1.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:43 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:
> 
> > I got the same result as Andre when using open-source firmware - endless MAC 
> > suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> > module parameter.
> 
> I just noticed one more bug -- I need to number the ACs the other way
> around, changing
> 	vif->hw_queue[i] = i;
> to
> 	vif->hw_queue[i] = 3 - i;
> 
> in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
> mac80211.
> 
> http://p.sipsolutions.net/449d71a3c76656f1.txt

Ahrg! I keep numbering them wrong, this should be fixed:
http://p.sipsolutions.net/3bbdb9c6294dad70.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:43 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:
> 
> > I got the same result as Andre when using open-source firmware - endless MAC 
> > suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> > module parameter.
> 
> I just noticed one more bug -- I need to number the ACs the other way
> around, changing
> 	vif->hw_queue[i] = i;
> to
> 	vif->hw_queue[i] = 3 - i;
> 
> in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
> mac80211.
> 
> http://p.sipsolutions.net/449d71a3c76656f1.txt

Ahrg! I keep numbering them wrong, this should be fixed:
http://p.sipsolutions.net/3bbdb9c6294dad70.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:44 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 17:43 +0200, Johannes Berg wrote:
> > On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:
> > 
> > > I got the same result as Andre when using open-source firmware - endless MAC 
> > > suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> > > module parameter.
> > 
> > I just noticed one more bug -- I need to number the ACs the other way
> > around, changing
> > 	vif->hw_queue[i] = i;
> > to
> > 	vif->hw_queue[i] = 3 - i;
> > 
> > in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
> > mac80211.
> > 
> > http://p.sipsolutions.net/449d71a3c76656f1.txt
> 
> Ahrg! I keep numbering them wrong, this should be fixed:
> http://p.sipsolutions.net/3bbdb9c6294dad70.txt

Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
info->index since now mac80211 is giving us the right *queue number*
rather than just *AC*

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:44 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 17:43 +0200, Johannes Berg wrote:
> > On Fri, 2012-06-08 at 10:38 -0500, Larry Finger wrote:
> > 
> > > I got the same result as Andre when using open-source firmware - endless MAC 
> > > suspend failures. It works OK with the proprietary fw, with or without a "qos=0" 
> > > module parameter.
> > 
> > I just noticed one more bug -- I need to number the ACs the other way
> > around, changing
> > 	vif->hw_queue[i] = i;
> > to
> > 	vif->hw_queue[i] = 3 - i;
> > 
> > in main.c, because 0 is BK and 3 is VO, rather than 0 VO/3 BK like in
> > mac80211.
> > 
> > http://p.sipsolutions.net/449d71a3c76656f1.txt
> 
> Ahrg! I keep numbering them wrong, this should be fixed:
> http://p.sipsolutions.net/3bbdb9c6294dad70.txt

Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
info->index since now mac80211 is giving us the right *queue number*
rather than just *AC*

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:48 +0200, Johannes Berg wrote:

> > Ahrg! I keep numbering them wrong, this should be fixed:
> > http://p.sipsolutions.net/3bbdb9c6294dad70.txt
> 
> Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
> info->index since now mac80211 is giving us the right *queue number*
> rather than just *AC*

Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:48 +0200, Johannes Berg wrote:

> > Ahrg! I keep numbering them wrong, this should be fixed:
> > http://p.sipsolutions.net/3bbdb9c6294dad70.txt
> 
> Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
> info->index since now mac80211 is giving us the right *queue number*
> rather than just *AC*

Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:52 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:48 +0200, Johannes Berg wrote:
>
>> > Ahrg! I keep numbering them wrong, this should be fixed:
>> > http://p.sipsolutions.net/3bbdb9c6294dad70.txt
>>
>> Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
>> info->index since now mac80211 is giving us the right *queue number*
>> rather than just *AC*
>
> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

The previous patched all had the mac suspend failure. This one:

drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
is negative
drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
is negative
drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
is negative

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:52 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:48 +0200, Johannes Berg wrote:
>
>> > Ahrg! I keep numbering them wrong, this should be fixed:
>> > http://p.sipsolutions.net/3bbdb9c6294dad70.txt
>>
>> Nope, still wrong, I shouldn't be using skb_get_queue_mapping but rather
>> info->index since now mac80211 is giving us the right *queue number*
>> rather than just *AC*
>
> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

The previous patched all had the mac suspend failure. This one:

drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
is negative
drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
is negative
drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
is negative

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:

> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
> 
> The previous patched all had the mac suspend failure. This one:
> 
> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
> is negative
> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
> is negative
> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
> is negative

Huh, I thought I compiled it ... guess I had the wrong version.

http://p.sipsolutions.net/511dda98892d2c9a.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:

> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
> 
> The previous patched all had the mac suspend failure. This one:
> 
> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
> is negative
> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
> is negative
> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
> is negative

Huh, I thought I compiled it ... guess I had the wrong version.

http://p.sipsolutions.net/511dda98892d2c9a.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>
>> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>>
>> The previous patched all had the mac suspend failure. This one:
>>
>> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>> is negative
>> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>> is negative
>> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>> is negative
>
> Huh, I thought I compiled it ... guess I had the wrong version.
>
> http://p.sipsolutions.net/511dda98892d2c9a.txt

It's getting warmer:

[    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
[    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
[    9.491781] b43-phy0: QoS not supported by firmware
[    9.868750] b43-phy0 debug: Chip initialized
[    9.888580] b43-phy0 debug: PIO initialized
[    9.899273] b43-phy0 debug: QoS disabled
[   10.088420] b43-phy0 debug: Wireless interface started
[   10.212209] b43-phy0 debug: Adding Interface type 2
[   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
[   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
[   12.811768] wlan0: authenticated
[   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
[   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
status=0 aid=2)
[   12.863966] wlan0: associated
[   16.319097] ieee80211 phy0: wlan0: No probe response from AP
d8:5d:4c:9c:31:14 after 500ms, disconnecting.
[   16.349674] cfg80211: Calling CRDA for country: DE
[   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
[   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
[   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
[   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
[   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out

Tried it 3 times, always times out.

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>
>> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>>
>> The previous patched all had the mac suspend failure. This one:
>>
>> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>> is negative
>> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>> is negative
>> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>> is negative
>
> Huh, I thought I compiled it ... guess I had the wrong version.
>
> http://p.sipsolutions.net/511dda98892d2c9a.txt

It's getting warmer:

[    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
[    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
[    9.491781] b43-phy0: QoS not supported by firmware
[    9.868750] b43-phy0 debug: Chip initialized
[    9.888580] b43-phy0 debug: PIO initialized
[    9.899273] b43-phy0 debug: QoS disabled
[   10.088420] b43-phy0 debug: Wireless interface started
[   10.212209] b43-phy0 debug: Adding Interface type 2
[   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
[   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
[   12.811768] wlan0: authenticated
[   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
[   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
status=0 aid=2)
[   12.863966] wlan0: associated
[   16.319097] ieee80211 phy0: wlan0: No probe response from AP
d8:5d:4c:9c:31:14 after 500ms, disconnecting.
[   16.349674] cfg80211: Calling CRDA for country: DE
[   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
[   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
[   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
[   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
[   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out

Tried it 3 times, always times out.

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
> >
> >> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
> >>
> >> The previous patched all had the mac suspend failure. This one:
> >>
> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
> >> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
> >> is negative
> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
> >> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
> >> is negative
> >> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
> >> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
> >> is negative
> >
> > Huh, I thought I compiled it ... guess I had the wrong version.
> >
> > http://p.sipsolutions.net/511dda98892d2c9a.txt
> 
> It's getting warmer:
> 
> [    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
> [    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    9.491781] b43-phy0: QoS not supported by firmware
> [    9.868750] b43-phy0 debug: Chip initialized
> [    9.888580] b43-phy0 debug: PIO initialized
> [    9.899273] b43-phy0 debug: QoS disabled
> [   10.088420] b43-phy0 debug: Wireless interface started
> [   10.212209] b43-phy0 debug: Adding Interface type 2
> [   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   12.811768] wlan0: authenticated
> [   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
> [   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
> status=0 aid=2)
> [   12.863966] wlan0: associated
> [   16.319097] ieee80211 phy0: wlan0: No probe response from AP
> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
> [   16.349674] cfg80211: Calling CRDA for country: DE
> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> 
> Tried it 3 times, always times out.

So you didn't get the warning, but can you still check what
info->hw_queue is in pio.c?

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
> >
> >> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
> >>
> >> The previous patched all had the mac suspend failure. This one:
> >>
> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
> >> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
> >> is negative
> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
> >> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
> >> is negative
> >> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
> >> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
> >> is negative
> >
> > Huh, I thought I compiled it ... guess I had the wrong version.
> >
> > http://p.sipsolutions.net/511dda98892d2c9a.txt
> 
> It's getting warmer:
> 
> [    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
> [    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    9.491781] b43-phy0: QoS not supported by firmware
> [    9.868750] b43-phy0 debug: Chip initialized
> [    9.888580] b43-phy0 debug: PIO initialized
> [    9.899273] b43-phy0 debug: QoS disabled
> [   10.088420] b43-phy0 debug: Wireless interface started
> [   10.212209] b43-phy0 debug: Adding Interface type 2
> [   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   12.811768] wlan0: authenticated
> [   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
> [   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
> status=0 aid=2)
> [   12.863966] wlan0: associated
> [   16.319097] ieee80211 phy0: wlan0: No probe response from AP
> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
> [   16.349674] cfg80211: Calling CRDA for country: DE
> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> 
> Tried it 3 times, always times out.

So you didn't get the warning, but can you still check what
info->hw_queue is in pio.c?

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 6:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
>> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>> >
>> >> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>> >>
>> >> The previous patched all had the mac suspend failure. This one:
>> >>
>> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>> >> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>> >> is negative
>> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>> >> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>> >> is negative
>> >> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>> >> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>> >> is negative
>> >
>> > Huh, I thought I compiled it ... guess I had the wrong version.
>> >
>> > http://p.sipsolutions.net/511dda98892d2c9a.txt
>>
>> It's getting warmer:
>>
>> [    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
>> [    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [    9.491781] b43-phy0: QoS not supported by firmware
>> [    9.868750] b43-phy0 debug: Chip initialized
>> [    9.888580] b43-phy0 debug: PIO initialized
>> [    9.899273] b43-phy0 debug: QoS disabled
>> [   10.088420] b43-phy0 debug: Wireless interface started
>> [   10.212209] b43-phy0 debug: Adding Interface type 2
>> [   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
>> [   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> [   12.811768] wlan0: authenticated
>> [   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
>> [   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
>> status=0 aid=2)
>> [   12.863966] wlan0: associated
>> [   16.319097] ieee80211 phy0: wlan0: No probe response from AP
>> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
>> [   16.349674] cfg80211: Calling CRDA for country: DE
>> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
>> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
>> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
>> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>>
>> Tried it 3 times, always times out.
>
> So you didn't get the warning, but can you still check what
> info->hw_queue is in pio.c?

always "1"

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 6:08 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
>> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> > On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>> >
>> >> > Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>> >>
>> >> The previous patched all had the mac suspend failure. This one:
>> >>
>> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>> >> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>> >> is negative
>> >> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>> >> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>> >> is negative
>> >> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>> >> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>> >> is negative
>> >
>> > Huh, I thought I compiled it ... guess I had the wrong version.
>> >
>> > http://p.sipsolutions.net/511dda98892d2c9a.txt
>>
>> It's getting warmer:
>>
>> [ ? ?9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
>> [ ? ?9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
>> [ ? ?9.491781] b43-phy0: QoS not supported by firmware
>> [ ? ?9.868750] b43-phy0 debug: Chip initialized
>> [ ? ?9.888580] b43-phy0 debug: PIO initialized
>> [ ? ?9.899273] b43-phy0 debug: QoS disabled
>> [ ? 10.088420] b43-phy0 debug: Wireless interface started
>> [ ? 10.212209] b43-phy0 debug: Adding Interface type 2
>> [ ? 12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
>> [ ? 12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> [ ? 12.811768] wlan0: authenticated
>> [ ? 12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
>> [ ? 12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
>> status=0 aid=2)
>> [ ? 12.863966] wlan0: associated
>> [ ? 16.319097] ieee80211 phy0: wlan0: No probe response from AP
>> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
>> [ ? 16.349674] cfg80211: Calling CRDA for country: DE
>> [ ? 17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
>> [ ? 17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> [ ? 17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
>> [ ? 18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
>> [ ? 18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>>
>> Tried it 3 times, always times out.
>
> So you didn't get the warning, but can you still check what
> info->hw_queue is in pio.c?

always "1"

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:

> >> > http://p.sipsolutions.net/511dda98892d2c9a.txt

> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >>
> >> Tried it 3 times, always times out.
> >
> > So you didn't get the warning, but can you still check what
> > info->hw_queue is in pio.c?
> 
> always "1"

Ok, so that's correct. Hmm.

Can you check in mac80211's debugfs if the queues are ever started? Or
maybe somewhere else? That's the only thing I can think of, if this is
getting 1 I finally got the mapping right ...

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:

> >> > http://p.sipsolutions.net/511dda98892d2c9a.txt

> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >>
> >> Tried it 3 times, always times out.
> >
> > So you didn't get the warning, but can you still check what
> > info->hw_queue is in pio.c?
> 
> always "1"

Ok, so that's correct. Hmm.

Can you check in mac80211's debugfs if the queues are ever started? Or
maybe somewhere else? That's the only thing I can think of, if this is
getting 1 I finally got the mapping right ...

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 11:05 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>>
>>>> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>>>
>>> The previous patched all had the mac suspend failure. This one:
>>>
>>> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>>> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>>> is negative
>>> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>>> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>>> is negative
>>> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>>> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>>> is negative
>>
>> Huh, I thought I compiled it ... guess I had the wrong version.
>>
>> http://p.sipsolutions.net/511dda98892d2c9a.txt
>
> It's getting warmer:
>
> [    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
> [    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    9.491781] b43-phy0: QoS not supported by firmware
> [    9.868750] b43-phy0 debug: Chip initialized
> [    9.888580] b43-phy0 debug: PIO initialized
> [    9.899273] b43-phy0 debug: QoS disabled
> [   10.088420] b43-phy0 debug: Wireless interface started
> [   10.212209] b43-phy0 debug: Adding Interface type 2
> [   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   12.811768] wlan0: authenticated
> [   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
> [   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
> status=0 aid=2)
> [   12.863966] wlan0: associated
> [   16.319097] ieee80211 phy0: wlan0: No probe response from AP
> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
> [   16.349674] cfg80211: Calling CRDA for country: DE
> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>
> Tried it 3 times, always times out.

Strange. I commented out the BUILD_BUG statements in version 017d73a, and it 
worked for me with both flavors of fw.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 11:05 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
>> On Fri, 2012-06-08 at 17:56 +0200, Andre Heider wrote:
>>
>>>> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt
>>>
>>> The previous patched all had the mac suspend failure. This one:
>>>
>>> drivers/net/wireless/b43/main.c: In function 'b43_qos_upload_all':
>>> drivers/net/wireless/b43/main.c:3483: error: size of array 'type name'
>>> is negative
>>> drivers/net/wireless/b43/main.c: In function 'b43_qos_clear':
>>> drivers/net/wireless/b43/main.c:3502: error: size of array 'type name'
>>> is negative
>>> drivers/net/wireless/b43/main.c: In function 'b43_op_conf_tx':
>>> drivers/net/wireless/b43/main.c:3578: error: size of array 'type name'
>>> is negative
>>
>> Huh, I thought I compiled it ... guess I had the wrong version.
>>
>> http://p.sipsolutions.net/511dda98892d2c9a.txt
>
> It's getting warmer:
>
> [    9.456216] b43-phy0: Loading OpenSource firmware version 410.31754
> [    9.473798] b43-phy0: Hardware crypto acceleration not supported by firmware
> [    9.491781] b43-phy0: QoS not supported by firmware
> [    9.868750] b43-phy0 debug: Chip initialized
> [    9.888580] b43-phy0 debug: PIO initialized
> [    9.899273] b43-phy0 debug: QoS disabled
> [   10.088420] b43-phy0 debug: Wireless interface started
> [   10.212209] b43-phy0 debug: Adding Interface type 2
> [   12.739776] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   12.796248] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   12.811768] wlan0: authenticated
> [   12.823310] wlan0: associate with d8:5d:4c:9c:31:14 (try 1/3)
> [   12.844942] wlan0: RX AssocResp from d8:5d:4c:9c:31:14 (capab=0x411
> status=0 aid=2)
> [   12.863966] wlan0: associated
> [   16.319097] ieee80211 phy0: wlan0: No probe response from AP
> d8:5d:4c:9c:31:14 after 500ms, disconnecting.
> [   16.349674] cfg80211: Calling CRDA for country: DE
> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>
> Tried it 3 times, always times out.

Strange. I commented out the BUILD_BUG statements in version 017d73a, and it 
worked for me with both flavors of fw.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:20 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
> 
> > >> > http://p.sipsolutions.net/511dda98892d2c9a.txt
> 
> > >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> > >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> > >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> > >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> > >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> > >>
> > >> Tried it 3 times, always times out.
> > >
> > > So you didn't get the warning, but can you still check what
> > > info->hw_queue is in pio.c?
> > 
> > always "1"
> 
> Ok, so that's correct. Hmm.
> 
> Can you check in mac80211's debugfs if the queues are ever started? Or
> maybe somewhere else? That's the only thing I can think of, if this is
> getting 1 I finally got the mapping right ...

I'd be very surprised if the queue is stopped, it doesn't look that
way .. but maybe you can figure that out with mac80211 tracing:
http://linuxwireless.org/en/developers/Documentation/mac80211/tracing

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:20 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
> 
> > >> > http://p.sipsolutions.net/511dda98892d2c9a.txt
> 
> > >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> > >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> > >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> > >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> > >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> > >>
> > >> Tried it 3 times, always times out.
> > >
> > > So you didn't get the warning, but can you still check what
> > > info->hw_queue is in pio.c?
> > 
> > always "1"
> 
> Ok, so that's correct. Hmm.
> 
> Can you check in mac80211's debugfs if the queues are ever started? Or
> maybe somewhere else? That's the only thing I can think of, if this is
> getting 1 I finally got the mapping right ...

I'd be very surprised if the queue is stopped, it doesn't look that
way .. but maybe you can figure that out with mac80211 tracing:
http://linuxwireless.org/en/developers/Documentation/mac80211/tracing

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 11:24 -0500, Larry Finger wrote:
> On 06/08/2012 11:05 AM, Andre Heider wrote:

> >>>> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

> Strange. I commented out the BUILD_BUG statements in version 017d73a,

Right, that would do it. I think we may want to add a
#define B43_HW_QUEUE_NUM 5

and then use it in all the right places instead of changing
B43_QOS_QUEUE_NUM maybe?

>  and it 
> worked for me with both flavors of fw.

Well, good to know... I wonder what Andre's bug is then, maybe not
related to this?

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 11:24 -0500, Larry Finger wrote:
> On 06/08/2012 11:05 AM, Andre Heider wrote:

> >>>> Hopefully this is better: http://p.sipsolutions.net/017d73ac0688f863.txt

> Strange. I commented out the BUILD_BUG statements in version 017d73a,

Right, that would do it. I think we may want to add a
#define B43_HW_QUEUE_NUM 5

and then use it in all the right places instead of changing
B43_QOS_QUEUE_NUM maybe?

>  and it 
> worked for me with both flavors of fw.

Well, good to know... I wonder what Andre's bug is then, maybe not
related to this?

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Fri, 08 Jun 2012 18:28:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> Right, that would do it. I think we may want to add a
> #define B43_HW_QUEUE_NUM 5
> 
> and then use it in all the right places instead of changing
> B43_QOS_QUEUE_NUM maybe?

Sounds like a good plan.

> >  and it 
> > worked for me with both flavors of fw.
> 
> Well, good to know... I wonder what Andre's bug is then, maybe not
> related to this?

Larry, did you check with PIO?

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Fri, 08 Jun 2012 18:28:24 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> Right, that would do it. I think we may want to add a
> #define B43_HW_QUEUE_NUM 5
> 
> and then use it in all the right places instead of changing
> B43_QOS_QUEUE_NUM maybe?

Sounds like a good plan.

> >  and it 
> > worked for me with both flavors of fw.
> 
> Well, good to know... I wonder what Andre's bug is then, maybe not
> related to this?

Larry, did you check with PIO?

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120608/06704690/attachment.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:

> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >>
> >> Tried it 3 times, always times out.

I missed one a use of queue_mapping, try this:

http://p.sipsolutions.net/cc1fc9799ad3c015.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:

> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >>
> >> Tried it 3 times, always times out.

I missed one a use of queue_mapping, try this:

http://p.sipsolutions.net/cc1fc9799ad3c015.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
>
>> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
>> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
>> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
>> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>> >>
>> >> Tried it 3 times, always times out.
>
> I missed one a use of queue_mapping, try this:
>
> http://p.sipsolutions.net/cc1fc9799ad3c015.txt

Unfortunately still the authentication timeout.

And trace-cmd, hmm. There're no debian packages for it (at least for
powerpc), ubuntu only has x86 and x86_64, I don't have a compiler on
the wii, my powerpc crosscompiler doesn't have a libc and if I find a
solution I can only blind-script a trace via rc.local because without
wlan there's no way to interact :)
But I'll think of something...

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
>
>> >> [ ? 17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
>> >> [ ? 17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
>> >> [ ? 17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
>> >> [ ? 18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
>> >> [ ? 18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
>> >>
>> >> Tried it 3 times, always times out.
>
> I missed one a use of queue_mapping, try this:
>
> http://p.sipsolutions.net/cc1fc9799ad3c015.txt

Unfortunately still the authentication timeout.

And trace-cmd, hmm. There're no debian packages for it (at least for
powerpc), ubuntu only has x86 and x86_64, I don't have a compiler on
the wii, my powerpc crosscompiler doesn't have a libc and if I find a
solution I can only blind-script a trace via rc.local because without
wlan there's no way to interact :)
But I'll think of something...

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:54 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
> >
> >> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >> >>
> >> >> Tried it 3 times, always times out.
> >
> > I missed one a use of queue_mapping, try this:
> >
> > http://p.sipsolutions.net/cc1fc9799ad3c015.txt
> 
> Unfortunately still the authentication timeout.

I'm out of ideas then, you had the right queue to start with so this
probably just fixed a corner case, but ... I have no idea where else a
bug could lurk.

Maybe you can first make sure the frames actually make it to the air,
using some other device as a sniffer?

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 18:54 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 18:16 +0200, Andre Heider wrote:
> >
> >> >> [   17.597307] wlan0: authenticate with d8:5d:4c:9c:31:14
> >> >> [   17.638399] wlan0: send auth to d8:5d:4c:9c:31:14 (try 1/3)
> >> >> [   17.851085] wlan0: send auth to d8:5d:4c:9c:31:14 (try 2/3)
> >> >> [   18.063086] wlan0: send auth to d8:5d:4c:9c:31:14 (try 3/3)
> >> >> [   18.275081] wlan0: authentication with d8:5d:4c:9c:31:14 timed out
> >> >>
> >> >> Tried it 3 times, always times out.
> >
> > I missed one a use of queue_mapping, try this:
> >
> > http://p.sipsolutions.net/cc1fc9799ad3c015.txt
> 
> Unfortunately still the authentication timeout.

I'm out of ideas then, you had the right queue to start with so this
probably just fixed a corner case, but ... I have no idea where else a
bug could lurk.

Maybe you can first make sure the frames actually make it to the air,
using some other device as a sniffer?

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 11:33 AM, Michael Büsch wrote:
>
> Larry, did you check with PIO?

No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
both kinds of firmware, while PIO fails for both.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 11:33 AM, Michael B?sch wrote:
>
> Larry, did you check with PIO?

No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
both kinds of firmware, while PIO fails for both.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
> On 06/08/2012 11:33 AM, Michael Büsch wrote:
> >
> > Larry, did you check with PIO?
> 
> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> both kinds of firmware, while PIO fails for both.

Hmm, both with QoS enabled and disabled?. I don't really see what could
be causing this, sorry.

One more thing that I just realised though is that mac80211 uses the #
of queues to determine whether to advertise QoS or not, so the whole
thing won't actually work anyway without more work :-(

I'm tempted to just remove the check for now to "fix" b43 and then maybe
you can load firmware before registering with mac80211 in b43?

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
> On 06/08/2012 11:33 AM, Michael B?sch wrote:
> >
> > Larry, did you check with PIO?
> 
> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> both kinds of firmware, while PIO fails for both.

Hmm, both with QoS enabled and disabled?. I don't really see what could
be causing this, sorry.

One more thing that I just realised though is that mac80211 uses the #
of queues to determine whether to advertise QoS or not, so the whole
thing won't actually work anyway without more work :-(

I'm tempted to just remove the check for now to "fix" b43 and then maybe
you can load firmware before registering with mac80211 in b43?

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

On Fri, 08 Jun 2012 12:43:06 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 06/08/2012 11:33 AM, Michael Büsch wrote:
> >
> > Larry, did you check with PIO?
> 
> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> both kinds of firmware, while PIO fails for both.

Does PIO even work without that patch and with prop-firmware?

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Fri, 08 Jun 2012 12:43:06 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 06/08/2012 11:33 AM, Michael B?sch wrote:
> >
> > Larry, did you check with PIO?
> 
> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> both kinds of firmware, while PIO fails for both.

Does PIO even work without that patch and with prop-firmware?

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120608/35b3ff47/attachment.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 19:56 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
> > On 06/08/2012 11:33 AM, Michael Büsch wrote:
> > >
> > > Larry, did you check with PIO?
> > 
> > No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> > both kinds of firmware, while PIO fails for both.
> 
> Hmm, both with QoS enabled and disabled?. I don't really see what could
> be causing this, sorry.
> 
> One more thing that I just realised though is that mac80211 uses the #
> of queues to determine whether to advertise QoS or not, so the whole
> thing won't actually work anyway without more work :-(

Maybe these two patches work:

http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
http://p.sipsolutions.net/ad2677233e6917e8.txt

still kinda hack like it always was, but ...

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 19:56 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
> > On 06/08/2012 11:33 AM, Michael B?sch wrote:
> > >
> > > Larry, did you check with PIO?
> > 
> > No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for 
> > both kinds of firmware, while PIO fails for both.
> 
> Hmm, both with QoS enabled and disabled?. I don't really see what could
> be causing this, sorry.
> 
> One more thing that I just realised though is that mac80211 uses the #
> of queues to determine whether to advertise QoS or not, so the whole
> thing won't actually work anyway without more work :-(

Maybe these two patches work:

http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
http://p.sipsolutions.net/ad2677233e6917e8.txt

still kinda hack like it always was, but ...

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 01:10 PM, Michael Büsch wrote:
> On Fri, 08 Jun 2012 12:43:06 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> On 06/08/2012 11:33 AM, Michael Büsch wrote:
>>>
>>> Larry, did you check with PIO?
>>
>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>> both kinds of firmware, while PIO fails for both.
>
> Does PIO even work without that patch and with prop-firmware?

No. That seems to be a different bug.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 01:10 PM, Michael B?sch wrote:
> On Fri, 08 Jun 2012 12:43:06 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> On 06/08/2012 11:33 AM, Michael B?sch wrote:
>>>
>>> Larry, did you check with PIO?
>>
>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>> both kinds of firmware, while PIO fails for both.
>
> Does PIO even work without that patch and with prop-firmware?

No. That seems to be a different bug.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 8:11 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 19:56 +0200, Johannes Berg wrote:
>> On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
>> > On 06/08/2012 11:33 AM, Michael Büsch wrote:
>> > >
>> > > Larry, did you check with PIO?
>> >
>> > No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>> > both kinds of firmware, while PIO fails for both.
>>
>> Hmm, both with QoS enabled and disabled?. I don't really see what could
>> be causing this, sorry.
>>
>> One more thing that I just realised though is that mac80211 uses the #
>> of queues to determine whether to advertise QoS or not, so the whole
>> thing won't actually work anyway without more work :-(
>
> Maybe these two patches work:
>
> http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
> http://p.sipsolutions.net/ad2677233e6917e8.txt
>
> still kinda hack like it always was, but ...

Those don't apply clean on 48d212a2eec, resolved a conflict, but
device worked and I could login ;)

But as soon as I ran `dmesg` (over ssh+wlan) I got a kernel crash. It
scrolled by too fast, but alot of b43 stuff starting with
__netif_schedule. Unsure if its because of these patches or unrelated.

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 8:11 PM, Johannes Berg <johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 19:56 +0200, Johannes Berg wrote:
>> On Fri, 2012-06-08 at 12:43 -0500, Larry Finger wrote:
>> > On 06/08/2012 11:33 AM, Michael B?sch wrote:
>> > >
>> > > Larry, did you check with PIO?
>> >
>> > No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>> > both kinds of firmware, while PIO fails for both.
>>
>> Hmm, both with QoS enabled and disabled?. I don't really see what could
>> be causing this, sorry.
>>
>> One more thing that I just realised though is that mac80211 uses the #
>> of queues to determine whether to advertise QoS or not, so the whole
>> thing won't actually work anyway without more work :-(
>
> Maybe these two patches work:
>
> http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
> http://p.sipsolutions.net/ad2677233e6917e8.txt
>
> still kinda hack like it always was, but ...

Those don't apply clean on 48d212a2eec, resolved a conflict, but
device worked and I could login ;)

But as soon as I ran `dmesg` (over ssh+wlan) I got a kernel crash. It
scrolled by too fast, but alot of b43 stuff starting with
__netif_schedule. Unsure if its because of these patches or unrelated.

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

On Fri, 08 Jun 2012 13:23:46 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 06/08/2012 01:10 PM, Michael Büsch wrote:
> > On Fri, 08 Jun 2012 12:43:06 -0500
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> >> On 06/08/2012 11:33 AM, Michael Büsch wrote:
> >>>
> >>> Larry, did you check with PIO?
> >>
> >> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
> >> both kinds of firmware, while PIO fails for both.
> >
> > Does PIO even work without that patch and with prop-firmware?
> 
> No. That seems to be a different bug.

That's nice. Could you probably bisect it? It used to work at some point.

PS:
I'm sorry that I'm not of much help these days, because I currently
don't have a working b43 device around :)

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Fri, 08 Jun 2012 13:23:46 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:

> On 06/08/2012 01:10 PM, Michael B?sch wrote:
> > On Fri, 08 Jun 2012 12:43:06 -0500
> > Larry Finger <Larry.Finger@lwfinger.net> wrote:
> >
> >> On 06/08/2012 11:33 AM, Michael B?sch wrote:
> >>>
> >>> Larry, did you check with PIO?
> >>
> >> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
> >> both kinds of firmware, while PIO fails for both.
> >
> > Does PIO even work without that patch and with prop-firmware?
> 
> No. That seems to be a different bug.

That's nice. Could you probably bisect it? It used to work at some point.

PS:
I'm sorry that I'm not of much help these days, because I currently
don't have a working b43 device around :)

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120608/c962331f/attachment-0001.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

Let's go back to the root of this problem ...

Is there *any* open firmware that enables QoS today? If not, this is
probably a much better choice for a patch for now, even though my other
patch contained code improvements for b43 in various areas.

http://p.sipsolutions.net/d486b77caacf3dbb.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

Let's go back to the root of this problem ...

Is there *any* open firmware that enables QoS today? If not, this is
probably a much better choice for a patch for now, even though my other
patch contained code improvements for b43 in various areas.

http://p.sipsolutions.net/d486b77caacf3dbb.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:28 +0200, Andre Heider wrote:

> > Maybe these two patches work:
> >
> > http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
> > http://p.sipsolutions.net/ad2677233e6917e8.txt
> >
> > still kinda hack like it always was, but ...
> 
> Those don't apply clean on 48d212a2eec, resolved a conflict, but
> device worked and I could login ;)

Ok, so I guess that confirms that somehow PIO breaks when we configure
QoS parameters or something .. bit strange, but hey.

> But as soon as I ran `dmesg` (over ssh+wlan) I got a kernel crash. It
> scrolled by too fast, but alot of b43 stuff starting with
> __netif_schedule. Unsure if its because of these patches or unrelated.

Could be related, or not.

I still dislike the way b43 plays with this stuff at runtime, and
Michael pointed out a flaw in my patch too, so we can't apply these
anyway...

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:28 +0200, Andre Heider wrote:

> > Maybe these two patches work:
> >
> > http://p.sipsolutions.net/b8912f8cad4cb3b2.txt
> > http://p.sipsolutions.net/ad2677233e6917e8.txt
> >
> > still kinda hack like it always was, but ...
> 
> Those don't apply clean on 48d212a2eec, resolved a conflict, but
> device worked and I could login ;)

Ok, so I guess that confirms that somehow PIO breaks when we configure
QoS parameters or something .. bit strange, but hey.

> But as soon as I ran `dmesg` (over ssh+wlan) I got a kernel crash. It
> scrolled by too fast, but alot of b43 stuff starting with
> __netif_schedule. Unsure if its because of these patches or unrelated.

Could be related, or not.

I still dislike the way b43 plays with this stuff at runtime, and
Michael pointed out a flaw in my patch too, so we can't apply these
anyway...

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:36 +0200, Johannes Berg wrote:
> Let's go back to the root of this problem ...
> 
> Is there *any* open firmware that enables QoS today? If not, this is
> probably a much better choice for a patch for now, even though my other
> patch contained code improvements for b43 in various areas.
> 
> http://p.sipsolutions.net/d486b77caacf3dbb.txt

Nope, this leaves qos_enabled wrong ...

http://p.sipsolutions.net/64cce044448bd819.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:36 +0200, Johannes Berg wrote:
> Let's go back to the root of this problem ...
> 
> Is there *any* open firmware that enables QoS today? If not, this is
> probably a much better choice for a patch for now, even though my other
> patch contained code improvements for b43 in various areas.
> 
> http://p.sipsolutions.net/d486b77caacf3dbb.txt

Nope, this leaves qos_enabled wrong ...

http://p.sipsolutions.net/64cce044448bd819.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:42 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 20:36 +0200, Johannes Berg wrote:
> > Let's go back to the root of this problem ...
> > 
> > Is there *any* open firmware that enables QoS today? If not, this is
> > probably a much better choice for a patch for now, even though my other
> > patch contained code improvements for b43 in various areas.
> > 
> > http://p.sipsolutions.net/d486b77caacf3dbb.txt
> 
> Nope, this leaves qos_enabled wrong ...
> 
> http://p.sipsolutions.net/64cce044448bd819.txt

Ahrg, b43 only sets fw.opensource too late ... this moves it:
http://p.sipsolutions.net/00c0056dc206e247.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 20:42 +0200, Johannes Berg wrote:
> On Fri, 2012-06-08 at 20:36 +0200, Johannes Berg wrote:
> > Let's go back to the root of this problem ...
> > 
> > Is there *any* open firmware that enables QoS today? If not, this is
> > probably a much better choice for a patch for now, even though my other
> > patch contained code improvements for b43 in various areas.
> > 
> > http://p.sipsolutions.net/d486b77caacf3dbb.txt
> 
> Nope, this leaves qos_enabled wrong ...
> 
> http://p.sipsolutions.net/64cce044448bd819.txt

Ahrg, b43 only sets fw.opensource too late ... this moves it:
http://p.sipsolutions.net/00c0056dc206e247.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 01:31 PM, Michael Büsch wrote:
> On Fri, 08 Jun 2012 13:23:46 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> On 06/08/2012 01:10 PM, Michael Büsch wrote:
>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>
>>>> On 06/08/2012 11:33 AM, Michael Büsch wrote:
>>>>>
>>>>> Larry, did you check with PIO?
>>>>
>>>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>>>> both kinds of firmware, while PIO fails for both.
>>>
>>> Does PIO even work without that patch and with prop-firmware?
>>
>> No. That seems to be a different bug.
>
> That's nice. Could you probably bisect it? It used to work at some point.
>
> PS:
> I'm sorry that I'm not of much help these days, because I currently
> don't have a working b43 device around :)

No problem. Most of the time when I'm running b43, it is on one of my older test 
machines.

I need to do a little more testing before I start a bisection of the PIO 
problem. My PPC Mac fails with kernel 2.6.32, which is as old as I have 
available. At the moment, I don't have the time to fire up an old i586 notebook 
to see if we have a PIO problem, or an endian issue with PIO; however, I think 
Andre's wii is big endian.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/08/2012 01:31 PM, Michael B?sch wrote:
> On Fri, 08 Jun 2012 13:23:46 -0500
> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>
>> On 06/08/2012 01:10 PM, Michael B?sch wrote:
>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>
>>>> On 06/08/2012 11:33 AM, Michael B?sch wrote:
>>>>>
>>>>> Larry, did you check with PIO?
>>>>
>>>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA works for
>>>> both kinds of firmware, while PIO fails for both.
>>>
>>> Does PIO even work without that patch and with prop-firmware?
>>
>> No. That seems to be a different bug.
>
> That's nice. Could you probably bisect it? It used to work at some point.
>
> PS:
> I'm sorry that I'm not of much help these days, because I currently
> don't have a working b43 device around :)

No problem. Most of the time when I'm running b43, it is on one of my older test 
machines.

I need to do a little more testing before I start a bisection of the PIO 
problem. My PPC Mac fails with kernel 2.6.32, which is as old as I have 
available. At the moment, I don't have the time to fire up an old i586 notebook 
to see if we have a PIO problem, or an endian issue with PIO; however, I think 
Andre's wii is big endian.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 9:37 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/08/2012 01:31 PM, Michael Büsch wrote:
>>
>> On Fri, 08 Jun 2012 13:23:46 -0500
>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>
>>> On 06/08/2012 01:10 PM, Michael Büsch wrote:
>>>>
>>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>
>>>>> On 06/08/2012 11:33 AM, Michael Büsch wrote:
>>>>>>
>>>>>>
>>>>>> Larry, did you check with PIO?
>>>>>
>>>>>
>>>>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA
>>>>> works for
>>>>> both kinds of firmware, while PIO fails for both.
>>>>
>>>>
>>>> Does PIO even work without that patch and with prop-firmware?
>>>
>>>
>>> No. That seems to be a different bug.
>>
>>
>> That's nice. Could you probably bisect it? It used to work at some point.
>>
>> PS:
>> I'm sorry that I'm not of much help these days, because I currently
>> don't have a working b43 device around :)
>
>
> No problem. Most of the time when I'm running b43, it is on one of my older
> test machines.
>
> I need to do a little more testing before I start a bisection of the PIO
> problem. My PPC Mac fails with kernel 2.6.32, which is as old as I have
> available. At the moment, I don't have the time to fire up an old i586
> notebook to see if we have a PIO problem, or an endian issue with PIO;
> however, I think Andre's wii is big endian.

Yeah, it's a 32bit powerpc.

>From my initial report:
The hw queues fail the check in ieee80211_check_queues(). When I hack
that function to always "return 0;" wlan works again.

Apart from the patch test runs that's what I'm running atm, so I'm
pretty sure you can assume its not a BE issue.

Regards,
Andre

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 8, 2012 at 9:37 PM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/08/2012 01:31 PM, Michael B?sch wrote:
>>
>> On Fri, 08 Jun 2012 13:23:46 -0500
>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>
>>> On 06/08/2012 01:10 PM, Michael B?sch wrote:
>>>>
>>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>>> Larry Finger <Larry.Finger@lwfinger.net> wrote:
>>>>
>>>>> On 06/08/2012 11:33 AM, Michael B?sch wrote:
>>>>>>
>>>>>>
>>>>>> Larry, did you check with PIO?
>>>>>
>>>>>
>>>>> No, I only used DMA. With the latest patch, compilation is Ok, and DMA
>>>>> works for
>>>>> both kinds of firmware, while PIO fails for both.
>>>>
>>>>
>>>> Does PIO even work without that patch and with prop-firmware?
>>>
>>>
>>> No. That seems to be a different bug.
>>
>>
>> That's nice. Could you probably bisect it? It used to work at some point.
>>
>> PS:
>> I'm sorry that I'm not of much help these days, because I currently
>> don't have a working b43 device around :)
>
>
> No problem. Most of the time when I'm running b43, it is on one of my older
> test machines.
>
> I need to do a little more testing before I start a bisection of the PIO
> problem. My PPC Mac fails with kernel 2.6.32, which is as old as I have
> available. At the moment, I don't have the time to fire up an old i586
> notebook to see if we have a PIO problem, or an endian issue with PIO;
> however, I think Andre's wii is big endian.

Yeah, it's a 32bit powerpc.

From my initial report:
The hw queues fail the check in ieee80211_check_queues(). When I hack
that function to always "return 0;" wlan works again.

Apart from the patch test runs that's what I'm running atm, so I'm
pretty sure you can assume its not a BE issue.

Regards,
Andre

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:

> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> http://p.sipsolutions.net/00c0056dc206e247.txt

Has anyone tested this?

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:

> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> http://p.sipsolutions.net/00c0056dc206e247.txt

Has anyone tested this?

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
>
>> Ahrg, b43 only sets fw.opensource too late ... this moves it:
>> http://p.sipsolutions.net/00c0056dc206e247.txt
>
> Has anyone tested this?

Sorry, missed that one.
I get this crash with that patch: http://i.imgur.com/2CMzA.png

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
>
>> Ahrg, b43 only sets fw.opensource too late ... this moves it:
>> http://p.sipsolutions.net/00c0056dc206e247.txt
>
> Has anyone tested this?

Sorry, missed that one.
I get this crash with that patch: http://i.imgur.com/2CMzA.png

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
> >
> >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> >> http://p.sipsolutions.net/00c0056dc206e247.txt
> >
> > Has anyone tested this?
> 
> Sorry, missed that one.
> I get this crash with that patch: http://i.imgur.com/2CMzA.png

Huh, that doesn't make a lot of sense to me, I don't move any
locking ...

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
> >
> >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> >> http://p.sipsolutions.net/00c0056dc206e247.txt
> >
> > Has anyone tested this?
> 
> Sorry, missed that one.
> I get this crash with that patch: http://i.imgur.com/2CMzA.png

Huh, that doesn't make a lot of sense to me, I don't move any
locking ...

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

[-- Attachment #1: Type: text/plain, Size: 814 bytes --]

On Wed, 13 Jun 2012 17:46:42 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> > > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
> > >
> > >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> > >> http://p.sipsolutions.net/00c0056dc206e247.txt
> > >
> > > Has anyone tested this?
> > 
> > Sorry, missed that one.
> > I get this crash with that patch: http://i.imgur.com/2CMzA.png
> 
> Huh, that doesn't make a lot of sense to me, I don't move any
> locking ...

This just seems to be a follow-up oops and the original one scrolled off screen.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Michael Büsch]

On Wed, 13 Jun 2012 17:46:42 +0200
Johannes Berg <johannes@sipsolutions.net> wrote:

> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> > <johannes@sipsolutions.net> wrote:
> > > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
> > >
> > >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
> > >> http://p.sipsolutions.net/00c0056dc206e247.txt
> > >
> > > Has anyone tested this?
> > 
> > Sorry, missed that one.
> > I get this crash with that patch: http://i.imgur.com/2CMzA.png
> 
> Huh, that doesn't make a lot of sense to me, I don't move any
> locking ...

This just seems to be a follow-up oops and the original one scrolled off screen.

-- 
Greetings, Michael.

PGP encryption is encouraged / 908D8B0E
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/b43-dev/attachments/20120613/4a2950eb/attachment.sig>

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 13, 2012 at 8:42 PM, Michael Büsch <m@bues.ch> wrote:
> On Wed, 13 Jun 2012 17:46:42 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
>> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> > > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
>> > >
>> > >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
>> > >> http://p.sipsolutions.net/00c0056dc206e247.txt
>> > >
>> > > Has anyone tested this?
>> >
>> > Sorry, missed that one.
>> > I get this crash with that patch: http://i.imgur.com/2CMzA.png
>>
>> Huh, that doesn't make a lot of sense to me, I don't move any
>> locking ...
>
> This just seems to be a follow-up oops and the original one scrolled off screen.

Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)

pause_on_oops=30 made that easier, and the offender is
drivers/net/wireless/b43/main.c:5294 from the patch:
wldev->qos_enabled = true;

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Wed, Jun 13, 2012 at 8:42 PM, Michael B?sch <m@bues.ch> wrote:
> On Wed, 13 Jun 2012 17:46:42 +0200
> Johannes Berg <johannes@sipsolutions.net> wrote:
>
>> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
>> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
>> > <johannes@sipsolutions.net> wrote:
>> > > On Fri, 2012-06-08 at 21:04 +0200, Johannes Berg wrote:
>> > >
>> > >> Ahrg, b43 only sets fw.opensource too late ... this moves it:
>> > >> http://p.sipsolutions.net/00c0056dc206e247.txt
>> > >
>> > > Has anyone tested this?
>> >
>> > Sorry, missed that one.
>> > I get this crash with that patch: http://i.imgur.com/2CMzA.png
>>
>> Huh, that doesn't make a lot of sense to me, I don't move any
>> locking ...
>
> This just seems to be a follow-up oops and the original one scrolled off screen.

Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)

pause_on_oops=30 made that easier, and the offender is
drivers/net/wireless/b43/main.c:5294 from the patch:
wldev->qos_enabled = true;

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 18:26 +0200, Andre Heider wrote:

> > This just seems to be a follow-up oops and the original one scrolled off screen.
> 
> Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)
> 
> pause_on_oops=30 made that easier, and the offender is
> drivers/net/wireless/b43/main.c:5294 from the patch:
> wldev->qos_enabled = true;

Ok ... seems wldev doesn't exist then? Doesn't make any sense to me, but
I don't understand the code ... not that it matters, try this:

http://p.sipsolutions.net/9c830800d14f3ff8.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 18:26 +0200, Andre Heider wrote:

> > This just seems to be a follow-up oops and the original one scrolled off screen.
> 
> Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)
> 
> pause_on_oops=30 made that easier, and the offender is
> drivers/net/wireless/b43/main.c:5294 from the patch:
> wldev->qos_enabled = true;

Ok ... seems wldev doesn't exist then? Doesn't make any sense to me, but
I don't understand the code ... not that it matters, try this:

http://p.sipsolutions.net/9c830800d14f3ff8.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 14, 2012 at 6:37 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-14 at 18:26 +0200, Andre Heider wrote:
>
>> > This just seems to be a follow-up oops and the original one scrolled off screen.
>>
>> Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)
>>
>> pause_on_oops=30 made that easier, and the offender is
>> drivers/net/wireless/b43/main.c:5294 from the patch:
>> wldev->qos_enabled = true;
>
> Ok ... seems wldev doesn't exist then? Doesn't make any sense to me, but
> I don't understand the code ... not that it matters, try this:
>
> http://p.sipsolutions.net/9c830800d14f3ff8.txt

This still oopses: if (!modparam_qos || wldev->fw.opensource)

I do get a working wlan0 if I force "hw->queues = 1;" without that
offending line, but just a `dmesg` over wlan+ssh yields another one
(prolly the same one I already described on an older patch):
http://i.imgur.com/epdRF.jpg

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 14, 2012 at 6:37 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-14 at 18:26 +0200, Andre Heider wrote:
>
>> > This just seems to be a follow-up oops and the original one scrolled off screen.
>>
>> Indeed, the framebuffer showed up too late on TV and I didn't even notice ;)
>>
>> pause_on_oops=30 made that easier, and the offender is
>> drivers/net/wireless/b43/main.c:5294 from the patch:
>> wldev->qos_enabled = true;
>
> Ok ... seems wldev doesn't exist then? Doesn't make any sense to me, but
> I don't understand the code ... not that it matters, try this:
>
> http://p.sipsolutions.net/9c830800d14f3ff8.txt

This still oopses: if (!modparam_qos || wldev->fw.opensource)

I do get a working wlan0 if I force "hw->queues = 1;" without that
offending line, but just a `dmesg` over wlan+ssh yields another one
(prolly the same one I already described on an older patch):
http://i.imgur.com/epdRF.jpg

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:

> > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> 
> This still oopses: if (!modparam_qos || wldev->fw.opensource)
> 
> I do get a working wlan0 if I force "hw->queues = 1;" without that
> offending line, but just a `dmesg` over wlan+ssh yields another one
> (prolly the same one I already described on an older patch):
> http://i.imgur.com/epdRF.jpg

Doh, of course, I still have wldev ... I'm in a meeting now, will check
again later.

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:

> > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> 
> This still oopses: if (!modparam_qos || wldev->fw.opensource)
> 
> I do get a working wlan0 if I force "hw->queues = 1;" without that
> offending line, but just a `dmesg` over wlan+ssh yields another one
> (prolly the same one I already described on an older patch):
> http://i.imgur.com/epdRF.jpg

Doh, of course, I still have wldev ... I'm in a meeting now, will check
again later.

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
> 
> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> > 
> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
> > 
> > I do get a working wlan0 if I force "hw->queues = 1;" without that
> > offending line, but just a `dmesg` over wlan+ssh yields another one
> > (prolly the same one I already described on an older patch):
> > http://i.imgur.com/epdRF.jpg
> 
> Doh, of course, I still have wldev ... I'm in a meeting now, will check
> again later.

Let's just move the hw->queues setup ...

http://p.sipsolutions.net/e45e57bbc9509e69.txt

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
> 
> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> > 
> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
> > 
> > I do get a working wlan0 if I force "hw->queues = 1;" without that
> > offending line, but just a `dmesg` over wlan+ssh yields another one
> > (prolly the same one I already described on an older patch):
> > http://i.imgur.com/epdRF.jpg
> 
> Doh, of course, I still have wldev ... I'm in a meeting now, will check
> again later.

Let's just move the hw->queues setup ...

http://p.sipsolutions.net/e45e57bbc9509e69.txt

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>
>> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
>> >
>> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
>> >
>> > I do get a working wlan0 if I force "hw->queues = 1;" without that
>> > offending line, but just a `dmesg` over wlan+ssh yields another one
>> > (prolly the same one I already described on an older patch):
>> > http://i.imgur.com/epdRF.jpg
>>
>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>> again later.
>
> Let's just move the hw->queues setup ...
>
> http://p.sipsolutions.net/e45e57bbc9509e69.txt

No oops during loading the fw or bringing the device up, but same
crash as in the picture above ;)

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
<johannes@sipsolutions.net> wrote:
> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>
>> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
>> >
>> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
>> >
>> > I do get a working wlan0 if I force "hw->queues = 1;" without that
>> > offending line, but just a `dmesg` over wlan+ssh yields another one
>> > (prolly the same one I already described on an older patch):
>> > http://i.imgur.com/epdRF.jpg
>>
>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>> again later.
>
> Let's just move the hw->queues setup ...
>
> http://p.sipsolutions.net/e45e57bbc9509e69.txt

No oops during loading the fw or bringing the device up, but same
crash as in the picture above ;)

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
> >> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
> >>
> >> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> >> >
> >> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
> >> >
> >> > I do get a working wlan0 if I force "hw->queues = 1;" without that
> >> > offending line, but just a `dmesg` over wlan+ssh yields another one
> >> > (prolly the same one I already described on an older patch):
> >> > http://i.imgur.com/epdRF.jpg
> >>
> >> Doh, of course, I still have wldev ... I'm in a meeting now, will check
> >> again later.
> >
> > Let's just move the hw->queues setup ...
> >
> > http://p.sipsolutions.net/e45e57bbc9509e69.txt
> 
> No oops during loading the fw or bringing the device up, but same
> crash as in the picture above ;)

I guess I shouldn't be doing this right now ...

Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
know this code well enough and you should be able to identify the intent
from the patch ...

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
> <johannes@sipsolutions.net> wrote:
> > On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
> >> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
> >>
> >> > > http://p.sipsolutions.net/9c830800d14f3ff8.txt
> >> >
> >> > This still oopses: if (!modparam_qos || wldev->fw.opensource)
> >> >
> >> > I do get a working wlan0 if I force "hw->queues = 1;" without that
> >> > offending line, but just a `dmesg` over wlan+ssh yields another one
> >> > (prolly the same one I already described on an older patch):
> >> > http://i.imgur.com/epdRF.jpg
> >>
> >> Doh, of course, I still have wldev ... I'm in a meeting now, will check
> >> again later.
> >
> > Let's just move the hw->queues setup ...
> >
> > http://p.sipsolutions.net/e45e57bbc9509e69.txt
> 
> No oops during loading the fw or bringing the device up, but same
> crash as in the picture above ;)

I guess I shouldn't be doing this right now ...

Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
know this code well enough and you should be able to identify the intent
from the patch ...

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/14/2012 12:27 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
>> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>>>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>>>
>>>>>> http://p.sipsolutions.net/9c830800d14f3ff8.txt
>>>>>
>>>>> This still oopses: if (!modparam_qos || wldev->fw.opensource)
>>>>>
>>>>> I do get a working wlan0 if I force "hw->queues = 1;" without that
>>>>> offending line, but just a `dmesg` over wlan+ssh yields another one
>>>>> (prolly the same one I already described on an older patch):
>>>>> http://i.imgur.com/epdRF.jpg
>>>>
>>>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>>>> again later.
>>>
>>> Let's just move the hw->queues setup ...
>>>
>>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
>>
>> No oops during loading the fw or bringing the device up, but same
>> crash as in the picture above ;)
>
> I guess I shouldn't be doing this right now ...
>
> Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
> know this code well enough and you should be able to identify the intent
> from the patch ...

I will give it a try. I was in the Canadian wilderness for 5 days fishing, which 
is why I have not responded earlier.

The device does not fail on my hardware, but I can prepare things for Andre to test.

Larry

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Larry Finger]

On 06/14/2012 12:27 PM, Johannes Berg wrote:
> On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
>> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
>> <johannes@sipsolutions.net> wrote:
>>> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>>>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>>>
>>>>>> http://p.sipsolutions.net/9c830800d14f3ff8.txt
>>>>>
>>>>> This still oopses: if (!modparam_qos || wldev->fw.opensource)
>>>>>
>>>>> I do get a working wlan0 if I force "hw->queues = 1;" without that
>>>>> offending line, but just a `dmesg` over wlan+ssh yields another one
>>>>> (prolly the same one I already described on an older patch):
>>>>> http://i.imgur.com/epdRF.jpg
>>>>
>>>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>>>> again later.
>>>
>>> Let's just move the hw->queues setup ...
>>>
>>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
>>
>> No oops during loading the fw or bringing the device up, but same
>> crash as in the picture above ;)
>
> I guess I shouldn't be doing this right now ...
>
> Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
> know this code well enough and you should be able to identify the intent
> from the patch ...

I will give it a try. I was in the Canadian wilderness for 5 days fishing, which 
is why I have not responded earlier.

The device does not fail on my hardware, but I can prepare things for Andre to test.

Larry

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 21:03 -0500, Larry Finger wrote:

> >>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
> >>
> >> No oops during loading the fw or bringing the device up, but same
> >> crash as in the picture above ;)
> >
> > I guess I shouldn't be doing this right now ...
> >
> > Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
> > know this code well enough and you should be able to identify the intent
> > from the patch ...
> 
> I will give it a try. I was in the Canadian wilderness for 5 days fishing, which 
> is why I have not responded earlier.
> 
> The device does not fail on my hardware, but I can prepare things for Andre to test.

Thanks Larry! Hope you brought home some good catch :-)

johannes

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Johannes Berg]

On Thu, 2012-06-14 at 21:03 -0500, Larry Finger wrote:

> >>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
> >>
> >> No oops during loading the fw or bringing the device up, but same
> >> crash as in the picture above ;)
> >
> > I guess I shouldn't be doing this right now ...
> >
> > Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
> > know this code well enough and you should be able to identify the intent
> > from the patch ...
> 
> I will give it a try. I was in the Canadian wilderness for 5 days fishing, which 
> is why I have not responded earlier.
> 
> The device does not fail on my hardware, but I can prepare things for Andre to test.

Thanks Larry! Hope you brought home some good catch :-)

johannes

Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 15, 2012 at 4:03 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/14/2012 12:27 PM, Johannes Berg wrote:
>>
>> On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
>>>
>>> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
>>> <johannes@sipsolutions.net> wrote:
>>>>
>>>> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>>>>>
>>>>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>>>>
>>>>>>> http://p.sipsolutions.net/9c830800d14f3ff8.txt
>>>>>>
>>>>>>
>>>>>> This still oopses: if (!modparam_qos || wldev->fw.opensource)
>>>>>>
>>>>>> I do get a working wlan0 if I force "hw->queues = 1;" without that
>>>>>> offending line, but just a `dmesg` over wlan+ssh yields another one
>>>>>> (prolly the same one I already described on an older patch):
>>>>>> http://i.imgur.com/epdRF.jpg
>>>>>
>>>>>
>>>>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>>>>> again later.
>>>>
>>>>
>>>> Let's just move the hw->queues setup ...
>>>>
>>>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
>>>
>>>
>>> No oops during loading the fw or bringing the device up, but same
>>> crash as in the picture above ;)
>>
>>
>> I guess I shouldn't be doing this right now ...
>>
>> Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
>> know this code well enough and you should be able to identify the intent
>> from the patch ...
>
>
> I will give it a try. I was in the Canadian wilderness for 5 days fishing,
> which is why I have not responded earlier.
>
> The device does not fail on my hardware, but I can prepare things for Andre
> to test.

Thanks guys!

Did I understood that correctly and your device works with the
e45e57bbc9509e69 patch on openfwwf/pio?

chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))

[Andre Heider]

On Fri, Jun 15, 2012 at 4:03 AM, Larry Finger <Larry.Finger@lwfinger.net> wrote:
> On 06/14/2012 12:27 PM, Johannes Berg wrote:
>>
>> On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
>>>
>>> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
>>> <johannes@sipsolutions.net> wrote:
>>>>
>>>> On Thu, 2012-06-14 at 19:09 +0200, Johannes Berg wrote:
>>>>>
>>>>> On Thu, 2012-06-14 at 19:00 +0200, Andre Heider wrote:
>>>>>
>>>>>>> http://p.sipsolutions.net/9c830800d14f3ff8.txt
>>>>>>
>>>>>>
>>>>>> This still oopses: if (!modparam_qos || wldev->fw.opensource)
>>>>>>
>>>>>> I do get a working wlan0 if I force "hw->queues = 1;" without that
>>>>>> offending line, but just a `dmesg` over wlan+ssh yields another one
>>>>>> (prolly the same one I already described on an older patch):
>>>>>> http://i.imgur.com/epdRF.jpg
>>>>>
>>>>>
>>>>> Doh, of course, I still have wldev ... I'm in a meeting now, will check
>>>>> again later.
>>>>
>>>>
>>>> Let's just move the hw->queues setup ...
>>>>
>>>> http://p.sipsolutions.net/e45e57bbc9509e69.txt
>>>
>>>
>>> No oops during loading the fw or bringing the device up, but same
>>> crash as in the picture above ;)
>>
>>
>> I guess I shouldn't be doing this right now ...
>>
>> Can't somebody else help me out? Rafal? Larry? Michael? I clearly don't
>> know this code well enough and you should be able to identify the intent
>> from the patch ...
>
>
> I will give it a try. I was in the Canadian wilderness for 5 days fishing,
> which is why I have not responded earlier.
>
> The device does not fail on my hardware, but I can prepare things for Andre
> to test.

Thanks guys!

Did I understood that correctly and your device works with the
e45e57bbc9509e69 patch on openfwwf/pio?