public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Andrej.Borsenkow@mow.siemens.ru, linux-kernel@vger.kernel.org
Subject: Re: ehci-hcd on CARDBUS hangs when stopping card service
Date: Thu, 23 May 2002 15:32:43 -0700	[thread overview]
Message-ID: <3CED6E0B.8020501@pacbell.net> (raw)
In-Reply-To: <20020523171326.GA11562@kroah.com>

I've recently got some similar reports, but with a few less
facts ... it was clear to me there was a problem somewhere
in the CardBus code, since I know that cleanup via rmmod is
working fine, and in fact that's the workaround one person
had ended up with!


>>usb-ohci.c: bogus NDP=255 for OHCI usb - 09:00.1
>>(the above two statements are repeated ~4x's)

And the OHCI driver hits a related problem too ...


> IMHO sequence in cs driver should be reverted - it is not polite to remove
> hardware before giving driver a chance to cleanup :-)

Yes, absolutely.  It's turning a "clean shutdown" scenario into a
"dirty shutdown" ... a normal "rmmod" works, correctly, and from the
perspective of a device driver (if not the CardBus code) those should
be exactly the same:  two ways to start the same driver shutdown.

That current sequence (powerdown before pci_dev->remove) violates the
device tree sequencing requirement ... which I recall was one of the
key features of the original 2.4 CardBus support.  Did it change rather
recently, or has this bug really been lurking for a very long time?
I'd expect to have heard about that OHCI problem (seemingly the same root
cause) before, since there are folk using Cardbus OHCI (more using EHCI!),
but nobody's reported it that I know of.

I'll hope that problem appears only in 2.4.18-6mdk, and isn't found in
other kernels.  In particular, if it's in 2.5.17 then there's a big
hole in the "new driver model" work (struct device etc)!


 > 
	 Irrespectively,
> endless loop in ehci_stop does not look nice.

I partially agree.  For a clean shutdown, it's guaranteed not to be
endless.  For a dirty shutdown -- physically ejecting the card, or
the hardware having truly nasty failure mode (one I've not seen but
which could conceivably happen) -- it's a problem to fix.

Is there a clean way to detect the "card ejected before anything calls 
pci_dev->remove()" case?  I don't really like the idea of wrapping code
around every PCI register access to detect such cases.

- Dave




       reply	other threads:[~2002-05-23 22:31 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 ` David Brownell [this message]
2002-05-24 18:49   ` ehci-hcd on CARDBUS hangs when stopping card service 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
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=3CED6E0B.8020501@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=Andrej.Borsenkow@mow.siemens.ru \
    --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