[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Mon November 28 2011, 9:48:14 AM, Flavio wrote:
> On 28 November 2011 03:41, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > And yes, I will look at the hvm to pv conversion, also. I haven't
> > forgotten you.
> 
> Thank you so much, I appreciate your efforts a lot!
> Do not worry because it's not urgent.

Ok - I've had partial success. I can get text mode up to 1280x1024, and the 
desktop up to 1024x768.

The text mode boost came from simply using vga=0x31a (1280x1024x24) in my 
menu.lst, on the kernel line. I remember you saying that didn't work for you, 
but I now assume you meant for the desktop, not text mode. What also works is 
0x307 (1280x1024x8) and 0x319 (1280x1024x15).

You can get the installer to put 0x31a in for you from it's main menu - select 
F3 to set the resolution. However, it's just as easy to edit menu.lst.

With the following /etc/X11/xorg.conf, you can get a desktop up to 1024x768:

Section "Monitor"
  HorizSync    20-220
  Identifier   "Monitor[0]"
  VertRefresh  30-320
#  UseModes     "Modes[0]"
EndSection

#Section "Modes"
#  Identifier   "Modes[0]"
#  Modeline "1280x1024" 276.24 1280 1384 1528 1776 1024 1025 1028 1111
#  Modeline "1280x1024" 108.88 1280 1360 1496 1712 1024 1025 1028 1060
#  Modeline "1280x1024_60.00"  109.00  1280 1368 1496 1712  1024 1027 1034 
1063 -hsync +vsync Doublescan
#  Modeline "1280x1024_75.00"  138.75  1280 1368 1504 1728  1024 1027 1034 
1072 -hsync +vsync Interlace
#  Modeline "1280x1024_85.00"  159.50  1280 1376 1512 1744  1024 1027 1034 
1078 -hsync +vsync Doublescan Interlace
#EndSection

Section "Device"
  BoardName    "Cirrus Logic GD 5446"
  Driver       "cirrus"
  Identifier   "Device[0]"
  VendorName   "XenSource Inc."
EndSection

Section "Screen"
  DefaultDepth 24
  SubSection "Display"
    Depth      15
    Modes      "1280x1024" "1152x864" "1024x768" "800x600" 
  EndSubSection
  SubSection "Display"
    Depth      16
    Modes      "1280x1024" "1152x864" "1024x768" "800x600" 
  EndSubSection
  SubSection "Display"
    Depth      24
    Modes      "1280x1024" "1152x864" "1024x768" "800x600" 
  EndSubSection
  SubSection "Display"
    Depth      8
    Modes      "1280x1024" "1152x864" "1024x768" "800x600" 
  EndSubSection
  Device       "Device[0]"
  Identifier   "Screen[0]"
  Monitor      "Monitor[0]"
EndSection

Section "ServerLayout"
  Identifier   "Layout[all]"
  Option       "Clone" "off"
  Option       "Xinerama" "off"
  Screen       "Screen[0]"
EndSection

The commented out Modelines were just an experiment with values obtained from 
the commands cvt and xmode. None of them made any difference. Maybe someone 
better than me at xorg can chime in, but at least I got the resolution up to 
the highest one Fajar said he got in his Nov. 9 post. This is about as far as 
I can go with this resolution problem.

Used to be that in earlier distro version of opensuse - 11.2 and lower - there 
were a couple of utilities called sax2 and isax that configured your xorg.conf 
for you, but the old rpms won't install on suse 11.4, with dependency 
problems. The xorg devs must think that xorg is self configuring enough 
nowadays. I would say that isn't true with older drivers like cirrusfb.

I also noticed that if you edit the INITRD_MODULES line of 
/etc/sysconfig/kernel, the modules in that line (that are put in the initrd) 
load sooner than even the 'modprobe cirrusfb' line I had you put in 
/etc/init.d/boot.local. (After editing INITRD_MODULES, you must run 'mkinitrd' 
again to recreate all the initrds in /boot. See the mkinitrd options if you 
want to only update a specific kernel's initrd.) Unfortunately, it still loads 
after vesafb, and I still get those BAR 0: errors, and cirrusfb doesn't 
initialize properly. All the resolution obtained above come from the xorg 
cirrus module, not the kernel cirrusfb module. I never found a way around the 
BAR 0: errors, and I'm pretty sure that is what is preventing you from getting 
even higher resolutions.

On another problem - before I started looking at hvm to pv conversion for your 
domu, I decided to look at the PVonHVM drivers. The old wiki page actually has 
more info than the new one:

http://wiki.xensource.com/xenwiki/XenLinuxPVonHVMdrivers

On suse 11.4, these drivers are installed with the xen-kmp-desktop rpm for the 
-desktop flavor of the suse kernel. I noticed from the end of your dmesg that 
you got the messages that would be expected from the xen drivers, so I'm 
assuming you have it installed. You may have missed how to enable it in your 
domu config though.

This is your hvm config that you posted on Nov. 8, with the obvious changes 
for local differences in my setup, like memory=, disk= and keymap=. I call the 
file simply 'suse':

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 768
#device_model = 'qemu-dm'

shadow_memory = 8
name = "opensuse-11.4"
vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0' ]
acpi = 1
apic = 1
disk = [ 'phy:/dev/disk/by-path/ip-192.168.1.101:3260-iscsi-
iqn.2001-04.com.Dell4550-iqn.2009-09.net.bellsouth.sda:041b7d3f-b008-4367-
b1f2-b4799d15e4cd-lun-2,hda,w', 'phy:/dev/cdrom,hdc:cdrom,r' ]
#vif = [ 'mac=00:16:3e:00:00:21, bridge=xenbr0, model=e1000' ]
#xen_platform_pci=1

boot="dc"
sdl=0
vnc=1
vncconsole=1
vncpasswd=''
vnclisten="192.168.1.100"
stdvga=0
videoram=16
#keymap="it"
keymap='en-us'

serial='pty'
usbdevice='tablet'

I noticed you didn't use device_model= in your config, and the install worked 
quite well with out it. I simply executed 'xl create suse', and the dvd 
installer came up and worked with no problems, and I picked all the defaults. 
I assume that is how you did it, and did not use something like virt-install 
or virt-manager.

After the install, I changed boot= to 'cd', and played with the Realtek 
drivers the first few times I rebooted. Then I enabled the PVonHVM drivers by 
commenting out your vif=, and un-commenting the vif= with the e1000 model, and 
xen_platform-pci=, according to the url.

I had some minor problems, because the dvd installer setup udev and modprobe 
rules based on Realtek as eth0, and PVonHVM tried to setup an eth1 with the 
PVonHVM drivers, but then tries to rename eth1 to eth0, and move eth0 out of 
the way. If you do an 'ethtool -i eth0'. if it says the driver is e1000, 
you're still using the qemu emulated device. If 'ethtool -i eth0' says the 
driver is netfront, you are using the PVonHVM driver.

I found if I edited /etc/modprobe.d/xen_pvdrivers.conf to include a line for 
e1000 similar to the existing lines for 8139{cp,too}, I can get eth0 to have 
the netfront driver nearly every time:

# Install the paravirtualized drivers
install libata  /sbin/modprobe xen-vbd 2>&1 |:; /sbin/modprobe --ignore-
install libata

install 8139cp  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe --ignore-
install 8139cp

install 8139too  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe --ignore-
install 8139too

install e1000  /sbin/modprobe xen-vnif 2>&1 |:; /sbin/modprobe --ignore-
install e1000

The results are impressive, at least on the network side. Benchmarking with 
'iperf' gives net speeds around 1Gbps. Can't say I was as impressed with the 
disk drivers, but all I tested with was 'hdparm -t devicename', where the 
devicename is /dev/sda? for qemu and /dev/hda? for PVonHVM. The numbers were 
all the same, but I'm probably limited by my iscsi speed anyway.

That being said, there will be an annoying 1 min. pause on boot up, around the 
message:

[   36.114925] eth1 renamed to eth1-eth0 by udevd [347]
[   36.121708] udev[347]: renamed network interface eth1 to eth1-eth0

Over the next few days, I'll look at full blown hvm to pv conversion. I 
suspect it will be as simple as installing kernel-xen, but using a pv config 
file to boot with. If I boot with an hvm config, and select Xen in the menu, I 
also got the 'invalid executable format' error. Then as I mentioned, the 
device names in menu.lst and /etc/fstab have to be changed. I'm already 
booting up with my hvm config with /dev/disk/by-uuid names instead of 
/dev/disk/by-id names. When I get it all together, I'll post it.

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.