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 <[email protected]>
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
On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> <[email protected]> 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
On 06/08/2012 10:25 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <[email protected]> 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
On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <[email protected]> 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
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 <[email protected]>
>
> 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
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
On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <[email protected]> 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.
On Fri, 2012-06-08 at 18:54 +0200, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <[email protected]> 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
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
On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> <[email protected]> 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 <[email protected]>
> >>
> >> 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 <[email protected]>
Date: Mon May 7 17:45:29 2012 +0200
mac80211: fix single queue drivers
johannes
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
On Fri, Jun 15, 2012 at 4:03 AM, Larry Finger <[email protected]> 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
>>> <[email protected]> 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?
On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
<[email protected]> 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 ;)
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
On Wed, 13 Jun 2012 17:46:42 +0200
Johannes Berg <[email protected]> wrote:
> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
> > <[email protected]> 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
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
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
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
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
On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
<[email protected]> 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
On Fri, Jun 8, 2012 at 5:52 PM, Johannes Berg <[email protected]> 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
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
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
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
On 06/08/2012 01:10 PM, Michael Büsch wrote:
> On Fri, 08 Jun 2012 12:43:06 -0500
> Larry Finger <[email protected]> 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
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
>> <[email protected]> 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
On Thu, 2012-06-14 at 19:23 +0200, Andre Heider wrote:
> On Thu, Jun 14, 2012 at 7:17 PM, Johannes Berg
> <[email protected]> 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
On Thu, 7 Jun 2012 17:24:51 +0200
Andre Heider <[email protected]> wrote:
> On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <[email protected]> wrote:
> > On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
> >> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
> >> <[email protected]> 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 <[email protected]>
> >> >>
> >> >> 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 <[email protected]>
> > 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
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
On Thu, Jun 7, 2012 at 9:16 AM, Johannes Berg <[email protected]> wrote:
> On Thu, 2012-06-07 at 09:10 +0200, Andre Heider wrote:
>> On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
>> <[email protected]> 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 <[email protected]>
>> >>
>> >> 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 <[email protected]>
> 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
On 06/08/2012 11:05 AM, Andre Heider wrote:
> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <[email protected]> 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
On Fri, Jun 8, 2012 at 4:52 PM, Johannes Berg <[email protected]> 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
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
On Thu, 2012-06-07 at 23:47 +0200, Andre Heider wrote:
> On Thu, Jun 7, 2012 at 11:21 PM, Larry Finger <[email protected]> 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
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
On Fri, Jun 8, 2012 at 6:08 PM, Johannes Berg <[email protected]> wrote:
> On Fri, 2012-06-08 at 18:05 +0200, Andre Heider wrote:
>> On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <[email protected]> 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"
On Wed, Jun 13, 2012 at 8:42 PM, Michael B?sch <[email protected]> wrote:
> On Wed, 13 Jun 2012 17:46:42 +0200
> Johannes Berg <[email protected]> wrote:
>
>> On Wed, 2012-06-13 at 17:39 +0200, Andre Heider wrote:
>> > On Wed, Jun 13, 2012 at 10:31 AM, Johannes Berg
>> > <[email protected]> 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;
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
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
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
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
On Fri, Jun 8, 2012 at 5:16 PM, Johannes Berg <[email protected]> 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.
On Fri, Jun 8, 2012 at 9:37 PM, Larry Finger <[email protected]> wrote:
> On 06/08/2012 01:31 PM, Michael B?sch wrote:
>>
>> On Fri, 08 Jun 2012 13:23:46 -0500
>> Larry Finger <[email protected]> wrote:
>>
>>> On 06/08/2012 01:10 PM, Michael B?sch wrote:
>>>>
>>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>>> Larry Finger <[email protected]> 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
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
On Fri, Jun 8, 2012 at 6:41 PM, Johannes Berg <[email protected]> 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...
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
On Fri, Jun 8, 2012 at 8:11 PM, Johannes Berg <[email protected]> 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.
On Fri, 08 Jun 2012 12:43:06 -0500
Larry Finger <[email protected]> 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
On Fri, Jun 8, 2012 at 8:41 AM, Johannes Berg <[email protected]> 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 <[email protected]> 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.
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
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
On Thu, Jun 14, 2012 at 6:37 PM, Johannes Berg
<[email protected]> 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
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
On Fri, Jun 8, 2012 at 5:59 PM, Johannes Berg <[email protected]> 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.
On Wed, Jun 6, 2012 at 10:35 PM, Johannes Berg
<[email protected]> 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 <[email protected]>
>>
>> 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
On Fri, 08 Jun 2012 18:28:24 +0200
Johannes Berg <[email protected]> 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
On 06/08/2012 01:31 PM, Michael Büsch wrote:
> On Fri, 08 Jun 2012 13:23:46 -0500
> Larry Finger <[email protected]> wrote:
>
>> On 06/08/2012 01:10 PM, Michael Büsch wrote:
>>> On Fri, 08 Jun 2012 12:43:06 -0500
>>> Larry Finger <[email protected]> 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
On Thu, 07 Jun 2012 12:25:07 -0500
Larry Finger <[email protected]> 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
On 06/07/2012 12:30 PM, Michael Büsch wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <[email protected]> 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
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
On Thu, Jun 7, 2012 at 7:30 PM, Michael B?sch <[email protected]> wrote:
> On Thu, 07 Jun 2012 12:25:07 -0500
> Larry Finger <[email protected]> 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
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
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 <[email protected]> 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
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
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
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
On Fri, 08 Jun 2012 13:23:46 -0500
Larry Finger <[email protected]> wrote:
> On 06/08/2012 01:10 PM, Michael Büsch wrote:
> > On Fri, 08 Jun 2012 12:43:06 -0500
> > Larry Finger <[email protected]> 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
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
