Package: linux-image-2.6.32-5-xen-amd64
Version: 2.6.32-20
The error manifests itself when trying to start a VM machine with a
clean/vanilla install of debian sid + linux-image-2.6.32-5 +
xen-hypervisor-4.0 from last Friday's package list. Since and 'upgrade'
today still listed package
'linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64' as current, it should
still be an existing bug if installing today.
Most obvious output is upon trying to 'xm create' a machine:
ERROR Internal error: Could not open event channel interface (22 =
Invalid argument)
>From what I was able to track down, udev doesn't seem to be creating the
'evtchn' device correctly using
linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64.deb.
I believe this is the package to file this bug against. It should be
relatively easily reproducible with a clean install. Reverting to
linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and updating initramfs
fixes the issue. Reverting to
xen-hypervisor-4.0-amd64_4.0.1~rc3-1_amd64 does _NOT_ make a difference.
Hence, I believe it's in the kernel img where the problem lies. I am
using 'linux-image-2.6.32-5-xen-amd64_2.6.32' as both dom0 and domU.
A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 will
produce this output
> 'find /dev | grep evtchn'
/dev/xen/evtchn
/dev/evtchn
/dev/.udev/db/misc:evtchn
> 'find /sys | grep evtchn'
(also produces useful output for comparison... didn't want to bloat the
post with text)
A clean boot into linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64 will
produce different output, mainly it will only have a line simlar to:
> 'find /dev | grep evtchn'
/dev/.udev/db/??misc:evtchn??
where the ??misc:evtchn?? string may be slightly different. most
importantly, it does _NOT_ create /dev/evtchn or /dev/xen/evtchn.
also:
> 'find /sys | grep evtchn'
will produce output where the device strings have '!'s in them where
they don't on the .18 kernel.
I have a feeling these changes to the device names/drivers/whatever they
are properly called are causing udev rules to fail. I have a suspicion
it is a result of trying to fix the issue where the kernel/udev was
complaining about "kernel-provided name 'evtchn' and NAME= 'xen/evtchn'
disagree, please use SYMLINK+= or change the kernel to provide the
proper name" which was an issue in the .18 kernel release. I have no
absolute proof of this, I am just trying to provide some thoughts.
I apologize I am reporting this bug only after downgrading to
linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 and 'fixing' the issue.
I don't have the luxery of time to re-create the broken fix and dump
exact output and sys-config. I need the system working. So, I hope I
provided enough to troubleshoot. I didn't see similar bugs posted under
linux-image, udev or xen hypervisor packages so I feel it's unique.
Thanks again for creating the pvopts kernels!!! It is SO nice to have
built packages back in the repos to use for dom0. Xen and the work to
support it is an awesome thing. Please ask me if you need more feedback
and I can dump output. The main packages/versions related to this bug
should be:
linux-image-2.6.32-5-xen-amd64_2.6.32-20_amd64
xen-hypervisor-4.0-amd64_4.0.1~rc5-1_amd64 (as mentioned, rc3 also
produces same bug)
libudev0 160-1 libudev shared library
udev 160-1 /dev/ and hotplug management daemon
linux-image-2.6.32-5-xen-amd64_2.6.32-18_amd64 downgrade 'fixes' issue.
Hope this helps someone.
- jmd
--
Joseph M. Deming
System Administrator
MATRIX/History
415 Nat Sci Bldg
East Lansing, MI 48824
(517) 884-2472
joseph.deming@matrix.msu.edu