On Fri, 7 Sep 2012, Marco d'Itri wrote:
On Sep 07, Stephan Springl <springl-u...@bfw-online.de> wrote:
when starting and generating the initial events, udevd tries to load
modules kvm and kvm-intel for every running cpu in the system in
parallel.
How so? The modules have no aliases which would allow autoloading:
What I did is unload the modules kvm-intel and kvm, stop udevd, started it
with debug option and said "udevadm trigger". I had debug prints in the
kernel that show that there were 32 attempts of allocationgg 304 byte
sized per cpu variables immediately following this. In a second try, I
actually verified it is udevd by replacing modprobe with a proxy script
that does debug output.
root@bongo:/lib/modules/3.2.0-3-amd64# grep kvm modules.alias
You're right. I actually found it with 3.5.1 and tried 3.5.3 and
then 3.6-rc. Looking at the machines and kernel versions I have at
hand now, I would say
Starting from 3.5, we have an alias
x86cpu:vendor:*:family:*:model:*:feature:*0085* kvm_intel
The mechanism for this came in with kernel commit 644e9cbbe3fc032cc92d09360
"Add driver auto probing for x86 features v4" and the entry for
kvm-intel was established with commit e9bda3b3d0ce775afe15ea
between 3.4 and 3.5. It gives a probe event for every core.
I am sorry for using a non standard kernel and reporting--but it
will probably be a problem in the future with newer kernels. It would
just go unnoticed with less than about 24 cores because percpu allocation
would not fail. Reading through udev's changelog until version 182
I found no hint on the situation being known. So it is probably
an upstream problem.
The kvm modules are loaded by /etc/init.d/qemu-kvm.
Is this something new in 3.6?
Yes. I noticed this before. Being number 33 in our case, it does
not make big difference with 32 attempts before this on. However,
this will have to be sorted out in the future because with makefile
style booting udevd and /etc/init.d/qemu-kvm might try to load the
modules simultaneously.
Stephan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
