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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
