From owner-freebsd-current@FreeBSD.ORG  Sat Jul 31 00:14:09 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 38A1C16A4CE
	for <current@freebsd.org>; Sat, 31 Jul 2004 00:14:09 +0000 (GMT)
Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2])
	by mx1.FreeBSD.org (Postfix) with ESMTP id AF19843D45
	for <current@freebsd.org>; Sat, 31 Jul 2004 00:14:07 +0000 (GMT)
	(envelope-from dillon@apollo.backplane.com)
Received: from apollo.backplane.com (localhost [127.0.0.1])
	i6V0DIds085698;	Fri, 30 Jul 2004 17:13:19 -0700 (PDT)
	(envelope-from dillon@apollo.backplane.com)
Received: (from dillon@localhost)
	by apollo.backplane.com (8.12.9p2/8.12.9/Submit) id i6V0DI9D085697;
	Fri, 30 Jul 2004 17:13:18 -0700 (PDT)
	(envelope-from dillon)
Date: Fri, 30 Jul 2004 17:13:18 -0700 (PDT)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <200407310013.i6V0DI9D085697@apollo.backplane.com>
To: Nate Lawson <nate@root.org>
References: <410AD054.8070202@root.org>
cc: current@freebsd.org
cc: sos@deepcore.dk
Subject: Re: memory corruption/panic solved ("FAILURE - ATAPI_IDENTIFY no
	interrupt")
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 31 Jul 2004 00:14:09 -0000

:I've tracked down the source of the memory corruption in -current that
:results when booting with various CD and DVD drives (especially the ones
:that come with Thinkpads including T23, R32, T41, etc.)  The panic is
:..

    Nick, what about the retry code in ata_completed()? (ata-queue.c 229).
    Does it need to reset donecount as well?  Both the code in 5.x and 
    the code in 4.x looks 'dangerous' with regards to general retries.

    The 5.x code seems to handle retries generically via 
    ata_finish()->ata_completed()->(retry handling), and this seems to
    include IMMEDIATE requests, and it does not appear to reset the 
    donecount when it requeues.

    The 4.x code seems to handle retries in ad_timeout() and ad_interrupt()
    (and doesn't reset donecount in either case as far as I can tell),
    and the 4.x code's addump() seems to rely on donecount in its transfer
    loop (but I do not see any similar reliance in the 5.x code).

						-Matt