Re: Loud "pop" coming from hard drive on reboot

[Mark Lord]

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 <mlord@xxxxxxxxx>
---
--- 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/