Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Tarkan" == Tarkan Erimer <tarkan.erimer@turknet.net.tr> writes:

Tarkan> Hi, I just tried to plug a "Western Digital, My Book Series" USB
Tarkan> disk on 2.6.31-rc1. But, it failed to recognize it by saying
Tarkan> "READ CAPACITY failed". The same disk works fine with =<
Tarkan> 2.6.30.

Can you please mail us the output of...

# sg_inq /dev/sdb
# sg_readcap /dev/sdb
# sg_readcap -l /dev/sdb

... for that WD drive?

You may have to install the sg3_utils package.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

[-- Attachment #1: Type: text/plain, Size: 1580 bytes --]

On 06/29/2009 06:21 AM, Martin K. Petersen wrote:
> Can you please mail us the output of...
>
> # sg_inq /dev/sdb
> # sg_readcap /dev/sdb
> # sg_readcap -l /dev/sdb
>
> ... for that WD drive?
>
> You may have to install the sg3_utils package.
>
>    

Here are the outputs of sg_* commands. But, I faced a strange behavior 
when I was trying these sg_* commands. Initially, it didn't recognize my 
usb WD disk as I mentioned in my BUG report. Then, after 8 mins, it 
recognized (you can see it on attached "usb.log" file.) it! so, I was 
able to get the outputs of sg_* commands ( Because; when it didn't 
recognize it, there was no "sdb" file under /dev ) and now it works fine!

root@tarkane:~# sg_inq /dev/sdb
standard INQUIRY:
   PQual=0  Device_type=0  RMB=0  version=0x00  [no conformance claimed]
   [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=0
   SCCS=0  ACC=0  TGPS=0  3PC=0  Protect=0  BQue=0
   EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
   [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=0
   [SPI: Clocking=0x0  QAS=0  IUS=0]
     length=74 (0x4a)   Peripheral device type: disk
  Vendor identification: WD
  Product identification: 2500JB External
  Product revision level: 0108

root@tarkane:~# sg_readcap /dev/sdb
Read Capacity results:
    Last logical block address=488397167 (0x1d1c596f), Number of 
blocks=488397168
    Logical block length=512 bytes
Hence:
    Device size: 250059350016 bytes, 238475.2 MiB, 250.06 GB


root@tarkane:~# sg_readcap -l /dev/sdb
READ CAPACITY (16) failed [res=-1], try with '-v'


Tarkan


[-- Attachment #2: usb.log --]
[-- Type: text/plain, Size: 3935 bytes --]

Jun 29 10:18:07 tarkane kernel: [160812.883025] usb 5-8: new high speed USB device using ehci_hcd and address 7                                                                                                           
Jun 29 10:18:07 tarkane kernel: [160813.005316] usb 5-8: configuration #1 chosen from 1 choice               
Jun 29 10:18:07 tarkane kernel: [160813.005704] scsi7 : SCSI emulation for USB Mass Storage devices          
Jun 29 10:18:12 tarkane kernel: [160818.046665] scsi 7:0:0:0: Direct-Access     WD       2500JB External  0108 PQ: 0 ANSI: 0                                                                                              
Jun 29 10:18:12 tarkane kernel: [160818.049086] sd 7:0:0:0: Attached scsi generic sg2 type 0                 
Jun 29 10:18:12 tarkane kernel: [160818.050136] sd 7:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/232 GiB)                                                                                                     
Jun 29 10:18:43 tarkane kernel: [160848.805027] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:19:14 tarkane kernel: [160879.805023] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:19:45 tarkane kernel: [160910.805027] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:20:16 tarkane kernel: [160941.805024] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:20:47 tarkane kernel: [160972.809028] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:21:18 tarkane kernel: [161003.809029] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:21:49 tarkane kernel: [161034.809024] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:22:20 tarkane kernel: [161065.810022] usb 5-8: reset high speed USB device using ehci_hcd and address 7                                                                                                         
Jun 29 10:22:20 tarkane kernel: [161065.932591] sd 7:0:0:0: [sdb] Write Protect is off                       
Jun 29 10:22:51 tarkane kernel: [161096.808032] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:23:22 tarkane kernel: [161127.809025] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:23:53 tarkane kernel: [161158.808037] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:24:24 tarkane kernel: [161189.809025] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:24:55 tarkane kernel: [161220.809056] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:25:26 tarkane kernel: [161251.809043] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:25:57 tarkane kernel: [161282.809033] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:26:28 tarkane kernel: [161313.809025] usb 5-8: reset high speed USB device using ehci_hcd and address 7
Jun 29 10:26:28 tarkane kernel: [161313.930904]  sdb: sdb1
Jun 29 10:26:59 tarkane kernel: [161344.809026] usb 5-8: reset high speed USB device using ehci_hcd and address 7

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Tarkan" == Tarkan Erimer <tarkan.erimer@turknet.net.tr> writes:

Tarkan> version=0x00 [no conformance claimed]

Wow, that's super lame.  And somewhat odd because WDC are usually pretty
good at USB-SATA bridge protocol compliance.  But in any case this is
unrelated to your problems.

My concern was that our recent changes to the capacity detection in SCSI
failed for your device.  However, given your attached log it looks like
it's a USB issue.  And rereading your original log it also looks like
you had a USB timeout which coincided with READ CAPACITY failing.

So I'm deferring to the USB folks.

Tarkan> [160848.805027] usb 5-8: reset high speed USB device using
Tarkan> ehci_hcd and address 7

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 06/29/2009 05:30 PM, Martin K. Petersen wrote:
>>>>>> "Tarkan" == Tarkan Erimer<tarkan.erimer@turknet.net.tr>  writes:
>>>>>>              
> Tarkan>  version=0x00 [no conformance claimed]
>
> Wow, that's super lame.  And somewhat odd because WDC are usually pretty
> good at USB-SATA bridge protocol compliance.  But in any case this is
> unrelated to your problems.
>
> My concern was that our recent changes to the capacity detection in SCSI
> failed for your device.  However, given your attached log it looks like
> it's a USB issue.  And rereading your original log it also looks like
> you had a USB timeout which coincided with READ CAPACITY failing.
>
> So I'm deferring to the USB folks.
>
> Tarkan>  [160848.805027] usb 5-8: reset high speed USB device using
> Tarkan>  ehci_hcd and address 7
>
>    

Hi again,

Any update for this issue ? This bug still exist in Linux-2.6.31-rc3.
Thanks,

Tarkan

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Tarkan" == Tarkan Erimer <tarkan.erimer@turknet.net.tr> writes:

Tarkan> Any update for this issue ? This bug still exist in
Tarkan> Linux-2.6.31-rc3.  Thanks,

I suggest you report the bug on linux-usb@vger.kernel.org.  Hopefully
they'll be able to help.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 07/20/2009 05:25 AM, Martin K. Petersen wrote:
> Tarkan>  Any update for this issue ? This bug still exist in
> Tarkan>  Linux-2.6.31-rc3.  Thanks,
>
> I suggest you report the bug on linux-usb@vger.kernel.org.  Hopefully
> they'll be able to help.
>
>    

OK. Thanks for the reply. I will forward the bug report to linux-usb 
people.

[BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 06/29/2009 05:30 PM, Martin K. Petersen wrote:
> Tarkan>  version=0x00 [no conformance claimed]
>
> Wow, that's super lame.  And somewhat odd because WDC are usually pretty
> good at USB-SATA bridge protocol compliance.  But in any case this is
> unrelated to your problems.
>
> My concern was that our recent changes to the capacity detection in SCSI
> failed for your device.  However, given your attached log it looks like
> it's a USB issue.  And rereading your original log it also looks like
> you had a USB timeout which coincided with READ CAPACITY failing.
>
> So I'm deferring to the USB folks.
>
> Tarkan>  [160848.805027] usb 5-8: reset high speed USB device using
> Tarkan>  ehci_hcd and address 7
>
>    

Martin,

Today, I had time to bisect and you were right: The below commit related 
to capacity detection changes in SCSI subsystem,as you mentioned, seems 
the cause of the problem.

3821d768912a47ddbd6cab52943a8284df88003c is first bad commit
commit 3821d768912a47ddbd6cab52943a8284df88003c
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Sat May 23 11:43:38 2009 -0400

     sd: Detect non-rotational devices

     Detect non-rotational devices and set the queue flag accordingly.

     Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
     Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>

:040000 040000 f744f08d73f56e6d8461267c8c5bc4c710d4c9dd 
89eb1f56a7066a22a9ae6b7b916453a78a9dd082 M      drivers

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 07/24/2009 01:55 PM, Tarkan Erimer wrote:
>
> Martin,
>
> Today, I had time to bisect and you were right: The below commit 
> related to capacity detection changes in SCSI subsystem,as you 
> mentioned, seems the cause of the problem.
>

Sorry, I was confused when replying. The introduced bug is not because 
of the "Capacity Detection Changes In SCSI Subsystem." commit; because 
of "sd: Detect non-rotational devices" commit. It seems I need more 
coffee ;-)
One more time sorry for my stupidity :-)


> 3821d768912a47ddbd6cab52943a8284df88003c is first bad commit
> commit 3821d768912a47ddbd6cab52943a8284df88003c
> Author: Martin K. Petersen <martin.petersen@oracle.com>
> Date:   Sat May 23 11:43:38 2009 -0400
>
>     sd: Detect non-rotational devices
>
>     Detect non-rotational devices and set the queue flag accordingly.
>
>     Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
>     Signed-off-by: James Bottomley 
> <James.Bottomley@HansenPartnership.com>
>
> :040000 040000 f744f08d73f56e6d8461267c8c5bc4c710d4c9dd 
> 89eb1f56a7066a22a9ae6b7b916453a78a9dd082 M      drivers
>
>

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Tarkan" == Tarkan Erimer <tarkan.erimer@turknet.net.tr> writes:

Tarkan> Today, I had time to bisect and you were right: The below commit
Tarkan> related to capacity detection changes in SCSI subsystem,as you
Tarkan> mentioned, seems the cause of the problem.

Thanks for bisecting this.


Tarkan>     Detect non-rotational devices and set the queue flag
Tarkan>     accordingly.

Aha, so you're getting USB resets because your USB-ATA bridge gets
confused when we ask it a simple question.  What a marvel of modern
engineering that thing is...

Please send me the output of:

sg_inq -e /dev/foo
sg_inq -l 16 /dev/foo
sg_inq -l 16 -e /dev/foo
sg_inq -l 36 /dev/foo
sg_inq -l 36 -e /dev/foo
sg_vpd -p sv /dev/foo
sg_vpd -p bl /dev/foo
sg_vpd -p bdc /dev/foo

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 07/24/2009 05:02 PM, Martin K. Petersen wrote:
> Tarkan>  Today, I had time to bisect and you were right: The below commit
> Tarkan>  related to capacity detection changes in SCSI subsystem,as you
> Tarkan>  mentioned, seems the cause of the problem.
>
> Thanks for bisecting this.
>
>    
You're welcome ;-)
> Tarkan>      Detect non-rotational devices and set the queue flag
> Tarkan>      accordingly.
>
> Aha, so you're getting USB resets because your USB-ATA bridge gets
> confused when we ask it a simple question.  What a marvel of modern
> engineering that thing is...
>
> Please send me the output of:
>
> sg_inq -e /dev/foo
> sg_inq -l 16 /dev/foo
> sg_inq -l 16 -e /dev/foo
> sg_inq -l 36 /dev/foo
> sg_inq -l 36 -e /dev/foo
> sg_vpd -p sv /dev/foo
> sg_vpd -p bl /dev/foo
> sg_vpd -p bdc /dev/foo
>
>    

Here are the results of the commands you asked :

root@tarkane:~# sg_inq -e /dev/sdb
VPD INQUIRY: extended INQUIRY data page

inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

     inquiry: failed, res=-1


root@tarkane:~# sg_inq -l 16 /dev/sdb
standard INQUIRY:
   PQual=0  Device_type=0  RMB=0  version=0x00  [no conformance claimed]
   [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=0
   SCCS=0  ACC=0  TGPS=0  3PC=0  Protect=0  BQue=0
   EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
   [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=0
     length=74 (0x4a), but only fetched 16 bytes   Peripheral device 
type: disk
  Vendor identification: WD
  Product identification: <none>
  Product revision level: <none>


root@tarkane:~# sg_inq -l 16 -e /dev/sdb
VPD INQUIRY: extended INQUIRY data page
inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

     inquiry: failed, res=-1


root@tarkane:~# sg_inq -l 36 /dev/sdb
standard INQUIRY:
   PQual=0  Device_type=0  RMB=0  version=0x00  [no conformance claimed]
   [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=0
   SCCS=0  ACC=0  TGPS=0  3PC=0  Protect=0  BQue=0
   EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
   [RelAdr=0]  WBus16=0  Sync=0  Linked=0  [TranDis=0]  CmdQue=0
    length=74 (0x4a), but only fetched 36 bytes   Peripheral device 
type: disk
  Vendor identification: WD
  Product identification: 2500JB External
  Product revision level: 0108


root@tarkane:~# sg_inq -l 36 -e /dev/sdb
VPD INQUIRY: extended INQUIRY data page
inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

     inquiry: failed, res=-1


root@tarkane:~# sg_vpd -p sv /dev/sdb
Supported VPD pages VPD page:
inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

fetching VPD page failed


root@tarkane:~# sg_vpd -p bl /dev/sdb
inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

VPD page=0xb0
fetching VPD page failed


root@tarkane:~# sg_vpd -p bdc /dev/sdb
abbreviation doesn't match a VPD page
available VPD pages:
   ai         0x89      ATA information (SAT)
   aod        0x82      ASCII implemented operating definition (obs)
   bl         0xb0      Block limits (SBC)
   di         0x83      Device identification
   di_asis    0x83      Like 'di' but designators ordered as found
   di_lu      0x83      Device identification, lu only
   di_port    0x83      Device identification, target port only
   di_target  0x83      Device identification, target device only
   ei         0x86      Extended inquiry data
   iod        0x81      Implemented operating definition (obs)
   mas        0xb1      Manufacturer assigned serial number (SSC)
   mna        0x85      Management network addresses
   mpp        0x87      Mode page policy
   oi         0xb0      OSD information
   sad        0xb0      Sequential access device capabilities (SSC)
   sii        0x84      Software interface identification
   sn         0x80      Unit serial number
   sp         0x88      SCSI ports
   st         0xb1      Security token (OSD)
   sv         0x00      Supported VPD pages
   tas        0xb2      TapeAlert supported flags (SSC)

Vendor specific VPD pages:
   datc       0xc1,0      Date code (Seagate)
   devb       0xc3,0      Device behavior (Seagate)
   firm       0xc0,0      Firmware numbers (Seagate)
   jump       0xc2,0      Jump setting (Seagate)
   sver       0xc2,1      Software version (RDAC)
   upr        0xc0,1      Unit path report (EMC)
   vac        0xc9,0      Volume access control (RDAC)

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Tarkan" == Tarkan Erimer <tarkan.erimer@turknet.net.tr> writes:

Tarkan> root@tarkane:~# sg_inq -e /dev/sdb
Tarkan> VPD INQUIRY: extended INQUIRY data page
Tarkan> inquiry: transport: Host_status=0x05 [DID_ABORT]
Tarkan> Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]
Tarkan>     inquiry: failed, res=-1

*sigh*


sd: Avoid sending extended inquiry to legacy/broken devices

Our existing check for VPD page validity does not handle devices that
refuse to respond to INQUIRY with the EVPD bit set.

Restrict extended inquiry to devices reporting SBC2/SPC3 or higher.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>

---

diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
index 5616cd7..9b703fd 100644
--- a/drivers/scsi/sd.c
+++ b/drivers/scsi/sd.c
@@ -1840,6 +1840,13 @@ static void sd_read_block_characteristics(struct scsi_disk *sdkp)
 	kfree(buffer);
 }
 
+static int sd_try_extended_inquiry(struct scsi_device *sdp)
+{
+	if (sdp->scsi_level > SCSI_SPC_2)
+		return 1;
+	return 0;
+}
+
 /**
  *	sd_revalidate_disk - called the first time a new disk is seen,
  *	performs disk spin up, read_capacity, etc.
@@ -1877,8 +1884,12 @@ static int sd_revalidate_disk(struct gendisk *disk)
 	 */
 	if (sdkp->media_present) {
 		sd_read_capacity(sdkp, buffer);
-		sd_read_block_limits(sdkp);
-		sd_read_block_characteristics(sdkp);
+
+		if (sd_try_extended_inquiry(sdp)) {
+			sd_read_block_limits(sdkp);
+			sd_read_block_characteristics(sdkp);
+		}
+
 		sd_read_write_protect_flag(sdkp, buffer);
 		sd_read_cache_type(sdkp, buffer);
 		sd_read_app_tag_own(sdkp, buffer);

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Matthew Wilcox]

On Sun, Jul 26, 2009 at 09:28:15PM -0400, Martin K. Petersen wrote:
> sd: Avoid sending extended inquiry to legacy/broken devices
> 
> Our existing check for VPD page validity does not handle devices that
> refuse to respond to INQUIRY with the EVPD bit set.

But ... why doesn't it?

we do:

        result = scsi_execute_req(sdev, cmd, DMA_FROM_DEVICE, buffer,
                                  len + 4, NULL, 30 * HZ, 3, NULL);
        if (result)
                return result;

so that should return some error code.  And that's called from here:

        /* Ask for all the pages supported by this device */
        result = scsi_vpd_inquiry(sdev, buf, 0, 255);
        if (result)
                goto fail;

which goes to:

 fail:
        kfree(buf);
        return NULL;

and the sd code seems to check for that.  So what bug are you papering
over here?

> Restrict extended inquiry to devices reporting SBC2/SPC3 or higher.
> 
> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
> 
> ---
> 
> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c
> index 5616cd7..9b703fd 100644
> --- a/drivers/scsi/sd.c
> +++ b/drivers/scsi/sd.c
> @@ -1840,6 +1840,13 @@ static void sd_read_block_characteristics(struct scsi_disk *sdkp)
>  	kfree(buffer);
>  }
>  
> +static int sd_try_extended_inquiry(struct scsi_device *sdp)
> +{
> +	if (sdp->scsi_level > SCSI_SPC_2)
> +		return 1;
> +	return 0;
> +}
> +
>  /**
>   *	sd_revalidate_disk - called the first time a new disk is seen,
>   *	performs disk spin up, read_capacity, etc.
> @@ -1877,8 +1884,12 @@ static int sd_revalidate_disk(struct gendisk *disk)
>  	 */
>  	if (sdkp->media_present) {
>  		sd_read_capacity(sdkp, buffer);
> -		sd_read_block_limits(sdkp);
> -		sd_read_block_characteristics(sdkp);
> +
> +		if (sd_try_extended_inquiry(sdp)) {
> +			sd_read_block_limits(sdkp);
> +			sd_read_block_characteristics(sdkp);
> +		}
> +
>  		sd_read_write_protect_flag(sdkp, buffer);
>  		sd_read_cache_type(sdkp, buffer);
>  		sd_read_app_tag_own(sdkp, buffer);
> --
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Matthew" == Matthew Wilcox <matthew@wil.cx> writes:

First let's see if I actually interpreted the responses correctly and
that this fixes the issue.

Matthew> and the sd code seems to check for that.  So what bug are you
Matthew> papering over here?

The USB drive in question appears to go tits up when we send it an
extended inquiry.  I contemplated adding a BLIST option but we really
only need EVPD to access pages 0xB0 and 0xB1.  The Block Limits page
appeared in SBC2 so I'm just trying to play it safe.  And hopefully fix
Tarkan's problem in the process.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Tarkan Erimer]

On 07/27/2009 04:28 AM, Martin K. Petersen wrote:
>>>>>> "Tarkan" == Tarkan Erimer<tarkan.erimer@turknet.net.tr>  writes:
>>>>>>              
> Tarkan>  root@tarkane:~# sg_inq -e /dev/sdb
> Tarkan>  VPD INQUIRY: extended INQUIRY data page
> Tarkan>  inquiry: transport: Host_status=0x05 [DID_ABORT]
> Tarkan>  Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]
> Tarkan>      inquiry: failed, res=-1
>
> *sigh*
>
>
> sd: Avoid sending extended inquiry to legacy/broken devices
>
> Our existing check for VPD page validity does not handle devices that
> refuse to respond to INQUIRY with the EVPD bit set.
>
> Restrict extended inquiry to devices reporting SBC2/SPC3 or higher.
>
> Signed-off-by: Martin K. Petersen<martin.petersen@oracle.com>
>
>    

Martin,

Happily, I confirm that your patch worked flawlessly with -rc4! Thanks a 
lot for your help :-)

Cheers!

Tarkan

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Boaz Harrosh]

On 07/27/2009 05:43 AM, Martin K. Petersen wrote:
>>>>>> "Matthew" == Matthew Wilcox <matthew@wil.cx> writes:
> 
> First let's see if I actually interpreted the responses correctly and
> that this fixes the issue.
> 
> Matthew> and the sd code seems to check for that.  So what bug are you
> Matthew> papering over here?
> 
> The USB drive in question appears to go tits up when we send it an
> extended inquiry.  I contemplated adding a BLIST option but we really
> only need EVPD to access pages 0xB0 and 0xB1.  

I don't understand. The device in question breaks when we try to read
a page that it reported it supports? we did do
        /* Ask for all the pages supported by this device */
        result = scsi_vpd_inquiry(sdev, buf, 0, 255);
        if (result)
                goto fail;
Didn't we? Are we checking that 0xB0 or 0xB1 are returned?

The Block Limits page
> appeared in SBC2 so I'm just trying to play it safe.  And hopefully fix
> Tarkan's problem in the process.
> 

Thanks
Boaz

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:

Boaz> I don't understand. The device in question breaks when we try to
Boaz> read a page that it reported it supports?

No.  The USB-ATA bridge in question locks up when we send it an INQUIRY
with EVPD=1.  I.e. when we try to get a list of pages. 0xB0 and 0xB1 are
not even in play here.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Matthew Wilcox]

