Bugzilla Bug 35458

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 an attachment (id=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 an attachment (id=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 an attachment (id=27586) [details]
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