linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Douglas Gilbert <dgilbert@interlog.com>
To: Hannes Reinecke <hare@suse.de>
Cc: SCSI Mailing List <linux-scsi@vger.kernel.org>,
	James Bottomley <jbottomley@parallels.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: Kernel crash with unsupported DIF protection type
Date: Tue, 18 Sep 2012 11:30:26 +0200	[thread overview]
Message-ID: <50583F32.1010103@interlog.com> (raw)
In-Reply-To: <50583924.90708@suse.de>

On 12-09-18 11:04 AM, Hannes Reinecke wrote:
> Hi all,
>
> I recently got my hands on some weird drives, insisting on having
> been formatted with protection type 7:
>
> # sg_readcap --16 /dev/sdb
> Read Capacity results:
>     Protection: prot_en=1, p_type=6, p_i_exponent=0
>     Logical block provisioning: lbpme=0, lbprz=0
>     Last logical block address=1758174767 (0x68cb9e2f), Number of
> logical blocks=1758174768
>     Logical block length=512 bytes
>     Logical blocks per physical block exponent=0
>     Lowest aligned logical block address=0
> Hence:
>     Device size: 900185481216 bytes, 858483.8 MiB, 900.19 GB
>
> (I know. I've already complained.)
> However, this drive causes a horrible crash:
>
> sd 0:0:1:0: [sdb] formatted with unsupported protection type 7.
> Disabling disk!
> sd 0:0:1:0: [sdb] 1758174768 512-byte logical blocks: (900
> GB/838 GiB)
> sd 0:0:1:0: [sdb]  Result: hostbyte=DID_OK
> driverbyte=DRIVER_SENSE
> sd 0:0:1:0: [sdb]  Sense Key : Medium Error [current]
> sd 0:0:1:0: [sdb]  Add. Sense: Medium format corrupted
> sd 0:0:1:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
> end_request: I/O error, dev sdb, sector 0
> Buffer I/O error on device sdb, logical block 0
>
> [ tons and tons of I/O errors ]
>
> [   15.551689] sd 0:0:1:0: [sdb] Enabling DIX T10-DIF-TYPE1-CRC
> protection
> [   15.561353] ------------[ cut here ]------------
> [   15.569416] kernel BUG at
> /usr/src/linux-3.0/drivers/scsi/scsi_lib.c:1069!
>
> There are several odd things happening here:
> - It says 'Disabling disk', which _should_ have set the
>    capacity to '0':
>
> drivers/scsi/sd.c:sd_read_protection_type()
> 	if (type > SD_DIF_TYPE3_PROTECTION) {
> 		sd_printk(KERN_ERR, sdkp, "formatted with unsupported "	\
> 			  "protection type %u. Disabling disk!\n", type);
> 		sdkp->capacity = 0;
> 		return;
> 	}
>
> - it enables type 1 protection, which it evidently is not.
>
> I've attached a tentative patch, which allows the system to boot.
> However, I'm not completely happy with that, as the capacity is
> _still_ updated after revalidation:
>
> sd 0:0:1:0: [sdb] formatted with unsupported protection type 7.
> Disabling disk!
> sd 0:0:1:0: [sdb] 0 512-byte logical blocks: (0 B/0 B)
> sd 0:0:1:0: [sdb] Write Protect is off
> sd 0:0:1:0: [sdb] Mode Sense: cf 00 10 08
> sd 0:0:1:0: [sdb] Write cache: disabled, read cache: enabled,
> supports DPO and FUA
> sd 0:0:1:0: [sdb] 1758174768 512-byte logical blocks: (900 GB/838 GiB)
> sd 0:0:1:0: [sdb] Attached SCSI disk
>
> Thoughts?

The "Medium format corrupted" additional sense qualifier occurs
(with Seagate disks) when a FORMAT UNIT command is interrupted.
So maybe, for good measure, that disk also sets the DIF
protection type to an unsupported value (i.e. 7). So re-doing a
FORMAT  UNIT may clear that state.

Obviously the kernel should not crash when faced with such
a disk.

Doug Gilbert




  reply	other threads:[~2012-09-18  9:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-18  9:04 Kernel crash with unsupported DIF protection type Hannes Reinecke
2012-09-18  9:30 ` Douglas Gilbert [this message]
2012-09-18  9:35   ` Hannes Reinecke
2012-09-18 10:20     ` Douglas Gilbert
2012-09-20 19:53 ` Martin K. Petersen
2012-09-21  6:03   ` Hannes Reinecke
2012-09-21 14:16   ` Hannes Reinecke
2012-09-21 16:05     ` Martin K. Petersen
2012-09-21 16:44       ` Martin K. Petersen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50583F32.1010103@interlog.com \
    --to=dgilbert@interlog.com \
    --cc=hare@suse.de \
    --cc=jbottomley@parallels.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).