When ripping a cd with grip, I noticed the drive was not in DMA mode. I did
hdparm -d1 /dev/hdi. The grip process (it uses libcdda_paranoia.so and
libcdda_interface.so) hung, and attempt to kill it with -KILL failed.
Eventually it died but remained as zombie:
PID TTY STAT TIME COMMAND
6392 pts/7 ZNl 1:54 [grip] <defunct>
According to fuser, it no longer occupies /dev/hdi, but it seems to hold a
reference to ide_cd.ko:
lsmod|grep cd
ide_cd 35936 1
cdrom 32800 1 ide_cd
The drive works, I but only partly. I can't mount any iso9660 disks, nor
rip anything with grip (it still finds the index, though). dd can only read
~491MB from /dev/hdi (they come out without errors), no matter whether which
~data cd or dvd I put there.
This probably explains it:
blockdev --getsize /dev/hdi
946048
The same reading for all disks I've tried.
Incidentally, I was about two thirds done with ripping, when I did hdparm
-d1. My guess it that the grip zombie keeps ide_cd in a state where the same
audio cd is still in drive and can't be read further.
As far as I can tell, the drive itself is not badly confused, and I was able
to rip a whole disk with cdda2wav (it probably uses another interface). The
mount/dd/grip problem remains.
hdparm -w /dev/hdi doesn't make difference.
I admit doing hdparm -d1 in the middle of an operation is a bad idea, but
perhaps kernel could handle it better?
This the second (and hopefully last) time I made the same mistake; last time
I was recording a DVD. I had to boot to get the drive working again.
If I do hdparm -d1 when the drive is idle, it works just fine.
05:01.0 Mass storage controller: Promise Technology, Inc. 20269 (rev 02)
(prog-if 85)
Subsystem: Promise Technology, Inc. Ultra133TX2
Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 19
I/O ports at cc00 [size=8]
I/O ports at c880 [size=4]
I/O ports at c800 [size=8]
I/O ports at c480 [size=4]
I/O ports at c400 [size=16]
Memory at feafc000 (32-bit, non-prefetchable) [size=16K]
Expansion ROM at 88000000 [size=16K]
Capabilities: [60] Power Management version 1
/dev/hdi:
ATAPI CD-ROM, with removable media
Model Number: OPTORITEDVD RW DD0401
Serial Number:
Firmware Revision: 150E
Standards:
Likely used CD-ROM ATAPI-1
Configuration:
DRQ response: 3ms.
Packet size: 12 bytes
Capabilities:
LBA, IORDY(can be disabled)
Buffer size: 1024.0kB
DMA: sdma0 sdma1 sdma2 mdma0 mdma1 mdma2 udma0 udma1 *udma2
Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
Cycle time: no flow control=383ns IORDY flow control=120ns
-- v --
[email protected]
Ville Herva wrote:
> When ripping a cd with grip, I noticed the drive was not in DMA mode. I did
> hdparm -d1 /dev/hdi. The grip process (it uses libcdda_paranoia.so and
> libcdda_interface.so) hung, and attempt to kill it with -KILL failed.
> Eventually it died but remained as zombie:
Known problem but probably won't get fixed. Just use hdparm only when
the drive is idle. Put it somewhere in the boot script.
Hmm... IDE should enable DMA automatically for most cases. Can you post
full dmesg?
--
tejun
On Mon, Nov 27, 2006 at 12:00:30PM +0900, you [Tejun Heo] wrote:
> Ville Herva wrote:
> >When ripping a cd with grip, I noticed the drive was not in DMA mode. I did
> >hdparm -d1 /dev/hdi. The grip process (it uses libcdda_paranoia.so and
> >libcdda_interface.so) hung, and attempt to kill it with -KILL failed.
> >Eventually it died but remained as zombie:
>
> Known problem but probably won't get fixed.
Fair enough.
> Just use hdparm only when the drive is idle. Put it somewhere in the boot
> script.
I already did, but DMA had dropped off in the meanwhile.
It did burn a dvd without a hitch with DMA=1, though.
> Hmm... IDE should enable DMA automatically for most cases. Can you post
> full dmesg?
Will do. I'll just have to boot first.
It's currently unavailable, as the
[2416661.676213] attempt to access beyond end of device
[2416661.676216] loop0: rw=0, want=1401620, limit=946048
messages from loop (/dev/hdi is limited to 946048 block as I described) have
filled dmesg.
Thanks.
-- v --
[email protected]