Freebsd-net

Popular Threads From Freebsd-net:

Current problem reports assigned to freebsd-net@FreeBSD.org

Juniper e3k with ports limitied to 100Mbit and re NICs on MSI MoBo: problems with duplex negotiation (Hetzner host provider discard FreeBSD support due this bug)

FreeBSD 8.2 and MPD5 stability issues

Vpn trouble

Igb watchdog timeouts

List Statistics

Total Threads: 2088
Total Posts: 3082

Phrases Used to Find This Thread

Page 1 of 1

29-07-2010 10:56 PM

Freebsd-net member admin is online now

User

29-07-2010 11:48 PM

Freebsd-net member admin is online now

User

30-07-2010 04:47 AM

Freebsd-net member admin is online now

User

30-07-2010 06:35 AM

Freebsd-net member admin is online now

User

30-07-2010 09:32 AM

Freebsd-net member admin is online now

User

30-07-2010 04:33 PM

Freebsd-net member admin is online now

User

30-07-2010 04:38 PM

Freebsd-net member admin is online now

User

30-07-2010 05:52 PM

Freebsd-net member admin is online now

User

30-07-2010 06:24 PM

Freebsd-net member admin is online now

User

#10

30-07-2010 07:17 PM

Freebsd-net member admin is online now

User

#11

03-01-2011 09:02 PM

Freebsd-net member admin is online now

User

#12

05-01-2011 03:57 AM

Freebsd-net member admin is online now

User

#13

06-01-2011 05:20 AM

Freebsd-net member admin is online now

User

#14

06-01-2011 06:39 AM

Freebsd-net member admin is online now

User

#15

13-01-2011 03:56 PM

Freebsd-net member admin is online now

User

#16

13-01-2011 06:27 PM

Freebsd-net member admin is online now

User

#17

13-01-2011 09:42 PM

Freebsd-net member admin is online now

User

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 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-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 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 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 *
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. Seeing a similar thing here, if we can help diagnose let us know.

Regards
Steve
----- Original Message -----
Sent: Thursday, July 29, 2010 10:56 PM
Subject: 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.

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to .

_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe.
Try the code from STABLE/8 or HEAD if you would please, if you have
questions
of what or how let me know.

Jack

On Thu, Jul 29, 2010 at 3:48 PM, Steven Hartland <>wrote:

> Seeing a similar thing here, if we can help diagnose let us know.
>
> Regards
> Steve
> ----- Original Message ----- From: "Robin Sommer" <>
> To: "freebsd-net"
> Sent: Thursday, July 29, 2010 10:56 PM
> Subject: 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.
>>
>
>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to .
>
>
> _______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. Hi,

the same was for me untill i upgraded BIOS up to the latest one
available from the MB vendor site

i run: FreeBSD 8.1-RELEASE amd64

on: Base Board Information
Manufacturer: Supermicro
Product Name: X8SIL-F
Version: 0123456789

BIOS Information
Vendor: American Megatrends Inc.
Version: 1.1
Release Date: 05/27/2010

with external quad port ethernet card
igb0@pci0:3:0:0: class=0x020000
card=0xa02b8086
chip=0x10e88086
rev=0x01
hdr=0x00
vendor = 'Intel Corporation'
device = 'Unknown (Unknown)'

this MB is the second one i was trying, several days ago i asked to
change it because of two onboard em(4) nics which worked unstable and
any load were hanging them out up to reboot

that time nothing helped (no one version of OS and bios upgrade), bUt
igb(4) was working perfectly

after the change the picture turned around until bios update and now
i'm still unable to make them (no em(4) nither igb(4)) to hang :) and
close to conclude the problem was in bios ...

but anyway, now i'm CVS-ing to RELENG_8 :)

--
Zeus V. Panchenko
IT Dpt., IBS ltd GMT+2 (EET)

Jack Vogel () [10.07.30 06:49] wrote:
> Try the code from STABLE/8 or HEAD if you would please, if you have
> questions
> of what or how let me know.
>
> Jack
---end quoted text---
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. Just the changes in sys/dev/e1000 required or are there any other dependencies?

Regards
Steve
----- Original Message -----
From: Jack Vogel
To: Steven Hartland
Cc: Robin Sommer ; freebsd-net
Sent: Friday, July 30, 2010 4:47 AM
Subject: Re: igb watchdog timeouts

Try the code from STABLE/8 or HEAD if you would please, if you have questions
of what or how let me know.

Jack

================================================
This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it.

