Bug 246749 - on shutdown, msg "unregister_netdevice: waiting for virbr3 to become free. Usage count = 1"
on shutdown, msg "unregister_netdevice: waiting for virbr3 to become free. U...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-04 11:48 EDT by Nathan Watson
Modified: 2008-01-09 10:42 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-09 10:42:02 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
List of RPMs installed on the Fedora 7 host machine (7.70 KB, application/x-gzip)
2007-07-04 12:18 EDT, Nathan Watson
no flags Details
Description of problem setup, and workaround (7.73 KB, text/plain)
2007-07-05 19:31 EDT, Nathan Watson
no flags Details

  None (edit)
Description Nathan Watson 2007-07-04 11:48:48 EDT
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.
Comment 1 Nathan Watson 2007-07-04 11:52:20 EDT
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.
Comment 2 Nathan Watson 2007-07-04 12:16:54 EDT
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]#
Comment 3 Nathan Watson 2007-07-04 12:18:32 EDT
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.
Comment 4 Chuck Ebbert 2007-07-05 17:36:51 EDT
What kind of interface is the virbr3 device?

Comment 5 Nathan Watson 2007-07-05 19:31:53 EDT
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.
Comment 6 Nathan Watson 2007-07-05 19:46:50 EDT
Changing severity from 'high' to 'medium' as I apparently have
a configuration that now works.
Comment 7 Nathan Watson 2007-07-05 19:48:03 EDT
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).
Comment 8 Christopher Brown 2007-09-17 16:28:45 EDT
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
Comment 9 Christopher Brown 2008-01-09 10:42:02 EST
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.

Note You need to log in before you can comment on or make changes to this bug.