Date: Tue, 29 Mar 2011 10:40:10 GMT From: PseudoCylon <moonlightakkiy@yahoo.ca> To: freebsd-usb@FreeBSD.org Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault while in kernel mode Message-ID: <201103291040.p2TAeADZ043841@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR usb/156000; it has been noted by GNATS.
From: PseudoCylon <moonlightakkiy@yahoo.ca>
To: bug-followup@freebsd.org, rcp@mipang.com
Cc: Hans Petter Selasky <hselasky@c2i.net>
Subject: Re: usb/156000: rum(4) Fatal trap 18: integer divide fault while in kernel mode
Date: Tue, 29 Mar 2011 03:09:33 -0700 (PDT)
> sudo arping -i wlan0 -b -S 192.168.77.100 -s 00:21:fe:3e:0a:6b -t
>00:1d:0f:07:9b:28 192.168.77.1
>
> * 00:1d:0f:07:9b:28 is the rum0/wlan0 's MAC
Looks like
1) rum0 was asked to Tx a packet with it's own mac addr as dst addr
2) find_tx_node() picked Tx node with ni_associd == 0 (node with own mac addr)
because rum0 runs in HOSTAP mode, IEEE80211_NODE_ASSOCID flag hasn't been
set
3) the packet slip though this test
http://fxr.watson.org/fxr/source/net80211/ieee80211_output.c#L231
4) picked up a bogus value at
http://fxr.watson.org/fxr/source/dev/usb/wlan/if_rum.c#L1221
5) probably divided by 0 at
http://fxr.watson.org/fxr/source/dev/usb/wlan/if_rum.c#L1019
[RFC] could add a simple test to the driver, like if (rate != 0), but isn't it
nicer to patch in ieee80211_output.c?
workaround
Also addm em0, and set dhcpd_iface in /etc/re.conf
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dhcp.html
Then, it should work without issuing tricky arping
AK
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201103291040.p2TAeADZ043841>