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@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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091130/b86b009d/attachment.pgp
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@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@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 >
Jack Vogel <jfvogel@gmail.com> wrote in <2a41acea0911301119j1449be58y183f2fe1d1112a68@mail.gmail.com>: jf> I will look into this Hiroki, as time goes the older hardware does not jf> always jf> get test cycles like one might wish. Thanks! Please let me know if you need more information. -- Hiroki -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20091201/0843867b/attachment.pgp