[9fans] ts7200

[9fans] ts7200

[Ronald G. Minnich]

well, it got into main, I think.

What this means is that I got the mmu set up probably right, since I do
turn it on and once it's on, it has to be right or the post code won't
make it out to the POST display.

I'm shocked.

ron

[9fans] compilers

[Tim Newsham]

The compilers share a bit of code through copy-paste.  I was wondering
if there are any important changes in recent years that were made
in a popularly used compiler (ie. 8[cal]) that might benefit other
compilers (ie. k[cal])?

Also, is there any documentation out there other than "How to
Use the Plan 9 C Compiler" and "Plan 9 C Compilers" that cover
the compilers?  I've been perusing the code and some of the
code takes quite a while to figure out.  Some quick notes would
go a long way (ie. "this function is a recursive tree walk that
checks types and inserts casts").

Tim N.

Re: [9fans] compilers

[kazumi iwane]

> in a popularly used compiler (ie. 8[cal]) that might benefit other
> compilers (ie. k[cal])?

It looks like 5[cal] will benefit, too, considering efforts going on for
ts7200 and simpad.

- kazumi

[9fans] ts7200

[Ronald G. Minnich]

it's almost coming up as a cpu server, I just have to finish up making
memory mapping sane.

ron

[9fans] ts7200

[Ronald G. Minnich]

It boots and runs fine. I can drawterm into it. 

IF ... l2 pte does not enable caching. 

I am caching the kernel text and data space (I just enable caching in the 
1 Mbyte L1 PTE for 2 MB of kernel text + data; and the conf.base1 starts 
at the next MB boundary) and that is fine. 

Here's the fun part. 

I have boot.c fork and exec /boot/rc. 

So I have an rc prompt. If caching is enabled, all rc system calls run
fine until the first Rfork from rc. In other words, all the RTC clock and
OS clock interrupts are fine, running at 50hz or so, all the page fault
activity from rc parent and child are fine, fine fine ... until the first
syscall by the parent.  The parent then explodes.

Possibilities:
1. mmuswitch is not working. But I've ripped off the linux code for cache
   writeback/invalidate, and it sure looks right at present.  I can send
   code to this list if there is interest.

2. The more interesting one. Something in the rfork/newproc path is
   setting something up wrong. Reason this could be it is that the two
   procs run fine until the first syscall ... that strikes me as odd. And,
   more interesting, there are a number of context switches back and forth
   between rc parent and rc child (I count 9) and they continue to run. I
   get the impression, looking at this, that they could run all day until
   a syscall and then they would die.  If mmuswitch were really broken I
   would expect that to fail more quickly.  But once the rc parent calls
   Pwrite (why that and not Await, I wonder)  it's all over.  And, even
   more odd, it's always repeatable. Same PC at the failure. 

This is typical:
(syscall debug)
rc:4 pc 15f20, Pwrite: 2014 9008 40 14604
rc: note: sys: trap: fault write va=0x0 pc=0x0001a

Check out the bogus va,pc. Almost like the stack the kernel is seeing is 
junk. And the fd is certainly weird: 2014? 

Wonder if the process stacks are getting trashed up somehow -- but how 
would enabling caching affect this?

ron

p.s. I'm going to italy for the next 10 days (not as long as I'd like)  
but I'll try to catch up on this list and hope some smart person fixes my
problem :-) Have a nice week, everyone, whereever you are.

Re: [9fans] ts7200

[Ronald G. Minnich]

On Fri, 1 Apr 2005, Ronald G. Minnich wrote:

> fine until the first Rfork from rc. In other words, all the RTC clock and

sorry, this is supposed to be:
> fine until the first Rfork from rc. In other words, all the RTC clock and
            ^-after

i.e. the Rfork is fine, but the first syscall after the rfork is very, 
very not fine.

ron

Re: [9fans] ts7200

[Michael Zappe]

Could you send the code when you get the chance?  I've been thinking of
getting one of these guys and porting to it: http://www.gumstix.com/ . 
Nifty little ARM devices!  I've also been working on our port of OpenBSD
to ARM, and going through all of the wonderful fun of getting the caches
to stay coherent.  (I'm working on one of their IXP chips, which has the
added fun of 3 attached microcode engines "Network Processing Engines",
associated coherency problems and a spaghetti-code library to use them. 
Yeesh.)  

I can also take a look and see which of the two scenarios it is.

Have fun in Italy!

    Mike

Ronald G. Minnich wrote:

>It boots and runs fine. I can drawterm into it. 
>
>IF ... l2 pte does not enable caching. 
>
>I am caching the kernel text and data space (I just enable caching in the 
>1 Mbyte L1 PTE for 2 MB of kernel text + data; and the conf.base1 starts 
>at the next MB boundary) and that is fine. 
>
>Here's the fun part. 
>
>I have boot.c fork and exec /boot/rc. 
>
>So I have an rc prompt. If caching is enabled, all rc system calls run
>fine until the first Rfork from rc. In other words, all the RTC clock and
>OS clock interrupts are fine, running at 50hz or so, all the page fault
>activity from rc parent and child are fine, fine fine ... until the first
>syscall by the parent.  The parent then explodes.
>
>Possibilities:
>1. mmuswitch is not working. But I've ripped off the linux code for cache
>   writeback/invalidate, and it sure looks right at present.  I can send
>   code to this list if there is interest.
>
>2. The more interesting one. Something in the rfork/newproc path is
>   setting something up wrong. Reason this could be it is that the two
>   procs run fine until the first syscall ... that strikes me as odd. And,
>   more interesting, there are a number of context switches back and forth
>   between rc parent and rc child (I count 9) and they continue to run. I
>   get the impression, looking at this, that they could run all day until
>   a syscall and then they would die.  If mmuswitch were really broken I
>   would expect that to fail more quickly.  But once the rc parent calls
>   Pwrite (why that and not Await, I wonder)  it's all over.  And, even
>   more odd, it's always repeatable. Same PC at the failure. 
>
>This is typical:
>(syscall debug)
>rc:4 pc 15f20, Pwrite: 2014 9008 40 14604
>rc: note: sys: trap: fault write va=0x0 pc=0x0001a
>
>Check out the bogus va,pc. Almost like the stack the kernel is seeing is 
>junk. And the fd is certainly weird: 2014? 
>
>Wonder if the process stacks are getting trashed up somehow -- but how 
>would enabling caching affect this?
>
>ron
>
>p.s. I'm going to italy for the next 10 days (not as long as I'd like)  
>but I'll try to catch up on this list and hope some smart person fixes my
>problem :-) Have a nice week, everyone, whereever you are.
>  
>