Dear all,

whenever I do a suspend resume cycle the input device's numbers are
increased until I finally run out of evdev devices. Is this a kernel
problem or some userspace program (udev/...) creating new devices all
the time?

here is the dmesg:

Soeren

input: Power Button (FF) as /devices/virtual/input/input0
input: Lid Switch as /devices/virtual/input/input1
input: Power Button (CM) as /devices/virtual/input/input2
input: Sleep Button (CM) as /devices/virtual/input/input3
input: Macintosh mouse button emulation as /devices/virtual/input/input4
input: Apple Computer Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input5
input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / Trackpad] on usb-0000:00:1d.0-2
input: Apple Computer Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.2/input/input6
input: USB HID v1.11 Device [Apple Computer Apple Internal Keyboard / Trackpad] on usb-0000:00:1d.0-2
input: HID 05ac:1000 as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input7
input: USB HID v1.11 Keyboard [HID 05ac:1000] on usb-0000:00:1d.3-1
input: HID 05ac:1000 as /devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.1/input/input8
input: USB HID v1.11 Mouse [HID 05ac:1000] on usb-0000:00:1d.3-1
input: appletouch as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.1/input/input9
input: Video Bus as /devices/virtual/input/input10
input: applesmc as /devices/platform/applesmc.768/input/input11
input: appletouch disconnected
input: Apple Computer Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.0/input/input12
input: USB HID v1.11 Keyboard [Apple Computer Apple Internal Keyboard / Trackpad] on usb-0000:00:1d.0-2
input: appletouch as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.1/input/input13
input: Apple Computer Apple Internal Keyboard / Trackpad as /devices/pci0000:00/0000:00:1d.0/usb2/2-2/2-2:1.2/input/input14
input: USB HID v1.11 Device ...
[ message continues ]

Did earlier kernels do the same thing, or was this problem introduced in
2.6.23?

-

[ message continues ]

evdev marks the device slot as free as soon as evdev_disconnect is
called which shoudl be called from input_unregister_device().

Could you please try sticking a printk in
hidinput_disconnect(drivers/hid/hid-input.c) to verify that
input_unregister_device is in fact being called?

-- 
Dmitry
-

[ message continues ]

Also, is 2.6.23 the only kernel you are experiencing this with please?

Thanks,

-- 
Jiri Kosina
-

[ message continues ]

So far yes. I am now on 2.6.24rc2 and although the input device numbers
steadily increase s2ram does reliably work even when done >10 times in a
row and no problems with evdev devices not being available.

However resume is slower as some ata device (I think my cdrom) is timing
out. So it could be related to a too fast resume from suspend.

So the problem may re-appear if matthew garrets fix for
[PATCH] Don't fail ata device revalidation for bad _GTF methods

will be committed.

Is there still a need to do tests with the printk's in 2.6.23?

Soeren
-

[ message continues ]