Xen devel - Mar 2004 - Via Cyrix 3 II / CentaurHauls Nehemiah support

Hi,

Now that I''ve tested the fixed RTL8139 network driver to work on my
laptop, I want to try and demo Xen on a mini PC I have with the same
card.  However it''s got a Via Nehemiah CPU, so Xen complains with
"Only
support Intel processors (P6+)".

I think it''s supposed to be 686 class processor - "uname
-mpi" reports
"i686 i686 i386".  I remember the earlier C3 also claimed to be a 686
but was missing the cmov instruction gcc apparently assumed to be
present, so only i586 binaries worked.  However the attached
/proc/cpuinfo from the new Nehemiah includes cmov, and sure enough both
i686 kernels and executables are running fine.

Hacking xen/arch/i386/setup.c to allow the chip seems to boot Xen fine
without the warning.  However adding processor support to
xenolinux-2.4.25/arch/xeno/config.in results in xenolinux kernels that
immediately hang starting DOM0 when built for 686, CYRIXIII or VIAC3_2. 
Passing "watchdog" to Xen didn''t report any extra help to the
screen on
stalling.

Any thoughts on how I could fix support for this processor please?

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject

> I think it''s supposed to be 686 class processor - "uname
-mpi" reports
> "i686 i686 i386".  I remember the earlier C3 also claimed to be a
686
> but was missing the cmov instruction gcc apparently assumed to be
> present, so only i586 binaries worked.  However the attached
> /proc/cpuinfo from the new Nehemiah includes cmov, and sure enough both
> i686 kernels and executables are running fine.
> 
> Hacking xen/arch/i386/setup.c to allow the chip seems to boot Xen fine
> without the warning.  However adding processor support to
> xenolinux-2.4.25/arch/xeno/config.in results in xenolinux kernels that
> immediately hang starting DOM0 when built for 686, CYRIXIII or VIAC3_2. 
> Passing "watchdog" to Xen didn''t report any extra help
to the screen on
> stalling.
> 
> Any thoughts on how I could fix support for this processor please?
What happens if you try to boot an unmodified standard Xenolinux
image? I would expect that you would see output from DOM0 but it will
then panic about an unrecognised CPU type. If you see no output from
DOM0 at all then that is weird.

 -- Keir
> Cheers,
> 
> Sean.
> 
> -- 
> Sean Atkinson <sean@netproject.com>
> Netproject
>    Press C-c C-c here to receive file transmission
 -=- MIME -=- 

--=-XatUKqAoDuY5c0w1CG7Q
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Hi,

Now that I''ve tested the fixed RTL8139 network driver to work on my
laptop, I want to try and demo Xen on a mini PC I have with the same
card.  However it''s got a Via Nehemiah CPU, so Xen complains with
"Only
support Intel processors (P6+)".

I think it''s supposed to be 686 class processor - "uname
-mpi" reports
"i686 i686 i386".  I remember the earlier C3 also claimed to be a 686
but was missing the cmov instruction gcc apparently assumed to be
present, so only i586 binaries worked.  However the attached
/proc/cpuinfo from the new Nehemiah includes cmov, and sure enough both
i686 kernels and executables are running fine.

Hacking xen/arch/i386/setup.c to allow the chip seems to boot Xen fine
without the warning.  However adding processor support to
xenolinux-2.4.25/arch/xeno/config.in results in xenolinux kernels that
immediately hang starting DOM0 when built for 686, CYRIXIII or VIAC3_2. 
Passing "watchdog" to Xen didn''t report any extra help to the
screen on
stalling.

Any thoughts on how I could fix support for this processor please?

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject

--=-XatUKqAoDuY5c0w1CG7Q
Content-Disposition: attachment; filename=cpuinfo
Content-Type: application/octet-stream; name=cpuinfo
Content-Transfer-Encoding: 7bit


--=-XatUKqAoDuY5c0w1CG7Q--



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> What happens if you try to boot an unmodified standard Xenolinux
> image? I would expect that you would see output from DOM0 but it will
> then panic about an unrecognised CPU type. If you see no output from
> DOM0 at all then that is weird.
Using my patched xen.gz to support the CPU but with the standard
xenolinux.gz from a demo CD I get the same behaviour using console=tty0
- no output after "(XEN) DOM0: Guest OS virtual load address is
c0000000".  However without any console= argument or using console=vga I
see this too:

*** Serial input -> DOM0 (type ''CTRL-a'' to switch input to
Xen).
Domain 0 killed: rebooting machine!
Reboot disabled on cmdline: require manual reset

Does that help?

-- 
Sean Atkinson <sean@netproject.com>
Netproject



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> > What happens if you try to boot an unmodified standard Xenolinux
> > image? I would expect that you would see output from DOM0 but it will
> > then panic about an unrecognised CPU type. If you see no output from
> > DOM0 at all then that is weird.
> 
> Using my patched xen.gz to support the CPU but with the standard
> xenolinux.gz from a demo CD I get the same behaviour using console=tty0
> - no output after "(XEN) DOM0: Guest OS virtual load address is
> c0000000".  However without any console= argument or using console=vga
I
> see this too:
> 
> *** Serial input -> DOM0 (type ''CTRL-a'' to switch
input to Xen).
> Domain 0 killed: rebooting machine!
> Reboot disabled on cmdline: require manual reset
> 
> Does that help?
Make a debug build of Xen (edit arch/i386/Rules.mk and get rid of
-DNDEBUG). You will then get some output when DOM0 crashes (you may
want to specify ''noreboot'' on Xen''s command line).

