Menu
▾
▴
linuxconsole-dev
|
From: Johann D. <jo...@Do...> - 2002-01-28 20:58:48
|
Hi, When I turn off my I-Force wheel while a process having opened its /dev/input/eventX entry is still running, strange things happen. I made trials with evtest and fftest. Both crash. They either crash immediately, on exit or when I press a key on my keyboard. Other strange behaviours are mouse clicks being uneffective, the wm unwilling to change focus (I use sloppy focus). The pointer of the mouse goes on moving, however. All this happens with a patched 2.4.17 kernel (with my input-only patch). I will try to see what happens with the latest CVS version as soon as I can get it working. Anyway, I think there should be a test on evdev->exist in every entry function (evdev_read, ioctl, write, release, flush ...). Adding these tests did not solve the problem, though. Can someone try to reproduce the bug with another USB device ? (Advice: sync your disks before! The crash is actually a complete freeze) -- Johann Deneux |
|
From: Vojtech P. <vo...@su...> - 2002-01-28 23:23:20
|
On Mon, Jan 28, 2002 at 09:58:39PM +0100, Johann Deneux wrote: > Hi, > > When I turn off my I-Force wheel while a process having opened its > /dev/input/eventX entry is still running, strange things happen. I made > trials with evtest and fftest. Both crash. They either crash immediately, > on exit or when I press a key on my keyboard. Other strange behaviours are > mouse clicks being uneffective, the wm unwilling to change focus (I use > sloppy focus). The pointer of the mouse goes on moving, however. > All this happens with a patched 2.4.17 kernel (with my input-only > patch). I will try to see what happens with the latest CVS version as soon > as I can get it working. Just use 2.5.2-dj6, it's all there ... > Anyway, I think there should be a test on evdev->exist in every entry > function (evdev_read, ioctl, write, release, flush ...). Adding these > tests did not solve the problem, though. That shouldn't be needed. The structs associated are freed only after the file descriptor is closed. > Can someone try to reproduce the bug with another USB device ? > (Advice: sync your disks before! The crash is actually a complete freeze) It works for me. Evtest just reports: evtest: error reading: No such device and exits just OK. -- Vojtech Pavlik SuSE Labs |
|
From: Johann D. <jo...@Do...> - 2002-01-29 18:35:56
|
On Tue, 29 Jan 2002, Vojtech Pavlik wrote: > On Mon, Jan 28, 2002 at 09:58:39PM +0100, Johann Deneux wrote: > > Hi, > > > > When I turn off my I-Force wheel while a process having opened its > > /dev/input/eventX entry is still running, strange things happen. I made > > trials with evtest and fftest. Both crash. They either crash immediately, > > on exit or when I press a key on my keyboard. Other strange behaviours are > > mouse clicks being uneffective, the wm unwilling to change focus (I use > > sloppy focus). The pointer of the mouse goes on moving, however. > > All this happens with a patched 2.4.17 kernel (with my input-only > > patch). I will try to see what happens with the latest CVS version as soon > > as I can get it working. > > Just use 2.5.2-dj6, it's all there ... After sending the mail yesterday, I fetched the dj6 patch. I see a few differences here and there (do_gettimeofday instead of get_fast_time, for example). Perhaps it would be a good idea to keep the tree in sync with dave jones' tree (instead of linus' one). This will have the side effect that the work of dave will become easier, as we commit back the changes he did. If I understand the plans, linuxconsole is going to go through dave's tree before getting to linus anyway, or ? > > > Anyway, I think there should be a test on evdev->exist in every entry > > function (evdev_read, ioctl, write, release, flush ...). Adding these > > tests did not solve the problem, though. > > That shouldn't be needed. The structs associated are freed only after > the file descriptor is closed. Yes, but some input_* functions may be called. Depending on how input.c is coded, that could be ok, but I have no idea right now. Let's have a look. Imagine a process tries to send events to a non-existing device. It writes to the dev entry. evdev_write is called, which calls input_event. Is the struct input_dev *dev parameter correct ? In the case of hid, it seems ok, as the hid pointer in hid_disconnect isn not kfreed (isn't that a memory leak ?). In iforce, it is, which most certainly causes problems. I see another possible problem. After a usb disconnect, the usb_device is "closed" by the usb system. Is it ok then to unregister it (again ?) in hid_exit ? -- Johann Deneux |
|
From: Johann D. <jo...@Do...> - 2002-01-29 20:55:27
|
On Tue, 29 Jan 2002, Johann Deneux wrote: > I see another possible problem. After a usb disconnect, the usb_device is > "closed" by the usb system. Is it ok then to unregister it (again ?) in > hid_exit ? This one is OK. I've just mistaken "unregistering a device" and "unregistering a driver". -- Johann Deneux |
|
From: James S. <jsi...@tr...> - 2002-01-30 00:53:57
|
> > All this happens with a patched 2.4.17 kernel (with my input-only > > patch). I will try to see what happens with the latest CVS version as soon > > as I can get it working. > > Just use 2.5.2-dj6, it's all there ... Hm. Prehaps we should put the ruby tree against the dj tree? |
|
From: Vojtech P. <vo...@su...> - 2002-01-30 01:06:56
|
On Tue, Jan 29, 2002 at 04:53:42PM -0800, James Simmons wrote: > > > > All this happens with a patched 2.4.17 kernel (with my input-only > > > patch). I will try to see what happens with the latest CVS version as soon > > > as I can get it working. > > > > Just use 2.5.2-dj6, it's all there ... > > Hm. Prehaps we should put the ruby tree against the dj tree? I really hope to start merging to Linus soon, now that the bugs found in the i8042/atkbd combination in Dave's kernel are fixed. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2002-01-30 18:16:46
|
> > > > All this happens with a patched 2.4.17 kernel (with my input-only > > > > patch). I will try to see what happens with the latest CVS version as soon > > > > as I can get it working. > > > > > > Just use 2.5.2-dj6, it's all there ... > > > > Hm. Prehaps we should put the ruby tree against the dj tree? > > I really hope to start merging to Linus soon, now that the bugs found in > the i8042/atkbd combination in Dave's kernel are fixed. Great!! Have those fixes made it back into CVS yet. Also I like the i8042 drivers have thier IRQ and IO regions configurable via Config.in. The reason being is on many platforms it various. I hate to see a ton of #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ. |
|
From: Vojtech P. <vo...@su...> - 2002-01-30 18:27:27
|
On Wed, Jan 30, 2002 at 10:16:23AM -0800, James Simmons wrote: > > > > > All this happens with a patched 2.4.17 kernel (with my input-only > > > > > patch). I will try to see what happens with the latest CVS version as soon > > > > > as I can get it working. > > > > > > > > Just use 2.5.2-dj6, it's all there ... > > > > > > Hm. Prehaps we should put the ruby tree against the dj tree? > > > > I really hope to start merging to Linus soon, now that the bugs found in > > the i8042/atkbd combination in Dave's kernel are fixed. > > Great!! Have those fixes made it back into CVS yet. Yes. > Also I like the i8042 > drivers have thier IRQ and IO regions configurable via Config.in. No problem with that. > The > reason being is on many platforms it various. I hate to see a ton of > #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ. Go ahead. It'd be nice if the config automatically selected the defaults based on the architecture, too. (Possibly it wouldn't even need to ask). -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2002-01-30 18:31:27
|
> > Also I like the i8042 > > drivers have thier IRQ and IO regions configurable via Config.in. > > No problem with that. > > > The > > reason being is on many platforms it various. I hate to see a ton of > > #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ. > > Go ahead. It'd be nice if the config automatically selected the defaults > based on the architecture, too. (Possibly it wouldn't even need to ask). The MIPS platform has a habit of doing that. Look at arch/mips/config.in and you will see all the if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then define_bool .. define_tristate ... ... fi The region for the PS/2 registers various from mips device to mips device!!! So with setups like mips the defaults will show up automatically. |
|
From: Vojtech P. <vo...@su...> - 2002-01-30 18:32:24
|
On Wed, Jan 30, 2002 at 10:31:06AM -0800, James Simmons wrote: > > > > Also I like the i8042 > > > drivers have thier IRQ and IO regions configurable via Config.in. > > > > No problem with that. > > > > > The > > > reason being is on many platforms it various. I hate to see a ton of > > > #ifdef in i8042.h. Is that okay? If so I can wipe up a patch for DJ. > > > > Go ahead. It'd be nice if the config automatically selected the defaults > > based on the architecture, too. (Possibly it wouldn't even need to ask). > > The MIPS platform has a habit of doing that. Look at arch/mips/config.in > and you will see all the > > if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then > define_bool .. > define_tristate ... > ... > fi > > The region for the PS/2 registers various from mips device to mips > device!!! So with setups like mips the defaults will show up > automatically. Good. I's suggest the same with other archs. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@tr...> - 2002-01-30 18:33:52
|
> > > Go ahead. It'd be nice if the config automatically selected the defaults > > > based on the architecture, too. (Possibly it wouldn't even need to ask). > > > > The MIPS platform has a habit of doing that. Look at arch/mips/config.in > > and you will see all the > > > > if [ "$CONFIG_MIPS_BLAHBLAH" = "y" ]; then > > define_bool .. > > define_tristate ... > > ... > > fi > > > > The region for the PS/2 registers various from mips device to mips > > device!!! So with setups like mips the defaults will show up > > automatically. > > Good. I's suggest the same with other archs. Agree. Will make patch. |
|
From: Johann D. <jo...@Do...> - 2002-01-30 23:10:05
|
On Tue, 29 Jan 2002, Vojtech Pavlik wrote: > > Can someone try to reproduce the bug with another USB device ? > > (Advice: sync your disks before! The crash is actually a complete freeze) > > It works for me. Evtest just reports: > > evtest: error reading: No such device > > and exits just OK. > With my latest changes to iforce, that's now what I get. However, I keep getting crashes when or shortly after reconnecting the device :( -- Johann Deneux |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X