Supermicro Bladeserver

I am trying to track down a problem being experienced at icir.org using SuperMicro bladeservers, the SERDES 82575 interfaces are having connectivity or perhaps autoneg problems, resulting in link transitions and watchdog resets. The closest hardware my org at Intel has is a Fujitsu server who's bl

Re: em 7.1.9

NO, and i was rather irritated by a checkin that broke backward compatibility without even asking me first btw. That should be the only issue however, and it can be fixed by a define. I'll get there soon. Jack On Thu, Jan 20, 2011 at 9:00 AM, Mike Tancsa wrote: > Hi Jack, >I was hoping

Re: High interrupt rate on a PF box + performance

If you go to 8.2 and the latest driver you will get better stats also, ahem... Jack On Thu, Jan 27, 2011 at 11:57 AM, Jeremy Chadwick wrote: > On Thu, Jan 27, 2011 at 08:39:40PM +0100, Damien Fleuriot wrote: > > > > > > On 1/27/11 7:46 PM, Sergey Lobanov wrote: > > > В сообщении от Пятница 28 я

Re: High interrupt rate on a PF box + performance

On Thu, Jan 27, 2011 at 12:58 PM, Jeremy Chadwick wrote: > > On Thu, Jan 27, 2011 at 09:38:22PM +0100, Damien Fleuriot wrote: > > On 1/27/11 8:57 PM, Jeremy Chadwick wrote: > > > > <...snipping out stuff...> > > > We're also considering moving to faster machines but I don't think that > > will hel

Re: em0: Watchdog timeout -- resetting

I don't test POLLING, sounds like its broken, I don't understand why you think you need you need it? This hardware supports MSI why not use it? Jack 2011/1/31 Lev Serebryakov > Hello, Freebsd-stable. > You wrote 1 февраля 2011 г., 10:24:16: > > > And all connections are reset. Before latest

Re: em0 with latest driver hangs again and again (without "Watchdog timeout" message!)

Anyone in net and stable that wants it, limits blocked it, so send me personal email and I'll send to you. Jack On Wed, Feb 23, 2011 at 9:47 AM, Jack Vogel wrote: > Here is the 7.2.2 tarball. IMPORTANT: if you use this DO NOT try and put it > > into your kernel source tree, it w

Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!)

Missed packets just mean that some temporary resource shortage or error caused the packet to be dropped. I don't believe this is indicative of a problem, just let it keep running, 2 days is good but 2 weeks is better :) Thanks for testing it! Jack On Sun, Mar 6, 2011 at 4:37 AM, Özkan KIRIK wr

Re: em0 with latest driver hangs again and again (without "Watchdogtimeout" message!)

> dev.em.3.mac_stats.mcast_pkts_recvd: 1713418 > dev.em.3.mac_stats.rx_frames_64: 1031384 > dev.em.3.mac_stats.rx_frames_65_127: 612329188 > dev.em.3.mac_stats.rx_frames_128_255: 21097424 > dev.em.3.mac_stats.rx_frames_256_511: 16515533 > dev.em.3.mac_stats.rx_frames_512_1023: 365471

Re: ixgbe(4) and "Could not setup receive structures"

If you get this message its only for one reason, you don't have enough mbufs to fill your rings. You must do one of two things, either reduce the number of queues, or increase the relevant mbuf pool. Increase the 9K mbuf cluster pool. Jack On Thu, Apr 14, 2011 at 6:05 AM, Leon Meßner wrote: >

Re: ixgbe(4) and "Could not setup receive structures"

So, what do you have in mind as the real problem then? Jack On Thu, Apr 14, 2011 at 11:55 AM, K. Macy wrote: > That isn't guaranteed to work if he is KVA limited. > > On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel wrote: > > If you get this message its only for one reason, y

Re: ixgbe(4) and "Could not setup receive structures"

f he is KVA limited. > > > > On Thu, Apr 14, 2011 at 6:44 PM, Jack Vogel wrote: > > > If you get this message its only for one reason, you don't have enough > mbufs > > > to > > > fill your rings. You must do one of two things, either reduce the

Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)

Notice this: em0: Using MSIX interrupts with 0 vectors ZERO vectors are not a good sign :) You need to look at your system, you have MSIX disabled or something? Maybe some message in /var/log/messages?? Jack On Thu, Apr 28, 2011 at 1:20 PM, Wiktor Niesiobedzki wrote: > Hi, > > I've installed

Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)