Boot DOM0 without console=tty0 to get this output (or Xen gives up the
VGA console).

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,
> > > What happens if you try to boot an unmodified standard Xenolinux
> > > image? I would expect that you would see output from DOM0 but it
will
> > > then panic about an unrecognised CPU type. If you see no output
from
> > > DOM0 at all then that is weird.
Reading other posts on the list I just realised this was never going to
work anyway, since Xen 1.3 silently fails with a 1.2 DOM0 as used on the
demo CD.  However I got similar results using the correct version as
well.
> Make a debug build of Xen (edit arch/i386/Rules.mk and get rid of
> -DNDEBUG). You will then get some output when DOM0 crashes (you may
> want to specify ''noreboot'' on Xen''s command
line).
Only get a couple more lines now:

DOM0: Guest OS virtual load adderss is c0000000
*** Serial input -> DOM0 (type ''CTRL-a'' to switch input to
Xen).
(file=schedule.c, line=264) DOM0 killed itself!
(file=schedule.c, line=265)  EIP = c0008b69
Domain 0 killed: rebooting machine!
Reboot disabled on cmdline: require manual reset

Perhaps I need to add some debugging to xenolinux too, or is that not
even getting started?

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Boot DOM0 without console=tty0 to get this output (or Xen gives up the
> VGA console).
Sorry - I only just tried this.  I noticed that
xenolinux-sparse/arch/xeno/kernel/setup.c panics if the vendor''s not
AMD
or Intel, and wondered why I hadn''t seen this on the C3-II.  Sure
enough
adding "console=tty0" enables the DOM0 output as expected, so
I''ll try
and hack it into submission now...

-- 
Sean Atkinson <sean@netproject.com>
Netproject



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Hi,

Fixed!  Attached is a patch for the current unstable tree to enable
support for the Via C3-II.  It allows the CPU in Xen itself, adds it to
the Xenolinux CPU config (although this is equivalent to a regular 686
for now), and also lets Xenolinux initialise it.  I just copied the
relevant sections of code from the regular Linux source, and it seems to
work fine.

Also attached are dmesg outputs from patched Xen and DOM0 running on the
Nehemiah, plus /proc/cpuinfo from Red Hat 9 and DOM0.  Apart from the
CPU MHz changing slightly (as they often do between reboots), I notice
DOM0 also includes the xstore flag and that the bogomips are almost 10
times the MHz, rather than almost double.  Other than that it all looks
pretty standard, which is comforting.

Incidentally I also had to connect a PS/2 keyboard since the USB
keyboard wasn''t recognised.  Somehow both then allowed input, although
the Num Lock changes only affected the PS/2 keyboard which prevented the
right side of the USB keyboard from being used for letters (it''s a mini
laptop style thing and defaults to Num Lock on).  Are there any thoughts
on adding USB support yet?

Cheers,

Sean.

-- 
Sean Atkinson <sean@netproject.com>
Netproject

> Hi,
> 
> Fixed!  Attached is a patch for the current unstable tree to enable
> support for the Via C3-II.  It allows the CPU in Xen itself, adds it to
> the Xenolinux CPU config (although this is equivalent to a regular 686
> for now), and also lets Xenolinux initialise it.  I just copied the
> relevant sections of code from the regular Linux source, and it seems to
> work fine.
Cheers. We should probably make the default such that it prints a
big warning message if it doesn''t know about the CPU, but then
has a go booting anyway. We could have an exclusion list of
things we know don''t work e.g. 586 or older. Want to update your
patch? ;-)
> Also attached are dmesg outputs from patched Xen and DOM0 running on the
> Nehemiah, plus /proc/cpuinfo from Red Hat 9 and DOM0.  Apart from the
> CPU MHz changing slightly (as they often do between reboots), I notice
> DOM0 also includes the xstore flag and that the bogomips are almost 10
> times the MHz, rather than almost double.  Other than that it all looks
> pretty standard, which is comforting.
Interesting about the bogomips. I haven''t looked too closely at
what other CPUs do. I suspect its a generic problem in the xeno
setup code, but I doubt it has any real consequence.
 
> Incidentally I also had to connect a PS/2 keyboard since the USB
> keyboard wasn''t recognised.  Somehow both then allowed input,
although
> the Num Lock changes only affected the PS/2 keyboard which prevented the
> right side of the USB keyboard from being used for letters (it''s a
mini
> laptop style thing and defaults to Num Lock on).  Are there any thoughts
> on adding USB support yet?
I suspect the BIOS is making the USB keyboard look like PS/2.

Native USB support for Xen will be rather easier in the new IO
model, but its not currently high on our priority list.

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel