Xen devel - May 2005 - Xen & Transmeta (from xen-users)

All-

With suggestions from Ian and previous posts on this list, I''ve been
investigating why Xen causes a Transmeta-based system to reboot immediately..

I''ve added instrumentation to xen/arch/x86/boot/x86_32.S (a
collection of ''.asciz "foo"'' statements) hoping to
locate a point of
failure.. and it dies sometime before this code is run..

At what point does Xen take over from the "normal" linux kernel?

I guess my approach at this point is to start ''at the
begining'', and try
to trace where things get run in bringing up the Xen kernel.. it''s
clear
it''s before any C code is run, and seems to be before a good deal of
this
assembler is run, too..

Any suggestions/ideas on how to track this down?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Carl Holtje ;021;vcsg6; wrote:
> At what point does Xen take over from the "normal" linux kernel?
it boots first ... is xen exploding before it starts the linux kernel? 

You might want to see what MSRs xen is using, and if they are supported on 
whatever transmeta you have.

ron

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

You don''t have a POST card, do you? What kind of machine is this in. I 
think you''re in for some low-level debug  fun, and POST cards are handy
for such.

ron

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 24 May 2005, at 16:20, Carl Holtje ;021;vcsg6; wrote:
> Any suggestions/ideas on how to track this down?
>
> Thanks!
Connect a null modem serial cable and outb printable characters to 
0x3f8 at various points in the assembly code (immediately followed by 
an infinite loop, or characters may not be emitted on the serial line 
before the system crashes). As you say it crashes pretty early, so you 
won''t have to move the debug output around very much to work out which 
instruction is causing the crash.

  -- keir




_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Ronald G. Minnich wrote:
>
> You don''t have a POST card, do you? What kind of machine is this
in. I
> think you''re in for some low-level debug  fun, and POST cards are
handy
> for such.
This is an OQO -- can''t get a POST card in.. :)

Thanks, though!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Keir Fraser wrote:
>
> On 24 May 2005, at 16:20, Carl Holtje ;021;vcsg6; wrote:
>
> > Any suggestions/ideas on how to track this down?
> >
> > Thanks!
>
> Connect a null modem serial cable and outb printable characters to
> 0x3f8 at various points in the assembly code (immediately followed by
> an infinite loop, or characters may not be emitted on the serial line
> before the system crashes). As you say it crashes pretty early, so you
> won''t have to move the debug output around very much to work out
which
> instruction is causing the crash.
This is an OQO, so I don''t have the facilities to plug a serial cable
into... can I do anything over USB at this level?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Carl Holtje ;021;vcsg6; wrote:
> This is an OQO -- can''t get a POST card in.. :)
ah, then do what keir said -- the outb 0x3f8 route. There''s nothing
like a
serial to make life better. Uh, does OQO have serial? 

ron

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Carl Holtje ;021;vcsg6; wrote:
> This is an OQO, so I don''t have the facilities to plug a serial
cable
> into... can I do anything over USB at this level?
ah, the pain. 

You can do USB at this level, but it''s not fun. You can look at some of
the open source bioses out there to see how to get usb going in early 
assembly. 

Another good option. -- does the thing have a speaker you can have beep?

ron

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> > This is an OQO, so I don''t have the facilities to plug a
serial cable
> > into... can I do anything over USB at this level?
An OQO?  *drool*  I bet nobody has ever tried Xen on one of those before :-)
> ah, the pain.
>
> You can do USB at this level, but it''s not fun. You can look at
some of
> the open source bioses out there to see how to get usb going in early
> assembly.
I don''t suppose you can find another Transmeta machine to test this on?
Or is
anyone else out there actually running on Transmeta at the moment?
> Another good option. -- does the thing have a speaker you can have beep?
Yes, that''d be favourite if the OQO supports something as arcane as a
PC
Speaker - just have your debug output beep to say "I''m still
alive!".  I
imagine you can cause a beep reasonably simply from the ASM, although I
don''t
know how ;-)

What have you tried so far?  Have you tried removing use of the global bits as 
Ian suggested?  Have you hacked the CPUid checks to allow the Transmeta, or 
is it definitely not booting that far?