In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337
or return the E.mail to .
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. I believe so, let me verify that for sure on a system in our validation lab
this morning,
stay tuned....

Jack

On Fri, Jul 30, 2010 at 1:32 AM, Steven Hartland <>wrote:

> Just the changes in sys/dev/e1000 required or are there any other
> dependencies?
>
> Regards
> Steve
>
> ----- Original Message -----
> *From:* Jack Vogel <>
> *To:* Steven Hartland <>
> *Cc:* Robin Sommer <> ; freebsd-net
> *Sent:* Friday, July 30, 2010 4:47 AM
> *Subject:* Re: igb watchdog timeouts
>
> Try the code from STABLE/8 or HEAD if you would please, if you have
> questions
> of what or how let me know.
>
> Jack
>
>
> ================================================
> This e.mail is private and confidential between Multiplay (UK) Ltd. and the
> person or entity to whom it is addressed. In the event of misdirection, the
> recipient is prohibited from using, copying, printing or otherwise
> disseminating it or any information contained in it.
>
> In the event of misdirection, illegible or incomplete transmission please
> telephone +44 845 868 1337
> or return the E.mail to .
>
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. On Fri, Jul 30, 2010 at 08:35 +0300, Zeus V Panchenko wrote:

> the same was for me untill i upgraded BIOS up to the latest one
> available from the MB vendor site

I'm going to try the driver from 8-STABLE, as suggested by Jack
(thanks!), but for the record, I've already updated the BIOS and I'm
still seeing the timeouts.

Robin

--
Robin Sommer * Phone +1 (510) 666-2886 *
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. Robin Sommer () [10.07.30 18:38] wrote:
> I'm going to try the driver from 8-STABLE, as suggested by Jack
> (thanks!), but for the record, I've already updated the BIOS and I'm
> still seeing the timeouts.

just have CVS-ed to RELENG_8, recompiled the kernel and loaded the
drivers em(4) and igb(4) - works! :)

i was testing them with nc(1)

server side: nc -u -l 55555 > /dev/null
client side: nc -u 55555 < /dev/random

but the maximum i was able to get was 500Mbit/s

btw, is it correct to test it such way?

--
Zeus V. Panchenko
IT Dpt., IBS ltd GMT+2 (EET)
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. At 12:52 PM 7/30/2010, Zeus V Panchenko wrote:

>but the maximum i was able to get was 500Mbit/s
>
>btw, is it correct to test it such way?

Try using the tools in /usr/src/tools/tools/netrate

you can generate a lot more traffic this way.

---Mike

>--
>Zeus V. Panchenko
>IT Dpt., IBS ltd GMT+2 (EET)
>_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. Mike Tancsa () [10.07.30 20:25] wrote:
>
> Try using the tools in /usr/src/tools/tools/netrate
>
> you can generate a lot more traffic this way.
>

thank you Mike,

it works! :)

netsend 10.11.0.2 55555 1000 200000 60
Sending packet of payload size 1000 every 0.000005000s for 60 seconds

start: 1280511835.000000000
finish: 1280511895.000014942
send calls: 11999990
send errors: 0
approx send rate: 199999
approx error rate: 0
waited: 13557673
approx waits/sec: 225961
approx wait rate: 1

--
Zeus V. Panchenko
IT Dpt., IBS ltd GMT+2 (EET)
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. 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 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-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 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 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 *
ICSI/LBNL * Fax +1 (510) 666-2956 * www.icir.org
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. I get them as well... on my em devices. I was just thinking of
upgrading to a dual port igb I have kicking around, but your email is
not encouraging. :)

# grep watchdog /var/log/message
Jan 2 21:13:38 turtle kernel: em5: watchdog timeout -- resetting
Jan 3 04:31:37 turtle kernel: em4: watchdog timeout -- resetting
Jan 3 09:41:09 turtle kernel: em4: watchdog timeout -- resetting
Jan 3 12:05:05 turtle kernel: em4: watchdog timeout -- resetting
Jan 4 10:29:58 turtle kernel: em1: watchdog timeout -- resetting
Jan 4 15:36:19 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 16:09:51 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 18:28:48 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 18:33:41 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 19:18:35 turtle kernel: em4: watchdog timeout -- resetting
Jan 4 19:26:21 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 19:27:25 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 19:33:33 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 19:40:54 turtle kernel: em5: watchdog timeout -- resetting
Jan 4 19:50:45 turtle kernel: em5: watchdog timeouts = 129
Jan 4 19:54:33 turtle kernel: em0: watchdog timeouts = 0
Jan 4 19:54:39 turtle kernel: em1: watchdog timeouts = 13
Jan 4 19:54:41 turtle kernel: em2: watchdog timeouts = 0
Jan 4 19:54:44 turtle kernel: em3: watchdog timeouts = 0
Jan 4 19:54:46 turtle kernel: em4: watchdog timeouts = 121

stats info:
Jan 4 19:50:45 turtle kernel: em5: Excessive collisions = 0
Jan 4 19:50:45 turtle kernel: em5: Sequence errors = 0
Jan 4 19:50:45 turtle kernel: em5: Defer count = 0
Jan 4 19:50:45 turtle kernel: em5: Missed Packets = 2280947
Jan 4 19:50:45 turtle kernel: em5: Receive No Buffers = 0
Jan 4 19:50:45 turtle kernel: em5: Receive Length Errors = 0
Jan 4 19:50:45 turtle kernel: em5: Receive errors = 0
Jan 4 19:50:45 turtle kernel: em5: Crc errors = 0
Jan 4 19:50:45 turtle kernel: em5: Alignment errors = 0
Jan 4 19:50:45 turtle kernel: em5: Collision/Carrier extension errors = 0
Jan 4 19:50:45 turtle kernel: em5: RX overruns = 115
Jan 4 19:50:45 turtle kernel: em5: watchdog timeouts = 129
Jan 4 19:50:45 turtle kernel: em5: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK
MSIX IRQ = 0
Jan 4 19:50:45 turtle kernel: em5: XON Rcvd = 0
Jan 4 19:50:45 turtle kernel: em5: XON Xmtd = 0
Jan 4 19:50:45 turtle kernel: em5: XOFF Rcvd = 0
Jan 4 19:50:45 turtle kernel: em5: XOFF Xmtd = 0
Jan 4 19:50:45 turtle kernel: em5: Good Packets Rcvd = 23188157965
Jan 4 19:50:45 turtle kernel: em5: Good Packets Xmtd = 42184614153
Jan 4 19:50:45 turtle kernel: em5: TSO Contexts Xmtd = 52043
Jan 4 19:50:45 turtle kernel: em5: TSO Contexts Failed = 0

debug info:
Jan 4 19:51:15 turtle kernel: em5: Adapter hardware address = 0xc51ca420
Jan 4 19:51:15 turtle kernel: em5: CTRL = 0x140248 RCTL = 0x8002
Jan 4 19:51:15 turtle kernel: em5: Packet buffer = Tx=20k Rx=12k
Jan 4 19:51:15 turtle kernel: em5: Flow control watermarks high = 10240
low = 8740
Jan 4 19:51:15 turtle kernel: em5: tx_int_delay = 66, tx_abs_int_delay = 66
Jan 4 19:51:15 turtle kernel: em5: rx_int_delay = 32, rx_abs_int_delay = 66
Jan 4 19:51:15 turtle kernel: em5: fifo workaround = 0,
fifo_reset_count = 0
Jan 4 19:51:15 turtle kernel: em5: hw tdh = 180, hw tdt = 180
Jan 4 19:51:15 turtle kernel: em5: hw rdh = 708, hw rdt = 707
Jan 4 19:51:15 turtle kernel: em5: Num Tx descriptors avail = 2048
Jan 4 19:51:15 turtle kernel: em5: Tx Descriptors not avail1 = 0
Jan 4 19:51:15 turtle kernel: em5: Tx Descriptors not avail2 = 0
Jan 4 19:51:15 turtle kernel: em5: Std mbuf failed = 0
Jan 4 19:51:15 turtle kernel: em5: Std mbuf cluster failed = 0
Jan 4 19:51:15 turtle kernel: em5: Driver dropped packets = 0
Jan 4 19:51:15 turtle kernel: em5: Driver tx dma failure in encap = 0

# pciconf -lv
em0@pci0:5:0:0: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82571EB Gigabit Ethernet Controller'
class = network
subclass = ethernet
em1@pci0:5:0:1: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82571EB Gigabit Ethernet Controller'
class = network
subclass = ethernet
em2@pci0:6:0:0: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82571EB Gigabit Ethernet Controller'
class = network
subclass = ethernet
em3@pci0:6:0:1: class=0x020000 card=0x10a48086 chip=0x10a48086 rev=0x06
hdr=0x00
vendor = 'Intel Corporation'
device = '82571EB Gigabit Ethernet Controller'
class = network
subclass = ethernet
em4@pci0:13:0:0: class=0x020000 card=0x108c15d9 chip=0x108c8086
rev=0x03 hdr=0x00
vendor = 'Intel Corporation'
device = '82573E Intel Corporation 82573E Gigabit Ethernet
Controller (Copper)'
class = network
subclass = ethernet
em5@pci0:15:0:0: class=0x020000 card=0x109a15d9 chip=0x109a8086
rev=0x00 hdr=0x00
vendor = 'Intel Corporation'
device = '82573L Intel PRO/1000 PL Network Adaptor'
class = network
subclass = ethernet

