event devices not released

event devices not released

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Hi,

I think I've found a bug :-/

Symptoms: when I remove (unplug) a USB keyboard or mouse, the 
corresponding event device seems to be closed but not released; when I 
plug the device back in, it gets a new input device handle. This means 
that after several suspend/resume cycles (in which it seems all usb 
devices are virtually unplugged and replugged) the kernel is out of 
event devices and complains likewise. My nice little program that 
catches specific keystrokes also stops to get any interesting events 
from that moment on. After reboot everything works again as expected.

I've seen a similar bug report on linux-kernel but it wasn't followed up 
on. Also this only mentioned problems through suspend cycles while I 
also have the problem simply plugging in and out.

Environment: linux kernel 2.6.24 vanilla on i386. The event files are 
held open by one or more processes when the devices are unplugged. 
Unfortunatly my program is not the only one that has them open, but hald 
and Xorg also have some of the devices open, so I cannot prevent this 
situation. Upon POLLERR | POLLHUP my app closes all event devices and 
rescans the /dev/input directory, this should be enough imho? I don't 
know how the other apps handle unplugging.

Please CC:

Thanks.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

Re: event devices not released

[Dmitry Torokhov]

Hi Erik,

On Mon, Feb 11, 2008 at 01:47:41PM +0100, Erik Slagter wrote:
> Hi,
>
> I think I've found a bug :-/
>
> Symptoms: when I remove (unplug) a USB keyboard or mouse, the corresponding 
> event device seems to be closed but not released; when I plug the device 
> back in, it gets a new input device handle. This means that after several 
> suspend/resume cycles (in which it seems all usb devices are virtually 
> unplugged and replugged) the kernel is out of event devices and complains 
> likewise. My nice little program that catches specific keystrokes also 
> stops to get any interesting events from that moment on. After reboot 
> everything works again as expected.
>
> I've seen a similar bug report on linux-kernel but it wasn't followed up 
> on. Also this only mentioned problems through suspend cycles while I also 
> have the problem simply plugging in and out.
>
> Environment: linux kernel 2.6.24 vanilla on i386. The event files are held 
> open by one or more processes when the devices are unplugged. Unfortunatly 
> my program is not the only one that has them open, but hald and Xorg also 
> have some of the devices open, so I cannot prevent this situation. Upon 
> POLLERR | POLLHUP my app closes all event devices and rescans the 
> /dev/input directory, this should be enough imho? I don't know how the 
> other apps handle unplugging.
>

What happens if you kill HAL and X and leave only your application
running? Do event devices get released/reused in this case? Do you
see POLLERR or POLLHUP signals devlievered to your app?

-- 
Dmitry

Re: event devices not released

[Erik Slagter]

Dmitry Torokhov wrote:
> Hi Erik,

> On Mon, Feb 11, 2008 at 01:47:41PM +0100, Erik Slagter wrote:
>> Hi,

>> I think I've found a bug :-/

>> Symptoms: when I remove (unplug) a USB keyboard or mouse, the corresponding 
>> event device seems to be closed but not released; when I plug the device 
>> back in, it gets a new input device handle. This means that after several 
>> suspend/resume cycles (in which it seems all usb devices are virtually 
>> unplugged and replugged) the kernel is out of event devices and complains 
>> likewise. My nice little program that catches specific keystrokes also 
>> stops to get any interesting events from that moment on. After reboot 
>> everything works again as expected.

>> I've seen a similar bug report on linux-kernel but it wasn't followed up 
>> on. Also this only mentioned problems through suspend cycles while I also 
>> have the problem simply plugging in and out.

>> Environment: linux kernel 2.6.24 vanilla on i386. The event files are held 
>> open by one or more processes when the devices are unplugged. Unfortunatly 
>> my program is not the only one that has them open, but hald and Xorg also 
>> have some of the devices open, so I cannot prevent this situation. Upon 
>> POLLERR | POLLHUP my app closes all event devices and rescans the 
>> /dev/input directory, this should be enough imho? I don't know how the 
>> other apps handle unplugging.

> What happens if you kill HAL and X and leave only your application
> running? Do event devices get released/reused in this case? Do you
> see POLLERR or POLLHUP signals devlievered to your app?

So this is what I did, I rebooted the machine (to have a clean start), I 
  killed haldaemon (which unfortunately already had been started). X 
wasn't started yet. According to $(fuser) none of the event devices were 
in use. Then I pulled the USB cable out, that has my USB keyboard and 
mouse attached to it (via a hub of course) and plugged the cable back 
in. Dmesg now shows that the mouse and keyboard have had new event id's 
assigned. So it looks like the problem also manifests itself when the 
event devices are not open when the corresponding devices are removed.

