Subject: Re: blocked interrupts (was CVS commit: src/sys/arch/arc)
To: Izumi Tsutsui <tsutsui@ceres.dti.ne.jp>
From: Garrett D'Amore <garrett_damore@tadpole.com>
List: port-mips
Date: 11/17/2005 16:46:26
I wonder if this is related to an interrupt problem with PCI on the
Au1550 core I'm currently debugging.  It manifests with network cards
taking 1 full second to respond to ping.  Increasing the ping frequency
seems to solve this problem.  However until it is solved, simple things
like a single telnet session have unacceptably poor performance.  (1
second latency!)

This is seen with both wi and bge.

I've been assuming a problem with PCI interrupt routing or with the
external interrupt controller logic, but I can't see any significant
difference in that code from the Linux code (which I presume works.)

Maybe I need to look deeper....

    -- Garrett

Izumi Tsutsui wrote:

>In article <20051117214050.7104C23403@thoreau.thistledown.com.au>
>simonb@wasabisystems.com wrote:
>
>  
>
>>>>	-   if (ipending & INT_MASK_REAL_DEV) == 0,
>>>>	    softnet() and softclock() are handled with all interrupt disabled.
>>>>		-> overblocking, possibly causes missing hardclock()
>>>>        
>>>>
>>>XXX: It seems some other mips ports (algor, evbmips, pmax, sgimips)
>>>XXX: also have the similar problem.
>>>      
>>>
>>I believe algor, evbmips and pmax get this right.  In these ports,
>>cpu_intr() calls a machine-specific *_iointr(),
>>    
>>
>
>Only if ((ipending & MIPS_INT_MASK_*) != 0) ?
>
>_clearsoftintr() should set MIPS_SR_INT_IE too?
>---
>Izumi Tsutsui
>  
>


-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134