On Mon, Jul 27, 2009 at 10:29:21AM -0400, Martin K. Petersen wrote:
> >>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:
> 
> Boaz> I don't understand. The device in question breaks when we try to
> Boaz> read a page that it reported it supports?
> 
> No.  The USB-ATA bridge in question locks up when we send it an INQUIRY
> with EVPD=1.  I.e. when we try to get a list of pages. 0xB0 and 0xB1 are
> not even in play here.

Tarkan didn't say it locked up.  He said it returned:

root@tarkane:~# sg_inq -e /dev/sdb
VPD INQUIRY: extended INQUIRY data page

inquiry: transport: Host_status=0x05 [DID_ABORT]
Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

    inquiry: failed, res=-1

I don't understand how we go any further at this point.

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Boaz Harrosh]

On 07/27/2009 05:29 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:
> 
> Boaz> I don't understand. The device in question breaks when we try to
> Boaz> read a page that it reported it supports?
> 
> No.  The USB-ATA bridge in question locks up when we send it an INQUIRY
> with EVPD=1.  I.e. when we try to get a list of pages. 0xB0 and 0xB1 are
> not even in play here.
> 

Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must be supported
but you are saying it's only SBC2/SPC3. So I guess there is nothing else we can do.

What I hate about all this is that in USB the scsi_level is hard coded at the driver,
without actually been able to probe the device about it. So my 1 TeraByte new seagate
external disk must behave like the above junk.
(Thank god for eSATA)

