Re: Supermicro Bladeserver
On Wed, Jan 12, 2011 at 03:13 -, you wrote: Out of interest what change was that? As what seems to have been a left-over from a debugging session a long time ago, I had MSI disabled in loader.conf. That's not supported by the driver. So simply reenabling that solved my problem. Robin -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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: igb watchdog timeouts
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: Intel(R) PRO/1000 Network Connection version - 1.9.5 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: Intel(R) PRO/1000 Network Connection version - 1.9.5 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 [...] -- Robin Sommer * Phone +1 (510) 722-6541 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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
igb watchdog timeouts
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: Intel(R) PRO/1000 Network Connection version - 1.9.5 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: Intel(R) PRO/1000 Network Connection version - 1.9.5 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 [...] -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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: Crashes with ixgbe on FreeBSD 8
On Tue, May 25, 2010 at 12:03 -0700, I wrote: /usr/src/sys/dev/ixgbe/ixgbe.c:833: warning: implicit declaration of function 'drbr_needs_enqueue' So, I've now simply copied that function over and, indeed, that not only compiles but gives me a working 2.2.0 driver, enabling me to capture traffic in a stable fashion as far as I can tell so far ... My question: is simply pasting this function into RELEASE a reasonable fix, or am I missing out on further changes and am thus getting myself into trouble in some form? Robin -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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: Crashes with ixgbe on FreeBSD 8
On Wed, May 19, 2010 at 09:47 -0700, you wrote: issue this morning but I will try and check the change into HEAD this afternoon then you will able to just pull that and the driver will drop into 8 REL with no problem. I'm trying to compile 2.2.0 with RELEASE, but I get the following error: /usr/src/sys/dev/ixgbe/ixgbe.c: In function 'ixgbe_mq_start_locked': /usr/src/sys/dev/ixgbe/ixgbe.c:833: warning: implicit declaration of function 'drbr_needs_enqueue' /usr/src/sys/dev/ixgbe/ixgbe.c:833: warning: nested extern declaration of 'drbr_needs_enqueue' Is there an easy way to get around this? Thanks, Robin -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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: Crashes with ixgbe on FreeBSD 8
On Tue, May 18, 2010 at 22:28 -0700, you wrote: Yes, download the latest code, oh hmmm, can you install STABLE, because there's one small issue that will cause a problem on 8 REL, but if that's a big problem I can also give you a patch so it will work. Jack, thanks for the reply. I could upgrade to STABLE but I as I have quite a number of machines in my setup (and not not all of them need the driver) I would prefer to stay with RELEASE if that is an option. So if you could send me a patch, that would be very helpful. What I'd like to see you try is the newest code that I checked into HEAD today, that's what I am planning for 8.1 and I want as much testing as I can get anyway. Sure, I'd be happy to try that. Can this be back-ported to RELEASE as well or does it need HEAD? Thanks! Robin -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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
Crashes with ixgbe on FreeBSD 8
Hi all, I'm running into crashes with the ixgbe driver on a FreeBSD 8.0-RELEASE system equipped with an Intel X520-SR2 (and using a Supermicro X8DTU-F motherboard). I was wondering whether somebody might have seen this before. I updated the driver to the latest version I found on Intel's download page, which is 2.0.1. However, the moment I run tcpdump on my ix1 interface (which is connected to a switch's monitor port), I see almost immediate crashes of the kind below. Sometimes tcpdump outputs a few 10s of packets before the system crashes, but most of the time it doesn't even get that far. I saw that 8.0-STABLE comes with a more recent version of the driver. Any chance that that might fix the problem? Any other thoughts? Thanks, Robin - cut --- syslog from crash: May 14 16:42:24 bart kernel: ix1: link state changed to UP May 14 16:43:34 bart kernel: ix1: promiscuous mode enabled May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: Fatal trap 12: page fault while in kernel mode May 14 16:43:35 bart kernel: cpuid = 5; apic id = 05 May 14 16:43:35 bart kernel: fault virtual address = 0x80403d38d3b8 May 14 16:43:35 bart kernel: fault code = supervisor read data, page not present May 14 16:43:35 bart kernel: instruction pointer= 0x20:0x808437fe May 14 16:43:35 bart kernel: May 14 16:43:35 bart kernel: stack pointer = 0x28:0xff82b34d5970 May 14 16:43:35 bart kernel: frame pointer = 0x28:0xff82b34d5980 May 14 16:43:35 bart kernel: code segment = base 0x0, limit 0xf, type 0x1b May 14 16:43:35 bart kernel: = DPL 0, pres 1, long 1, def32 0, gran 1 May 14 16:43:35 bart kernel: processor eflags = interrupt enabled, Driver initalization: ix0: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.0.1 port 0xec00-0xec1f mem 0xf8f8-0xf8ff,0xf8f7c006 ix0: Using MSIX interrupts with 33 vectors ix0: [ITHREAD] [...] ix0: Ethernet address: 00:1b:21:55:7f:d8 ix0: PCI Express Bus: Speed 5.0Gb/s Width x8 ix1: Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 2.0.1 port 0xe880-0xe89f mem 0xf8e8-0xf8ef,0xf8e7c006 ix1: Using MSIX interrupts with 33 vectors ix1: [ITHREAD] [...] ix1: Ethernet address: 00:1b:21:55:7f:d9 ix1: PCI Express Bus: Speed 5.0Gb/s Width x8 ifconfig ix1 ix1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=5bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO ether 00:1b:21:55:7f:d9 media: Ethernet autoselect (10Gbase-SR full-duplex) status: active -- Robin Sommer * Phone +1 (510) 666-2886 * ro...@icir.org ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.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: BPF problems on FreeBSD 7.0
On Mon, Jul 14, 2008 at 14:44 +0100, Bruce M. Simpson wrote: One place to start might be: netstat -B output in 7.x (I *think* this got MFCed), this will let us see what the drop count is for the Bro process, and what the flags are for the open BPF descriptors in the system. Thanks for the suggestion. Here's the netstat -B output at the time it has stalled (after about 6 hours of working normally): Pid Netif Flags Recv Drop Match Sblen Hblen Command 14557 nxge0 p--s--- 2162189525 32514465 42815457 4194248 4194258 bro Top shows: PID USERNAME THR PRI NICE SIZERES STATE C TIME WCPU COMMAND 14557 bro1 -580272M 267M5 25:53 0.00% bro A few minutes after starting the process, when Bro was still working fine, a netstat -B output was: # netstat -B Pid Netif Flags Recv Drop Match Sblen Hblen Command 14557 nxge0 p--s--- 4779235 0 94967 0 0 bro Thanks, Robin -- Robin Sommer * Phone +1 (510) 666-2886 * [EMAIL PROTECTED] ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BPF problems on FreeBSD 7.0
On Tue, Jul 15, 2008 at 14:25 -0700, you wrote: Thanks for the suggestion. Here's the netstat -B output at the time it has stalled (after about 6 hours of working normally): [...] at your rate of receiving packets, it passed that value about 2 minutes before this snapshot was taken.. Sorry, I wasn't precise: the process stalled after about 6 hours but the netstat output is actually from much later (the next day in fact, because it stalled latet a night) when it was still in that state. Robin -- Robin Sommer * Phone +1 (510) 666-2886 * [EMAIL PROTECTED] ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
BPF problems on FreeBSD 7.0
Hi all, we're seeing some strange effects with our libpcap-based application (the Bro network intrusion detection system) on a FreeBSD 7-RELEASE system. As the application has always been running fine on 6.x, we're wondering whether this might be triggered by any of the changes that went into 7. The problem is that the Bro process, after running fine for a few hours or so, regularly stalls completely; the process seems to enter some odd state, using 0% CPU and with top showing only an empty field in the STATE column. We saw this effect with a Neterion network card and first thought it might be a driver problem. After switching to an Intel card, we see something slightly different: now the process doesn't stall completely anymore but it still gets to some point at which it stops receiving packets from libpcap. We haven't yet seen these problems with any other libpcap application. The only difference between Bro and most other libpcap applications that I can think of right now, is that Bro is using select() on the file descriptor. However, with a small test applicaton which mimics Bro's way of using libpcap, we couldn't reproduce the problem so far either. With the Neterion card, we have also tried disabling LRO and MSI explicitly but to no avail. Again, this is all with a Bro installation that works fine when running FreeBSD 6.x (we haven't run 6.x on the same boxes but we see the problems on two separate machines running FreeBSD 7). I'm wondering whether anybody here has seen something similar or might have an idea where to start looking for the cause. Any ideas? Thanks, Robin -- Robin Sommer * Phone +1 (510) 666-2886 * [EMAIL PROTECTED] ICSI/LBNL* Fax +1 (510) 666-2956 * www.icir.org ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
