Bug 246749
| Summary: | on shutdown, msg "unregister_netdevice: waiting for virbr3 to become free. Usage count = 1" | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Nathan Watson <nwatson> | ||||||
| Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> | ||||||
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 7 | CC: | chris.brown | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2008-01-09 15:42:02 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: | |||||||||
| Attachments: |
|
||||||||
Forgot to say, this message repeats over and over again on the physical console screen attached to the computer. Shutdown does not proceed further, hung up on this. Output of "uname -a": Linux XXX.YYY.com 2.6.21-1.3228.fc7 #1 SMP Tue Jun 12
14:56:37 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux (NOTE: not using the Xen
kernel, not required for QEMU/KVM).
Probably relevant modules and versions:
* kernel-2.6.21-1.3228.fc7
* libvirt-0.2.3-1.fc7
* qemu-0.9.0-2.fc7
* ... don't know about network/virtual-network packages that
might be relevant ... I'll just attach a file with current
RPMs -- host machine is a standard Fedora 7 with little or
not custom software installed
After re-boot and getting machine in typical operating state,
here is the 'lsmod' output:
[root@XXX rc.d]# lsmod
Module Size Used by
tun 20673 1
ipt_MASQUERADE 12353 4
iptable_nat 16581 1
nf_nat 29549 2 ipt_MASQUERADE,iptable_nat
bridge 65641 0
nfsd 265833 17
exportfs 14529 1 nfsd
lockd 75121 2 nfsd
nfs_acl 12225 1 nfsd
autofs4 32841 2
sunrpc 188329 12 nfsd,lockd,nfs_acl
nf_conntrack_netbios_ns 11713 0
nf_conntrack_ipv4 20689 6 iptable_nat
xt_state 11201 4
nf_conntrack 75293 6
ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_netbios_ns,nf_conntrack_ipv4,xt_state
nfnetlink 16137 3 nf_nat,nf_conntrack_ipv4,nf_conntrack
xt_tcpudp 12097 14
ipt_REJECT 13377 3
iptable_filter 11585 1
ip_tables 28713 2 iptable_nat,iptable_filter
x_tables 29257 6
ipt_MASQUERADE,iptable_nat,xt_state,xt_tcpudp,ipt_REJECT,ip_tables
dm_multipath 27985 0
video 28113 0
sbs 25729 0
i2c_ec 14401 1 sbs
button 17633 0
dock 19505 0
battery 19785 0
ac 14537 0
ipv6 340289 46
parport_pc 38121 0
lp 22801 0
parport 48973 2 parport_pc,lp
loop 26705 0
kvm_intel 29133 1
kvm 75969 1 kvm_intel
e1000 131457 0
sr_mod 26341 0
cdrom 44137 1 sr_mod
pcspkr 11969 0
i2c_i801 17885 0
serio_raw 16069 0
i2c_core 32449 2 i2c_ec,i2c_i801
shpchp 42845 0
ata_generic 17861 0
floppy 71913 0
sg 45673 0
dm_snapshot 25481 0
dm_zero 10817 0
dm_mirror 30209 2
dm_mod 69457 25 dm_multipath,dm_snapshot,dm_zero,dm_mirror
ata_piix 25541 0
ahci 31557 3
libata 131689 3 ata_generic,ata_piix,ahci
sd_mod 30017 4
scsi_mod 165241 4 sr_mod,sg,libata,sd_mod
ext3 141649 3
jbd 72881 1 ext3
mbcache 18249 1 ext3
ehci_hcd 42957 0
ohci_hcd 30277 0
uhci_hcd 34145 0
[root@XXX rc.d]#
Created attachment 158523 [details]
List of RPMs installed on the Fedora 7 host machine
Here is a listing of the RPMs installed on the host machine at the
time the error happened.
What kind of interface is the virbr3 device? Created attachment 158630 [details]
Description of problem setup, and workaround
See the attached file for more thorough description of the problem, and the
workaround I used to get around it and accomplish my goals. It could be my
original approach was wrong and "not supported", but even if it is, there may
be some hole in the kernel/module-provided services you'll want to close.
Thanks for your help.
Changing severity from 'high' to 'medium' as I apparently have a configuration that now works. From 'ifconfig' on main host I get this:
virbr3 Link encap:Ethernet HWaddr 72:48:E6:0E:86:E5
inet addr:192.168.8.1 Bcast:192.168.8.255 Mask:255.255.255.0
inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1981 errors:0 dropped:0 overruns:0 frame:0
TX packets:3490 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:122445 (119.5 KiB) TX bytes:961999 (939.4 KiB)
The virtual network starts up when "service libvirtd start" happens
during boot-up or later on. I'm using the regular kernel instead
of the Xen kernel, as I'm using QEMU/KVM instead of Xen (not sure
whether that makes a difference). The configuration file that leads
to the creation of 'virbr3' is:
[root@porta01x ~]# cat /etc/libvirt/qemu/networks/janelaz.xml
<network>
<name>janelaz</name>
<uuid>d83670ee-a32a-4d07-9939-aaaa71852404</uuid>
<bridge name="virbr3" />
<forward/>
<ip address="192.168.8.1" netmask="255.255.255.0">
<dhcp>
<range start="192.168.8.100" end="192.168.8.109" />
</dhcp>
</ip>
</network>
I'm not sure which, if any, network script in
/etc/sysconfig/network-scripts (it appears
"rpm --query --filesbypkg libvirt" does not return
any specific files from that directory, so it must
be started through some other mechanism).
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. There hasn't been much activity on this bug for a while. Could you tell me if you are still having problems with the latest kernel - you indicate this issue may be resolved in comment #6 ...? If the problem no longer exists then please close this bug or I'll do so in a few days if there is no additional information lodged. Cheers Chris As indicated previously there has been no update on the progress of this bug therefore I am closing it as INSUFFICIENT_DATA. Please re-open if the issue still occurs for you and I will try to assist in its resolution. Thank you for taking the time to report the initial bug. |
Description of problem: When shutting down a Fedora 7 real physical machine (not virtual machine) I get message: "unregister_netdevice: waiting for virbr3 to become free. Usage count = 1". Seems to come from kernel level (not familiar with these things, other postings in various forums imply this is at kernel level or at least in modules). Version-Release number of selected component (if applicable): Host is shutting down, I can't get this info right now, will post in further comment later. How reproducible: Happened once so far. Not in state to try to reproduce yet. Steps to Reproduce: SETUP: I'm running a virtual machine environment: * host is Fedora 7 * guests are various Fedora 7, Windows XP Pro Svc Pack 2, Windows Server 2003 R2 Svc Pack 2 * running them in multiple virtual networks (including virtual network 'virbr3') * will have more detail later, but I believe 'virbr3' is the one hosting an internal Win Srv 2003 VPN gateway with "public" iface 192.168.7.31 on virbr?, internal "private" iface 192.168.8.31 on virbr? (probably virbr3), other Win Srv 2003 machine also on "private" network with iface 192.168.8.42 * Using libvirt, QEMU, KVM, virt-manager, virsh to manage virtual networks and machines * Using iptables to configure internal virtual env routing and external routing * High-level operations at time just before re-boot: I was trying to get network connectivity from non-VPN Win-Srv-2003 to work through VPN/gateway server then to outside world (e.g., from Windows command shell execute successfully "telnet www.google.com 80") -- perhaps irrelevant, more details upon request ACTION TRIGGERING FAILURE: after experiments, tried to do an /sbin/reboot on the Fedora 7 host ... leading to the problem witnessed Actual results: /sbin/reboot leads to error message on Fedora 7 host, on physical screen attached Expected results: /sbin/reboot should shut down Fedora 7 physical machine host and successfully re-start also (IMPORTANT FOR REMOTE ADMINISTRATION) Additional info: I can provide more if required. If I can reproduce in more controlled circumstances can do this also.