Boaz

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Matthew" == Matthew Wilcox <matthew@wil.cx> writes:

Matthew> Tarkan didn't say it locked up.  He said it returned:

Matthew> root@tarkane:~# sg_inq -e /dev/sdb VPD INQUIRY: extended
Matthew> INQUIRY data page

Matthew> inquiry: transport: Host_status=0x05 [DID_ABORT]
Matthew> Driver_status=0x00 [DRIVER_OK, SUGGEST_OK]

Matthew>     inquiry: failed, res=-1

Look further back in the original thread.  Sending the extended inquiry
causes a USB reset.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:

Boaz> Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must
Boaz> be supported but you are saying it's only SBC2/SPC3. So I guess
Boaz> there is nothing else we can do.

Yes, EVPD must be supported.  USB-ATA bridge firmware writers are
dyslexic.  Film at 11.

What I'm saying is that *our* reason for sending out extended inquiry
appeared in SBC2 (block limits VPD).  So there is no point in asking
devices older than that.

The fact that this fixes the problem for Tarkan's crappy disk is a
(quasi-intentional) side effect.  My patch simply tries to be
conservative about asking for those pages.


Boaz> What I hate about all this is that in USB the scsi_level is hard
Boaz> coded at the driver, without actually been able to probe the
Boaz> device about it.

