Skip site navigation (1)Skip section navigation (2)
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>