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>