http://qa.mandrakesoft.com/show_bug.cgi?id=2103
------- Additional Comments From [EMAIL PROTECTED] 2003-03-05 19:28 ------- Same problem exists in mdk-9.1rc2 for /dev/hdd. Now, I have scsi emulation for only /dev/scd0 (/dev/hdc) while /dev/hdd is not scsi-emulated. My fstab entries are: none /mnt/cdrom supermount dev=/dev/scd0,fs=auto,ro,--,iocharset=iso8859-1,codepage=850,umask=0 0 0 none /mnt/cdrom2 supermount dev=/dev/hdd,fs=auto,ro,--,iocharset=iso8859-1,codepage=850,umask=0 0 0 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. ------- Reminder: ------- assigned_to: [EMAIL PROTECTED] status: UNCONFIRMED creation_date: description: Firstly, I am running kernel 2.4.19-24mdk (not 2.4.19-19mdk). I have all updates applied. I also have supermount and scsi-emulation enabled. I have two CD drives (hdc and hdd). The ejection problem is with /dev/cdrom1 (/dev/hdd). Here are the steps to reproduce the problem: 1. Put a CD in the drive and close the tray by pressing the CD eject button (the hardware button present on the drive). 2. Press the eject button and the CD is ejected normally 3. Close the CD tray again. 4. Run a command to read /dev/cdrom1 as: cat /dev/cdrom1 5. a) Now press the CD eject button. Nothing happens. b) If I use "eject /dev/cdrom1", the CD is ejected fine. 6. a) If I skip step 5b and run "ls /mnt/cdrom2" (/dev/cdrom1 is mounted on /mnt/cdrom2), then the CD files are listed just fine. b) After step 6a, if I press the CD eject button, it ejects normally. This strange behavior is 100% reproducible. It seems that every time the cat command is used, it prevents a manual hardware ejection of the CD. After cat, using another read command (like ls) that reads from the device, sets things right. Further investigation revealed that if I manually umount /mnt/cdrom2 then this problem disappears. If I manually re-mount /mnt/cdrom2, the problem reappears. Obviously, supermount is not handling it correctly since it is related to mounting. No error messages in dmesg or /var/log/* can be found that explains this odd behavior.