Alan Cox wrote:
+ if (dev->needs_flush && ata_try_flush_cache(dev)) {
return ata_scsi_flush_xlat;
+ dev->needs_flush = 0;
Works better if you swap the dev-> and return lines
Heh, yeah, I noticed that!
Here it is, *tested* now, with another fix.
It would be nice if somebody who can hear the "pop" would also test this,
as it will confirm that this is a complete fix for the problem.
My "pop" drives are busy elsewhere right now.
Tejun might use something like this, or do something better in libata-core,
but it's still helpful to have confirmation that we're on the right track.
This patch eliminates the redundant "SYNCHRONIZE_CACHE" request at shutdown
which is causing undue wear/tear/alarm to various systems.
Signed-off-by: Mark Lord <[EMAIL PROTECTED]>
---
--- old/include/linux/libata.h 2007-04-18 10:30:25.000000000 -0400
+++ linux/include/linux/libata.h 2007-04-18 10:30:28.000000000 -0400
@@ -499,6 +499,7 @@
struct ata_ering ering;
int spdn_cnt;
unsigned int horkage; /* List of broken features */
+ int needs_sync_cache; /* 0==sync-cache not needed */
#ifdef CONFIG_SATA_ACPI
/* ACPI objects info */
acpi_handle obj_handle;
--- old/drivers/ata/libata-scsi.c 2007-04-18 10:48:34.000000000 -0400
+++ linux/drivers/ata/libata-scsi.c 2007-04-18 10:51:09.000000000 -0400
@@ -2749,18 +2749,20 @@
return atapi_xlat;
switch (cmd) {
- case READ_6:
- case READ_10:
- case READ_16:
-
case WRITE_6:
case WRITE_10:
case WRITE_16:
+ dev->needs_sync_cache = 1;
+ case READ_6:
+ case READ_10:
+ case READ_16:
return ata_scsi_rw_xlat;
case SYNCHRONIZE_CACHE:
- if (ata_try_flush_cache(dev))
+ if (dev->needs_sync_cache && ata_try_flush_cache(dev)) {
+ dev->needs_sync_cache = 0;
return ata_scsi_flush_xlat;
+ }
break;
case VERIFY:
@@ -2769,6 +2771,7 @@
case ATA_12:
case ATA_16:
+ dev->needs_sync_cache = 1;
return ata_scsi_pass_thru;
case START_STOP:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
