Description of problem: I can not suspend my computer anymore if I connect an USB 3.0 disk to it. It "shuts" down then it wakes up (resumes) immediately. If I don't connect the disk at all, suspend works fine. Version-Release number of selected component (if applicable): kernel-3.11.6-200.fc19.x86_64 How reproducible: Every time Steps to Reproduce: 1. Power on computer. 2. Connect USB 3.0 disk. 3. Use disk. 4. Disconnect disk. I use GNOME Disks to shut it down then I unplug it from the power socket. The USB cable remains plugged in all the time, but I don't think this matters. 5. Suspend (to RAM). Actual results: Computer suspends then it wakes up immediately. Expected results: Computer should remain suspended. Additional info: The motherboard is an Intel DZ77BH-55K and the disk is WD My Book 1140 (1016) 3TB. In case it matters I'm using the latest BIOS i.e. BIOS Update [BHZ7710H.86A], date 5/17/2013, version 0100. This has been happening for some time, at least a couple of months and to be honest I remember ever working, so I can't say if it's a regression or not.
Created attachment 818606 [details] lspci -vv # after booting
Created attachment 818607 [details] dmesg # after booting
Created attachment 818608 [details] lsusb -vv # after booting
Created attachment 818609 [details] lsmod # after booting
Created attachment 818613 [details] lspci -vv # after 1st resume [OK] N.B. The USB 3.0 disk hasn't been connected yet.
Created attachment 818614 [details] dmesg # after 1st resume [OK] N.B. The USB 3.0 disk hasn't been connected yet.
Created attachment 818615 [details] lsusb -vv # after 1st resume [OK] N.B. The USB 3.0 disk hasn't been connected yet.
Created attachment 818616 [details] lspci -vv # after connecting disk
Created attachment 818617 [details] dmesg # after connecting disk
Created attachment 818618 [details] lsusb -vv # after connecting disk
Created attachment 818619 [details] lsmod # after connecting disk
Created attachment 818620 [details] lspci -vv # after disconnecting disk
Created attachment 818621 [details] dmesg # after disconnecting disk
Created attachment 818622 [details] lsusb -vv # after disconnecting disk
Created attachment 818623 [details] lspci -vv # after 2nd resume [FAIL]
Created attachment 818624 [details] dmesg # after 2nd resume [FAIL]
Created attachment 818625 [details] lsusb -vv # after 2nd resume [FAIL]
The attached information was generated with kernel-debug-3.11.6-200.fc19.x86_64 and `/proc/cmdline` was: BOOT_IMAGE=/vmlinuz-3.11.6-200.fc19.x86_64.debug root=/dev/mapper/hermesVG-Fedora--rootVol ro rd.luks=0 rd.md=0 rd.dm=0 rd.luks=0 vconsole.keymap=us intel_iommu=on rd.driver.blacklist=nvidia,nouveau nouveau.modeset=0 video=VGA-1:d log_buf_len=3M debug The steps were: - power on computer - collect info - suspend - resume (I pressed a key of my PS/2 keyboard) - collect info # 1st resume - connect disk - collect info - disconnect disk - collect info - suspend - resume (computer resumed immediately) - collect info # 2nd resume
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.12.6-200.fc19. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 20, and are still experiencing this issue, please change the version to Fedora 20. If you experience different issues, please open a new bug report for those.
The bug seems to be fixed by kernel-3.12.6-300.fc20.x86_64.
It happened again with kernel-3.12.6-300.fc20.x86_64. I think it might be caused by IOMMU because when it worked before, I did't boot with intel_iommu=on.
I rebooted with IOMMU disabled to double check what's going on and it seems that if I disconnect the external disk using gnome-disks[1], the computer resumes immediately from the suspend. If I remember correctly, when I said that the bug was fixed (comment #20), the disk was still connected to the computer and powered on (it might have been mounted too), so it was a different scenario. [1]: gnome-disk-utility-3.10.0-1.fc20.x86_64
kernel-3.12.7-300.fc20.x86_64 with initrd=\865b8ff295c29b42a3eef3ecebbeea5a\3.12.7-300.fc20.x86_64\initrd root=UUID=ca0414e3-a3f3-4a12-9bf2-47a528bea489 ro vconsole.font=latarcyrheb-sun16 rhgb quiet rd.driver.blacklist=nvidia,nouveau nouveau.modeset=0 video=VGA-1:d nmi_watchdog=0 suspends then immediately resumes.
It still happens with kernel-3.13.4-200.fc20.x86_64
It still happens with kernel-3.13.9-200.fc20.x86_64.
It's still happening with kernel-3.13.10-200.fc20.x86_64.
I connected the disk to an USB 2.0 (Hi-Speed) port and suspend worked.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.14.4-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
It looks like it has been fixed, but I'm planning to test it more thoroughly in the next couple of days to be sure.
I think that I was lucky when it worked before once or twice. Thing is kernel 3.15.3-200.fc20.x86_64 failed to suspend properly just like the initial bug report.
It also happens with kernel-3.15.4-200.fc20.x86_64. And to add to the injury the external disk stopped suspending while mounted even if it's not being used.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.17.2-200.fc20. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 21, and are still experiencing this issue, please change the version to Fedora 21. If you experience different issues, please open a new bug report for those.
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in over 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
It's still happening with kernel-4.8.6-300.fc25.x86_64.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 25 kernel bugs. Fedora 25 has now been rebased to 4.9.3-200.fc25. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
It seems to work fine under 4.9.5-200.fc25.x86_64.