Breakage in -unstable for Transmeta

Breakage in -unstable for Transmeta

[Carl Holtje ;021;vcsg6;]

All-

In xen/arch/x86/boot/x83_32.S, a great deal has changed since 2.0.6 and
even some recent pulls of the unstable tree. These changes have stoped my
Transmeta efforts cold; the box now reboots upon boot..

I've narrowed it down (at least I think I have) to the following lines
from the start_paging routine:

1:   mov     $idle_pg_table-__PAGE_OFFSET,%eax
2:   mov     %eax,%cr3
3:   mov     $0x80050033,%eax /* hi-to-lo: PG,AM,WP,NE,ET,MP,PE */
4:   mov     %eax,%cr0
5:   jmp     1f

Specifically, it seems to be line 4 from above...

I noticed the memory layout stuff at the bottom (I think thats what it is,
anyways) has undergone a major overhauling, and this code block references
it.. how do I go about diagnosing/fixing this?

For those interested, I have been fairly successful in getting Xen to work
on my OQO.. I hope that fixing this problem will put me back on track and
I'll get a patch in soon.

Help is greatly appreciated.

Thanks!

Carl

- --

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

Re: Breakage in -unstable for Transmeta

[Keir Fraser]

On 22 Jun 2005, at 19:50, Carl Holtje ;021;vcsg6; wrote:

> In xen/arch/x86/boot/x83_32.S, a great deal has changed since 2.0.6 and
> even some recent pulls of the unstable tree. These changes have stoped 
> my
> Transmeta efforts cold; the box now reboots upon boot..
>
> I've narrowed it down (at least I think I have) to the following lines
> from the start_paging routine:

I just diff'ed between 2.0 stable and the unstable versions of that 
file, and there are almost no code changes. Just some additions to 
support PAE (which you will not be building so will not affect you) and 
the data layout changes at the bottom of the file.

The code that you think may be causing your problem is also identically 
present in 2.0.6 so I don't think it can be due to that.

  -- Keir

Re: Breakage in -unstable for Transmeta

[Carl Holtje ;021;vcsg6;]

On Thu, 23 Jun 2005, Keir Fraser wrote:

>
> On 22 Jun 2005, at 19:50, Carl Holtje ;021;vcsg6; wrote:
>
> > In xen/arch/x86/boot/x83_32.S, a great deal has changed since 2.0.6 and
> > even some recent pulls of the unstable tree. These changes have stoped
> > my
> > Transmeta efforts cold; the box now reboots upon boot..
> >
> > I've narrowed it down (at least I think I have) to the following lines
> > from the start_paging routine:
>
> I just diff'ed between 2.0 stable and the unstable versions of that
> file, and there are almost no code changes. Just some additions to
> support PAE (which you will not be building so will not affect you) and
> the data layout changes at the bottom of the file.
>
> The code that you think may be causing your problem is also identically
> present in 2.0.6 so I don't think it can be due to that.

Alright.. So where do you suggest I look to try solving this?.. I was
setting waypoints in x86_32.S by printing a character and it seems to be
that code that it broke at. Since those lines reference the page table
stuff at the bottom, I'm not entirely sure where else to poke at..

I generated a diff between what I know works (on the Transmeta) and my
most recent bk pull -- the changes seem to be more applicable to SMP than
anything else...

Thanks for your help!

Carl

- --

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

Re: Breakage in -unstable for Transmeta

[Keir Fraser]

On 23 Jun 2005, at 21:45, Carl Holtje ;021;vcsg6; wrote:

> Alright.. So where do you suggest I look to try solving this?.. I was
> setting waypoints in x86_32.S by printing a character and it seems to 
> be
> that code that it broke at. Since those lines reference the page table
> stuff at the bottom, I'm not entirely sure where else to poke at..
>
> I generated a diff between what I know works (on the Transmeta) and my
> most recent bk pull -- the changes seem to be more applicable to SMP 
> than
> anything else...

It's hard to believe that things are failing that early. If you put 
your debugging code at the same point(s) in x86_32.S in a working 
version of Xen, does that still work? (i.e., could it be your debugging 
code at fault?)

  -- Keir

Re: Breakage in -unstable for Transmeta

[Carl Holtje ;021;vcsg6;]

On Thu, 23 Jun 2005, Keir Fraser wrote:

>
> On 23 Jun 2005, at 21:45, Carl Holtje ;021;vcsg6; wrote:
>
> > Alright.. So where do you suggest I look to try solving this?.. I was
> > setting waypoints in x86_32.S by printing a character and it seems to
> > be
> > that code that it broke at. Since those lines reference the page table
> > stuff at the bottom, I'm not entirely sure where else to poke at..
> >
> > I generated a diff between what I know works (on the Transmeta) and my
> > most recent bk pull -- the changes seem to be more applicable to SMP
> > than
> > anything else...
>
> It's hard to believe that things are failing that early. If you put
> your debugging code at the same point(s) in x86_32.S in a working
> version of Xen, does that still work? (i.e., could it be your debugging
> code at fault?)

Yes, it still works.. like I mentioned, my code simply writes a character
to the framebuffer.. different characters in different locations provide
waypoints..

The only exception to 'it still works' is if I print waypoint characters
before the multiboot check (because I was using that register)..
everything else works fine..

Thanks!

Carl

- --

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

Re: Breakage in -unstable for Transmeta

[Keir Fraser]

On 24 Jun 2005, at 01:23, Carl Holtje ;021;vcsg6; wrote:

> Yes, it still works.. like I mentioned, my code simply writes a 
> character
> to the framebuffer.. different characters in different locations 
> provide
> waypoints..
>
> The only exception to 'it still works' is if I print waypoint 
> characters
> before the multiboot check (because I was using that register)..
> everything else works fine..

Maybe the pagetable layout has changed. That write to CR0 enables 
paging so if the tables are not in a format that Transmeta likes then 
you would probably fail at that point. But I don't think the initial 
layout differs from 2.0.6...

  -- Keir

Re: Breakage in -unstable for Transmeta

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, Keir Fraser wrote:

>
> On 24 Jun 2005, at 01:23, Carl Holtje ;021;vcsg6; wrote:
>
> > Yes, it still works.. like I mentioned, my code simply writes a
> > character
> > to the framebuffer.. different characters in different locations
> > provide
> > waypoints..
> >
> > The only exception to 'it still works' is if I print waypoint
> > characters
> > before the multiboot check (because I was using that register)..
> > everything else works fine..
>
> Maybe the pagetable layout has changed. That write to CR0 enables
> paging so if the tables are not in a format that Transmeta likes then
> you would probably fail at that point. But I don't think the initial
> layout differs from 2.0.6...

I apologize for being so dense, but how do I go about investigating this
further?

Thanks!

Carl

- --

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

Re: Breakage in -unstable for Transmeta

[Keir Fraser]

On 24 Jun 2005, at 14:30, Carl Holtje ;021;vcsg6; wrote:

>> Maybe the pagetable layout has changed. That write to CR0 enables
>> paging so if the tables are not in a format that Transmeta likes then
>> you would probably fail at that point. But I don't think the initial
>> layout differs from 2.0.6...
>
> I apologize for being so dense, but how do I go about investigating 
> this
> further?

No apology needed -- I really cannot see where a bug has been 
introduced, but assuming your debug code works on one code version 
(2.0.6) and not the other (latest unstable), clearly a bug does exist.

The only good point of the situation is that there isn't actually that 
much code in x86_32.S to be going wrong. It's feasible to check through 
it line by line and compare with 2.0.6 as you go. How about you try 
reducing the number of flags you set in %cr0, or double check that the 
code that creates the initial pagetables really is identical between 
2.0.6 and unstable?

Basically, like with all 'impossible' bugs, you need to think outside 
the box on this one and get a bit more creative/imaginative with your 
debugging strategies. Without having a Transmeta box and time to debug 
it myself, I can't really give any more immediate help with this one 
I'm afraid. There must be some incredibly stupid thing going on that we 
will be amazed we didn't spot sooner. :-)

  -- Keir

Re: Breakage in -unstable for Transmeta

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, Keir Fraser wrote:

>
> On 24 Jun 2005, at 14:30, Carl Holtje ;021;vcsg6; wrote:
>
> >> Maybe the pagetable layout has changed. That write to CR0 enables
> >> paging so if the tables are not in a format that Transmeta likes then
> >> you would probably fail at that point. But I don't think the initial
> >> layout differs from 2.0.6...
> >
> > I apologize for being so dense, but how do I go about investigating
> > this further?
>
> No apology needed -- I really cannot see where a bug has been
> introduced, but assuming your debug code works on one code version
> (2.0.6) and not the other (latest unstable), clearly a bug does exist.
>
> The only good point of the situation is that there isn't actually that
> much code in x86_32.S to be going wrong. It's feasible to check through
> it line by line and compare with 2.0.6 as you go. How about you try
> reducing the number of flags you set in %cr0, or double check that the
> code that creates the initial pagetables really is identical between
> 2.0.6 and unstable?

Is the initial page table creation code in xen/include/asm/page.h?

Thanks!

Carl

- --

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

Re: Breakage in -unstable for Transmeta

[Keir Fraser]

On 24 Jun 2005, at 16:57, Carl Holtje ;021;vcsg6; wrote:

> Is the initial page table creation code in xen/include/asm/page.h?
>
> Thanks!

No, it's this piece of code in x86_32.S (which I've pasted from latest 
xen-unstable, but I think is identical to the code in 2.0.6):

         /* Initialize low and high mappings of all memory with 4MB 
pages */
         mov     $idle_pg_table-__PAGE_OFFSET,%edi
         mov     $0xe3,%eax                  /* PRESENT+RW+A+D+4MB */
1:      mov     %eax,__PAGE_OFFSET>>20(%edi) /* high mapping */
         stosl                                /* low mapping */
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         cmp     $DIRECTMAP_PHYS_END+0xe3,%eax
         jne     1b
1:      stosl   /* low mappings cover as much physmem as possible */
         add     $(1<<L2_PAGETABLE_SHIFT),%eax
         cmp     $__HYPERVISOR_VIRT_START+0xe3,%eax
         jne     1b

  -- Keir

Re: Breakage in -unstable for Transmeta -- Solution

[Carl Holtje ;021;vcsg6;]

Keir-

In xen/include/asm/page.h, revision 1.53 changed a line from:
  #define PAGE_MASK           (~(PAGE_SIZE-1))
to:
  #define PAGE_MASK           (~(intpte_t)(PAGE_SIZE-1))
and caused Bad Things for Transmeta..

Which leads me to my next question...

It seems to me, and please correct me if I'm wrong, the Best Way to fix
this is with something like a #ifndef CONFIG_X86_TRANSMETA {ver 1.53 code}
#else {earlier code} #endif around this. This is what I've done for my other
changes, and seems to work pretty well. So.. where would
CONFIG_X86_TRANSMETA get defined? I've currently got it in xen/Rules.mk as
"CFLAGS += -DCONFIG_X86_TRANSMETA", and am sure it's not the Right Way to
do it..

Thanks!

(Transmeta patch coming RSN.. I'm sure everybody is salivating for it, so
I'll try to keep the wait short... :) )

Carl

- --

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

Re: Breakage in -unstable for Transmeta -- Solution

[Keir Fraser]

On 24 Jun 2005, at 20:22, Carl Holtje ;021;vcsg6; wrote:

> In xen/include/asm/page.h, revision 1.53 changed a line from:
>   #define PAGE_MASK           (~(PAGE_SIZE-1))
> to:
>   #define PAGE_MASK           (~(intpte_t)(PAGE_SIZE-1))
> and caused Bad Things for Transmeta..

That change actually got reverted as it broke PAE. So you may find the 
latest unstable version works better for you.

> It seems to me, and please correct me if I'm wrong, the Best Way to fix
> this is with something like a #ifndef CONFIG_X86_TRANSMETA {ver 1.53 
> code}
> #else {earlier code} #endif around this. This is what I've done for my 
> other
> changes, and seems to work pretty well. So.. where would
> CONFIG_X86_TRANSMETA get defined? I've currently got it in 
> xen/Rules.mk as
> "CFLAGS += -DCONFIG_X86_TRANSMETA", and am sure it's not the Right Way 
> to
> do it..

We don't want to select support for things like Transmeta at compile 
time. We'll have to work out how to make the selection at run time. 
Transmeta chips are fairly fully-featured afaik, so this oughtn;t to be 
hard.

  -- Keir

Re: Breakage in -unstable for Transmeta -- Solution

[Carl Holtje ;021;vcsg6;]

On Fri, 24 Jun 2005, Keir Fraser wrote:

