FS#12545 - k3b forces PIO on read errors but doesn't scale back to DMA

Attached to Project: Arch Linux
Opened by Peter Kraus (PetoKraus) - Monday, 22 December 2008, 20:17 GMT
Last edited by Roman Kyrylych (Romashka) - Monday, 26 January 2009, 11:12 GMT
Task Type Support Request
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:
I have found this problem in the latest k3b. I am reporting this bug here, because the k3b page is a maze, and I guess someone (package maintainer, or just someone more exped) can forward it to upstream, if you can confirm it.
After trying to create ISO's from several DVD's, one of them couldn't be read properly. Afterwards, when trying to subsequently read another DVD from the drive, the system totally slowed down, even the mouse cursor was delayed. Upon checking dmesg (http://rafb.net/p/dPHGv158.html), I saw the access method has been throttled down from UDMA to PIO.
I tried to use "ignore read errors", this only changed the behavior slightly - the reading continued after the unreadable sector, but the IO was throttled down to PIO and never scaled back to UDMA anyway.
Nothing really helped - different media were accessed using PIO, since it's SATA drive, hdparm -d didn't work, and I don't know if it's possible to turn on DMA using sdparm. So I guess this is a bug in K3b, or somewhere else...


Additional info:
(up to date testing)
k3b v. 1.0.5
kernel v. vanilla 2.6.27.9

hdparm -I /dev/scd0:
>/dev/scd0:
> HDIO_DRIVE_CMD(identify) failed: Bad address

sdparm /dev/scd0:
http://rafb.net/p/pvIBKx57.html

dmesg after failed read:
http://rafb.net/p/dPHGv158.html

zcat /proc/config.gz:
http://rafb.net/p/OFeMu922.html

lspci:
http://rafb.net/p/gFl0qu59.html


Steps to reproduce:
1) get a slightly scratched DVD
2) try creating .iso image using k3b
3) watch k3b error out on the bad sector
4) try doing anything with the drive afterwards - with same or different disc in the drive. The system is unresponsive.

Cheers guys!
This task depends upon

Closed by  Roman Kyrylych (Romashka)
Monday, 26 January 2009, 11:12 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Problem with reporter's hardware.
Comment by Jan de Groot (JGC) - Monday, 22 December 2008, 22:28 GMT
This is not a K3b bug. Your DVD drive locks up the ATA port, which makes the kernel reset the port. When a reset doesn't help either, it will try to find a transfer mode that does work. As your DVD drive still locks up, the kernel tries to find a method that will work. As your drive keeps locking up, eventually the kernel goes all the way down to PIO0, where it fails and keeps failing.
The drive will stay at PIO0 until you reset the bus or force it to another mode. The kernel can't detect that your DVD drive is suddenly not having a problem at ATA33 anymore.
Comment by Glenn Matthys (RedShift) - Tuesday, 23 December 2008, 09:01 GMT
I had similar problems with a crappy A-Open DVD-RW drive. Sometimes that thing wouldn't even eject its content after the IDE bus was reset, I had to turn off the computer and turn it back on. Replaced the drive with a better one and sent the old one to my computer graveyard.

Note that you can have similar problems if your drive is getting too old and the lenses are starting to wear.
Comment by Peter Kraus (PetoKraus) - Tuesday, 23 December 2008, 14:34 GMT
Rebooting the computer, obviously, helps. I don't know how to reset the bus using software... And yes, I agree it's not a bug in k3b itself. Though as explained above, I thought it's better to submit it somewhere to get the fix started...

The drive "locks up" only on read errors on the optical media; and those are usually only few sectors. I don't have a clue about the whole k3b -> dvd+rw tools -> dvd driver -> kernel hierarchy, but there definitely is a "bug/bad feature" somewhere - it makes sense to throttle down the speed, but the stack _should_ detect (or try) that «your DVD drive is suddenly not having a problem at ATA33 anymore.»

So, what's the next step? Who should I bug, and where?
Comment by Jan de Groot (JGC) - Tuesday, 23 December 2008, 15:23 GMT
I think you should bug the manufacturer of your DVD drive because it locks up the ATA bus. Seriously, how can the kernel detect that ATA33 is working fine while it's operating at PIO0?
Note that some other commercial operating system disables DMA permanently in these cases, you will have to uninstall the whole IDE controller to get DMA working again on that OS.
Comment by Peter Kraus (PetoKraus) - Tuesday, 23 December 2008, 16:49 GMT
Right, I'll try to do. Anyway - is it normal, that read error, something which definitely occurs on optical media, triggers slowdown like this? I don't really understand where is this problem located - is it the drive hardware? Or the firmware located in the drive? Or the kernel driver/kernel itself?

I guess I could try reading the same DVD in another drive and see what it does.

«Seriously, how can the kernel detect that ATA33 is working fine while it's operating at PIO0?»
Dunno, empirically? :P

Thank you very much Jan.

Loading...