[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-20 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

Kenneth D. Merry  changed:

   What|Removed |Added

   Assignee|freebsd-bugs@FreeBSD.org|asom...@freebsd.org

--- Comment #6 from Kenneth D. Merry  ---
Reassigning to Alan.  Looks like his change broke this, and it would be good
for him to  double check the patch as well.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

--- Comment #5 from Kashyap  ---
Created attachment 175903
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=175903=edit
Rescan ATA Device with valid MD5 checksum

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

Mark Linimon  changed:

   What|Removed |Added

   Keywords||patch

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-18 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

--- Comment #4 from Kashyap  ---
This issue is fixed using below patch. Please review and let me know if this is
a correct fix.  Root cause is - "Checksum is updated using different serial
number. One without removing extra spaces and another with additional spaces.
Because of that, any rescan of ATA disk is defected as different ATA drive, so
it is removed and re-added later. "


Index: scsi_xpt.c
===
--- scsi_xpt.c  (revision 307137)
+++ scsi_xpt.c  (working copy)
@@ -1600,8 +1600,8 @@
  sizeof(struct scsi_inquiry_data));

if (have_serialnum)
-   MD5Update(, serial_buf->serial_num,
- serial_buf->length);
+   MD5Update(, path->device->serial_num,
+   path->device->serial_num_len);

MD5Final(digest, );
if (bcmp(softc->digest, digest, 16) == 0)

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-14 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

--- Comment #3 from Kashyap  ---
Here is CAMDEBUG enabled logs  for SAS Drives. This is a working case -

Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug:
xpt_run_allocq(0xf80060a62e00)
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): Probe
PROBE_EXTENDED_INQUIRY to PROBE_SERIAL_NUM
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): xpt_schedule
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug:
xpt_run_allocq(0xf80060a62e00)
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): xpt_setup_ccb
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: calling periph_start()
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): probestart
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
Oct 14 18:56:06 freeBSD11_RC1 kernel: xpt_action: func 0x901 XPT_SCSI_IO
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
xpt_action_default: func 0x901 XPT_SCSI_IO
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:
Oct 14 18:56:06 freeBSD11_RC1 kernel: 73:0): xpt_action_default: func= 0x901
XPT_SCSI_IO status 0
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_release_devq(0, 0, 0, 0)
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): xpt_setup_ccb
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0): xpt_action: func
0x5 XPT_REL_SIMQ
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
Oct 14 18:56:06 freeBSD11_RC1 kernel: xpt_action_default: func 0x5 XPT_REL_SIMQ
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
xpt_release_devq(1, 1)
Oct 14 18:56:06 freeBSD11_RC1 kernel: (noperiph:mrsas0:1:73:0):
Oct 14 18:56:06 freeBSD11_RC1 kernel: xpt_release_devq_device(1, 1) 1->0
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: xpt_schedule_dev
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: Inserting onto queue
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: xpt_run_devq
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: running device
0xf8000f04d000
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
xpt_freeze_devq(1)
Oct 14 18:56:06 freeBSD11_RC1 kernel: (noperiph:mrsas0:1:73:0):
xpt_freeze_devq_device(1) 0->1
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
Oct 14 18:56:06 freeBSD11_RC1 kernel: . CDB: 12 01 80 00 ff 00
Oct 14 18:56:06 freeBSD11_RC1 kernel: (probe0:mrsas0:1:73:0):
xpt_action_default: func= 0x5 XPT_REL_SIMQ status 0x1
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug:
xpt_run_allocq(0xf8000f000900)
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: calling periph_start()
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: xpt_schedule_dev
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: Inserting onto queue
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: xpt_run_devq
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: running device
0xf8000f165800
Oct 14 18:56:06 freeBSD11_RC1 kernel: cam_debug: xpt_run_devq


See below similar logs from SATA Drives. - This is non working case -

Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): Probe
PROBE_EXTENDED_INQUIRY to PROBE_SERIAL_NUM
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_schedule
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
cam_release_devq(0, 0, 0, 0)
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_setup_ccb
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_action: func
0x5 XPT_REL_SIMQ
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
xpt_action_default: func 0x5 XPT_REL_SIMQ
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
xpt_release_devq(1, 1)
Oct 14 18:52:04 freeBSD11_RC1 kernel: (noperiph:mrsas0:1:71:0):
xpt_release_devq_device(1, 1) 2->1
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
xpt_action_default: func= 0x5 XPT_REL_SIMQ status 0x1
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_setup_ccb
Oct 14 18:52:04 freeBSD11_RC1 kernel: cam_debug: calling periph_start()
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): probestart
Oct 14 18:52:04 freeBSD11_RC1 kernel: cam_debug: (probe0:xpt_run_devq
Oct 14 18:52:04 freeBSD11_RC1 kernel: mrsas0:1:cam_debug: 71:xpt_release_ccb
Oct 14 18:52:04 freeBSD11_RC1 kernel: 0): cam_debug: xpt_action: func 0x901
XPT_SCSI_IO
Oct 14 18:52:04 freeBSD11_RC1 kernel: xpt_run_allocq(0xf8000f000900)
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
xpt_action_default: func 0x901 XPT_SCSI_IO
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
xpt_action_default: func= 0x901 XPT_SCSI_IO status 0
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0):
cam_release_devq(0, 0, 0, 0)
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_setup_ccb
Oct 14 18:52:04 freeBSD11_RC1 kernel: (probe0:mrsas0:1:71:0): xpt_action: func
0x5 XPT_REL_SIMQ
Oct 14 18:52:04 freeBSD11_RC1 kernel:

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-12 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

--- Comment #2 from Kenneth D. Merry  ---
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 whether
someone is issuing a rescan, and whether the device is returning inconsistent
results.  Those inconsistent results could be buried in the part of the Inquiry
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 and
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 protocol
device.

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-10-12 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

--- Comment #1 from Kashyap  ---

Any update/pointer  on this ?  Issue happen only with SATA driver attached via
CAM layer.

Do we need to address this in driver or will there be any fix in CAM layer ?

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"

[Bug 212914] CAM: SATA drives are getting deleted and then re-added after controller rescan

2016-09-22 Thread bugzilla-noreply 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914

Bug ID: 212914
   Summary: CAM: SATA drives are getting deleted and then re-added
after controller rescan
   Product: Base System
   Version: 11.0-RC1
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: kern
  Assignee: freebsd-bugs@FreeBSD.org
  Reporter: kashyap.de...@broadcom.com

This issue is even common for LSI/Broadcom IT HBA (mpr driver), so looks to be
a common issue. 

If you have SATA drive and just do "camcontrol rescan all", SATA disc is added
and removed back by CAM layer.


On FreeBSD11.0 RC1, we are facing an issue where SATA drives connected behind
LSI's MegaRAID controller getting deleted and added back after controller
reset.
I am using Broadcom/Avago/LSI's  MegaRAID Invader controller(device ID-
0x005d). The point to note here is- this behavior is not observed with SAS
drives on FreeBSD11.0-RC1.
Also on FreeBSD10.3 this behavior is not at all observed on SATA as well.
We are debugging the issue but it would be much helpful if we can get quick
inputs/pointers.

Please find below the detailed information-

OS: FreeBSD 11.0 RC1
Controller: LSI's MegaRAID invader controller

Connected devices list:

root@freeBSD11:~ # camcontrol devlist
 at scbus5 target 0 lun 0 (pass0,ada0)
   at scbus6 target 0 lun 0 (ses0,pass1)
 at scbus8 target 51 lun 0
(da9,pass11)->this is SATA drive which
is getting deleted and re-added post controller reset
 at scbus8 target 163 lun 0 (da8,pass10)
 at scbus9 target 0 lun 0 (da6,pass8)
 at scbus9 target 1 lun 0 (da2,pass4)
 at scbus9 target 2 lun 0 (da0,pass2)
 at scbus9 target 3 lun 0 (da7,pass9)
 at scbus9 target 4 lun 0 (da3,pass5)
 at scbus9 target 5 lun 0 (da1,pass3)
 at scbus10 target 48 lun 0 (da4,pass6)
 at scbus10 target 54 lun 0 (da5,pass7)


Relevant dmesg logs snippet(da9 is SATA drive which is getting deleted and
added back):


mrsas0: Initiaiting OCR because of FW fault!
mrsas0: Waiting for FW to come to ready state
mrsas0: Jbod map is supported
mrsas0: Reset successful
da9 at mrsas0 bus 1 scbus8 target 51 lun 0
da9:  s/n 9XE02AR2 detached
(da9:mrsas0:1:51:0): Periph destroyed
(da9:mrsas0:1:51:0): UNMAPPED
(da9:mrsas0:1:51:0): fatal error, could not acquire reference count
g_access(918): provider da9 has error
g_access(918): provider da9 has error
g_access(918): provider da9 has error
(da9:mrsas0:1:51:0): UNMAPPED
da9 at mrsas0 bus 1 scbus8 target 51 lun 0
da9:  Fixed Direct Access SPC-4 SCSI device
da9: Serial Number 9XE02AR2
da9: 150.000MB/s transfers
da9: 238475MB (488397168 512 byte sectors) =

-- 
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"