From nobody@www.freebsd.org  Wed May 29 20:25:34 2002
Return-Path: <nobody@www.freebsd.org>
Received: from nwww.freebsd.org (www.FreeBSD.org [216.136.204.117])
	by hub.freebsd.org (Postfix) with ESMTP id D267737B400
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 29 May 2002 20:25:33 -0700 (PDT)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by nwww.freebsd.org (8.12.2/8.12.2) with ESMTP id g4U3PXhG060072
	for <freebsd-gnats-submit@FreeBSD.org>; Wed, 29 May 2002 20:25:33 -0700 (PDT)
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.12.2/8.12.2/Submit) id g4U3PXYK060071;
	Wed, 29 May 2002 20:25:33 -0700 (PDT)
Message-Id: <200205300325.g4U3PXYK060071@www.freebsd.org>
Date: Wed, 29 May 2002 20:25:33 -0700 (PDT)
From: "M.J.Kouache" <bsdmail@rhoda.fsworld.co.uk>
To: freebsd-gnats-submit@FreeBSD.org
Subject: HPT372 fixes have not propagated down to 4-stable
X-Send-Pr-Version: www-1.0

>Number:         38721
>Category:       misc
>Synopsis:       HPT372 fixes have not propagated down to 4-stable
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 29 20:30:01 PDT 2002
>Closed-Date:    Mon Jun 24 12:33:42 PDT 2002
>Last-Modified:  Mon Jun 24 12:33:42 PDT 2002
>Originator:     M.J.Kouache
>Release:        4-stable
>Organization:
>Environment:
irrelevant, the bugs in the code are obvious.
>Description:
      Despite the release docs saying 4.5 supports the HPT372 controller, it doesn't actually work, and 4-STABLE still doesn't.
 The controller is recognised, but is not correctly initialised by the 4.x code and is unable to actually operate.
 After having perused the code, it is also apparent that 4.x would set UDMA5 when UDMA6 was requested, which would be a bug, but the code never runs because of the initialisation bug.

 This has been cured in 5.0, and the diffs to fix HPT372 alone are almost negligible. I have include specific diffs for _my_ HTP372 , but I suggest the person(s) responsible take a look at the whole of the HPT37x series updates in 5.0 and make a quick decision on wether to just go for that 1 or include all of them, there's not a great deal of change anyway.

Also, it's reported as ATA100, when it's actually ATA133, but that's obviously not a critical problem.

 
>How-To-Repeat:
      run 4.5 RELEASE ... 4-STABLE, on an system with an I-Will XP333-R motherboard, and (I guess) other HPT372 equipped machines.
>Fix:

these are 'diff -c; of my hpt372 fixed code against 4-STABLE

*** ata-all.c	Sat Jan  5 17:49:36 2002
--- ata-all.fixed.c	Thu May 30 04:22:43 2002
***************
*** 399,405 ****
  	case 0x04:
  	    return "HighPoint HPT370 ATA100 controller";
  	case 0x05:
! 	    return "HighPoint HPT372 ATA100 controller";
  	default:
  	    return "Unknown revision HighPoint ATA controller";
  	}
--- 399,405 ----
  	case 0x04:
  	    return "HighPoint HPT370 ATA100 controller";
  	case 0x05:
! 	    return "HighPoint HPT372 ATA133 controller";
  	default:
  	    return "Unknown revision HighPoint ATA controller";
  	}
***************
*** 510,515 ****
--- 510,516 ----
  	case 0x02:
  	case 0x03:
  	case 0x04:
+ 	case 0x05:
  	    /* turn off interrupt prediction */
  	    pci_write_config(dev, 0x51, 
  	    		     (pci_read_config(dev, 0x51, 1) & ~0x02), 1);
***************
*** 1172,1178 ****
       */
      switch (scp->chiptype) {
  #if NPCI > 0
!     case 0x00041103:    /* HighPoint HPT366/368/370 */
  	if (((dmastat = ata_dmastatus(scp)) &
  	    (ATA_BMSTAT_ACTIVE | ATA_BMSTAT_INTERRUPT)) != ATA_BMSTAT_INTERRUPT)
  	    return;
--- 1173,1179 ----
       */
      switch (scp->chiptype) {
  #if NPCI > 0
!     case 0x00041103:    /* HighPoint HPT366/368/370/372 */
  	if (((dmastat = ata_dmastatus(scp)) &
  	    (ATA_BMSTAT_ACTIVE | ATA_BMSTAT_INTERRUPT)) != ATA_BMSTAT_INTERRUPT)
  	    return;

*** ata-dma.c	Sat Jan  5 17:49:36 2002
--- ata-dma.fixed.c	Thu May 30 04:11:23 2002
***************
*** 926,936 ****
  	    error = ata_command(scp, device, ATA_C_SETFEATURES, 0,
  				ATA_UDMA6, ATA_C_F_SETXFER, ATA_WAIT_READY);
  	    if (bootverbose)
! 		ata_printf(scp, device, "%s setting UDMA5 on HighPoint chip\n",
  			   (error) ? "failed" : "success");
  	    if (!error) {
! 		hpt_timing(scp, devno, ATA_UDMA5);
! 		scp->mode[ATA_DEV(device)] = ATA_UDMA5;
  		return;
  	    }
  	}
--- 926,936 ----
  	    error = ata_command(scp, device, ATA_C_SETFEATURES, 0,
  				ATA_UDMA6, ATA_C_F_SETXFER, ATA_WAIT_READY);
  	    if (bootverbose)
! 		ata_printf(scp, device, "%s setting UDMA6 on HighPoint chip\n",
  			   (error) ? "failed" : "success");
  	    if (!error) {
! 		hpt_timing(scp, devno, ATA_UDMA6);
! 		scp->mode[ATA_DEV(device)] = ATA_UDMA6;
  		return;
  	    }
  	}



>Release-Note:
>Audit-Trail:

From: "M.J.Kouache" <bsdmail@rhoda.fsworld.co.uk>
To: freebsd-gnats-submit@FreeBSD.org, bsdmail@rhoda.fsworld.co.uk
Cc:  
Subject: Re: misc/38721: HPT372 fixes have not propagated down to 4-stable
Date: Sat, 15 Jun 2002 06:44:35 +0100

 They appear to be in the -stable tree now,
 so please close this pr, thanks.
 
 >8O)
 
 P.S.
  Sorry if the original pr seems mis-filed, but I originally meant to stat=
 e=20
 that the problem would also go away if HPT372 compatability was scrubbed =
 from=20
 the hardware docs (it got lost in the editing somewhere), so it seemed=20
 equally valid and invalid as both kern/ and doc/ to me (I'm a bsd newbie,=
  as=20
 you probably figured out already).
 
State-Changed-From-To: open->closed 
State-Changed-By: robert 
State-Changed-When: Mon Jun 24 12:32:59 PDT 2002 
State-Changed-Why:  
The missing changes were integrated into -stable. 

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