Subject: Re: com rumblings...
To: Bill Studenmund <firstname.lastname@example.org>
From: Garrett D'Amore <email@example.com>
Date: 06/20/2006 16:05:07
David Laight wrote:
> On Mon, Jun 19, 2006 at 06:45:28PM -0700, Bill Studenmund wrote:
>>> (The 'easy' way is to connect the IRQ line from the UART to a logic
>>> analiser timing port, set it to trigger on the signal being active
>>> for > some_time, connect the trigger-out of the analiser to the systems
>>> NMI line, and use the NMI to enter ddb, then look at the traceback.)
>> Actually, mac68k has seen the same issue. I've seen anticdotal problems
>> springing up in the 1.5/1.6 time frame.
>> Another way to test this is to instrument splx() so that it remembers the
>> IPL it is dropping from. Then when you see an overflow, you ask the IPL
>> code what level splx last left, and you know what IPL is your issue.
> The PL level splx() is dropping from isn't relevant.
> You need the PC that the ISR interrupted (and if in splx where that
> was called from), and the ISR that executed immediately previously.
> None of which is actually that hard to get.
Assuming you have a system which exhibits this behavior. I don't. :-)
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191