Bug 432729
Description
Peng Haitao
2008-02-14 01:40:34 UTC
Created attachment 294862 [details]
This is a patch fixing this bug
Hello, I need some additional info from you. Please, run eject (without a patch) in a verbose mode "$ eject -v -X" and create an attachment. Also create an attachment with an output of "$ cat /proc/sys/dev/cdrom/info". Thanks Created attachment 294961 [details]
the attachment of executing command "eject -v -X"
Created attachment 294962 [details]
the attachment of executing command "cat /proc/sys/dev/cdrom/info"
Created attachment 294998 [details]
This is a patch fixing this bug
This patch avoids giving up too early the speed detection: in case of error,
just try with the next speed.
Patch seems fine. But still, I would like to have some additional information. Because this is first case of this kind of problems, a bug could be in a kernel module of cdrom. So, what cdrom do you have? Please, attach an output of "$ lsmod" as attachment too. Thanks Created attachment 295119 [details]
The attachment of executing command "lsmod"
I execute command in the machine "Acer Altos G530(SATA)"
Please try to build eject-2.1.5-5.el5.src.rpm which I'll create as an attachment. This version tries to list speeds of a cdrom in different way. Please, let me know, if this version works correct. Created attachment 296204 [details]
eject-2.1.5-5.el5.src.rpm
Created attachment 296298 [details]
This is a patch fixing this bug in the source of "eject-2.1.5-5.el5.src.rpm"
This version does not work correct, the bug is still existent. So I make a
another patch to fix this bug in the source of "eject-2.1.5-5.el5.src.rpm".
Hello, one more test. Because eject fails to set some low CDROM speed, we try another tool. So run this as a root: $ for s in `seq 0 1 52`; do hdparm -E $s /dev/hda; done Will every set of speed run without any error? Created attachment 297128 [details]
The attachment of executing command "for s in `seq 0 1 52`; do hdparm -E $s /dev/hda; done"
BTW, The function ioctl(fd, CDROM_SELECT_SPEED, speed) when the speed is 1, 2
or 3 will return -1.
Hmm, it's really strange. As I mentioned before, it may be a kernel stuff. So I'm reassigning this to kernel and will wait for their statement. It's obviously normal return of the ioctl(). Nothing really strange happened, it's device dependent. No doubts that eject tool have to deal with other then successful returns from ioctl(), it will not break the logic of the tool and does not change the behavior. Proposed there patches for eject is what I'd like to see in eject. Alternatively, you can try to update the firmware in cd/dvd drive. Or at least to look for it,... it might be known issue. go ahead, Zdenek! This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?". The proposed solution does not solve the problem, which seems to be caused by the device (or its firmware). As there is nothing we can improve in eject itself wrt. the issue, I am closing the bug as CANTFIX. Feel free to reopen if you are aware of another solution. Thanks in advance! |