Newsgroups: comp.os.minix
Subject: Re: Changing click size in MacMinix
References: <3qxT2.378$Xj7.29407@news.uswest.net>
Organization: Rochester Institute of Technology, Rochester, NY
From: aje9383@osfmail.isc.rit.edu (Andrew Erickson)
NNTP-Posting-Host: grace.isc.rit.edu
X-Original-NNTP-Posting-Host: grace.isc.rit.edu
Message-ID: <371f41c9.0@isc-newsserver.isc.rit.edu>
Date: 22 Apr 1999 11:35:37 -0500
X-Trace: 22 Apr 1999 11:35:37 -0500, grace.isc.rit.edu
Lines: 65
XPident: aje9383
X-Original-NNTP-Posting-Host: 129.21.3.100
XPident: Unknown
Path: star.cs.vu.nl!newsfeed.amsterdam.nl.net!sun4nl!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!news-peer1.sprintlink.net!news-backup-west.sprintlink.net!news.sprintlink.net!isc-newsserver.isc.rit.edu!aje9383
Xref: star.cs.vu.nl comp.os.minix:35351

In article <3qxT2.378$Xj7.29407@news.uswest.net>,
Johnathon McAlister <maccer@uswest.net> wrote:
>OK - I managed to do a bunch of tracing in MacMinix trying to chase down the
>24-bit dependency that's still hiding in the startup code.
>
<Snip--fork() appears to work, but exec() appears to fail>
>
>4) Diagnostic prints in "kernel/exec.c" seem to indicate that the error is
>in the first call to "load_seg", when the text segment is loaded.  Due to
>weird things (see below), I'm not so sure about the results from here on
>out.
>
>5) Diagnostic prints in "load_seg" point to "read" as the culprit.  This
>seems to make sense, since this use of "read" (reading in a segment) does
>strange things to bypass the MM - I'd expect possible problems with
>memory...
>
>6) ...However, diagnostic prints in "read.c" give inconsistent results (dies
>at different places).
>
>A) The error is always the same - "Type 11 error in Finder".  A little odd
>to see Finder as the culprit, but I've seen similar oddities with other
>programming crashes dealing with memory screwups.

A type 11 error is, according to my handy-dandy chart, a "miscellaneous
hardware exception error".  Not much help there. :(

>B) I'm wondering if I've exceeded some "timing granularity", and thus get
>errors at different stages.  I'm not sure about the details...
>
>C) Maybe the crash is a different, parallel process that launches after the
>EXEC starts but before it finishes - is that possible?  Can another process
>(or whatever) interrupt EXEC and crash?  Since the timing might shift
>around, EXEC would seem to die at different places.

The only other process in the system at the momment is the parent process
(the initial init), which immediately does a wait().

It is possible that, during a read, the disk driver could block while
waiting for asynchronous I/O to complete; if this happened, the parent
process would attempt to run.

I'd suggest leaving a debugging message in init.c around the comment
/* Parent just waits. */ (after the fork() but before the wait().  If this
doesn't get printed, there's probably some difficulty in shadowing stuff;
I'd take a good look at what flipclicks() and copyclicks() are doing;  it
seems that stuff isn't getting unshadowed identically to how it was
shadowed.  If it gets printed, of couse, these routines are apparently okay.

This fork() is the first time either of these get used, since it is the
first fork() in the system.

>I'm at a loss at this point - can Macsbug be used to trace the flow of Minix
>at the assembly level?  I'd have a lot more control over the timing issues
>by single stepping through the code, but I'm concerned about how the
>parallel process would be handled.

MacsBug and MacBoot don't work together too well, as the kernel also
provides tracing facilities to processes and all sorts of strange
interactions can and do result.  (I think that's the casue--MacsBug will
most certaily cause panics and the like.)

-- Andrew Erickson, aje9383@grace.isc.rit.edu
May miscellaneous hardware exceptions plague you without end if you insist
on sending me unsolicited commercial e-mail.