Huh, what?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Boaz Harrosh]

On 07/27/2009 06:19 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:
> 
> Boaz> Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must
> Boaz> be supported but you are saying it's only SBC2/SPC3. So I guess
> Boaz> there is nothing else we can do.
> 
> Yes, EVPD must be supported.  USB-ATA bridge firmware writers are
> dyslexic.  Film at 11.
> 
> What I'm saying is that *our* reason for sending out extended inquiry
> appeared in SBC2 (block limits VPD).  So there is no point in asking
> devices older than that.
> 
> The fact that this fixes the problem for Tarkan's crappy disk is a
> (quasi-intentional) side effect.  My patch simply tries to be
> conservative about asking for those pages.
> 
> 
> Boaz> What I hate about all this is that in USB the scsi_level is hard
> Boaz> coded at the driver, without actually been able to probe the
> Boaz> device about it.
> 
> Huh, what?
> 

Look in drivers/usb/storage::slave_configure

		/* Some devices report a SCSI revision level above 2 but are
		 * unable to handle the REPORT LUNS command (for which
		 * support is mandatory at level 3).  Since we already have
		 * a Get-Max-LUN request, we won't lose much by setting the
		 * revision level down to 2.  The only devices that would be
		 * affected are those with sparse LUNs. */
		if (sdev->scsi_level > SCSI_2)
			sdev->sdev_target->scsi_level =
					sdev->scsi_level = SCSI_2;

