Re: Broadcom BCM4310 / bwi(4) and interface bwi0 is not showing up
On Sunday, October 24, 2010 07:25:59 Matthias Apitz wrote:
> Hello,
>
> I have a new laptop Acer Aspire One D250 and I want to install a
> 8-CURRENT as of CVS from May 2009 (as I use this on all my laptops).
> The laptop comes with as Wifi chip:
>
> no...@pci0:1:0:0: class=0x028000 card=0xe01b105b chip=0x431514e4
> rev=0x01 hdr=0x00
> vendor = 'Broadcom Corporation'
> device = 'BCM4310 USB Controller'
> class = network
>
> I learned after searching around that it should be supported by bwi(4)
> and one should install the firmware kmod from the ports. I have in
> loader.conf:
> [..]
Please try attached patch, I'm not sure if it is that simple.. worth a try
though.
--
Bernhard
--- a/sys/dev/bwi/if_bwi_pci.c
+++ b/sys/dev/bwi/if_bwi_pci.c
@@ -85,6 +85,7 @@ static const struct bwi_dev {
{ PCI_VENDOR_BROADCOM, 0x4311,"Broadcom BCM4311 802.11b/g Wireless Lan" },
{ PCI_VENDOR_BROADCOM, 0x4312,"Broadcom BCM4312 802.11a/b/g Wireless Lan" },
{ PCI_VENDOR_BROADCOM, 0x4313,"Broadcom BCM4312 802.11a Wireless Lan" },
+ { PCI_VENDOR_BROADCOM, 0x4315,"Broadcom BCM4312 802.11b/g Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4320,"Broadcom BCM4306 802.11b/g Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4321,"Broadcom BCM4306 802.11a Wireless Lan"},
{ PCI_VENDOR_BROADCOM, 0x4325,"Broadcom BCM4306 802.11b/g Wireless Lan"},
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Current problem reports assigned to freebsd-net@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/151690 netnetwork connectivity won't work until dhclient is run o kern/151681 net[nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net[igb] [panic] Kernel panic when bringing up igb networ o kern/151441 net[iwi] iwi module not work properly using HP nc6220 o kern/150920 net[ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net[igb] igb0: Watchdog timeout -- resetting o kern/150257 net[msk] watchdog timeout o kern/150251 net[patch] [ixgbe] Late cable insertion broken o kern/150249 net[ixgbe] Media type detection broken o kern/150247 net[patch] [ixgbe] Version in -current won't build on 7.x o bin/150224 netppp(8) does not reassign static IP after kill -KILL co o kern/150148 net[ath] Atheros 5424/2424 - AR2425 stopped working with o kern/150052 net[wi] wi(4) driver does not work with wlan(4) driver fo f kern/149969 net[wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net[ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149786 net[bwn] bwn on Dell Inspiron 1150: connections stall o kern/149643 net[rum] device not sending proper beacon frames in ap mo o kern/149609 net[panic] reboot after adding second default route o kern/149539 net[ath] atheros ar9287 is not supported by ath_hal o kern/149516 net[ath] ath(4) hostap with fake MAC/BSSID results in sta o kern/149373 net[realtek/atheros]: None of my network card working o kern/149307 net[ath] Doesn't work Atheros 9285 o kern/149306 net[alc] Doesn't work Atheros AR8131 PCIe Gigabit Etherne o kern/149117 net[inet] [patch] in_pcbbind: redundant test o kern/149086 net[multicast] Generic multicast join failure in 8.1 o kern/148862 net[panic] page fault while in kernel mode at _mtx_lock_s o kern/148322 net[ath] Triggering atheros wifi beacon misses in hostap o kern/148317 net[ath] FreeBSD 7.x hostap memory leak in net80211 or At o kern/148078 net[ath] wireless networking stops functioning o kern/147985 net[alc] alc network driver + tso ( + vlan ? ) does not w o kern/147894 net[ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147862 net[wpi] Possible bug in the wpi driver. Network Manager o kern/147155 net[ip6] setfb not work with ipv6 o kern/146845 net[libc] close(2) returns error 54 (connection reset by o kern/146792 net[flowtable] flowcleaner 100% cpu's core load o kern/146759 net[cxgb] [patch] cxgb panic calling cxgb_set_lro() witho o kern/146719 net[pf] [panic] PF or dumynet kernel panic o kern/146534 net[icmp6] wrong source address in echo reply o kern/146517 net[ath] [wlan] device timeouts for ath wlan device on re o kern/146427 net[mwl] Additional virtual access points don't work on m o kern/146426 net[mwl] 802.11n rates not possible on mwl o kern/146425 net[mwl] mwl dropping all packets during and after high u f kern/146394 net[vlan] IP source address for outgoing connections o bin/146377 net[ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net[vlan] wrong destination MAC address o kern/146165 net[wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net[ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net[panic] mpd + CoA = kernel panic o bin/145934 net[patch] add count option to netstat(1) o kern/145826 net[ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net[panic] panic: soabort: so_count o kern/145777 net[wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net[lagg] Stops working lagg between two servers. o amd64/145654 netamd64-curent memory leak in kernel o kern/144987 net[wpi] [panic] injecting packets with wlaninject using o kern/144882 netMacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net[if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net[rc.d] async dhclient breaks stuff for too many people o kern/144642 net[rum] [panic] Enabling rum interface causes panic o kern/144616 net[nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net[carp] CARP preemption mode traffic partially goes to f kern/144315
Re: carp and arp_rtrequest: bad gateway 1.1.1.5 (!AF_LINK)
Further workaround: 1st server has advbase 1 and advskew 0 2nd server has advbase 1 and advskew 100 So 2nd server should failover after what period of time when 1st server fails? In openbsd man 8 ifconfig ( http://www.openbsd.org/cgi-bin/man.cgi?query=ifconfig&apropos=0&sektion=8&manpath=OpenBSD+Current&arch=i386&format=html ) I found that info: Taken together, the advbase and advskew indicate how frequently, in seconds, the host will advertise the fact that it considers itself master of the virtual host. The formula is advbase + (advskew / 256). If the master does not advertise within three times this interval, this host will begin advertising as master. Due to CARP be ported from openbsd I think it should be same for freebsd too. So 2nd server should take MASTER state after 3*(advbase+(advskew / 256)) = 3*(1+(100/256)) =~ 4 secs. But when I promote 1st servers CARP interface down, 2nd server became MASTER immediately, no 4 seconds holdtime/timeout occurs. Why is it so? Any tips? Want to understand why 2nd server takes master state too often while 1st server are still available in network. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/147985: [alc] alc network driver + tso ( + vlan ? ) does not work.
Synopsis: [alc] alc network driver + tso ( + vlan ? ) does not work. State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Oct 25 18:32:39 UTC 2010 State-Changed-Why: I can't reproduce this on my box with/without VLAN. I believe this is the first report that TSO issue on alc(4) and I have no idea how this can happen. The only vague guess I have at this moment is upper stack's TSO issue. r212803 fixed a TSO issue but it was not MFCed yet due to possible side-effects. http://svn.freebsd.org/viewvc/base/head/sys/netinet/tcp_output.c?r1=212765&r2=212803&view=patch Another thing to try is using alc(4) in stable/8. http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/alc/if_alc.c http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/alc/if_alcreg.h http://svn.freebsd.org/viewvc/base/stable/8/sys/dev/alc/if_alcvar.h I'm not sure whether it correctly builds on 8.1-RELEASE but mostly it would work. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 25 18:32:39 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=147985 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: kern/150257: [msk] watchdog timeout
Synopsis: [msk] watchdog timeout State-Changed-From-To: open->feedback State-Changed-By: yongari State-Changed-When: Mon Oct 25 19:17:29 UTC 2010 State-Changed-Why: I also have a DGE-560T but I can't reproduce this issue on my box. Because you said disabling MSI fixed the issue I vaguely guess it could be a silicon bug which controller sometimes looses Tx completion interrupts or could be trggered by inappropriately programmed event timer for the controller. It seems Yukon II controllers are very sensitive to internal timer values so it can also trigger the issue. I don't have permanent solution for these issues but you can try the patch at the following URL. http://people.freebsd.org/~yongari/msk/msk.watchdog.diff It does not fix the issue but it will show watchdog timeout message and tries to recover from that ranther than completely resetting controller. If all goes ok, it sometimes shows watchdog timeouts but it wouldn't reset controller such that you can treat the watchdog timeouts as information message. Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Mon Oct 25 19:17:29 UTC 2010 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=150257 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Query Regarding RFC 3517/RFC 4653 Implementation
Hi RFC 4653: I am looking for an Implementation of RFC 4653(Improving Robustness of TCP for Non Congestion Events) in FreeBSD and I figured from the to-do page http://wiki.freebsd.org/Networking that it is yet to be implemented. Is that true still?(as the page seems to have been updated an year ago). RFC 3517 : Again, Is this implemented as per the RFC or FreeBSD has its own version of SACK based Loss recovery for TCP? Reason that this question is raised being that the to-do list for FreeBSD/Networking says "Review FreeBSD TCP SACK implementation against RFC 3517's Conservative SACK Recovery Scheme" Expecting your inputs, S Lakshmi Narasimhan ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Question on TCP reassembly counter
On 10/25/10 17:40, Sriram Gorti wrote: > Hi, > > On Sat, Oct 23, 2010 at 5:29 AM, Lawrence Stewart > wrote: >> On 10/22/10 18:10, Sriram Gorti wrote: >>> Hi, >>> >>> On Mon, Oct 18, 2010 at 3:08 AM, Lawrence Stewart >>> wrote: >>> >>> Thanks for the fix. Tried it on XLR/XLS and the earlier tests pass >>> now. net.inet.tcp.reass.overflows was always zero after the tests (and >>> in the samples I took while the tests were running). >> >> Great, thanks for testing. >> >>> One observation though: net.inet.tcp.reass.cursegments was non-zero >>> (it was just 1) after 30 rounds, where each round is (as earlier) >>> 15-concurrent instances of netperf for 20s. This was on the netserver >>> side. And, it was zero before the netperf runs. On the other hand, >>> Andre told me (in a separate mail) that this counter is not relevant >>> anymore - so, should I just ignore it ? >> >> It's relevant, just not guaranteed to be 100% accurate at any given >> point in time. The value is calculated based on synchronised access to >> UMA zone stats and unsynchronised access to UMA per-cpu zone stats. The >> latter is safe, but causes the overall result to potentially be >> inaccurate due to use of stale data. The accuracy vs overhead tradeoff >> was deemed worthwhile for informational counters like this one. >> >> That being said, I would not expect the value to remain persistently at >> 1 after all TCP activity has finished on the machine. It won't affect >> performance, but I'm curious to know if the calculation method has a >> flaw. I'll try to reproduce locally, but can you please confirm if the >> value stays at 1 even after many minutes of no TCP activity? >> > > This behavior does repeat easily but finally it did. Even after > leaving the system alone (other than for background NFS messages) for > a few mins, the value persists. After a little more investigation, it > is observed that one of the spawned netserver's has not terminated and > when it is explicitly terminated, the sysctl of interest drops back to > zero. Does that mean the TCP reassembly portion is doing okay ? Yes, the fact that it drops to zero after killing the process indicates everything is as I expected wrt the accounting. Thanks for confirming. > But, it opens up the question of why the netserver has not terminated. > I will dig further into it but if you have any quick suggestions, they > are most welcome. Not sure I can answer that, but I'm very interested to know why a segment appears to become stuck in the reassembly queue. It seems unlikely that an actual segment is stuck, as the connection would eventually timeout if it was waiting for a retransmit that never came. It seems more probable that the process being wedged simply causes the net.inet.tcp.reass.cursegments sysctl to continue reporting a stale value, perhaps due to the per-cpu calculation continually using the same stale data whilst the process is running. Perhaps you could try reproduce whilst using siftr(4) to capture data at the same time. That will allow you to see for sure what the state of the reass queue is amongst other things and rule out a segment really being stuck in the queue. You could then also use perhaps procstat -kk on the wedged process and/or truss/ktrace to see what it's doing. Quick-start guide for siftr (man page has full details): kldload siftr sysctl net.inet.siftr.logfile=/somewhere/with/decent/space/siftr.log sysctl net.inet.siftr.enabled=1 sysctl net.inet.siftr.enabled=0 If it takes a few attempts to reproduce, delete the siftr log file in between each reproduction attempt so we end up with a log that only covers an actual example. I think it's the last column that logs the size of the reass queue. Filter log for the connection of interest (e.g. grep "," siftr.log | tail), and check what the reass queue size is when the last packet for that connection was sent/received. Let me know how you go. Cheers, Lawrence ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
