On Tue November 15 2011, 11:10:25 AM, Flavio wrote:
> 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.
That's fine. CONFIG_XEN_NETDEV_FRONTEND is totally irrelevant to a dom0, which
only deal with BACKEND drivers.
> > 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
Thought so.
> > 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.
>
> > 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!!!! <----
Cool beans! One less problem.
> 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.
Yeah - the xennet / xenblk errors are occurring early on on in the boot
process, before the disks are mounted, so the only code it can be executing is
the kernel, and initrd modules & config files. And the initrd creation is in
turn controlled by /etc/sysconfig/kernel. As I said, it can be ignored.
The other two errors are prevented in the 2.6.37 kernel by installing the rpm
package preload-kmp-default, which installs /lib/modules/2.6.37.1-1.2-
default/systemtap/preloadtrace.ko. I don't think there is a corresponding
package for the 3.1 kernel. At least I can't find one in f16, which uses the
3.1 kernel. At any rate, it is a boot optimization routine, and the errors can
be ignored without concern. From 'rpm -qi preload-kmp-default', the
Description field says:
This will work with preload hand in hand to make sure no unnecessary
files are preload.
and 'rpm -qi preload' says:
Preload lists files to load into the system cache. This shortens system
boot time if used correctly.
> Well, now that the networking works, this problem has been solved. Let's go
> back to the resolution problem. :)
Yeah, no response from Fajar, yet. I'll repost the problem with a different
Subject line tomorrow, if no one responds.
> > Your head reeling yet? :-)
>
> LOL, a little bit. :)
>
> On 15 November 2011 00:35, jim burns <jim_burn@xxxxxxxxxxxxx> wrote:
> >> > 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.
Ok. Evdev has nothing to do with resolution, just input peripherals, like
keyboard, mouse, USB. So I'll forget about this.
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home
