When I upgraded to 2.6.14 from 2.6.14-rc5, my X server failed to stop.
Investigation revealed it was because my CorePointer was the Synaptics
driver, and the device corresponding to the Synaptics touchpad
(/dev/input/event2 on my laptop) was not being created. Once I manually
created the device with the proper major/minor device numbers, X started
correctly.
A comparison of "udevinfo -e" on 2.6.14-rc5 and 2.5.14 reveals the
following differences. Was this change deliberate? And can it be
reverted?
Thanks,
- Ted
--- udevinfo-2.6.14-rc5 2005-11-06 00:17:06.000000000 -0500
+++ udevinfo-2.6.14 2005-11-06 00:22:42.000000000 -0500
@@ -86,27 +86,15 @@
P: /class/cpuid/cpu0
N: cpu/0/cpuid
-P: /class/input/event0
-N: input/event0
-
-P: /class/input/event1
-N: input/event1
-
-P: /class/input/event2
-N: input/event2
-
-P: /class/input/event3
+P: /class/input/input3/event3
N: input/event3
+P: /class/input/input3/mouse1
+N: input/mouse1
+
P: /class/input/mice
N: input/mice
-P: /class/input/mouse0
-N: input/mouse0
-
-P: /class/input/mouse1
-N: input/mouse1
-
P: /class/misc/device-mapper
N: mapper/control
Theodore Ts'o napsal(a):
>When I upgraded to 2.6.14 from 2.6.14-rc5, my X server failed to stop.
>Investigation revealed it was because my CorePointer was the Synaptics
>driver, and the device corresponding to the Synaptics touchpad
>(/dev/input/event2 on my laptop) was not being created. Once I manually
>created the device with the proper major/minor device numbers, X started
>correctly.
>
>A comparison of "udevinfo -e" on 2.6.14-rc5 and 2.5.14 reveals the
>following differences. Was this change deliberate? And can it be
>reverted?
>
>Thanks,
>
> - Ted
>
>
>--- udevinfo-2.6.14-rc5 2005-11-06 00:17:06.000000000 -0500
>+++ udevinfo-2.6.14 2005-11-06 00:22:42.000000000 -0500
>@@ -86,27 +86,15 @@
> P: /class/cpuid/cpu0
> N: cpu/0/cpuid
>
>-P: /class/input/event0
>-N: input/event0
>-
>-P: /class/input/event1
>-N: input/event1
>-
>-P: /class/input/event2
>-N: input/event2
>-
>-P: /class/input/event3
>+P: /class/input/input3/event3
> N: input/event3
>
>+P: /class/input/input3/mouse1
>+N: input/mouse1
>+
> P: /class/input/mice
> N: input/mice
>
>-P: /class/input/mouse0
>-N: input/mouse0
>-
>-P: /class/input/mouse1
>-N: input/mouse1
>-
> P: /class/misc/device-mapper
> N: mapper/control
>
>
You should also write which version of udev do you use.
regards,
--
Jiri Slaby http://www.fi.muni.cz/~xslaby
\_.-^-._ [email protected] _.-^-._/
B67499670407CE62ACC8 22A032CC55C339D47A7E
On Sun, Nov 06, 2005 at 11:08:53AM +0100, Jiri Slaby wrote:
>
> >When I upgraded to 2.6.14 from 2.6.14-rc5, my X server failed to stop.
> >Investigation revealed it was because my CorePointer was the Synaptics
> >driver, and the device corresponding to the Synaptics touchpad
> >(/dev/input/event2 on my laptop) was not being created. Once I manually
> >created the device with the proper major/minor device numbers, X started
> >correctly.
> >
> >A comparison of "udevinfo -e" on 2.6.14-rc5 and 2.5.14 reveals the
> >following differences. Was this change deliberate? And can it be
> >reverted?
>
> You should also write which version of udev do you use.
Oh, of course. Version 0.071-1, from Debian unstable.
- Ted
On Sun, Nov 06, 2005 at 12:47:02AM -0500, Theodore Ts'o wrote:
>
> When I upgraded to 2.6.14 from 2.6.14-rc5, my X server failed to stop.
> Investigation revealed it was because my CorePointer was the Synaptics
> driver, and the device corresponding to the Synaptics touchpad
> (/dev/input/event2 on my laptop) was not being created. Once I manually
> created the device with the proper major/minor device numbers, X started
> correctly.
>
> A comparison of "udevinfo -e" on 2.6.14-rc5 and 2.5.14 reveals the
> following differences. Was this change deliberate? And can it be
> reverted?
>
> --- udevinfo-2.6.14-rc5 2005-11-06 00:17:06.000000000 -0500
> +++ udevinfo-2.6.14 2005-11-06 00:22:42.000000000 -0500
> @@ -86,27 +86,15 @@
> P: /class/cpuid/cpu0
> N: cpu/0/cpuid
>
> -P: /class/input/event0
> -N: input/event0
> -
> -P: /class/input/event1
> -N: input/event1
> -
> -P: /class/input/event2
> -N: input/event2
> -
> -P: /class/input/event3
> +P: /class/input/input3/event3
> N: input/event3
>
> +P: /class/input/input3/mouse1
> +N: input/mouse1
> +
> P: /class/input/mice
> N: input/mice
>
> -P: /class/input/mouse0
> -N: input/mouse0
> -
> -P: /class/input/mouse1
> -N: input/mouse1
> -
> P: /class/misc/device-mapper
> N: mapper/control
The change in the path in udevinfo is correct with that kernel, but it
seems, that you miss some devices.
What does:
find /sys/class/input
print?
What does:
ls -l /dev/input
print?
Are the same modules loaded after bootup?
If the devices show up in /sys/class/input, but not in /dev/input,
does running:
/sbin/udevstart
create them?
Thanks,
Kay
On Sun, Nov 06, 2005 at 12:47:02AM -0500, Theodore Ts'o wrote:
> +P: /class/input/input3/event3
No, this shows a post-2.6.14 kernel, not 2.6.14 as what is located on
kernel.org, right? I'm guessing 2.6.14-git1? Or is this a distro based
kernel?
If so, you need to upgrade udev, as the Documentation says to :)
If not, and this is 2.6.14, something is very wrong...
thanks,
greg k-h
On Sun, Nov 06, 2005 at 12:34:21PM -0800, Greg KH wrote:
> On Sun, Nov 06, 2005 at 12:47:02AM -0500, Theodore Ts'o wrote:
> > +P: /class/input/input3/event3
>
> No, this shows a post-2.6.14 kernel, not 2.6.14 as what is located on
> kernel.org, right? I'm guessing 2.6.14-git1? Or is this a distro based
> kernel?
>
> If so, you need to upgrade udev, as the Documentation says to :)
>
> If not, and this is 2.6.14, something is very wrong...
Yes, sorry, I got confused about which tree I had booting; this was
indeed a post-2.6.14 kernel (pulled using hg).
Documentation/changes at the tip as of tonight still says use "udev
version 071", which is what I have installed. I note that the latest
version on kernel.org is udev 072 --- is that what is going to be
required for 2.6.15? If so, better warn folks at distro's like Debian
unstable. If not, what do I need to change so I can easily test post
2.6.14 kernels --- and where was it documented that I needed a newer
version of udev?
- Ted
On Mon, Nov 07, 2005 at 12:36:49AM -0500, Theodore Ts'o wrote:
> On Sun, Nov 06, 2005 at 12:34:21PM -0800, Greg KH wrote:
> > On Sun, Nov 06, 2005 at 12:47:02AM -0500, Theodore Ts'o wrote:
> > > +P: /class/input/input3/event3
> >
> > No, this shows a post-2.6.14 kernel, not 2.6.14 as what is located on
> > kernel.org, right? I'm guessing 2.6.14-git1? Or is this a distro based
> > kernel?
> >
> > If so, you need to upgrade udev, as the Documentation says to :)
> >
> > If not, and this is 2.6.14, something is very wrong...
>
> Yes, sorry, I got confused about which tree I had booting; this was
> indeed a post-2.6.14 kernel (pulled using hg).
Ah good, scared me for a bit there :)
> Documentation/changes at the tip as of tonight still says use "udev
> version 071", which is what I have installed.
Which should handle this just fine. I suggest you file a bug against
the debian package if this is not the case.
> I note that the latest version on kernel.org is udev 072 --- is that
> what is going to be required for 2.6.15?
Actually 073 is now out :)
Anyway, no, I do not think that it will be required for 2.6.15, unless
something is found really wrong with 071 and that kernel.
> If so, better warn folks at distro's like Debian unstable.
072 is already availble in unstable.
> If not, what do I need to change so I can easily test post 2.6.14
> kernels --- and where was it documented that I needed a newer version
> of udev?
071 should be fine, as documented. Works for me here :)
thanks,
greg k-h
On Mon, Nov 07, 2005 at 07:52:43AM -0800, Greg KH wrote:
> > Yes, sorry, I got confused about which tree I had booting; this was
> > indeed a post-2.6.14 kernel (pulled using hg).
>
> Ah good, scared me for a bit there :)
>
> > Documentation/changes at the tip as of tonight still says use "udev
> > version 071", which is what I have installed.
>
> Which should handle this just fine. I suggest you file a bug against
> the debian package if this is not the case.
Ok, I'll gather more information but I was indeed using udev 0.71 from
Debian with a post 2.6.14 kernel, and it wasn't working for me. I can
try again with stock udev from kernel.org, if you like, once I verify
that the Debian package hasn't changed anything critical which is
required for correct operation on Debian systems.
- Ted
On Mon, Nov 07, 2005 at 01:17:06PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 07, 2005 at 07:52:43AM -0800, Greg KH wrote:
> > > Yes, sorry, I got confused about which tree I had booting; this was
> > > indeed a post-2.6.14 kernel (pulled using hg).
> >
> > Ah good, scared me for a bit there :)
> >
> > > Documentation/changes at the tip as of tonight still says use "udev
> > > version 071", which is what I have installed.
> >
> > Which should handle this just fine. I suggest you file a bug against
> > the debian package if this is not the case.
>
> Ok, I'll gather more information but I was indeed using udev 0.71
Minor nit, udev does not use "." in its version numbers :)
> from Debian with a post 2.6.14 kernel, and it wasn't working for me.
I see that 073 is in unstable, which fixed a lot of problems with 071,
072 and 073 due to Debian configuration issues. I suggest you try that.
> I can try again with stock udev from kernel.org,
No, stick with the debian packages, due to the wierd packaging and init
issues that Debian has.
I wouldn't recommend using the kernel.org udev packages for anyone on
their own these days, they are what the distros use to package from, and
they know best, due to the different ways the init process works in
different distros.
Good luck,
greg k-h
On Mon, Nov 07, 2005 at 10:24:34AM -0800, Greg KH wrote:
> > from Debian with a post 2.6.14 kernel, and it wasn't working for me.
>
> I see that 073 is in unstable, which fixed a lot of problems with 071,
> 072 and 073 due to Debian configuration issues. I suggest you try that.
I've just tried udev 073 from Debian unstable, with a freshly pulled
kernel 2.6.14 from earlier in the evening on 11/7. Same failure:
/dev/input only has /dev/input/event3, and is missing the event0, event1,
and event2 files that is present if I boot 2.6.14.
So is this a Debian bug, a kernel bug, or a udev bug? What is going
on? I don't know enough about recent changes to udev and/or the
events sent to udev to start debugging this, but this is something
that works in 2.6.14 and fails post-2.6.14....
So this is what I believe Andrew would call "a regression". :-)
- Ted
On Mon, Nov 07, 2005 at 10:30:19PM -0500, Theodore Ts'o wrote:
> On Mon, Nov 07, 2005 at 10:24:34AM -0800, Greg KH wrote:
> > > from Debian with a post 2.6.14 kernel, and it wasn't working for me.
> >
> > I see that 073 is in unstable, which fixed a lot of problems with 071,
> > 072 and 073 due to Debian configuration issues. I suggest you try that.
>
> I've just tried udev 073 from Debian unstable, with a freshly pulled
> kernel 2.6.14 from earlier in the evening on 11/7. Same failure:
>
> /dev/input only has /dev/input/event3, and is missing the event0, event1,
> and event2 files that is present if I boot 2.6.14.
>
> So is this a Debian bug, a kernel bug, or a udev bug?
Debian bug, as this version of udev, and kernel, running on a different
distro, works just fine for me here :)
> What is going on? I don't know enough about recent changes to udev
> and/or the events sent to udev to start debugging this, but this is
> something that works in 2.6.14 and fails post-2.6.14....
The input subsystem moved to handle nested class devices, so udev had to
change to handle this properly. I bet however Debian does the initial
population of the /dev tree is messed up somehow, as that is what it
looks like is happening (event3 I bet is from a USB device that is added
after init starts?)
> So this is what I believe Andrew would call "a regression". :-)
I call it a "Debian mess"...
Good luck,
greg k-h
On Mon, Nov 07, 2005 at 08:43:49PM -0800, Greg KH wrote:
>
> The input subsystem moved to handle nested class devices, so udev had to
> change to handle this properly. I bet however Debian does the initial
> population of the /dev tree is messed up somehow, as that is what it
> looks like is happening (event3 I bet is from a USB device that is added
> after init starts?)
>
Nope, it looks like there's some sort of layering/nesting going on:
% cat /sys/class/input/event1/device/description
i8042 Kbd Port
% cat /sys/class/input/event2/device/description
i8042 Aux Port
% cat /sys/class/input/event3/device/description
Synaptics pass-through
.. and the Synaptics driver wants to talk to /dev/input/event2, and
_not_ /dev/input/event3. But the Debian scripts seem to think that
the only thing of value to expose is the /dev/input/event3, the very
top of the stack. /dev/input/event1, and /dev/input/event2 are both
not showing up on my system once a I boot a post-2.6.14 kernel.
> > So this is what I believe Andrew would call "a regression". :-)
>
> I call it a "Debian mess"...
>
Great.... I'll file a bug report to Debian, and hopefully they can
get this mess straightened out before 2.6.15 (and hopefully before
2.6.14-rc1) ships.
- Ted
On Tue, Nov 08, 2005 at 08:14:51AM -0500, Theodore Ts'o wrote:
> On Mon, Nov 07, 2005 at 08:43:49PM -0800, Greg KH wrote:
> >
> > The input subsystem moved to handle nested class devices, so udev had to
> > change to handle this properly. I bet however Debian does the initial
> > population of the /dev tree is messed up somehow, as that is what it
> > looks like is happening (event3 I bet is from a USB device that is added
> > after init starts?)
> >
>
> Nope, it looks like there's some sort of layering/nesting going on:
>
> % cat /sys/class/input/event1/device/description
> i8042 Kbd Port
>
> % cat /sys/class/input/event2/device/description
> i8042 Aux Port
>
> % cat /sys/class/input/event3/device/description
> Synaptics pass-through
>
> .. and the Synaptics driver wants to talk to /dev/input/event2, and
> _not_ /dev/input/event3. But the Debian scripts seem to think that
> the only thing of value to expose is the /dev/input/event3, the very
> top of the stack. /dev/input/event1, and /dev/input/event2 are both
> not showing up on my system once a I boot a post-2.6.14 kernel.
Is there a "dev" file in /sys/class/input/event1/ and
/sys/class/input/event2/ ? That should be all the udev cares about.
thanks,
greg k-h
On Nov 08, Theodore Ts'o <[email protected]> wrote:
> .. and the Synaptics driver wants to talk to /dev/input/event2, and
> _not_ /dev/input/event3. But the Debian scripts seem to think that
> the only thing of value to expose is the /dev/input/event3, the very
> top of the stack. /dev/input/event1, and /dev/input/event2 are both
> not showing up on my system once a I boot a post-2.6.14 kernel.
Yes, sure. The current Debian package uses udevsynthesize, which knows
nothing about what happened post-2.6.14 in sysfs.
> Great.... I'll file a bug report to Debian, and hopefully they can
> get this mess straightened out before 2.6.15 (and hopefully before
> 2.6.14-rc1) ships.
Not unless you will send me a tested patch for the init script, since I
do not run rc kernels myself.
(Or at least you will help me with some testing.)
--
ciao,
Marco
On Tue, Nov 08, 2005 at 10:52:09PM +0100, Marco d'Itri wrote:
> On Nov 08, Theodore Ts'o <[email protected]> wrote:
>
> > .. and the Synaptics driver wants to talk to /dev/input/event2, and
> > _not_ /dev/input/event3. But the Debian scripts seem to think that
> > the only thing of value to expose is the /dev/input/event3, the very
> > top of the stack. /dev/input/event1, and /dev/input/event2 are both
> > not showing up on my system once a I boot a post-2.6.14 kernel.
> Yes, sure. The current Debian package uses udevsynthesize, which knows
> nothing about what happened post-2.6.14 in sysfs.
Ugh, you don't use 'udevstart'? Oh well...
Ted, this is a distro issue, not a kernel one. Marco, you are going to
get a lot of error reports about this once 2.6.15-rc1 is out...
Good luck,
greg k-h
> Ugh, you don't use 'udevstart'? Oh well...
debian uses a highly patched udevstart and calls it udevsyntesize.
needed some time to figure that out when chasing failures of ubuntu's
initramfs-tools which in debian use the newer udevsyntesize.
the patches can be seen at:
http://ftp.debian.org/debian/pool/main/u/udev/udev_0.071-1.diff.gz
but more easily if you apply that to the unpacked
http://ftp.debian.org/debian/pool/main/u/udev/udev_0.071.orig.tar.gz
--
maks
ps sorry if i trimmed cc, just stepping in and trying to reconstruct
from previous postings.