Re: Buffer I/O error after s2ram with usb storage
Le Wed, 27 Aug 2014 10:54:53 -0400,
Alan Stern a écrit :
> On Wed, 27 Aug 2014, Matthieu CASTET wrote:
>
> > Ping
> >
> > I have got also a problem with a usb sdcard reader (without power cut
> > during suspend)
>
> > > > The usb storage driver call scsi_report_bus_reset after device reset,
> > > > but because of commit dfcf7775 <4>, we don't ignore unit attention if
> > > > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
> > > >
> > > > If dfcf7775 is reverted there is no more Buffer I/O error.
> > > >
> > > > Is that possible to find a way to restore the behavior before dfcf7775
> > > > commit (no Buffer I/O error after device reset) after a suspend to ram ?
>
> Since that commit was written to fix a problem with certain cdrom
> drives, maybe we would work around the issue by modifying the commit.
> Have it go back to the original behavior if the device isn't a cdrom
> drive.
>
> That's not a complete fix (it won't help when a CD drive is attached
> via USB), but maybe it's better than nothing.
>
Ok,
note to handle all case we need also to filter unit_attention in
scsi_test_unit_ready. Otherwise DISK_EVENT_MEDIA_CHANGE event is set and
check_disk_change will invalidate vfs cache.
Matthieu
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2bc0362..e994061 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -2030,8 +2030,12 @@ scsi_test_unit_ready(struct scsi_device *sdev, int
timeout, int retries,
result = scsi_execute_req(sdev, cmd, DMA_NONE, NULL, 0, sshdr,
timeout, retries, NULL);
if (sdev->removable && scsi_sense_valid(sshdr) &&
- sshdr->sense_key == UNIT_ATTENTION)
- sdev->changed = 1;
+ sshdr->sense_key == UNIT_ATTENTION) {
+ if (sdev->expecting_cc_ua)
+ sdev->expecting_cc_ua = 0;
+ else
+ sdev->changed = 1;
+ }
} while (scsi_sense_valid(sshdr) &&
sshdr->sense_key == UNIT_ATTENTION && --retries);
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Buffer I/O error after s2ram with usb storage
Ping
I have got also a problem with a usb sdcard reader (without power cut
during suspend)
[ 1073.606668] PM: Entering mem sleep
[ 1073.606742] Suspending console(s) (use no_console_suspend to debug)
[ 1073.607146] sd 1:0:0:0: [sda] Synchronizing SCSI cache
[ 1073.639076] sd 1:0:0:0: [sda] Stopping disk
[ 1074.186688] PM: suspend of devices complete after 580.127 msecs
[...]
[ 1075.265183] PM: resume of devices complete after 615.990 msecs
[ 1075.265627] PM: Finishing wakeup.
[ 1075.265630] Restarting tasks ...
[...]
[ 1203.404593] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
6, 29065 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404628] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
5, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404648] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
4, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404667] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
3, 1601 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404686] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
2, 0 clusters in bitmap, 32768 in gd; block bitmap corrupt.
[ 1203.404705] EXT4-fs error (device sdb6): ext4_mb_generate_buddy:756: group
1, 1600 clusters in bitmap, 32321 in gd; block bitmap corrupt.
[ 1203.404726] JBD2: Spotted dirty metadata buffer (dev = sdb6, blocknr = 0).
There's a risk of filesystem corruption in case of system crash.
[ 1204.141482] sd 8:0:0:0: [sdb] Media Changed
[ 1204.141490] sd 8:0:0:0: [sdb]
[ 1204.141494] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1204.141497] sd 8:0:0:0: [sdb]
[ 1204.141499] Sense Key : Unit Attention [current]
[ 1204.141504] Info fld=0x0
[ 1204.141506] sd 8:0:0:0: [sdb]
[ 1204.141510] Add. Sense: Not ready to ready change, medium may have changed
[ 1204.141514] sd 8:0:0:0: [sdb] CDB:
[ 1204.141516] Read(10): 28 00 00 0a 75 f8 00 00 08 00
[ 1204.141526] end_request: I/O error, dev sdb, sector 685560
Le Mon, 28 Apr 2014 15:01:39 +0200,
Matthieu CASTET a écrit :
> Hi,
>
> any news on this.
>
> Matthieu CASTET
>
> Le Tue, 22 Apr 2014 16:01:15 +0200,
> Matthieu CASTET a écrit :
>
> > Hi,
> >
> > while playing with suspend to ram I found a strange behavior with usb
> > key.
> >
> > This can be easily reproduced by doing :
> > - plug a usb key
> > - start to read the usb key : "cat /dev/sdx > /dev/null"
> > - go to suspend : "echo mem > /sys/power/state"
> > - while in suspend, unplug and replug the usb key (simulate usb power
> > loss for computer that keep power)
> > - exit suspend
> > - there is read error on the usb key
> >
> >
> > Because the power was cut during s2ram, the usb stack reset the device
> > <1>.
> > When new data transfer are done, we got a UNIT_ATTENTION from the
> > device <2> and IO error are returned to user space application.
> >
> > After some investigation it seems some (all on the 3 I tested) usb key
> > report as removable, and scsi layer abort the transfer in case of
> > UNIT_ATTENTION <3>.
> >
> > The usb storage driver call scsi_report_bus_reset after device reset,
> > but because of commit dfcf7775 <4>, we don't ignore unit attention if
> > "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
> >
> > If dfcf7775 is reverted there is no more Buffer I/O error.
> >
> > Is that possible to find a way to restore the behavior before dfcf7775
> > commit (no Buffer I/O error after device reset) after a suspend to ram ?
> >
> >
> > Matthieu CASTET
> >
> > PS : the same error happen if sg_reset -b /dev/sdx is used on the
> > device.
> >
> >
> > <1>
> > [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using
> > ehci-pci [...]
> > [ 117.543922] Restarting tasks ... done.
> > [ 117.548390] video LNXVIDEO:01: Restoring backlight state
> > <2>
> > [ 117.549179] sd 6:0:0:0: [sdb] Media Changed
> > [ 117.549184] sd 6:0:0:0: [sdb]
> > [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> > [ 117.549189] sd 6:0:0:0: [sdb]
> > [ 117.549191] Sense Key : Unit Attention [current]
> > [ 117.549195] Info fld=0x0
> > [ 117.549197] sd 6:0:0:0: [sdb]
> > [ 117.549201] Add. Sense: Not ready to ready change, medium may have
> > changed [ 117.549203] sd 6:0:0:0: [sdb] CDB:
> > [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
> > [ 117.549212] end_request: I/O error, dev sdb, sector 182528
> > [ 117.549218] Buffer I/O error on device sdb1, logical block 2
Re: Buffer I/O error after s2ram with usb storage
Hi,
any news on this.
Matthieu CASTET
Le Tue, 22 Apr 2014 16:01:15 +0200,
Matthieu CASTET a écrit :
> Hi,
>
> while playing with suspend to ram I found a strange behavior with usb
> key.
>
> This can be easily reproduced by doing :
> - plug a usb key
> - start to read the usb key : "cat /dev/sdx > /dev/null"
> - go to suspend : "echo mem > /sys/power/state"
> - while in suspend, unplug and replug the usb key (simulate usb power
> loss for computer that keep power)
> - exit suspend
> - there is read error on the usb key
>
>
> Because the power was cut during s2ram, the usb stack reset the device
> <1>.
> When new data transfer are done, we got a UNIT_ATTENTION from the
> device <2> and IO error are returned to user space application.
>
> After some investigation it seems some (all on the 3 I tested) usb key
> report as removable, and scsi layer abort the transfer in case of
> UNIT_ATTENTION <3>.
>
> The usb storage driver call scsi_report_bus_reset after device reset,
> but because of commit dfcf7775 <4>, we don't ignore unit attention if
> "sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
>
> If dfcf7775 is reverted there is no more Buffer I/O error.
>
> Is that possible to find a way to restore the behavior before dfcf7775
> commit (no Buffer I/O error after device reset) after a suspend to ram ?
>
>
> Matthieu CASTET
>
> PS : the same error happen if sg_reset -b /dev/sdx is used on the
> device.
>
>
> <1>
> [ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using
> ehci-pci [...]
> [ 117.543922] Restarting tasks ... done.
> [ 117.548390] video LNXVIDEO:01: Restoring backlight state
> <2>
> [ 117.549179] sd 6:0:0:0: [sdb] Media Changed
> [ 117.549184] sd 6:0:0:0: [sdb]
> [ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
> [ 117.549189] sd 6:0:0:0: [sdb]
> [ 117.549191] Sense Key : Unit Attention [current]
> [ 117.549195] Info fld=0x0
> [ 117.549197] sd 6:0:0:0: [sdb]
> [ 117.549201] Add. Sense: Not ready to ready change, medium may have
> changed [ 117.549203] sd 6:0:0:0: [sdb] CDB:
> [ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
> [ 117.549212] end_request: I/O error, dev sdb, sector 182528
> [ 117.549218] Buffer I/O error on device sdb1, logical block 22560
> [ 117.549225] Buffer I/O error on device sdb1, logical block 22561
> [ 117.549228] Buffer I/O error on device sdb1, logical block 22562
> [ 117.549231] Buffer I/O error on device sdb1, logical block 22563
> [ 117.549233] Buffer I/O error on device sdb1, logical block 22564
> [ 117.549235] Buffer I/O error on device sdb1, logical block 22565
> [ 117.549238] Buffer I/O error on device sdb1, logical block 22566
> [ 117.549240] Buffer I/O error on device sdb1, logical block 22567
> [ 117.549243] Buffer I/O error on device sdb1, logical block 22568
> [ 117.549245] Buffer I/O error on device sdb1, logical block 22569
> [ 117.809462] sd 6:0:0:0: [sdb] No Caching mode page found
> [ 117.809470] sd 6:0:0:0: [sdb] Assuming drive cache: write through
> [ 117.812696] sd 6:0:0:0: [sdb] No Caching mode page found
> [ 117.812703] sd 6:0:0:0: [sdb] Assuming drive cache: write through
> [ 117.813688] sdb: sdb1
>
>
> <3>
> case UNIT_ATTENTION:
> if (cmd->device->removable) {
> /* Detected disc change. Set a bit
> * and quietly refuse further access.
> */
> cmd->device->changed = 1;
> description = "Media Changed";
> action = ACTION_FAIL;
> } else {
> /* Must have been a power glitch, or a
> * bus reset. Could not have been a
> * media change, so we just retry the
> * command and see what happens.
> */
> action = ACTION_RETRY;
> }
>
> <4>
> commit dfcf7775815504d13a1d273073810058caf84b9d
> Author: TARUISI Hiroaki
> Date: Thu Aug 11 20:25:20 2011 +0900
>
> [SCSI] Fix out of spec CD-ROM problem with media change
>
> Some CD-ROMs fail to report a media change correctly. The specific
> one for this patch simply fails to respond to commands, then gives a
> UNIT ATTENTION after being reset which returns ASC/ASCQ 28/00. This
> is out of spec behaviour, but add a check in the eat CC/UA on reset
> path to catch this case so the CD-ROM will function somewhat properly.
>
> [jejb: fixed up white space and accepted without signoff]
>
Buffer I/O error after s2ram with usb storage
Hi,
while playing with suspend to ram I found a strange behavior with usb
key.
This can be easily reproduced by doing :
- plug a usb key
- start to read the usb key : "cat /dev/sdx > /dev/null"
- go to suspend : "echo mem > /sys/power/state"
- while in suspend, unplug and replug the usb key (simulate usb power
loss for computer that keep power)
- exit suspend
- there is read error on the usb key
Because the power was cut during s2ram, the usb stack reset the device
<1>.
When new data transfer are done, we got a UNIT_ATTENTION from the
device <2> and IO error are returned to user space application.
After some investigation it seems some (all on the 3 I tested) usb key
report as removable, and scsi layer abort the transfer in case of
UNIT_ATTENTION <3>.
The usb storage driver call scsi_report_bus_reset after device reset,
but because of commit dfcf7775 <4>, we don't ignore unit attention if
"sshdr.asc == 0x28 && sshdr.ascq == 0x00" ("Not-ready to ready").
If dfcf7775 is reverted there is no more Buffer I/O error.
Is that possible to find a way to restore the behavior before dfcf7775
commit (no Buffer I/O error after device reset) after a suspend to ram ?
Matthieu CASTET
PS : the same error happen if sg_reset -b /dev/sdx is used on the
device.
<1>
[ 117.070255] usb 2-1.4: reset high-speed USB device number 3 using
ehci-pci [...]
[ 117.543922] Restarting tasks ... done.
[ 117.548390] video LNXVIDEO:01: Restoring backlight state
<2>
[ 117.549179] sd 6:0:0:0: [sdb] Media Changed
[ 117.549184] sd 6:0:0:0: [sdb]
[ 117.549187] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 117.549189] sd 6:0:0:0: [sdb]
[ 117.549191] Sense Key : Unit Attention [current]
[ 117.549195] Info fld=0x0
[ 117.549197] sd 6:0:0:0: [sdb]
[ 117.549201] Add. Sense: Not ready to ready change, medium may have
changed [ 117.549203] sd 6:0:0:0: [sdb] CDB:
[ 117.549205] Read(10): 28 00 00 02 c9 00 00 00 f0 00
[ 117.549212] end_request: I/O error, dev sdb, sector 182528
[ 117.549218] Buffer I/O error on device sdb1, logical block 22560
[ 117.549225] Buffer I/O error on device sdb1, logical block 22561
[ 117.549228] Buffer I/O error on device sdb1, logical block 22562
[ 117.549231] Buffer I/O error on device sdb1, logical block 22563
[ 117.549233] Buffer I/O error on device sdb1, logical block 22564
[ 117.549235] Buffer I/O error on device sdb1, logical block 22565
[ 117.549238] Buffer I/O error on device sdb1, logical block 22566
[ 117.549240] Buffer I/O error on device sdb1, logical block 22567
[ 117.549243] Buffer I/O error on device sdb1, logical block 22568
[ 117.549245] Buffer I/O error on device sdb1, logical block 22569
[ 117.809462] sd 6:0:0:0: [sdb] No Caching mode page found
[ 117.809470] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 117.812696] sd 6:0:0:0: [sdb] No Caching mode page found
[ 117.812703] sd 6:0:0:0: [sdb] Assuming drive cache: write through
[ 117.813688] sdb: sdb1
<3>
case UNIT_ATTENTION:
if (cmd->device->removable) {
/* Detected disc change. Set a bit
* and quietly refuse further access.
*/
cmd->device->changed = 1;
description = "Media Changed";
action = ACTION_FAIL;
} else {
/* Must have been a power glitch, or a
* bus reset. Could not have been a
* media change, so we just retry the
* command and see what happens.
*/
action = ACTION_RETRY;
}
<4>
commit dfcf7775815504d13a1d273073810058caf84b9d
Author: TARUISI Hiroaki
Date: Thu Aug 11 20:25:20 2011 +0900
[SCSI] Fix out of spec CD-ROM problem with media change
Some CD-ROMs fail to report a media change correctly. The specific
one for this patch simply fails to respond to commands, then gives a
UNIT ATTENTION after being reset which returns ASC/ASCQ 28/00. This
is out of spec behaviour, but add a check in the eat CC/UA on reset
path to catch this case so the CD-ROM will function somewhat properly.
[jejb: fixed up white space and accepted without signoff]
Signed-off-by: James Bottomley
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index a4b9cdb..dc6131e 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -293,8 +293,16 @@ static int scsi_check_sense(struct scsi_cmnd *scmd)
* so that we can deal with it there.
*/
if (scmd->device->expecting_cc_ua) {
- scmd->device->expecting_cc_ua = 0;
- return NEEDS_RETRY;
+ /*
+* Because some device does not queue unit
+* attentions correctly,
Re: [usb-storage] Re: usb disk recognized but fails
Hi, Le Fri, 24 Jan 2014 11:07:01 -0500, Alan Stern a écrit : > Matthieu: > > Can you help with this problem? > > > You were right; that driver caused the problem. > > Matthieu Castet wrote the Cypress-ATACB driver, so maybe he can help. > > As shown above, this device matches the last entry in the > unusual_cypress.h file (the one named "Super Top"). Not shown here is The "Super Top" id were added later. When I did the driver I only check the datasheet of the fisrt two entry. Looking at the git log, we can see there already was corruption detected by this entry [1]. Without knowing what chip is in the "super top" bridge, I propose to remove the entry : it seems to cause too much trouble. An alternative could be to enable it only for bcdDevice 1.60. Matthieu [1] USB: usb-storage: unusual_devs update for Super TOP SATA bridge The current entry in unusual_cypress.h for the Super TOP SATA bridge devices seems to be causing corruption on newer revisions of this device. This has been reported in Arch Linux and Fedora. The original patch was tested on devices with bcdDevice of 1.60, whereas the newer devices report bcdDevice as 2.20. Limit the UNUSUAL_DEV entry to devices less than 2.20. This fixes https://bugzilla.redhat.com/show_bug.cgi?id=909591 The Arch Forum post on this is here: https://bbs.archlinux.org/viewtopic.php?id=152011 -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