Cheers,
Mark

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 24 May 2005, at 16:31, Carl Holtje ;021;vcsg6; wrote:
>> Connect a null modem serial cable and outb printable characters to
>> 0x3f8 at various points in the assembly code (immediately followed by
>> an infinite loop, or characters may not be emitted on the serial line
>> before the system crashes). As you say it crashes pretty early, so you
>> won''t have to move the debug output around very much to work
out which
>> instruction is causing the crash.
>
> This is an OQO, so I don''t have the facilities to plug a serial
cable
> into... can I do anything over USB at this level?
Worst case: does it fail by crashing and rebooting? If so, then you 
could move an infinite loop around in the boot assembly code and 
observe whether the system reboots or hangs. When the behaviour changes 
you have found the offending instruction.

If it fails by hanging you can instead add an instruction that causes a 
reboot crash (e.g., invalid opcode like ud2) and move that around in 
the assembly code.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Ronald G. Minnich wrote:
> 
> On Tue, 24 May 2005, Carl Holtje ;021;vcsg6; wrote:
> 
>>This is an OQO -- can''t get a POST card in.. :)
> 
> 
> ah, then do what keir said -- the outb 0x3f8 route. There''s
nothing like a
> serial to make life better. Uh, does OQO have serial? 
If you have a VGA screen connected you can write some characters to the 
VGA console buffer, if I recall correctly that is mapped at 0xb8000 
before paging gets enabled.

Jacob

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Jacob Gorm Hansen wrote:
> If you have a VGA screen connected you can write some characters to the VGA
> console buffer, if I recall correctly that is mapped at 0xb8000 before
paging
> gets enabled.
> 
oh, man, great idea! I always forget this because with linuxbios vga is 
the last thing you get. 

Attached is a (short) piece of code we used to use for this purpose, when 
we were doing early work.

It is so short I hope the list does not mind -- others of you might find 
it useful too. We got a lot of use out of it. 

In video_init, just comment ou the vga_hardware_fixup(). Also vidmem 
should probably be set to B8000. 
i.e. 
static char *vidmem = VIDBUFFER;


ron


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 24 May 2005, Jacob Gorm Hansen wrote:
> Ronald G. Minnich wrote:
> >
> > On Tue, 24 May 2005, Carl Holtje ;021;vcsg6; wrote:
> >
> >>This is an OQO -- can''t get a POST card in.. :)
> >
> >
> > ah, then do what keir said -- the outb 0x3f8 route. There''s
nothing like a
> > serial to make life better. Uh, does OQO have serial?
>
> If you have a VGA screen connected you can write some characters to the
> VGA console buffer, if I recall correctly that is mapped at 0xb8000
> before paging gets enabled.
Writing characters is what ultimately worked for me..

I''ve gotten things a little happier with Xen on the OQO.. I want to get
it
working or give up entirely before I show my hand, though..

Using the grub config suggestion, I have an entry as thus:

label xen
  root (hd0,0)
  kernel /xen.gz dom0_mem=64M
  module /vmlinuz-2.6.11-xen0 ro root=LABEL=/

When Xen boots, I am greeted with the message ''ERR: Not a MultiBoot
bootloader!'', followed by it telling me that /xen.gz is a
multiboot-elf,
and module vmlinuz-2.6.11-xen0 is a multiboot-module.. (from
xen/arch/x86/boot/x86_32.S)

Can anybody help make heads or tails of this? It may, in all honesty, be
grub itself.. this has a full install of FC3, and we all know how
RH/Fedora likes to hack up packages..

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 25 May 2005, at 19:39, Carl Holtje ;021;vcsg6; wrote:
> When Xen boots, I am greeted with the message ''ERR: Not a
MultiBoot
> bootloader!'', followed by it telling me that /xen.gz is a 
> multiboot-elf,
> and module vmlinuz-2.6.11-xen0 is a multiboot-module.. (from
> xen/arch/x86/boot/x86_32.S)
>
> Can anybody help make heads or tails of this? It may, in all honesty, 
> be
> grub itself.. this has a full install of FC3, and we all know how
> RH/Fedora likes to hack up packages..
Only the first line is from Xen: the other two are left over from GRUB 
itself (Xen reset the cursor to top of screen, but is failing earlier 
than the point it clears the vga console).

GRUB should be passing a magic number in register %eax. Perhaps changes 
you made to the bootstrap assembly code are clobbering %eax before it 
is checked?

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 25 May 2005, Keir Fraser wrote:
> GRUB should be passing a magic number in register %eax. Perhaps changes
> you made to the bootstrap assembly code are clobbering %eax before it
> is checked?
Yep -- that was it.. I was using %ax for writing ASCII out..

Ok.. next hurdle- the ACPI checksum function (xen/drivers/acpi/tables.c)
is returning zero -- it calculates the sum to be 1536 (0x600). After the
AND with 0xFF, zero results..

