On Feb 1, 2011, at 8:54 PM, Krunal Desai wrote: > On Tue, Feb 1, 2011 at 11:34 PM, Richard Elling > <richard.ell...@gmail.com> wrote: >> There is a failure going on here. It could be a cable or it could be a bad >> disk or firmware. The actual fault might not be in the disk reporting the >> errors (!) >> It is not a media error. >> > > Errors were as follows: > Feb 01 19:33:01.3665 ereport.io.scsi.cmd.disk.recovered 0x269213b01d700401 > Feb 01 19:33:01.3665 ereport.io.scsi.cmd.disk.recovered 0x269213b01d700401 > Feb 01 19:33:01.3665 ereport.io.scsi.cmd.disk.recovered 0x269213b01d700401 > Feb 01 19:33:04.9969 ereport.io.scsi.cmd.disk.tran 0x269f99ef0b300401 > Feb 01 19:33:04.9970 ereport.io.scsi.cmd.disk.tran 0x269f9a165a400401 > > Verbose of a message: > Feb 01 2011 19:33:04.996932283 ereport.io.scsi.cmd.disk.tran > nvlist version: 0 > class = ereport.io.scsi.cmd.disk.tran > ena = 0x269f99ef0b300401 > detector = (embedded nvlist) > nvlist version: 0 > version = 0x0 > scheme = dev > device-path = /pci@0,0/pci8086,2e21@1/pci15d9,a580@0/sd@3,0 > (end detector) > > devid = id1,sd@n5000c50010ed6a31 > driver-assessment = fail > op-code = 0x0 > cdb = 0x0 0x0 0x0 0x0 0x0 0x0 > pkt-reason = 0x18
This error code means the device is gone. > pkt-state = 0x1 The command got the bus, but could not access the target. > pkt-stats = 0x0 > __ttl = 0x1 > __tod = 0x4d48a640 0x3b6bfabb > > It was a cable error, but why didn't fault management tell me about > it? What do you mean by "The actual fault might not be in the disk > reporting the errors (!) > It is not a media error."? Fault might be sourcing from my SATA > controller or something possibly? Possibly. -- richard _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
