For quite a long time now in these pre-2.4.x kernels I've noticed
problems with DMA. Particularly with my cdrom, which is a Kenwood
52x TrueX ide drive. This is the info /proc gives me as detected by
linux.
/proc/ide/hdc/
model; KENWOOD CD-ROM UCR-412 V124I
driver; ide-cdrom version 4.58
settings;
name value min
max mode
---- ----- --- ---
---- breada_readahead 4 0 127 rw current_speed 34 0 69 rw dsc_overlap 0 0 1 rw file_readahead 0 0 2097151 rw ide_scsi 0 0 1 rw init_speed 34 0 69 rw io_32bit 0 0 3 rw keepsettings 0 0 1 rw max_kb_per_request 127 1 127 rw nice1 1 0 1 rw number 2 0 3 rw pio_mode write-only 0 255 w slow 0 0 1 rw unmaskirq 0 0 1 rw using_dma 0 0 1 rwNow, I understand this cdrom is not a standard cdrom, so it may be using non-standard DMA, but if that is so, then why when using hdparm, my hdd's will also be finicky with DMA. I dont have any exact logs that show what is really going on except of course the atapi driver puts my cdrom in an infinite reset loop. It would be nice if I could force it to stop doing that ... even if it means making the cdrom not accessible because all it seems to do is increase load depending on what was accessing it when the loop began. I usually have to turn the dma off on the cdrom to get anything to access it now, although for some reason it just stopped reading with 2.4.0-test7-pre7 ..it has power, but it wont respond. Any help will be appreciated, I'm at a loss to explain what is wrong. I was only aware of DMA problems on other non-standard motherboards, this is a genuine intel 440LX . Kernel options selected: ALL the DMA options regarding "Use as default when available" and "good bad firmware" and Piix chipset support ( along with the correct for wrong value option ) output of /proc/ide/piix Intel PIIX4 Ultra 33 Chipset. --------------- Primary Channel ---------------- Secondary Channel ------------- enabled enabled --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------ DMA enabled: yes yes no no UDMA enabled: yes yes no no UDMA enabled: 2 2 X X UDMA DMA PIO
The Cdrom is detected as "DMA" on boot but I turned it off with hdparm because of the problems I mentioned before. The cdrom is supposed to be UDMA2 like the other drives though (that's what the box said) After looking in /proc/sys/dev/cdrom i set the "lock" file to 0 instead of 1, thinking maybe it was wrongfully locked and that's why it wasn't responding ...but that didn't help so i set "debug' file to 1 and tried to eject the disc using the eject command cdrom: entering CDROMEJECT cdrom: entering cdrom_release cdrom: Use count for "/dev/hdc" now zero cdrom: Unlocking door! ....obviously the kernel knows something I don't, because the door is still shut and the led didn't even light up. so I tried mounting it and this is what I get cdrom: entering cdrom_open cdrom: entering open_for_data cdrom: drive_status=4 cdrom: entering cdrom_count_tracks ATAPI device hdc: Error: Not ready -- (Sense key=0x02) Unable to recover table of contents -- (asc=0x57, ascq=0x00) The failed "Read Table of Contents" packet command was: "43 02 00 00 00 00 00 00 04 00 00 00 " cdrom: wrong media type, but CDO_CHECK_TYPE not set. cdrom: all seems well, opening the device. cdrom: opening the device gave me 0. cdrom: device opened successfully. cdrom: Use count for "/dev/hdc" now 1 VFS: Disk change detected on device ide1(22,0) ATAPI device hdc: Error: Not ready -- (Sense key=0x02) Unable to recover table of contents -- (asc=0x57, ascq=0x00) The failed "Read Table of Contents" packet command was: "43 02 00 00 00 00 00 00 04 00 00 00 " VFS: Disk change detected on device ide1(22,0) ATAPI device hdc: Error: Not ready -- (Sense key=0x02) Unable to recover table of contents -- (asc=0x57, ascq=0x00) The failed "Read Table of Contents" packet command was: "43 02 00 00 00 00 00 00 04 00 00 00 " hdc: irq timeout: status=0x80 { Busy } hdc: ATAPI reset complete ATAPI device hdc: Error: Unit attention -- (Sense key=0x06) Not ready to ready transition, medium may have changed -- (asc=0x28, ascq=0x00)
and that repeats until mount timeouts and gives up. If there is any other info needed to figure this out tell me and I'll get it. Thanks in advance.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:12 EST