Hi,

I'm late reporting this mainly because until now I wasn't sure whether 
this was a kernel issue or not.

Since 2.6.27 I've had several times, but not always, that after I open the 
CD tray by pressing the eject button it spontaneously closes after a 
short delay. The delay varies between ~0 and ~2 seconds.

A few times this has resulted in a DVD getting stuck halfway out because I 
had already staring taking it out after playing it with vlc.

I've now also seen this happen two times while vlc was not running which 
makes the kernel the prime suspect.

Are you aware of any likely culprits I could try reverting?

System is running x86_64 current git, debian unstable.

The system has two CD drives:
- one normal IDE DVD drive on an Intel ICH7 controller (8086:27df); this
  is the one I've seen the issue with
- one SATA DVD writer, also on Intel ICH7 (8086:27c1); I haven't seen the
  issue with this one but I only use it very rarely

Cheers,
FJP
--

[ message continues ]

For the record, I had this on my Gentoo system. It turned out that HAL
was responsible. (So it may not be a kernel bug at all)

Do see this report:

Regards,
Tony V.
[ message continues ]

Thanks for the link.

It cannot be hal in my case as I've disabled polling by hal for both
drives using the 'hal-disable-polling' command.

The bug report also mentions udev, but I'm not sure if that's it either
as the bit in the report is about sr* devices, which is SCSI/SATA and
the patch linked there is in Debian's udev.
The udev changelog for Debian has:
udev (0.125-4) unstable; urgency=medium
  * 60-persistent-storage.rules: do not run vol_id on media tray open
    events or the kernel will close the tray again.

Hmm, in Debian unstable /etc/udev/rules.d/60-persistent-storage.rules
also has:
# skip removable ide devices, because open(2) on them causes an events loop
KERNEL=="hd*[!0-9]", ATTR{removable}=="1", DRIVERS=="ide-cs|ide-floppy", \
                                        GOTO="persistent_storage_end"

I wonder if we've got a simple case of a typo here: ide-cs instead of
ide-cd? However, there is such a thing as an ide-cs driver (legacy driver
for PCMCIA IDE/ATA disk cards).
But it does seem logical that rule should also cover IDE CDs...

Cheers,
FJP
--

[ message continues ]

Well, in upstream udev 128 the comment for that rule has been changed to:
# never access non-cdrom removable ide devices, the drivers are causing
# event loops on open()

So it looks like that's not it either.
--

[ message continues ]

This rule is fine, it was only ide-cs, the old pcmcia stuff, that had
these issues.

You might need:
  http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=f755fd5657b619fd27160ad...

Kay
--

[ message continues ]

Yes, I'd seen that new rule, but:
- that fix is already included in the udev version I'm using
- I'm seeing the issue on /dev/hda (IDE DVD drive), not on /dev/sr*
--

[ message continues ]

Does:
  /sbin/udevadm monitor --env
print something while you see the tray closing?

Does this also happen when you set:
  /proc/sys/dev/cdrom/autoclose
to 0?

Kay
--

[ message continues ]

I was somewhat lucky to reproduce it with that running and there was no 
output during the open or close. I guess that rules out udev?

I still don't know how to reliably reproduce this. It seems that after it 
has occurred once, it will not occur again unless the system is rebooted. 
But I'm not 100% sure of that.

Most times I've seen it was after playing a DVD when ejecting the disc to 
put it back in its box, but not when the DVD was inserted earlier.
But I've also seen it shortly after the system is booted when just opening 
the tray with no media inserted.

Just to be clear: until recently the drive has always behaved perfectly in 

I'll set that on boot using /etc/sysctl.conf and will report if I can 
still reproduce with that setting. I've checked that the "normal" value 
is 1.

Thanks.
--

[ message continues ]

That will prevent the closing, when something tries to open the device
in blocking mode. If that solves the issue, you should start looking
which process tries to access your drive.

Kay
--

[ message continues ]

I didn't try. I have only slot-in optical drives and manual laptop
trays, there is no autoclose possible. I also have no box with IDE
drivers anymore, sorry.

Kay
--

[ message continues ]

Right. It happens with autoclose=0 too.

Any suggestions for the next step? Maybe add some instrumentation in the 
cdrom or ide-cd drivers?

I think I'll also go back to 2.6.26 for a while to see if I can reproduce 
it with that. I'm fairly sure it won't, but confirming that will be a 
good data point.

I don't see myself bisecting this as long as I don't have a reliable way 
to reproduce it.

BTW, I have considered a hardware problem like a short in the eject 
button, but I don't think that's it. The eject button "feels" good and 
I'd expect it to also spontaneously eject if that was the problem.
It also does feel like there is a pattern to it, even if I cannot see yet 
what that pattern would be.
--

[ message continues ]

Hi,


I have a debugging infrastructure ready in ide-cd which is in Bart's tree, you
could apply it ontop of current git, enable it and send dmesg so that we could
see exactly what is going on:

http://www.kernel.org/pub/linux/kernel/people/bart/pata-2.6/patches/

-- 
Regards/Gruss,
Boris
--

[ message continues ]

I have tried to reproduce this with the extra debugging, but have so far 
not been able to (which also explains the delay in replying).

There was one reply suggesting that the close could be triggered by 
the "user pushes tray in manually" sensor (which I had not thought of 
myself). I normally never do that, but when I fiddled with the tray it 
did close very quickly once. After that I did push it in a few times 
(with some force needed as you'd expect) and the problem has not 
reoccurred since.

So I'm currently inclined to blame that sensor as the cause of the 
problem, but will keep an open mind and try further tracing in case the 
problem reoccurs.

My thanks to all who responded and helped eliminate a number of possible 
causes.

Cheers,
FJP
--

[ message continues ]

I have the problem too, I'm following the thread. As far as I can say, HW is not
involved here. It happens after eject command too. I don't know how to reproduce
it too, though.
--

[ message continues ]