Hide Forgot
Description of problem: Update kernel from 3.1.5-1 to 3.1.6-1 (the first update to 3.1.5-2 crashed somehow and 3.1.6-2 is a reinstallation). pm-hibernate results in not proper resume: it will come to Gnome shell with blinking cursor in gnome-terminal (no command line prompt). At this stage, toggle numlock makes the green light on/off and move mouse is responsive (not click). However, any stroke on the keyboard will freeze the screen and the numlock light will be off. ctrl+alt+f2 will bring a blank tty with only a blinking cursor and no login. nearly everything is dead. if getting into hibernation by 'pm-hibernate; dmesg > /var/log/dmesg.log; sync' basically yield same thing as above with no resulting dmesg.log. Version-Release number of selected component (if applicable): kernel 3.1.6-1 in F16. I think it might be related to the kernel update because the problem appears after this update. How reproducible: Steps to Reproduce: 1. boot into F16 kernel 3.1.6-1 2. pm-hibernate in gnome-terminal 3. after hibernation, restart the system Actual results: Everything is freezed and only option is to hard reboot. Expected results: Additional info:
Please try kernel-3.1.7-1.fc16 which will be in the next f16-updates-testing push.
Is there any release schedule to share? Or is there any twist of kernel parameters on current kernel 3.1.6-1? Thank you
(In reply to comment #2) > Is there any release schedule to share? Or is there any twist of kernel > parameters on current kernel 3.1.6-1? > > Thank you It should be pushed to updates-testing already. It got enough karma to be bumped to a stable update, but it hasn't made it to the stable repos yet. If the mirrors you are using are stale, you can download it directly from koji: http://koji.fedoraproject.org/koji/buildinfo?buildID=280853
Hi, Josh: Thank you. Just tried 3.1.7-1.fc16.x86_64 and from there pm-hibernate. When resume, the same old symptom, the screen got into the gnome but eventually freezed there. I have only one option to hard reboot. is there anyway I can install the old kernel-3.1.5-1.fc16.x86_64?
Are you by chance using the nVidia module?
No. Nouveau driver. But my graphic card is Nvidia FX480.
I mean I only use Nouveau driver.
Tried out 3.1.8-2.fc16.x86_64. a little change in the result in terms of hibernation. When resume, mouse pointer is always responsive to the move. However, it won't respond to any mouse click. Any main keyboard hit will freeze the screen. Only way out is still hard reboot.
Kernel: 3.1.9-1.fc16.x86_64. Same old story. No fix. Able to reinstall 3.1.5-1.fc16 from koji. it just worked out immediately for hibernate/resume. Really want to know what is difference between this version and later versions.
with pm_trace and no_console_suspend kernel option, it seems that the resume failure is from the io error to the disk. The system has sata disks. f16 was installed on /dev/sdb (with /boot, /home, and / partitions) and /dev/sda is a data disk and can be automounted in fstab. the disc driver is mvsas. not sure, how the resume failure is related with sata drive/disk. I thought this is more related to Nvidia.
Just tried 3.2.1-3.fc16.x86_64 kernel. pm-hibernate has different symptom now: when it resume, it will come to the point to thawt process and recover the image, it then go to reboot itself... Any idea?
kernel: 3.2.2-1.fc16.x86_64. pm-hibernate still fail in resume. I can read more error message from tty2 when resume: ... [sda] start_stop failed [sda] Resule hostbyte=DIR_OK driverbyte=DIRVER_TIMEOUT pm_op(): scsi_but_resume_common+0x0/0x60 return 100663296 PM device x:x:x:x failed to resume async error 100663296 ... I hope this error message will help in debug the resume process. The following info might help also: 1. The system has Marvell 88SE6480 chipset for SATA II. I use mvsas driver. 2. I installed 2 SATA disks through Marvell without RAID (f16 is on sdb2; sda is automounted through fstab). 3. RAM 6GB and swap 18 GB. 4. F16 has partitions for /boot, /home, and /; all, along with swap, are on sdb. sda is merely a data disk. 5. The graphic card is Nvidia FX 580; I use nouveau driver. 6. pm-suspend.log which records the hibernate process seems that all are successful during the hibernation. During past kernel usage for resume after hibernate, I also see some error messages saying libata port error. Hopefully some one could find the problem; also is mvsas/libata relevant resume failure in wake-up? because the obvious problem is to the access to the harddisk.... Thank you very much.
Still 3.2.2-1 but with additional updates package (sorry don't know which ones because of so many): resume is not correct but with different symptom from tty2: hibernate successful; resume starts and upto thawt (see some percentage of recovery) and then go to reboot.... reboot itself is successful but it isn't meant to be... Really don't know why this one is different from the previous error before package update. same kernel though...
kernel 3.2.3-2 and 3.2.5-3 have the same problem in wake-up from hibernate. It can't access to the scsi disks.
kernel 3.3.0-4: pm-suspend/pm-hibernate still failed. hibernate | suspend phase is successful. but resume phase failed: I think the image was thawed but when it came to access scsi disk it failed: sd 6:0:0:0 [sda] start-stop failed sd 6:0:0:0 [sda] Result: hostbyte=DID_OK drivetype=DRIVER_TIMEOUT dpm_run_callback(): scsi_bus_resume_common+0x0/0x90 returns 100663296 similar to sdb disk. is this related to some Marvell Host Controller driver? I have Marvell 88SE6480 chipset for SATA II and use mvsas driver. And the graphic card is Nvidia FX 580; I use nouveau driver. It seems more likely related to Marvell.
According to previous comments I am changing component to kernel.
kernel 3.3.0-8: same problem for pm suspend/hibernate. In addition: during resume, has error message on screen: tpm_tis 00:0a: tpm_transmit: tpm_send: error -62 this bug has been in F15 and sometimes ago it was fixed. but now it appears again. (see bug 530393: https://bugzilla.redhat.com/show_bug.cgi?id=530393). Furthermore, find ioatdma bugs during system normal boot up. This bug may appear early but I lapsed. The excerpt from dmesg: ... [ 27.113356] ioatdma: Intel(R) QuickData Technology Driver 4.00 [ 27.113604] ioatdma 0000:00:16.0: enabling device (0000 -> 0002) [ 27.113862] ioatdma 0000:00:16.0: can't derive routing for PCI INT A [ 27.114242] ioatdma 0000:00:16.0: PCI INT A: no GSI [ 27.114703] IRQ handler type mismatch for IRQ 0 [ 27.115003] current handler: timer [ 27.115377] Pid: 583, comm: modprobe Not tainted 3.3.0-8.fc16.x86_64 #1 [ 27.115761] Call Trace: [ 27.116147] [<ffffffff810e58ae>] __setup_irq+0x45e/0x550 [ 27.116537] [<ffffffff8116d01b>] ? kmem_cache_alloc_trace+0x11b/0x150 [ 27.116930] [<ffffffff810e5a4b>] ? request_threaded_irq+0xab/0x1c0 [ 27.117324] [<ffffffffa02f8330>] ? ioat_dma_do_interrupt_msix+0x30/0x30 [ioatdma] [ 27.117727] [<ffffffff810e5a94>] request_threaded_irq+0xf4/0x1c0 [ 27.118127] [<ffffffff810e79c3>] devm_request_threaded_irq+0x73/0xd0 [ 27.118533] [<ffffffffa02f8330>] ? ioat_dma_do_interrupt_msix+0x30/0x30 [ioatdma] [ 27.118943] [<ffffffffa02fec84>] ioat_probe+0x2b0/0x330 [ioatdma] [ 27.119352] [<ffffffffa02fe4f9>] ? system_has_dca_enabled+0x49/0xdc [ioatdma] [ 27.119762] [<ffffffffa02ff901>] ioat3_dma_probe+0x1fa/0x2a2 [ioatdma] [ 27.120172] [<ffffffffa02fe787>] ioat_pci_probe+0x152/0x175 [ioatdma] [ 27.120584] [<ffffffff812e67ec>] local_pci_probe+0x5c/0xd0 [ 27.120995] [<ffffffff812e8099>] pci_device_probe+0x109/0x130 [ 27.121403] [<ffffffff813a18dc>] driver_probe_device+0x9c/0x300 [ 27.121804] [<ffffffff813a1beb>] __driver_attach+0xab/0xb0 [ 27.122203] [<ffffffff813a1b40>] ? driver_probe_device+0x300/0x300 [ 27.122605] [<ffffffff8139fd46>] bus_for_each_dev+0x56/0x90 [ 27.123001] [<ffffffff813a14ee>] driver_attach+0x1e/0x20 [ 27.123394] [<ffffffff813a10f0>] bus_add_driver+0x1b0/0x2a0 [ 27.123776] [<ffffffffa0307000>] ? 0xffffffffa0306fff [ 27.124152] [<ffffffff813a2146>] driver_register+0x76/0x140 [ 27.124519] [<ffffffff8116f524>] ? kmem_cache_create+0x2a4/0x2e0 [ 27.124887] [<ffffffffa0307000>] ? 0xffffffffa0306fff [ 27.125246] [<ffffffff812e7d76>] __pci_register_driver+0x56/0xd0 [ 27.125600] [<ffffffffa0307000>] ? 0xffffffffa0306fff [ 27.125951] [<ffffffffa0307068>] ioat_init_module+0x68/0x1000 [ioatdma] [ 27.126299] [<ffffffff8100203f>] do_one_initcall+0x3f/0x170 [ 27.126652] [<ffffffff810b7432>] sys_init_module+0xba2/0x2010 [ 27.126987] [<ffffffff815fbca9>] system_call_fastpath+0x16/0x1b [ 27.127333] ioatdma 0000:00:16.0: no usable interrupts ... Not sure if this interects with hibernate/resume process...
Here is some more debug info that may identify the real resume/thaw problem in this machine. A bit more of the system layout is need here: this is dual boot system with F16 (kernel 3.3.0-8 and CentOS 6.1: sdb1: /boot, F16 sdb2: /, F16 sdb3: /home, F16 sdb4: extended sdb5: /swap sdb6: /boot, CentOS sdb7: /, CentOS sdb8: /home, CentOS sda1: /data all partition is formatted as ext4. however, after hibernate in F16, kernel log tells that: 1. it doesn't record for probing sdb2 2. it probe sequentially from sda1, sdb1, sdb3, ..., sdb8. However, it only detects sdb6, 7, and 8 as ext4 and it fails to recognize sda1 - sdb3 as ext4 or other os type (why not ext4?). thus grub boots from sdb6 into CentOS while hibernate image is for F16. Hope there is a quick workaround for this failure. here is the lengthy log: ... Apr 6 18:15:16 d20-x86 kernel: [ 707.881840] Btrfs loaded Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10freedos on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 10freedos: debug: /dev/sda1 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10qnx on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 10qnx: debug: /dev/sda1 is not a QNX4 partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20macosx on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 macosx-prober: debug: /dev/sda1 is not an HFS+ partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20microsoft on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 20microsoft: debug: /dev/sda1 is not a MS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/30utility on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 30utility: debug: /dev/sda1 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/40lsb on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/70hurd on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/80minix on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/83haiku on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 83haiku: debug: /dev/sda1 is not a BeFS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90linux-distro on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90solaris on mounted /dev/sda1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10freedos on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 10freedos: debug: /dev/sdb1 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10qnx on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 10qnx: debug: /dev/sdb1 is not a QNX4 partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20macosx on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 macosx-prober: debug: /dev/sdb1 is not an HFS+ partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20microsoft on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 20microsoft: debug: /dev/sdb1 is not a MS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/30utility on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 30utility: debug: /dev/sdb1 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/40lsb on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/70hurd on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/80minix on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/83haiku on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 83haiku: debug: /dev/sdb1 is not a BeFS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90linux-distro on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90solaris on mounted /dev/sdb1 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10freedos on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 10freedos: debug: /dev/sdb3 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/10qnx on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 10qnx: debug: /dev/sdb3 is not a QNX4 partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20macosx on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 macosx-prober: debug: /dev/sdb3 is not an HFS+ partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/20microsoft on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 20microsoft: debug: /dev/sdb3 is not a MS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/30utility on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 30utility: debug: /dev/sdb3 is not a FAT partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/40lsb on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/70hurd on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/80minix on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/83haiku on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 83haiku: debug: /dev/sdb3 is not a BeFS partition: exiting Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90linux-distro on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/mounted/90solaris on mounted /dev/sdb3 Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sdb4 Apr 6 18:15:16 d20-x86 50mounted-tests: debug: /dev/sdb4 type not recognised; skipping Apr 6 18:15:16 d20-x86 os-prober: debug: os detected by /usr/libexec/os-probes/50mounted-tests Apr 6 18:15:16 d20-x86 os-prober: debug: /dev/sdb5: is active swap Apr 6 18:15:16 d20-x86 os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sdb6 Apr 6 18:15:16 d20-x86 kernel: [ 708.560305] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:16 d20-x86 kernel: [ 708.560310] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 708.592393] EXT4-fs (sdb6): mounted filesystem with ordered data mode. Opts: (null) Apr 6 18:15:17 d20-x86 50mounted-tests: debug: mounted as ext4 filesystem Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10freedos Apr 6 18:15:17 d20-x86 10freedos: debug: /dev/sdb6 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10qnx Apr 6 18:15:17 d20-x86 10qnx: debug: /dev/sdb6 is not a QNX4 partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20macosx Apr 6 18:15:17 d20-x86 macosx-prober: debug: /dev/sdb6 is not an HFS+ partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20microsoft Apr 6 18:15:17 d20-x86 20microsoft: debug: /dev/sdb6 is not a MS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/30utility Apr 6 18:15:17 d20-x86 30utility: debug: /dev/sdb6 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/40lsb Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/70hurd Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/80minix Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/83haiku Apr 6 18:15:17 d20-x86 83haiku: debug: /dev/sdb6 is not a BeFS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90linux-distro Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90solaris Apr 6 18:15:17 d20-x86 kernel: [ 708.709158] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 708.709163] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sdb7 Apr 6 18:15:17 d20-x86 kernel: [ 708.729312] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 708.729316] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 708.782659] EXT4-fs (sdb7): mounted filesystem with ordered data mode. Opts: (null) Apr 6 18:15:17 d20-x86 50mounted-tests: debug: mounted as ext4 filesystem Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10freedos Apr 6 18:15:17 d20-x86 10freedos: debug: /dev/sdb7 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10qnx Apr 6 18:15:17 d20-x86 10qnx: debug: /dev/sdb7 is not a QNX4 partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20macosx Apr 6 18:15:17 d20-x86 macosx-prober: debug: /dev/sdb7 is not an HFS+ partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20microsoft Apr 6 18:15:17 d20-x86 20microsoft: debug: /dev/sdb7 is not a MS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/30utility Apr 6 18:15:17 d20-x86 30utility: debug: /dev/sdb7 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/40lsb Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/70hurd Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/80minix Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/83haiku Apr 6 18:15:17 d20-x86 83haiku: debug: /dev/sdb7 is not a BeFS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90linux-distro Apr 6 18:15:17 d20-x86 90linux-distro: result: /dev/sdb7:CentOS release 6.2 (Final):RedHat:linux Apr 6 18:15:17 d20-x86 50mounted-tests: debug: os found by subtest /usr/libexec/os-probes/mounted/90linux-distro Apr 6 18:15:17 d20-x86 kernel: [ 709.061888] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 709.061893] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 os-prober: debug: os detected by /usr/libexec/os-probes/50mounted-tests Apr 6 18:15:17 d20-x86 os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sdb8 Apr 6 18:15:17 d20-x86 kernel: [ 709.093022] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 709.093027] blockdev: sending ioctl 125d to a partition! Apr 6 18:15:17 d20-x86 kernel: [ 709.116700] EXT4-fs (sdb8): mounted filesystem with ordered data mode. Opts: (null) Apr 6 18:15:17 d20-x86 50mounted-tests: debug: mounted as ext4 filesystem Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10freedos Apr 6 18:15:17 d20-x86 10freedos: debug: /dev/sdb8 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/10qnx Apr 6 18:15:17 d20-x86 10qnx: debug: /dev/sdb8 is not a QNX4 partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20macosx Apr 6 18:15:17 d20-x86 macosx-prober: debug: /dev/sdb8 is not an HFS+ partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/20microsoft Apr 6 18:15:17 d20-x86 20microsoft: debug: /dev/sdb8 is not a MS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/30utility Apr 6 18:15:17 d20-x86 30utility: debug: /dev/sdb8 is not a FAT partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/40lsb Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/70hurd Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/80minix Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/83haiku Apr 6 18:15:17 d20-x86 83haiku: debug: /dev/sdb8 is not a BeFS partition: exiting Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90linux-distro Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running subtest /usr/libexec/os-probes/mounted/90solaris Apr 6 18:15:17 d20-x86 linux-boot-prober: debug: running /usr/libexec/linux-boot-probes/50mounted-tests Apr 6 18:15:17 d20-x86 50mounted-tests: debug: mapped UUID=dd683827-5552-4869-8f0a-b8769f81b82f to /dev/sdb6 Apr 6 18:15:17 d20-x86 50mounted-tests: debug: found boot partition /dev/sdb6 for linux system on /dev/sdb7 Apr 6 18:15:17 d20-x86 50mounted-tests: debug: running /usr/libexec/linux-boot-probes/mounted/40grub /dev/sdb7 /dev/sdb6 /var/lib/os-prober/mount ext4 Apr 6 18:15:17 d20-x86 40grub: debug: parsing menu.lst Apr 6 18:15:17 d20-x86 40grub: result: /dev/sdb7:/dev/sdb6:CentOS (2.6.32-220.4.2.el6.x86_64):/boot/vmlinuz-2.6.32-220.4.2.el6.x86_64:/boot/initramfs-2.6.32-220.4.2.el6.x86_64.img:ro root=UUID=0a1cd5af-a632-4e21-aa13-0fd0b1d17f87 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM Apr 6 18:15:17 d20-x86 40grub: result: /dev/sdb7:/dev/sdb6:CentOS (2.6.32-220.2.1.el6.x86_64):/boot/vmlinuz-2.6.32-220.2.1.el6.x86_64:/boot/initramfs-2.6.32-220.2.1.el6.x86_64.img:ro root=UUID=0a1cd5af-a632-4e21-aa13-0fd0b1d17f87 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM Apr 6 18:15:17 d20-x86 40grub: result: /dev/sdb7:/dev/sdb6:CentOS (2.6.32-220.el6.x86_64):/boot/vmlinuz-2.6.32-220.el6.x86_64:/boot/initramfs-2.6.32-220.el6.x86_64.img:ro root=UUID=0a1cd5af-a632-4e21-aa13-0fd0b1d17f87 rd_NO_LUKS rd_NO_LVM LANG=en_US.UTF-8 rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM Apr 6 18:15:17 d20-x86 50mounted-tests: debug: /usr/libexec/linux-boot-probes/mounted/40grub succeeded Apr 6 18:15:17 d20-x86 linux-boot-prober: debug: linux detected by /usr/libexec/linux-boot-probes/50mounted-tests ...
Kernel: 3.3.4-1. similar as before: suspend/hibernate doesn't wake up correctly. seems the problem is related to scsi drive. (or libata/libsas, etc).
Have followed LKML for quite some time and read the following message that might hint the possible solution/workaround: https://lkml.org/lkml/2012/5/8/23. The resume problem is always that it freezes when access to the sata driver. I was hoping if statically compiled mvsas into the kernel, it might provide more insight into the potential problem. currently mvsas is a kernel module. But here are some concerns: 1. if compiled kernel with mvsas as static, when update kernel with yum update, will this create trouble because I assume that "standard" kernel have mvsas.ko. 2. I need to fumble around for compiling kernel. is there any quick and dirty way to do it?
tried to have a static mvsas compiled into kernel. no luck on hibernation/suspend, same error message. it seems there is other factor played here for inable to resume.
Hello. My working configuration: 1. Gentoo x64 3.3.8 2. pm-utils 1.4.1-r2 3. Marvell 88SE6440 mvsas compiled as module, and: cat /etc/pm/config.d/gentoo PM_DEBUG="false" HOOK_BLACKLIST="01grub 90clock" SUSPEND_MODULES="mvsas xhci_hcd nvidia" PS. Few hours I tried another kernels and settings. With kernel version 2.6.38.8 my sas controller not see hard drives and suspend to ram worked. Then i compile mvsas as module and add it to pm-utils config file.
Hi, livelace: Thank you for your feedback on your workaround. Tried your config and still black screen. Noticed one difference: can't put mvsas in suspend_modules. failed because of mvsas is in use. Would you be able to check against your pm-suspend.log? Rather googled around find another possible reason: hdparm/sdparm. The disk I have: WDC WD2500AAJS supports APM ( and from hdparm -I) and when I quoted from -i or set with -B it fails with APM_level not supported error. I think this message matches what the symptoms I saw in hibernate/suspend on-screen resume output. One of the suggestion is in BIOS to set it in IDE mode. Will test and explore other option.
Hello. I deceived you, sorry. My example above working for me, when hdd isn't using. If: dd_rescue /dev/sdh /dev/null -> suspend not work After few hours i found (google -> libsas suspend): 1. http://www.spinics.net/lists/linux-scsi/msg60238.html 2. http://lwn.net/Articles/504914/ I tried linux-next and i see, that now mvsas tried suspend, but with unstable kernel - did not work. I compile 2.6.32-279.el6, and tried suspend, but did not work (rhel have big patch and i'm not particularly worried). PS.3.5-rc6 from kernel.org work don't have patch for libsas. I will wait stable kernel with libsas patch.
Hi, livelace: Thank you for your link. Hope libsas update will fix this problem. Will wait to see.
# Mass update to all open bugs. Kernel 3.6.2-1.fc16 has just been pushed to updates. This update is a significant rebase from the previous version. Please retest with this kernel, and let us know if your problem has been fixed. In the event that you have upgraded to a newer release and the bug you reported is still present, please change the version field to the newest release you have encountered the issue with. Before doing so, please ensure you are testing the latest kernel update in that release and attach any new and relevant information you may have gathered. If you are not the original bug reporter and you still experience this bug, please file a new report, as it is possible that you may be seeing a different problem. (Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).
tested with 3.6.3 Kernel. Same symptom with pm-hibernate/pm-suspend. I think bugs 679631 and 865597 are all related to the same problem here and according to bug 679631 recent update it is likely in the region in mvsas/libsas driver. 3 bugs share the commons: Lenovo D20 workstation which use SATA drives.
Is this still an issue with 3.8.2?
thank you, Justin. I tried 3.8.3 and 3.8.4-1 (missed 3.8.2) recently. The problem is still there with hibernate/suspend. the error message is similar to the above with (maybe additional one): READ FPDMA failed. ... I also tried one kernal option nohpet from arch linux website; with no success.
More update on this bug: I think this related to the Marvell sas/sata controller 88SE6480. I have 2 sata/sas controllers on my system: Intel ICH10 (3 ports) and Marvell 88SE6480, which Lenovo is intended for (software) raid and I use for JBOD. Both can be used to boot into the system (connected to marvell or intel that is fine). However, only when disk(s) is connected to intel controller, suspend/hibernate/resume works. here are some scenarios: 1. If boot disk (disk A) and data disk (disk B) are connected to marvell, then resume will fail. 2. if disk A is connected to marvell and disk B is connected to intel, then resume will fail. 3. if disk A is attached to intel and disk B is attached to marvel, then resume will "partially" succeed; disk A will fully resumed, however, disk B will not be attached thus will not be seen even after system is resumed back. thus it is obviously to say that problem is associated with Marvell 88SE6480 controller in the failure of resume from suspend/hibernation. This is true even if I just have 1 disk connected to intel or marvell. this is tested up to 3.10.10 kernel.
*********** 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 18 kernel bugs. Fedora 18 has now been rebased to 3.11.4-101.fc18. 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 19, and are still experiencing this issue, please change the version to Fedora 19. If you experience different issues, please open a new bug report for those.
tested in kernel 3.11.5-5 and still not working. believe this is related to marvell driver and mvsas doesn't work correct in the hibernate & suspend / resume mode.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
*********** 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.13.4-200.fc20. Please test this kernel update 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.
*********** MASS BUG UPDATE ************** This bug has been in a needinfo state for several weeks and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 20, please feel free to reopen the bug and provide the additional information requested.