<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 2, 2014, at 10:02 PM, wuffers <<a href="mailto:moo@wuffers.net">moo@wuffers.net</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I'm at home just looking into the health of our SAN and came across a bunch of errors on the Stec ZeusRAM (in a mirrored log configuration):<div><br></div><div><div># iostat -En</div><div>c12t5000A72B300780FFd0 Soft Errors: 0 Hard Errors: 1 Transport Errors: 5224</div></div></div></blockquote><div><br></div><div>ZeusRAMs are more sensitive to noisy fabric or cables than some other drives.</div><div>At the OS level, one symptom is transport errors, but that is only one view of the</div><div>fabric and you'll need more than one view to reach root cause.</div><div><br></div><div>Check the drive's health using something like sg3_utils:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>sg_logs -a /dev/rdsk/c#t#d#</div><div>and look for link stats, especially loss of DWORD sync and running disparity errors.</div><div> -- richard</div><br><blockquote type="cite"><div dir="ltr"><div><div>Vendor: STEC Product: ZeusRAM Revision: C018 Serial No: STM000170C98</div><div>Size: 8.00GB <8000000000 bytes></div><div>Media Error: 0 Device Not Ready: 0 No Device: 0 Recoverable: 0</div><div>Illegal Request: 391 Predictive Failure Analysis: 0</div><div><br></div><div>#fmdump -eV<br></div><div>Dec 03 2014 00:26:22.592888816 ereport.io.scsi.cmd.disk.recovered</div><div>nvlist version: 0</div><div> class = ereport.io.scsi.cmd.disk.recovered</div><div> ena = 0xd38b237e7ed02001</div><div> detector = (embedded nvlist)</div><div> nvlist version: 0</div><div> version = 0x0</div><div> scheme = dev</div><div> device-path = /pci@0,0/pci8086,3c08@3/pci1000,3030@0/iport@f/disk@w5000a72b300780ff,0</div><div> devid = id1,sd@n5000a720300780ff</div><div> (end detector)</div><div><br></div><div> devid = id1,sd@n5000a720300780ff</div><div> driver-assessment = recovered</div><div> op-code = 0x2a</div><div> cdb = 0x2a 0x0 0x0 0x2d 0xda 0x0 0x0 0x0 0xf8 0x0</div><div> pkt-reason = 0x0</div><div> pkt-state = 0x1f</div><div> pkt-stats = 0x0</div><div> __ttl = 0x1</div><div> __tod = 0x547e9efe 0x2356c3f0</div><div><br></div><div># dmesg</div><div>Dec 3 00:28:24 san1 scsi: [ID 365881 <a href="http://kern.info/">kern.info</a>] /pci@0,0/pci8086,3c08@3/pci1000,3030@0 (mpt_sas1):</div><div>Dec 3 00:28:24 san1 Log info 0x31120303 received for target 10 w5000a72b300780ff.</div><div>Dec 3 00:28:24 san1 scsi_status=0x0, ioc_status=0x804b, scsi_state=0xc</div><div><br></div><div>from format:</div><div><br></div><div>57. c12t5000A72B300780FFd0 <STEC-ZeusRAM-C018-7.45GB></div><div> /pci@0,0/pci8086,3c08@3/pci1000,3030@0/iport@f/disk@w5000a72b300780ff,0</div></div><div><br></div><div>Both fmdump and dmesg has these errors repeating over and over. Everything seems to point to the drive. I suppose I would have to physically move the drive to eliminate cable, backplane or controller issues. Is there another way to tell just by these error logs or is the physical test the way to go? </div><div><br></div><div>Are logs enough to justify an RMA? </div></div>
_______________________________________________<br>OmniOS-discuss mailing list<br><a href="mailto:OmniOS-discuss@lists.omniti.com">OmniOS-discuss@lists.omniti.com</a><br>http://lists.omniti.com/mailman/listinfo/omnios-discuss<br></blockquote></div><br></body></html>