From owner-freebsd-current@FreeBSD.ORG Thu Aug 6 20:45:45 2009 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A7D08106564A for ; Thu, 6 Aug 2009 20:45:45 +0000 (UTC) (envelope-from mav@FreeBSD.org) Received: from cmail.optima.ua (cmail.optima.ua [195.248.191.121]) by mx1.freebsd.org (Postfix) with ESMTP id 36B2C8FC15 for ; Thu, 6 Aug 2009 20:45:44 +0000 (UTC) Received: from [212.86.226.226] (account mav@alkar.net HELO mavbook.mavhome.dp.ua) by cmail.optima.ua (CommuniGate Pro SMTP 5.2.9) with ESMTPSA id 250896687; Thu, 06 Aug 2009 23:45:41 +0300 Message-ID: <4A7B40C5.7040500@FreeBSD.org> Date: Thu, 06 Aug 2009 23:44:53 +0300 From: Alexander Motin User-Agent: Thunderbird 2.0.0.21 (X11/20090405) MIME-Version: 1.0 To: Juergen Lock References: <20090806191848.GA14171@triton.kn-bremen.de> <4A7B357C.5010203@FreeBSD.org> <20090806203501.GA16639@triton.kn-bremen.de> In-Reply-To: <20090806203501.GA16639@triton.kn-bremen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: (es)ata drives may need an explicit spinup command? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 20:45:45 -0000 Juergen Lock wrote: > On Thu, Aug 06, 2009 at 10:56:44PM +0300, Alexander Motin wrote: >> Juergen Lock wrote: >>> So I tested esata on a siis pcie card with a 750G Seagate Freeagent Pro >>> drive and it does work - until the drive falls into powersave mode >>> after being idle for a little while. :( (I had the drive on 1394 >>> before on another box where it was able to recover from this condition, >>> but not on usb or esata - and the drive's 1394 interface died a while >>> ago and also esata is faster anyway...) >>> >>> And now I came across this patch for the linux ata driver: >>> http://git.kernel.org/?p=linux/kernel/git/jgarzik/libata-dev.git;a=commitdiff;h=169439c2e35f01e7832a9b4fc8a7446980c3d593;hp=1e999736cafdffc374f22eed37b291129ef82e4e >>> >>> So my question is, could the same be done in our ata code? >>> I have a slight :) hope it would help this drive too at least as it >>> does seem to work on Linux... >> I am not sure it is related to your case, as you said your drive works >> for some time after plug. If drive spun-down automatically due to >> inactivity, it should spin-up automatically also, as OS unable to track >> that transition. 30 seconds of ATA command timeout should be sufficient >> for drive to do this. Do you have any other symptoms? > > Well the drive becomes completely `dead' for our drivers once in this > state, and when I try an atacontrol detach/attach on it at that point > its not even found anymore. (And when I powercycle it by pulling its > little wall wart for a moment it comes back.) Oh and I think I saw > something in our 1394 drivers too that does send something like a > spinup command... The problem is that we have no idea when to use this command after drive was successfully working. Could you boot with new CAM drivers and kernel verbose messages enabled? I am interested of what exactly happens on logs/console when drive dies and how it reacts on `camcontrol reset X` and `camcontrol rescan X` commands. -- Alexander Motin