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