[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 Sun November 13 2011, 7:35:18 PM, jim burns wrote: > Ok - As I said, so long as the 3.1 domu config has > CONFIG_XEN_NETDEV_FRONTEND=y (builtin) the network should theoretically > work. Particularly since your Gentoo dom0 is also 3.1. The fact that your > 2.6.37 domu network works, and 2.6.37 is the old xenlinux style, as opposed > to the newer 3.1 pvops style, shows that qemu-dm is capable of hiding the > differences. The fact that /etc/sysconfig/kernel asks for the old xennet, > xenblk names shouldn't matter with the newer xen-netfront as a builtin. And > again, your eth0 got an ipv4 address from the network - I assume you get > addresses from dhcp? 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. 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.) This is just like we didn't care about CONFIG_XEN_FBDEV_FRONTEND, because we are using cirrusfb, not xen-netfront. According to your 2.6.37 dmesg, the the network card is initialized this way: [ 0.209416] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200 [ 0.209789] pci 0000:00:04.0: reg 10: [io 0xc100-0xc1ff] [ 0.210096] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff] [...] [ 8.550920] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [ 8.551133] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 [ 8.568729] xen_mem: Initialising balloon driver. [ 8.771269] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc90000c40000, 00:16:3e:00:00:21, IRQ 32 [ 8.771366] 8139cp 0000:00:04.0: setting latency timer to 64 [ 8.858934] netfront: Initialising virtual ethernet driver. [ 8.919407] xen-vbd: registered block device major 3 [ 8.919450] blkfront: hda: barriers enabled [ 8.922799] hda: hda1 hda2 [ 8.931426] 8139too: 8139too Fast Ethernet driver 0.9.28 [...] [ 43.310820] eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 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): [ 0.685919] pci 0000:00:04.0: [10ec:8139] type 0 class 0x000200 [ 0.688990] pci 0000:00:04.0: reg 10: [io 0xc100-0xc1ff] [ 0.692039] pci 0000:00:04.0: reg 14: [mem 0xf3001000-0xf30010ff] [...] [ 9.458707] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) [ 9.458839] xen: --> pirq=23 -> irq=32 (gsi=32) [ 9.458845] 8139cp 0000:00:04.0: PCI INT A -> GSI 32 (level, low) -> IRQ 32 [ 9.475499] 8139cp 0000:00:04.0: eth0: RTL-8139C+ at 0xffffc900004fc000, 00:16:3e:00:00:21, IRQ 32 [ 9.475653] 8139cp 0000:00:04.0: setting latency timer to 64 [...] [ 9.613185] 8139too: 8139too Fast Ethernet driver 0.9.28 [...] [ 24.322502] 8139cp 0000:00:04.0: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1 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. (Btw, both kernels report the same BAR errors with cirrusfb, and fail, leaving (presumably) vesa in charge.) There is a 2nd configuration possible, though. Qemu-dm also supports an Intel 1000 Mbps card, which Pasi K. prefers to use in linux hvm domus. The vif= line has a model= suboption. Model=rtl8139, or no model= option, picks the Realtek emulation, model=e1000 picks the Intel emulation. Of course, if you change your hvm config, you change it for both kernels. You might want to configure both interfaces, giving you an eth0 and an eth1: 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' ] Note each interface has a unique mac address. They are also both attached to xenbr0. This shouldn't case network loops, but if it does, you can always ifup one, and ifdown the other. And then there is a third possibility. Your kernel with the network problems, 3.1, is fully capable of booting as a pv domu. You have already compiled all the xen frontends as builtin. Domu support has been available in mainline kernels for some time now. Of course, changing from hvm to pv drivers will cause some configuration problems in your file system image. I've already mentioned how your /dev/disk/by-id soft links won't be valid anymore. Not sure whether you should be using /dev/sda<n>, or /dev/xvda<n> in your menu.lst, since I use root=UUID=, but you will definitely be using /dev/xvda<n> in your /etc/fstab, at least until you see whether something stays constant, like /dev/disk/by- uuid. Rather than changing your fstab every time you want to change from hvm to pv, if you have enough disk space, you might want to clone (copy) your file system image file, and use it for pv. Your menu.lst stanza will look very similar to the one for your kernel-xen install. Your head reeling yet? :-) _______________________________________________ Xen-users mailing list Xen-users@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-users
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |