On Thursday, 21 September 2006 16:56, Alan Stern wrote:
> [Trimmed down the CC list]
> 
> On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
> 
> > On Monday, 18 September 2006 17:07, Alan Stern wrote:
> > > On Mon, 18 Sep 2006, Rafael J. Wysocki wrote:
> > > 
> > > > > Actually, the problem is ohci_hcd doesn't seem to recognize devices 
> > > > > plugged
> > > > > into the USB ports.
> > > > > 
> > > > > For example, if I unplug and replug a mouse (that worked before 
> > > > > unplugging),
> > > > > it doesn't work any more.  I have to reload ohci_hcd to make it work 
> > > > > again.
> > > > > 
> > > > > This is 100% reproducible and occurs on the two boxes above.
> > > > 
> > > > I have carried out a binary search and found that the problem is caused 
> > > > by
> > > > 
> > > > gregkh-usb-usbcore-remove-usb_suspend_root_hub.patch
> > > 
> > > Tell me, what happens if you leave that patch installed, and you use 
> > > the patch I sent last week (the one that removes a chunk of code from 
> > > ohci-hub.c), and you also set CONFIG_USB_SUSPEND?
> > 
> > The problem continues to happen.
> > 
> > Moreover, if I revert the above patch and apply the patch removing code
> > from ohci-hub.c, the problem reappears.
> 
> I'm working on this, but it's slow going because I'm not very familiar 
> with ohci-hcd.  One of my computers does have OHCI controllers but I can't 
> reproduce your problem.
> 
> In the meantime, let's make sure I understand the symptoms properly.  
> Let's say you start with pure 2.6.18-rc6-mm2 and apply the patch below.  
> (Two of the parts have already been submitted and the third is for 
> testing.)  Let's also say you start with a clean boot and don't do any 
> suspends.  Finally, let's say you leave the mouse unplugged while you boot 
> and then plug it in afterward.  Does it work?  If it does, what happens if 
> you unplug it and then replug it several seconds later?
> 
> Do you see the problem is CONFIG_USB_SUSPEND isn't set?  What about if it
> is set?  What do the kernel logs show?
> 
> Assuming the symptoms do not appear, if you do suspend-to-disk do they 
> appear afterward?

I have tested 2.6.18-rc6-mm2 with your patch applied (it is called 2.6.18-rc6
in the attached dmesg outputs, but that's because I have a "customized"
2.6.18-rc6-mm2 installed and I didn't want to replace it).

I have tested both with and without CONFIG_USB_SUSPEND set.  In either case
I booted the system without my USB mouse.  Then, I plugged the mouse in
and checked if it worked.  Next, I suspended and resumed the system twice
checking if the mouse worked after each resume, without unplugging it.
Finally, after the second resume I unplugged and replugged the mouse.

The results are the following:

1) The kernel compiled without CONFIG_USB_SUSPEND works just fine, suspends
and resumes correctly, and the mouse always works (ie. is correctly detected
every time).

2) The kernel compiled with CONFIG_USB_SUSPEND set doesn't detect the mouse
plugged in after a fresh boot.  However, if the mouse is connected to a USB
port during an entire suspend/resume cycle, it works after the resume, but
when it's unplugged after the resume and replugged, the kernel fails to detect
it.

The outputs of dmesg for each case are attached.

Greetings,
Rafael


-- 
You never change things by fighting the existing reality.
                R. Buckminster Fuller

Attachment: dmesg.log.gz
Description: GNU Zip compressed data

Attachment: dmesg-usb_suspend.log.gz
Description: GNU Zip compressed data

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to