Bug 149786
| Summary: | [bwn] bwn on Dell Inspiron 1150: connections stall | ||
|---|---|---|---|
| Product: | Base System | Reporter: | tom |
| Component: | wireless | Assignee: | freebsd-wireless (Nobody) <wireless> |
| Status: | Open --- | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
Responsible Changed From-To: freebsd-bugs->freebsd-net Over to maintainer(s). What if you force it to work in mode 11b? I have similiar problem here, but it is usable if I `ifconfig wlan0 mode 11b ssid BLAH` Buganini no stalled connections so far after explicitly setting "mode 11b", but i have only done the most minimal testing so far. there have been a few times when connections seemed bursty, but that could have been due to the lower bandwidth & buffering effects, or it could have been my imagination... in any case it seems we have the same issue. tom after a bit more testing, i seem to be experiencing some minor problems in 802.11b mode too: when doing a cvs update of /usr/src from an NFSv3 mounted repository, i experienced a number of NFS failures. but unlike running the wlan in g mode, it did always recover and start talking again (nfs server not responding ... nfs server is alive again ...) Responsible Changed From-To: freebsd-net->freebsd-wireless Over to maintainer(s) I have nearly the same problem/symptoms on FreeBSD 9.0-STABLE #0 r235121:
siba_bwn0@pci0:4:0:0: class=0x028000 card=0x000c1028 chip=0x431514e4
rev=0x01 hdr=0x00
vendor = 'Broadcom Corporation'
device = 'BCM4312 802.11b/g LP-PHY'
class = network
Toggling hw.bwn.usedma to 0 resulting in less console spam, but the
operation of the device seems even more flaky then albeit with less console
spam.
Setting mode 11b also seems to work around the issue, but it's a not really
a desirable workaround and introduces console spam of "bwn0: unsupported
rate 0".
--
Adam Vande More
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed. |
My laptop (Dell Inspiron 1150) has bwn supported wireless provided by a Broadcom internal mini-pci card. the identifying info printed os said card is c2003 BROADCOM CORP BCM94306MPSG REV4 pciconf -lv says: siba_bwn0@pci0:2:2:0: class=0x028000 card=0x00031028 chip=0x432014e4 rev=0x03 hdr=0x00 vendor = 'Broadcom Corporation' device = '802.11b/g Wireless LAN Controller (BCM4309)' class = network and dmesg says: siba_bwn0: <Broadcom BCM4306 802.11b/g Wireless> mem 0xfcffc000-0xfcffdfff irq 11 at device 2.0 on pci2 bwn0 on siba_bwn0 bwn0: WLAN (chipid 0x4306 rev 5) PHY (analog 2 type 2 rev 2) RADIO (manuf 0x17f ver 0x2050 rev 2) bwn0: DMA (30 bits) bwn0: [FILTER] this card seems to initialize properly and associate w/ any nearby access point. but when it is used to make TCP connections, the connection will always stall (and eventually time out and disconnect) any time it receives a substantial amount of data at once (the threshold seems to be a few hundred bytes). for example, i can ssh to another host, and as long as i stick to commands that only produce a few bytes of output it will work indefinitely. but as soon as i do anything that produces a more significant amount of output, for example "ls -al" or "man bwn" it will stall, and i get nothing more from that connection. http w/ firefox behaves similarly: small simple pages load, big ones lock up. the problem seems to affect individual connects rather then locking up the driver as a whole. when an ssh session locks up, i can open a new window and ssh to the same or any other host and the new session will also connect and behave as described above. this occurs w/ GENERIC as well as my customized kernel (w/ all unused drivers, etc stripped from config). it does not affect other network drivers (such as builtin bfe port or an ath based wireless pccard). none of the changes in current that have not yet been MFC'd had any effect, nor could i find any past revision where this problem did not occur. Fix: n/a How-To-Repeat: % ssh <some host> // via bwn0 / wlan0 interface % cd /usr/bin % ls -al session becomes non-responsive and will eventually time out & disconnect, it can be killed (-9) from another window or vty.