Re: [POLLING] strange interrupt/system load
On 2009-Sep-13 07:19:24 -0700, Barney Cordoba wrote: >64bits must be faster than 32bits is patently misguided. My rule of >thumb is that if I don't need 64bits for something, I avoid it. It's not quite that cut-and-dry. The 64-bit ISA is significantly different to the 32-bit ISA and has different subroutine calling conventions. Yes, you do need to lug 64-bit pointers around but the overall codesize is comparable (looking at /usr/bin and /lib suggests about a 5% increase in size going from i386 to amd64) - a lot of this is probably because amd64 has a 16-bit offset mode so there's much less need for 32-bit offsets. Having twice as many registers is a win in some areas (less spilling to memory) and a loss in others (more state to save/restore on a context switch). If performance is critical, it's probably worthwhile benchmarking both i386 and amd64 variants and seeing which works best for you. -- Peter Jeremy pgpMmwiAepFmo.pgp Description: PGP signature
Re: [POLLING] strange interrupt/system load
--- On Tue, 9/15/09, peterjer...@acm.org wrote: > From: peterjer...@acm.org > Subject: Re: [POLLING] strange interrupt/system load > To: "Barney Cordoba" > Cc: freebsd-net@freebsd.org > Date: Tuesday, September 15, 2009, 3:38 AM > On 2009-Sep-13 07:19:24 -0700, Barney > Cordoba > wrote: > >64bits must be faster than 32bits is patently > misguided. My rule of > >thumb is that if I don't need 64bits for something, I > avoid it. > > It's not quite that cut-and-dry. The 64-bit ISA is > significantly > different to the 32-bit ISA and has different subroutine > calling > conventions. Yes, you do need to lug 64-bit pointers > around but the > overall codesize is comparable (looking at /usr/bin and > /lib suggests > about a 5% increase in size going from i386 to amd64) - a > lot of this > is probably because amd64 has a 16-bit offset mode so > there's much > less need for 32-bit offsets. Having twice as many > registers is a > win in some areas (less spilling to memory) and a loss in > others (more > state to save/restore on a context switch). > > If performance is critical, it's probably worthwhile > benchmarking > both i386 and amd64 variants and seeing which works best > for you. > "Rules of Thumb" are generally for those times when you don't have a pressing preference and you don't want to spend your life endlessly benchmarking. I don't think its the code, necessarity, but rather the significant increase in the size of data structures, and the memory that has to be moved around. I haven't tried with the latest compiler but I can't see why it would have any benefit for systems used for high capacity networking other than incrementing counters. Barney ___ 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: 8.0-BETA4 not responding to ARP for published entries
Hi, At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote: > Hi, > > Please try patch at > >http://people.freebsd.org/~qingli/proxy-arp-patch.diff > > -- Qing Thanks for taking care of it. I tried it, and now proxy arp works on the patched FreeBSD 8.0-CURRENT-200902/amd64 as expected. Thanks! Could it be considered important enough to make it into 8.0-RELEASE at this final stage? Hope it will, but if not, please consider to point it out in the release note. Hiroharu Tamaru > -Original Message- > From: owner-freebsd-...@freebsd.org on behalf of Hiroharu Tamaru > Sent: Mon 9/14/2009 6:34 PM > To: freebsd-net@freebsd.org > Subject: Re: 8.0-BETA4 not responding to ARP for published entries > > > At Mon, 14 Sep 2009 10:43:09 -0700, Chris Cowart wrote: > > We have a system which makes heavy use of published arp entries. I know > > the arp code has been significantly overhauled in 8, but it looks like > > this functionality is now broken. > > > > $ arp -s 172.16.132.100 00:0c:29:16:bd:49 pub > > > > If I watch tcpdump on the interface, I see arp requests come in but no > > replies are sent. This is a clean build with no firewalls enabled. > > Just for another datapoint, I see the same symptom. > I am currently running ports/net-mgmt/choparp as a workaround. > > At Thu, 23 Apr 2009 21:13:51 +0900, Hiroharu Tamaru wrote: > > Subject: proxy arp on 8.0-current? > > Date: Thu, 23 Apr 2009 21:13:51 +0900 > > To: freebsd-net@freebsd.org > > > > Hi, > > > > I'm trying to setup an proxy arp on a dual homed host. > > > > I noticed that I cannot set it up on 8.0-current the same way as I > > could on 6.2; hence the question: have the setup procedure changed > > recently (when the arp table was separated from the routing table, > > maybe?)? My 8.0-current is from 200902 snapshot. > > > > Here is a simple demonstration using two single-interfaced hosts: > > > > setup: > > host6.2# ifconfig em0 inet 192.168.0.1/24 > > host6.2# arp -s 192.168.0.11 auto pub > > host6.2# arp -an | grep permanent > > ? (192.168.0.1) at 00:16:d3:xx:xx:xx on em0 permanent [ethernet] > > ? (192.168.0.11) at 00:16:d3:xx:xx:xx on em0 permanent published [ethernet] > > host6.2# tcpdump -np arp > > > > host8.0# ifconfig em0 inet 192.168.0.2/24 > > host8.0# arp -s 192.168.0.12 auto pub > > host8.0# arp -an | grep permanent > > ? (192.168.0.2) at 00:0c:29:xx:xx:xx on em0 permanent [ethernet] > > ? (192.168.0.12) at 00:0c:29:xx:xx:xx on em0 permanent published [ethernet] > > host8.0# tcpdump -np arp > > > > then, I do: > > host6.2# arp -d 192.168.0.2; ping -c 1 192.168.0.2 > > host6.2# arp -d 192.168.0.12; ping -c 1 192.168.0.12 > > host8.0# arp -d 192.168.0.1; ping -c 1 192.168.0.1 > > host8.0# arp -d 192.168.0.11; ping -c 1 192.168.0.11 > > > > I am not caring about 'arp -d' errors (cannot locate) nor ping not > > responding (for proxied addresses). I just cared about arp requests and > > replys for now. The output of tcpdump on both sides are like this: > > > > arp who-has 192.168.0.2 tell 192.168.0.1 > > arp reply 192.168.0.2 is-at 00:0c:29:xx:xx:xx > > > > arp who-has 192.168.0.12 tell 192.168.0.1 > > >no reply > > > > arp who-has 192.168.0.1 tell 192.168.0.2 > > arp reply 192.168.0.1 is-at 00:16:d3:xx:xx:xx > > > > arp who-has 192.168.0.11 tell 192.168.0.2 > > arp reply 192.168.0.11 is-at 00:16:d3:xx:xx:xx > > > > As you can see from the above, > > 'arp -s 192.168.0.12 auto pub' on 8.0-current host > > seems not to be producing proxy arp's. > > > > What am I missing? > > > > Thanks. > > -- > > Hiroharu Tamaru ___ 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/127587: [bge] [request] if_bge(4) doesn't support BCM576X family
The following reply was made to PR kern/127587; it has been noted by GNATS.
From: matthieu
To: bug-follo...@freebsd.org
Cc:
Subject: Re: kern/127587: [bge] [request] if_bge(4) doesn't support BCM576X
family
Date: Tue, 15 Sep 2009 17:25:35 +0200
--0016e6d7e06cd8875604739f640b
Content-Type: text/plain; charset=ISO-8859-1
--- if_bge.c.back 2009-07-08 20:36:45.0 +0200
+++ if_bge.c2009-09-12 00:12:53.0 +0200
@@ -272,6 +272,7 @@
{ BGE_CHIPID_BCM5755_A1,"BCM5755 A1" },
{ BGE_CHIPID_BCM5755_A2,"BCM5755 A2" },
{ BGE_CHIPID_BCM5722_A0,"BCM5722 A0" },
+ { BGE_CHIPID_BCM5761, "BCM5761" },
/* 5754 and 5787 share the same ASIC ID */
{ BGE_CHIPID_BCM5787_A0,"BCM5754/5787 A0" },
{ BGE_CHIPID_BCM5787_A1,"BCM5754/5787 A1" },
@@ -2417,6 +2418,12 @@
sc->bge_asicrev = BGE_ASICREV(sc->bge_chipid);
sc->bge_chiprev = BGE_CHIPREV(sc->bge_chipid);
+ if (sc->bge_asicrev == BGE_ASICREV_PROD_ID_REG)
+ {
+ sc->bge_chipid = pci_read_config(dev, BGE_PCI_PRODID_ASICREV, 4);
+ }
+
+
/*
* Don't enable ether...@wirespeed for the 5700, 5906, or the
* 5705 A0 and A1 chips.
@@ -2424,8 +2431,9 @@
if (sc->bge_asicrev != BGE_ASICREV_BCM5700 &&
sc->bge_asicrev != BGE_ASICREV_BCM5906 &&
sc->bge_chipid != BGE_CHIPID_BCM5705_A0 &&
- sc->bge_chipid != BGE_CHIPID_BCM5705_A1)
- sc->bge_flags |= BGE_FLAG_WIRESPEED;
+ sc->bge_chipid != BGE_CHIPID_BCM5705_A1 &&
+ sc->bge_chipid != BGE_CHIPID_BCM5761)
+ sc->bge_flags |= BGE_FLAG_WIRESPEED;
if (bge_has_eaddr(sc))
sc->bge_flags |= BGE_FLAG_EADDR;
@@ -2474,6 +2482,10 @@
sc->bge_flags |= BGE_FLAG_BER_BUG;
}
+ if (sc->bge_chipid == BGE_CHIPID_BCM5761)
+ {
+ sc->bge_flags |= BGE_FLAG_5705_PLUS;
+ }
/*
* We could possibly check for BCOM_DEVICEID_BCM5788 in bge_probe()
--- if_bgereg.h.old 2009-03-23 15:36:50.0 +0100
+++ if_bgereg.h 2009-09-14 12:23:38.0 +0200
@@ -218,6 +218,7 @@
#defineBGE_PCI_UNDI_TX_BD_PRODIDX_LO 0xAC
#defineBGE_PCI_ISR_MBX_HI 0xB0
#defineBGE_PCI_ISR_MBX_LO 0xB4
+#defineBGE_PCI_PRODID_ASICREV 0xBC
/* PCI Misc. Host control register */
#defineBGE_PCIMISCCTL_CLEAR_INTA 0x0001
@@ -302,6 +303,7 @@
#defineBGE_CHIPID_BCM5787_A2 0xb002
#defineBGE_CHIPID_BCM5906_A1 0xc001
#defineBGE_CHIPID_BCM5906_A2 0xc002
+#defineBGE_CHIPID_BCM5761 0x05761100
/* shorthand one */
#defineBGE_ASICREV(x) ((x) >> 28)
@@ -319,6 +321,9 @@
#defineBGE_ASICREV_BCM5754 0x0b
#defineBGE_ASICREV_BCM5787 0x0b
#defineBGE_ASICREV_BCM5906 0x0c
+#defineBGE_ASICREV_PROD_ID_REG 0x0f
+
+#defineBGE_ASICREV_BCM5761 0x5761
/* chip revisions */
#defineBGE_CHIPREV(x) ((x) >> 24)
@@ -2098,6 +2103,7 @@
--0016e6d7e06cd8875604739f640b
Content-Type: text/plain; charset=US-ASCII; name="patch_5761.patch.txt"
Content-Disposition: attachment; filename="patch_5761.patch.txt"
Content-Transfer-Encoding: base64
X-Attachment-Id: file0
LS0tIGlmX2JnZS5jLmJhY2sJMjAwOS0wNy0wOCAyMDozNjo0NS4wMDAwMDAwMDAgKzAyMDAKKysr
IGlmX2JnZS5jCTIwMDktMDktMTIgMDA6MTI6NTMuMDAwMDAwMDAwICswMjAwCkBAIC0yNzIsNiAr
MjcyLDcgQEAKIAl7IEJHRV9DSElQSURfQkNNNTc1NV9BMSwJIkJDTTU3NTUgQTEiIH0sCiAJeyBC
R0VfQ0hJUElEX0JDTTU3NTVfQTIsCSJCQ001NzU1IEEyIiB9LAogCXsgQkdFX0NISVBJRF9CQ001
NzIyX0EwLAkiQkNNNTcyMiBBMCIgfSwKKwl7IEJHRV9DSElQSURfQkNNNTc2MSwJCSJCQ001NzYx
IiB9LCAKIAkvKiA1NzU0IGFuZCA1Nzg3IHNoYXJlIHRoZSBzYW1lIEFTSUMgSUQgKi8KIAl7IEJH
RV9DSElQSURfQkNNNTc4N19BMCwJIkJDTTU3NTQvNTc4NyBBMCIgfSwgCiAJeyBCR0VfQ0hJUElE
X0JDTTU3ODdfQTEsCSJCQ001NzU0LzU3ODcgQTEiIH0sCkBAIC0yNDE3LDYgKzI0MTgsMTIgQEAK
IAlzYy0+YmdlX2FzaWNyZXYgPSBCR0VfQVNJQ1JFVihzYy0+YmdlX2NoaXBpZCk7CiAJc2MtPmJn
ZV9jaGlwcmV2ID0gQkdFX0NISVBSRVYoc2MtPmJnZV9jaGlwaWQpOwogCisJaWYgKHNjLT5iZ2Vf
YXNpY3JldiA9PSBCR0VfQVNJQ1JFVl9QUk9EX0lEX1JFRykKKwkgIHsKKwkgICAgc2MtPmJnZV9j
aGlwaWQgPSBwY2lfcmVhZF9jb25maWcoZGV2LCBCR0VfUENJX1BST0RJRF9BU0lDUkVWLCA0KTsK
KwkgIH0KKworCiAJLyoKIAkgKiBEb24ndCBlbmFibGUgRXRoZXJuZXRAV2lyZVNwZWVkIGZvciB0
aGUgNTcwMCwgNTkwNiwgb3IgdGhlCiAJICogNTcwNSBBMCBhbmQgQTEgY2hpcHMuCkBAIC0yNDI0
LDggKzI0MzEsOSBAQAogCWlmIChzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTcw
MCAmJgogCSAgICBzYy0+YmdlX2FzaWNyZXYgIT0gQkdFX0FTSUNSRVZfQkNNNTkwNiAmJgogCSAg
ICBzYy0+YmdlX2NoaXBpZCAhPSBCR0VfQ0hJUElEX0JDTTU3MDVfQTAgJiYKLQkgICAgc2MtPmJn
ZV9jaGlwaWQgIT0gQkdFX0NISVBJRF9CQ001NzA1X0ExKQotCQlzYy0+YmdlX2ZsYWdzIHw9IEJH
RV9GTEF
Re: 8.0-BETA4 not responding to ARP for published entries
Hiroharu Tamaru wrote: > At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote: >> Please try patch at >> >>http://people.freebsd.org/~qingli/proxy-arp-patch.diff > > Thanks for taking care of it. > > I tried it, and now proxy arp works on the patched FreeBSD > 8.0-CURRENT-200902/amd64 as expected. Thanks! > > Could it be considered important enough to make it into > 8.0-RELEASE at this final stage? Hope it will, but if not, > please consider to point it out in the release note. The patch works for me too. I would like to second the hope that this makes it into the 8.0-RELEASE. Otherwise, the regression would seriously complicate our upgrade path. Thanks, -- Chris Cowart Network Technical Lead Network & Infrastructure Services, RSSP-IT UC Berkeley pgp1k6Fwz2JMf.pgp Description: PGP signature
RE: 8.0-BETA4 not responding to ARP for published entries
Hi, I have committed the code into -CURRENT and it's now merged into 8 Release branch. So RC1 should contain the fix. -- Qing > -Original Message- > From: Chris Cowart [mailto:ccow...@rescomp.berkeley.edu] > Sent: Tuesday, September 15, 2009 11:19 AM > To: Hiroharu Tamaru > Cc: Li, Qing; freebsd-net@freebsd.org; er...@berkeley.edu; freebsd- > curr...@freebsd.org > Subject: Re: 8.0-BETA4 not responding to ARP for published entries > > Hiroharu Tamaru wrote: > > At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote: > >> Please try patch at > >> > >>http://people.freebsd.org/~qingli/proxy-arp-patch.diff > > > > Thanks for taking care of it. > > > > I tried it, and now proxy arp works on the patched FreeBSD > > 8.0-CURRENT-200902/amd64 as expected. Thanks! > > > > Could it be considered important enough to make it into > > 8.0-RELEASE at this final stage? Hope it will, but if not, > > please consider to point it out in the release note. > > The patch works for me too. I would like to second the hope that this > makes it into the 8.0-RELEASE. Otherwise, the regression would > seriously > complicate our upgrade path. > > Thanks, > > -- > Chris Cowart > Network Technical Lead > Network & Infrastructure Services, RSSP-IT > UC Berkeley ___ 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/138850: [dummynet] dummynet doesn't work correctly on a bridge
Old Synopsis: dummynet doesn't work correctly on a bridge New Synopsis: [dummynet] dummynet doesn't work correctly on a bridge Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Sep 16 01:07:55 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138850 ___ 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"
Can lagg0 failback be prevented?
We're using the lag driver to provide automatic failover in case of a network outage. The default configuration looks like this: lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:a0:d1:e3:58:26 inet 192.168.17.40 netmask 0xf000 broadcast 192.168.31.255 inet 192.168.22.11 netmask 0xff00 broadcast 192.168.22.255 media: Ethernet autoselect status: active laggproto failover laggport: nfe1 flags=0<> laggport: nfe0 flags=5 If nfe0 was to fail, we get an (almost) automatic failover to nfe1: lagg0: flags=8843 metric 0 mtu 1500 options=19b ether 00:a0:d1:e3:58:26 inet 192.168.17.40 netmask 0xf000 broadcast 192.168.31.255 inet 192.168.22.11 netmask 0xff00 broadcast 192.168.22.255 media: Ethernet autoselect status: active laggproto failover laggport: nfe1 flags=4 laggport: nfe0 flags=1 The problem we're having is when nfe0 comes online again, a failback occurs making nfe0 active again. This causes a momentary network outage that we want to prevent. Is there a way to configure the lagg device to stay with the currently active interface, even if the MASTER interface comes back online? ___ 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: 8.0-BETA4 not responding to ARP for published entries
Hi, At Tue, 15 Sep 2009 17:05:46 -0700, Li, Qing wrote: > Hi, > > I have committed the code into -CURRENT and it's now merged into 8 > Release > branch. So RC1 should contain the fix. > > -- Qing Excellent! I'll try RC1 when it comes out. Thanks. Hiroharu Tamaru > > -Original Message- > > From: Chris Cowart [mailto:ccow...@rescomp.berkeley.edu] > > Sent: Tuesday, September 15, 2009 11:19 AM > > To: Hiroharu Tamaru > > Cc: Li, Qing; freebsd-net@freebsd.org; er...@berkeley.edu; freebsd- > > curr...@freebsd.org > > Subject: Re: 8.0-BETA4 not responding to ARP for published entries > > > > Hiroharu Tamaru wrote: > > > At Mon, 14 Sep 2009 21:50:47 -0700, Li, Qing wrote: > > >> Please try patch at > > >> > > >>http://people.freebsd.org/~qingli/proxy-arp-patch.diff > > > > > > Thanks for taking care of it. > > > > > > I tried it, and now proxy arp works on the patched FreeBSD > > > 8.0-CURRENT-200902/amd64 as expected. Thanks! > > > > > > Could it be considered important enough to make it into > > > 8.0-RELEASE at this final stage? Hope it will, but if not, > > > please consider to point it out in the release note. > > > > The patch works for me too. I would like to second the hope that this > > makes it into the 8.0-RELEASE. Otherwise, the regression would > > seriously > > complicate our upgrade path. > > > > Thanks, > > > > -- > > Chris Cowart > > Network Technical Lead > > Network & Infrastructure Services, RSSP-IT > > UC Berkeley ___ 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: 8.0-BETA4 not responding to ARP for published entries
Hi Qing, On Tue, Sep 15, 2009 at 05:05:46PM -0700, Li, Qing wrote: > I have committed the code into -CURRENT and it's now merged into 8 > Release branch. So RC1 should contain the fix. The patch worked for me as well. Thanks for fixing this so quickly and for getting it in for RC1. I'll test again when RC1 comes out. Erik ___ 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/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4
lini...@freebsd.org wrote: Old Synopsis: wpi(4) does not work very well under 8.0-BETA4 New Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Sep 12 00:53:04 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 I was just looking for possible sol'ns to a very similar problem that I have with my FreeBSD 7.2 laptop, a Dell D820 with a 3945abg card: wpi0: mem 0xecfff000-0xecff irq 17 at device 0.0 on pci12 I've had what looks like exactly this same problem for ages. Back into the FreeBSD 6.X days when the wpi driver was first added. Also, I think that PR 127102 is probably related. I've noticed problems when I'm in an area with lots of SSIDs and APs. I get this particularly bad when at work where there are 5 SSIDs present on each AP and at least 4+ APs always within range. At home where I see only 3 SSIDs on 3 APs, I can associate with my Linksys "router" just fine, but I see the slow throughput problem. This might be because I'm only associated at 1Mbps: wpi0: flags=8843 metric 0 mtu 1500 inet 172.16.23.65 netmask 0xff80 broadcast 172.16.23.127 media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps) status: associated ssid SSID channel 6 (2437 Mhz 11g) bssid 00:21:19:ae:00:00 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 7 scanvalid 60 protmode CTS roaming MANUAL Anyway, at work today, I did a bunch of testing. I attempted to associate first with a WPA2-enterprise SSID and then with an open SSID. In both cases, my laptop went into a spiral of doom: associate, spew errors, disassociate, repeat: Sep 15 15:21:13 yog kernel: wpi0: link state changed to UP Sep 15 15:21:13 yog kernel: wpi0: fatal firmware error Sep 15 15:21:13 yog kernel: wpi0: timeout resetting Rx ring Sep 15 15:21:13 yog kernel: wpi0: link state changed to DOWN Sep 15 15:21:17 yog kernel: wpi0: link state changed to UP Sep 15 15:21:17 yog kernel: wpi0: fatal firmware error Sep 15 15:21:17 yog kernel: wpi0: timeout resetting Rx ring Sep 15 15:21:17 yog kernel: wpi0: link state changed to DOWN ... A network engineer pulled the logs from the network gear (Trapeze ABGN APs) and saw that my laptop was repeatedly roaming between all of the available APs. I strongly suspect that there's a bug lurking in wpi firmware related to roaming. A possible pointer for this problem might be here: http://www.openbsd.org/plus41.html "Fix firmware fatal errors on re-associations in wpi(4)." I'm willing to provide more data and test any possible fixes for 7.2, but I'm lacking the time and experience necessary to track this one down myself. Paul -- Paul Dokas dokas at oitsec.umn.edu == Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla." ___ 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/138739: [wpi] wpi(4) does not work very well under?8.0-BETA4
The following reply was made to PR kern/138739; it has been noted by GNATS. From: Mark Linimon To: bug-follo...@freebsd.org Cc: Subject: Re: kern/138739: [wpi] wpi(4) does not work very well under?8.0-BETA4 Date: Tue, 15 Sep 2009 21:38:23 -0500 - Forwarded message from Paul Dokas - From: Paul Dokas Reply-To: Paul Dokas Organization: OIT Security & Assurance, University of Minnesota To: lini...@freebsd.org CC: freebsd-b...@freebsd.org, freebsd-net@FreeBSD.org Subject: Re: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4 I was just looking for possible sol'ns to a very similar problem that I have with my FreeBSD 7.2 laptop, a Dell D820 with a 3945abg card: wpi0: mem 0xecfff000-0xecff irq 17 at device 0.0 on pci12 I've had what looks like exactly this same problem for ages. Back into the FreeBSD 6.X days when the wpi driver was first added. Also, I think that PR 127102 is probably related. I've noticed problems when I'm in an area with lots of SSIDs and APs. I get this particularly bad when at work where there are 5 SSIDs present on each AP and at least 4+ APs always within range. At home where I see only 3 SSIDs on 3 APs, I can associate with my Linksys "router" just fine, but I see the slow throughput problem. This might be because I'm only associated at 1Mbps: wpi0: flags=8843 metric 0 mtu 1500 inet 172.16.23.65 netmask 0xff80 broadcast 172.16.23.127 media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps) status: associated ssid SSID channel 6 (2437 Mhz 11g) bssid 00:21:19:ae:00:00 authmode WPA privacy ON deftxkey UNDEF TKIP 2:128-bit TKIP 3:128-bit txpower 50 bmiss 7 scanvalid 60 protmode CTS roaming MANUAL Anyway, at work today, I did a bunch of testing. I attempted to associate first with a WPA2-enterprise SSID and then with an open SSID. In both cases, my laptop went into a spiral of doom: associate, spew errors, disassociate, repeat: Sep 15 15:21:13 yog kernel: wpi0: link state changed to UP Sep 15 15:21:13 yog kernel: wpi0: fatal firmware error Sep 15 15:21:13 yog kernel: wpi0: timeout resetting Rx ring Sep 15 15:21:13 yog kernel: wpi0: link state changed to DOWN Sep 15 15:21:17 yog kernel: wpi0: link state changed to UP Sep 15 15:21:17 yog kernel: wpi0: fatal firmware error Sep 15 15:21:17 yog kernel: wpi0: timeout resetting Rx ring Sep 15 15:21:17 yog kernel: wpi0: link state changed to DOWN ... A network engineer pulled the logs from the network gear (Trapeze ABGN APs) and saw that my laptop was repeatedly roaming between all of the available APs. I strongly suspect that there's a bug lurking in wpi firmware related to roaming. A possible pointer for this problem might be here: http://www.openbsd.org/plus41.html "Fix firmware fatal errors on re-associations in wpi(4)." I'm willing to provide more data and test any possible fixes for 7.2, but I'm lacking the time and experience necessary to track this one down myself. Paul -- Paul Dokas dokas at oitsec.umn.edu == Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla." - End forwarded message - ___ 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"
