Date: Thu, 17 Nov 2011 11:58:19 +0100 From: Willem Jan Withagen <wjw@digiware.nl> To: Alexander Motin <mav@FreeBSD.org> Cc: FreeBSD Stable <freebsd-stable@freebsd.org> Subject: Re: Trouble with SSD on SATA Message-ID: <4EC4E8CB.1000101@digiware.nl> In-Reply-To: <4EC4152B.6020404@FreeBSD.org> References: <mailpost.1321460004.9163788.7059.mailing.freebsd.stable@FreeBSD.cs.nctu.edu.tw> <4EC4152B.6020404@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4EC4E8CB.1000101>