Most recent kernel where this bug did *NOT* occur: Distribution:gentoo 2006.1 i686-pc-linux-gnu Hardware Environment:scanner epson perfection 1670, 82801G (ICH7 Family) USB2 EHCI Controller Problem Description: with suspend to ram kernel will set scanner to the standby mode, but after resume kernel can't resume scanner _if_ ehci (module) is used. With this issue sane can't use the scanner you need replug it to make it use. This issue not upper if kernel compiled without ehci support. Steps to reproduce: 1. compile kernel with ehci (module or build-in) and restart 2. plugin scanner (sane is working) 3. echo mem > /sys/power/state && scanner will be set to standby mode too. 4. resume && scanner will stay in standby mode 5. replug the scanner to make it use.
Created attachment 10738 [details] dmesg with ehci dmesg with ehci... the scanner will stay disabled.
Created attachment 10739 [details] dmesg with noehci dmesg with noehci, the scanner will be resumed correctly.
Reply-To: akpm@linux-foundation.org > On Tue, 13 Mar 2007 00:51:32 -0700 bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8190 > > Summary: ehci_hcd can't reinitialize scanner after suspend>resume > Kernel Version: 2.6.20, 2.6.21-rc3-gbe521466 > Status: NEW > Severity: normal > Owner: acpi_power-sleep-wake@kernel-bugs.osdl.org > Submitter: bug-track@fisher-privat.net > > > Most recent kernel where this bug did *NOT* occur: > Distribution:gentoo 2006.1 i686-pc-linux-gnu > Hardware Environment:scanner epson perfection 1670, 82801G (ICH7 Family) USB2 > EHCI Controller > > Problem Description: with suspend to ram kernel will set scanner to the standby > mode, but after resume kernel can't resume scanner _if_ ehci (module) is used. > With this issue sane can't use the scanner you need replug it to make it use. > > This issue not upper if kernel compiled without ehci support. > > Steps to reproduce: > 1. compile kernel with ehci (module or build-in) and restart > 2. plugin scanner (sane is working) > 3. echo mem > /sys/power/state && scanner will be set to standby mode too. > 4. resume && scanner will stay in standby mode > 5. replug the scanner to make it use. > Is this an ACPI bug, or a USB bug?
Created attachment 10740 [details] usb-devices i don't know if it's acpi or usb bug.
Reply-To: oneukum@suse.de Am Dienstag, 13. M
Please try building a kernel with CONFIG_USB_DEBUG turned on, and attach the dmesg log showing what happens during suspend and resume with ehci-hcd loaded.
Created attachment 10746 [details] dmesg with usb and pm debug
The scanner is "usb 5-3" in the last debug.
There are some things in the latest log I don't understand... Please try this: Edit the file drivers/usb/core/driver.c. Near the end of usb_resume_device() is a dev_dbg() line which has been commented out. Uncomment it, and then do the same thing for usb_resume_interface() and usb_resume_both(). Then run the test again. There's no need to do a supsend without ehci-hcd; we know it works. Just do a single suspend/resume cycle with ehci-hcd loaded. After the resume, when the scanner isn't functioning, go to /sys/class/usb_host/usb_host5. Make a copy of the "registers" file and attach it also.
did this work properly with any previous kernel? does this work properly after a suspend-to-disk cycle?
Created attachment 10754 [details] with some more debug
Created attachment 10756 [details] after hibernate > does this work properly after a suspend-to-disk cycle? yes it working.
Okay, now I understand what the system log is saying. But it doesn't explain the problem. Please attach two copies of the /sys/class/usb_host/usb_host5/registers file: one from before the suspend and one from after the resume.
Created attachment 10757 [details] usb_host/registers before
Created attachment 10758 [details] usb_host/registers after
Created attachment 10759 [details] Diagnose EHCI port resume Okay, this is definitely a problem in the ehci-hcd driver. You can remove the changes to drivers/usb/core/driver.c, and instead please try this diagnostic patch. The system log after resuming should tell us what we need to know.
Created attachment 10760 [details] dmesg with diagnose patch
Created attachment 10761 [details] Diagnose EHCI port resume This is very bizarre. Here's the important part of the log, leaving out everything except for port 3: [ 0.971514] ehci_hcd 0000:00:1d.7: port 3 status1 1005 [ 0.991544] ehci_hcd 0000:00:1d.7: port 3 status2 1085 [ 0.991546] ehci_hcd 0000:00:1d.7: resume done The status1 value should be 1085 and the status2 value should be 10c5, meaning that the port was suspended at first but then the resume bit was turned on. Instead the port was unsuspended at first and then somehow it got suspended! That's why the scanner wasn't working; it was still suspended. Try using this new patch and see if it makes any difference.
Created attachment 10762 [details] dmesg with the fix This patch working for me. After resume scanner was ready to work. Thank you for make it for me understandable.
appears to be a USB issue rather than ACPI issue, moving to drivers/usb
Good. The new mdelay(20) line in that patch solved the problem. In fact, 20 is probably larger than necessary. Could you experiment and see if you can reduce it? Maybe even mdelay(1) would be good enough. For testing mdelay values, you don't need to reboot or even try to run sane. All you have to do is rmmod ehci-hcd and then insmod ehci-hcd.ko every time you rebuild it, and then check the port status values the patch prints in the system log. If you can tell me a good value to use for the mdelay, I will submit it for inclusion in 2.6.21 and 2.6.20-stable.
Created attachment 10780 [details] dmesg with mdelay(4) The minimal value for mdelay is 4.
Okay. I'll use 8 just to be safe and submit a patch.