Re: igb watchdog timeouts
Thanks for all the feedback on polling, Jack and others. Very helpful.
We are working to merge the latest RELENG_8 em/igb driver into our
custom build that's based on RELENG_8_1. I've been able to create a
patch using the following command:
cvs di -N -up -jRELENG_8_1 -jRELENG_8 sys/dev/e1000 sys/dev/ixgb
sys/dev/ixgbe sys/conf/files > /tmp/e1000.diff
... by hand trimming sys/conf/files down to only the relevant bits. It
compiled and seems to be functioning, but I wouldn't mind a sanity
check on my methodology. In particular:
* Some of the patches overlapped with sys/dev/ixgb, igbe... so I
included them. Should I have?
* Is there anything else I should have included?
Thanks very much,
Charles
On 1/13/11 4:49 PM, Jack Vogel wrote:
Polling has seemed to me to be a way around other problems, problems
that these days
no longer exist. I remember back in the FreeBSD 6 days having
interrupt problems which
of course also led to watchdogs. Polling got rid of that. But now
there are dedicated
MULTIPLE interrupts by using MSIX, so that reason for polling is gone.
Of course there can still be advantages, reducing interrupts and hence
context switches,
which is why the Linux approach does what it does.
I have not spent time with that issue, its good to know that there
could be problems
lurking with it. But if you can simply go with MSIX I would do that
for now.
Jack
On Thu, Jan 13, 2011 at 1:42 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
So we went back to basics (stock 8.1-RELEASE) and found no
issue!We then added in our kernel mods one by one and
ultimately discovered that device-polling is the culprit (the
kernel config was simply GENERIC + PAE + polling).
Immediately upon running "ifconfig igb0 polling" the symptoms appear.
This is very good news overall, in that we can certainly disable
polling for igb. This begs the question, though, as to whether
polling is recommended these days at all for em/igb NICs... or
even in general. From other conversations we've seen there seems
to be some general debate about this. In testing we've done in
the past (circa 7.0) there certainly seemed to be benefit to using
this feature. What are your thoughts about this?
For our product releases we'd like stay with RELENG_8_1. Would
you recommend the driver in 8.2 as being preferable?
In case it's of interest:
igb0@pci0:1:0:0:class=0x02 card=0x34de8086 chip=0x10a78086
rev=0x02
hdr=0x00
vendor = 'Intel Corporation'device = '82575EB Gigabit
Network Connection'
class = network
subclass = ethernet
Thanks,
Charles
On 1/13/11 1:27 PM, Jack Vogel wrote:
The 8.2 latest does have the latest igb, so using that should be
indicative...
Jack
On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Ok... I got my wires crossed: our first time testing 8.1 on
this particular platform was with a kernel that had ichwd
enabled (a new thing for us) and so when igb started
complaining about "watchdog" we thought it was related.
We've tested again and clearly the real story is that we're
simply seeing igb issues, symptoms similar to those described.
Does 8.2-RC1 have sufficiently "latest" code, or should I be
looking to load up something else? (8-stable, maybe?)
Thanks,
Charles
On 1/13/11 12:07 AM, Jack Vogel wrote:
The problem that Robin saw was due to having MSIX interrupts
disabled on the system, I doubt that
is going to be the "issue" for others.
Get the latest version of the igb code and see if that helps
you as a first step.
Jack
On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
I'd like to report that we're running into this issue
also, in our case on systems that are based on the Intel
S5520UR Server Board, running 8.1-RELEASE. If the ichwd
driver is loaded we see the same messages, and network
communication via the igb nics is non-functional.
Have you had any luck?
Thanks,
Charles
Charles Owens
Great Bay Software, Inc.
On 1/3/11 4:02 PM, Robin Sommer wrote:
Hello all,
quite a while ago I asked about the problem below.
Unfortunately, I
haven't found a solution yet and I'm actually still
seeing these
timeouts after just upgrading to 8.2-RC1. Any
further ideas on w
Re: igb watchdog timeouts
So we went back to basics (stock 8.1-RELEASE) and found no issue!We
then added in our kernel mods one by one and ultimately discovered that
device-polling is the culprit (the kernel config was simply GENERIC +
PAE + polling).
Immediately upon running "ifconfig igb0 polling" the symptoms appear.
This is very good news overall, in that we can certainly disable polling
for igb. This begs the question, though, as to whether polling is
recommended these days at all for em/igb NICs... or even in general.
From other conversations we've seen there seems to be some general
debate about this. In testing we've done in the past (circa 7.0) there
certainly seemed to be benefit to using this feature. What are your
thoughts about this?
For our product releases we'd like stay with RELENG_8_1. Would you
recommend the driver in 8.2 as being preferable?
In case it's of interest:
igb0@pci0:1:0:0:class=0x02 card=0x34de8086 chip=0x10a78086 rev=0x02
hdr=0x00
vendor = 'Intel Corporation'device = '82575EB Gigabit Network
Connection'
class = network
subclass = ethernet
Thanks,
Charles
On 1/13/11 1:27 PM, Jack Vogel wrote:
The 8.2 latest does have the latest igb, so using that should be
indicative...
Jack
On Thu, Jan 13, 2011 at 7:56 AM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Ok... I got my wires crossed: our first time testing 8.1 on this
particular platform was with a kernel that had ichwd enabled (a
new thing for us) and so when igb started complaining about
"watchdog" we thought it was related.
We've tested again and clearly the real story is that we're simply
seeing igb issues, symptoms similar to those described.
Does 8.2-RC1 have sufficiently "latest" code, or should I be
looking to load up something else? (8-stable, maybe?)
Thanks,
Charles
On 1/13/11 12:07 AM, Jack Vogel wrote:
The problem that Robin saw was due to having MSIX interrupts
disabled on the system, I doubt that
is going to be the "issue" for others.
Get the latest version of the igb code and see if that helps you
as a first step.
Jack
On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
I'd like to report that we're running into this issue also,
in our case on systems that are based on the Intel S5520UR
Server Board, running 8.1-RELEASE. If the ichwd driver is
loaded we see the same messages, and network communication
via the igb nics is non-functional.
Have you had any luck?
Thanks,
Charles
Charles Owens
Great Bay Software, Inc.
On 1/3/11 4:02 PM, Robin Sommer wrote:
Hello all,
quite a while ago I asked about the problem below.
Unfortunately, I
haven't found a solution yet and I'm actually still
seeing these
timeouts after just upgrading to 8.2-RC1. Any further
ideas on what
could be triggering them, or how I could track down the
cause?
Thanks,
Robin
On Thu, Jul 29, 2010 at 14:56 -0700, I wrote:
Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing
lots of messages
like those below on all my SuperMicro SBI-7425C-T3
blades. There's
almost no traffic on those interfaces.
Any idea?
Thanks,
Robin
Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout
-- resetting
Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh =
256, hw tdt = 266
Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail
= 1013,Next TX to Clean = 255
Jul 29 13:01:18 blade0 kernel: igb1: link state
changed to DOWN
Jul 29 13:01:18 blade0 kernel: igb1: link state
changed to UP
Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout
-- resetting
Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh =
0, hw tdt = 10
Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail
= 1014,Next TX to Clean = 0
Jul 29 13:01:29 blade0 kernel: igb1: link state
changed to DOWN
Jul 29 13:01:29 blade0 kernel: igb1: link state
changed to UP
Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout
-- resetting
Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh =
32, hw tdt = 33
Jul 29 13:01:46 blade0 kernel:
Re: igb watchdog timeouts
Ok... I got my wires crossed: our first time testing 8.1 on this
particular platform was with a kernel that had ichwd enabled (a new
thing for us) and so when igb started complaining about "watchdog" we
thought it was related.
We've tested again and clearly the real story is that we're simply
seeing igb issues, symptoms similar to those described.
Does 8.2-RC1 have sufficiently "latest" code, or should I be looking to
load up something else? (8-stable, maybe?)
Thanks,
Charles
On 1/13/11 12:07 AM, Jack Vogel wrote:
The problem that Robin saw was due to having MSIX interrupts disabled
on the system, I doubt that
is going to be the "issue" for others.
Get the latest version of the igb code and see if that helps you as a
first step.
Jack
On Wed, Jan 12, 2011 at 6:43 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
I'd like to report that we're running into this issue also, in our
case on systems that are based on the Intel S5520UR Server Board,
running 8.1-RELEASE. If the ichwd driver is loaded we see the
same messages, and network communication via the igb nics is
non-functional.
Have you had any luck?
Thanks,
Charles
Charles Owens
Great Bay Software, Inc.
On 1/3/11 4:02 PM, Robin Sommer wrote:
Hello all,
quite a while ago I asked about the problem below.
Unfortunately, I
haven't found a solution yet and I'm actually still seeing these
timeouts after just upgrading to 8.2-RC1. Any further ideas on
what
could be triggering them, or how I could track down the cause?
Thanks,
Robin
On Thu, Jul 29, 2010 at 14:56 -0700, I wrote:
Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots
of messages
like those below on all my SuperMicro SBI-7425C-T3 blades.
There's
almost no traffic on those interfaces.
Any idea?
Thanks,
Robin
Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout --
resetting
Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256,
hw tdt = 266
Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail =
1013,Next TX to Clean = 255
Jul 29 13:01:18 blade0 kernel: igb1: link state changed to
DOWN
Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP
Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout --
resetting
Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw
tdt = 10
Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail =
1014,Next TX to Clean = 0
Jul 29 13:01:29 blade0 kernel: igb1: link state changed to
DOWN
Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP
Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout --
resetting
Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw
tdt = 33
Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail =
1022,Next TX to Clean = 31
Jul 29 13:01:46 blade0 kernel: igb1: link state changed to
DOWN
Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP
Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout --
resetting
Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw
tdt = 10
Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail =
1014,Next TX to Clean = 0
Jul 29 13:01:57 blade0 kernel: igb1: link state changed to
DOWN
Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP
Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout --
resetting
grep igb /var/run/dmesg.boot
igb0: port 0x2000-0x201f mem
0xfc94-0xfc95,0xfc92-0xfc93,0xfc90-0xfc903fff
irq 16 at device 0.0 on pci4
igb0: [FILTER]
igb0: Ethernet address: 00:30:48:9e:22:00
igb1: port 0x2020-0x203f mem
0xfc98-0xfc99,0xfc96-0xfc97,0xfc904000-0xfc907fff
irq 17 at device 0.1 on pci4
igb1: [FILTER]
igb1: Ethernet address: 00:30:48:9e:22:01
pciconf -lv
[...]
igb0@pci0:4:0:0: class=0x02 card=0x10a915d9
chip=0x10a98086 rev=0x02 hdr=0x00
vendor = 'Intel Corporation'
device = '82575EB Gigabit Backplane Connection'
class = network
subclass = ethernet
igb1@pci0:4:0:1:class=0x02 card=0x10a915d9
chip=0x10a98086 rev=0x02
Re: igb watchdog timeouts
I'd like to report that we're running into this issue also, in our case on systems that are based on the Intel S5520UR Server Board, running 8.1-RELEASE. If the ichwd driver is loaded we see the same messages, and network communication via the igb nics is non-functional. Have you had any luck? Thanks, Charles Charles Owens Great Bay Software, Inc. On 1/3/11 4:02 PM, Robin Sommer wrote: Hello all, quite a while ago I asked about the problem below. Unfortunately, I haven't found a solution yet and I'm actually still seeing these timeouts after just upgrading to 8.2-RC1. Any further ideas on what could be triggering them, or how I could track down the cause? Thanks, Robin On Thu, Jul 29, 2010 at 14:56 -0700, I wrote: Since upgrading from 8.0 to 8.1-RELEASE, I'm seeing lots of messages like those below on all my SuperMicro SBI-7425C-T3 blades. There's almost no traffic on those interfaces. Any idea? Thanks, Robin Jul 29 13:01:18 blade0 kernel: igb1: Watchdog timeout -- resetting Jul 29 13:01:18 blade0 kernel: igb1: Queue(0) tdh = 256, hw tdt = 266 Jul 29 13:01:18 blade0 kernel: igb1: TX(0) desc avail = 1013,Next TX to Clean = 255 Jul 29 13:01:18 blade0 kernel: igb1: link state changed to DOWN Jul 29 13:01:18 blade0 kernel: igb1: link state changed to UP Jul 29 13:01:29 blade0 kernel: igb1: Watchdog timeout -- resetting Jul 29 13:01:29 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 Jul 29 13:01:29 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to Clean = 0 Jul 29 13:01:29 blade0 kernel: igb1: link state changed to DOWN Jul 29 13:01:29 blade0 kernel: igb1: link state changed to UP Jul 29 13:01:46 blade0 kernel: igb1: Watchdog timeout -- resetting Jul 29 13:01:46 blade0 kernel: igb1: Queue(0) tdh = 32, hw tdt = 33 Jul 29 13:01:46 blade0 kernel: igb1: TX(0) desc avail = 1022,Next TX to Clean = 31 Jul 29 13:01:46 blade0 kernel: igb1: link state changed to DOWN Jul 29 13:01:46 blade0 kernel: igb1: link state changed to UP Jul 29 13:01:57 blade0 kernel: igb1: Watchdog timeout -- resetting Jul 29 13:01:57 blade0 kernel: igb1: Queue(0) tdh = 0, hw tdt = 10 Jul 29 13:01:57 blade0 kernel: igb1: TX(0) desc avail = 1014,Next TX to Clean = 0 Jul 29 13:01:57 blade0 kernel: igb1: link state changed to DOWN Jul 29 13:01:58 blade0 kernel: igb1: link state changed to UP Jul 29 13:02:13 blade0 kernel: igb1: Watchdog timeout -- resetting grep igb /var/run/dmesg.boot igb0: port 0x2000-0x201f mem 0xfc94-0xfc95,0xfc92-0xfc93,0xfc90-0xfc903fff irq 16 at device 0.0 on pci4 igb0: [FILTER] igb0: Ethernet address: 00:30:48:9e:22:00 igb1: port 0x2020-0x203f mem 0xfc98-0xfc99,0xfc96-0xfc97,0xfc904000-0xfc907fff irq 17 at device 0.1 on pci4 igb1: [FILTER] igb1: Ethernet address: 00:30:48:9e:22:01 pciconf -lv [...] i...@pci0:4:0:0: class=0x02 card=0x10a915d9 chip=0x10a98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Backplane Connection' class = network subclass = ethernet i...@pci0:4:0:1:class=0x02 card=0x10a915d9 chip=0x10a98086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82575EB Gigabit Backplane Connection' class = network subclass = ethernet [...] ___ 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: em(4): 4-port Intel Pro/1000 PF card not detected
The appliance is in a 1U form-factor with just a single riser-based slot
(PCIe 2.0).
Thanks for your help with this,
Charles
On 11/15/10 6:14 PM, Jack Vogel wrote:
The way you talked about this at first made me think this was
something new, but its actually
fairly old, its just a quad port 82571, id is 0x10A5, support has been
in the drivers for ages :)
The issue is the hardware not the OS or driver, even if the
motherboard is PCIE 2.0, does it
not have slots that are 1 ?
For server adapters you might consider going 82576 or 82580.
Jack
On Mon, Nov 15, 2010 at 2:38 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Well, I believe we have an answer:
http://www.intel.com/support/network/adapter/pro100/sb/CS-030873.htm
The motherboard definitely is PCIe 2.0 . The page suggests these
cards for use with a PCIe2.0 system:
# Intel® PRO/1000 PT Quad Port LP Server Adapter (P/N EXPI9404PTL)
# Intel® Gigabit ET Quad Port Server Adapter (P/N E1G44ET)
# Intel® Gigabit ET2 Quad Port Server Adapter (P/N E1G44ET2)
Notably there's not a PF option shown, so we're going to have to
think about that. But in any case, do you think these models
will function with 8.0? 8.0 plus a patch? or is 8.1 the
only option?
Thanks,
Charles
On 11/15/10 4:58 PM, Jack Vogel wrote:
Well, if the system doesnt show the hardware in a PCI scan there
isn't much my driver can do :)
The last line in your log says 'eth0', what's that about?
You could try booting 8.1 64 bit, you can also send me all the
details about the board, just to
make sure I can get the exact one and then I'll try it here. This
is quad port fiber, right? I was
thinking this was PCI ID 0x1527, 82580 adapter. The support is
in HEAD now.
Regards,
Jack
On Mon, Nov 15, 2010 at 1:45 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Jack, I'm afraid that with the card _not_ installed we get
identical pciconf output. We're running 32 bit simply
because that's where we got rolling with our product, and
have not yet made the call to invest in the effort required
to make the jump to 64. Do you think that our being at 32
bit could be a factor here?
So far the same card model has been tested on several of
these server appliances, so I doubt it's a bad-slot situation.
In case it's helpful, I've attached a boot log. Anything
else that I can provide that might help?
Thank you,
Charles
On 11/15/10 3:23 PM, Jack Vogel wrote:
UH, did you do that with the adapter in the system?? I do
not see the ID I
expected
to see. Some reason you're running 32 bit??
Can you run the pciconf with the adapter in and out,
compare and tell me
what its
ID is? All the unidentified devices I see are in the
0x3XXX range and those
are not
network devices.
Maybe its a bad slot?
Jack
On Mon, Nov 15, 2010 at 11:59 AM, Charles
Owensmailto:cow...@greatbaysoftware.com>
wrote:
Great... thanks! Please see attached. BTW, the
system is running
8.0-RELEASE-p2 i386 (PAE).
Charles
On 11/13/10 2:24 AM, Jack Vogel wrote:
pciconf -l please, I'll betcha these are the new quad
ports that are in my
next igb driver
update, it would have gone in already but I've been
fighting a bug in the
header split
code.
Show me what the output looks like, and I'll get ya
fixed up, dont worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens<
cow...@greatbaysoftware.com
<mailto:cow...@greatbaysoftware.com>> wrote:
Hello,
We're trying to work with newly purcharsed Intel
EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they
do not seem to be detected
(no ports showing with 'ifconfig -l'). We're
having no problems with the
2-port version of the same card -- is there a
known issue with the 4-port
version?
We've tried three different cards of this model,
all with same result.
Thanks in advance
Re: em(4): 4-port Intel Pro/1000 PF card not detected
Well, I believe we have an answer:
http://www.intel.com/support/network/adapter/pro100/sb/CS-030873.htm
The motherboard definitely is PCIe 2.0 . The page suggests these cards
for use with a PCIe2.0 system:
# Intel® PRO/1000 PT Quad Port LP Server Adapter (P/N EXPI9404PTL)
# Intel® Gigabit ET Quad Port Server Adapter (P/N E1G44ET)
# Intel® Gigabit ET2 Quad Port Server Adapter (P/N E1G44ET2)
Notably there's not a PF option shown, so we're going to have to think
about that. But in any case, do you think these models will function
with 8.0? 8.0 plus a patch? or is 8.1 the only option?
Thanks,
Charles
On 11/15/10 4:58 PM, Jack Vogel wrote:
Well, if the system doesnt show the hardware in a PCI scan there isn't
much my driver can do :)
The last line in your log says 'eth0', what's that about?
You could try booting 8.1 64 bit, you can also send me all the details
about the board, just to
make sure I can get the exact one and then I'll try it here. This is
quad port fiber, right? I was
thinking this was PCI ID 0x1527, 82580 adapter. The support is in
HEAD now.
Regards,
Jack
On Mon, Nov 15, 2010 at 1:45 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Jack, I'm afraid that with the card _not_ installed we get
identical pciconf output. We're running 32 bit simply because
that's where we got rolling with our product, and have not yet
made the call to invest in the effort required to make the jump to
64. Do you think that our being at 32 bit could be a factor here?
So far the same card model has been tested on several of these
server appliances, so I doubt it's a bad-slot situation.
In case it's helpful, I've attached a boot log. Anything else
that I can provide that might help?
Thank you,
Charles
On 11/15/10 3:23 PM, Jack Vogel wrote:
UH, did you do that with the adapter in the system?? I do not
see the ID I
expected
to see. Some reason you're running 32 bit??
Can you run the pciconf with the adapter in and out, compare
and tell me
what its
ID is? All the unidentified devices I see are in the 0x3XXX
range and those
are not
network devices.
Maybe its a bad slot?
Jack
On Mon, Nov 15, 2010 at 11:59 AM, Charles
Owensmailto:cow...@greatbaysoftware.com>
wrote:
Great... thanks! Please see attached. BTW, the system
is running
8.0-RELEASE-p2 i386 (PAE).
Charles
On 11/13/10 2:24 AM, Jack Vogel wrote:
pciconf -l please, I'll betcha these are the new quad
ports that are in my
next igb driver
update, it would have gone in already but I've been
fighting a bug in the
header split
code.
Show me what the output looks like, and I'll get ya fixed
up, dont worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens<
cow...@greatbaysoftware.com
<mailto:cow...@greatbaysoftware.com>> wrote:
Hello,
We're trying to work with newly purcharsed Intel
EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they do not
seem to be detected
(no ports showing with 'ifconfig -l'). We're having
no problems with the
2-port version of the same card -- is there a known
issue with the 4-port
version?
We've tried three different cards of this model, all
with same result.
Thanks in advance for any help.
Charles
--
Charles Owens
Great Bay Software, Inc.
___
freebsd-net@freebsd.org
<mailto: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
<mailto:freebsd-net-unsubscr...@freebsd.org>"
___
freebsd-net@freebsd.org <mailto: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
<mailto:freebsd-net-unsubscr...@freebsd.org>"
___
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: em(4): 4-port Intel Pro/1000 PF card not detected
The eth0 line in log: we rename our NICs to be ethX (via "iconfig em0
name eth0"). That line is just one of the copper NICs coming up.
Info on the card -- model number (EXPi9404PFBLK), chipset (dual 82571 GB
chips). Here's the Intel page:
http://www.intel.com/Products/Server/Adapters/PRO1000PF-QuadPort/PRO1000PF-QuadPort-overview.htm
Is this what you were expecting?We can also work on booting into 8.1
64bit.
Thanks much,
Charles
On 11/15/10 4:58 PM, Jack Vogel wrote:
Well, if the system doesnt show the hardware in a PCI scan there isn't
much my driver can do :)
The last line in your log says 'eth0', what's that about?
You could try booting 8.1 64 bit, you can also send me all the details
about the board, just to
make sure I can get the exact one and then I'll try it here. This is
quad port fiber, right? I was
thinking this was PCI ID 0x1527, 82580 adapter. The support is in
HEAD now.
Regards,
Jack
On Mon, Nov 15, 2010 at 1:45 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Jack, I'm afraid that with the card _not_ installed we get
identical pciconf output. We're running 32 bit simply because
that's where we got rolling with our product, and have not yet
made the call to invest in the effort required to make the jump to
64. Do you think that our being at 32 bit could be a factor here?
So far the same card model has been tested on several of these
server appliances, so I doubt it's a bad-slot situation.
In case it's helpful, I've attached a boot log. Anything else
that I can provide that might help?
Thank you,
Charles
On 11/15/10 3:23 PM, Jack Vogel wrote:
UH, did you do that with the adapter in the system?? I do not
see the ID I
expected
to see. Some reason you're running 32 bit??
Can you run the pciconf with the adapter in and out, compare
and tell me
what its
ID is? All the unidentified devices I see are in the 0x3XXX
range and those
are not
network devices.
Maybe its a bad slot?
Jack
On Mon, Nov 15, 2010 at 11:59 AM, Charles
Owensmailto:cow...@greatbaysoftware.com>
wrote:
Great... thanks! Please see attached. BTW, the system
is running
8.0-RELEASE-p2 i386 (PAE).
Charles
On 11/13/10 2:24 AM, Jack Vogel wrote:
pciconf -l please, I'll betcha these are the new quad
ports that are in my
next igb driver
update, it would have gone in already but I've been
fighting a bug in the
header split
code.
Show me what the output looks like, and I'll get ya fixed
up, dont worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens<
cow...@greatbaysoftware.com
<mailto:cow...@greatbaysoftware.com>> wrote:
Hello,
We're trying to work with newly purcharsed Intel
EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they do not
seem to be detected
(no ports showing with 'ifconfig -l'). We're having
no problems with the
2-port version of the same card -- is there a known
issue with the 4-port
version?
We've tried three different cards of this model, all
with same result.
Thanks in advance for any help.
Charles
--
Charles Owens
Great Bay Software, Inc.
___
freebsd-net@freebsd.org
<mailto: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
<mailto:freebsd-net-unsubscr...@freebsd.org>"
___
freebsd-net@freebsd.org <mailto: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
<mailto:freebsd-net-unsubscr...@freebsd.org>"
___
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: em(4): 4-port Intel Pro/1000 PF card not detected
Jack, I'm afraid that with the card _not_ installed we get identical
pciconf output. We're running 32 bit simply because that's where we got
rolling with our product, and have not yet made the call to invest in
the effort required to make the jump to 64. Do you think that our being
at 32 bit could be a factor here?
So far the same card model has been tested on several of these server
appliances, so I doubt it's a bad-slot situation.
In case it's helpful, I've attached a boot log. Anything else that I
can provide that might help?
Thank you,
Charles
On 11/15/10 3:23 PM, Jack Vogel wrote:
UH, did you do that with the adapter in the system?? I do not see the ID I
expected
to see. Some reason you're running 32 bit??
Can you run the pciconf with the adapter in and out, compare and tell me
what its
ID is? All the unidentified devices I see are in the 0x3XXX range and those
are not
network devices.
Maybe its a bad slot?
Jack
On Mon, Nov 15, 2010 at 11:59 AM, Charles Owens
wrote:
Great... thanks! Please see attached. BTW, the system is running
8.0-RELEASE-p2 i386 (PAE).
Charles
On 11/13/10 2:24 AM, Jack Vogel wrote:
pciconf -l please, I'll betcha these are the new quad ports that are in my
next igb driver
update, it would have gone in already but I've been fighting a bug in the
header split
code.
Show me what the output looks like, and I'll get ya fixed up, dont worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens<
cow...@greatbaysoftware.com> wrote:
Hello,
We're trying to work with newly purcharsed Intel EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they do not seem to be detected
(no ports showing with 'ifconfig -l'). We're having no problems with the
2-port version of the same card -- is there a known issue with the 4-port
version?
We've tried three different cards of this model, all with same result.
Thanks in advance for any help.
Charles
--
Charles Owens
Great Bay Software, Inc.
___
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"
___
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"
Copyright (c) 1992-2009 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.0-RELEASE-p2 #8: Mon Apr 19 16:31:20 UTC 2010
se...@newcastle.greatbaysoftware.com:/usr/obj/usr/src/sys/BEACON
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.27-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5
Features=0xbfebfbff
Features2=0x9ce3bd
AMD Features=0x2810
AMD Features2=0x1
TSC: P-state invariant
real memory = 6442450944 (6144 MB)
avail memory = 6202404864 (5915 MB)
ACPI APIC Table:
FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs
FreeBSD/SMP: 2 package(s) x 4 core(s) x 2 SMT threads
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
cpu2 (AP): APIC ID: 2
cpu3 (AP): APIC ID: 3
cpu4 (AP): APIC ID: 4
cpu5 (AP): APIC ID: 5
cpu6 (AP): APIC ID: 6
cpu7 (AP): APIC ID: 7
cpu8 (AP): APIC ID: 16
cpu9 (AP): APIC ID: 17
cpu10 (AP): APIC ID: 18
cpu11 (AP): APIC ID: 19
cpu12 (AP): APIC ID: 20
cpu13 (AP): APIC ID: 21
cpu14 (AP): APIC ID: 22
cpu15 (AP): APIC ID: 23
ioapic0 irqs 0-23 on motherboard
ioapic1 irqs 24-47 on motherboard
lapic0: Forcing LINT1 to edge trigger
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
ispfw: registered firmware
kbd0 at kbdmux0
acpi0: on motherboard
acpi0: [ITHREAD]
acpi0: Power Button (fixed)
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0
acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0
Timecounter "HPET" frequency 14318180 Hz quality 900
pcib0: port 0xcf8-0xcff on acpi0
pci0: on pcib0
pcib1: irq 28 at device 1.0 on pci0
pci1: on pcib1
igb0: port 0x2020-0x203f
mem 0xb1a2-0xb1a3,0xb1a44000-0xb1a47fff irq 40 at device 0.0 on pci1
igb0: Using MSIX interrupts with 3 vectors
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: [ITHREAD]
igb0: Ethernet address: 00:15:17:b4:
Re: em(4): 4-port Intel Pro/1000 PF card not detected
Great... thanks! Please see attached. BTW, the system is running
8.0-RELEASE-p2 i386 (PAE).
Charles
On 11/13/10 2:24 AM, Jack Vogel wrote:
pciconf -l please, I'll betcha these are the new quad ports that are
in my next igb driver
update, it would have gone in already but I've been fighting a bug in
the header split
code.
Show me what the output looks like, and I'll get ya fixed up, dont
worry :)
Jack
On Fri, Nov 12, 2010 at 2:08 PM, Charles Owens
mailto:cow...@greatbaysoftware.com>> wrote:
Hello,
We're trying to work with newly purcharsed Intel EXPi9404PF NICs
("Intel PRO/1000 PF Quad Port Server Adapter") but they do not
seem to be detected (no ports showing with 'ifconfig -l'). We're
having no problems with the 2-port version of the same card -- is
there a known issue with the 4-port version?
We've tried three different cards of this model, all with same
result. Thanks in advance for any help.
Charles
--
Charles Owens
Great Bay Software, Inc.
___
freebsd-net@freebsd.org <mailto: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
<mailto:freebsd-net-unsubscr...@freebsd.org>"
hos...@pci0:0:0:0: class=0x06 card=0x34de8086 chip=0x34068086 rev=0x13
hdr=0x00
pc...@pci0:0:1:0: class=0x060400 card=0x34de8086 chip=0x34088086 rev=0x13
hdr=0x01
pc...@pci0:0:3:0: class=0x060400 card=0x34de8086 chip=0x340a8086 rev=0x13
hdr=0x01
pc...@pci0:0:7:0: class=0x060400 card=0x34de8086 chip=0x340e8086 rev=0x13
hdr=0x01
pc...@pci0:0:9:0: class=0x060400 card=0x34de8086 chip=0x34108086 rev=0x13
hdr=0x01
pc...@pci0:0:10:0: class=0x060400 card=0x34de8086 chip=0x34118086 rev=0x13
hdr=0x01
no...@pci0:0:16:0: class=0x08 card=0x00de0086 chip=0x34258086 rev=0x13
hdr=0x00
no...@pci0:0:16:1: class=0x08 card=0x00de0086 chip=0x34268086 rev=0x13
hdr=0x00
no...@pci0:0:17:0: class=0x08 card=0x00de0086 chip=0x34278086 rev=0x13
hdr=0x00
no...@pci0:0:17:1: class=0x08 card=0x00de0086 chip=0x34288086 rev=0x13
hdr=0x00
ioap...@pci0:0:19:0:class=0x080020 card=0x00de0086 chip=0x342d8086 rev=0x13
hdr=0x00
no...@pci0:0:20:0: class=0x08 card=0x00de0086 chip=0x342e8086 rev=0x13
hdr=0x00
no...@pci0:0:20:1: class=0x08 card=0x00de0086 chip=0x34228086 rev=0x13
hdr=0x00
no...@pci0:0:20:2: class=0x08 card=0x00de0086 chip=0x34238086 rev=0x13
hdr=0x00
no...@pci0:0:20:3: class=0x08 card=0x00de0086 chip=0x34388086 rev=0x13
hdr=0x00
ioap...@pci0:0:21:0:class=0x080020 card=0x00de0086 chip=0x342f8086 rev=0x13
hdr=0x00
no...@pci0:0:22:0: class=0x088000 card=0x34de8086 chip=0x34308086 rev=0x13
hdr=0x00
no...@pci0:0:22:1: class=0x088000 card=0x34de8086 chip=0x34318086 rev=0x13
hdr=0x00
non...@pci0:0:22:2: class=0x088000 card=0x34de8086 chip=0x34328086 rev=0x13
hdr=0x00
non...@pci0:0:22:3: class=0x088000 card=0x34de8086 chip=0x34338086 rev=0x13
hdr=0x00
non...@pci0:0:22:4: class=0x088000 card=0x34de8086 chip=0x34298086 rev=0x13
hdr=0x00
non...@pci0:0:22:5: class=0x088000 card=0x34de8086 chip=0x342a8086 rev=0x13
hdr=0x00
non...@pci0:0:22:6: class=0x088000 card=0x34de8086 chip=0x342b8086 rev=0x13
hdr=0x00
non...@pci0:0:22:7: class=0x088000 card=0x34de8086 chip=0x342c8086 rev=0x13
hdr=0x00
uh...@pci0:0:26:0: class=0x0c0300 card=0x34de8086 chip=0x3a378086 rev=0x00
hdr=0x00
uh...@pci0:0:26:1: class=0x0c0300 card=0x34de8086 chip=0x3a388086 rev=0x00
hdr=0x00
uh...@pci0:0:26:2: class=0x0c0300 card=0x34de8086 chip=0x3a398086 rev=0x00
hdr=0x00
eh...@pci0:0:26:7: class=0x0c0320 card=0x34de8086 chip=0x3a3c8086 rev=0x00
hdr=0x00
pc...@pci0:0:28:0: class=0x060400 card=0x34de8086 chip=0x3a408086 rev=0x00
hdr=0x01
pc...@pci0:0:28:4: class=0x060400 card=0x34de8086 chip=0x3a488086 rev=0x00
hdr=0x01
pc...@pci0:0:28:5: class=0x060400 card=0x34de8086 chip=0x3a4a8086 rev=0x00
hdr=0x01
uh...@pci0:0:29:0: class=0x0c0300 card=0x34de8086 chip=0x3a348086 rev=0x00
hdr=0x00
uh...@pci0:0:29:1: class=0x0c0300 card=0x34de8086 chip=0x3a358086 rev=0x00
hdr=0x00
uh...@pci0:0:29:2: class=0x0c0300 card=0x34de8086 chip=0x3a368086 rev=0x00
hdr=0x00
eh...@pci0:0:29:7: class=0x0c0320 card=0x34de8086 chip=0x3a3a8086 rev=0x00
hdr=0x00
pc...@pci0:0:30:0: class=0x060401 card=0x34de8086 chip=0x244e8086 rev=0x90
hdr=0x01
is...@pci0:0:31:0: class=0x060100 card=0x34de8086 chip=0x3a168086 rev=0x00
hdr=0x00
atap...@pci0:0:31:2:class=0x01018f card=0x34de8086 chip=0x3a208086 rev=0x00
hdr=0x00
non...@pci0:0:31:3: class=0x0c0500 card=0x34de8086 chip=0x3a308086 rev=0x00
hdr=0x00
atap...@pci0:0:31:5:class=0x010185 card=0x34de
em(4): 4-port Intel Pro/1000 PF card not detected
Hello,
We're trying to work with newly purcharsed Intel EXPi9404PF NICs ("Intel
PRO/1000 PF Quad Port Server Adapter") but they do not seem to be
detected (no ports showing with 'ifconfig -l'). We're having no
problems with the 2-port version of the same card -- is there a known
issue with the 4-port version?
We've tried three different cards of this model, all with same result.
Thanks in advance for any help.
Charles
--
Charles Owens
Great Bay Software, Inc.
___
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"
attempting local merge of e1000 from RELENG_8 to RELENG_8_0
Hello, We're trying to backport the latest e1000 driver from the -STABLE branch into our internal release that is based around the 8.0 security branch (RELENG_8_0). Specifically, we see some flakiness with the igb driver on one of our hardware platforms that we're hoping the new driver will address. Our initial test with this custom kernel seems not quite right, and I think a suggestion or two from someone more familiar with this code could be a big help. I merged in the driver code last Wednesday... in addition to all files in sys/dev/e1000 I also brought in changes to these files: * sys/conf/files * sys/net/if.c * sys/net/if.h * sys/net/if_var.h * sys/net80211/ieee80211_ioctl.c * sys/sys/priv.h * sys/sys/sockio.h More or less this amounts to this (admittedly simplistic) approach: bring in just enough to get it to compile. Most changes were brought in from -STABLE in full (so each affected file in our source tree now matches STABLE, as of last Wednesday). When we test the igb driver with this kernel, communication seems iffy, and we're seeing this on the console: igb0: Watchdog timeout -- resetting igb0: Queue(1) tdh = 4, hw tdt = 4 igb0: TX(1) desc avail = 1020,Next TX to Clean = 0 On the upside, link-state detection (which was messed up in the 8.0 driver) now seems to work properly. This morning I note that on Friday a number of additional "fixes" to em/igb were MFC'd. So... here are my questions: * Are the error messages likely related to the bugs fixed by these latest commits? --or-- is it more likely a problem with how we did the merge? * Should we expect to succeed at all, or are there other bits of new plumbing (changes since 8.0 was cut) that the newer driver relies on somehow, such that this is an iffy proposition? * Has the e1000 driver in -STABLE now mostly stabilized... or is additional engineering expected in the near term? Any and all assistance is greatly appreciated! Thanks, Charles -- Charles Owens Great Bay Software, Inc. ___ 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"
MFC of igb fixes?
Hello Jack, I'm wondering if you have any thoughts with regard to the expected timeframe for MFC of commit *203049* <http://svn.freebsd.org/viewvc/base?view=revision&revision=203049> to RELENG_8? With igb NICS we're seeing flakiness with link-state handling... and I'm worried that we could fall victim to problems others have seen when putting the NIC under load. Would you happen to have a version of the patch that is ready for RELENG_8? (we'd actually be applying it against RELENG_8_0, as that's what we're currently bundling with our product). I do note that you made a few other minor fixes in the week or so following -- should these be in the picture as well? Any help or advise is appreciated. The system in question is based on the Intel S5520UR motherboard... the NICs are on-board (_not_ PCI-card-based). During boot, the NICs are detected as shown below. At boot the NICs will always show link-state as being active, whether or not a cable is plugged in. igb0: port 0x3020-0x303f mem 0xb1b2-0xb1b3,0xb1b44000-0xb1b47fff irq 40 at device 0.0 on pci1 igb0: Using MSIX interrupts with 3 vectors igb0: [ITHREAD] igb0: [ITHREAD] igb0: [ITHREAD] igb0: Ethernet address: 00:15:17:b4:cf:e4 igb1: port 0x3000-0x301f mem 0xb1b0-0xb1b1,0xb1b4-0xb1b43fff irq 28 at device 0.1 on pci1 igb1: Using MSIX interrupts with 3 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: Ethernet address: 00:15:17:b4:cf:e5 Thank you, Charles -- Charles Owens Great Bay Software, Inc. ___ 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: Sudden mbuf demand increase and shortage under the load (igb issue?)
I've dug around in the source repo... it appears the new code is just shy of being MFC'd. Any known caveats with the new code or is it by all accounts good to go? I'm going to try testing it in 8.0. Thanks Charles Owens Great Bay Software, Inc. Charles Owens wrote: > Hello Jack, > > We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new > Intel server box (based on their S5520UR motherboard). So far we've > seen only oddness with link-state (it wants to always say "active", with > no cable plugged in, unless we do an ifconfig up/down/up), but I'm > concerned that we might fall victim to other symptoms mentioned if we > put the system under load. > > Would you recommend we apply the igb patch you've mentioned? Is it in > RELENG_8 yet, or is it still under development? > > Thanks very much, > Charles > > Charles Owens > Great Bay Software, Inc. > > > > Jack Vogel wrote: > >> This thread is confusing, first he says its an igb problem, then you offer >> an em patch :) >> >> I have an important rev of igb that I am about ready to release, anyone that >> wishes to >> test against a problem they have would be welcome to have early access, just >> let me >> know. >> >> I am not sure about this ich10 change, there are client NICs that >> specifically do NOT >> support jumbo frames, I'll need to look into it tomorrow at work. >> >> Jack >> >> >> On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: >> >> >> >>> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >>> >>> >>>> Folks, >>>> >>>> Indeed, it looks like igb(4) issue. Replacing the card with the >>>> desktop-grade em(4)-supported card has fixed the problem for us. The >>>> system has been happily pushing 110mbps worth of RTP traffic and 2000 >>>> concurrent calls without any problems for two days now. >>>> >>>> e...@pci0:7:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 >>>> hdr=0x00 >>>> vendor = 'Intel Corporation' >>>> class = network >>>> subclass = ethernet >>>> >>>> em0: port 0xec00-0xec1f mem >>>> 0xfbee-0xfbef,0xfbe0-0xfbe7,0xfbedc000-0xfbed irq 24 >>>> at device 0.0 on pci7 >>>> em0: Using MSIX interrupts >>>> em0: [ITHREAD] >>>> em0: [ITHREAD] >>>> em0: [ITHREAD] >>>> em0: Ethernet address: 00:1b:21:50:02:49 >>>> >>>> I really think that this has to be addressed before 7.3 release is out. >>>> FreeBSD used to be famous for its excellent network performance and it's >>>> shame to see that deteriorating due to sub-standard quality drivers. >>>> Especially when there is a multi-billion vendor supporting the driver in >>>> question. No finger pointing, but it really looks like either somebody >>>> is not doing his job or the said vendor doesn't care so much about >>>> supporting FreeBSD. I am pretty sure the vendor in question has access >>>> to numerous load-testing tools, that should have catched this issue. >>>> >>>> This is the second time during the past 6 months I have issue with the >>>> quality of the Intel-based drivers - the first one is filed as >>>> kern/140326, which has stalled apparently despite me providing all >>>> necessary debug information. >>>> >>>> >>>> >>> I can reproduce this bug on my box and I guess the root cause comes >>> from PBA(Packet Buffer Allocation) configuration. Some controllers >>> seems to require more TX buffer size to use 9000 MTU. The datasheet >>> is not clear which controller has how much amount of Packet Buffer >>> storage. This parameter seems to affect performance a lot because >>> increasing TX buffer size results in decreasing RX buffer size. The >>> attached patch seems to fix the issue for me but Jack may know >>> better the hardware details as publicly available datasheet seems >>> to be useless here. >>> >>> >>> >> ___ >> 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" >> >> >> >> > ___ > 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" > > > ___ 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: Sudden mbuf demand increase and shortage under the load (igb issue?)
Hello Jack, We're seeing iffy behavior with igb on FreeBSD 8.0-RELEASE on a new Intel server box (based on their S5520UR motherboard). So far we've seen only oddness with link-state (it wants to always say "active", with no cable plugged in, unless we do an ifconfig up/down/up), but I'm concerned that we might fall victim to other symptoms mentioned if we put the system under load. Would you recommend we apply the igb patch you've mentioned? Is it in RELENG_8 yet, or is it still under development? Thanks very much, Charles Charles Owens Great Bay Software, Inc. Jack Vogel wrote: > This thread is confusing, first he says its an igb problem, then you offer > an em patch :) > > I have an important rev of igb that I am about ready to release, anyone that > wishes to > test against a problem they have would be welcome to have early access, just > let me > know. > > I am not sure about this ich10 change, there are client NICs that > specifically do NOT > support jumbo frames, I'll need to look into it tomorrow at work. > > Jack > > > On Thu, Feb 18, 2010 at 7:42 PM, Pyun YongHyeon wrote: > > >> On Thu, Feb 18, 2010 at 05:05:16PM -0800, Maxim Sobolev wrote: >> >>> Folks, >>> >>> Indeed, it looks like igb(4) issue. Replacing the card with the >>> desktop-grade em(4)-supported card has fixed the problem for us. The >>> system has been happily pushing 110mbps worth of RTP traffic and 2000 >>> concurrent calls without any problems for two days now. >>> >>> e...@pci0:7:0:0: class=0x02 card=0xa01f8086 chip=0x10d38086 rev=0x00 >>> hdr=0x00 >>> vendor = 'Intel Corporation' >>> class = network >>> subclass = ethernet >>> >>> em0: port 0xec00-0xec1f mem >>> 0xfbee-0xfbef,0xfbe0-0xfbe7,0xfbedc000-0xfbed irq 24 >>> at device 0.0 on pci7 >>> em0: Using MSIX interrupts >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: [ITHREAD] >>> em0: Ethernet address: 00:1b:21:50:02:49 >>> >>> I really think that this has to be addressed before 7.3 release is out. >>> FreeBSD used to be famous for its excellent network performance and it's >>> shame to see that deteriorating due to sub-standard quality drivers. >>> Especially when there is a multi-billion vendor supporting the driver in >>> question. No finger pointing, but it really looks like either somebody >>> is not doing his job or the said vendor doesn't care so much about >>> supporting FreeBSD. I am pretty sure the vendor in question has access >>> to numerous load-testing tools, that should have catched this issue. >>> >>> This is the second time during the past 6 months I have issue with the >>> quality of the Intel-based drivers - the first one is filed as >>> kern/140326, which has stalled apparently despite me providing all >>> necessary debug information. >>> >>> >> I can reproduce this bug on my box and I guess the root cause comes >> from PBA(Packet Buffer Allocation) configuration. Some controllers >> seems to require more TX buffer size to use 9000 MTU. The datasheet >> is not clear which controller has how much amount of Packet Buffer >> storage. This parameter seems to affect performance a lot because >> increasing TX buffer size results in decreasing RX buffer size. The >> attached patch seems to fix the issue for me but Jack may know >> better the hardware details as publicly available datasheet seems >> to be useless here. >> >> > ___ > 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" > > > ___ 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: libnet_get_hwaddr() failing with FreeBSD 8
Charles Owens wrote: > Hello, > > I'm working with some code (snippet below) that fails with > libnet_get_hwaddr() function (it returns false). The code works fine > under 7.x but not with 8.0 . > > Any thoughts as to what might be going on? > Issue solved. I had been building the libnet port within a jail... and if it can't find /dev/bpf0 then it compiles in dummy code for a number of functions. Building libnet in a non-jail setting is fine. The final solution for us was to tweak devfs in the jail so /dev/bpf0 _is_ present. Charles Owens Great Bay Software, Inc. ___ 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"
libnet_get_hwaddr() failing with FreeBSD 8
Hello,
I'm working with some code (snippet below) that fails with
libnet_get_hwaddr() function (it returns false). The code works fine
under 7.x but not with 8.0 .
Any thoughts as to what might be going on?
Thanks much,
Charles
int
get_hw_addr(char *device, u_char mac[6])
{
struct libnet_ether_addr*mac_address;
libnet_t*ln;
charerr_buf[LIBNET_ERRBUF_SIZE];
ln = libnet_init(LIBNET_LINK, device, err_buf);
if (!ln) {
fprintf(stderr, "libnet_open_link_interface: %s\n", err_buf);
return -1;
}
mac_address = libnet_get_hwaddr(ln);
if (!mac_address) {
fprintf(stderr, "libnet_get_hwaddr: %s\n", err_buf);
return -1;
}
memcpy(mac, mac_address->ether_addr_octet, 6);
return 0;
}
--
Charles Owens
Great Bay Software, Inc.
___
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: "PHY read timeout" with bce2 & 3 on FreeBSD 8.0
Pyun YongHyeon wrote: > On Mon, Jan 18, 2010 at 10:40:55AM -0500, Charles Owens wrote: >> Hello, >> >> I'm working with a system (IBM System x3550 M2) that has four onboard >> bce(4) NICs. Using FreeBSD 8.0, the first two seem to function fine, >> but the second two do not, yielding messages like this when a cable is >> inserted: >> >> Jan 12 10:37:19 dmz55 kernel: <2<>N2M>NINM IM INISMI AI S AIIS SAA >> 22cc2,,c , E2EIcIES,SIAS AA >> E I00 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: S0 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: <<22>>A >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: 0 >> Jan 12 10:37:28 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): >> Error: PHY read timeout! >> phy = 1, reg = 0x0001 >> >> >> What's are the best next steps to take in figuring this out? Thanks in >> advance for any assistance. Kernel boot log appending below. >> > > Are you using ASF/IMPI/UMP on bce2 or bce3? > If so would you try attached patch? Publicly available datasheet > lacks details on management firmware handling so I'm not sure what > is really happening here. > davidch may shed light on this(CCed). Ok, I've got the patch in place plus the PRINTF buffer option that David suggested. More observations: * bce2 and 3 now seem usable. Could this be the patch? Or maybe I just was moving too fast before. * Trouble (similar error messages then eventually reboot) begins only when I plug into the IMM management port. Why is this related to the bce ports? Below are the error logs. Note that I've got now got bce2 configured as the active NIC on local LAN. You can see here that I unplug bce2. What you don't see is that I plug cable into the IMM port, wait 10 seconds or so, then move the cable back to bce2. Within a second or two the error messages start flowing... and finally the system reboots about a minute later. Jan 20 06:50:02 dmz55 kernel: bce2: link state changed to DOWN Jan 20 06:50:23 dmz55 kernel: NMI ISNAM I ISNAM 2IcN ,I2M cSE,AI IISESA2AIcS, AE I00S Jan 20 06:50:23 dmz55 kernel: Jan 20 06:50:23 dmz55 kernel: A Jan 20 06:50:23 dmz55 kernel: 2c0, Jan 20 06:50:23 dmz55 kernel: E Jan 20 06:50:23 dmz55 kernel: ISA 0 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0001 Jan 20 06:50:23 dmz55 last message repeated 3 times Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0004 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0005 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0019 Jan 20 06:50:24 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0001 Jan 20 06:50:24 dmz55 last message repeated 3 times ... etc., with eventually some of these showing up as well: Jan 20 06:50:37 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1608): PHY write timeout! Thanks, Charles ___ 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: "PHY read timeout" with bce2 & 3 on FreeBSD 8.0
Pyun YongHyeon wrote: > On Mon, Jan 18, 2010 at 10:40:55AM -0500, Charles Owens wrote: >> Hello, >> >> I'm working with a system (IBM System x3550 M2) that has four onboard >> bce(4) NICs. Using FreeBSD 8.0, the first two seem to function fine, >> but the second two do not, yielding messages like this when a cable is >> inserted: >> >> Jan 12 10:37:19 dmz55 kernel: <2<>N2M>NINM IM INISMI AI S AIIS SAA >> 22cc2,,c , E2EIcIES,SIAS AA >> E I00 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: S0 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: <<22>>A >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: 0 >> Jan 12 10:37:28 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): >> Error: PHY read timeout! >> phy = 1, reg = 0x0001 >> >> >> What's are the best next steps to take in figuring this out? Thanks in >> advance for any assistance. Kernel boot log appending below. >> > > Are you using ASF/IMPI/UMP on bce2 or bce3? > If so would you try attached patch? Publicly available datasheet > lacks details on management firmware handling so I'm not sure what > is really happening here. > davidch may shed light on this(CCed). > At this stage I'm not doing anything with the interfaces beyond trying plug in a cable and configure an IP with ifconfig. A few more details that might be worth mentioning: * The system does have the built-in Integrated Management Module (IMM) that has its own dedicated Ethernet port. I've done nothing with it. * If you do happen to plug a cable into this management NIC, within a few seconds the box does a reboot (!) I'll test the patch within a couple days. Thanks! Charles ___ 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"
"PHY read timeout" with bce2 & 3 on FreeBSD 8.0
Hello, I'm working with a system (IBM System x3550 M2) that has four onboard bce(4) NICs. Using FreeBSD 8.0, the first two seem to function fine, but the second two do not, yielding messages like this when a cable is inserted: Jan 12 10:37:19 dmz55 kernel: <2<>N2M>NINM IM INISMI AI S AIIS SAA 22cc2,,c , E2EIcIES,SIAS AA E I00 Jan 12 10:37:19 dmz55 kernel: Jan 12 10:37:19 dmz55 kernel: S0 Jan 12 10:37:19 dmz55 kernel: Jan 12 10:37:19 dmz55 kernel: <<22>>A Jan 12 10:37:19 dmz55 kernel: Jan 12 10:37:19 dmz55 kernel: 0 Jan 12 10:37:28 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0001 What's are the best next steps to take in figuring this out? Thanks in advance for any assistance. Kernel boot log appending below. Charles -- Charles Owens Great Bay Software, Inc. Copyright (c) 1992-2009 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-RELEASE-p1 #0: Mon Dec 7 08:21:01 EST 2009 m...@dmz55.greatbaysoftware.com:/usr/obj/usr/src/sys/PAE Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(R) CPU E5504 @ 2.00GHz (2000.08-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106a5 Stepping = 5 Features=0xbfebfbff Features2=0x9ce3bd AMD Features=0x2810 AMD Features2=0x1 TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4145225728 (3953 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 6 ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 20090521 tbfadt-707 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware ispfw: registered firmware kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x588-0x58b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 28 at device 1.0 on pci0 pci11: on pcib1 bce0: mem 0x9600-0x97ff irq 28 at device 0.0 on pci11 miibus0: on bce0 brgphy0: PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce0: Ethernet address: 00:1a:64:e5:57:64 bce0: [ITHREAD] bce0: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (4.6.4); Flags (MSI|MFW); MFW (NCSI 1.0.6) bce1: mem 0x9800-0x99ff irq 40 at device 0.1 on pci11 miibus1: on bce1 brgphy1: PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce1: Ethernet address: 00:1a:64:e5:57:66 bce1: [ITHREAD] bce1: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (4.6.4); Flags (MSI|MFW); MFW (NCSI 1.0.6) pcib2: irq 29 at device 2.0 on pci0 pci16: on pcib2 bce2: mem 0x9200-0x93ff irq 29 at device 0.0 on pci16 miibus2: on bce2 brgphy2: PHY 1 on miibus2 brgphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce2: Ethernet address: 00:21:5e:08:14:68 bce2: [ITHREAD] bce2: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (4.6.4); Flags (MSI|MFW); MFW (NCSI 1.0.6) bce3: mem 0x9400-0x95ff irq 41 at device 0.1 on pci16 miibus3: on bce3 brgphy3: PHY 1 on miibus3 brgphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto bce3: Ethernet address: 00:21:5e:08:14:6a bce3: [ITHREAD] bce3: ASIC (0x57092003); Rev (C0); Bus (PCIe x2, 5Gbps); B/C (4.6.4); Flags (MSI|MFW); MFW (NCSI 1.0.6) pcib3: irq 24 at device 3.0 on pci0 pci21: on pcib3 pcib4: irq 30 at device 7.0 on pci0 pci26: on pcib4 pci0: at device 16.0 (no driver attached) pci0: at device 16.1 (no driver attached) pci0: at device 17.0 (no driver attached) pci0: at device 17.1 (no driver attached) pci0: at device 20.0 (no driver attached) pci0: at device 20.1 (no driver attached) pci0: at device 20.2 (no driver attached) pci0: at device 20.3 (no driver attached) pci0: at device 22.0 (no driver attached) pci0: at device 22.1 (no driver attached) pci0: at device 22.2 (no driver attached) pci0: at device 22.3 (no driver attached) pci0: at device 22.4 (no driver attac
