[Bug 205706] Watchdog timeout on em driver under heavy traffic on a bridge configuration

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Wed Dec 30 00:02:13 UTC 2015


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205706

            Bug ID: 205706
           Summary: Watchdog timeout on em driver under heavy traffic on a
                    bridge configuration
           Product: Base System
           Version: 11.0-CURRENT
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: avilamarquezalvaro2015 at gmail.com
                CC: freebsd-amd64 at FreeBSD.org
                CC: freebsd-amd64 at FreeBSD.org

The em driver hangs with following error:

em1: Watchdog timeout Queue[0]-- resetting
Interface is RUNNING and ACTIVE
em1: TX Queue 0 ------
em1: hw tdh = 379, hw tdt = 315
em1: Tx Queue Status = -2147483648
em1: TX descriptors avail = 64
em1: Tx Descriptors avail failure = 816926
em1: RX Queue 0 ------
em1: hw rdh = 149, hw rdt = 145
em1: RX discarded packets = 0
em1: RX Next to Check = 146
em1: RX Next to Refresh = 145
em1: link state changed to DOWN
em1: link state changed to UP

This is in a machine with dual Intel Gigabit NICs set up as a bridge with
11-CURRENT-amd64-20151217 base r292413. I suspect this will also happen if only
one of the NICs uses em driver.

This happens under heavy traffic conditions (>= 10MiBytes/sec in both
directions of the bridge) after 1-4 hours. Once the watchdog timeouts, the link
won't pass any more packets, it will detect cable disconn/conn. ifconfig
down/ifconfig up won't help at all, a reboot is necessary.

I tried the what is suggested here: bug #200221 (ifconfig -tso -vlanhwtso in
both intfs) the watchdog doesn't timeout anymore but after a similar period of
time the link becomes unusable (a ping loses ~ 90% packets).

This was also tested on 10.2-CURRENT with identical results

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-bugs mailing list