> On 24 Jun 2005, at 20:22, Carl Holtje ;021;vcsg6; wrote:
>
> > In xen/include/asm/page.h, revision 1.53 changed a line from:
> >   #define PAGE_MASK           (~(PAGE_SIZE-1))
> > to:
> >   #define PAGE_MASK           (~(intpte_t)(PAGE_SIZE-1))
> > and caused Bad Things for Transmeta..
>
> That change actually got reverted as it broke PAE. So you may find the
> latest unstable version works better for you.

Ah.. just my luck. ;) Thanks!

> > It seems to me, and please correct me if I'm wrong, the Best Way to fix
> > this is with something like a #ifndef CONFIG_X86_TRANSMETA {ver 1.53
> > code}
> > #else {earlier code} #endif around this. This is what I've done for my
> > other changes, and seems to work pretty well. So.. where would
> > CONFIG_X86_TRANSMETA get defined? I've currently got it in
> > xen/Rules.mk as "CFLAGS += -DCONFIG_X86_TRANSMETA", and am sure it's
> > not the Right Way to do it..
>
> We don't want to select support for things like Transmeta at compile
> time. We'll have to work out how to make the selection at run time.
> Transmeta chips are fairly fully-featured afaik, so this oughtn;t to be
> hard.

Hm.. alright.. To faciliate this thought, the changes I had to make
include (this is from memory, so all may not be exact):

* In xen/arch/x86/boot/x86_32.S, disable FPU initialization
* In xen/arch/x86/boot/x86_32.S, disable PGE enabling
* In xen/{I don't remember}/flushtlb.c, the call to local_flush_tlb or
something of this nature calls __pge_off() and __pge_on -- I used a #ifdef
CONFIG_X86_TRANSMETA to work around it as local_flush_tlb is a #define.
(I'm certainly not saying what I've done is best by any means, but it
works for me..)
* Added support to linux-2.6...-sparse/arch/xen/Kconfig to select
Transmeta support (dependant upon x86-32)
* Failed attempt to select different xen0 config files in the
buildconfigs/mk.linu-2.6-xen0 to grab the Transmeta/OQO config file
* Xen0 & xenU kernel config files

* um.. I think that might have been it.. course, with this, you could
practically write your own patch... :)

And you'd know far better than I about how to support these changes at
runtime than I would..

Thanks!

Carl

- --

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

Re: Breakage in -unstable for Transmeta -- Solution

[Keir Fraser]

On 25 Jun 2005, at 02:57, Carl Holtje ;021;vcsg6; wrote:

> * In xen/arch/x86/boot/x86_32.S, disable FPU initialization
> * In xen/arch/x86/boot/x86_32.S, disable PGE enabling
> * In xen/{I don't remember}/flushtlb.c, the call to local_flush_tlb or
> something of this nature calls __pge_off() and __pge_on -- I used a 
> #ifdef
> CONFIG_X86_TRANSMETA to work around it as local_flush_tlb is a #define.
> (I'm certainly not saying what I've done is best by any means, but it
> works for me..)

The PGE enable, and __pge_off/__pge_on, are easily handled. I'll do a 
patch for those.

Do Transmeta CPUs really not have an FPU unit?

  -- Keir

Re: Breakage in -unstable for Transmeta -- Solution

[Carl Holtje ;021;vcsg6;]

On Sat, 25 Jun 2005, Keir Fraser wrote:

>
> On 25 Jun 2005, at 02:57, Carl Holtje ;021;vcsg6; wrote:
>
> > * In xen/arch/x86/boot/x86_32.S, disable FPU initialization
> > * In xen/arch/x86/boot/x86_32.S, disable PGE enabling
> > * In xen/{I don't remember}/flushtlb.c, the call to local_flush_tlb or
> > something of this nature calls __pge_off() and __pge_on -- I used a
> > #ifdef
> > CONFIG_X86_TRANSMETA to work around it as local_flush_tlb is a #define.
> > (I'm certainly not saying what I've done is best by any means, but it
> > works for me..)
>
> The PGE enable, and __pge_off/__pge_on, are easily handled. I'll do a
> patch for those.
>
> Do Transmeta CPUs really not have an FPU unit?

No, they do in fact have FPUs.. it is my understanding they are
initialized auto-magically by the CPU, and a subsequent initialization
from software totally confused the device, and it reset.

I'm workin' on a proper patch -- I'm in and out of the office all week, so
it may take me a bit..

Thanks!

Carl

- --

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