In working on swsusp, I've found the following patches were needed.
The first fragment is trivial, as you'll see.
The second and third handle the fact that the suspend & resume functions
can be called multiple times. Pavel asked me to pass it on immediately.
The fourth handles the fact that writeback caches seem to be implemented
in two ways. People using swsusp under 2.4 found that everything worked
fine if they rebooted after writing the image, but powering down at the
end of writing the image caused corruption. I got the additional check
from the source for hdparm, which only does the new check to determine
if a drive has a writeback cache.
Regards,
Nigel
--- linux-2.5.66-original/drivers/ide/ide-disk.c 2003-03-26 08:56:49.000000000 +1200
+++ linux-2.5.66/drivers/ide/ide-disk.c 2003-04-05 18:51:17.000000000 +1200
@@ -1515,7 +1515,7 @@
{
ide_drive_t *drive = dev->driver_data;
- printk("Suspending device %p\n", dev->driver_data);
+ printk(KERN_INFO "Suspending device %p\n", dev->driver_data);
/* I hope that every freeze operation from the upper levels have
* already been done...
@@ -1527,7 +1527,7 @@
/* set the drive to standby */
printk(KERN_INFO "suspending: %s ", drive->name);
do_idedisk_standby(drive);
- drive->blocked = 1;
+ drive->blocked++;
BUG_ON (HWGROUP(drive)->handler);
return 0;
@@ -1539,8 +1539,8 @@
if (level != RESUME_RESTORE_STATE)
return 0;
- BUG_ON(!drive->blocked);
- drive->blocked = 0;
+ if (drive->blocked)
+ drive->blocked--;
return 0;
}
@@ -1804,7 +1804,8 @@
if ((!drive->head || drive->head > 16) && !drive->select.b.lba) {
printk(KERN_ERR "%s: INVALID GEOMETRY: %d PHYSICAL HEADS?\n",
drive->name, drive->head);
- if ((drive->id->cfs_enable_2 & 0x3000) && drive->wcache)
+ if (((drive->id->cfs_enable_2 & 0x3000) && drive->wcache) ||
+ ((drive->id->command_set_1 & 0x20) && drive->id->cfs_enable_1 & 0x20))
if (do_idedisk_flushcache(drive))
printk (KERN_INFO "%s: Write Cache FAILED Flushing!\n",
drive->name);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/