From owner-freebsd-stable@FreeBSD.ORG Thu Nov 17 10:58:24 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 564311065680; Thu, 17 Nov 2011 10:58:24 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (mail.ip6.digiware.nl [IPv6:2001:4cb8:1:106::2]) by mx1.freebsd.org (Postfix) with ESMTP id E62D68FC15; Thu, 17 Nov 2011 10:58:23 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id 50DF3153436; Thu, 17 Nov 2011 11:58:22 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+yrDGYL2B9p; Thu, 17 Nov 2011 11:58:20 +0100 (CET) Received: from [192.168.10.67] (opteron [192.168.10.67]) by mail.digiware.nl (Postfix) with ESMTP id 5DC2B153434; Thu, 17 Nov 2011 11:58:20 +0100 (CET) Message-ID: <4EC4E8CB.1000101@digiware.nl> Date: Thu, 17 Nov 2011 11:58:19 +0100 From: Willem Jan Withagen User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Alexander Motin References: <4EC4152B.6020404@FreeBSD.org> In-Reply-To: <4EC4152B.6020404@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable Subject: Re: Trouble with SSD on SATA X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Nov 2011 10:58:24 -0000 On 2011-11-16 20:55, Alexander Motin wrote: > Hi. > > On 16.11.2011 18:12, Willem Jan Withagen wrote: >> I'm getting these: >> >> Nov 16 16:40:49 zfs kernel: ata6: port is not ready (timeout 15000ms) >> tfd = 00000080 >> Nov 16 16:40:49 zfs kernel: ata6: hardware reset timeout >> Nov 16 16:41:50 zfs kernel: ata6: port is not ready (timeout 15000ms) >> tfd = 00000080 >> Nov 16 16:41:50 zfs kernel: ata6: hardware reset timeout >> >> When inserting the tray with a SSD disk connected to that controller. >> >> Which is probably due to a BIOS upgrade.... >> At least it started after upgrading the BIOS. So I'm asking SuperMicro >> for an older version. >> >> When this happens, the system sometimes panics, haven't written the >> details yet down right now. somewhere in get_devices... >> >> After the panic I really need to powerdown the machine, otherwise it >> boots but stalls at finding any disks. It does not just find no disks, >> it "freezes" at the point it should report the found disks in the >> bios-boot. >> So apparently the ata controller are left in a very confused state. >> >> Why is the controller found at boot, and works as it should. >> And why later it just starts generating these hardware resets?? > > Looking on messages, I would say that you are using AHCI controller with > old ata(4) driver. I would recommend you to try new ahci(4) driver. It > has better hot-plug support and also supports NCQ and some other > features. Note that disks connected to it will be reported as adaX > instead of adY. Hi Alexander, Thanx for pointing that out. I recompiled the kernel with ahci.. And using GPT for the most part took care of the fact that the underlying devicenames changed.... Only "problem" was swap, which I renamed from ad{6,8} to ada{6,8} but ahci also renumbers.... However on swap that is not much of a problem during booting. the root partition however is running of: zfsboot 4.16G 62.3G 0 0 0 0 mirror 4.16G 62.3G 0 0 0 0 gptid/966bdc14-0b73-11df-a9ff-003048de97cd - - 0 0 0 0 gptid/60be2c5d-4a83-11df-bf4f-003048de97cd - - 0 0 0 0 But they were not labeled as such in GPT, so that sor t of makes sense. And I've seen a lot of discussion on how to try and fix this. But I think that at the moment I will not bother. Performance wise I have the feeling that it has al lot better performance. It was scrubbing a 6,5T filesystem and read io-ops where around 100-200 with ata, but now they are more in the 600-900 range. Let's see how we fare with this setting. --WjW