Hey,

here is a discussion about the reproducablity. I'm wrote very early in
these thread that
if I set the following network config in a container

ip -6 tunnel add gt6nactr01 mode ip6gre local 2a4:4483:5:1709::2:1
remote 2a4:4494:f:997:217:110:59:5
ip link set mtu 1500 dev gt6nactr01 up
ip addr add 2a04:4454:f:f003::1/64 dev gt6nactr01
ip addr add 169.254.193.1/30 dev gt6nactr01

it will hang on reboot, try it again just now an it works/halt! There
is also a other possiblity to stop a lxc with the same result "waiting
for lo to become free".
And this is if you mount a nfs server with a lxc container, you have
to change something apparmor but than it works perfectly until you try
to reboot the lxc container.

Is there any reason why not try to fix these reproducable problems first?

cheers

meno


On Mon, Feb 9, 2015 at 6:50 PM, Rodrigo Vaz <email address hidden> wrote:
> I left a couple instances running with the mainline kernel
> (http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.19-rc7-vivid/) during
> the weekend, it took more time to see the bug on the mainline kernel but
> this morning one out of ten instances had the same problem so I'm
> assuming mainline is also affected.
>
> Kernel version 3.19.0-031900rc7-generic
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1403152
>
> Title:
>   unregister_netdevice: waiting for lo to become free. Usage count
>
> Status in The Linux Kernel:
>   Unknown
> Status in linux package in Ubuntu:
>   Triaged
> Status in linux source package in Trusty:
>   New
> Status in linux source package in Utopic:
>   New
>
> Bug description:
>   I currently running trusty latest patches and i get on these hardware
>   and software:
>
>   Ubuntu 3.13.0-43.72-generic 3.13.11.11
>
>   processor     : 7
>   vendor_id     : GenuineIntel
>   cpu family    : 6
>   model         : 77
>   model name    : Intel(R) Atom(TM) CPU  C2758  @ 2.40GHz
>   stepping      : 8
>   microcode     : 0x11d
>   cpu MHz               : 2400.000
>   cache size    : 1024 KB
>   physical id   : 0
>   siblings      : 8
>   core id               : 7
>   cpu cores     : 8
>   apicid                : 14
>   initial apicid        : 14
>   fpu           : yes
>   fpu_exception : yes
>   cpuid level   : 11
>   wp            : yes
>   flags         : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes rdrand lahf_lm 3dnowprefetch arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms
>   bogomips      : 4799.48
>   clflush size  : 64
>   cache_alignment       : 64
>   address sizes : 36 bits physical, 48 bits virtual
>   power management:
>
>   somehow reproducable the subjected error, and lxc is working still but
>   not more managable until a reboot.
>
>   managable means every command hangs.
>
>   I saw there are alot of bugs but they seams to relate to older version
>   and are closed, so i decided to file a new one?
>
>   I run alot of machine with trusty an lxc containers but only these kind of machines produces these errors, all
>   other don't show these odd behavior.
>
>   thx in advance
>
>   meno
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/1403152/+subscriptions