If you use ide-scsi to access cdwriters you are not able to set de DMA Mode using the hdparm init script because it thinks that it is a real SCSI Drive. Reproducible: Always Steps to Reproduce:
Created attachment 21935 [details] Modified Version of the hdparm to fix this This is a modified Version of the hdparm script that is able to set the dma mode for ide-scsi drives because it has another method of "detection" as the original script.
as far as i know dma does not work with ide-scsi
Created attachment 21947 [details] Modified Version of the hdparm to fix this (there was a problem with cd drives NOT used with ide-scsi - fixed it)
DMA works with ide-scsi - but you have to determinate which device it is: In /dev/cdroms you have the scsi symlink but in /dev/ide you also have an generic "device" to access the ide part of the drive: Example : /dev/cdroms/cdrom0 is a CDWriter connected as Secondary Master on your onboard ide-controller. The "device" to use hdparm on would be /dev/ide/host0/bus1/target0/lun0/generic hdparm -d1 -X udma2 /dev/ide/host0/bus1/target0/lun0/generic
could you please post a diff
now that we can burn with ATAPI/IDE is there even a need for ide-scsi ? meaning, is there really a need for this update ?
Created attachment 27586 [details, diff] Added a FIX or Workaround for having ide-scsi drives work ok with the hdparm init script Ok, so I also hated the fact that hdparm doesn't like to work with ide-scsi drives. However, this patch fixed that! The main problem is that as soon as ide-cd is replaced by ide-scsi in the kernel, then /dev/cdroms/cdromX no longer points to an IDE disc, but it points to the emulated ide-scsi SCSI disc. Furthermore, if /dev/hdX used to exist for the real IDE CDROM, it disappears in lieu of it's SCSI counterpart. This is very good for CD burning, but very bad for hdparm, which refuses to do anything with SCSI drives. HOWEVER, it is still possible to talk to the kernel's IDE core (and thus issue hdparm commands to change the IDE settings) if one uses the OLD IDE-based device nodes (eg hda, hdb, hdc, hdd). Those nodes normally disappear automatically if you have devfs, but one can re-create them temorarily, pass them as parameters to hdparm, and then delete them when done. This way it is possible to set IDE parameters on CDROM drives claimed by ide-scsi.o. So, my workaround has the hdparm init scrip create the IDE-equivalent device nodes (in /tmp) for all SCSI cdroms that are claimed by ide-scsi (the code to detect this is rather ugly but it's in the patch). It matches up the /dev/cdroms/cdromXX entries with these device nodes, and if the user requested some hdparm commands to be run on those entries, it then does the right thing and applies the hdparm settings to them using the IDE device nodes, not the SCSI ones. This is possible because really it's still possible to issue ioctl's to the kernel to set IDE parameters on these pseudo-scsi discs.. one just needs to do it via the correct device nodes. Anyway.. this patch works. I hope it gets applied to mainstream portage as it is very inconvenient to not have DMA and the correct udma settings for my CD burner! :(
Ok the above patch that I attached is needed because: 1. You still need ide-scsi. Not all burning software knows how to talk to IDE/ATAPI (even thought it's basically the same command set as SCSI MMC3). AFAIK the most popular burning program, K3B, can't deal with IDE discs. 2. The IDE core gets rid of /dev/ide/hostX/busX/target0/lun0/generic as soon as ide-scsi claims the CDROM drive as it's own! Thus there IS no ide device node! So you need to create one yourself.. So, my attached patch creates temporary device nodes for all ide-scsi discs in /tmp (which it then deletes when done) to address this.. At any rate, even if IDE cd burning becomes 100% mainstream, it's still nice to support ide-scsi discs in the init script just in case people happen to have that setup..
One more note: perhaps it makes more sense to create the temporary device nodes in /dev/shm.. since /tmp may not always be writeable?
i don't like the idea of creating a device node, k3b supports ide burning without problem, eroaster and xcdroast as well
Yeah you are right.. most newer programs now support IDE cd burning. At any rate the problem is that init scripts should be smart and work OK with ide-scsi drives. What's wrong with creating a temporary device node? It can be done in tmpfs. If a user wants to use ide-scsi drives there really is no solution other than fooling the kernel into allowing hdparm to set DMA mode. Fooling the kernel involves creating a temporary device node. Either that, or someone needs to patch hdparm to work properly with ide-scsi drives. Good software should 'just work'. If the linux kernel supports ide-scsi, Gentoo should 'just work' with it. If a user has an ide-scsi drive, he/she may very well want to use DMA. Or he/she might want to tell the kernel to keep settings across IDE resets (-k1 for hdparm). This is actually more useful a feature than you would think... as having the cdrom drive revert back to no DMA when there is a read error (a common occurence on removable, scratchable media), is just horrible behavior. Why should some users that aren't big experts in linux suffer with poorly performing, non-DMA mode cd burners, when there is a very feasible fix for the case when they are using ide-scsi. We already have hdparm init scripts.. it is a small step to make them work OK with ide-scsi.
can you take a look at bug 37755 if that fixes your problem
fixed with bug #37755
