On Tuesday 30 September 2008, Kay Sievers wrote:
> >> Does this also happen when you set:
> >> /proc/sys/dev/cdrom/autoclose
> >> to 0?
> >
> > 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.
>
> 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.
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.
Hi,
On Wed, Oct 1, 2008 at 3:53 PM, Frans Pop <[email protected]> wrote:
> On Tuesday 30 September 2008, Kay Sievers wrote:
>> >> Does this also happen when you set:
>> >> /proc/sys/dev/cdrom/autoclose
>> >> to 0?
>> >
>> > 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.
>>
>> 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.
>
> 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 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
On 10/01/2008 03:53 PM, Frans Pop wrote:
> BTW, I have considered a hardware problem like a short in the eject
> button, but I don't think that's it.
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.
On Wednesday 01 October 2008, Boris Petkov wrote:
> 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/
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