Re: [Xen-devel] Xen-Unstable : no eth0 when boot up

[Ian Pratt <Ian.Pratt@xxxxxxxxxxxx>]

> unfortunaly new problems comes. :(
> I noticed long ago that after install xen, 'halt' didn't work, it just acted
> like reboot. So I wanna try it on this 1.3, and it turned that it still just
> reboots the machine. And I trid this on two xen machines, both worked this
> way.

You mean in domain 0?  I think invoking halt/reboot in other
domains does the right thing, though I haven't checked (there's
at least now code for a domain to exit with a code indicating
what action it wants).

Whenever domain 0 exits, Xen reboots the machine. I guess we
could look at the exit code and loop if its a halt.
 
> More serious problems is after this reboot, eth0 lost again. I didn't change
> anything since eth0 was up. I'm sure the .config has set e100=y. So I 'make
> clean' and 'make world' 'make install' again, still didn't work.
> 
> Then I add printk("hello world from e100_init_module\n") in e100_main.c. and
> then just 'make linux-xen0', 'cp /install/boot/vmlinuz-2.4.26-xen0'. From
> dmesg, can see this:
> 
> e100:selftest timeout
> e100:failed to initialize, instance #0
> hello world from e100_init_module
> 
> While if I use just reboot to standard linux or xen 1.2, eth0 works fine.
> Then I changed the grub, use 1.2 kernal+1.3 module, it shows that e100
> selftest ok, eth0 is ready, but surely invalid guest OS image. I also tried
> 1.3 kernal+1.2 module, just didn't go to e100 step. My question here is when
> useing 1.2 kernal+1.3 module, why the 'hello world from e100_init_module'
> didn't appear?

Don't mix different Xen images and OSes -- it won't work. The
hypervisor API has changed.

> After these two tries, I changed the grub back to normal 1.3 kernal+1.3
> module, and, it magically worked, eth0 is back again.

It sounds like that unless your NIC gets a hard reboot, Linux's
e100 driver code won't detect it next time round.  I'm guessing
Xen does a soft reboot when it exits, as its faster and works on
the vast majority of hardware.

I guess we could add a "hardreboot" xen cmdline option, but
rebooting a PC in s/w is a bit of a black art.

Ian

> Then I rebooted again to see what'd happend, and again, eth0 was lost. same
> as the info above. And I tried all these stuff again, still no eth0.But
> still, if I loaded into linux or xen 1.2, it's fine, so it seems not network
> card's problem. And also with another machine, all works well. It's network
> card driver is not e100 though, it's 3c59x.
> 
> Anyone can help? I was rebooting like crazy, really frustrated. :(
> 
> Thanks,
> Yan
> ----- Original Message ----- 
> From: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
> To: "Yan Li" <yan_li00@xxxxxxxxxxx>
> Cc: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>; "Ian Pratt"
> <Ian.Pratt@xxxxxxxxxxxx>; <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
> Sent: Monday, June 28, 2004 11:36 PM
> Subject: Re: [Xen-devel] Xen-Unstable : no eth0 when boot up
> 
> 
> > > ok, now it works. I found you set e100 enabled in defconfig-xen0. So I
> just
> > > cloned it again and build it all over again, and it works fine. Thank
> your
> > > help.
> > > btw, I have a question about how xen handle the system calls. Xen has
> fast
> > > trap mechanism. But when we commented out the line
> > >     "HYPERVISOR_set_fast_trap(SYSCALL_VECTOR);"
> > > in xenolinux-2.4.26/arch/xeno/kernel/traps.c, (talking about 1.2 here)
> > > xen still performed well. So xen must have something to handle system
> calls
> > > from guest OS, right? but we cannot find where it did this. It seems to
> us
> > > xen only defined 0-19, not 128 for system calls.
> >
> > Traps to undefined vectors, or vectors for which the trapper has
> > insufficient privilege, cause a general protection fault (GPF) with a
> > particular type of error code. Xen detects that type of error code
> > and, if the guest OS registered a suitable virtual handler on that
> > vector, virtualises the GPF as a trap of the appropriate type. If teh
> > guest OS didn't, then the GPF is virtualised as a GPF in the usual
> > way. See the "cunning trick" comment in general_protection_fault() in
> > arch/x86/traps.c.
> >
> >  -- Keir
> >
> >



-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel