Bug 656751

Summary:	cannot remove igb module
Product:	Red Hat Enterprise Linux 5	Reporter:	Chao Yang <chayang>
Component:	udev	Assignee:	Harald Hoyer <harald>
Status:	CLOSED NOTABUG	QA Contact:	qe-baseos-daemons
Severity:	medium	Docs Contact:
Priority:	low
Version:	5.6	CC:	alex.williamson, ashish.n.shah, ddutile, ehabkost, jiajun.xu, jkt, john.cooper, juzhang, kcao, llim, lmiksik, michen, mkenneth, narendra_k, neepatel, psklenar, tburke, virt-maint, xin.li, xudong.hao, yang.z.zhang, yongkang.you, ypu
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	654208	Environment:
Last Closed:	2014-01-31 12:32:35 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	613892, 654208
Bug Blocks:	1049888

Comment 1 Chao Yang 2010-11-24 02:13:14 UTC

According to comments above, clone the bug to udev component, if it is in wrong component, please move this bug to the right component

Comment 2 Harald Hoyer 2010-11-24 11:02:07 UTC

I don't know of any mechanism in the udev package, which modprobes a module on removal.

Might be a hotplug script from another package...

Comment 3 Chao Yang 2011-01-06 08:42:36 UTC

[root@dhcp-66-83-36 ~]# modprobe -r igb
[root@dhcp-66-83-36 ~]# 
[root@dhcp-66-83-36 ~]# 
[root@dhcp-66-83-36 ~]# 
[root@dhcp-66-83-36 ~]# 
[root@dhcp-66-83-36 ~]# dmesg 
ACPI: PCI interrupt for device 0000:09:00.1 disabled
switch: port 1(eth0) entering disabled state
device eth0 left promiscuous mode
switch: port 1(eth0) entering disabled state
ACPI: PCI interrupt for device 0000:09:00.0 disabled
dca service started, version 1.8
802.1Q VLAN Support v1.8 Ben Greear <greearb>
All bugs added by David S. Miller <davem>
Intel(R) Gigabit Ethernet Network Driver - version 2.1.0-k2-1
Copyright (c) 2007-2009 Intel Corporation.
PCI: Enabling device 0000:09:00.0 (0000 -> 0002)
ACPI: PCI Interrupt 0000:09:00.0[A] -> Link [LN48] -> GSI 48 (level, high) -> IRQ 51
PCI: Setting latency timer of device 0000:09:00.0 to 64
igb 0000:09:00.0: 0 vfs allocated
igb 0000:09:00.0: Intel(R) Gigabit Ethernet Network Connection
igb 0000:09:00.0: eth0: (PCIe:2.5Gb/s:Width x4) 00:1b:21:36:79:f0
igb 0000:09:00.0: eth0: PBA No: e43709-003
igb 0000:09:00.0: Using MSI-X interrupts. 4 rx queue(s), 1 tx queue(s)
PCI: Enabling device 0000:09:00.1 (0000 -> 0002)
ACPI: PCI Interrupt 0000:09:00.1[B] -> Link [LN49] -> GSI 49 (level, high) -> IRQ 107
PCI: Setting latency timer of device 0000:09:00.1 to 64
igb 0000:09:00.1: 0 vfs allocated
igb 0000:09:00.1: Intel(R) Gigabit Ethernet Network Connection
igb 0000:09:00.1: eth1: (PCIe:2.5Gb/s:Width x4) 00:1b:21:36:79:f1
igb 0000:09:00.1: eth1: PBA No: e43709-003
igb 0000:09:00.1: Using MSI-X interrupts. 4 rx queue(s), 1 tx queue(s)
ADDRCONF(NETDEV_UP): eth0: link is not ready
device eth0 entered promiscuous mode
igb: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
switch: topology change detected, propagating
switch: port 1(eth0) entering forwarding state
[root@dhcp-66-83-36 ~]# lsmod | grep igb
igb                   128213  0 
8021q                  57937  1 igb
dca                    41605  1 igb

Comment 9 Surya Prabhakar 2011-06-08 06:29:12 UTC

Hi Harald, 
  I have seen this issue in Rhel6-snapshot4 timeframe.

On RHEL5.6-Snapshot4 , unload the igb driver and then reload igb driver with max_vfs option then igb driver fails to unload. We have not seen this issue in 5.6 GA. 

Could update on what fix went in regarding this.

thanks.

Comment 10 Harald Hoyer 2011-06-17 10:19:56 UTC

(In reply to comment #9)
> Hi Harald, 
>   I have seen this issue in Rhel6-snapshot4 timeframe.
> 
> On RHEL5.6-Snapshot4 , unload the igb driver and then reload igb driver with
> max_vfs option then igb driver fails to unload. We have not seen this issue in
> 5.6 GA. 
> 
> Could update on what fix went in regarding this.
> 
> thanks.

So, you are saying this issue is fixed? I didn't change anything in this regard.

Comment 12 Harald Hoyer 2014-01-31 12:32:35 UTC

Anyway, module removal is not and will not be supported.