Bug 118695 - [em] device polling + vlan causes panic on "em" interface
Summary: [em] device polling + vlan causes panic on "em" interface
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 7.0-BETA4
Hardware: Any Any
: Normal Affects Only Me
Assignee: Eric Joyner
URL:
Keywords: IntelNetworking
Depends on:
Blocks:
 
Reported: 2007-12-14 15:50 UTC by Travis Mikalson
Modified: 2018-05-28 19:41 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 Travis Mikalson 2007-12-14 15:50:00 UTC
Enabling device polling on my em1 interface which has a VLAN (vlan0) attached to it seems to trigger either a panic or the em1/vlan0 interface becoming unresponsive to the network (ifconfig em1 down/up remedies that). The system is fine otherwise with polling enabled on all the other interfaces (including em0) which are not using VLANs. It seems to panic the same with or without txcsum, rxcsum or vlanhwtag. But, VLAN_HWCSUM and VLAN_MTU are still enabled, ifconfig em1 -vlanmtu doesn't seem to have any effect and there doesn't seem to be any documented ifconfig option to disable VLAN_HWCSUM. The problem may or may not exist without VLAN_HWCSUM but unfortunately I have no way to turn VLAN_HWCSUM off.

Here are the affected NICs:
em0@pci0:6:0:0: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82546EB Dual Port Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
em1@pci0:6:0:1: class=0x020000 card=0x11798086 chip=0x10798086 rev=0x03 hdr=0x00
    vendor     = 'Intel Corporation'
    device     = '82546EB Dual Port Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet

When you trigger the problem you get one of these:
em1: discard frame w/o packet header

Followed shortly by a panic:
panic: sbflush_internal: cc 4294967156 || mb 0 || mbcnt 0
Uptime: 1h10m48s
Physical memory: 501 MB
Dumping 90 MB: 75 59 43 27 11
Dump complete
Automatic reboot in 15 seconds - press a key on the console to abort

I'm afraid I don't have debug symbols in my kernel so the crashdump isn't very useful, sorry. But this should be an easily reproduceable problem, so anybody with an "em" NIC around who cares to work on this shouldn't have a problem making their own crashdump within 5 minutes.

How-To-Repeat: Enable device polling on an "em" interface.
Attach a VLAN to an "em" interface.
Pass some traffic over the VLAN interface.
Comment 1 Remko Lodder freebsd_committer 2007-12-14 21:14:51 UTC
Responsible Changed
From-To: freebsd-bugs->jfv

Hi Jack, can you have a look at this please?
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2015-11-12 07:42:43 UTC
Reassign to erj@ for triage.  To submitter: is this issue still relevant?
Comment 3 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:41:47 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.