Re: dummynet dropping too many packets

2009-10-18 Thread rihad
Peter Jeremy wrote: Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table sizes. It was

Re: dummynet dropping too many packets

2009-10-18 Thread rihad
rihad wrote: Peter Jeremy wrote: Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) problem with table

Re: dummynet dropping too many packets

2009-10-18 Thread rihad
rihad wrote: rihad wrote: Peter Jeremy wrote: Since the problem only appears to manifest when table(0) exceeds 2000 entries, have you considered splitting (at least temporarily) that table (and possibly table(2)) into two (eg table(0) and table(4))? This would help rule out an (unlikely) probl

Re: dummynet dropping too many packets

2009-10-18 Thread rihad
rihad wrote: I've just split both table(0) and table(2) in two, and the output drops were brought down to 20-80 up to 150 (in systat -ip). Now there are around 1700 in each of the tables 0 and 2, and exactly 1500 enries in each of the tables 10 and 20. 01060 pipe tablearg ip from any to table

Re: Intel WiFi 5100/5300

2009-10-18 Thread Bernhard Schmidt
On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > .. anyways, I'll post updates on sunday. Here we go. http://techwires.net/~bschmidt/patches/freebsd/iwn/ Testers/feedback welcome! Code is pretty stable although there are still a few open issues. Nothing major I should be able to

Re: Intel WiFi 5100/5300

2009-10-18 Thread Pawel Worach
On Oct 18, 2009, at 16:27, Bernhard Schmidt wrote: On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: .. anyways, I'll post updates on sunday. Here we go. http://techwires.net/~bschmidt/patches/freebsd/iwn/ Testers/feedback welcome! Code is pretty stable although there are still

Re: Intel WiFi 5100/5300

2009-10-18 Thread Lucius Windschuh
Hi Bernhard, I tried your module on my T400 with a PRO/Wireless 5300 and WITNESS, INVARIANTS enabled. If the RF kill switch is set to "WLAN disabled", this command sequence produces a panic: $ kldload iwnfw $ kldload if_iwn $ ifconfig wlan create wlandev iwn0 wlan0 $ ifconfig wlan0 up iwn0: iwn_in

Re: Intel WiFi 5100/5300

2009-10-18 Thread Bernhard Schmidt
On Sunday 18 October 2009 21:41:36 Lucius Windschuh wrote: > Hi Bernhard, > I tried your module on my T400 with a PRO/Wireless 5300 and WITNESS, > INVARIANTS enabled. > If the RF kill switch is set to "WLAN disabled", this command sequence [..] Thanks for reporting this, there seems to be an issu

Re: Intel WiFi 5100/5300

2009-10-18 Thread Vassilis Laganakos
Hello, > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: > > .. anyways, I'll post updates on sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable although there are still a few open issues. Noth

Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c]

2009-10-18 Thread Harsha
On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: > Harsha wrote: >> wrote: >>> >>> Looks like a NULL pointer dereference, so perhaps a more traditional bug >>> -- >>> could you convert ifindex_alloc_locked+0x71 to a line of code? You can do >>> this using kgdb on the kernel symbols file,

Re: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4

2009-10-18 Thread wen
Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: freebsd-net->wen Responsible-Changed-By: wen Responsible-Changed-When: Mon Oct 19 00:23:37 UTC 2009 Responsible-Changed-Why: I'll take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 ___

Re: kern/138739: [wpi] wpi(4) does not work very well under 8.0-BETA4

2009-10-18 Thread wen
Synopsis: [wpi] wpi(4) does not work very well under 8.0-BETA4 Responsible-Changed-From-To: wen->freebsd-net Responsible-Changed-By: wen Responsible-Changed-When: Mon Oct 19 00:53:24 UTC 2009 Responsible-Changed-Why: Sorry I mistake it. http://www.freebsd.org/cgi/query-pr.cgi?pr=138739 _

Re: Intel WiFi 5100/5300

2009-10-18 Thread Brandon Gooch
On Sun, Oct 18, 2009 at 2:27 PM, Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on  sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty stable altho

Re: Intel WiFi 5100/5300

2009-10-18 Thread Glen Barber
Howdy! On Sun, Oct 18, 2009 at 10:27 AM, Bernhard Schmidt wrote: > On Thursday 15 October 2009 08:15:57 Bernhard Schmidt wrote: >> .. anyways, I'll post updates on  sunday. > > Here we go. > > http://techwires.net/~bschmidt/patches/freebsd/iwn/ > > Testers/feedback welcome! > > Code is pretty sta

Re: Intel WiFi 5100/5300

2009-10-18 Thread Glen Barber
On Sun, Oct 18, 2009 at 9:14 PM, Glen Barber wrote: > Howdy! > > > Any thoughts on the errors I get with buildkernel (attached)?  The > kernel config has no other changes compared to GENERIC than enabling > KDB and DDB. > > Thanks and regards, > This is 8-STABLE, r198209 by the way. Sorry for not

Re: Page fault in IFNET_WLOCK_ASSERT [if.c and pccbb.c]

2009-10-18 Thread Julian Elischer
Harsha wrote: On Sat, Oct 17, 2009 at 11:42 PM, Julian Elischer wrote: Harsha wrote: wrote: Looks like a NULL pointer dereference, so perhaps a more traditional bug -- could you convert ifindex_alloc_locked+0x71 to a line of code? You can do this using kgdb on the kernel symbols file, perhap

Re: Wacky DHCP values that work in windows but not in FreeBSD

2009-10-18 Thread Doug Barton
I'm adding Brooks to the cc list since he is mr. dhcp lately. :) David Horn wrote: > On Tue, Oct 13, 2009 at 1:31 AM, Doug Barton wrote: >> David Horn wrote: >>> Without seeing the actual tcpdump of the dhcp packets, I would guess >>> that this is the Classless Static Route option in DHCPv4 (opti