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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox