Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 18 Oct 2016 14:50:06 +0530
From:      Kashyap Desai <kashyap.desai@broadcom.com>
To:        Sumit Saxena <sumit.saxena@broadcom.com>, freebsd-scsi@freebsd.org,  scott4long@yahoo.com, ken@freebsd.org
Cc:        Seema Kumashikar <seema1.kumashikar@broadcom.com>
Subject:   RE: MRSAS: SATA drives are getting deleted and then readded after controller reset
Message-ID:  <f27d1dcb2c36529ad9912daec85e02ae@mail.gmail.com>
In-Reply-To: 10b16ee77a11213da804bf8b0f2c58a0@mail.gmail.com
References:  <03ee30cfdb1ac86b644ff3516e0d88c0@mail.gmail.com> 2f1e12bf33bd90c4df3172294f20dc2e@mail.gmail.com 10b16ee77a11213da804bf8b0f2c58a0@mail.gmail.com

next in thread | previous in thread | raw e-mail | index | archive | help
Updated BZ -

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(&context, serial_buf->serial_num,
-					  serial_buf->length);
+				MD5Update(&context, path->device->serial_num,
+				    path->device->serial_num_len);

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


Please review and let us know if we need fix in kernel or
Any workaround to remove this check sum related code in CAM via some tunable
?


` Kashyap

> -----Original Message-----
> From: Kashyap Desai [mailto:kashyap.desai@broadcom.com]
> Sent: Wednesday, October 12, 2016 7:33 PM
> To: Sumit Saxena; 'freebsd-scsi@freebsd.org'; 'scott4long@yahoo.com';
> 'ken@freebsd.org'
> Cc: Seema Kumashikar
> Subject: RE: MRSAS: SATA drives are getting deleted and then readded after
> controller reset
>
> Hi  -
>
> 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
> ?
>
>
> ` Kashyap
>
> > -----Original Message-----
> > From: Kashyap Desai [mailto:kashyap.desai@broadcom.com]
> > Sent: Friday, September 23, 2016 8:55 AM
> > To: Sumit Saxena; 'freebsd-scsi@freebsd.org'; 'scott4long@yahoo.com';
> > 'ken@freebsd.org'
> > Cc: Seema Kumashikar
> > Subject: RE: MRSAS: SATA drives are getting deleted and then readded
> > after controller reset
> >
> > Hi -
> >
> > I have posted new BZ/defect.
> >
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212914
> >
> > ~ Kashyap
> >
> > > -----Original Message-----
> > > From: Sumit Saxena [mailto:sumit.saxena@broadcom.com]
> > > Sent: Thursday, September 22, 2016 7:54 PM
> > > To: freebsd-scsi@freebsd.org; scott4long@yahoo.com; ken@freebsd.org
> > > Cc: Kashyap Desai; Seema Kumashikar
> > > Subject: MRSAS: SATA drives are getting deleted and then readded
> > > after controller reset
> > >
> > > Ken/Scott,
> > >
> > > 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
> > > <ST500NM0011 PA09>                 at scbus5 target 0 lun 0
> > > (pass0,ada0)
> > > <AHCI SGPIO Enclosure 1.00 0001>   at scbus6 target 0 lun 0
> > > (ses0,pass1)
> > > <ATA ST9250610NS SN01>             at scbus8 target 51 lun 0
> > > (da9,pass11)----------------------------------------->this is SATA
> > > drive which is getting deleted and re-added post controller reset
> > > <SEAGATE ST9300605SS 0004>         at scbus8 target 163 lun 0
> > > (da8,pass10)
> > > <LSI Default 5.00>                 at scbus9 target 0 lun 0
> > > (da6,pass8)
> > > <LSI Default 5.00>                 at scbus9 target 1 lun 0
> > > (da2,pass4)
> > > <LSI Default 5.00>                 at scbus9 target 2 lun 0
> > > (da0,pass2)
> > > <LSI Default 5.00>                 at scbus9 target 3 lun 0
> > > (da7,pass9)
> > > <LSI Default 5.00>                 at scbus9 target 4 lun 0
> > > (da3,pass5)
> > > <LSI Default 5.00>                 at scbus9 target 5 lun 0
> > > (da1,pass3)
> > > <SEAGATE ST600MP0005 VS09>         at scbus10 target 48 lun 0
> > > (da4,pass6)
> > > <SEAGATE ST600MP0005 VS09>         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: <ATA ST9250610NS SN01> 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: <ATA ST9250610NS SN01> Fixed Direct Access SPC-4 SCSI device
> > > da9: Serial Number 9XE02AR2
> > > da9: 150.000MB/s transfers
> > > da9: 238475MB (488397168 512 byte sectors)
> > > =================================
> > >
> > > Thanks,
> > > Sumit



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?f27d1dcb2c36529ad9912daec85e02ae>