Bug 725639

Summary: bluetooth USB dongle doesn't wakeup after suspend to ram
Product: [Fedora] Fedora Reporter: Jacek Pawlyta <cunio>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-25 08:46:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Jacek Pawlyta 2011-07-26 07:04:14 UTC
Description of problem:
btusb dongle doesn't wakeup after suspend, an activity diode stays blank,
to enable bluetooth again I have to remove the dongle from the USB port and plug it again. 

Version-Release number of selected component (if applicable):
kernel 3.0.0-1.fc16.x86_64

How reproducible:
often

Steps to Reproduce:
1. plug usb bluetooth dongle
2. pair some bt device (in my case bt mouse)
3. suspend to ram 
4. wakeup the laptop 
  
Actual results:
bt dongle is not activated, activity led stays blank, mouse is not seen by laptop

Expected results:
bt wakes up and mouse is working

Additional info:

kernel: [112978.797803] usb 8-1: reset full speed USB device number 5 using uhci_hcd
kernel: [112979.661541] btusb 8-1:1.0: no reset_resume for driver btusb?
kernel: [112979.661544] btusb 8-1:1.1: no reset_resume for driver btusb?
kernel: [112979.732049] usb 2-3: reset high speed USB device number 2 using ehci_hcd

Comment 1 Jacek Pawlyta 2011-07-26 07:05:21 UTC
kernels 2.6.38 work fine (F15)

Comment 2 Jacek Pawlyta 2011-09-29 17:50:02 UTC
kernels 3.1 rc gives the same problem as 3.0 branch

Comment 3 Jacek Pawlyta 2011-11-25 08:46:49 UTC

*** This bug has been marked as a duplicate of bug 727106 ***