I forgot to perform the other test with poll, and it's not so easy to 
perform, because I need to shutdown X for that and... without X I don't 
access to my mailbox :-/

It this enough information for you for the moment or do I need to do the 
poll test or do a check with "virgin" event devices (not been opened at 
all since boot time)?

BTW concerning my little app with the poll() call, poll works as 
expected, also after all event devices have been used up, it's just that 
no events are delivered for the devices that didn't get an event device 
assigned, if you get what I mean.

BTW2 problems with LCD-output switching using the keyboard (FN+F8 = 
CRT/LCD switch on my laptop) that used to work but doesn't anymore since 
2.6.23, is that also an "input" list issue or would I need to complain 
somewhere else ;-)

Re: event devices not released

[Jiri Kosina]

On Mon, 11 Feb 2008, Erik Slagter wrote:

> Symptoms: when I remove (unplug) a USB keyboard or mouse, the 
> corresponding event device seems to be closed but not released; when I 
> plug the device back in, it gets a new input device handle. This means 
> that after several suspend/resume cycles (in which it seems all usb 
> devices are virtually unplugged and replugged) the kernel is out of 
> event devices and complains likewise. My nice little program that 
> catches specific keystrokes also stops to get any interesting events 
> from that moment on. After reboot everything works again as expected.

Hi Erik,

this is very likely bug in HAL -- please see 
https://bugzilla.novell.com/show_bug.cgi?id=344872

-- 
Jiri Kosina

Re: event devices not released

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 998 bytes --]

Jiri Kosina wrote:
> On Mon, 11 Feb 2008, Erik Slagter wrote:
> 
>> Symptoms: when I remove (unplug) a USB keyboard or mouse, the 
>> corresponding event device seems to be closed but not released; when I 
>> plug the device back in, it gets a new input device handle. This means 
>> that after several suspend/resume cycles (in which it seems all usb 
>> devices are virtually unplugged and replugged) the kernel is out of 
>> event devices and complains likewise. My nice little program that 
>> catches specific keystrokes also stops to get any interesting events 
>> from that moment on. After reboot everything works again as expected.

> this is very likely bug in HAL -- please see 
> https://bugzilla.novell.com/show_bug.cgi?id=344872

Negative ;-)

A few moments ago I rebooted with HAL disabled and without going into X. 
I unplugged the hub that has the mouse and keyboard attached and plugged 
it back in again, a few times. Once again every time higher event 
handlers were assigned.


[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

Re: event devices not released

[Jiri Kosina]

On Tue, 12 Feb 2008, Erik Slagter wrote:

> > this is very likely bug in HAL -- please see
> > https://bugzilla.novell.com/show_bug.cgi?id=344872
> Negative ;-)
> A few moments ago I rebooted with HAL disabled and without going into X. I
> unplugged the hub that has the mouse and keyboard attached and plugged it back
> in again, a few times. Once again every time higher event handlers were
> assigned.

That is OK. But you shouldn't run into the situation when you run out of 
the free evdev devices.

-- 
Jiri Kosina

Re: event devices not released

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 929 bytes --]

Jiri Kosina wrote:
> On Tue, 12 Feb 2008, Erik Slagter wrote:
> 
>> Negative ;-)
>> A few moments ago I rebooted with HAL disabled and without going into X. I
>> unplugged the hub that has the mouse and keyboard attached and plugged it back
>> in again, a few times. Once again every time higher event handlers were
>> assigned.
> 
> That is OK. But you shouldn't run into the situation when you run out of 
> the free evdev devices.

I was under the impression that increasing event device handlers implied 
that it would run out of them eventually.

Are you saying that event handlers are normally ever increasing and that 
they are being reused when the upper limit has been reached?

In that case I'd probably best test this with a decreased EVDEV_MINORS 
value.

How is hald triggering the out-of-devices condition then? Do you mean 
that if the condition occurs, restarting hald would free up the 
"removed" event devices?

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]

Re: event devices not released

[Erik Slagter]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Jiri Kosina wrote:

> That is OK. But you shouldn't run into the situation when you run out of 
> the free evdev devices.

Seems indeed to be a misinterpretation on my side.

I add a few debug statements, and it seems that although the event 
device kernel name increases, they still reference the same event device 
slot(s). Also I don't get the "out of event devices" error now, even 
with hald running. I'll check shortly whether this also counts for 
suspend cycles.

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3315 bytes --]