So the scsi_level is hard coded to very low.
Or am I reading this code wrong and it is only triggered for some but not
all devices?

Boaz

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Boaz Harrosh]

On 07/27/2009 06:40 PM, Boaz Harrosh wrote:
> On 07/27/2009 06:19 PM, Martin K. Petersen wrote:
>>>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:
>> Boaz> Haa, OK. I thought INQUIRY EVPD=1 page=0 was so old it sure must
>> Boaz> be supported but you are saying it's only SBC2/SPC3. So I guess
>> Boaz> there is nothing else we can do.
>>
>> Yes, EVPD must be supported.  USB-ATA bridge firmware writers are
>> dyslexic.  Film at 11.
>>
>> What I'm saying is that *our* reason for sending out extended inquiry
>> appeared in SBC2 (block limits VPD).  So there is no point in asking
>> devices older than that.
>>
>> The fact that this fixes the problem for Tarkan's crappy disk is a
>> (quasi-intentional) side effect.  My patch simply tries to be
>> conservative about asking for those pages.
>>
>>
>> Boaz> What I hate about all this is that in USB the scsi_level is hard
>> Boaz> coded at the driver, without actually been able to probe the
>> Boaz> device about it.
>>
>> Huh, what?
>>
> 
> Look in drivers/usb/storage::slave_configure
> 
> 		/* Some devices report a SCSI revision level above 2 but are
> 		 * unable to handle the REPORT LUNS command (for which
> 		 * support is mandatory at level 3).  Since we already have
> 		 * a Get-Max-LUN request, we won't lose much by setting the
> 		 * revision level down to 2.  The only devices that would be
> 		 * affected are those with sparse LUNs. */
> 		if (sdev->scsi_level > SCSI_2)
> 			sdev->sdev_target->scsi_level =
> 					sdev->scsi_level = SCSI_2;
> 
Maybe it should be:

		if (sdev->scsi_level > SCSI_2 && sdev->scsi_level < SCSI_SPC_2)
			sdev->sdev_target->scsi_level =
					sdev->scsi_level = SCSI_2;

To account for the devices the comment is talking about. Which seems to be
written at the time SCSI_3 was the highest level.

> So the scsi_level is hard coded to very low.
> Or am I reading this code wrong and it is only triggered for some but not
> all devices?
> 
> Boaz
> --

Sigh
Boaz

Re: [BISECTED] Re: [BUG] Linux-2.6.31-rc1 Fails To Recognize Some USB Disks

[Martin K. Petersen]

>>>>> "Boaz" == Boaz Harrosh <bharrosh@panasas.com> writes:

Boaz> if (sdev->scsi_level > SCSI_2)
Boaz> 	 sdev-> sdev_target->scsi_level = sdev-> scsi_level = SCSI_2;

Beautiful!

The suck of USB strikes back.

-- 
Martin K. Petersen	Oracle Linux Engineering