linux-kernel - Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Sep 2006 11:04:48 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Andrew Morton <akpm@...l.org>, Mattia Dongili <malattia@...ux.it>,
	Robert Hancock <hancockr@...w.ca>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	USB development list <linux-usb-devel@...ts.sourceforge.net>
Subject: Re: [linux-usb-devel] 2.6.18-rc6-mm1 (-mm2): ohci resume problem

On Thu, 14 Sep 2006, Rafael J. Wysocki wrote:

> > > Try adding some ehci_dbg() lines in there (copy the form of the line just
> > > after restart:).  We want to follow the value of
> > > hcd->self.root_hub->state.  Initially it should be equal to
> > > USB_STATE_SUSPENDED (= 8), and it shouldn't change.  But somewhere it is
> > > getting set to USB_STATE_CONFIGURED (= 7).  I don't know where, but almost 
> > > certainly somewhere in this routine.  If you can find out where that 
> > > happens, I'd appreciate it.
> > 
> > Done, but it shows hcd->self.root_hub->state is already 7 right after restart.
> 
> BTW, all of the systems on which the problem shows up seem to be 64-bit.
> 
> If you can't reproduce it on a 32-bit system, some type casting may be wrong
> somewhere.

I realized last night what the problem must be.  It's extremely obvious in 
retrospect, but I happen to have a blind spot in this particular area.

All you guys must have CONFIG_USB_SUSPEND turned off.  Mattis certainly 
does; I checked his .config.  Now I hardly ever do any testing without 
CONFIG_USB_SUSPEND, since there's not much point working on power 
management code if your kernel isn't set up to actually suspend devices.
As a result I missed seeing the problems caused by the autosuspend 
changes.

Now of course, the autosuspend stuff has to work properly no matter what 
the kernel configuration is.  I'll go back and rebuild the drivers with 
USB_SUSPEND turned off and see what happens.  With any luck I'll have a 
fix ready in the near future.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/