* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:25 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 15:25 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:25 ` Andre Heider
@ 2012-06-08 15:38 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 15:38 UTC (permalink / raw)
To: Andre Heider
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:38 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 15:38 UTC (permalink / raw)
To: Andre Heider
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:38 ` Larry Finger
@ 2012-06-08 15:43 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:43 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:43 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:43 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:43 ` Johannes Berg
@ 2012-06-08 15:44 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:44 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:44 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:44 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:44 ` Johannes Berg
@ 2012-06-08 15:48 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:48 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:48 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:48 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:48 ` Johannes Berg
@ 2012-06-08 15:52 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:52 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:52 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:52 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:52 ` Johannes Berg
@ 2012-06-08 15:56 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 15:56 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:56 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 15:56 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:56 ` Andre Heider
@ 2012-06-08 15:59 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:59 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:59 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:59 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:59 ` Johannes Berg
@ 2012-06-08 16:05 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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.
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:05 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:05 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:05 ` Andre Heider
@ 2012-06-08 16:08 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:08 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:08 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:08 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:08 ` Johannes Berg
@ 2012-06-08 16:16 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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"
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:16 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:16 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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"
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:16 ` Andre Heider
@ 2012-06-08 16:20 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:20 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:20 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:20 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:20 ` Johannes Berg
@ 2012-06-08 16:24 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:24 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:24 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:24 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:16 ` Andre Heider
@ 2012-06-08 16:41 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:41 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:41 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:41 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:41 ` Johannes Berg
@ 2012-06-08 16:54 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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...
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:54 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 16:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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...
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:54 ` Andre Heider
@ 2012-06-08 16:56 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:56 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:56 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:56 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:05 ` Andre Heider
@ 2012-06-08 16:24 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 16:24 UTC (permalink / raw)
To: Andre Heider
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:24 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 16:24 UTC (permalink / raw)
To: Andre Heider
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:24 ` Larry Finger
@ 2012-06-08 16:28 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:28 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:28 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 16:28 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:28 ` Johannes Berg
@ 2012-06-08 16:33 ` Michael Büsch
-1 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 16:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, Andre Heider, linux-wireless, b43-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 16:33 ` Michael Büsch
0 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 16:33 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, Andre Heider, linux-wireless, b43-dev
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>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:33 ` Michael Büsch
@ 2012-06-08 17:43 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 17:43 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 17:43 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 17:43 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 17:43 ` Larry Finger
@ 2012-06-08 17:56 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 17:56 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 17:56 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 17:56 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 17:56 ` Johannes Berg
@ 2012-06-08 18:11 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:11 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:11 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:11 ` Johannes Berg
@ 2012-06-08 18:28 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev
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.
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:28 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 18:28 UTC (permalink / raw)
To: Johannes Berg; +Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev
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.
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:28 ` Andre Heider
@ 2012-06-08 18:38 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:38 UTC (permalink / raw)
To: Andre Heider; +Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:38 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:38 UTC (permalink / raw)
To: Andre Heider; +Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 17:43 ` Larry Finger
@ 2012-06-08 18:10 ` Michael Büsch
-1 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 18:10 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:10 ` Michael Büsch
0 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 18:10 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:10 ` Michael Büsch
@ 2012-06-08 18:23 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 18:23 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:23 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 18:23 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:23 ` Larry Finger
@ 2012-06-08 18:31 ` Michael Büsch
-1 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 18:31 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:31 ` Michael Büsch
0 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-08 18:31 UTC (permalink / raw)
To: Larry Finger; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:31 ` Michael Büsch
@ 2012-06-08 19:37 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 19:37 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 19:37 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-08 19:37 UTC (permalink / raw)
To: Michael Büsch; +Cc: Johannes Berg, Andre Heider, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 19:37 ` Larry Finger
@ 2012-06-08 19:42 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 19:42 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Johannes Berg, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 19:42 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-08 19:42 UTC (permalink / raw)
To: Larry Finger; +Cc: Michael Büsch, Johannes Berg, linux-wireless, b43-dev
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 16:24 ` Larry Finger
@ 2012-06-08 18:36 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:36 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:36 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:36 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:36 ` Johannes Berg
@ 2012-06-08 18:42 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:42 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 18:42 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 18:42 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 18:42 ` Johannes Berg
@ 2012-06-08 19:04 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 19:04 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 19:04 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 19:04 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 19:04 ` Johannes Berg
@ 2012-06-13 8:31 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-13 8:31 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-13 8:31 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-13 8:31 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-13 8:31 ` Johannes Berg
@ 2012-06-13 15:39 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-13 15:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-13 15:39 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-13 15:39 UTC (permalink / raw)
To: Johannes Berg
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-13 15:39 ` Andre Heider
@ 2012-06-13 15:46 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-13 15:46 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-13 15:46 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-13 15:46 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-13 15:46 ` Johannes Berg
@ 2012-06-13 18:42 ` Michael Büsch
-1 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-13 18:42 UTC (permalink / raw)
To: Johannes Berg
Cc: Andre Heider, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
[-- 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 --]
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-13 18:42 ` Michael Büsch
0 siblings, 0 replies; 135+ messages in thread
From: Michael Büsch @ 2012-06-13 18:42 UTC (permalink / raw)
To: Johannes Berg
Cc: Andre Heider, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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>
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-13 18:42 ` Michael Büsch
@ 2012-06-14 16:26 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 16:26 UTC (permalink / raw)
To: Michael Büsch
Cc: Johannes Berg, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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;
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 16:26 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 16:26 UTC (permalink / raw)
To: Michael Büsch
Cc: Johannes Berg, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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;
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 16:26 ` Andre Heider
@ 2012-06-14 16:37 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 16:37 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 16:37 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 16:37 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 16:37 ` Johannes Berg
@ 2012-06-14 17:00 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 17:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 17:00 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 17:00 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 17:00 ` Andre Heider
@ 2012-06-14 17:09 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:09 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 17:09 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:09 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 17:09 ` Johannes Berg
@ 2012-06-14 17:17 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:17 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 17:17 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:17 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 17:17 ` Johannes Berg
@ 2012-06-14 17:23 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 17:23 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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 ;)
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 17:23 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-14 17:23 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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 ;)
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 17:23 ` Andre Heider
@ 2012-06-14 17:27 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:27 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-14 17:27 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-14 17:27 UTC (permalink / raw)
To: Andre Heider
Cc: Michael Büsch, Larry Finger, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-14 17:27 ` Johannes Berg
@ 2012-06-15 2:03 ` Larry Finger
-1 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-15 2:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-15 2:03 ` Larry Finger
0 siblings, 0 replies; 135+ messages in thread
From: Larry Finger @ 2012-06-15 2:03 UTC (permalink / raw)
To: Johannes Berg
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-15 2:03 ` Larry Finger
@ 2012-06-15 8:17 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-15 8:17 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-15 8:17 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-15 8:17 UTC (permalink / raw)
To: Larry Finger
Cc: Andre Heider, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-15 2:03 ` Larry Finger
@ 2012-06-15 17:14 ` Andre Heider
-1 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-15 17:14 UTC (permalink / raw)
To: Larry Finger
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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?
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-15 17:14 ` Andre Heider
0 siblings, 0 replies; 135+ messages in thread
From: Andre Heider @ 2012-06-15 17:14 UTC (permalink / raw)
To: Larry Finger
Cc: Johannes Berg, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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?
^ permalink raw reply [flat|nested] 135+ messages in thread
* Re: chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
2012-06-08 15:25 ` Andre Heider
@ 2012-06-08 15:38 ` Johannes Berg
-1 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:38 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread
* chip id 4318 regression: WARN_ON_ONCE(sdata->vif.hw_queue[i] >= n_queues))
@ 2012-06-08 15:38 ` Johannes Berg
0 siblings, 0 replies; 135+ messages in thread
From: Johannes Berg @ 2012-06-08 15:38 UTC (permalink / raw)
To: Andre Heider
Cc: Larry Finger, Michael Büsch, linux-wireless, b43-dev,
Rafał Miłecki
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
^ permalink raw reply [flat|nested] 135+ messages in thread