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