# uname -a
FreeBSD turtle 7.2-STABLE FreeBSD 7.2-STABLE #0: Thu Sep 24 08:43:29 PDT
2009 root@turtle:/usr/obj/usr/src/sys/TURTLE i386

I know... old kernel, but the box has been pretty stable, and in 2009 I
asked the list about these watchdogs, upgraded from 7.0 and the problem
didn't go away, so I don't think kernel upgrades help...

Rudy

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 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-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 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 card=0x10a915d9
>> chip=0x10a98086 rev=0x02 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82575EB Gigabit Backplane Connection'
>> class = network
>> subclass = ethernet
>> [...]
>>
>
>

_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. On Mon, 2011-01-03 at 13:02 -0800, 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 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-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 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 card=0x10a915d9
> > chip=0x10a98086 rev=0x02 hdr=0x00
> > vendor = 'Intel Corporation'
> > device = '82575EB Gigabit Backplane Connection'
> > class = network
> > subclass = ethernet
> > [...]
>

I don't suppose you have ASPM enabled? If so, turn it off. That seemed
to make things go much better here at Yahoo.

Sean

_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. >
> I don't suppose you have ASPM enabled? If so, turn it off. That seemed
> to make things go much better here at Yahoo.
>
> Sean
>

I can get in to the data center later this week and check the BIOS. I
can't control that from freebsd, can I? I may as well build a new
kernel as long as I am rebooting!

Rudy
_______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. 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
> < > 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: > 1.9.5> port 0x2000-0x201f mem
> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff
> irq 16 at device 0.0 on pci4
> igb0: [FILTER]
> igb0: Ethernet address: 00:30:48:9e:22:00
> igb1: > 1.9.5> port 0x2020-0x203f mem
> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 card=0x10a915d9
> chip=0x10a98086 rev=0x02 hdr=0x00
> vendor = 'Intel Corporation'
> device = '82575EB Gigabit Backplane Connection'
> class = network
> subclass = ethernet
> [...]
>
>
> _______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. 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
<>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 <
> > 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
>>>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-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
>>>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 card=0x10a915d9
>>>> chip=0x10a98086 rev=0x02 hdr=0x00
>>>> vendor = 'Intel Corporation'
>>>> device = '82575EB Gigabit Backplane Connection'
>>>> class = network
>>>> subclass = ethernet
>>>> [...]
>>>>
>>>
>> _______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe. 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=0x020000 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
> < > 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
>> <
>> > 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: >> 1.9.5> port 0x2000-0x201f mem
>> 0xfc940000-0xfc95ffff,0xfc920000-0xfc93ffff,0xfc900000-0xfc903fff
>> irq 16 at device 0.0 on pci4
>> igb0: [FILTER]
>> igb0: Ethernet address: 00:30:48:9e:22:00
>> igb1: >> 1.9.5> port 0x2020-0x203f mem
>> 0xfc980000-0xfc99ffff,0xfc960000-0xfc97ffff,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=0x020000 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=0x020000 card=0x10a915d9
>> chip=0x10a98086 rev=0x02 hdr=0x00
>> vendor = 'Intel Corporation'
>> device = '82575EB Gigabit Backplane Connection'
>> class = network
>> subclass = ethernet
>> [...]
>>
>>
>> _______________________________________________
___________________________________________________

Posted on the Freebsd-net mailing list. Go to http://lists.freebsd.org/mailman/listinfo/freebsd-net to subscribe.

#18

13-01-2011 09:47 PM

Freebsd-net member admin is online now

User

#19

13-01-2011 09:49 PM

Freebsd-net member admin is online now

User

#20

14-01-2011 04:54 AM

Freebsd-net member admin is online now

User

Page 1 of 1

NewsArc Lists | Culture Pages | Computing Archive | Media-Pages

Link to this page on your blog or website by copying the HTML code below and pasting it into your site:

Next Thread »