Hi,
I just tried to plug a "Western Digital, My Book Series" USB disk on
2.6.31-rc1. But, it failed to recognize it by saying "READ CAPACITY
failed". The same disk works fine with =< 2.6.30. Interestingly, I tried
another USB Disk (which is noname, just USB Box with disk) and it worked
fine. Here are the logs when WD-My Book has plugged in :
With 2.6.31-rc1
Jun 26 09:31:56 tarkane kernel: [ 459.016642] Initializing USB Mass
Storage driver...
Jun 26 09:31:56 tarkane kernel: [ 459.016779] scsi4 : SCSI emulation
for USB Mass Storage devices
Jun 26 09:31:56 tarkane kernel: [ 459.016895] usbcore: registered new
interface driver usb-storage
Jun 26 09:31:56 tarkane kernel: [ 459.016899] USB Mass Storage support
registered.
Jun 26 09:32:01 tarkane kernel: [ 464.051692] scsi 4:0:0:0:
Direct-Access WD 2500JB External 0108 PQ: 0 ANSI: 0
Jun 26 09:32:01 tarkane kernel: [ 464.052354] sd 4:0:0:0: Attached scsi
generic sg2 type 0
Jun 26 09:32:01 tarkane kernel: [ 464.054141] sd 4:0:0:0: [sdb]
488397168 512-byte logical blocks: (250 GB/232 GiB)
Jun 26 09:32:32 tarkane kernel: [ 494.805017] usb 5-8: reset high speed
USB device using ehci_hcd and address 4
Jun 26 09:32:36 tarkane kernel: [ 498.707778] usb 5-8: USB disconnect,
address 4
Jun 26 09:32:36 tarkane kernel: [ 498.709294] sd 4:0:0:0: [sdb] Write
Protect is off
Jun 26 09:32:36 tarkane kernel: [ 498.709445] sd 4:0:0:0: [sdb] READ
CAPACITY failed
Jun 26 09:32:36 tarkane kernel: [ 498.709448] sd 4:0:0:0: [sdb] Result:
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Jun 26 09:32:36 tarkane kernel: [ 498.709454] sd 4:0:0:0: [sdb] Sense
not available.
Jun 26 09:32:36 tarkane kernel: [ 498.709502] sdb: detected capacity
change from 250059350016 to 0
Jun 26 09:32:36 tarkane kernel: [ 498.709653] sd 4:0:0:0: [sdb] READ
CAPACITY failed
With 2.6.30
Jun 26 09:38:57 tarkane kernel: [ 315.453136] usb 5-8: new high speed
USB device using ehci_hcd and address 4
Jun 26 09:38:57 tarkane kernel: [ 315.575147] usb 5-8: configuration #1
chosen from 1 choice
Jun 26 09:38:58 tarkane kernel: [ 315.618461] Initializing USB Mass
Storage driver...
Jun 26 09:38:58 tarkane kernel: [ 315.618653] scsi4 : SCSI emulation
for USB Mass Storage devices
Jun 26 09:38:58 tarkane kernel: [ 315.618775] usbcore: registered new
interface driver usb-storage
Jun 26 09:38:58 tarkane kernel: [ 315.618779] USB Mass Storage support
registered.
Jun 26 09:39:03 tarkane kernel: [ 320.653653] scsi 4:0:0:0:
Direct-Access WD 2500JB External 0108 PQ: 0 ANSI: 0
Jun 26 09:39:03 tarkane kernel: [ 320.655270] sd 4:0:0:0: Attached scsi
generic sg2 type 0
Jun 26 09:39:03 tarkane kernel: [ 320.661485] sd 4:0:0:0: [sdb]
488397168 512-byte hardware sectors: (250 GB/232 GiB)
Jun 26 09:39:03 tarkane kernel: [ 320.664200] sd 4:0:0:0: [sdb] Write
Protect is off
Jun 26 09:39:03 tarkane kernel: [ 320.666169] sdb: sdb1
Jun 26 09:39:03 tarkane kernel: [ 320.675070] sd 4:0:0:0: [sdb]
Attached SCSI disk
Also, my .config is attached.
Tarkan
>>>>> "Tarkan" == Tarkan Erimer <[email protected]> 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
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
>>>>> "Tarkan" == Tarkan Erimer <[email protected]> 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
On 06/29/2009 05:30 PM, Martin K. Petersen wrote:
>>>>>> "Tarkan" == Tarkan Erimer<[email protected]> 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
>>>>> "Tarkan" == Tarkan Erimer <[email protected]> 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 [email protected]. Hopefully
they'll be able to help.
--
Martin K. Petersen Oracle Linux Engineering
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 [email protected]. Hopefully
> they'll be able to help.
>
>
OK. Thanks for the reply. I will forward the bug report to linux-usb
people.
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 <[email protected]>
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 <[email protected]>
Signed-off-by: James Bottomley <[email protected]>
:040000 040000 f744f08d73f56e6d8461267c8c5bc4c710d4c9dd
89eb1f56a7066a22a9ae6b7b916453a78a9dd082 M drivers
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 <[email protected]>
> 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 <[email protected]>
> Signed-off-by: James Bottomley
> <[email protected]>
>
> :040000 040000 f744f08d73f56e6d8461267c8c5bc4c710d4c9dd
> 89eb1f56a7066a22a9ae6b7b916453a78a9dd082 M drivers
>
>
>>>>> "Tarkan" == Tarkan Erimer <[email protected]> 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
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)
>>>>> "Tarkan" == Tarkan Erimer <[email protected]> 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 <[email protected]>
---
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);
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 <[email protected]>
>
> ---
>
> 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 [email protected]
> 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."
>>>>> "Matthew" == Matthew Wilcox <[email protected]> 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
On 07/27/2009 04:28 AM, Martin K. Petersen wrote:
>>>>>> "Tarkan" == Tarkan Erimer<[email protected]> 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<[email protected]>
>
>
Martin,
Happily, I confirm that your patch worked flawlessly with -rc4! Thanks a
lot for your help :-)
Cheers!
Tarkan
On 07/27/2009 05:43 AM, Martin K. Petersen wrote:
>>>>>> "Matthew" == Matthew Wilcox <[email protected]> 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
>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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
On Mon, Jul 27, 2009 at 10:29:21AM -0400, Martin K. Petersen wrote:
> >>>>> "Boaz" == Boaz Harrosh <[email protected]> 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."
On 07/27/2009 05:29 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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
>>>>> "Matthew" == Matthew Wilcox <[email protected]> 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
>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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
On 07/27/2009 06:19 PM, Martin K. Petersen wrote:
>>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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
On 07/27/2009 06:40 PM, Boaz Harrosh wrote:
> On 07/27/2009 06:19 PM, Martin K. Petersen wrote:
>>>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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
>>>>> "Boaz" == Boaz Harrosh <[email protected]> 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