Re: 2.6.36/2.6.37: broken compatibility with userspace input-utils ?

[Mauro Carvalho Chehab <mchehab@redhat.com>]

Em 27-01-2011 04:38, Dmitry Torokhov escreveu:
> On Wed, Jan 26, 2011 at 10:18:53PM -0500, Mark Lord wrote:
>> On 11-01-26 09:12 PM, Dmitry Torokhov wrote:
>>> On Wed, Jan 26, 2011 at 08:07:29PM -0500, Mark Lord wrote:
>>>> On 11-01-26 08:01 PM, Mark Lord wrote:
>>>>> On 11-01-26 10:05 AM, Mark Lord wrote:
>>>>>> On 11-01-25 09:00 PM, Dmitry Torokhov wrote:
>>>>> ..
>>>>>>> I wonder if the patch below is all that is needed...
>>>>>>
>>>>>> Nope. Does not work here:
>>>>>>
>>>>>> $ lsinput
>>>>>> protocol version mismatch (expected 65536, got 65537)
>>>>>>
>>>>>
>>>>> Heh.. I just noticed something *new* in the bootlogs on my system:
>>>>>
>>>>> kernel: Registered IR keymap rc-rc5-tv
>>>>> udevd-event[6438]: run_program: '/usr/bin/ir-keytable' abnormal exit
>>>>> kernel: input: i2c IR (Hauppauge) as /devices/virtual/rc/rc0/input7
>>>>> kernel: ir-keytable[6439]: segfault at 8 ip 00000000004012d2 sp 00007fff6d43ca60
>>>>> error 4 in ir-keytable[400000+7000]
>>>>> kernel: rc0: i2c IR (Hauppauge) as /devices/virtual/rc/rc0
>>>>> kernel: ir-kbd-i2c: i2c IR (Hauppauge) detected at i2c-0/0-0018/ir0 [ivtv i2c
>>>>> driver #0]
>>>>>
>>>>> That's udev invoking ir-keyboard when the ir-kbd-i2c kernel module is loaded,
>>>>> and that is also ir-keyboard (userspace) segfaulting when run.
>>>>
>>>> Note: I tried to capture an strace of ir-keyboard segfaulting during boot
>>>> (as above), but doing so kills the system (hangs on boot).
>>>>
>>>> The command from udev was: /usr/bin/ir-keytable -a /etc/rc_maps.cfg -s rc0
>>>
>>> Does it die when you try to invoke the command by hand? Can you see where?
>>
>>
>> No, it does not seem to segfault when I unload/reload ir-kbd-i2c
>> and then invoke it by hand with the same parameters.
>> Quite possibly the environment is different when udev invokes it,
>> and my strace attempt with udev killed the system, so no info there.
>>
>> It does NOT segfault on the stock 2.6.37 kernel, without the patch.
> 
> I must admit I am baffled. The patch in question only affects the
> EVIOCGKEYCODE path whereas '-a' means "automatically load appropriate
> keymap" and as far as I can see it does not call EVIOCGKEYCODE, only
> EVIOCSKEYCODE...
> 
> Mauro, any ideas?
> 
> BTW, I wonder what package ir-keytable is coming from? Ubuntu seems to
> have v4l-utils at 0.8.1-2 and you say yours is 0.8.2...

0.8.2 is the new version that was released in Jan, 25. One of the major
differences is that it now installs the udev rules, with make install.

This is there in order to prepare to the removal of all those in-kernel
Remote Controller tables.

On my tests here, this is working fine, with Fedora and RHEL 6, on my
usual test devices, so I don't believe that the tool itself is broken, 
nor I think that the issue is due to the fix patch.

I remember that when Kay added a persistence utility tool that opens a V4L
device in order to read some capabilities, this caused a race condition
into a number of drivers that use to register the video device too early.
The result is that udev were opening the device before the end of the
register process, causing OOPS and other problems.

I suspect that Mark may be experiencing a similar issue.

I don't think that most of the c/c will be able to help with this issue.
So, I think that the better is if Mark could either open a Buzgilla or
send me and linux-media the dmesg logs and other information that he may
have about what's happening. It would be interesting if he can remove the
udev rule, boot it and run the udev command manually, to see if this is
really a race condition or something else. If it fails manually, the
better is to activate ftrace logs for rc-core and for the driver functions
and send us the trace logs.

Thanks,
Mauro