From owner-freebsd-stable@FreeBSD.ORG Sun Feb 24 03:09:29 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A2F60EAC for ; Sun, 24 Feb 2013 03:09:29 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by mx1.freebsd.org (Postfix) with ESMTP id 67A5210BC for ; Sun, 24 Feb 2013 03:09:29 +0000 (UTC) Received: from omta11.emeryville.ca.mail.comcast.net ([76.96.30.36]) by qmta03.emeryville.ca.mail.comcast.net with comcast id 42WG1l0020mlR8UA339VSr; Sun, 24 Feb 2013 03:09:29 +0000 Received: from koitsu.strangled.net ([67.180.84.87]) by omta11.emeryville.ca.mail.comcast.net with comcast id 439U1l0051t3BNj8X39Ug1; Sun, 24 Feb 2013 03:09:28 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 03CA573A31; Sat, 23 Feb 2013 19:09:28 -0800 (PST) Date: Sat, 23 Feb 2013 19:09:27 -0800 From: Jeremy Chadwick To: Michael BlackHeart Subject: Re: Old ICH7 SATA-2 question Message-ID: <20130224030927.GA46638@icarus.home.lan> References: <20130223211932.GA41809@icarus.home.lan> <20130224001307.GA43436@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130224001307.GA43436@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1361675369; bh=++lPy7n4kozBHxGxIb2OrkwxUnYqcAgB2/vszmzVdrw=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=EM4mLVMcens953zqnGwQ+Pji/tjfY6hJjKuTpQmtmoziGPuQnN3sYoMxCO9ubqXyy ZAfhPSaaZ/tQwqyIONiAU3fIgnjGRFWBIWAgezH+wss6Z2CTPO9VbpufYtz//xDBO/ jDWg2U6i3r89rTIrq2zSbwdN/keYxCoIGdxi/MWbYEkresjPSe/qLr3WSNQYJn6S0l 98TRBoOHH4N9juzhoH0CiyVGChUqAqmKKyS5UvSnb6gNJw25xhvx2BjjsOZA9VHIUR G0k5IDvML4vAfLX8cxAWbS0tZkyoaMBggzoie1IIhmT+wXdPIDhjQOHaQm+gvTH7KZ gFPe8rrONVlcw== Cc: mav@freebsd.org, freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Feb 2013 03:09:29 -0000 On Sat, Feb 23, 2013 at 04:13:07PM -0800, Jeremy Chadwick wrote: > On Sun, Feb 24, 2013 at 02:28:08AM +0400, Michael BlackHeart wrote: > > 2013/2/24 Jeremy Chadwick : > > > > {snipping irrelevant stuff and fixing formatting} > > > > atapci1@pci0:0:31:2: class=0x01018f card=0x26011043 chip=0x27c08086 rev=0x01 hdr=0x00 > > vendor = 'Intel Corporation' > > device = 'N10/ICH7 Family SATA IDE Controller' > > > > {snip} > > I had written up a significantly longer reply to this Email, but once I > finished and went back reviewing the information provided, my memory > recalled having this exact conversation some time ago. After some > extensive digging, I found it -- circa late 2008: > > http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046306.html > > The result of this conversation was that FreeBSD at the time -- this > would have been probably FreeBSD 8.0 or 8.1 -- contained a bug: > ata_chipset.c (part of the classic ata(4) driver) was misidentifying the > different revisions of ICH7 and therefore limiting controller capacities > incorrectly. > > Possibly a regression has been introduced as a result of the ATA-via-CAM > migration (now the default), which uses a completely different set of > code. CC'ing mav@ because I need some help/clarification on this one. I received an off-list mail from another ICH7 user, particularly one who is using an SSD. Their controller is identical (same vendor/device ID), and all their devices also claim "SATA" as well as "150MBytes/sec". However, "diskinfo -t" on the individuals' SSD shows quite clearly rates of up to 200MBytes/second. So the issue appears to be cosmetic. The question is why. Let me clarify because some list members have already gotten confused about some of the information output by the kernel and utilities. I'm going to use my own system (different controller, etc.) to educate list members. The fact I'm using AHCI has no bearing on this educational section, let me make that clear! * The following output during boot reflects the results of the ATA IDENTIFY command, and indicates what the **disk itself** (or more specifically, the controller on the disk itself) claims it is capable of: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 2.x device This indicates the ada0 disk supports up to the SATA 2.x revision (i.e. SATA300). This DOES NOT indicate what the motherboard (or HBA) SATA controllers' PHY/port is operating at; it only indicates what the disk supports "up to". * The subsequent output during boot reflects the actual motherboard (or HBA) SATA controllers' PHY/port speed, including what has been negotiated: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) There's a 1:1 mapping between SATA revision and PHY speed, effectively, unless otherwise throttled down or forced in some manner. I'm reminded of the non-ATA_CAM function ata_satarev2str() where the revision map is like this: value 0 = "" (default speed value is used?? unsure) value 1 = "SATA150" (150MB/sec) value 2 = "SATA300" (300MB/sec) value 3 = "SATA600" (600MB/sec) value 0xff = "SATA" (default speed value is used) else = "???" (default speed value is used?? unsure) Now for the rest... I've taken a look at the code and it's very difficult for me to follow; I'm not entirely sure, but it does look like pieces of sys/dev/ata/chipsets are still used today. I need mav@ to verify that fact however, because if ata_intel_probe() isn't used any more, then that might explain what's going on here (possibly). The "negotiated speed" printing comes from sys/cam/ata/ata_xpt.c, in ata_announce_periph(). The code logic here is simple, while the complex bits (e.g. what sets CTS_SATA_VALID_REVISION) are elsewhere. First, the speed: 2022 /* Report connection speed */ 2023 speed = cpi.base_transfer_speed; 2024 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_ATA) { 2025 struct ccb_trans_settings_pata *pata = 2026 &cts.xport_specific.ata; 2027 2028 if (pata->valid & CTS_ATA_VALID_MODE) 2029 speed = ata_mode2speed(pata->mode); 2030 } 2031 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { 2032 struct ccb_trans_settings_sata *sata = 2033 &cts.xport_specific.sata; 2034 2035 if (sata->valid & CTS_SATA_VALID_REVISION) 2036 speed = ata_revision2speed(sata->revision); 2037 } 2038 mb = speed / 1000; 2039 if (mb > 0) 2040 printf("%s%d: %d.%03dMB/s transfers", 2041 periph->periph_name, periph->unit_number, 2042 mb, speed % 1000); The if() statement that is being used in Michael's case is the one for XPORT_SATA, not XPORT_PATA; that will be proven further below. I then had two questions: 1. Where does base_transfer_speed get set? For SATA devices, it gets set in sys/dev/ata/ata-all.c (I think). The default value chosen is 150000: 1884 if (ch->flags & ATA_SATA) 1885 cpi->base_transfer_speed = 150000; 1886 else 1887 cpi->base_transfer_speed = 3300; 2. Where does CTS_SATA_VALID_REVISION get set, which can in effect override base_transfer_speed? The jury is still out on this one as you'll see. Now on to the "protocol revision" printing code, i.e. "SATA 2.x" -- remember we're talking about the negotiated speed/protocol, not what's returned from ATA IDENTIFY (e.g. "camcontrol identify") for the disk. 2060 if (cts.ccb_h.status == CAM_REQ_CMP && cts.transport == XPORT_SATA) { 2061 struct ccb_trans_settings_sata *sata = 2062 &cts.xport_specific.sata; 2063 2064 printf(" ("); 2065 if (sata->valid & CTS_SATA_VALID_REVISION) 2066 printf("SATA %d.x, ", sata->revision); 2067 else 2068 printf("SATA, "); 2069 if (sata->valid & CTS_SATA_VALID_MODE) 2070 printf("%s, ", ata_mode2string(sata->mode)); 2071 if ((sata->valid & CTS_ATA_VALID_ATAPI) && sata->atapi != 0) 2072 printf("ATAPI %dbytes, ", sata->atapi); 2073 if (sata->valid & CTS_SATA_VALID_BYTECOUNT) 2074 printf("PIO %dbytes", sata->bytecount); 2075 printf(")"); 2076 } 2077 printf("\n"); Here we can see that XPORT_SATA must be set, because Michael's kernel output clearly shows the above printf()s. But once again we're back to CTS_SATA_VALID_REVISION. Without CTS_SATA_VALID_REVISION being set, ata_xpt.c chooses to simply say "SATA". That's all -- just "SATA". And that is what Michael and others with this chip see. The question is, simply, why does this model of ICH7 result in the bit CTS_SATA_VALID_REVISION, in the "valid" member of the appropriate ccb_trans_settings_sata struct, not being set correctly. I dug further than this, but I ended up chasing my tail while trying to look at sys/dev/ata/ata-all.c in ataaction() to figure out what went on. I pretty much lost faith (well, not faith, just lost the driving force) when I tried to find ATA_GETREV -- it's generated during buildworld as an inline function and comes from a DEVMETHOD() macro expansion, I believe; look for ata_getrev instead. As I've said many times in the past: the rabbit hole is deep and it is very easy to get lost when you lack familiarity with this code. -- | Jeremy Chadwick jdc@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB |