Subject: Re: com rumblings...
To: Bill Studenmund <wrstuden@netbsd.org>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: tech-kern
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
> 	David
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191