usb/132080: [patch] [usb] Kernel panic after NOMEM caused by rum card

[Alexander Melkov]

Hello!

> Maybe you can 
> confirm that the time from start of device with heavy download until it gets 
> the first timeout is 10minutes?

I've unplugged and reinserted the usb card, then restarted wifi and started network activity.
There doesn't seem to be any timeout within 21 minutes.

There were 3 consecutive device timeouts yesterday (since my system doesn't reboot any more).
Feb 24 10:42:49 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 10:42:49 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 10:42:54 melkov kernel: rum0: device timeout
Feb 24 10:57:26 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 10:57:26 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 10:57:31 melkov kernel: rum0: device timeout
Feb 24 11:05:02 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 11:05:02 melkov kernel: rum0: could not transmit buffer: NOMEM
Feb 24 11:05:06 melkov kernel: rum0: device timeout

Between the timeouts I've restarted hostapd daemon (manually) to get wifi service working again.
Notably timeout #3 comes 7.5 minutes after #2.

--Alexander

From: "Hans Petter Selasky" <hselasky at c2i.net>, Wednesday, February 25, 2009 10:10
> Hi,
> 
> The RUM timeouts you are seeing I am aware about. They happen most likely 
> because the WLAN channel is set when the device is in the running state on 
> the RUM device due to WLAN re-keying or something like that. Maybe you can 
> confirm that the time from start of device with heavy download until it gets 
> the first timeout is 10minutes?
> 
> This issue is actually a RUM firmware issue. If it has frames pending for TX 
> and we set the channel, the chip will simply reset or do strange things.
> 
> Possible RUM workaround: Set the same WLAN channel only once.
> 
> I think Andrew Thompson is working on this. I have some patches in the USB P4 
> project for 8-current which fix the problem to a level where TX will 
> dissappear for 4 seconds every 10 minutes, but there will be no device 
> timeout! The final patch should solve the problem completely, but I need some 
> help to figure out when we should ignore set_channel requests.
> 
> --HPS
> 
> On Wednesday 25 February 2009, Alexander Melkov wrote:
>> >Number:         132080
>> >Category:       usb
>> >Synopsis:       [patch] [usb] Kernel panic after NOMEM caused by rum card
>> >Confidential:   no
>> >Severity:       serious
>> >Priority:       medium
>> >Responsible:    freebsd-usb
>> >State:          open
>> >Quarter:
>> >Keywords:
>> >Date-Required:
>> >Class:          sw-bug
>> >Submitter-Id:   current-users
>> >Arrival-Date:   Wed Feb 25 01:20:02 UTC 2009
>> >Closed-Date:
>> >Last-Modified:
>> >Originator:     Alexander Melkov
>> >Release:        7.1-STABLE
>> >Organization:
>> >Environment:
>>
>> FreeBSD melkov.ru 7.1-STABLE FreeBSD 7.1-STABLE #14: Tue Feb 24 06:28:45
>> MSK 2009     root_at_melkov.ru:/usr/obj/usr/src/sys/MELKOV  amd64
>>
>> >Description:
>>
>> I have <rum> device which is Cisco-Linksys Compact Wireless-G USB Adapter
>> that runs in hostap mode (i.e. wifi access point). Sometimes it
>> malfunctions (that may happen several times a day), at that moment I have
>> message "rum0: could not transmit buffer: NOMEM" from kernel. Right after
>> the message kernel crashes upon read from (nearly) null address.
>>