linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@transmeta.com>
To: David Brownell <david-b@pacbell.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: ehci-hcd on CARDBUS hangs when stopping card service
Date: Sat, 25 May 2002 10:54:46 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.44.0205251049380.6515-100000@home.transmeta.com> (raw)
In-Reply-To: <3CEFC6A3.6080002@pacbell.net>



On Sat, 25 May 2002, David Brownell wrote:
>
> Seems to me it'd be worth mentioning this issue somewhere in the
> documentation or source.  One could get the impression that the
> main issue for a CardBus-enabled PCI driver is to make sure that
> the "new style" driver APIs -- with a DEVICE_TABLE etc -- are used.
> (Maybe just a brief comment in <asm/io.h> ...)

Documentation might be a good thing, indeed. I doubt <asm/io.h> is the
right place for it, people tend to look at other drivers etc to pattern
after (as clearly showed by how often a bug in one place is replicated in
lots of other places ;)

We've actually fixed a number of these things - there are drivers that
notice removal on their own silently, and just turn it into a no-op.

> I'm hardly averse to changing that loop (which normally does have an end :)
> and I expected to need to at some point.  It's interesting to me just how
> long that has been there without causing problems.  In this case the root
> cause is that Cardbus "improper shutdown sequence" problem, so "no end"
> is just a particularly nasty secondary failure mode.

Most people don't unplug their devices while they are in use, and on
cardbus the most common case ends up (I think) being the fact that the
cardbus PCI static interrupt itself is shared with the device interrupt.
So what happens is that when you remove the CardBus card, that causes the
cardbus controller to send an interrupt (for removal), but since that
interrupt is shared with the card driver, the card driver also sees the
interrupt even if the card itself is otherwise idle.

This meant that some tulip cards at least were _guaranteed_ to lock up
some time ago, simply because their interrupt handler would loop forever
on seeing the "more work" bit continually (all bits in the status register
were set due to the removal and floating data lines).

		Linus


  reply	other threads:[~2002-05-25 17:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20020523171326.GA11562@kroah.com>
2002-05-23 22:32 ` ehci-hcd on CARDBUS hangs when stopping card service David Brownell
2002-05-24 18:49   ` Linus Torvalds
2002-05-26 13:41     ` David Woodhouse
2002-05-28 13:54       ` Ingo Oeser
     [not found]   ` <200205241849.g4OInTe02393@penguin.transmeta.com>
2002-05-25 17:15     ` David Brownell
2002-05-25 17:54       ` Linus Torvalds [this message]
2002-05-27  6:27   ` Borsenkow Andrej
2002-05-27 18:37     ` David Brownell
2002-05-27 10:54   ` Borsenkow Andrej
2002-05-23  6:33 Borsenkow Andrej
2002-05-23  6:39 ` Borsenkow Andrej

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=Pine.LNX.4.44.0205251049380.6515-100000@home.transmeta.com \
    --to=torvalds@transmeta.com \
    --cc=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    /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 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).