From nobody@FreeBSD.ORG  Sun Jan  9 13:52:46 2000
Return-Path: <nobody@FreeBSD.ORG>
Received: by hub.freebsd.org (Postfix, from userid 32767)
	id 8F94E14EEF; Sun,  9 Jan 2000 13:52:46 -0800 (PST)
Message-Id: <20000109215246.8F94E14EEF@hub.freebsd.org>
Date: Sun,  9 Jan 2000 13:52:46 -0800 (PST)
From: klh@netcom.com
Sender: nobody@FreeBSD.ORG
To: freebsd-gnats-submit@FreeBSD.org
Subject: cam/scsi/scsi_da.c: Fujitsu M2952 doesn't like synch cache either
X-Send-Pr-Version: www-1.0

>Number:         16016
>Category:       kern
>Synopsis:       cam/scsi/scsi_da.c: Fujitsu M2952 doesn't like synch cache either
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jan  9 14:00:01 PST 2000
>Closed-Date:    Fri Feb 9 05:24:49 PST 2001
>Last-Modified:  Fri Feb 09 05:25:54 PST 2001
>Originator:     Ken Harrenstien
>Release:        3.3-RELEASE
>Organization:
>Environment:
FreeBSD bohica 3.3-RELEASE FreeBSD 3.3-RELEASE #0: Sat Dec 18 00:24:47 PST 1999     klh@bohica:/rj1/src/sys/compile/JUMPGATE  i386

>Description:
From system log:

Jan  9 00:17:44 bohica /kernel: (da2:amd0:0:2:0): Synchronize cache failed, status == 0xc0, scsi status == 0x2

This only happens for da2, which is a Fujitsu M2952ESP.  Other 2 drives
on system (IBM DPES and Seagate ST32550W) seem OK.
>How-To-Repeat:
With nothing mounted on the da2 Fujitsu:

# dd if=/dev/rda2s1 of=/dev/null bs=10b

Let it run for several seconds, then interrupt out.  Error message
pops up on console.
>Fix:
Examination of scsi_da.c suggests that the M2952 should be added to
da_quirk_table to join its close cousin, the M2954.

If more info or verification is desired, let me know.

>Release-Note:
>Audit-Trail:

From: "Justin T. Gibbs" <gibbs@FreeBSD.org>
To: klh@netcom.com
Cc: freebsd-gnats-submit@FreeBSD.ORG
Subject: Re: kern/16016: cam/scsi/scsi_da.c: Fujitsu M2952 doesn't like synch 
 cache either
Date: Sun, 09 Jan 2000 15:12:04 -0700

 >>Fix:
 >Examination of scsi_da.c suggests that the M2952 should be added to
 >da_quirk_table to join its close cousin, the M2954.
 >
 >If more info or verification is desired, let me know.
 
 Since you have hardware to test this, can you determine why the code
 to weed out devices that return ILLEGAL_REQUEST fails to work for
 your device?  We should be able to completely avoid quirk entries
 for this particular issue.
 
 --
 Justin
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: mjacob 
State-Changed-When: Mon Jan 15 23:57:46 PST 2001 
State-Changed-Why:  
Per Justin's request, can you supply the requested info or state 
that this is no longer a problem? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=16016 

From: Ken Harrenstien <klh@transmeta.com>
To: freebsd-gnats-submit@freebsd.org
Cc: klh@panix.com, mjacob@freebsd.org
Subject: Re: kern/16016: cam/scsi/scsi_da.c: Fujitsu M2952 doesn't like synch 
 cache either
Date: Thu, 08 Feb 2001 23:25:25 -0800

 Sorry, didn't realize this was still pending.  The audit trail does
 not reflect several messages that I exchanged with Justin, in which
 he diagnosed the code and made a fix to pci/amd.c which resolved the
 problem (completely, as far as I could tell).
 
 I just checked and the fix is there as of rev 1.3 (14-Jan-2000); has
 been out there for a while now.
 
 Appreciate the cleanup you are doing!
 
 --Ken
 
State-Changed-From-To: feedback->closed 
State-Changed-By: dwmalone 
State-Changed-When: Fri Feb 9 05:24:49 PST 2001 
State-Changed-Why:  
Submitter indicates that problem has been fixed. 

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