This appears to really throw everything else (the remaining ACPI stuff)
off, as other ACPI properties aren''t located/read/understood. This
confusion results in a page fault originating from
xen/drivers/acpi/tables.c#acpi_table_get_sdt ..

I''ve not had a chance to track it further into the method, but I wanted
to
ask the group if they had any idea what was going on/how I can fix
this..

Is this indicative of issues to come, or is this just part of supporting a
new platform?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 26 May 2005, at 21:59, Carl Holtje ;021;vcsg6; wrote:
> Ok.. next hurdle- the ACPI checksum function 
> (xen/drivers/acpi/tables.c)
> is returning zero -- it calculates the sum to be 1536 (0x600). After 
> the
> AND with 0xFF, zero results..
That''s a _good_ thing: returning zero means the checksum was valid. The
checksum is a single byte value, which is why the return value is ANDed 
with 0xff.
> This appears to really throw everything else (the remaining ACPI stuff)
> off, as other ACPI properties aren''t located/read/understood. This
> confusion results in a page fault originating from
> xen/drivers/acpi/tables.c#acpi_table_get_sdt ..
It''s not been thrown off -- the fault is probably due to a table not 
being properly dynamically mapped, or something like that. Look 
carefully where the pointer you are dereferencing originated from.
> Is this indicative of issues to come, or is this just part of 
> supporting a
> new platform?
If the CPU has a local APIC and supports 4MB superpages then it 
oughtn''t to be that hard to get working...

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 26 May 2005, Keir Fraser wrote:
> > This appears to really throw everything else (the remaining ACPI
stuff)
> > off, as other ACPI properties aren''t located/read/understood.
This
> > confusion results in a page fault originating from
> > xen/drivers/acpi/tables.c#acpi_table_get_sdt ..
>
> It''s not been thrown off -- the fault is probably due to a table
not
> being properly dynamically mapped, or something like that. Look
> carefully where the pointer you are dereferencing originated from.
{\NEWBIE ALERT}

First, how do I  get any more information other than ''Unknown
Interrupt''?
(I did this once, but have since forgotten how I got that to work..)

And secondly, how do I make a pointer mean anything to me so I know where
to start looking?

Thanks for your help and understanding..

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 31 May 2005, at 20:47, Carl Holtje ;021;vcsg6; wrote:
> First, how do I  get any more information other than ''Unknown 
> Interrupt''?
> (I did this once, but have since forgotten how I got that to work..)
Move the call to trap_init() in arch/x86/setup.c to just before the 
call to acpi_boot_table_init(). This will initialise the trap table so 
that the proper page fault handler runs and you should get a stack 
backtrace when you crash.
> And secondly, how do I make a pointer mean anything to me so I know 
> where
> to start looking?
If you send the output from the stack backtrace of the crash, and a 
link to your xen-syms image, then we can start to narrow the problem 
down some more.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Tue, 31 May 2005, Keir Fraser wrote:
>
> On 31 May 2005, at 20:47, Carl Holtje ;021;vcsg6; wrote:
>
> > First, how do I  get any more information other than ''Unknown
> > Interrupt''?
> > (I did this once, but have since forgotten how I got that to work..)
>
> Move the call to trap_init() in arch/x86/setup.c to just before the
> call to acpi_boot_table_init(). This will initialise the trap table so
> that the proper page fault handler runs and you should get a stack
> backtrace when you crash.
>
> > And secondly, how do I make a pointer mean anything to me so I know
> > where to start looking?
>
> If you send the output from the stack backtrace of the crash, and a
> link to your xen-syms image, then we can start to narrow the problem
> down some more.
I can certainly do this, but I have one initial problem -- with the small
screen and no scrolling feature, I can''t capture the entire stack
trace.
In fact, I''ve commented out all the stack trace printing stuff to see
what
was above it.. :)

I can get you a register dump, the location the stack trace starts at
(ESP), the call trace from that point, and what it''s determined to be
the
faulty linear address -- is this enough?

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1 Jun 2005, at 14:24, Carl Holtje ;021;vcsg6; wrote:
> I can get you a register dump, the location the stack trace starts at
> (ESP), the call trace from that point, and what it''s determined to
be
> the
> faulty linear address -- is this enough?
Yes. The stack trace is the least useful bit, although it''s sometime 
useful for working out what arguments were passed to functions in the 
backtrace.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 1 Jun 2005, Keir Fraser wrote:
>
> On 1 Jun 2005, at 14:24, Carl Holtje ;021;vcsg6; wrote:
>
> > I can get you a register dump, the location the stack trace starts at
> > (ESP), the call trace from that point, and what it''s
determined to be
> > the
> > faulty linear address -- is this enough?
>
> Yes. The stack trace is the least useful bit, although it''s
sometime
> useful for working out what arguments were passed to functions in the
> backtrace.
Excellent!

The sysms file is available at
[http://www.cs.rit.edu/~cwh0803/xen/xen-2.0-testing-syms].

A note about the symbols -- there are strings I''ve added for
debug/tracing
purposes, most of which are of the form '' -> XXX''...

The debug dump is as follows (let me know if you need more):

========== BEGIN DEBUG DUMP =========Initializing CPU#0
ACPI: RSDP (v000 OID_00                        ) @ 0x000e4010
CPU:            0
EIP:            0808:[<fc5349c0>]
EFLAGS:         00210086
eax:  ffff27c0  ebx:  0e7fb7c0  ecx:  00000000  edx:  00000000
esi:  fc4e4010  edi:  00000024  ebp:  0e7fb7c0  esp:  fc503c20
ds: 0810  es: 0810  fs: 0810  gs: 0810  ss: 0810

Stack Trace from ESP=fc503c20:
{NOT DISPLAYED}

Call Trace from ESP=fc503c20: [<fc525520>] [<fc5237f0>]
[<fc50400c>]
Faulting linear address might be ffff27c4

CPU0 FATAL TRAP 14 (page fault), ERROR_CODE 0009, IN INTERRUPT CONTEXT
=========== END DEBUG DUMP ==========
Please let me know if you need anything else or want me to try stuff..

Thanks for your help!

Carl


- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1 Jun 2005, at 15:08, Carl Holtje ;021;vcsg6; wrote:
> Excellent!
>
> The sysms file is available at
> [http://www.cs.rit.edu/~cwh0803/xen/xen-2.0-testing-syms].
>
> A note about the symbols -- there are strings I''ve added for 
> debug/tracing
> purposes, most of which are of the form '' -> XXX''...
You are dying at line 479 in drivers/acpi/table.c. The reason is that 
you are dereferencing an ACPI header structure that should have been 
mapped using __acpi_map_table() (it''s the call immediately above, at 
line 471).

So, looks like for some reason __acpi_map_table isn''t working properly 
for you which probably also means that set_fixmap isn''t working 
properly. You''ll need to add tracing to __acpi_map_table, and the 
functions that it calls to create the mapping, to find out where things 
are going wrong.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Wed, 1 Jun 2005, Keir Fraser wrote:
> You are dying at line 479 in drivers/acpi/table.c. The reason is that
> you are dereferencing an ACPI header structure that should have been
> mapped using __acpi_map_table() (it''s the call immediately above,
at
> line 471).
>
> So, looks like for some reason __acpi_map_table isn''t working
properly
> for you which probably also means that set_fixmap isn''t working
> properly. You''ll need to add tracing to __acpi_map_table, and the
> functions that it calls to create the mapping, to find out where things
> are going wrong.
Ok.. so this may be a horribly basic question, but what does ''working
properly'' look like -- I mean, how do I know if what I have is right or
wrong?

How do I go about verifying the functionality of set_fixmap and the
subsequent set_pte_phys calls?

It would appear that it locates the header high in the memory space (as it
should according to fixmap.h documentation), but there''s nothing there
for
the subsequent call where it tries to map the table (at least this is how
I understand it -- am I close?)

Thanks for your ongoing help!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 1 Jun 2005, at 18:50, Carl Holtje ;021;vcsg6; wrote:
> Ok.. so this may be a horribly basic question, but what does
''working
> properly'' look like -- I mean, how do I know if what I have is
right or
> wrong?
Try calling show_page_walk(header), where header is the virtual address 
returned by set_fixmap. You should see valid non-zero entries at both 
levels of the pagetable.
> How do I go about verifying the functionality of set_fixmap and the
> subsequent set_pte_phys calls?
>
> It would appear that it locates the header high in the memory space 
> (as it
> should according to fixmap.h documentation), but there''s nothing
there
> for
> the subsequent call where it tries to map the table (at least this is 
> how
> I understand it -- am I close?)
Yes, that''s the problem. The mapping hasn''t happened, or has
happened
at the wrong place in the pagetables, or something like that.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2 Jun 2005, Keir Fraser wrote:
> On 1 Jun 2005, at 18:50, Carl Holtje ;021;vcsg6; wrote:
>
> > Ok.. so this may be a horribly basic question, but what does
''working
> > properly'' look like -- I mean, how do I know if what I have
is right or
> > wrong?
>
> Try calling show_page_walk(header), where header is the virtual address
> returned by set_fixmap. You should see valid non-zero entries at both
> levels of the pagetable.
Ok.. so I''ve ''upgraded'' to using the xen-unstable
tree... and walked into
a bunch more trouble..

I''m totally lost looking at the assembler for
xen/arch/x86/string.c#memset, but that seems to be where my latest
"unknown interrupt" message is coming from (originating from
xen/arch/x86/mm.c#init_frametable)... how do I go about fixing
this?

I moved the init_trap() call in setup.c before this, but don''t get
anything.. must be too early?

Thanks again... your help is definitely appreciated!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 2 Jun 2005, at 22:09, Carl Holtje ;021;vcsg6; wrote:
> Ok.. so I''ve ''upgraded'' to using the
xen-unstable tree... and walked
> into
> a bunch more trouble..
>
> I''m totally lost looking at the assembler for
> xen/arch/x86/string.c#memset, but that seems to be where my latest
> "unknown interrupt" message is coming from (originating from
> xen/arch/x86/mm.c#init_frametable)... how do I go about fixing
> this?
>
> I moved the init_trap() call in setup.c before this, but don''t get
> anything.. must be too early?
>
> Thanks again... your help is definitely appreciated!
Let''s take a step back: does the CPU have all the capabilities that Xen
expects? If you run ''cat /proc/cpuinfo'' on native Linux, do
you see all
the following flags: fpu, pse, tsc, cx8, pge?
Those are the ones I''m pretty sure you''ll run into trouble if
you lack.
If you have all those then we should press on and find the bugs. :-)

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, 2 Jun 2005, Keir Fraser wrote:
>
> On 2 Jun 2005, at 22:09, Carl Holtje ;021;vcsg6; wrote:
>
> > Ok.. so I''ve ''upgraded'' to using the
xen-unstable tree... and walked
> > into
> > a bunch more trouble..
> >
> > I''m totally lost looking at the assembler for
> > xen/arch/x86/string.c#memset, but that seems to be where my latest
> > "unknown interrupt" message is coming from (originating from
> > xen/arch/x86/mm.c#init_frametable)... how do I go about fixing
> > this?
> >
> > I moved the init_trap() call in setup.c before this, but
don''t get
> > anything.. must be too early?
> >
> > Thanks again... your help is definitely appreciated!
>
> Let''s take a step back: does the CPU have all the capabilities
that Xen
> expects? If you run ''cat /proc/cpuinfo'' on native Linux,
do you see all
> the following flags: fpu, pse, tsc, cx8, pge?
> Those are the ones I''m pretty sure you''ll run into
trouble if you lack.
> If you have all those then we should press on and find the bugs. :-)
The only one I don''t have is PGE -- but this should be a performance
thing, not so much a functionality issue, right?

(Here''s the appropriate substring from /proc/cpuinfo: fpu vme de pse
tsc
msr cx8 sep cmov mmx pni longrun lrt)

Thanks!

Carl

- --

"There are 10 types of people in the world: Those who understand binary
and those that don''t."


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On 3 Jun 2005, at 02:13, Carl Holtje ;021;vcsg6; wrote:
> The only one I don''t have is PGE -- but this should be a
performance
> thing, not so much a functionality issue, right?
>
> (Here''s the appropriate substring from /proc/cpuinfo: fpu vme de
pse
> tsc
> msr cx8 sep cmov mmx pni longrun lrt)
It depends whether the CPU is checking the reserved flags and faulting 
if any are set, rather than ignoring the global flag....

A quick thing you can try is to define _PAGE_GLOBAL in 
include/asm-x86/page.h to be 0 rather than 0x100U. This will stop us 
trying to use pge in any page table entries.

The crashes you are seeing are so weird and early that it must be 
something stupid like this that is causing you problems.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

> It depends whether the CPU is checking the reserved flags and faulting 
> if any are set, rather than ignoring the global flag....
>
> A quick thing you can try is to define _PAGE_GLOBAL in 
> include/asm-x86/page.h to be 0 rather than 0x100U. This will stop us 
> trying to use pge in any page table entries.
>
> The crashes you are seeing are so weird and early that it must be 
> something stupid like this that is causing you problems.
If this is the problem then hopefully it is now fixed in the unstable 
repository.

  -- Keir


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel