|
[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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |