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

[Hans Petter Selasky]

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.
>