[11420] attempting to read scuffed CDs causes libata to switch the drive to PIO0 mode and there's no way switch back

Open Source Support Tools

Home

Just Starting? View the Demo

Download Diagnostic Tools

(JavaScript Disabled)

Search Item

Summary

Reported Issue

Title: [11420] attempting to read scuffed CDs causes libata to switch the drive to PIO0 mode and there's no way switch back

Project: kernel

Item Last Modified: Wed, 03 Sep 2008 10:50:14

Tags:

Tag This

Bookmark This

Details

[11420] attempting to read scuffed CDs causes libata to switch the drive to PIO0 mode and there's no way switch back

Reporter:		nmiell
Created:		Sun, 24 Aug 2008 20:03:00
Updated:		Wed, 03 Sep 2008 10:50:14
Key:		11420
Versions:		Not provided
Environment:
Priority:		-1
Status:		In Progress
Resolution:		Not provided
Original Link:		http://bugzilla.kernel.org/show_bug.cgi?id=11420
Summary:		attempting to read scuffed CDs causes libata to switch the drive to PIO0 mode and there's no way switch back

Description:

Attempting to rip a scuffed CD results in lots of errors in the log as libata
steps down from UDMA66 to PIO0 (for no reason, afaik, these are media errors,
not link errors). Once the libata has erroneously decided on a tediously slow
communication method, there's no way to tell it to go back to UDMA66.

Comments:

Nicholas Miell	Sun, 24 Aug 2008 20:08:57
Created an attachment (id=17422) [details] relevant portion of system logs
Bartlomiej Zolnierkiewicz	Mon, 25 Aug 2008 01:51:44
Re-assigning to libata component.
Alan	Mon, 25 Aug 2008 05:21:57
its not seeing media errors from your drive - in that case it wouldn't slow down. Its seeing complete non-responsiveness. Might be a sign we need to bump the timeouts up for that drive.
Nicholas Miell	Mon, 25 Aug 2008 18:13:25
This is a bog-standard drive, vendor is "Optiarc", model is "DVD RW AD-7170A".
Tejun Heo	Fri, 29 Aug 2008 03:58:00
Well, the drive doesn't tell libata that it was a media error, it just timed out. libata can't tell what went down, all it knows is the drive for some reason is timing out read commands which happen to be one of indications pointing to transfer mode problems. Hmm... determining the proper action to take is tricky when the drive doesn't actually report what's going on, so I'm not sure we can do much on that department. Is the drive still busy when a command times out? ie. is it still trying to read data off the disc when libata comes in and says time's up? As for the inability to turn transfer speed up, that's a genuine missing feature and sadly will take more time to implement. Thanks.
Nicholas Miell	Mon, 01 Sep 2008 14:43:02
I assume it's still trying to read, but I don't know how to distinguish the drive being busy due to it's own retry logic compared to the kernel's retry logic. How do I crank up the timeout to see if the drive eventually responds?
Tejun Heo	Mon, 01 Sep 2008 21:18:37
You'll need to modify drivers/scsi/sr.h::SR_TIMEOUT. It's currently 30secs but drives not responding in 30secs isn't usually not usable. Anyways, please give it a try and see whether it makes any difference. Also, the kernel prints out messages every time a command times out and is retried, so you can tell by looking at the kernel messages.
Nicholas Miell	Tue, 02 Sep 2008 16:53:26
# sdparm --page=1Dh /dev/sr0 /dev/sr0: Optiarc DVD RW AD-7170A 1.02 [cd/dvd] Timeout and protect (MMC) mode page: G3E 0 [cha: n, def: 0] TMOE 0 [cha: y, def: 0] DISP 0 [cha: n, def: 0] SWPP 0 [cha: n, def: 0] G1MT 60 [cha: y, def: 60] G2MT 60 [cha: y, def: 60] Timeouts for this drive should be 60 seconds for both group 1 and group 2 commands. Does the kernel even use the drive-specific group-specific timeout values? (I'm guessing that if there's a defined constant in a header file, the answer is "no")
Tejun Heo	Tue, 02 Sep 2008 21:11:20
It is a no and has been that way from the beginning. ide-cd uses the hardcoded timeout of 60s and sr uses 30s. Till now, we've been hit more by too long a timeout than the other way around. Does increasing the timeout solve your issue?
Nicholas Miell	Wed, 03 Sep 2008 10:50:14
I don't know. The disc now reads without I/O error both in the patched and unpatched kernels.

URL: ../../kernel/issues/11420 • Email URL