From: Russell King <rmk+lkml@arm.linux.org.uk>
To: rafael2k <rafael@riseup.net>
Cc: dahinds@users.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: pcnet_cs problems in ARM handheld
Date: Mon, 11 Apr 2005 20:57:45 +0100 [thread overview]
Message-ID: <20050411205745.B5070@flint.arm.linux.org.uk> (raw)
In-Reply-To: <200504111622.54719.rafael@riseup.net>; from rafael@riseup.net on Mon, Apr 11, 2005 at 04:22:52PM +0000
On Mon, Apr 11, 2005 at 04:22:52PM +0000, rafael2k wrote:
> Hi David and others kernel developers,
> Thanx for your pcnet_cs driver! I use it since old days :-P
>
> I bought a IC-CARD+ pcnet_cs compatible pcmcia nic, and i'm using it on a
> StrongARM HP Jornada 710. My kernel is a 2.4.18-rmk3-hh10 and my pcmcia-cs
> version is 3.1.33
>
> From dmesg I got this messages:
>
> --
> jornada720_pcmcia_configure_socket(): config socket 0 vcc 50 vpp 0
> jornada720_pcmcia_configure_socket(): config socket 0 vcc 50 vpp 0
> eth0: NE2000 Compatible: io 0xc2800300, irq 114, hw_addr 00:80:C8:88:00:56
> eth0: interrupt(s) dropped!
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x96, t=39.
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=55.
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=49.
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=88.
> eth0: interrupt(s) dropped!
> NETDEV WATCHDOG: eth0: transmit timed out
> eth0: Tx timed out, lost interrupt? TSR=0x3, ISR=0x3, t=77.
This looks like a case of the old 2.4 interrupt handling problems
which got resolved by rewriting the ARM interrupt handling
infrastructure during 2.5.
The problem occurs because of the need to handle edge-triggered
interrupts (as is the case with Intel CPUs) differently from
level-triggered interrupts, especially when the peripherals are
designed to be used with level-triggered inputs.
In effect, you can end up with the situation where the device has
its interrupt asserted, but because the CPU doesn't see a change
of state, it "forgets" about the interrupt input.
I'm not aware of a solution for this problem with 2.4 kernels.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
prev parent reply other threads:[~2005-04-11 19:58 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-11 16:22 pcnet_cs problems in ARM handheld rafael2k
2005-04-11 19:57 ` Russell King [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20050411205745.B5070@flint.arm.linux.org.uk \
--to=rmk+lkml@arm.linux.org.uk \
--cc=dahinds@users.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@riseup.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.