archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <>
To: DHollenbeck <>
Cc:, Alan Cox <>,
Subject: Re: yenta_socket rapid fires interrupts
Date: Tue, 11 Jan 2005 13:40:34 -0800 (PST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, 11 Jan 2005, DHollenbeck wrote:
> only the last several lines were caught.  There is toggling between two 
> states, the very first state was not captured.

That's fine. This is interesting:

> yenta: event 00000000 state 30000006 csc 00

30000006 means (apart from the socket voltage information) "CB_CDETECT1 | 
CB_CDETECT2", which just means that a socket detect is pending.

> yenta: event 00000000 state 30000829 csc 00

And this means "CB_CARDSTS | CB_PWRCYCLE | CB_CBCARD | CB_3VCARD", ie that
it's become ready, powered, 32-bit card at 3.3V. Goodie. Everything looks 
fine, as far as I can tell.

But then something makes it back to detect pending again:

> yenta: event 00000000 state 30000006 csc 00

and it bounces between those two states forever. 

That certainly would seem to explain why you get a lot of interrupts, 
except the actual "event" flags are never set, so afaik it wasn't actually 
this yenta controller that sent those events in the first place. In fact, 
at no point would "yenta_events()" have returned non-zero, which is why 
the Yenta driver says "this interrupt was not for me".

What I don't see is why the port changes state, then. Since the yenta 
driver doesn't care for the interrupt anyway, it shouldn't be touching the 
hardware, and if it doesn't touch the hardware, then the pcmcia thing 
should eventually just calm down, even if it were to de-bounce a few 

The above is what you'd likely see if somebody was forcing a reset on the
card or a card voltage re-interrogation all the time, which I don't see
why it would happen.

Can you change the "#if 0" at top of yenta_socket.c (around the debug 
thing), into a "#if 1"? That will make it _really_ noisy and totally 
unusable, but since it's unusable already.. I'd like to see what the 
accesses are in a full "cycle" of those bounces.

And don't worry about capturing the whole log - the only thing that I'm 
interested in is one full cycle (from likely 5000 of them - since every 
other interrupt is in the reset state, and every other is PWRCYCLE).


  reply	other threads:[~2005-01-11 21:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-10 17:33 yenta_socket rapid fires interrupts DHollenbeck
2005-01-10 19:24 ` Alan Cox
2005-01-11  3:17 ` Linus Torvalds
2005-01-11 19:18   ` DHollenbeck
2005-01-11 19:46     ` Grzegorz Kulewski
2005-01-11 19:54     ` Linus Torvalds
2005-01-11 21:16       ` DHollenbeck
2005-01-11 21:40         ` Linus Torvalds [this message]
2005-01-13 14:13           ` Stefan Seyfried
2005-01-13 15:42             ` DHollenbeck
2005-01-13 15:59             ` DHollenbeck
2005-01-11 21:38       ` DHollenbeck
2005-01-11 21:43         ` Linus Torvalds
2005-01-11 22:32           ` DHollenbeck
2005-01-12  0:03             ` Linus Torvalds
2005-01-12 23:14               ` DHollenbeck

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).