Trouble with SSD on SATA
Willem Jan Withagen
wjw at digiware.nl
Thu Nov 17 10:58:24 UTC 2011
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
More information about the freebsd-stable
mailing list