From tbyte@otel.net  Sun Jul  2 22:54:17 2006
Return-Path: <tbyte@otel.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id EB9C916A52D;
	Sun,  2 Jul 2006 22:54:17 +0000 (UTC)
	(envelope-from tbyte@otel.net)
Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 6C0DA43E87;
	Sun,  2 Jul 2006 22:22:15 +0000 (GMT)
	(envelope-from tbyte@otel.net)
Received: from warhead.otel.net ([212.36.8.210])
	by mail.otel.net with esmtp (Exim 4.62 (FreeBSD))
	(envelope-from <tbyte@otel.net>)
	id 1FxAKT-0006AS-1N; Mon, 03 Jul 2006 01:22:13 +0300
Message-Id: <1151878932.16831@WarHeaD.OTEL.net>
Date: Mon, 3 Jul 2006 01:22:12 +0300
From: "Iasen Kostoff" <tbyte@otel.net>
To: "FreeBSD gnats submit" <FreeBSD-gnats-submit@freebsd.org>
Cc: freebsd-stable@freebsd.org
Subject: Bug in ata (ata-all.c) driver
X-Send-Pr-Version: gtk-send-pr 0.4.7 
X-GNATS-Notify:

>Number:         99729
>Category:       kern
>Synopsis:       [ata] [patch] Bug in ata (ata-all.c) driver
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    sos
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jul 02 23:00:33 GMT 2006
>Closed-Date:    Mon Feb 26 13:38:41 GMT 2007
>Last-Modified:  Mon Feb 26 13:38:41 GMT 2007
>Originator:     Iasen Kostoff
>Release:        FreeBSD 6.1-STABLE i386
>Organization:
OTEL.net 
>Environment:


System: FreeBSD 6.1-STABLE #2: Sat Jul  1 13:01:14 EEST 2006
    root@WarHeaD.OTEL.net:/usr/src6/sys/i386/compile/WARHEAD



>Description:


I found a little bug (probably) in sys/dev/ata-all.c which somehow corrupts device parameters structure. When I first did "atacontrol list" device info about ad0 looked like this:
Master:  ad0 <Maxtor 6Y080P0/YAR41BW0> ATA/ATAPI revision 7
after I ran "atacontrol cap ad0" it printed somewhat messy output like having enabled SMART but not supported...
then I did "atacontrol list" again and saw that the line about ad0 have changed to something like this:
Master:  ad0 <W0Maxtor 6Y080P0/YAR41BW0> ATA/ATAPI revision 0
or similar.

After some digging and comparing the way "IOCATADEVICES" and "IOCATAGPARM" work I saw (probably) bogus ata_getparam() call. After removing this call to ata_getparam() everything work as expected (atleast that's what it looks like for ~30 min run). "atacontrol cap ad0" shows right results and doesn't screw the device parameters. I just hope that this doesn't break something else but I doubt it coz it just gets info and doesn't set anything.




>How-To-Repeat:


In description.


>Fix:


--- ata-all.c.old	Sat Jul  1 04:10:30 2006
+++ ata-all.c	Sat Jul  1 04:40:26 2006
@@ -505,7 +505,6 @@
 	return error;
    
     case IOCATAGPARM:
-	ata_getparam(atadev, 0);
 	bcopy(&atadev->param, params, sizeof(struct ata_params));
 	return 0;
 


>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->sos 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun Jul 2 23:33:36 UTC 2006 
Responsible-Changed-Why:  
Over to maintainer. 

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

From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= <sos@deepcore.dk>
To: bug-followup@FreeBSD.org, tbyte@otel.net
Cc:  
Subject: Re: kern/99729: [ata] [patch] Bug in ata (ata-all.c) driver
Date: Mon, 03 Jul 2006 13:01:54 +0200

 The call to ata_getparam is *not* bogus, its needed to get the current 
 device settings.
 However the data shown should not be distorted as shown. Are you sure 
 that your kernel and userland is in sync ?
 
 -Sren

From: Iasen Kostov <tbyte@otel.net>
To: =?ISO-8859-1?Q?S=F8ren?= Schmidt <sos@deepcore.dk>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/99729: [ata] [patch] Bug in ata (ata-all.c) driver
Date: Mon, 03 Jul 2006 15:27:38 +0300

 On Mon, 2006-07-03 at 13:01 +0200, S=C3=B8ren Schmidt wrote:
 > The call to ata_getparam is *not* bogus, its needed to get the current=20
 > device settings.
 That's why I wrote "probably" coz it looked like right think there but
 removing it "fixed" the problem. Of course is I change the params it
 won't show it :(.
 > However the data shown should not be distorted as shown. Are you sure=20
 > that your kernel and userland is in sync ?
 Yep it were in sync. Is it possible that something is wrong with
 underlaying code or the it could be a problem with the chipset ? Here is
 the dmesg line:
 atapci0: <nVidia nForce CK804 UDMA133 controller> port
 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 6.0 on pci0
 and the coresponding drive line:
 ad0: 78167MB <Maxtor 6Y080P0 YAR41BW0> at ata0-master UDMA133
 
 to be 100% sure I'll csup & recompile the kernel and atacontrol (I think
 this should be enough world is no older than a week).
 
 

From: Iasen Kostov <tbyte@otel.net>
To: =?ISO-8859-1?Q?S=F8ren?= Schmidt <sos@deepcore.dk>
Cc: bug-followup@FreeBSD.org
Subject: Re: kern/99729: [ata] [patch] Bug in ata (ata-all.c) driver
Date: Mon, 03 Jul 2006 15:55:13 +0300

 Here is more complete documentation of the problem:
 
 #:> atacontrol list
 ATA channel 0:
     Master:  ad0 <Maxtor 6Y080P0/YAR41BW0> ATA/ATAPI revision 7
     Slave:       no device present
 ATA channel 1:
     Master: acd0 <TOSHIBA CD-ROM XM-6302B/1017> ATA/ATAPI revision 0
     Slave:       no device present
 ATA channel 2:
     Master:      no device present
     Slave:       no device present
 ATA channel 3:
     Master:      no device present
     Slave:       no device present
 ATA channel 4:
     Master:      no device present
     Slave:       no device present
 ATA channel 5:
     Master:      no device present
     Slave:       no device present
 
 #:> atacontrol cap ad0
 
 Protocol              ATA/ATAPI revision 0
 device model          W0Maxtor 6Y080P0
 serial number         Y2GCH92E
 firmware revision     9YAR41B
 cylinders             64
 heads                 51255
 sectors/track         0
 lba not supported         -1174404848 sectors
 lba48 supported
 dma not supported
 overlap not supported
 
 Feature                      Support  Enable    Value           Vendor
 write cache                    no       no
 read ahead                     no       no
 Tagged Command Queuing (TCQ)   yes      no      0/0x00
 SMART                          no       yes
 microcode download             yes      yes
 security                       yes      yes
 power management               yes      no
 advanced power management      yes      yes     0/0x00
 automatic acoustic management  no       no      11/0x0B 96/0x60
 
 #:> atacontrol list
 ATA channel 0:
     Master:  ad0 <W0Maxtor 6Y080P0/9YAR41B> ATA/ATAPI revision 0
     Slave:       no device present
 ATA channel 1:
     Master: acd0 <TOSHIBA CD-ROM XM-6302B/1017> ATA/ATAPI revision 0
     Slave:       no device present
 ATA channel 2:
     Master:      no device present
     Slave:       no device present
 ATA channel 3:
     Master:      no device present
     Slave:       no device present
 ATA channel 4:
     Master:      no device present
     Slave:       no device present
 ATA channel 5:
     Master:      no device present
     Slave:       no device present
 
 root@WarHeaD:~ on ttyp0
 #:> diff -u /usr/include/sys/ata.h /sys/sys/ata.h
 root@WarHeaD:~ on ttyp0
 #:>
 
 #:> ll /sbin/atacontrol
 -r-xr-xr-x  1 root  wheel  13212 Jul  3 15:42 /sbin/atacontrol*
 
 #:> uname -a
 FreeBSD WarHeaD.OTEL.net 6.1-STABLE FreeBSD 6.1-STABLE #0: Mon Jul  3
 15:34:57 EEST 2006
 root@WarHeaD.OTEL.net:/usr/obj/usr/src6/sys/WARHEAD  i386
 
 It's csuped today.
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: sos 
State-Changed-When: Mon Sep 18 18:47:39 UTC 2006 
State-Changed-Why:  
I've made several changes to the nVidia code, could you retest if this is 
still a problem for you as I've newer been able to reproduce the problem. 
Thanks! 

http://www.freebsd.org/cgi/query-pr.cgi?pr=99729 
State-Changed-From-To: feedback->closed 
State-Changed-By: remko 
State-Changed-When: Mon Feb 26 13:38:32 UTC 2007 
State-Changed-Why:  
Soren requested feedback for this a long time ago, none was recorded in 
the ticket. Closing the PR ticket assuming this got fixed. If not please 
report back to -me- so that I can make sure that all relevant data is 
included in the ticket prior to informing Soren (to avoid overloading 
Soren). 

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