Bug 147989 - [em] em Receive errors / CRC Errors / Alignment Errors
Summary: [em] em Receive errors / CRC Errors / Alignment Errors
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 8.1-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: jfv
URL:
Keywords: IntelNetworking
Depends on:
Blocks:
 
Reported: 2010-06-19 05:20 UTC by Curtis Hacker
Modified: 2015-06-30 17:37 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Curtis Hacker 2010-06-19 05:20:01 UTC
I'm getting huge Ierrs through netstat -i on my em device.

I really never update the machine, but I guess since last kernel/world update this happened. I really can't be very descriptive in that area since I'm not exactly sure when. I just tried to do some portupgrades today and noticed the awful receive speed of 15kb/sec.

I have a custom kernel with just altq / hz=1000 / polling enabled. Everything else is generic.

Make.conf:
CPUTYPE?=pentium4.

I've disabled polling.. hasn't helped.
I've removed rxcsum / txcsum.. hasn't helped.
Disabling pf rules hasn't helped.
Unloading pf module hasn't helped.
I've removed all sysctl tweaks of buffers etc.. nada
I've tried :
/boot/loader.conf
hw.em.rxd=4096
hw.em.txd=4096
hw.em.rx_process_limit="-1"
dev.em.0.rx_int_delay: 250
dev.em.0.tx_int_delay: 250
dev.em.0.rx_abs_int_delay: 250
dev.em.0.tx_abs_int_delay: 250

Still hasn't helped.
I've just recently compiled the smp em module from http://people.yandex-team.ru/~wawa/

I really can't seem to debug this machine. It gets HORRIBLE receiving.. yet tx is perfectly fine. Unfortunatly I can't debug the machine in person its on a colo out of state, but I assume the switch / cable is fine.

pciconf -lcv
em0@pci0:0:8:0: class=0x020000 card=0x004e8086 chip=0x100e8086 rev=0x02 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = 'Gigabit Ethernet Controller (82540EM)'
    class      = network
    subclass   = ethernet
    cap 01[dc] = powerspec 2  supports D0 D3  current D0
    cap 07[e4] = PCI-X supports 2048 burst read, 1 split transaction
    cap 05[f0] = MSI supports 1 message, 64 bit

dmesg
em0: link state changed to UP
em0: Excessive collisions = 0
em0: Sequence errors = 0
em0: Defer count = 0
em0: Missed Packets = 0
em0: Receive No Buffers = 0
em0: Receive Length Errors = 0
em0: Receive errors = 240
em0: Crc errors = 289
em0: Alignment errors = 7
em0: Collision/Carrier extension errors = 0
em0: RX overruns = 0
em0: watchdog timeouts = 0
em0: RX MSIX IRQ = 0 TX MSIX IRQ = 0 LINK MSIX IRQ = 0
em0: XON Rcvd = 0
em0: XON Xmtd = 0
em0: XOFF Rcvd = 0
em0: XOFF Xmtd = 0
em0: Good Packets Rcvd = 10562
em0: Good Packets Xmtd = 10386
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-06-21 04:25:47 UTC
Responsible Changed
From-To: freebsd-i386->freebsd-net

Over to maintainer(s).
Comment 2 Andre Oppermann freebsd_committer 2010-08-23 15:30:51 UTC
Responsible Changed
From-To: freebsd-net->jfv

Over to maintainer.
Comment 3 Sean Bruno freebsd_committer 2015-06-30 17:37:20 UTC
em(4) has been significantly updated in 10.2r and current.  If this is still a problem in your case (might be using lem(4) instead of em(4)), reopen this issue for further research.