At 12:37 AM -0800 3/12/03, David Gatwood wrote:
>On Wed, 5 Mar 2003, Henry B. Hotz wrote:
>
>>  At 3:41 PM -0500 3/5/03, der Mouse wrote:
>>  >  > My understanding is that the problem affected most 68K Macs, and that
>>  >>  it was caused by the clock interrupt having the lowest priority
>>  >>  rather than (as would be usual) the highest.
>>  >
>>  >I have a IIci which suffers from _something_ of the sort.  When sitting
>>  >idle it keeps moderately good time, but put it under any sort of load
>>  >and it starts losing ticks like mad.
>>
>>  No "something" about it.  That's the problem.  Time interrupts are
>>  blocked during any disk or Ethernet access.  MacOS works around the
>>  problem by rereading the RTC after every floppy access, and elsewhere
>>  as well probably.
>
>Well, that's oversimplifying things slightly.  There are two problems,
>which when combined, result in this issue.  The first is a poor priority
>scheme.  The second is high latency interrupt handler routines.  Fix
>either one, and you fix the problem.

I think the bigger issue (for the second) is the data copy loop that 
substitutes for DMA.  That runs on an interrupt doesn't it?  And the 
clock would be locked out while it runs.

>Which reminds me, last time I tried to solve this problem, I was having
>problems with panics when creating kernel threads during early boot.
>Does anybody have any idea how to get around that?  I need a thread to be
>marked as "ready to run" so that it can potentially be scheduled as soon
>as interrupts are turned on.  Is there a right way to do that?

Sorry, can't help with that one.
-- 
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu