Hi;
Todd L. Miller wrote:
> First, a quick question: did I fluff my cvs update, or has none of
> the gc stuff made it in yet?
I sent a message to the list earlier today asking whether I should
commit the new gc stuff given that it doesn't work too well on the i386
build, and I haven't heard Word One (oh, we're computer types -- Word
Zero) about whether I should. (See more below...)
> About interupt eight: the reason Bad Things happened to the i386
> build is that the clock interrupt fires before everything (i.e. the
> static variables interrupts.intXXX) is ready. Testing with all the tests
> off (except the console drivers, which need work, btw) and w/o the
> function trace reveals that the java_word slurped up from
> interrupts.int008, the one that's supposed to be an interrupt object, is
> in fact a null object, so that when the threadable object is cast out of
> it, Bad Things happen.
OK. A couple of questions --
(1) The "static variables" are exactly which ones? We shouldn't have
any static variables that require initialization code to be run -- given
the limitations of the current initialization code, it *won't* be run
for the i386 target.
(2) I should've disabled interrupts (*all* interrupts) at head.s86 on
line 124 (on my copy). Theoretically (famous last words), there
shouldn't be any interrupts happening until about line 161 in entry.cc
(after the assignInterrupts() call). If this isn't the case, something
weird is going on, and it needs to be tracked down. Maybe I need to
disable them really early -- but I think that *not* having interrupts
enabled breaks the BIOS calls.
> At any rate, on my Celery 400, this happens three times before the
> initialization goes through, and everything seems to work fine. The
> current check & abort correction I've got set up [ if ( jw.isNull() ) {
> kprintf(...); return; } ]* is rather kludgy. I'd imagine that we could
> forcibly initialize the interrupts class before start()ing the scheduler,
> but I'm not sure what this would do to the system or the classes required
> by the clock driver. What might work best is to offer a
> jos.system.machine method switching off/on native clock handling, so that
> init() could handle what was necessary to ensure the clock-handler was
> ready before it was allowed to run.
>
> I haven't committed the changed scheduler.cc in light of my
> uncertainty about the correctness of my tree at this point; I've just
> moved into a new Slackware 4.0 system and I'm still being very careful
> about things.
>
> I'll be trying the new vga driver later tonight and doing a bit of
> fiddling with the console driver(s).
Let me know what the status of your i386 build is, so I can tell whether
I'm either degrading things terribly, or the new changes are no-ops.
Like I said, I'm sitting on a whole bunch of changes...
-jm
--
==== John Morrison ==== [EMAIL PROTECTED] == http://www.mak.com/welcome.html
==== MaK Technologies Inc., 185 Alewife Brook Pkwy, Cambridge, MA 02138
==== vox:617-876-8085 x115
==== fax:617-876-9208
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
