SCSI: sd: don't fail if the device doesn't recognize SYNCHRONIZE CACHE
PATCH RESEND 1/1 SCSI: sd: don't fail if the device doesn't recognize SYNCHRONIZE CACHE
From: Alan Stern <[email protected]>
Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE CACHE command, as shown in this email thread:
http://marc.info/?t=138978356200002&r=1&w=2
The fact that we can't tell them to drain their caches shouldn't prevent the system from going into suspend. Therefore sd_sync_cache() shouldn't return an error if the device replies with an Invalid Command ASC.
---
Hi,
this patch has been around for awhile, but hasn't gained much attraction, and hasn't been merged anywhere yet. Which is sad, as it fixes a bug on real hardware when going to suspend :)
Could anyone from the SCSI people have a quick look maybe?
Thanks,
Daniel
drivers/scsi/sd.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/scsi/sd.c +2 -2
@@ -1463,8 +1463,8 @@ static int sd_sync_cache(struct scsi_disk *sdkp)sd_print_sense_hdr (sdkp, &sshdr);/* we need to evaluate the error return */ if (scsi_sense_valid (&sshdr) && -/* 0x3a is medium not present */ - sshdr.asc ==0x3a ) + (sshdr.asc ==0x3a ||/* medium not present */ + sshdr.asc ==0x20 ))/* invalid command */ /* this is no error here */ return 0 ;
Signature · 1 line
1.8.5.3
Quoted 17 lines · Daniel Mack
From: Alan Stern <[email protected]>
Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE CACHE command, as shown in this email thread:
http://marc.info/?t=138978356200002&r=1&w=2The fact that we can't tell them to drain their caches shouldn't prevent the system from going into suspend. Therefore
sd_sync_cache()shouldn't return an error if the device replies with an Invalid Command ASC.Signed-off-by Alan Stern <[email protected]>Reported-by Sven Neumann <[email protected]>Tested-by Daniel Mack <[email protected]>CC Oliver Neukum <[email protected]>CC <[email protected]>
Quoted 8 lines
---
Hi,this patch has been around for awhile, but hasn't gained much attraction, and hasn't been merged anywhere yet. Which is sad, as it fixes a bug on real hardware when going to suspend :)
Could anyone from the SCSI people have a quick look maybe?
But I agree with Tejun [1], that this likely does not go far enough. We should also be looking to fail future writes to the device or disabling the cache.
Tejun's comment:
"Ooh, yeah, flush failure is special. That said, I think the right way to deal with that is marking the device as failed and fail writes / flushes afterwards instead of failing suspend. It's hightly unlikely the device is in any useable state after failing flushes anyway and failing suspend has potential to lead to pretty dramatic failure conditions (device overheating in the bag would be a common one) too."
Quoted 33 lines · Dan Williams
Quoted 17 lines · Daniel Mack
From: Alan Stern <[email protected]>
Evidently some wacky USB-ATA bridges don't recognize the SYNCHRONIZE CACHE command, as shown in this email thread:
http://marc.info/?t=138978356200002&r=1&w=2The fact that we can't tell them to drain their caches shouldn't prevent the system from going into suspend. Therefore
sd_sync_cache()shouldn't return an error if the device replies with an Invalid Command ASC.Signed-off-by Alan Stern <[email protected]>Reported-by Sven Neumann <[email protected]>Tested-by Daniel Mack <[email protected]>CC Oliver Neukum <[email protected]>CC <[email protected]>Quoted 8 lines
---
Hi,this patch has been around for awhile, but hasn't gained much attraction, and hasn't been merged anywhere yet. Which is sad, as it fixes a bug on real hardware when going to suspend :)
Could anyone from the SCSI people have a quick look maybe?
Acked-by Dan Williams <[email protected]>But I agree with Tejun [1], that this likely does not go far enough. We should also be looking to fail future writes to the device or disabling the cache.
Quoted 7 lines
Tejun's comment:
"Ooh, yeah, flush failure is special. That said, I think the right way to deal with that is marking the device as failed and fail writes / flushes afterwards instead of failing suspend. It's hightly unlikely the device is in any useable state after failing flushes anyway and failing suspend has potential to lead to pretty dramatic failure conditions (device overheating in the bag would be a common one) too."
I disagree with part of Tejun's comment. In the case of the bug report leading to this patch, it is _not_ true that the device ends up in an unusable state (as far as I know). There's no reason to mark the device as failed.
Alan Stern