From wwwadmin@1822direkt.com  Thu Nov 13 06:13:08 2003
Return-Path: <wwwadmin@1822direkt.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 8FECA16A4CE
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Nov 2003 06:13:08 -0800 (PST)
Received: from www-3.1822direkt.com (www-3.1822direkt.com [213.83.45.132])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 0B6FC43FCB
	for <FreeBSD-gnats-submit@freebsd.org>; Thu, 13 Nov 2003 06:13:07 -0800 (PST)
	(envelope-from wwwadmin@1822direkt.com)
Received: from dirham.1822direkt.com (localhost.1822direkt.com [127.0.0.1])
	by www-3.1822direkt.com (8.12.10/8.12.9) with ESMTP id hADED7ZG003720;
	Thu, 13 Nov 2003 15:13:07 +0100 (CET)
	(envelope-from wwwadmin@dirham.1822direkt.com)
Received: (from wwwadmin@localhost)
	by dirham.1822direkt.com (8.12.10/8.12.10/Submit) id hADED7S8003719;
	Thu, 13 Nov 2003 15:13:07 +0100 (CET)
	(envelope-from wwwadmin)
Message-Id: <200311131413.hADED7S8003719@dirham.1822direkt.com>
Date: Thu, 13 Nov 2003 15:13:07 +0100 (CET)
From: dzuck@1822direkt.com
Reply-To: dzuck@1822direkt.com
To: FreeBSD-gnats-submit@freebsd.org
Cc: dzuck@1822direkt.com
Subject: ata device reset hangs if device is dead
X-Send-Pr-Version: 3.113
X-GNATS-Notify: dzuck@1822direkt.com

>Number:         59253
>Category:       i386
>Synopsis:       ata device reset hangs if device is dead
>Confidential:   no
>Severity:       critical
>Priority:       low
>Responsible:    sos
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Nov 13 06:20:09 PST 2003
>Closed-Date:    Mon Oct 04 11:27:27 GMT 2004
>Last-Modified:  Mon Oct 04 11:27:27 GMT 2004
>Originator:     Daniel Zuck
>Release:        FreeBSD 4.9-STABLE i386
>Organization:
1822direkt GmbH
>Environment:
System: FreeBSD dirham.1822direkt.com 4.9-STABLE FreeBSD 4.9-STABLE #3: Wed Nov 5 19:01:59 CET 2003 root@dirham.1822direkt.com:/usr/obj/usr/src/sys/DIRHAM i386
atapci0: <Intel PIIX4 ATA33 controller> port 0xfff0-0xffff at device 7.1 on pci0
ad0: 29325MB <Maxtor 2F030J0> [59582/16/63] at ata0-master UDMA33

	
>Description:
We experience problems with a certain charge of HDDs under different operating
plattforms. So even if the reason is pretty sure a hardware-issue, the ata
driver handles the situation for my understanding not so well.
The hardware-symptom is: The HDD dies while writing. The kernal messages are
like what you expect in that sort of trouble:
ad0: WRITE command timeout tag=0 serv=0 - resetting
ata0: resetting devices ..
However: The reset is never completed, as the device is really dead (until
you do a power-off, power-on reset), which causes - and that is the issue
of my PR - the kernel to freeze.
	
>How-To-Repeat:
Maybe you will not get the apropriate (faulty) hardware, so it may be
difficult to reproduce. But maybe you can HALT the device-electronics
with a certain signal. This should be okay to reproduce the device's 
behaviour.
As I leave together the faulty hardware for some time from now on,
I am willing to run code for testing on this platform and report the
results.
	
>Fix:
For my understanding the driver should never freeze the system, even if
in trouble with some messy faulty piece of hardware. However, if there
are some transactions needed, which require that they need to be done
non-preemtive, they should time-out after a certain period.
	


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-i386->sos 
Responsible-Changed-By: arved 
Responsible-Changed-When: Mon Aug 23 20:26:17 GMT 2004 
Responsible-Changed-Why:  
Over to ATA maintainer 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59253 
State-Changed-From-To: open->feedback 
State-Changed-By: sos 
State-Changed-When: Mon Aug 23 20:33:46 GMT 2004 
State-Changed-Why:  
ATA and ATAPI devices might get into a state where only a hard reset or  
powercycle is needed, and there is no way in the std ATA setup that we  
can deliver those. Its possible for the device to lock the PCI bus in 
some configs leading to system lockup, and there is nothing we can do 
about it. 

That said it would be interesting to know if -current handles this  
better than ancient 4.x does (at least I'd hope so)... 


http://www.freebsd.org/cgi/query-pr.cgi?pr=59253 
State-Changed-From-To: feedback->closed 
State-Changed-By: sos 
State-Changed-When: Mon Oct 4 11:26:35 GMT 2004 
State-Changed-Why:  
feedback timeout. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=59253 
>Unformatted:
