From: Maxim <maximlevitsky@gmail.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kernel development list <linux-kernel@vger.kernel.org>,
USB development list <linux-usb-devel@lists.sourceforge.net>,
gregkh@suse.de
Subject: Re: USB: on suspend to ram/disk all usb devices are replugged
Date: Tue, 27 Mar 2007 19:54:42 +0200 [thread overview]
Message-ID: <200703271954.42628.maximlevitsky@gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0703271306230.2558-100000@iolanthe.rowland.org>
On Tuesday 27 March 2007 19:15:14 Alan Stern wrote:
> On Tue, 27 Mar 2007, Maxim Levitsky wrote:
>
> > Hi,
> > I noticed that after suspend/resume cycle all my usb devices are unplugged/replugged by uhci driver.
> > While it is not that big problem to me, that can be a real problem if a device is a flash card with mounted
> > file-system, because disappeared device will cause file-system corruption.
> >
> > I found why this happens.
> >
> > drivers/usb/host/pci-quirks.c:uhci_check_and_reset_hc checks that the BIOS didn't play with USB controller, and on my system
> > with or without a USB Legacy support turned on in the BIOS, the BIOS does meddle with USB controller,
> >
> > But I suggest adding a option that will allow the user to bypass that check, because for example on my system USB works perfectly
> > if I disable the checks that this function does (but I agree that those checks are very valuable, since I almost sure that on many systems USB
> > won't work without resetting the USB controller.)
>
> No. It just isn't safe to do that. If the BIOS has done something to the
> controller then it may very well have reset the attached devices too. Or
> changed their addresses, or done something else equally drastic.
I agree, I was only saying a option to override this check, for users who know that this is not the case.
>
> > Secondary, this function checks for UHCI_USBCMD_CONFIGURE, that is not set on resume,
> > According to both UHCI and ICH8 documentation this is software only bit, but I didn't find any place in kernel where it is set,
> > (But such place exist, because reading from usb IO ports confirm that it is set during normal work, I will try to find it)
>
> It is set in drivers/usb/host/uhci-hcd.c:start_rh().
Thanks a lot, it would take a lot of time to find that out to me,
>
> > Disabling both check for UHCI_USBLEGSUP and UHCI_USBCMD_CONFIGURE makes all usb devices (I have mouse,keyborad, and joystick)
> > work fine on resume from ram without this "virtual" replugging.
>
> The UHCI specification is rather sparse in many respects, and it doesn't
> say what the host firmware should or should not do during a resume. So
> the driver has to be very conservative and assume that any indication of a
> change means that the entire controller must be reset.
>
> > Suspend to disk still causes "virtual replugging" and I think that controller is reset and will unplug/replug devices anyway
> > Resolving this problem is very difficult. Maybe it possible to check on unplugging event that this caused by suspend if the same device is
> > replugged then don't remove/reinstall driver, but this is very difficult to implement properly,
> > Maybe just refuse to suspend if some valuable device is connected (sorry if it is done this way already)
>
> Long ago I posted a patch that would take care of all this. Not just for
> UHCI, but for any USB controller. Maybe I should dig it out, update it,
> and submit it.
This sounds great, where is it ? .... :-)
This will improve linux suspend to ram/disk a lot.
>
> > Also I want to note that I didn't yet checked any EHCI devices, because I don't have any (I am going to buy a usb stick soon)
> > But I feel that the above will be true for ehci too....
>
> EHCI controllers tend to be better behaved than UHCI controllers, perhaps
> because the specification is much more careful to explain what must be
> done. In many cases a computer can resume from suspend-to-RAM with all
> the EHCI-connected devices still intact.
Big thanks, maybe usb stick I am going to buy will work with suspend to ram....
>
> Alan Stern
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi,
Thanks a lot for so quick reply,
I want to note to myself that making a assumptions generally a bad idea,
Until now I thought that linux always unplugs/re plugs usb devices on suspend/resume,
that this is normal, but it looks that linux is better... :-)
Best regards,
Maxim Levitsky
next prev parent reply other threads:[~2007-03-27 17:54 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-03-27 16:24 USB: on suspend to ram/disk all usb devices are replugged Maxim Levitsky
2007-03-27 17:15 ` Alan Stern
2007-03-27 17:54 ` Maxim [this message]
2007-03-27 18:05 ` Pete Zaitcev
2007-03-27 23:29 ` Maxim
2007-04-01 15:29 ` Pavel Machek
2007-04-01 17:42 ` David Zeuthen
2007-04-01 17:50 ` Pavel Machek
2007-04-01 18:01 ` David Zeuthen
2007-04-01 18:29 ` Pavel Machek
2007-04-01 18:26 ` Alan Stern
2007-04-01 18:34 ` Pavel Machek
2007-04-01 20:53 ` Rafael J. Wysocki
2007-04-02 2:54 ` Alan Stern
2007-04-02 20:37 ` Rafael J. Wysocki
2007-04-02 18:38 ` Chuck Ebbert
2007-04-02 19:36 ` Pavel Machek
2007-04-06 22:23 ` Nigel Cunningham
2007-04-02 14:49 ` Mark Lord
2007-04-02 18:28 ` Pavel Machek
2007-03-29 13:19 ` Mark Lord
2007-03-29 15:56 ` Alan Stern
2007-03-29 16:03 ` Mark Lord
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=200703271954.42628.maximlevitsky@gmail.com \
--to=maximlevitsky@gmail.com \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb-devel@lists.sourceforge.net \
--cc=stern@rowland.harvard.edu \
/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.