9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: "Ronald G. Minnich" <rminnich@lanl.gov>
To: 9fans@cse.psu.edu
Subject: [9fans] ts7200
Date: Fri,  1 Apr 2005 20:54:10 -0700	[thread overview]
Message-ID: <Pine.LNX.4.58.0504012035380.8967@enigma.lanl.gov> (raw)


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.



             reply	other threads:[~2005-04-02  3:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-02  3:54 Ronald G. Minnich [this message]
2005-04-02  3:55 ` Ronald G. Minnich
2005-04-02  6:49 ` Michael Zappe
  -- strict thread matches above, loose matches on Subject: below --
2005-03-26 20:16 [9fans] compilers Tim Newsham
2005-03-27  6:01 ` kazumi iwane
2005-03-28 15:27   ` [9fans] ts7200 Ronald G. Minnich
2005-03-11 15:37 Ronald G. Minnich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.58.0504012035380.8967@enigma.lanl.gov \
    --to=rminnich@lanl.gov \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).