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

[jim burns <jim_burn@xxxxxxxxxxxxx>]

On Tue November 15 2011, 11:10:25 AM, Flavio wrote:
> 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.

That's fine. CONFIG_XEN_NETDEV_FRONTEND is totally irrelevant to a dom0, which 
only deal with BACKEND drivers.

> > 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

Thought so.

> > 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.
> 

> > 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!!!! <----

Cool beans! One less problem.

> 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.

Yeah - the xennet / xenblk errors are occurring early on on in the boot 
process, before the disks are mounted, so the only code it can be executing is 
the kernel, and initrd modules & config files. And the initrd creation is in 
turn controlled by /etc/sysconfig/kernel. As I said, it can be ignored.

The other two errors are prevented in the 2.6.37 kernel by installing the rpm 
package preload-kmp-default, which installs /lib/modules/2.6.37.1-1.2-
default/systemtap/preloadtrace.ko. I don't think there is a corresponding 
package for the 3.1 kernel. At least I can't find one in f16, which uses the 
3.1 kernel. At any rate, it is a boot optimization routine, and the errors can 
be ignored without concern. From 'rpm -qi preload-kmp-default', the 
Description field says:

This will work with preload hand in hand to make sure no unnecessary
files are preload.

and 'rpm -qi preload' says:

Preload lists files to load into the system cache. This shortens system
boot time if used correctly.

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

Yeah, no response from Fajar, yet. I'll repost the problem with a different 
Subject line tomorrow, if no one responds.

> > Your head reeling yet? :-)
> 
> LOL, a little bit. :)
> 
> On 15 November 2011 00:35, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> >> > 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.

Ok. Evdev has nothing to do with resolution, just input peripherals, like 
keyboard, mouse, USB. So I'll forget about this.



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