em interface slow down on 8.0R

Jack Vogel jfvogel at gmail.com
Mon Nov 30 19:50:39 UTC 2009


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 <hrs at freebsd.org> wrote:

> Hi,
>
>  I noticed that network connection of one of my boxes got
>  significantly slow just after upgrading it to 8.0R.  The box has an
>  em0 (82547EI) and worked fine with 7.2R.
>
>  The symptoms are:
>
>  - A ping to a host on the same LAN takes 990ms RTT, it reduces
>   gradually to around 1ms, and then it returns to around 1s.  The
>   rate was about 2ms/ping.
>
>  - The response is quite slow, but no packet loss and network services
>   on the box seem to work fine as far as I can check.  There does not
>   seem interrupt storm according to "vmstat -i".  No error message
>   such as "watchdog timeout" appears.
>
>  Any ideas to narrow down the cause?  It maybe a linkup problem with a
>  specific model of hub like full-duplex/half-duplex mismatch, but the
>  link is "1000baseT <full-duplex>" and setting it manually did not
>  solve it.  I think it is certain that upgrading to 8.0R triggered it,
>  at least.
>
>  Another box with an em interface works fine after upgrading to 8.0R.
>  It has a different chip (82573E).
>
>  Details of the em interface and vmstat -i are the following:
>
>  em0 at pci0:1:1:0: class=0x020000 card=0x302c8086 chip=0x10198086 rev=0x00
> hdr=0x00
>    vendor     = 'Intel Corporation'
>    device     = 'Gigabit Ethernet Controller (LOM) (82547EI)'
>    class      = network
>    subclass   = ethernet
>
>  Adapter hardware address = 0xc42e1424
>  em0: CTRL = 0x183c0241 RCTL = 0x8002
>  em0: Packet buffer = Tx=10k Rx=30k
>  em0: Flow control watermarks high = 28672 low = 27172
>  em0: tx_int_delay = 66, tx_abs_int_delay = 66
>  em0: rx_int_delay = 0, rx_abs_int_delay = 66
>  em0: fifo workaround = 0, fifo_reset_count = 0
>  em0: hw tdh = 49, hw tdt = 49
>  em0: hw rdh = 238, hw rdt = 187
>  em0: Num Tx descriptors avail = 250
>  em0: Tx Descriptors not avail1 = 0
>  em0: Tx Descriptors not avail2 = 0
>  em0: Std mbuf failed = 0
>  em0: Std mbuf cluster failed = 0
>  em0: Driver dropped packets = 0
>  em0: Driver tx dma failure in encap = 0
>
>  dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14
>  dev.em.0.%driver: em
>  dev.em.0.%location: slot=1 function=0 handle=\_SB_.PCI0.P0P2.TANA
>  dev.em.0.%pnpinfo: vendor=0x8086 device=0x1019 subvendor=0x8086
> subdevice=0x302c class=0x020000
>  dev.em.0.%parent: pci1
>  dev.em.0.debug: -1
>  dev.em.0.stats: -1
>  dev.em.0.rx_int_delay: 0
>  dev.em.0.tx_int_delay: 66
>  dev.em.0.rx_abs_int_delay: 66
>  dev.em.0.tx_abs_int_delay: 66
>  dev.em.0.rx_processing_limit: 100
>  dev.em.0.wake: 0
>
>  % vmstat -i
>  interrupt                          total       rate
>  irq4: uart0                         3585          3
>  irq14: ata0                         1811          1
>  irq15: ata1                          112          0
>  irq16: uhci0 uhci3                    15          0
>  irq18: em0 uhci2+                  92457         99
>  irq19: uhci1                           1          0
>  irq23: ehci0                           2          0
>  cpu0: timer                      1849981       1997
>  cpu1: timer                      1849961       1997
>  Total                            3797925       4101
>
> -- Hiroki
>


More information about the freebsd-stable mailing list