Bug 2951

Hi,

any progress in this problem? :(

I had a simmilar problem
Mine was a permissions problem

Do a
ls -l /dev/cdrom

Follow the symbolic links.
Check the permissions of the device it finally links to

I have a group called "cdrom"


I set my device to the group "cdrom""
with the permissions rw-rw----
and then I add cdrom users to this group

Make sure no one has the cdrom mounted
it won't open until everyone has unmounted.

I had the same problem (mount /dev/hdc /cdrom; umount /cdrom; And then I cannot
eject without 1) eject from root or 2) reboot or 3) paperclip) on my laptop
(Toshiba M30-801), but only with the latest versions of the kernel.

I've tried these kernel version:
Unaffected: 2.6.5, 2.6.6, 2.6.7 (with and without pktcdvd patch),
Affected: 2.6.9, 2.6.10, 2.6.11, 2.6.13.2, 2.6.14-rc3

This is the relevant output of dmesg (in my opinion):
From Kernel 2.6.7 (Last kernel I tried where everithing worked) patched with
packetwrite support:
ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio
hdc: UJDA750 DVD/CDRW, ATAPI CD/DVD-ROM drive
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
pktcdvd: v0.1.5a 2004-06-26 Jens Axboe (axboe@suse.de) and petero2@telia.com
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command 
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04Aborted Command 
cdrom: This disc doesn't have any tracks I recognize!
pktcdvd: writer 0 mapped to hdc

From Kernel 2.6.14-rc3:
ide1: BM-DMA at 0x1848-0x184f, BIOS settings: hdc:DMA, hdd:pio
hdc: UJDA750 DVD/CDRW, ATAPI CD/DVD-ROM drive
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
pktcdvd: v0.2.0a 2004-07-14 Jens Axboe (axboe@suse.de) and petero2@telia.com
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xef
hdc: drive_cmd: status=0x51 { DriveReady SeekComplete Error }
hdc: drive_cmd: error=0x04 { AbortedCommand }
ide: failed opcode was: 0xe3
cdrom: This disc doesn't have any tracks I recognize!
pktcdvd: writer pktcdvd0 mapped to hdc

program eject is using a deprecated SCSI ioctl, please convert it to SG_IO

Note that last line is displayed only after mount/umount.
When the line is displayed from dmesg, eject reports: "eject: unable to eject,
last error: Invalid argument".
If an user tries to eject a cdrom which has mounted and umounted, eject don't
eject the cdrom. But if root tries, the error messages are the same, but the
cdrom is ejected.
If an user tries to eject a cdrom which before mounting it, eject doesn't
display any error message and does his job. eject doesn't display any error
message and works good, even after a mounting/umounting problem, if root ejects
the cdrom, and then the cdrom is inserted again (but not mounted again):
ejection from root seems to reset the situation.
The button in front of the cd drive, have the same behaviour of eject (it stop
to work after a mount/umount, and restart to work after an ejection from root).

Also new kernel versions (2.6.14 2.6.14.x 2.6.15)are affected.

I've found another way to restore the situation: from root running

# pktsetup -d /dev/pktcdvd/0

gives this error:
"ioctl: Inappropriate ioctl for device"

but then you can eject the cdrom without any other problem.

(/dev/pktcdvd/0 comes from:
# pktsetup /dev/pktcdvd/0 /dev/hdc
, where /dev/hdc is my cdrom)

Jens, do you have any idea?

By the way, when you use pktsetup dmesg output is:

pktcdvd: Unknown ioctl for pktcdvd0 (40045802)

Also I noticed that you don't need to be root to use this last trick: it works
for any user with read/write permission on the device.

Slackware 10.2, kernel.org kernel 2.6.16.1
DVD drive: 0,0,0     0) 'LITE-ON ' 'DVDRW SOHW-1633S' 'BS0C' Removable CD-ROM
(ATAPI drive)

I have experienced this problem also.

using eject-2.1.2 or eject-2.1.4, as root:
# mount /mnt/cdrom/
# umount /mnt/cdrom/
  umount command is optional, eject now unmounts, behaviour is the same with or
without it
  door button will not open door after umount
# ./eject /dev/hda
  door opens briefly and closes
  door button will now open door
# ./eject /dev/hda
  door opens

I am having a similar problem on Slackware 10.2 with a complied 2.6.16.5 kernel. If i mount a cd AND try 
to copy a file from it to the disk I get a read error. I can then unmount the cdrom but cannot eject it. 
Trying to remount produces a kernel error that locks the terminal that I am in, but the other terms 2-6 are 
still responsive. Only rebooting will unlock the cdrom.
When I unloaded the nvidia binary module before mounting the cdrom everything works fine. So I'd guess 
this is an nvidia problem.

Some news...

With newer kernels the "eject" trick works also for normal users, not only for root.

The problem seems to be related to packet writing: the problem exist only when
I've setted up device with pktsetup.

I also have this problem for last several minor versions of kernel, beginning
from 2.6.14 or 15, or 13, not sure, sorry :-( and to current 2.6.18. 

After inserting formatted dvdrw in my liteon sohw-1653 kernel being to write
something on it. I know that because corresponding LED is on and disk rotating.
Also it is impossible to get it back with eject (which produce no messages) or
device button -- only reboot helps. No messages in dmesg log too. Read-only
media and unformated dvdrw disks not cause such effects. Most important -- media
need not to be mounted to cause trouble. 

Device is working -- i checked it under windows after last reboot produced to
safe the disk.

I`m ready to help as much as possible to resolve this issue.

This looks like the "failing command after close" thing Al Viro was poking at ?

Hi! I've still the same hardware and the same problems. :-)
I'd like to answer Your question, but I cannot, since I don't know where to find information about the "failing command after close" thing You are talking about (Searching for "failing command after close" doesn't give me any hint)

Anyway my actual configuration is:
Debian Lenny, kernel vanilla 2.6.22.6, eject 2.1.5 by Jeff Tranter, udftools 1.0.0b3.

Hi! I've still the same hardware and the same problems. :-)
I'd like to answer Your question, but I cannot, since I don't know where to find information about the "failing command after close" thing You are talking about (Searching for "failing command after close" doesn't give me any hint)

Anyway my actual configuration is:
Debian Lenny, kernel vanilla 2.6.22.6, eject 2.1.5 by Jeff Tranter, udftools 1.0.0b3.

Hi,

can anyone with the aforementioned problem test 2.6.25-rc2, please, to see whether the issue still exists?

Thanks,
Boris.

any news on this one?

No responses so closing. If anyone can duplicate it with a current kernel please re-open