On 15 November 2011 00:16, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> 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.
OK, in any case I have CONFIG_XEN_NETDEV_FRONTEND not set in the dom0 kernel
and the network is perfectly working both on other PV and hvm domUs.
> 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.)
# lsmod|grep 8139
8139too 30960 0
8139cp 23939 0
> 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):
[...]
>
> 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.
OK, even I'm not so practical with it.
>
> (Btw, both kernels report the same BAR errors with cirrusfb, and fail, leaving
> (presumably) vesa in charge.)
So, this could be the point where the resolution problem is generated. Anyway,
I still think that something in the suse guest is very wrong, because other
domU work (windows for instance).
[CUT]
> 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' ]
OK, I tried to set model=e1000 for the domU eth0.
kernel-2.6.37:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK
kernel-3.1.0:
00:04.0 Ethernet controller: Intel Corporation 82540EM Gigabit
Ethernet Controller (rev 03)
networking OK!!!! <----
Screenshot just after the domU launch: http://i.imgur.com/T6ICQ.png
It still complains about xennet and xenblk not found and other two
errors. I don't know
what it is.
Well, now that the networking works, this problem has been solved. Let's go back
to the resolution problem. :)
> Your head reeling yet? :-)
LOL, a little bit. :)
On 15 November 2011 00:35, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> I was afraid of that. Worth a try.
No problem, every attempt is licit here!
> Yeah - on my system, the first line is DRIVER=<kernel module>. Further
> evidence that cirrusfb is missing in action.
I don't know what to say here :(
>
>> > No, I mean do you see lines that evdev loaded? 'grep evdev
>> > /var/log/Xorg.0.log'
>>
>> Yes, I see those lines.
>> domU: http://pastebin.com/emieNZxy
>> dom0: http://pastebin.com/WxSdq74i
>>
>
> Your domu install with the nonfunctional mouse none the less has the message:
Just a moment: there is a little bit of confusion now. It's my fault probably.
Get rid of the PV installation where the mouse is not working (it
failed). I abandoned such
setup for now, because it completely freezes my system causing an
emergency sysrq
keys use to reboot. The domU log above comes from the suse with the resolution
problem we are talking about in the main discussion here!
In any case I don't know how to get the Xorg.0.log file from a system which is
pretty unusable and during the installation phase.
Anyway I am planning to retry with this setup.
> Maybe. The mount -o loop doesn't take any significant memory, but each domu
> will. Check with 'xm/xl list'.
I know this, and this is actually strange for me. In any case I only
have one domU
running when performing the setup: the suse I am trying to install.
> Doing an hvm install is going to be slow anyway. I know the fedora installer
> does a lot of thinking picking packages, before it starts installing them,
> and looks like it's hung, and then hvm slows down things even more. Suse
> installers do some thinking, but it's more obvious it's doing something.
I've noticed that too. This is not a great problem. My hope is to finish the
installation and to run the pv domU.
>
> Xen domus have has a problem with hung cpus for sometime now, on multi core
> cpus (SMP code). That's why modern kernels start a khungtaskd process.
I've seen that. I guess this khungtaskd process is not so efficient, because
I am obligued to reboot.
Thanks a lot
Flavio
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home
