From owner-freebsd-fs@FreeBSD.ORG Fri Aug 5 03:30:18 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0C96106566C for ; Fri, 5 Aug 2011 03:30:18 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by mx1.freebsd.org (Postfix) with ESMTP id D231A8FC13 for ; Fri, 5 Aug 2011 03:30:18 +0000 (UTC) Received: from omta20.emeryville.ca.mail.comcast.net ([76.96.30.87]) by qmta10.emeryville.ca.mail.comcast.net with comcast id GTQz1h0041smiN4AATWEAA; Fri, 05 Aug 2011 03:30:14 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta20.emeryville.ca.mail.comcast.net with comcast id GTWb1h01p1t3BNj8gTWkar; Fri, 05 Aug 2011 03:30:47 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id C4537102C19; Thu, 4 Aug 2011 20:30:01 -0700 (PDT) Date: Thu, 4 Aug 2011 20:30:01 -0700 From: Jeremy Chadwick To: Steven Hartland Message-ID: <20110805033001.GA47366@icarus.home.lan> References: <13BEC27B17D24D0CBF2E6A98FD3227F3@multiplay.co.uk> <20110728012437.GA23430@icarus.home.lan> <20110728103234.GA33275@icarus.home.lan> <20110728145917.GA37805@icarus.home.lan> <2A07CD8AE6AE49A5BAED59A7E547D1F9@multiplay.co.uk> <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D117F9F212A4CCBA6B7F51E8705BDB7@multiplay.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-fs@FreeBSD.ORG Subject: Re: Questions about erasing an ssd to restore performance under FreeBSD X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 03:30:19 -0000 On Fri, Aug 05, 2011 at 12:10:40AM +0100, Steven Hartland wrote: > ----- Original Message ----- From: "Steven Hartland" > >>Understood. I'm off work this week so I'll see if I can dedicate some > >>time to it. Too many non-work projects I'm juggling right now, argh. > >> > >>I'll have to start with camcontrol since the test system I have uses > >>ada(4) and not classic ata(4). I'm not even sure what I'm really in for > >>given that I've never looked at camcontrol's code before. > >> > >>If I "brick" my SSD I'll send you a bill, Steven. Kidding. :-) > > We seem to be having this issue on more disks now so I thought I'd > have a bash at it to see how far I could get. To my suprise I think > I've pretty much got it all the ata security options added to camcontrol. > > The only outstanding issue seems to be cam / ata appears to have an > overflow bug which limits timeouts to 2147 seconds or less which would > likely cause issues for rotary disks. > > I've posted about this in a seperate thread > "cam / ata timeout limited to 2147 due to overflow bug?" > > In the mean time would you be interested in reviewing the code Jeremy? I can try. I started working on it myself last weekend and ended up experiencing some anomalies that required me to mail mav@. My request CDBs through CAM were being rejected with ABRT (which can happen per ATA specification when certain criteria aren't met). However, CAM includes the request CDB bytes when such occurs, and the bytes I sent with my CDB did not match in any way shape or form what CAM was insisting I had sent. I was doing my testing using "camcontrol cmd", since I didn't want to write a bunch of code if I could at least confirm behaviour with cmd. I was making the assumption that if I gave cmd a 512-byte CDB but only provided, say, 15 or 16 of the initial bytes, that the kernel or CAM layer would zero out the rest of the 512-byte CDB. I asked mav@ and he wasn't sure if this was the case. I've included the Email between him and I below (I hope he doesn't mind). I did not have time to try providing all 512 bytes, but I did remove my erroneous "ff ff" bytes (set to "00 00" instead) and it made no difference. The code I wrote for viewing the ATA Security Feature Set bits works fine (wasn't hard to implement). I based my code on what Linux hdparm had. I can put that patch up on the web, but be aware it's more of a "hack" because /usr/include/sys/ata.h needs certain bits added to it, which I just defined in camcontrol.c for the time being. There's also user interface pieces which are half-written which I need to remove. I wouldn't want people patching their camcontrol for this functionality with a half-ass patch is what I'm saying. :-) icarus# ~jdc/work/camcontrol/camcontrol identify ada0 {...} Feature Support Enabled Value Vendor read ahead yes yes write cache yes yes flush cache yes yes overlap no Tagged Command Queuing (TCQ) no no Native Command Queuing (NCQ) yes 32 tags SMART yes yes microcode download yes yes Security Mode feature set yes no power management yes yes advanced power management no no automatic acoustic management no no media status notification no no power-up in Standby no no write-read-verify no no unload yes yes free-fall no no data set management (TRIM) yes ATA Security Features Status/Value master password revision 0xfffe locked no frozen no password attempt exceeded no enhanced erase support yes security level high erase unit time 2 minutes enhanced erase unit time 2 minutes -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | Date: Fri, 29 Jul 2011 12:36:21 +0300 From: Alexander Motin To: Jeremy Chadwick Subject: Re: Question about "camcontrol cmd" and ATA CDBs Jeremy Chadwick wrote: > Alexander, > > I've been working on implementing the ATA Security Feature set commands > to camcontrol so folks can accomplish Secure Erase for their SSDs. To > test things, I've been using "camcontrol cmd" to issue ATA CDBs to the > drive along with data/payload, while also following the Linux hdparm > source code (what a mess!). > > However, my drive is continually returning ABRT when issuing command > 0xf1 (SECURITY_SET_PASSWORD) to set the user password. > > The ATA specification states this can happen if the Security feature set > is in LOCKED or FROZEN mode, but that doesn't appear to be true. I've > modified camcontrol to show the state of the Security set features > (IDENTIFY word 128 and friends), so you'll see some extra output below > that isn't in normal camcontrol. > > # ~jdc/work/camcontrol/camcontrol identify ada4 > pass4: ATA-8 SATA 2.x device > pass4: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > protocol ATA/ATAPI-8 SATA 2.x > device model INTEL SSDSA2CW080G3 > firmware revision 4PC10302 > serial number CVPR112001WZ080BGN > WWN 500151795950e88f > cylinders 16383 > heads 16 > sectors/track 63 > sector size logical 512, physical 512, offset 0 > LBA supported 156301488 sectors > LBA48 supported 156301488 sectors > PIO supported PIO4 > DMA supported WDMA2 UDMA6 > media RPM non-rotating > > Feature Support Enabled Value Vendor > read ahead yes yes > write cache yes yes > flush cache yes yes > overlap no > Tagged Command Queuing (TCQ) no no > Native Command Queuing (NCQ) yes 32 tags > SMART yes yes > microcode download yes yes > Security Mode feature set yes no > power management yes yes > advanced power management no no > automatic acoustic management no no > media status notification no no > power-up in Standby no no > write-read-verify no no > unload yes yes > free-fall no no > data set management (TRIM) yes > > ATA Security Features Status/Value > master password revision 0xfffe > locked no > frozen no > password attempt exceeded no > enhanced erase support yes > security level high > erase unit time 2 minutes > enhanced erase unit time 2 minutes > > The extra output here comes from bits per master_passwd_revision, > security_status, erase_time, and enhanced_erase_time fields of > ata_params (include/sys/ata.h). > > Here's the camcontrol CDB I'm submitting: > > camcontrol cmd ada4 -v -r - \ > -a "f1 00 00 00 00 00 00 00 00 00 00 00" \ > -o 512 "00 00 45 69 6e 73 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff" > > The CDB should be: > > command = 0xf1 > feature = unused > count = unused > lba = unused > device = the usual :-) > > The payload should be: > > byte 0 = 0x00 = bits 7-1 = n/a > bit 0 = set USER password identifier > byte 1 = 0x00 = bits 15-9 = n/a > bit 8 = master pass capability HIGH > byte 2-33 = 0x45696e73... = password string ("Eins" in ASCII) > byte 34 = 0xff = low byte of master password revision + 1 > byte 35 = 0xff = high byte of master password revision + 1 Valid from 0001 to fffe. But only in byte 36-511 = I assume CAM zeros these out, so they should be 0x00 ? I haven't experimented. You may try to use 512bytes file. > What I get back: > > camcontrol: error sending command > (pass4:ahcich4:0:0:0): NOP. ACB: 00 00 c0 a0 00 00 00 00 00 58 c0 a0 > (pass4:ahcich4:0:0:0): CAM status: ATA Status Error > (pass4:ahcich4:0:0:0): ATA status: 51 (DRDY SERV ERR), error: 04 (ABRT ) > (pass4:ahcich4:0:0:0): RES: 51 04 c0 a0 00 00 00 00 00 c0 a0 Something is wrong there. You should see your command after "ACB:". > I assume I'm doing something wrong but I've been scratching my head for > a couple hours now trying to figure out the issue. Byte ordering? I'm > not sure. cam_cdbparse() does not do a very good job explaining the > exact ATA CDB byte order. I've power-cycled the device as well to no > avail. CDB byte order described in camcontrol(8). Data block transferred as-is. > Also, the NOP seems to be because src/sys/dev/ata/ata-queue.c lacks > relevant case statements for the Security Feature set commands. I can > submit a simple PR/patch for improving those. To the hell ata-queue.c :) cam/ata/ata_all.c seems has them. -- Alexander Motin