Comment 296 for bug 263555

Also, the locking in e1000e seems indeed to be dodgy, Thomas Gleixner reported this to be spotted by lockdep on his system with 2.6.27-rc7:

e1000e: Intel(R) PRO/1000 Network Driver - 0.3.3.3-k2
e1000e: Copyright (c) 1999-2008 Intel Corporation.
e1000e 0000:00:19.0: PCI INT A -> GSI 20 (level, low) -> IRQ 20
e1000e 0000:00:19.0: setting latency timer to 64
0000:00:19.0: eth0: (PCI Express:2.5GB/s:Width x1) 00:15:58:84:9f:94
0000:00:19.0: eth0: Intel(R) PRO/1000 Network Connection
0000:00:19.0: eth0: MAC: 4, PHY: 6, PBA No: ffffff-0ff
------------[ cut here ]------------
WARNING: at /home/tglx/work/kernel/git/linux-2.6/kernel/mutex.c:135 mutex_lock_nested+0x5c/0x26d()
Modules linked in: e1000e i915 drm ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 xt_state nf_conntrack ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp bnep rfcomm l2cap bluetooth autofs4 coretemp fuse sunrpc ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi scsi_transport_iscsi e1000 cpufreq_ondemand acpi_cpufreq ext2 dm_mirror dm_log dm_multipath dm_mod ipv6 kvm_intel kvm snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq arc4 snd_seq_device snd_pcm_oss ecb snd_mixer_oss snd_pcm video crypto_blkcipher snd_timer snd_page_alloc iwlagn i2c_i801 i2c_core firewire_ohci iwlcore mac80211 snd_hwdep firewire_core crc_itu_t iTCO_wdt iTCO_vendor_support rtc_cmos snd soundcore output ac battery pcspkr cfg80211 sr_mod thinkpad_acpi rfkill cdrom sg hwmon button joydev ata_piix ahci libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd [last unloaded: microcode]
Pid: 3484, comm: ip Not tainted 2.6.27-rc7-00006-gcec5eb7-dirty #89

Call Trace:
 <IRQ> [<ffffffff8103654d>] warn_on_slowpath+0x51/0x77
 [<ffffffff810572e9>] __lock_acquire+0x6ad/0x716
 [<ffffffff8129c285>] mutex_lock_nested+0x5c/0x26d
 [<ffffffffa04f85c2>] e1000_acquire_swflag_ich8lan+0x59/0x74 [e1000e]
 [<ffffffffa04fd753>] e1000e_read_kmrn_reg+0x18/0x62 [e1000e]
 [<ffffffffa04f8606>] e1000e_gig_downshift_workaround_ich8lan+0x29/0x71 [e1000e]
 [<ffffffffa0503e07>] e1000_intr_msi+0x46/0xec [e1000e]
 [<ffffffff81076fa5>] handle_IRQ_event+0x1e/0x51
 [<ffffffff81078295>] handle_edge_irq+0xe8/0x12b
 [<ffffffffa04fb312>] e1000e_update_mc_addr_list_generic+0x0/0x18e [e1000e]
 [<ffffffff8100ea88>] do_IRQ+0x6c/0xd4
 [<ffffffff8100c556>] ret_from_intr+0x0/0xf
 <EOI> [<ffffffffa04fb312>] e1000e_update_mc_addr_list_generic+0x0/0x18e [e1000e]
 [<ffffffffa04fb38f>] e1000e_update_mc_addr_list_generic+0x7d/0x18e [e1000e]
 [<ffffffffa04fb359>] e1000e_update_mc_addr_list_generic+0x47/0x18e [e1000e]
 [<ffffffffa0500ace>] e1000_set_multi+0xe2/0x11b [e1000e]
 [<ffffffff8121a1e8>] dev_set_rx_mode+0x21/0x2d
 [<ffffffff8121d1a6>] dev_open+0x85/0x9e
 [<ffffffff8121b172>] dev_change_flags+0xa6/0x15d
 [<ffffffff81262588>] devinet_ioctl+0x242/0x58a
 [<ffffffff812109a5>] sock_ioctl+0x1d8/0x1ff
 [<ffffffff810b80a9>] vfs_ioctl+0x21/0x6b
 [<ffffffff810b834c>] do_vfs_ioctl+0x259/0x272
 [<ffffffff81055a14>] trace_hardirqs_on_caller+0xf2/0x115
 [<ffffffff810b83b6>] sys_ioctl+0x51/0x73
 [<ffffffff8100bf4b>] system_call_fastpath+0x16/0x1b

Haven't looked into the code yet to see if this could possibly cause some deadly race access to NVRAM contents, but maybe some Intel people will know from top of their head.