Bad sector on hard drive upon suspend resume.

[Replicant10000]

Hello all,

I use a Toshiba Satellite A215-S5818 with FC11 x64 and the 2.6.30.8-64 kernel. Today, something weird happened to me when I resumed the laptop after having hit "suspend to disk" from the KDE menu. The network was off due to my having clicked the wireless notch on the front from on to off before I left. I restarted from suspension (which usually makes me resume all the way from the GRUB boot list, don't ask me why) and tried to get into the 'net.

Oops. Wireless off.

So I clicked the notch back to the on position and found my network in the wireless network list. Clicked it, was asked for my network password and encryption. Put those in. Nothing happened, and the bubble that says "the network connection has been disconnected" showed up. Tried it twice more -- Same result.



So I decided to log out and log back in. Couldn't do that. Had to hit Ctrl-Alt-Backspace.

This is where things really get freaky:

The screen went black like it usually does, but the Xserver didn't restart. Instead I found this message:

EXT4-fs error (device dm-9) in ext4_delete_inode: IO failure
ext4_abort called
EXT4-fs error (device dm-9): ext4_journal_start_sb: Detected aborted journal
Remounting filesystem read only.

Whoa.

From that point on I figured it was best to hit the Ctrl-Alt-SysRq keys and restart the whole thing.

So I tried to complete the whole sequence of SysRq calls to reboot the computer (R,E,I,S,U,B) and I got . . . this.

SysRq:Terminate All Tasks
0:0:0:0: [sda] Unhandled error code
0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
cmd_request: I/O error, dev sda, sector 25653359
EXT4-fs error (device dm-9): ext4_find_entry: reading directory #43 offset 0
0:0:0:0: [sda] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
cmd_request: I/O error, dev sda, sector 25653359
EXT4-fs error (device dm-9): ext4_find_entry: reading directory #43 offset 0

o.O

What happened? It better not be my hard drive going south . . . I already corrected the Load_Cycle_Count killer bug and this is rated for 600K cycles regardless, a long way away from where it is now.