Description of problem:
With upgrade to F8, one of my Dell Inspiron 6400 notebooks fails to hibernate
with errors related to writes to disks (along the lines of: unable to write to
swap, EXT3-fs unable to write etc.). The weird bit is that my other Dell
Inspiron 6400 (which has a slightly different configuration) has no problems
whatsoever. My best guess is that this difference is what's causing the problem.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot F8 on this notebook.
2. Attempt to hibernate.
3. Watch it print endless messages about inability to write to disk.
Fails to hibernate.
Worked fine under F7 with all the updates (i.e. kernel 126.96.36.199-21).
I'm using the "combined_mode=libata" boot option to enable good performance on
Upgrade to latest Koji kernel (-49) doesn't fix the problem. The only difference
is that the machine remounts ext3 file systems read only and then goes back to X
(i.e. one can see the mouse pointer), which is, of course, unusable, because all
file systems are mounted read only. Ditto logging into one of the text consoles.
The only option is to turn the system off.
Repeated fsck of the file systems and runs of badblocks did not reveal any file
system or disk problems.
Apart from this, F8 appears to work fine on this notebook.
I will attach dmesg and lspci from both notebooks.
Created attachment 253541 [details]
lspci -vv from the notebook that fails hibernation
Created attachment 253551 [details]
dmesg from the notebook that fails hibernation
Created attachment 253561 [details]
lspci -vv from the notebook that doesn't fail hibernation
Created attachment 253571 [details]
dmesg from the notebook that doesn't fail hibernation
In fact, downgrading to F7 kernel (188.8.131.52-21.fc7) makes this go away on F8 as
(In reply to comment #0)
> Description of problem:
> With upgrade to F8, one of my Dell Inspiron 6400 notebooks fails to hibernate
> with errors related to writes to disks (along the lines of: unable to write to
> swap, EXT3-fs unable to write etc.).
We need to see the exact messages.
> We need to see the exact messages.
Yeah, I knew you were going to say that :-)
Had my camera ready, but then the failure decided to hang my X instead. I'll try
to reproduce again and take a photo.
BTW, there is nothing in the logs (i.e. the file system is already screwed at
that point). Any other way to catch this, apart from taking a photo?
Created attachment 253721 [details]
Error as seen from run level 3 after running pm-hibernate
Created attachment 253731 [details]
End of dmesg output (sorry, more/less would not work - I/O error)
Created attachment 255081 [details]
I can confirm this with kernel 184.108.40.206-49.fc8
Dell 6400 notebook too. I think it happens on suspend too, because when it
resumes I see the cursor but nothing else.
Like OP many disk errors on resume. see attachment above
I can confirm that 220.127.116.11-21.fc7 (from FEDORA 7) works fine for suspend and
hibernate and I can resume fine.
I suspect that this bug applies both to hibernation and suspend. When suspending
with the f8 kernel, it suspends but appears to be a read only file system on
resume (only cursor moves, can't change console etc..). On hibernation lots of
disk errors - same as bug reporter.
I've installed the i686 version of the f7 kernel and no problems
Created attachment 260241 [details]
excerpt of lspci -vv and dmesg for ICH7 SATA controller
My Dell M1710 (lshal smbios.system.product = 'MXG061') also has this problem.
Hibernate worked well in F7, but now crashes in an identical error (ext3 sends
scary messages about I/O errors). Suspend to RAM appears to succeed (goes to
sleep), but again it resumes in a very angry state, losing all access to the
disk drive. Dmesg has errors like:
end_request: I/O error, dev sda, sector 35517611
sd 0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK
Other distros like Ubuntu appear to have run into this as well, and some claim
to have fixed it.
I've attached segments of lspci -vv and dmesg that show the controller. If you
want the whole thing let me know.
I see 18.104.22.168-61.fc8 is being built in Koji. Is it likely to contain fixes for
This one (22.214.171.124-61.fc8) works on my box.
126.96.36.199-61.fc8 also fixes my hibernate problems, and the machine comes back
to life after a suspend as well (the NVidia-based display doesn't come out of
sleep, but that's a separate and known issue)
I can confirm 188.8.131.52-61.fc8 fixes this issue
As of kernel 184.108.40.206-63.fc8, my hibernate function has broke. It appears to
hibernate correctly, but when I try to wake it up, all I get is the cursor
flashing in the top left of the screen. I have not tried suspend yet, but I am
guessing it will react the same.
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the Fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel?
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
As reported before in this bug, this has been fixed.