On 13 November 2011 18:17, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> Just make sure that xen-netback is a
> builtin in your Gentoo dom0 - grep XEN /boot/config* | grep BACK | grep NET .
> You should come up with CONFIG_XEN_NETDEV_BACKEND=y for a 3.1 Gentoo kernel.
> I'm assuming this is going to work, since one hvm domu has a network, and the
> other doesn't.
This seems to be OK actually:
$ cat /boot/config-3.1.0-gentoo | grep BACK | grep NET
CONFIG_XEN_NETDEV_BACKEND=y
>
> Eth0 & tap2.0 look good - they only have an ipv6 address, since they are on a
> bridge. Vif2.0 has no address, which is fine, since an hvm domu uses tap, not
> vif (unless you are using pv on hvm). Xenbr0 has both ipv6 and ipv4 addresses,
> for internet access. Not sure why you have a tun0 point to point interface,
> but since it is on a different private subnet, I'm going to ignore it
Yes, ignore it. It's for the openvpn.
> Since you don't specify vncdisplay / vncunused in your hvm config, you are
> defaulting to vncunused, which grabs the first unused vnc port, which appears
> to be 5900.
Yes, it is that port number.
> eth0. SuSE has a rather restrictive firewall.
Yes I know. Actually, in order to get also the ssh working I had to enable sshd
traffic in the firewall.
> As a test, try doing
> 'rcSuSEfirewall2 stop', and see if that helps.
nope. I've already tried that and it doesn't help. I think it is all related to
those kernel modules that are missing.
> If it does, we can play with
> the firewall config to allow all traffic on your 192.168.1 subnet. If one hvm
> domu works, and the other doesn't. it could be that one kernel doesn't have a
> kernel module that the firewall needs, so it is defaulting to lockdown.
It's not due to the firewall because if I boot with the default 2.6.37
kernel that
comes with the installation, the network works. Changing the kernel
with the 3.1.0
it doesn't.
>
> If none of this works, you may have to break out tcpdump on the tap interface.
> I'm no expert with it,
so am I.
> but I'd look for some kind of restriction on the kind
> of traffic that's getting out of the interface - just arp and udp, but no tcp,
> or communication in one direction, but not the other.
I repeat. I think it's due to the kernel configuration. I have no idea of what
could the problem be. I prefer to find an alternate solution. By the
way, I couldn't
setup the PV guest at the end.
>> cirrusfb 32579 0
>
> Ok, now I'm confused again. Have I got this right - your compiled kernel, 3.1,
> has no network, and your 2.6.37 has the resolution problem?
Both have the resolution problem. 2.6.37 is OK for the network. 3.1.0 is not OK.
> Because at one
> point, you said you tried to install the kernel-xen package from suse
> (2.6.37.6-0.9), and you got an 'Invalid or unsupported executable format'
> error.
Yes, the kernel-xen doesn't work to me. Anyway, I don't think it is a good
thing, to install a domU kernel if it won't run on a PV guest.
> Which 2.6.37 kernel are you talking about now, that's (mostly) working?
2.6.37 is the kernel that comes with the distribution setup (suse 11.4).
It's not a xen capable kernel, or even better it's a "normal" kernel.
3.1.0 is a kernel that has been compiled by myself.
kernel-xen, has been installed with zypper, the suse package manager.
>
> Ok - I just looked at your dmesg, and your booting suse's 2.6.37.1-1.2-
> desktop. Let's look at the file formats:
> [...]
>
> So suse's desktop flavor of the kernel (which has no xen features for a pv
> domain) is a bzimage format, which is standard, and an hvm domain should have
> no problems with it, and your (earlier version) 2.6.37.1-1.2-desktop kernel
> does in deed boot. The 2.6.37.6-0.9-xen kernel(s) are ELF formats, as required
> by a pv domain. Don't know why you are getting the bad executable error, but
> you can try substituting vmlinux (with an x) for vmlinuz (with a z), and see
> if your pv domain will boot now.
It's not pv, but hvm. Anyway, I can't substitute a z with a x. The
file is called
vmlinuz. Or maybe I didn't understand exactly what you mean.
>
> So my question remains: the 3.1 kernel is the one without a network, and the
> 2.6.37.1-1.2-desktop is the one with the resolution problems, right?
Right. As I've written above, both have the resolution problem, otherwise,
the resolution problem would be solved now, and we would talk about a networking
problem! ;)
>
> This is showing that vesa is builtin, and cirrusfb is a module, as on my
> systems.
>
>> > ls -alF /sys/bus/pci/devices/0000:00:02.0 (your video device)
>
>> lrwxrwxrwx 1 root root 0 Nov 13 09:57
>> /sys/bus/pci/devices/0000:00:02.0 ->
>> ../../../devices/pci0000:00/0000:00:02.0/
>
> Sorry - I forgot about the soft link. I meant ls -alF
> /sys/bus/pci/devices/0000:00:02.0/ (with a trailing slash). Pls repost.
# ls -alF /sys/bus/pci/devices/0000:00:02.0/
total 0
drwxr-xr-x 3 root root 0 Nov 13 23:49 ./
drwxr-xr-x 12 root root 0 Nov 13 23:49 ../
-r--r--r-- 1 root root 4096 Nov 13 23:49 boot_vga
-rw-r--r-- 1 root root 4096 Nov 13 23:52 broken_parity_status
-r--r--r-- 1 root root 4096 Nov 13 23:51 class
-rw-r--r-- 1 root root 256 Nov 13 23:49 config
-r--r--r-- 1 root root 4096 Nov 13 23:52 consistent_dma_mask_bits
-r--r--r-- 1 root root 4096 Nov 13 23:52 device
-r--r--r-- 1 root root 4096 Nov 13 23:52 dma_mask_bits
-rw------- 1 root root 4096 Nov 13 23:52 enable
-r--r--r-- 1 root root 4096 Nov 13 23:52 irq
-r--r--r-- 1 root root 4096 Nov 13 23:52 local_cpulist
-r--r--r-- 1 root root 4096 Nov 13 23:52 local_cpus
-r--r--r-- 1 root root 4096 Nov 13 23:52 modalias
-rw-r--r-- 1 root root 4096 Nov 13 23:52 msi_bus
-r--r--r-- 1 root root 4096 Nov 13 23:52 numa_node
drwxr-xr-x 2 root root 0 Nov 13 23:52 power/
--w--w---- 1 root root 4096 Nov 13 23:52 remove
--w--w---- 1 root root 4096 Nov 13 23:52 rescan
-r--r--r-- 1 root root 4096 Nov 13 23:49 resource
-rw------- 1 root root 33554432 Nov 13 23:52 resource0
-rw------- 1 root root 33554432 Nov 13 23:49 resource0_wc
-rw------- 1 root root 4096 Nov 13 23:49 resource1
-r-------- 1 root root 131072 Nov 13 23:52 rom
lrwxrwxrwx 1 root root 0 Nov 13 23:49 subsystem -> ../../../bus/pci/
-r--r--r-- 1 root root 4096 Nov 13 23:52 subsystem_device
-r--r--r-- 1 root root 4096 Nov 13 23:52 subsystem_vendor
-rw-r--r-- 1 root root 4096 Nov 13 23:49 uevent
-r--r--r-- 1 root root 4096 Nov 13 23:52 vendor
> So the drivers listing, and lsmod are showing that cirrusfb is loaded, but
> lspci -vvv is not? Contradictory - again, is this the domu with the resolution
> problem?
Yes it is. I have the resolution problem in any case.
> Yeah - the BAR error bothers me. Something is preventing the cirrusfb from
> initializing. Normally you get a handoff from the builtin vesa driver to the
> installed card driver. This is from my baremetal suse system:
>
> fb: conflicting fb hw usage radeondrmfb vs VESA VGA - removing generic driver
>
> BAR errors are not something I have experience with. I'm going to repost this
> section of your post, and see if Fajar has something to say.
OK
On 13 November 2011 18:57, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
>
> If you are installing from a modern install disk, the xorg driver evdev should
> configure your mouse correctly. Check your Xorg.0.log for evdev.
I am using the latest DVD release. No errors reported in the Xorg.0.log file
in the dom0.
> This is kind of old. You say the install worked,
It started... but as I've already said, it blocked.
It is really frustrating that there is not any guide to setup
a OpenSuse PV domU.
Anyway, the config file I use to start the installation is a little
bit different:
name="OpenSuse11"
memory=2048
disk =
['phy:/dev/loop0,hdc:cdrom,r','file:/mnt/xen/vmstore/opensuse11/opensuse11.img,xvda,w'
]
vif = [ 'type=ioemu, mac=00:16:3e:00:00:21, bridge=xenbr0' ]
vfb = [ "type=vnc,vncunused=1,vnclisten=0.0.0.0,keymap=it" ]
kernel = "/mnt/xen/kernel/opensuse/vmlinuz-xen"
ramdisk = "/mnt/xen/kernel/opensuse/initrd-xen"
vcpus=1
on_reboot = 'restart'
on_crash = 'restart'
> even though the config is
> using hdc/hda instead of xvdc/xvda. I'm assuming you changed bridge=eth0, and
> kernel= and ramdisk= to the names on your system.
Of course.
>
> How is this method working out for you? Network and resolution ok?
You already know the answer now.. :(
>
> Keep answers for this install separate from the hvm problems we are working
> on. This gets confusing enough to keep track of as is. ;-)
Of course. Just in case, I will open another discussion on that.
Thank you so much.
--
Flavio
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home