Subject: Re: Macs faults
To: Henry B. Hotz <hotz@jpl.nasa.gov>
From: David Gatwood <dgatwood@gatwood.net>
List: port-macppc
Date: 03/21/2003 10:13:37
On Wed, 12 Mar 2003, Henry B. Hotz wrote:

> 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.

Yup.  And which shouldn't be running in an interrupt context.  That's the
latency issue I was referring to.  Specifically, the drivers do too much
work with interrupts turned off.


David

---------------------------------------------------------------------
David A. Gatwood                                dgatwood@gatwood.net
Developer Docs Writer                             dgatwood@apple.com
Apple Computer                                  dgatwood@mklinux.org

                    Check out my weekly web comic:
                     http://www.techmagazine.org