scsi error at SEAGATE ST1200MM0088 TT31
geoffroy desvernay
dgeo at centrale-marseille.fr
Thu Jan 5 13:20:41 UTC 2017
On 01/03/2017 23:19, geoffroy desvernay wrote:
> Sorry for the 'me too' style, I won't bring a response here… But it
> seems there is something to catch here, I'm just adding my case's details:
>
> These "ILLEGAL REQUEST asc:20,0" seems identical to the thread 'mpr(4)
> bug ?' (2016/12/12) this wasn't a mpr(4) bug.
>
> Same symptoms: disks seems ok, but real use fails… Now trying to
> "sg_format" them… to be continued …
>
It worked for me® :) just `sg_format --format daX` each drive to disable
'type 2 protection'
Many thanks for the workaround baris !
> Here we have 24 SEAGATE ST2000NX0433 NS02 drives in a md1420 enclosure
> connected via a sas3008 adapter. Setup tested working with debian 8 and
> centos 7.
>
> sg_readcap --16 returns:
> Read Capacity results:
> Protection: prot_en=1, p_type=1, p_i_exponent=0 [type 2 protection]
> Logical block provisioning: lbpme=0, lbprz=0
> Last logical block address=3907029167 (0xe8e088af), Number of logical
> blocks=3907029168
> Logical block length=512 bytes
> Logical blocks per physical block exponent=0
> Lowest aligned logical block address=0
> Hence:
> Device size: 2000398934016 bytes, 1907729.1 MiB, 2000.40 GB
>
> Yours,
>
> On 12/22/2016 07:39 AM, baris.cavus wrote:
>> I have found the same issue here:
>>
>> https://bugs.freenas.org/issues/14517
>>
>> `sg_readcap --16 da16` reported "type 2 protection"
>>
>> Protection: prot_en=1, p_type=1, p_i_exponent=0 [type 2 protection]
>>
>> Then we formatted all disks at night and it worked
>>
>> sg_format --format /dev/da16 -f0
>>
>>
>> Normally DPICZ bit set to 1 in control mode page states it doesn't check
>> the protection but this doesn't work.
>> I would be happy to learn if someone find any other workaround.
>>
>> Thanks,
>>
>>
>> On 21-12-2016 17:42, baris.cavus wrote:
>>> I have "1.2 TB SEAGATE ST1200MM0088 TT31" on my enclosures connected
>>> with lsa 3008 hba . I can't write to disks on Freebsd 10 but I can in
>>> centos 7. Any idea what is the reason ?.
>>>
>>> (da2:mpr0:0:10:0): CAM status: SCSI Status Error
>>> (da2:mpr0:0:10:0): SCSI status: Check Condition
>>> (da2:mpr0:0:10:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid
>>> command operation code)
>>> (da2:mpr0:0:10:0): Error 22, Unretryable error
>>> (da2:mpr0:0:10:0): READ(10). CDB: 28 00 00 00 02 00 00 01 00 00
>>> (da2:mpr0:0:10:0): CAM status: SCSI Status Error
>>> (da2:mpr0:0:10:0): SCSI status: Check Condition
>>> (da2:mpr0:0:10:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid
>>> command operation code)
>>> (da2:mpr0:0:10:0): Error 22, Unretryable error
>>> (da2:mpr0:0:10:0): READ(10). CDB: 28 00 8b ba 08 00 00 01 00 00
>>> (da2:mpr0:0:10:0): CAM status: SCSI Status Error
>>> (da2:mpr0:0:10:0): SCSI status: Check Condition
>>> (da2:mpr0:0:10:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid
>>> command operation code)
>>> (da2:mpr0:0:10:0): Error 22, Unretryable error
>>> (da2:mpr0:0:10:0): READ(10). CDB: 28 00 8b ba 0a 00 00 01 00 00
>>> (da2:mpr0:0:10:0): CAM status: SCSI Status Error
>>> (da2:mpr0:0:10:0): SCSI status: Check Condition
>>> (da2:mpr0:0:10:0): SCSI sense: ILLEGAL REQUEST asc:20,0 (Invalid
>>> command operation code)
>>> (da2:mpr0:0:10:0): Error 22, Unretryable error
>>>
>>
>> _______________________________________________
>> freebsd-scsi at freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-scsi
>> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe at freebsd.org"
>
>
--
*geoffroy desvernay*
C.R.I - Administration systèmes et réseaux
Ecole Centrale de Marseille
More information about the freebsd-scsi
mailing list