All of lore.kernel.org
 help / color / mirror / Atom feed
From: Seth Forshee <seth.forshee@canonical.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-usb@vger.kernel.org, usb-storage@lists.one-eyed-alien.net,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb_storage: make usb-stor-scan task non-freezable
Date: Tue, 26 Jul 2011 08:33:17 -0500	[thread overview]
Message-ID: <20110726133317.GB6687@thinkpad-t410> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1107232150380.27037-100000@netrider.rowland.org>

On Sat, Jul 23, 2011 at 09:56:15PM -0400, Alan Stern wrote:
> On Sat, 23 Jul 2011, Seth Forshee wrote:
> 
> > After experimenting with this device more I came to the conclusion that
> > the normal behavior with this machine is for the card reader to be
> > disconnected from the USB bus unless there's a card in the slot. During
> > a normal boot with an empty card slot the card reader never shows up on
> > the bus.
> 
> Weird.  Then the reader would never be usable.  Unless it connects 
> itself to the bus when a card is inserted?

Yes, the reader is connected to the bus when a card is inserted. Remove
the card and it disappears again.

> > The only solution I've come up with is to leave usb-stor-scan freezable
> > without allowing it to actually freeze. We can request a fake signal be
> > sent when freezing and use interruptible sleep to abort the wait early
> > and finish up the thread's processing. This is implemented in the patch
> > below. Does this approach look reasonable? It's rather subtle, but it
> > does seem to work. I done numerous S4 cycles with and without a card
> > inserted and didn't get any failures.
> 
> This runs the risk of failing to suspend if scanning takes too long.  

It may increase the exposure to that risk, but really the risk is
already there.

> On the other hand, many systems nowadays use async scanning anyway.
> And that combination of events isn't too likely to happen, whereas 
> you're facing a real problem right now.  So I guess this is okay.

Great, thanks.

Will the patch get picked up from my previous email, or do I need to
resend it?

Thanks,
Seth

  reply	other threads:[~2011-07-26 13:33 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-18 16:28 [PATCH] usb_storage: make usb-stor-scan task non-freezable Seth Forshee
2011-07-18 21:12 ` Alan Stern
2011-07-18 22:44   ` Seth Forshee
2011-07-19 14:26     ` Alan Stern
2011-07-19 17:21       ` Seth Forshee
2011-07-23 21:08       ` Seth Forshee
2011-07-24  1:56         ` Alan Stern
2011-07-26 13:33           ` Seth Forshee [this message]
2011-07-26 14:21             ` Alan Stern

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=20110726133317.GB6687@thinkpad-t410 \
    --to=seth.forshee@canonical.com \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mdharm-usb@one-eyed-alien.net \
    --cc=stern@rowland.harvard.edu \
    --cc=usb-storage@lists.one-eyed-alien.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.