[snip discussion]
Sorry to all for the noise, turns out that with a motherboard BIOS update
the card is recognized and initialized fine.
For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I
updated to the 1001 version.
Jonathan Stewart
Oleksandr Samoylyk wrote:
Alexander Sack wrote:
Oleksandr:
Are you using DEVICE_POLLING by chance? If so, have you tried turning
it off (ifconfig use -polling etc.)? Just curious.
Surely, no :)
# ifconfig em0
em0: flags=8843 metric 0 mtu 1500
options=19b
I'm just trying the same
Oleksandr Samoylyk wrote:
Oleksandr Samoylyk wrote:
Alexander Sack wrote:
Oleksandr:
Are you using DEVICE_POLLING by chance? If so, have you tried turning
it off (ifconfig use -polling etc.)? Just curious.
Surely, no :)
# ifconfig em0
em0: flags=8843 metric 0 mtu 1500
options=19
Stefan Lambrev wrote:
how many packets per second ?
I've seen this only during syn floods :)
Can you show the output of netstat -I em0 2 ?
netstat -I em0 -w 1:
input (em0) output
packets errs bytespackets errs bytes colls
13440 05
Moreover, here is a result of profiling:
granularity: each sample hit covers 16 byte(s) for 0.00% of 221.50 seconds
called/total parents
index %timeself descendents called+selfname index
called/total
On Sun, May 4, 2008 at 2:13 AM, <[EMAIL PROTECTED]> wrote:
> [snip discussion]
>
> Sorry to all for the noise, turns out that with a motherboard BIOS update
> the card is recognized and initialized fine.
>
> For the archives the board was an Asus P5B-VM DO and had the 0505 BIOS. I
> updated t
On Sat, 03 May 2008 18:28:55 +0300, in sentex.lists.freebsd.net you
wrote:
>Hi!
>
>I'm running a SMP FreeBSD box with mpd5 on it.
>
># uname -a
>FreeBSD xxx.x.xxx 7.0-STABLE FreeBSD 7.0-STABLE #0: Sat May 3
>12:40:02 EEST 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/
> amd64
>
>
Is there a list of patches that have been applied to -STABLE since
the -RELEASE ?
I can't seem to find a simple organized list of applied patches
(something similar to linux kernel changelog).
I want to know if anything has been fixed or udpated in the network area
to see if it warrants chang
Paul wrote:
Is there a list of patches that have been applied to -STABLE since
the -RELEASE ?
I can't seem to find a simple organized list of applied patches
(something similar to linux kernel changelog).
I want to know if anything has been fixed or udpated in the network
area to see if it w
[EMAIL PROTECTED] wrote:
A new version of the em drivers went into the tree Friday.
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3
dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.0
dev.em.0.%driver: em
dev.em.0.%location: slot=0 function=0
dev.em.0.%pnpinfo: ve
At 06:07 PM 5/4/2008, Oleksandr Samoylyk wrote:
I tried both:
- new drivers: 6.9.0
- rx_processing_limit: 100
Result the same :(
Also, post some of the stats. Do a sysctl -w dev.em.1.stats=1
to all of your em nics
em0: Excessive collisions = 0
em0: Sequence errors = 0
em0: Defer count = 0
On Sun, May 4, 2008 at 3:07 PM, Oleksandr Samoylyk
<[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>
> >
> > A new version of the em drivers went into the tree Friday.
> >
> >
> > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection Version - 6.7.3
> > >
> >
> > dev.em.0.%desc: Intel(R) PRO
Oh, I just had a thought, increase the RX processing limit,
that only allows you to process 100 packets in one pass.
First change it to 250 and see what it does, you might
also set it to -1 which will allow you to process til you
drain the ring, the risk is that you cause other problems
by doing t
Jack Vogel wrote:
You are running out of RX side resources, did you say this
was UDP? I'm guessing upping your mbuf pool at least, I
can't think of something in driver-wise that would help.
If you have this same load going into a different nic, or
different os (like say Linux) can it manage?
L
Jack Vogel wrote:
Oh, I just had a thought, increase the RX processing limit,
that only allows you to process 100 packets in one pass.
First change it to 250 and see what it does, you might
also set it to -1 which will allow you to process til you
drain the ring, the risk is that you cause other
Paul wrote:
What is your kernel HZ setting?
1000
in /boot/loader.conf try adding these two lines:
hw.em.rxd=1024
hw.em.txd=1024
I've already had:
# cat /boot/loader.conf
loader_logo="beastie"
autoboot_delay="3"
hw.em.rxd="4096"
hw.em.txd="4096"
and then do this in sysctl.conf:
net.inet.ip
Synopsis: [bge] bge link state issues [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:06:19 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=109733
__
Synopsis: [pppd] [panic] Multiple panics kernel ppp suspected [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:06:43 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query
Synopsis: pppd(8): PPPoE dead connections on 6.2 [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:07:34 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=10
Synopsis: Regression in ifconfig(8) + vlan(4) [regression]
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:10:38 UTC 2008
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query-pr.cgi?pr=10592
Old Synopsis: FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT 4-ort NIC
in PCI slot 3 of DL380 G4 (regression)
New Synopsis: [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/1000 MT
4-port NIC in PCI slot 3 of DL380 G4 [regression]
Responsible-Changed-From-To: freebsd-i386->freebsd-net
Synopsis: [nsswitch] nsswitch in 7.0 is f*cked up
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:40:11 UTC 2008
Responsible-Changed-Why:
Reclassify.
http://www.freebsd.org/cgi/query-pr.cgi?pr=122858
_
Synopsis: [ip6] [panic] _mtx_lock_sleep: recursed on non-recursive mutex
rtentry @ /usr/src/sys/net/route.c:1287
Responsible-Changed-From-To: freebsd-amd64->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Mon May 5 01:44:51 UTC 2008
Responsible-Changed-Why:
This is probably
Jack Vogel wrote:
Oh, I just had a thought, increase the RX processing limit,
that only allows you to process 100 packets in one pass.
First change it to 250 and see what it does, you might
also set it to -1 which will allow you to process til you
drain the ring, the risk is that you cause other
24 matches
Mail list logo
