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