[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <MWHPR03MB2669C439014CD20B21ED3A69BF580@MWHPR03MB2669.namprd03.prod.outlook.com>
Date: Tue, 14 Feb 2017 14:17:52 +0000
From: Dexuan Cui <decui@...rosoft.com>
To: "hch@....de" <hch@....de>
CC: Jens Axboe <axboe@...nel.dk>,
Bart Van Assche <Bart.VanAssche@...disk.com>,
"hare@...e.com" <hare@...e.com>, "hare@...e.de" <hare@...e.de>,
"Martin K. Petersen" <martin.petersen@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"jth@...nel.org" <jth@...nel.org>,
Nick Meier <Nick.Meier@...rosoft.com>,
"Alex Ng (LIS)" <alexng@...rosoft.com>,
Long Li <longli@...rosoft.com>,
"Adrian Suhov (Cloudbase Solutions SRL)" <v-adsuho@...rosoft.com>,
"Chris Valean (Cloudbase Solutions SRL)" <v-chvale@...rosoft.com>
Subject: RE: Boot regression (was "Re: [PATCH] genhd: Do not hold event lock
when scheduling workqueue elements")
> From: hch@....de [mailto:hch@....de]
>
> Hi Dexuan,
>
> can you try the hack below for now? I disable the TUR call from
> sd_check_events, which I think your VM is hanging on. The checks
> it does on the sense data look a bit fishy, but so far I've not
> identified a possible root cause.
>
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 40b4038c019e..1502e87c2be9 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1457,9 +1457,13 @@ static unsigned int sd_check_events(struct
> gendisk *disk, unsigned int clearing)
> retval = -ENODEV;
>
> if (scsi_block_when_processing_errors(sdp)) {
> +#if 0
> sshdr = kzalloc(sizeof(*sshdr), GFP_KERNEL);
> retval = scsi_test_unit_ready(sdp, SD_TIMEOUT,
> SD_MAX_RETRIES,
> sshdr);
> +#else
> + retval = 0;
> +#endif
> }
>
> /* failed to execute TUR, assume media not present */
Unluckily, the issue is still there.
Please see the attachment for the new log.
It looks somewhere we're still sending the cmd "Test Unit Ready", which
somehow hangs.
Thanks,
-- Dexuan
Download attachment "putty.log" of type "application/octet-stream" (30844 bytes)
Powered by blists - more mailing lists