cap 01[68] = powerspec 2 supports D0 D3 current D0 >cap 05[70] = MSI supports 1 message, 64 bit, vector masks >cap 08[88] = HT MSI fixed address window disabled at 0xfee0 >cap 0d[90] = PCI Bridge card=0x0004 > > Though they mention that HT MSI windows is disabl

Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)

On Thu, Apr 28, 2011 at 2:28 PM, John Baldwin wrote: > On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: > > Hi, > > > > I really don't know (I haven't done that intentionally). There is > > nothing special in /var/log/messages: > > kadlubek# grep -i msix /var/log/messages > > Apr

Re: No data received with Intel Corporation Gigabit CT Desktop Adapter (82574L)

29 Wiktor Niesiobedzki : > > > 2011/4/28 Jack Vogel : > > >> On Thu, Apr 28, 2011 at 2:28 PM, John Baldwin > wrote: > > >>> > > >>> On Thursday, April 28, 2011 5:17:11 pm Wiktor Niesiobedzki wrote: > > >>> > Though they ment

Re: Intel "em" driver sleeps with non-sleepable lock.

So, this happens EVERY time after an install of 8.2 ?? Give me details about the hardware please. Jack On Thu, May 5, 2011 at 11:11 AM, Zaphod Beeblebrox wrote: > The motherboard in question is made by Intel and contains a Xeon 3440 > (4 core x 2 HT per core). 16 Gig of RAM is installed and w

Re: em0 watchdog timeouts on 8-STABLE

I have hardware now, am working on reproducing this. Just curious, do you have the em driver defined in the kernel, or as a module? Jack On Wed, Jun 15, 2011 at 2:09 AM, Joshua Boyd wrote: > On Wed, Jun 15, 2011 at 3:57 AM, Jeremy Chadwick > wrote: > > > On Wed, Jun 15, 2011 at 03:14:43AM -040

Re: em0 watchdog timeouts on 8-STABLE

astebin.com/raw.php?i=4JL814m3 >> >> On Wed, Jun 15, 2011 at 8:20 PM, Jack Vogel wrote: >> >>> I have hardware now, am working on reproducing this. Just curious, do you >>> have >>> the em driver defined in the kernel, or as a module? >>> >&

Re: 10G Inter adapter

What OS release are you going to be using, 8.2 ? The driver in HEAD is the latest code, the internal tarball goes thru release machinery so it is lagging a bit (2.3.8 vs 2.3.11), you should be OK in either case, but I'd recommend the newer. Jack On Tue, Aug 23, 2011 at 12:39 AM, Sami Halabi wr

Re: rsync corrupted MAC

