On Sun November 13 2011, 10:12:00 AM, Flavio wrote:
> On 13 November 2011 01:13, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> > Sorry - I got busy.
>
> No problem!
>
> > Ok - while the domu is running, let's see the output of
> > in dom0: ls -alFR /sys/bus/xen* ; ifconfig ; brctl show ; & netstat -tlp
> > | grep 59
>
> These are the outputs produced when the new 3.1.0 kernel is running and the
> network is not working:
> http://pastebin.com/6yRqnzrh
Mostly looks ok. Just double check - you don't have a xen-netback module
servicing vif2.0, as shown by /sys/bus/xen-backend/drivers/vif (as opposed to
xen-blkback, which is shown servicing what appears to be qdisk-2-768 in
/sys/bus/xen-backend/drivers/vbd). 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.
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.
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.
> > in domu: ls -alFR /sys/bus/xen* ; ifconfig
>
> http://pastebin.com/eaiVdHz0
Looks good. Again, no xen frontend drivers shown. You said that you compiled
the FRONTENDs in 3.1 as builtin, so that's ok. Eth0 correctly has the mac
address you specified in your hvm config, and a 192.168.1 subnet address to
match the 192.168.1.100 address on your dom0 xenbr0.
Assuming everything is builtin that I asked about, this should be working. You
have enough of a network working to have gotten an ipv4 address for your domu
eth0. SuSE has a rather restrictive firewall. As a test, try doing
'rcSuSEfirewall2 stop', and see if that helps. 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.
If none of this works, you may have to break out tcpdump on the tap interface.
I'm no expert with it, 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.
> Now I came back to 2.6.37 (network working) so I can use ssh.
>
> > Ok - in domu, post the output of:
> > lsmod|egrep 'vesa|cirrus'
>
> 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? 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. Which 2.6.37 kernel are you talking about now, that's (mostly) working?
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:
root@Dell4550 11/13/11 11:23AM:~
[545] > file /boot/vmlinu?-2*
/boot/vmlinux-2.6.37.6-0.9-xen.gz: gzip compressed data, was
"vmlinux-2.6.37.6-0.9-xen", from Unix, last modified: Wed Oct 26 11:57:21
2011, max compression /boot/vmlinuz-2.6.37.6-0.9-default: Linux/x86 Kernel,
Setup Version 0x20a, bzImage, Version 2.6.37.6, RO-rootFS, swap_dev 0x3,
Normal VGA
/boot/vmlinuz-2.6.37.6-0.9-xen: gzip compressed data, from Unix, last
modified: Wed Oct 26 11:39:23 2011, max compression
root@Dell4550 11/13/11 11:25AM:~
[546] > cp /boot/vmlinux-2.6.37.6-0.9-xen.gz .
root@Dell4550 11/13/11 11:27AM:~
[547] > cp /boot/vmlinuz-2.6.37.6-0.9-xen .
root@Dell4550 11/13/11 11:27AM:~
[548] > gunzip vmlinux-2.6.37.6-0.9-xen.gz
root@Dell4550 11/13/11 11:27AM:~
[549] > gunzip vmlinuz-2.6.37.6-0.9-xen
gzip: vmlinuz-2.6.37.6-0.9-xen: unknown suffix -- ignored
[1] 27589 exit 2 gunzip vmlinuz-2.6.37.6-0.9-xen
root@Dell4550 11/13/11 11:27AM:~
[550] > mv vmlinuz-2.6.37.6-0.9-xen{,.gz}
root@Dell4550 11/13/11 11:29AM:~
[551] > gunzip vmlinuz-2.6.37.6-0.9-xen.gz
root@Dell4550 11/13/11 11:29AM:~
[552] > file vmlin*
vmlinux-2.6.37.6-0.9-xen: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), statically linked, not stripped
vmlinuz-2.6.37.6-0.9-xen: ELF 32-bit LSB executable, Intel 80386, version 1
(SYSV), statically linked, stripped
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.
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?
> > egrep -i 'vesa|cirrus' /boot/config*
>
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-2.6.37.1-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_BOOT_VESA_SUPPORT=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_CIRRUS=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_UVESA=m
> /boot/config-3.1.0-1.2-desktop:CONFIG_FB_VESA=y
> /boot/config-3.1.0-1.2-desktop:CONFIG_SND_HDA_CODEC_CIRRUS=y
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/drivers/{vesa,cirrus}*
>
> ls: cannot access /sys/bus/pci/drivers/vesa*: No such file or directory
> /sys/bus/pci/drivers/cirrusfb:
> total 0
> drwxr-xr-x 2 root root 0 Nov 13 09:57 ./
> drwxr-xr-x 23 root root 0 Nov 13 09:57 ../
> --w------- 1 root root 4096 Nov 13 09:58 bind
> lrwxrwxrwx 1 root root 0 Nov 13 09:58 module ->
> ../../../../module/cirrusfb/ --w------- 1 root root 4096 Nov 13 09:58
> new_id
> --w------- 1 root root 4096 Nov 13 09:58 remove_id
> --w------- 1 root root 4096 Nov 13 09:57 uevent
> --w------- 1 root root 4096 Nov 13 09:58 unbind
>
> > modprobe cirrusfb
>
> module is already loaded but no errors reported.
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?
> > Let's see which driver is servicing the video card. On my systems,
> > cirrusfb is a module, vesa is builtin. Builtins will not show up as a
> > kernel driver in lspci -vvv. Then we'll see whether the cirrusfb module
> > gets an error on loading.
>
> It seems not during loading even I've found this in the dmesg:
> [ 32.626308] cirrusfb 0000:00:02.0: BAR 0: can't reserve [mem
> 0xf0000000-0xf1ffffff pref]
> [ 32.626312] cirrusfb 0000:00:02.0: cannot reserve region 0xf0000000,
> abort [ 32.626324] cirrusfb: probe of 0000:00:02.0 failed with error -16
> > Hmm - that's an error I would expect with earlier versions of xen. Eg -
> > xen < 3.4.0 can't boot a pvops domu, without backported patches. What
> > distribution is your dom0, and what xen version?
>
> First of all, I say that my dom0 works like a charm with most of my domUs.
> Gentoo Linux x86_64 kernel 3.1.0-gentoo
> app-emulation/xen-4.1.2
> app-emulation/xen-tools-4.1.2
> I'm using xl toolstack.
>
> > Which is what we are checking above.
>
> Mmmh, I think it is not, after having seen the result above :|
> Do you agree?
>
> > Finally, post your full dmesg from your domu. Maybe something will jump
> > out at me.
>
> Yes, here it is: http://pastebin.com/vNpumSik
>
> Thanks a lot,
> --
> Flavio
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.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home