On 09/09/2012 04:11 PM, Arvydas Sidorenko wrote:
I think you know your way around SCSI/libata much better than I do.
I just bisected linux-next, and it comes down to the commit below, which
introduces the regression for me, and I'm guessing for you also. Maybe
it can be fixed up to satisfy us, but otherwise will have to be reverted:
we don't invert a default if it's going to break older working systems.
A good workaround for me meanwhile is to add boot option "libata.fua=0":
please try that (or reverting the commit) and let us know the result.
Thanks,
Hugh
commit 91895b786e631ab47b618c901231f22b5a44115b
Author: Zheng Liu <wenqing...@taobao.com>
Date: Tue May 8 11:24:03 2012 +0800
libata: enable SATA disk fua detection on default
Currently, SATA disk fua detection is disabled on default because most of
devices don't support this feature at that time. With the development of
technology, more and more SATA disks support this feature. So now we can
enable
this detection on default.
Although fua detection is defined as a kernel module parameter, it is too
hard
to set its value because it must be loaded and set before system starts up.
That needs to modify initrd file. So it is inconvenient for administrator
who
needs to manage a huge number of servers.
Signed-off-by: Zheng Liu <wenqing...@taobao.com>
Signed-off-by: Jeff Garzik <jgar...@redhat.com>
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 5eee1c1..c3fbdca 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -135,9 +135,9 @@ int atapi_passthru16 = 1;
module_param(atapi_passthru16, int, 0444);
MODULE_PARM_DESC(atapi_passthru16, "Enable ATA_16 passthru for ATAPI devices
(0=off, 1=on [default])");
-int libata_fua = 0;
+int libata_fua = 1;
module_param_named(fua, libata_fua, int, 0444);
-MODULE_PARM_DESC(fua, "FUA support (0=off [default], 1=on)");
+MODULE_PARM_DESC(fua, "FUA support (0=off, 1=on [default])");
static int ata_ignore_hpa;
module_param_named(ignore_hpa, ata_ignore_hpa, int, 0644);
Indeed, disabling FUA explicitly solved the issue on my disk as well.
Hugh, what hard drive you have this issue on?
I believe there are two solutions:
- Revert FUA default back to '0'
- Start filling SATA drive blacklist in function:
I think the right thing to do for release is disable it (again), then we
can try again later with better logic.
I'll send Linus a patch to disable.
It is entirely possible that this is a software problem, where we
missing some detail turning on FUA (thereby engaging some less traveled
core block layer machinery), or even a remote possibility of triggering
a filesystem bug.
Jeff
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
