On Mon November 14 2011, 11:46:03 AM, Flavio wrote:
> If I boot using these entries:
Yes - this is what I meant.
> kernel /boot/vmlinux-2.6.37.6-0.9-xen
> root=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part2
> resume=/dev/disk/by-id/ata-QEMU_HARDDISK_QM00001-part1 splash=silent
> quiet showopts vga=0x314
> initrd /boot/initrd-2.6.37.6-0.9-xen
> (I gunzipped the vmlinux file)
> It still says: Error 13: Invalid or unsupported executable format.
> Same thing if I use the .gz file of course.
I was afraid of that. Worth a try.
> > Again, there is no directory entry for a soft link called 'driver'
> > pointing to a kernel module, such as cirrusfb, so vesa is probably
> > still in charge. See if anything interesting comes from 'cat
> > /sys/bus/pci/devices/0000:00:02.0/uevent'.
>
> With the 2.6.37 kernel booted:
> PCI_CLASS=30000
> PCI_ID=1013:00B8
> PCI_SUBSYS_ID=5853:0001
> PCI_SLOT_NAME=0000:00:02.0
> MODALIAS=pci:v00001013d000000B8sv00005853sd00000001bc03sc00i00
Yeah - on my system, the first line is DRIVER=<kernel module>. Further
evidence that cirrusfb is missing in action.
> > No, I mean do you see lines that evdev loaded? 'grep evdev
> > /var/log/Xorg.0.log'
>
> Yes, I see those lines.
> domU: http://pastebin.com/emieNZxy
> dom0: http://pastebin.com/WxSdq74i
>
Your domu install with the nonfunctional mouse none the less has the message:
[ 110.096] (**) ImExPS/2 Generic Explorer Mouse: Applying InputClass "evdev
pointer catchall"
so I don't know what happened there.
> > I don't know what you mean by blocked. Did the installer load, and you
> > got a menu, but you couldn't get it to start installing packages?
>
> The package installation begins, but it's very slow and it blocks.
>
> > Your link to the
> > setup procedure mentioned setting up Apache to mount your cdrom. You
> > could just as easily have used an nfs mount of the cdrom.
>
> I mounted the ISO image as loop in /var/www/localhost/htdocs/suse11. Maybe
> the memory is going to run out if I launch both the dom0 and the mount
> -o loop and
> also the domU start.
Maybe. The mount -o loop doesn't take any significant memory, but each domu
will. Check with 'xm/xl list'.
> > The problem is you can get
> > your dom0 to load a cd in a pv install, but once the installer is handed
> > control, an inherent limitation of a pv domu or install, is it doesn't
> > know about cd devices.
>
> The installer got frozen. No possibility to go ahead. Sometime even my dom0
> got blocked, so I have to use sysrq magic keys to reboot. Maybe it's
> due to a memory
> issue, even if the system is still accessible via ssh and is "alive".
> It seems the
> hypervisor die. Every xl command stucks without giving any reply in the
> console.
Doing an hvm install is going to be slow anyway. I know the fedora installer
does a lot of thinking picking packages, before it starts installing them,
and looks like it's hung, and then hvm slows down things even more. Suse
installers do some thinking, but it's more obvious it's doing something.
Xen domus have has a problem with hung cpus for sometime now, on multi core
cpus (SMP code). That's why modern kernels start a khungtaskd process.
As I am writing this, I just got a:
Nov 14 18:26:41 Insp6400 kernel: [191104.568001] BUG: soft lockup - CPU#0
stuck for 22s! [savapi:9977]
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home