if_em locked up under high network load in -CURRENT

Tai-hwa Liang avatar at mmlab.cse.yzu.edu.tw
Mon Jun 7 09:38:14 GMT 2004


  It seems that recent kernel changes breaks the em driver when the network
load is high enough(rsync a directory contains +150MB files). The onboard
Intel PRO/1000 just doesn't respond to network request such like ping or DHCP
lease renewal -- all interrupt related to em0 was stopped since the lockup
took place. However, the system is still workable(can compile/edit code, only
em0 hangs) at this moment. Manually unload/reload the if_em kernel module
doesn't solve this problem.

  Last known good kernel was cvsup'ed on Apr-28-2004, the problem occurred
since May-09-2004(cvsup/kernel build on a weekly basis, not sure about
whether it worked between Apr-28 and May-09 or not).

  Since booting w/o ACPI support solved this problem, I'm wondering
about whether recent PCI/ACPI changes correlated to this lockup.
The module was built without polling support; however, the lockup always
happens disregarding device polling support is compiled in or not.

---------------------- vmstat -i ----------------------------
interrupt                          total       rate
irq0: clk                          93968         99
irq1: atkbd0                        4227          4
irq4: cbb0 em0++                  166447        176
irq6: cbb1 pcm0                   133702         41
irq7: ppc0                             1          0
irq8: rtc                         120281        127
irq9: acpi0                          301          0
irq10: uhci1                         200          0
irq11: ath0 uhci2+                     2          0
irq12: psm0                           21          0
irq13: npx0                            1          0
irq14: ata0                         7425          7
irq15: ata1                           55          0
Total                             392929        417

For complete dmesg of this Thinkpad T40, please consult:


(the reason why em0 was detached and re-attached twice is that I've tried to
see whether kldunload/kldload if_em again can workaround this problem without

More information about the freebsd-current mailing list