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" <[email protected]>, 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.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
