From nobody@FreeBSD.org  Sat Jan 23 14:46:21 2010
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id A47D7106568B
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 Jan 2010 14:46:21 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id AE1238FC1B
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 Jan 2010 14:46:20 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id o0NEkKB2053930
	for <freebsd-gnats-submit@FreeBSD.org>; Sat, 23 Jan 2010 14:46:20 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id o0NEkKAS053927;
	Sat, 23 Jan 2010 14:46:20 GMT
	(envelope-from nobody)
Message-Id: <201001231446.o0NEkKAS053927@www.freebsd.org>
Date: Sat, 23 Jan 2010 14:46:20 GMT
From: Andrey Russev <ruan@mail.univ.kiev.ua>
To: freebsd-gnats-submit@FreeBSD.org
Subject: [ata] Data loss on read timeout
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         143126
>Category:       kern
>Synopsis:       [ata] Data loss on read timeout
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          open
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sat Jan 23 14:50:01 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator:     Andrey Russev
>Release:        8.0
>Organization:
>Environment:
FreeBSD mizar 8.0-RELEASE FreeBSD 8.0-RELEASE #1: Sun Nov 29 02:44:55 EET 2009     root@mizar:/usr/src/sys/i386/compile/MIZAR  i386
>Description:
Sometimes (possibly on heavy loads of disk) kernel prints messages like:
ad6: TIMEOUT - READ_DMA48 retrying (1 retry left) LBA=615699968
These messages appear while copy/move of large file in progress. Such timeouts do not interrupt commands and they finish _without_ errors.
In case mentioned above I figured out that data from previous 64k block (LBA=615699968-128) was damaged (first ~30% bytes are correct). Second copy command (after unmount/mount) makes exact copy of data.

>How-To-Repeat:
I don't know. It occurs at random intervals.
>Fix:


>Release-Note:
>Audit-Trail:
>Unformatted:
