WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen-Unstable : no eth0 when boot up
From: "Yan Li" <yan_li00@xxxxxxxxxxx>
Date: Fri, 2 Jul 2004 00:16:30 -0700
Cc: "Ian Pratt" <Ian.Pratt@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxxx>
Delivery-date: Fri, 02 Jul 2004 08:18:10 +0100
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <E1BfCEI-0004Eo-00@xxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
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.

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?

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.

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