c/sys/**THEBIGHONKER >>> amd64 >>> $ >>> >>> >>> >>> $ ifconfig em0 >>> em0: flags=8843 metric 0 mtu >>> 1500 >>>options=2088 >>>ether 00:30:48:8e:9f:f3 >>>inet 192.168.200.4 netma

Re: rsync corrupted MAC

e my brevity. > > > Jack Vogel wrote: >> >> Well, for a start I'd get both interfaces at the same speed, sounds like a >> hardware >> issue of some sort, cable or switch maybe? >> >> Jack >> >> >> On Mon, Oct 10, 2011 at 5

Re: em0 watchdog timeout

On Sun, Nov 13, 2011 at 10:22 AM, Willem Jan Withagen wrote: > On 2011-11-10 23:25, Joshua Boyd wrote: > >> On Thu, Nov 10, 2011 at 6:51 AM, Willem Jan Withagen > > wrote: >> >>em0@pci0:0:25:0:class=0x02 card=0x10bd15d9 >>chip=0x10bd8086 rev=0x02 hdr=0x

Re: igb hang when cable unplugged

On Fri, Nov 25, 2011 at 1:18 PM, Daniel Kalchev wrote: > I am observing an transmit hang of the igb driver when the cable is > unplugged. It only recovers after unit reset, such as > > ifconfig igb0 down up > > This is with kernel > > FreeBSD xxx 8.2-STABLE FreeBSD 8.2-STABLE #0: Fri Sep 30 16:17

nmbclusters: how do we want to fix this for 8.3 ?

Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf clusters per MSIX vector, that's how many are in a ring. Either driver will configure 8 queues on a system with that many or more cores, so 8K clusters per port... My test engineer has a system with 2 igb ports, and 2 10G ixgbe

Re: nmbclusters: how do we want to fix this for 8.3 ?

On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo wrote: > On Wed, Feb 22, 2012 at 09:09:46PM +, Ben Hutchings wrote: > > On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > ... > > > I have hit this problem recently, too. > > > Maybe the issue mostly/only exists on 32-bit systems. > > > > No,

Re: ixgbe v2.3.11 won't negotiate LACP, v2.4.4 does

Never rains but it pours, this is the second request today :) Yes, I will do an MFC as soon as quickly as I am able. Jack On Tue, Mar 6, 2012 at 3:00 PM, Chris Forgeron wrote: > I have a few systems with Intel X520-DA2 PCIe network cards (10 Gig). > > The problem I've been running into is wit

Re: Support for Intel 82599ES?

Yes, it is supported in the ixgbe driver. Jack On Fri, Jun 1, 2012 at 8:36 AM, Rick Miller wrote: > Hi All, > > I did not see the Intel 82599ES chipset in the hardware release notes > for 8.3 or 9.0. Are these controllers supported at this time? > > -- > Take care > Rick Miller > _

Re: Intel X520-DA2 Supported in stable/8?

Increase your system mbuf pool size, you do not want that failure to happen. Jack On Fri, Jun 22, 2012 at 2:01 PM, Rick Miller wrote: > dmesg and ifconfig output below... > > On Fri, Jun 22, 2012 at 4:02 PM, Rick Miller > wrote: > > On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer > wrote: > >>

Re: Intel X520-DA2 Supported in stable/8?

ups. Hopefully, when you get rid of the rx ring setup failure you will get things working. Jack On Fri, Jun 22, 2012 at 3:19 PM, Rick Miller wrote: > On Fri, Jun 22, 2012 at 5:21 PM, Jack Vogel wrote: > > Increase your system mbuf pool size, you do not want that failure to > happen.

Re: Intel X520-DA2 Supported in stable/8?

Rick Miller wrote: > > On Fri, Jun 22, 2012 at 7:23 PM, Jack Vogel wrote: > >> Would probably be good to take care of the storm threshold if you > >> haven't, > >> set it to 0 > >> and you disable the check, that's what we do internally. As for

Re: FreeBSD 8-STABLE on R620 w/ X520-DA2/Intel 82599

Be patient, a new version will hit HEAD soon with the ID added. Jack On Fri, Jun 29, 2012 at 9:35 AM, Rick Miller wrote: > On Fri, Jun 29, 2012 at 11:56 AM, Gary Palmer wrote: > > On Fri, Jun 29, 2012 at 10:50:52AM -0400, Rick Miller wrote: > >> Hi All, > >> > >> I have 2 hosts, HP DL360 G8 an

Re: network probs rxcsum

he same NIC in > >> my other box! > >> What could be causing this problem? > >> > > I think you mean "-rxcsum", not "-rxcons". > > > > Could you please provide output from the following commands? Jack Vogel > > will probably respond

Re: Strange igb befavior

Panic is due to a failure to get enough mbufs, when you make your ring that big you hit the problem, I have been experimenting with a change to fix it but am not yet completely confident, for the moment don't make your ring so big :) Jack On Thu, May 27, 2010 at 1:08 AM, Kirill Yelizarov wrot

Re: Strange igb befavior

k_latency=4000 > hw.igb.rx_process_limit=400 > hw.igb.fc_setting=0 > hw.igb.lro=0 > > Some years ago i downloaded an article about em card from intel site. > Perhaps there is one for igb as well? > > Kirill > > --- On Thu, 5/27/10, Jack Vogel wrote: > > > From: Jack Vogel

Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850

d = 0 > >> em1: Good Packets Rcvd = 251348 > >> em1: Good Packets Xmtd = 204160 > >> em1: TSO Contexts Xmtd = 0 > >> em1: TSO Contexts Failed = 0 > >> > >> > >> > >> > >> as0# sh int fa0/43 > >

Re: RELENG_8 em(4) -- input errors ("Missed Packets")

I do not believe this is a problem, a bit hard to parse the numbers on that netstat, but missed packets will happen when an interface gets lots of traffic. Keep an eye on things though. Thanks, Jack On Sat, Jun 19, 2010 at 12:23 PM, Jeremy Chadwick wrote: > Something I came across today on a R

Re: RELENG_7 em problems (and RELENG_8)

I got the email, there are server outages around here today and people leaving for a long weekend, so not much getting done. I'll take some time and look into this after the weekend, ok? Jack On Fri, Jul 2, 2010 at 10:39 AM, Mike Tancsa wrote: > Hi Jack, >Just a followup to the email

Re: em(4) duplex problems with 82541EI on RELENG_8, -CURRENT on PowerEdge 1850

The fact that I WISH it to be MFC'd doesn't mean that I am actually given permission to do so. Jack On Thu, Jul 15, 2010 at 10:48 AM, Steve Polyack wrote: > On 07/15/10 13:31, Michael Tuexen wrote: > >> On Jul 15, 2010, at 6:50 PM, Brian A. Seklecki wrote: >> >> >> >>> >>> It may have gon

Watchdog resets on 82575

If you have this adapter and have been getting watchdogs you need to pick up the small update I checked into HEAD today. When I added the SR-IOV support for the 82576 adapter I removed a call to set the MAC type in an early routine, thinking it was unnecessary, since a slightly later shared code in

Re: svn commit: r209611 - head/sys/dev/e1000

's not the complete string, use sysctl -a |grep blacklist to find it) and set that to 0. It needs to be set at boot. That should get you running. Jack On Tue, Aug 17, 2010 at 8:18 AM, pluknet wrote: > On 1 July 2010 02:13, Jack Vogel wrote: > > On Wed, Jun 30, 2010 at 2:50 PM,

Re: RELENG_7 em problems (and RELENG_8)

Hmmm, interesting, I'll have to have some testing done, maybe for the 574 it should automagically disable CSUM? Jack On Tue, Aug 17, 2010 at 11:52 AM, Pyun YongHyeon wrote: > On Mon, Aug 16, 2010 at 05:07:11PM -0400, Mike Tancsa wrote: > > Hi Jack, > > FYI, I am still seeing this same

Re: RELENG_7 em problems (and RELENG_8)

I believe the requirement of a context descriptor for most frames in the igb driver is just the way the hardware works, I've looked over the Linux driver again and it looks like they require the same. I don't believe its a big deal, just the added descriptor for the frame. Jack On Tue, Aug 17, 2

Re: RELENG_7 em problems (and RELENG_8)

Well we do of course, i'll have my test engineer try it both ways and see what looks better. Let you know... Jack On Tue, Aug 17, 2010 at 12:35 PM, Pyun YongHyeon wrote: > On Tue, Aug 17, 2010 at 12:05:56PM -0700, Jack Vogel wrote: > > Hmmm, interesting, I'll have to hav

Re: RELENG_7 em problems (and RELENG_8)

ng about igb. But hey, I'm willing to be proven wrong :) Jack On Tue, Aug 17, 2010 at 12:47 PM, Pyun YongHyeon wrote: > On Tue, Aug 17, 2010 at 12:34:31PM -0700, Jack Vogel wrote: > > I believe the requirement of a context descriptor for most frames in the > igb > > driv

Re: svn commit: r209611 - head/sys/dev/e1000

On Thu, Aug 19, 2010 at 2:45 AM, pluknet wrote: > > By the way, > > Sometimes after boot I have to kldreload if_igb.ko several > times until watchdog go to sleep, so traffic starts flowing. > Hmmm, the intention is that the VF always be single queue, but I see the code I used to limit it is brok

Re: Crashes on X7SPE-HF with em

Hmmm, can you remove ALTQ from the mix and see if that eliminates it? Jack On Thu, Aug 26, 2010 at 2:56 PM, Philipp Wuensche wrote: > Jeremy Chadwick wrote: > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > ideas. OP's ba

Re: Crashes on X7SPE-HF with em

On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick wrote: > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wuensche wrote: > > Jeremy Chadwick wrote: > > > > > > CC'ing Jack Vogel of Intel and Yong-Hyeon PYUN who might have some > > > ideas. O

Re: Crashes on X7SPE-HF with em

On Fri, Aug 27, 2010 at 6:04 AM, Philipp Wuensche wrote: > Jack Vogel wrote: > > > > > > On Thu, Aug 26, 2010 at 3:15 PM, Jeremy Chadwick > > mailto:free...@jdc.parodius.com>> wrote: > > > > On Thu, Aug 26, 2010 at 11:56:48PM +0200, Philipp Wu

Re: page fault in e1000_clear_hw_cntrs_base_generic() during SIOCAIFADDR

LOL, if its the VF its pretty new code, PLEASE anyone, if this is the case make it clear in the title somewhere, ok? Thanks. Jack On Wed, Sep 1, 2010 at 10:24 AM, John Baldwin wrote: > On Wednesday, September 01, 2010 1:11:31 pm pluknet wrote: > > On 1 September 2010 20:06, John Baldwin wrote

Re: MSIX failure

In the future make sure that you put E1000 or EM in the title otherwise I might miss it, fortunately I looked at this :) I'm on a holiday weekend, I will investigate this tomorrow. Jack On Mon, Sep 6, 2010 at 8:53 AM, Gareth de Vaux wrote: > Hi all, I moved from 8.0-RELEASE to last week's -ST

Re: MSIX failure

more about the system please? Jack On Mon, Sep 6, 2010 at 11:36 AM, Jack Vogel wrote: > In the future make sure that you put E1000 or EM in the title otherwise I > might miss it, > fortunately I looked at this :) > > I'm on a holiday weekend, I will investigate thi

Re: MSIX failure

some other issues, and I have added a changed message that will be less confusing. Regards, Jack On Tue, Sep 7, 2010 at 10:00 AM, Jack Vogel wrote: > Email to Gareth de Vaux is bouncing :( > > First off, this device was not supported in 8.0 REL, what were you running > that last

Re: MSIX failure

2010 at 2:40 AM, Gareth de Vaux wrote: > On Tue 2010-09-07 (13:25), Jack Vogel wrote: > > I've looked at the code, this message was misleading, what really happens > > is that the driver fails to be able to setup either MSIX OR MSI, when > this > > happens it will fall

Re: MSIX failure

On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > Hi! > > > > Is this within a jail or something else along those lines? I can't > > > reproduce the problem otherwise. Frustrating! Someone else on the > list > > > might have ideas as to what could cause this. > > > > Nope, this's a normal h

Re: MSIX failure

On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: > > > > > Hi! > > > > > > > > Is this within a jail or something else alo

Re: MSIX failure

ote: > On Thursday, September 09, 2010 3:04:27 pm Jack Vogel wrote: > > On Thu, Sep 9, 2010 at 11:37 AM, John Baldwin wrote: > > > > > On Thursday, September 09, 2010 12:41:07 pm Jack Vogel wrote: > > > > On Thu, Sep 9, 2010 at 7:33 AM, Kurt Jaeger wrote: &g

Re: MSIX failure

On Fri, Sep 10, 2010 at 1:41 AM, Gareth de Vaux wrote: > On Thu 2010-09-09 (13:48), Jack Vogel wrote: > > Gareth's email bouncing for anybody else or is it just me? > > Yes sorry I disabled this alias after picking up years of spam on the > mailman archives. I assumed

Re: MSIX failure

On Sun, Sep 12, 2010 at 1:15 AM, Gareth de Vaux wrote: > On Fri 2010-09-10 (10:41), Gareth de Vaux wrote: > > > Gareth, set hw.pci.honor_msi_blacklist=0, you'll have to do that at > boot > > > btw. > > > > Ok, I'll have to get back to you in a day or 2 when I reboot. > > Done: > > $ sysctl -a |

Re: MSIX failure

We don't deal with desktop systems that much in my group, it was pointed out by a coworker that the BIOS has settings that could disable MSI, please check out how yours is set. Jack On Mon, Sep 13, 2010 at 7:42 AM, Gareth de Vaux wrote: > On Fri 2010-09-10 (10:43), Jack Vogel wrote

Re: RELENG_7 em problems (and RELENG_8)

There is a new revision of the em driver coming next week, its going thru some stress pounding over the weekend, if no issues show up I'll put it into HEAD. Yongari's changes in TX context handling which effects checksum and tso are added. I've also decided that multiple queues in 82574 just are a

Re: RELENG_7 em problems (and RELENG_8)

m what you show here. I will try to get the new driver out shortly for you to try. Jack On Sun, Sep 26, 2010 at 2:57 PM, Mike Tancsa wrote: > At 06:36 PM 9/24/2010, Jack Vogel wrote: > >> There is a new revision of the em driver coming next week, its going thru >> some >> st

Re: RELENG_7 em problems (and RELENG_8)

The system I've had stress tests running on has 82574 LOMs, so I hope it will solve the problem, will see tomorrow morning at how things have held up... Jack On Sun, Sep 26, 2010 at 4:43 PM, Mike Tancsa wrote: > At 06:19 PM 9/26/2010, Jack Vogel wrote: > >> Your em1 is using

Re: Bogus "igb1: Could not setup receive structures" in 8-STABLE

The problem is mbuf resources, the driver is autoconfiguring the number of queues based on the number of cores, on newer systems with lots of them this is outstripping the mbuf resource pool. I have decided to hard limit the queues to 8, you can fix the number manually by searching for num_queues

Re: Bogus "igb1: Could not setup receive structures" in 8-STABLE

The number of MSIX vectors it uses is the number of queues PLUS one vector for link. I would use two or four rather than 3, but it should be ok with that if that's what you wish. Jack On Thu, Oct 14, 2010 at 6:58 PM, Terry Kennedy wrote: > > The problem is mbuf resources, the driver is autocon

Re: repeating crashes with 8.1

520 1504 1488 1472 1456 1440 1424 > 1408 1392 1376 1360 1344 1328 1312 1296 1280 1264 1248 1232 1216 1200 1184 > 1168 1152 1136 1120 1104 1088 1072 1056 1040 1024 1008 992 976 960 944 928 > 912 896 880 864 848 832 816 800 784 768 752 736 720 704 688 672 656 640 624 > 608 592 576 560 544 5

Re: repeating crashes with 8.1

Odd, can you make any connection between this and the em complaints?? Jack On Fri, Oct 22, 2010 at 6:59 PM, Mike Tancsa wrote: > At 09:11 PM 10/22/2010, Mike Tancsa wrote: > >> At 08:01 PM 10/22/2010, Chris Morrow wrote: >> >>> Note, Warren and I attempted to test this this evening on a 10.04

Re: icmp packets on em larger than 1472

472 > > To: "Kirill Yelizarov" > > Cc: freebsd-stable@freebsd.org, "Jack Vogel" > > Date: Wednesday, November 10, 2010, 3:59 PM > > On Wed, Nov 10, 2010 at 04:21:12AM > > -0800, Kirill Yelizarov wrote: > > > Hi, > > > > > &g

Re: problems with network on em

>>> dev.em.2.%pnpinfo: vendor=0x8086 device=0x1010 subvendor=0x8086 > subdevice=0x1011 class=0x02 > >>> dev.em.2.%parent: pci1 > >>> dev.em.2.debug: -1 > >>> dev.em.2.stats: -1 > >>> dev.em.2.rx_int_delay: 0 > >>> dev.em.2.t

Re: problems with network on em

t ~1Gbit/s (125MB/s,115Kpps) forwarding traffic in testing > (24 nodes was downloading a file with wget from server from another side of > router), but finally there was some deadlock. I'm recovering the data on it. > > On 2010.11.20, at 22:37, Jack Vogel wrote: > > > Did you m

Re: repeating crashes with 8.1

I'm a bit dubious about this, if a descriptor still has an mbuf it was due to a discard, go look at em_rx_discard(), you will notice there that all these things are already being done at that point. So do you have a scenario where we can have an unused mbuf that didn't come thru that path?? Jack

Re: em(4) on FreeBSD is sometimes annoying

"me too" 's are of little help. Please elaborate on your "exact same", since each person's perception will be slightly different. So far I have heard nothing that sounds like a driver issue. Jack On Fri, Aug 8, 2008 at 5:50 AM, Markus Vervier <[EMAIL PROTECTED]> wrote: > > Hi, > > I just stumbl

Re: em(4) on FreeBSD is sometimes annoying

OK, I just got access to a machine, am going to install and see if I can repro this this afternoon. Jack On Fri, Aug 8, 2008 at 10:56 AM, Markus Vervier <[EMAIL PROTECTED]> wrote: > Jack Vogel schrieb: >> >> "me too" 's are of little help. Please elabo

Re: em(4) on FreeBSD is sometimes annoying

On Mon, Aug 11, 2008 at 7:02 AM, Jeremy Chadwick <[EMAIL PROTECTED]> wrote: > On Mon, Aug 11, 2008 at 08:19:46AM +, Josh Paetzel wrote: >> On Friday 08 August 2008 06:31:24 pm Jack Vogel wrote: >> > OK, I just got access to a machine, am going to install and see

Re: em(4) on FreeBSD is sometimes annoying

On Mon, Aug 11, 2008 at 1:32 PM, Markus Vervier <[EMAIL PROTECTED]> wrote: > Jack Vogel wrote: >> >> Seems possibly a BIOS thing, if not that bad cable, bad link partner >> maybe?? >> > > I had the problem with all sorts of switches / cables. How can I dump

Re: em(4) on FreeBSD is sometimes annoying

On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier <[EMAIL PROTECTED]> wrote: > Jack Vogel wrote: >> >> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >> running the version that Jeremy said he was, if that matches you might go >> look

Re: em(4) on FreeBSD is sometimes annoying

On Wed, Aug 13, 2008 at 8:22 AM, Jack Vogel <[EMAIL PROTECTED]> wrote: > On Wed, Aug 13, 2008 at 3:04 AM, Markus Vervier <[EMAIL PROTECTED]> wrote: >> Jack Vogel wrote: >>> >>> I didn't mean the NIC EEPROM, but the system BIOS, make sure you are >

HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE

e path, or using a set of scripts that get postinstalled you need to be ready to make this change. How can you tell if you have such a device: Simple, use pciconf, there are only 3 ID's that are effected: 0x10A7, 0x10A9, and 0x10D6. If you have questions feel free to email me. Cheers

Re: HEADS UP: E1000 networking changes in STABLE/7.1 RELEASE

On Wed, Aug 13, 2008 at 8:13 PM, Paul <[EMAIL PROTECTED]> wrote: > Hi Jack. Will the em driver ever support the multiple hardware queues of > the 82571 or are we just stuck with the standard em driver? > Has there been any significant change in the em driver itself ? > I have a feeling that the 82

Re: em(4) on FreeBSD is sometimes annoying

d neither our driver or the Linux driver has a way to bring it back out of that state. Until this gets worked out all I can tell you is "keep that cable IN" :) Jack On Thu, Aug 14, 2008 at 4:33 AM, Markus Vervier <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE

Re: fxp multicast forwarding problems

>> >> Attempted workarounds which don't work to un-wedge the chip: >> Reload the fxp0 microcode with "ifconfig fxp0 link0" >> Forcibly unloading the kernel module and reloading it >> Unpatching and repatching at the switch (a cheap 10/100 one) >> En

7.1 RC E1000 fix testing

Anyone running 7.1 and using E1000 hardware that has the time, I would appreciate any testing you can do. This has an important fix for SuperMicro servers but any regression test of the code would be helpful. The email was getting rejected due to the tarball size, so contact me and I will send you

7.1 RC E1000 fix

Anyone running 7.1 and using E1000 hardware that has the time, I would appreciate any testing you can do. This has an important fix for SuperMicro servers but any regression test of the code would be helpful. Backup the contents of /usr/src/sys/dev/e1000 and then overwrite with this tarball. Send

Re: igb on a Nehalem system, buildworld stats

I have not seen a problem like this ever, what is the link partner of each NIC and if you switch the ports what happens? We have Nehalem's in the validation lab but I have not had an excuse to install on one so far, I guess now I do :) Jack On Thu, Jan 8, 2009 at 6:16 AM, Mars G Miro wrote: >

Re: igb on a Nehalem system, buildworld stats

other engineer in my group had an encounter with one like yours, I have two managers looking for me, hopefully I can find one. Jack On Thu, Jan 8, 2009 at 10:50 AM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel wrote: > > Well, I am at Intel you know, and even we d

Re: igb on a Nehalem system, buildworld stats

On Fri, Jan 9, 2009 at 12:02 AM, Mars G Miro wrote: > On Fri, Jan 9, 2009 at 2:50 AM, Mars G Miro > wrote: > > On Fri, Jan 9, 2009 at 2:33 AM, Jack Vogel wrote: > >> Well, I am at Intel you know, and even we don't seem to have any systems > >> with > &

Re: Driver for Intel 10GbE adapter

On Wed, Feb 11, 2009 at 3:21 PM, pluknet wrote: > Hi. > > 2009/2/12 Greg Rivers > > >: > > I'm trying to light an Intel 10GbE adapter in an HP DL380 G5 using very > > recent 7.1-STABLE amd64 with GENERIC kernel. I expected the ixbg(4) > driver > > to attach, but it does not. > > > > The labels

Re: Driver for Intel 10GbE adapter

Thu, 12 Feb 2009, pluknet wrote: > > You probably want to load ixgbe(4), not ixgb(4) (latter is afaik an older >> PCI-X version driver). The labels on the card are close to the description >> of ixgbe. Note, it's not in GENERIC. >> >> > On Wed, 11 Feb 2009, Jack

Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)

tems are being repurposed, jumping from 6.3 to 7.2. The same > system and its kin do not exhibit the symptom under 6.3-RELEASE-p13. The > symptoms appear under freebsd-updated 7.2-RELEASE GENERIC kernel with no > tuning. > > > > Previously, we've been using DCGDIS.EXE (from

Re: 82573 xfers pause, no watchdog timeouts, DCGDIS ineffective (7.2-R)

LOL, glad the problem has been resolved, and no thanks, I do not need to pursue this any further. I also want to thank Jeremy for his help and data!! Thanks guys and good evening, Jack On Thu, Nov 12, 2009 at 6:56 PM, Royce Williams wrote: > On Thu, Nov 12, 2009 at 2:18 PM, Royce Williams >

Re: bug with some em nics on RELENG_7

Hey Mike, Can you check if you see the same behavior on RELENG 8? There is a systemic problem having to do with when to enable interrupts that might be behind this. The em driver does not enable them until em_init_locked(), this is because until then its not ready to deal with a TX or RX interrup

Re: bug with some em nics on RELENG_7

Cool, so stable/7 will just need to be updated :) I need to catch up all the drivers in that stream actually. Thanks for testing!! Jack On Thu, Nov 19, 2009 at 8:58 AM, Mike Tancsa wrote: > At 07:29 PM 11/18/2009, Jack Vogel wrote: > >> Hey Mike, >> >> Can you c

Re: em interface slow down on 8.0R

I will look into this Hiroki, as time goes the older hardware does not always get test cycles like one might wish. Jack On Mon, Nov 30, 2009 at 12:04 AM, Hiroki Sato wrote: > Hi, > > I noticed that network connection of one of my boxes got > significantly slow just after upgrading it to 8.0R

Re: em interface slow down on 8.0R

t was working. To me this is further data on the need to have a frozen legacy version of em but the problem is which code to use and how to approach it. Can you give me more specifics on the box you have this installed on?? Regards, Jack On Mon, Nov 30, 2009 at 5:29 PM, Hiroki Sato wrote: &

Re: em interface slow down on 8.0R

debug, but wanted you to know that I have reproduced this. Jack On Wed, Dec 2, 2009 at 12:49 PM, Jack Vogel wrote: > We've run into a snag on this problem. The 82547 is a LOM only interface > and my validation engineer has only found two old systems that have it, > and neither o

Re: em interface slow down on 8.0R

The 82573, when onboard (LOM) is usually special, it is used by system management firmware. Go to the system BIOS and turn off management, see if that eliminates the periodic hang. Jack On Sat, Dec 5, 2009 at 9:27 PM, Hiroki Sato wrote: > John Nielsen wrote > in <1e3c66ea-a6d3-44d7-b28e-bf0

Re: State of igb on FreeBSD 8 stable?

:14AM -0800, alan bryan wrote: >> > I did some searching last night and found others using igb on Intel >> Cards having high interrupts and other strange issues and some comments to >> the effect that igb is soon going to have a lot of work done to it (I >> believe Jack Vo

Re: em interface slow down on 8.0R

No, it hasn't, I need time to look it over and be convinced of what he was doing. Jack On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers wrote: > looks like the patch mentioned in kern/141843 has not been applied to the > tree? > > On Tue, Jan 26, 2010 at 9:00 AM, Nick Rogers wrote: > > > Is it ad

Re: em interface slow down on 8.0R

issue? Regards, Jack On Tue, Jan 26, 2010 at 9:40 AM, Jack Vogel wrote: > No, it hasn't, I need time to look it over and be convinced of what he was > doing. > > Jack > > > > On Tue, Jan 26, 2010 at 9:14 AM, Nick Rogers wrote: > >> looks like the patch mentioned

Re: em interface slow down on 8.0R

e was an effort to bring the > support in but I don't know current status. If we have the > capability I would have to update all other drivers that can do > IPv6 checksum offloading/TSO for IPv6. > > > Regards, > > > > Jack > > > > > >

Re: em interface slow down on 8.0R

> On Tue, Jan 26, 2010 at 12:22:01PM -0800, Jack Vogel wrote: > > Well, what our testers do is assign BOTH an ipv4 and ipv6 address to an > > interface, > > then netperf runs over both, I don't know the internal details but I > assume > > both TCP > > and

  1   2   3   4   >