Date: Wed, 12 Oct 2016 18:10:21 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan Message-ID: <bug-212914-8-XmJrqbm2fR@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-212914-8@https.bugs.freebsd.org/bugzilla/> References: <bug-212914-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212914 --- Comment #2 from Kenneth D. Merry <ken@FreeBSD.org> --- The device may be going away for several possible reasons: 1. A CCB is returned with the status CAM_DEV_NOT_THERE or CAM_SEL_TIMEOUT. 2. A CCB is returned with the SCSI ASC/ASCQ 0x25,0x00, Logical Unit Not Supported. 3. Someone is doing an xpt_async(AC_LOST_DEVICE, ...) A device may go away and come back as a result of a rescan if any of the following changes: SCSI Standard Inquiry Data (Full inquiry data, including Vendor, Product, Revision) SCSI page 0x80 serial number The first thing I would look at here is what status is getting returned from the drive in question after a reset. If that all looks good, look at wheth= er someone is issuing a rescan, and whether the device is returning inconsiste= nt results. Those inconsistent results could be buried in the part of the Inq= uiry data that isn't displayed. Standard inquiry data is checksummed along with= the serial number and any change in the checksum will make the device go away a= nd come back. Although this is a SATA drive, obviously the only thing that matters is the SCSI response, because CAM is communicating with it as if it is a SCSI prot= ocol device. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212914-8-XmJrqbm2fR>