Bug 771142

Summary:	hibernate doesn't resume correctly
Product:	[Fedora] Fedora	Reporter:	andyzhu35
Component:	kernel	Assignee:	Kernel Maintainer List <kernel-maint>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	20	CC:	admin, andyzhu35, dwmw2, gansalmon, hughsient, itamar, jforbes, jonathan, jskarvad, kernel-maint, madhu.chinakonda, paul.destefano-redhat2, pknirsch
Target Milestone:	---	Flags:	jforbes: needinfo?
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-03-17 18:43:11 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description andyzhu35 2012-01-02 00:55:40 UTC

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:

Comment 1 Josh Boyer 2012-01-03 22:58:50 UTC

Please try kernel-3.1.7-1.fc16 which will be in the next f16-updates-testing push.

Comment 2 andyzhu35 2012-01-06 01:47:27 UTC

Is there any release schedule to share?  Or is there any twist of kernel parameters on current kernel 3.1.6-1?

Thank you

Comment 3 Josh Boyer 2012-01-06 12:32:54 UTC

(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

Comment 4 andyzhu35 2012-01-07 02:58:02 UTC

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?

Comment 5 Josh Boyer 2012-01-08 15:06:08 UTC

Are you by chance using the nVidia module?

Comment 6 andyzhu35 2012-01-08 16:38:17 UTC

No.  Nouveau driver.  But my graphic card is Nvidia FX480.

Comment 7 andyzhu35 2012-01-10 01:18:11 UTC

I mean I only use Nouveau driver.

Comment 8 andyzhu35 2012-01-14 00:06:03 UTC

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.

Comment 9 andyzhu35 2012-01-18 01:58:17 UTC

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.

Comment 10 andyzhu35 2012-01-23 21:59:25 UTC

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.

Comment 11 andyzhu35 2012-01-25 02:35:45 UTC

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?

Comment 12 andyzhu35 2012-01-28 17:13:05 UTC

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.

Comment 13 andyzhu35 2012-02-04 04:19:05 UTC

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...

Comment 14 andyzhu35 2012-02-11 19:45:00 UTC

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.

Comment 15 andyzhu35 2012-03-23 08:23:12 UTC

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.

Comment 16 Jaroslav Škarvada 2012-03-23 08:33:00 UTC

According to previous comments I am changing component to kernel.

Comment 17 andyzhu35 2012-04-03 04:01:50 UTC

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...

Comment 18 andyzhu35 2012-04-07 04:30:23 UTC

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
...

Comment 19 andyzhu35 2012-05-05 05:23:29 UTC

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).

Comment 20 andyzhu35 2012-05-10 02:39:40 UTC

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?

Comment 21 andyzhu35 2012-05-11 06:39:10 UTC

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.

Comment 22 livelace 2012-07-07 16:18:42 UTC

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.

Comment 23 andyzhu35 2012-07-08 19:58:59 UTC

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.

Comment 24 livelace 2012-07-09 04:53:59 UTC

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.

Comment 25 andyzhu35 2012-07-10 03:56:40 UTC

Hi, livelace:

Thank you for your link.  Hope libsas update will fix this problem.  Will wait to see.

Comment 26 Dave Jones 2012-10-23 15:36:47 UTC

# 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).

Comment 27 andyzhu35 2012-10-27 07:46:52 UTC

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.

Comment 28 Justin M. Forbes 2013-03-14 21:12:03 UTC

Is this still an issue with 3.8.2?

Comment 29 andyzhu35 2013-03-23 04:41:33 UTC

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.

Comment 30 andyzhu35 2013-09-15 22:44:16 UTC

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.

Comment 31 Justin M. Forbes 2013-10-18 21:15:54 UTC

*********** 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.

Comment 32 andyzhu35 2013-10-20 02:58:05 UTC

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.

Comment 33 Fedora End Of Life 2013-12-21 08:31:48 UTC

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.

Comment 34 Justin M. Forbes 2014-02-24 13:59:35 UTC

*********** 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.

Comment 35 Justin M. Forbes 2014-03-17 18:43:11 UTC

*********** 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.