WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-users

Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480

To: jim burns <jim_burn@xxxxxxxxxxxxx>
Subject: Re: [Xen-users] OpenSuse 11 hvm domU: screen resolution up to 640x480
From: Flavio <fbcyborg@xxxxxxxxx>
Date: Tue, 15 Nov 2011 11:10:25 +0100
Cc: xen-users@xxxxxxxxxxxxxxxxxxx, "Fajar A. Nugraha" <list@xxxxxxxxx>
Delivery-date: Tue, 15 Nov 2011 02:12:48 -0800
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=o9xWycJGi2hpYh96G6U+NUZ0tstIUOZSclW5R71oTVQ=; b=ebi/LC65tMQIsi5MBZjKWKNZB/ymfeM7Hz0WvR3fG/BEalg0jPkCMMGogOwt3Gcc5R dzlqzsbSzYWvgZquGteoMVlEfiFkiRWqzhdZ0tsqtYHu/rC/AjgpmIUEqY0BfJIq9q8I sjmTVtNslQCKudGn1KXs5hsk2U1ENlzEFHgO0=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2827784.4lBjxsVN9O@dell4550>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <7877809.94pu0BOf0I@dell4550> <4592072.7zkAKQjZAl@dell4550> <CAP8Jb=o3uXC6MCkjozLo-1h=XTQ3hB+vS_oefVY1hOZWkBHnSA@xxxxxxxxxxxxxx> <2827784.4lBjxsVN9O@dell4550>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
On 15 November 2011 00:16, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> Oy - I just realized this morning that I'm going about your network problem
> all wrong. While it's true that CONFIG_XEN_NETDEV_BACKEND=y in your Gentoo
> dom0 was a good thing, that's because a dom0 is always a pv domain. However,
> we don't really need to care about CONFIG_XEN_NETDEV_FRONTEND=y or =m in an
> hvm domu, because that also only matters to a pv domu.
OK, in any case I have CONFIG_XEN_NETDEV_FRONTEND not set in the dom0 kernel
and the network is perfectly working both on other PV and hvm domUs.

> Qemu-dm (by default)
> provides an emulated Realtek 8139 network card, so we are looking for the
> kernel drivers 8139cp and/or 8139too. (Not sure which or both - your 2.6.37
> dmesg initializes both. Do a 'lsmod|grep 8139' and tell me which one(s) you
> have.)
# lsmod|grep 8139
8139too                30960  0
8139cp                 23939  0

> My guess is the driver attached to the pci device 00:04.0, 8139cp, handles the
> device, and 8139too handles the protocol. This is similar to wireless devices
> being serviced by multiple kernel modules.
>
> Your 3.1 dmesg says virtually the same thing (except for netfront & blkfront):
[...]
>
> In other words, as far as the domu is concerned, for both kernels, eth0 has
> been initialized, and the link is up. So the problem is in the dom0 to domu
> frontend, backend communication, or the bridge. Can't do anything more with
> this configuration, short of using tcpdump to troubleshoot.
OK, even I'm not so practical with it.

>
> (Btw, both kernels report the same BAR errors with cirrusfb, and fail, leaving
> (presumably) vesa in charge.)
So, this could be the point where the resolution problem is generated. Anyway,
I still think that something in the suse guest is very wrong, because other
domU work (windows for instance).

[CUT]
> vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0, model=rtl8139',
> 'type=ioemu, mac=00:16:3e:00:00:22, bridge=xenbr0, model=e1000' ]
OK, I tried to set model=e1000 for the domU eth0.

kernel-2.6.37:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK

kernel-3.1.0:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK!!!! <----
Screenshot just after the domU launch: http://i.imgur.com/T6ICQ.png
It still complains about xennet and xenblk not found and other two
errors. I don't know
what it is.

Well, now that the networking works, this problem has been solved. Let's go back
to the resolution problem. :)

> Your head reeling yet? :-)
LOL, a little bit. :)



On 15 November 2011 00:35, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> I was afraid of that. Worth a try.
No problem, every attempt is licit here!

> Yeah - on my system, the first line is DRIVER=<kernel module>. Further
> evidence that cirrusfb is missing in action.
I don't know what to say here :(

>
>> > 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:
Just a moment: there is a little bit of confusion now. It's my fault probably.
Get rid of the PV installation where the mouse is not working (it
failed). I abandoned such
setup for now, because it completely freezes my system causing an
emergency sysrq
keys use to reboot. The domU log above comes from the suse with the resolution
problem we are talking about in the main discussion here!
In any case I don't know how to get the Xorg.0.log file from a system which is
pretty unusable and during the installation phase.

Anyway I am planning to retry with this setup.

> Maybe. The mount -o loop doesn't take any significant memory, but each domu
> will. Check with 'xm/xl list'.
I know this, and this is actually strange for me. In any case I only
have one domU
running when performing the setup: the suse I am trying to install.


> 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.
I've noticed that too. This is not a great problem. My hope is to finish the
installation and to run the pv domU.

>
> 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.
I've seen that. I guess this khungtaskd process is not so efficient, because
I am obligued to reboot.

Thanks a lot

Flavio

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users

<Prev in Thread] Current Thread [Next in Thread>