SSD are connected to on-board SATA port on motherboard
Presumably to controllers provided by the Intel Tylersburg 5520 chipset.
This system was commissioned in February of 2012 and ran without issue
as a ZFS backup system on our network until about 3 weeks ago.
The system is dual PSU behind a UPS so I don't think that this is an issue.
No changes? e.g. no added hardware to increase power load.
Overloading the power supply and/or the wiring (with too many splitters)
can result in flaky problems like this.
OS will respond to ping requests after the issue and if you have an
active SSH session you will remain connected to the system until you
attempt to do something like 'ls', 'ps', etc.
I am not able to drop into DDB when the issue happens as the system is
locked up completely. Could be a failure on my part to
understand/engage in how to do this, will try if the issue happens
again (should on Wednesday AM unless setting camcontrol apm to off for
the disks somehow fixes the issue).
If the system is alive enough to respond to ping, I'd expect you
should be able to get into DDB? Can you get into DDB when the system
is working normally?
2 x Crucial M4 64 Gb SATA SSD for FreeBSD OS (zroot)
2 x Intel 320 MLC 80 Gb SATA SSD for L2ARC and swap
I ran the Crucial firmware update ISO and it did not see any firmware
updates as necessary on the SSD disks.
Does the problem happen with both the Crucial and the Intel SSDs?
If software I agree that it would not make sense that this would
suddenly pop-up after months of operation with no issues.
If something causes the software/firmware to take a different
path, new issues can appear. E.g. error handling or even timing.
Infrequently used code paths might not have been tested sufficiently.
Does the controller have firmware? Part of the BIOS I suppose.
Is there a BIOS update available? Have you considered connecting the
SSDs to a different controller?
the on-board AHCI portion of the BIOS does
not always see the disks after the event without a hard system power
reset.
That's at least one bug somewhere, probably the hardware isn't getting reset
properly. Does Supermicro know about this bug?
I have 48 Gb of Crucial memory that I will put in this system today to
replace the 24 Gb or so of Kingston memory I have in the system.
Which in addition to being different memory, should reduce swap activity.
Suggestion: move everything to conventional drives. Keep at least one
SSD connected to system, but normally unused. Now you can beat on the
SSD in a controlled manner to debug the problem. Does reading trigger
the problem? Writing? Try dd with different blocksizes, accessing
multiple SSDs at once, etc. I have to wonder if there is a timing problem,
or missing interrupt, or...
* Ditch FreeBSD for Solaris so I can keep ZFS lovin for the intended
purpose of this system
If it fails with FreeBSD but works with Solaris on the same hardware,
then it is almost certainly a problem with the device driver. (Or
at least a problem that Solaris has a workaround for.)
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hardware
To unsubscribe, send any mail to "[email protected]"
