Bug 85721 - IR Remote IMon stopped working without errors in log
Summary: IR Remote IMon stopped working without errors in log
Status: NEW
Alias: None
Product: v4l-dvb
Classification: Unclassified
Component: v4l-other (show other bugs)
Hardware: All Linux
: P1 high
Assignee: v4l-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-10-06 20:36 UTC by a_user
Modified: 2014-11-11 07:43 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.17.0
Tree: Mainline
Regression: Yes


Attachments
syslog (741.13 KB, text/plain)
2014-10-06 20:36 UTC, a_user
Details
Enable RC5-SZ decoding at rc5-decoder (958 bytes, patch)
2014-10-30 09:55 UTC, Mauro Carvalho Chehab
Details | Diff

Description a_user 2014-10-06 20:36:43 UTC
Created attachment 152691 [details]
syslog

While on kernel 3.16.x my iMon remote control is still working it doesn't on kernel 3.17.0. The device is correctly identified which is logged in syslog. Also lirc can connect etc. All log messages are absolutely identical to the working behavior on kernel 3.16.

But actually when trying to test it by using irw (or anything else) absolutely nothing happens, neither in log nor in the terminal is any reaction seen while pressing any of the keys on the remote control.

Rebooting to kernel 3.16 and it is working again.

Problem is 100% reproducable.

Note: The iMon Remote Control came together with my chieftec htpc case. It also has iMon Knobs on the front which are actually working even with kernel 3.17. Only the IR Remote isn't.

My wireless mouse/keyboard is also working fine.

I have attached my syslog of several reboots with 3.17 and 3.16.20 kernel on ubuntu 14.10. During that sessions i also tried stopping lirc and then using cat or irrecord etc. So you can see connection errors from vdr failing to connect to the lirc deamon/device.
Comment 1 a_user 2014-10-07 17:36:12 UTC
Bug is not present in newst mainline 3.16.4 kernel btw.
I'll try to find some time bisecting the 3.17.xx kernels if there is interest at all.
Comment 2 a_user 2014-10-17 15:57:15 UTC
Common, no one cares? Did i did something wrong?
Issue still present on 3.17.1.
Comment 3 Dmitry Torokhov 2014-10-17 16:39:24 UTC
I think iMon belongs to media (Mauro). Bisecting would help greatly. Please note that many people are traveling for LinuxCon/Plumbers/etc.
Comment 4 a_user 2014-10-18 11:30:33 UTC
Thank you very much for your answer.
I did bisect and the problem starts with 3.17.0 rc1. All 3.16.x kernels work fine and all 3.17 kernels have the problem.
Comment 5 Rod 2014-10-21 19:34:11 UTC
I have also experienced problems with my IR remote starting with 3.17-rc1 and continuing through 3.18-rc1, but my problems are with a streamzap remote that I use for MythTV. I'm not sure that the problems are related but the timeframes coincide.

I have noticed that /sys/class/rc/rc0/protocols isn't getting initialized properly in these kernel versions.

# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony rc-5-sz sanyo sharp mce_kbd lirc xmp

Since the only protocols that I have enabled are CONFIG_LIRC and CONFIG_IR_RC5_DECODER, they should be the only ones shown.
rc-5-sz (CONFIG_IR_RC5_SZ_DECODER) is obsolete starting with 3.17 but is still listed.

I noticed that in these versions, drivers/media/rc/rc-main.c contains the following structure which includes the obsolete rc-5-sz protocol:

static struct {
        u64     type;
        char    *name;
} proto_names[] = {
        { RC_BIT_NONE,          "none"          },
        { RC_BIT_OTHER,         "other"         },
        { RC_BIT_UNKNOWN,       "unknown"       },
        { RC_BIT_RC5 |
          RC_BIT_RC5X,          "rc-5"          },
        { RC_BIT_NEC,           "nec"           },
        { RC_BIT_RC6_0 |
          RC_BIT_RC6_6A_20 |
          RC_BIT_RC6_6A_24 |
          RC_BIT_RC6_6A_32 |
          RC_BIT_RC6_MCE,       "rc-6"          },
        { RC_BIT_JVC,           "jvc"           },
        { RC_BIT_SONY12 |
          RC_BIT_SONY15 |
          RC_BIT_SONY20,        "sony"          },
        { RC_BIT_RC5_SZ,        "rc-5-sz"       },
        { RC_BIT_SANYO,         "sanyo"         },
        { RC_BIT_SHARP,         "sharp"         },
        { RC_BIT_MCE_KBD,       "mce_kbd"       },
        { RC_BIT_LIRC,          "lirc"          },
        { RC_BIT_XMP,           "xmp"           },
};

I hope that this helps track down the issue.
Comment 6 Rod 2014-10-23 18:21:37 UTC
WARNING: I have almost zero kernel hacking experience! Everything below may be BS. I hope not. ;-)

I have finally been able to get my Streamzap remote working with 3.18-rc1 by fixing the proto_names structure in rc-main.c. I believe that this same fix should also work for 3.17 but I haven't tried it.

Since RC_BIT_RC5_SZ has been combined with the other RC5 protocols, the structure needs to be:

static struct {
        u64     type;
        char    *name;
} proto_names[] = {
        { RC_BIT_NONE,          "none"          },
        { RC_BIT_OTHER,         "other"         },
        { RC_BIT_UNKNOWN,       "unknown"       },
        { RC_BIT_RC5 |
          RC_BIT_RC5X|
          RC_BIT_RC5_SZ,        "rc-5"          },
        { RC_BIT_NEC,           "nec"           },
        { RC_BIT_RC6_0 |
          RC_BIT_RC6_6A_20 |
          RC_BIT_RC6_6A_24 |
          RC_BIT_RC6_6A_32 |
          RC_BIT_RC6_MCE,       "rc-6"          },
        { RC_BIT_JVC,           "jvc"           },
        { RC_BIT_SONY12 |
          RC_BIT_SONY15 |
          RC_BIT_SONY20,        "sony"          },
        { RC_BIT_SANYO,         "sanyo"         },
        { RC_BIT_SHARP,         "sharp"         },
        { RC_BIT_MCE_KBD,       "mce_kbd"       },
        { RC_BIT_LIRC,          "lirc"          },
        { RC_BIT_XMP,           "xmp"           },
};

Here's a patch:

# cat rc-proto_names.patch
--- a/drivers/media/rc/rc-main.c        2014-10-20 01:08:38.000000000 +0000
+++ b/drivers/media/rc/rc-main.c        2014-10-22 23:34:47.653144954 +0000
@@ -783,8 +783,9 @@
        { RC_BIT_NONE,          "none"          },
        { RC_BIT_OTHER,         "other"         },
        { RC_BIT_UNKNOWN,       "unknown"       },
-       { RC_BIT_RC5 |
-         RC_BIT_RC5X,          "rc-5"          },
+        { RC_BIT_RC5 |
+          RC_BIT_RC5X|
+         RC_BIT_RC5_SZ,        "rc-5"          },
        { RC_BIT_NEC,           "nec"           },
        { RC_BIT_RC6_0 |
          RC_BIT_RC6_6A_20 |
@@ -795,7 +796,6 @@
        { RC_BIT_SONY12 |
          RC_BIT_SONY15 |
          RC_BIT_SONY20,        "sony"          },
-       { RC_BIT_RC5_SZ,        "rc-5-sz"       },
        { RC_BIT_SANYO,         "sanyo"         },
        { RC_BIT_SHARP,         "sharp"         },
        { RC_BIT_MCE_KBD,       "mce_kbd"       },

## end patch

/sys/class/rc/rc0/protocols still doesn't get initialized properly and still shows all the protocols instead of just the ones that were actually included in the kernel, but rc-5-sz is now combined with rc-5 as it should be.

# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony sanyo sharp mce_kbd lirc xmp

But, since none of the protocols have been enabled by default, I needed one more hack to get things working.

# echo "rc-5" >/sys/class/rc/rc0/protocols

This enables the protocol needed by the Streamzap, as shown below.

# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony sanyo sharp mce_kbd lirc xmp

If /sys/class/rc/rc0/protocols was being initialized properly, it would show the following and the echo statement above wouldn't be necessary.

# cat /sys/class/rc/rc0/protocols (if working properly)
[rc-5] [lirc]

I'm looking at show_protocols() in drivers/media/rc/rc-main.c, but I haven't pinpointed the problem yet.
Comment 7 a_user 2014-10-23 23:13:03 UTC
Rod, thank you for your contribution. I hope some of the devs finally takes not of this issue.
Comment 8 Rod 2014-10-24 01:01:34 UTC
a_user, I'm not sure if I helped you or anyone else but I got mine working. This indicates that the merge of the rc-5-sz protocol with the other rc-5 protocols seems to be working, if only the implementation and configuration get completed.

Since you don't need the rc-5-sz protocol you shouldn't need to do the patch, just enable the protocol that you need:

# echo "protocol_name" >/sys/class/rc/rc0/protocols

You can find out which protocol(s) were enabled in 3.16 by booting into it and doing:

# cat /sys/class/rc/rc0/protocols

Whichever ones are in brackets are the enabled ones.

If you need to enable more than one, you can do:

# echo "protocol_1 +protocol_2 +protocol_3" >/sys/class/rc/rc0/protocols

I put the command in the startup file for lircd: /etc/init.d/lircd on gentoo. It can be removed when the initialization of /sys/class/rc/rc0/protocols gets fixed.
Comment 9 a_user 2014-10-24 09:12:46 UTC
i tried what yuo suggested. Indeed all but one protocol that are enabled on 3.16 are disabled if using any newer kernel. While the enabled and available protocols for rc0 are the same the protocols on rc1 differ. There only rc-5 is enabled on 3.17 or 3.18 kernel.

Like you suggested i enabled all missing protocols but the remote is still not working after that.

I tried stopping and enabling lirc again and still no reaction on irw command.

So i can confirm that since 3.17 the protocols are not being set but it seems that this is not all that is needed to getting iMon remote of my chieftec case working again. :(
Comment 10 Rod 2014-10-24 17:10:29 UTC
a_user, I can't help you with testing rc1 since I don't have one.

I guess we will just have to wait for someone who actually knows what they are doing to take notice.

zzzzzzzzzzzzzzzzzz
Comment 11 Mauro Carvalho Chehab 2014-10-24 22:51:04 UTC
There was a regression on 3.17 that affect LIRC users.

Patches with a proposed fix it were already submitted to linux-media@vger.kernel.org (where the Linux media discussions happen):
   https://patchwork.linuxtv.org/patch/26517/
   https://patchwork.linuxtv.org/patch/26516/

I'll be likely testing them next week.

Please test if applying those patches fix the issue for you.
Comment 12 a_user 2014-10-25 11:24:29 UTC
At the moment i can't compile the kernel to apply the patches and test them. I'll see if i can do this during next week though.
Comment 13 Rod 2014-10-26 22:18:55 UTC
I applied both patches shown above.

/sys/class/rc/rc0/protocols still isn't getting initialized properly.

I currently have only one protocol defined:

    <*>   Enable IR raw decoder for the RC-5 protocol

But /sys/class/rc/rc0/protocols still shows all protocols being allowed, with rc-5 and lirc being enabled.

# cat /sys/class/rc/rc0/protocols
other unknown [rc-5] nec rc-6 jvc sony sanyo sharp mce_kbd [lirc] xmp

This should only show rc-5 as both allowed and enabled, like:

# cat /sys/class/rc/rc0/protocols
[rc-5]

I still need to actually enable rc-5 before it will work:
# echo rc-5 >/sys/class/rc/rc0/protocols

Also, neither of these patches deals with changes to the proto_names structure (see above). This is needed for the rc-5-sz protocol to work now that it has been merged with the other rc-5 protocols.
Comment 14 Rod 2014-10-26 23:29:34 UTC
More diagnostics after patches:

I turned on debugging in rc-main.c

int rc_core_debug = 1;    /* ir_debug level (0,1,2) */

Now, the first time that show_protocols() is called, before I explicitly enable rc-5, the following is logged:

show_protocols: allowed - 0xfffff, enabled - 0x24

After it is explicitly enabled:

show_protocols: allowed - 0xfffff, enabled - 0x38

rc-5 should be the only one that is allowed or enabled in either case since my .config looks like this:

CONFIG_RC_DECODERS=y
# CONFIG_LIRC is not set
# CONFIG_IR_NEC_DECODER is not set
CONFIG_IR_RC5_DECODER=y
# CONFIG_IR_RC6_DECODER is not set
# CONFIG_IR_JVC_DECODER is not set
# CONFIG_IR_SONY_DECODER is not set
# CONFIG_IR_SANYO_DECODER is not set
# CONFIG_IR_SHARP_DECODER is not set
# CONFIG_IR_MCE_KBD_DECODER is not set
# CONFIG_IR_XMP_DECODER is not set
Comment 15 Mauro Carvalho Chehab 2014-10-29 10:05:31 UTC
(In reply to Mauro Carvalho Chehab from comment #11)
> There was a regression on 3.17 that affect LIRC users.
> 
> Patches with a proposed fix it were already submitted to
> linux-media@vger.kernel.org (where the Linux media discussions happen):
>    https://patchwork.linuxtv.org/patch/26517/
>    https://patchwork.linuxtv.org/patch/26516/
> 
> I'll be likely testing them next week.
> 
> Please test if applying those patches fix the issue for you.

The patch that was applied to fix for LIRC is this one:

http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b

So, at least on my knowledge, this should be enough to fix for LIRC.

(In reply to Rod from comment #13)
> Also, neither of these patches deals with changes to the proto_names
> structure (see above). This is needed for the rc-5-sz protocol to work now
> that it has been merged with the other rc-5 protocols.

This is actually a separate issue. 

What keytable are you using on your device? If it is this one:

drivers/media/rc/keymaps/rc-streamzap.c

It should work as-is, as the keytable is properly defined as:
                .rc_type = RC_TYPE_RC5_SZ,

We don't want to merge RC5_SZ with standard RC5, as this is non-standard.
That's why the patches didn't touch at the rc-main.c code you mentioned.

If you're otherwise using another keytable, then perhaps the .rc_type field
there is wrong.

Can you provide a full dmesg log with IR debug enabled?
Comment 16 Rod 2014-10-30 01:05:42 UTC
(In reply to Mauro Carvalho Chehab from comment #15)
> (In reply to Rod from comment #13)
> > Also, neither of these patches deals with changes to the proto_names
> > structure (see above). This is needed for the rc-5-sz protocol to work now
> > that it has been merged with the other rc-5 protocols.
> 
> This is actually a separate issue. 
> 

caveat: This is my first foray into kernel debugging and I have no expertise in this area, so if I'm in the wrong forum, violating procedures, or otherwise out-of-line feel free to slap me. But, since I got my remote working (and was feeling pretty smug) I thought that I might help diagnose the problem. I was probably just lucky anyway ;)

Mauro, I think that you are correct: these are separate issues, but I think that they are related.

> What keytable are you using on your device? If it is this one:
> 
> drivers/media/rc/keymaps/rc-streamzap.c
> 

yes

> It should work as-is, as the keytable is properly defined as:
>                 .rc_type = RC_TYPE_RC5_SZ,
> 
> We don't want to merge RC5_SZ with standard RC5, as this is non-standard.
> That's why the patches didn't touch at the rc-main.c code you mentioned.
> 

Just to be clear, I'm not proposing that RC5_SZ be merged, that was already done when ir-rc5-sz-decoder.c and CONFIG_IR_RC5_SZ_DECODER were removed from 3.17 and the logic was merged into ir-rc5-decoder.c

After looking at the modified ir-rc5-decoder.c in 3.17, I didn't see how it could work unless changes were made to the proto_names structure (see patch above). I tried it and it worked! Luck?

But I need to explicitly enable rc-5 on each boot by adding a line to the init file for lircd: echo "rc-5" >/sys/class/rc/rc0/protocols

I think that line is only required because of the initialization issue with /sys/class/rc/rc0/protocols, which seems related to the issue first mentioned by a_user and addressed by your patch.

> If you're otherwise using another keytable, then perhaps the .rc_type field
> there is wrong.
> 
> Can you provide a full dmesg log with IR debug enabled?

I'll do some more testing starting with 3.16.6 to try to pinpoint the regression and then provide the dmesg file uploads.

How do I post dmesg files without just pasting them into the text?

clue to problem?: Why would show_protocols: allowed ever be 0xfffff when .conf contains:

CONFIG_RC_DECODERS=y
# CONFIG_LIRC is not set
# CONFIG_IR_NEC_DECODER is not set
CONFIG_IR_RC5_DECODER=y
# CONFIG_IR_RC6_DECODER is not set
# CONFIG_IR_JVC_DECODER is not set
# CONFIG_IR_SONY_DECODER is not set
# CONFIG_IR_SANYO_DECODER is not set
# CONFIG_IR_SHARP_DECODER is not set
# CONFIG_IR_MCE_KBD_DECODER is not set
# CONFIG_IR_XMP_DECODER is not set
Comment 17 Mauro Carvalho Chehab 2014-10-30 09:50:42 UTC
(In reply to Rod from comment #16)

> > What keytable are you using on your device? If it is this one:
> > drivers/media/rc/keymaps/rc-streamzap.c
> yes

Ok. 

> > It should work as-is, as the keytable is properly defined as:
> >                 .rc_type = RC_TYPE_RC5_SZ,
> > 
> > We don't want to merge RC5_SZ with standard RC5, as this is non-standard.
> > That's why the patches didn't touch at the rc-main.c code you mentioned.
> > 
> 
> Just to be clear, I'm not proposing that RC5_SZ be merged, that was already
> done when ir-rc5-sz-decoder.c and CONFIG_IR_RC5_SZ_DECODER were removed from
> 3.17 and the logic was merged into ir-rc5-decoder.c

What it was merged there is the implementation for the decoder: just one
driver can handle both decodings. Yet, we want an explicit way to enable
RC5_SZ decoding.

> After looking at the modified ir-rc5-decoder.c in 3.17, I didn't see how it
> could work unless changes were made to the proto_names structure (see patch
> above).

Then the patch that merged SZ decoding on it is broken, as it should only
be enabling it if rc-5-sz is enabled.

I'll be submitting a fixup for you to test.

> How do I post dmesg files without just pasting them into the text?

No. Add it as an attachment.

> clue to problem?: Why would show_protocols: allowed ever be 0xfffff when
> .conf contains:

This seems to be another separate issue, if this is happening.

It should only show the protocols for the decoders that are loaded.
Comment 18 Mauro Carvalho Chehab 2014-10-30 09:55:46 UTC
Created attachment 155861 [details]
Enable RC5-SZ decoding at rc5-decoder
Comment 19 Rod 2014-10-30 13:00:26 UTC
(In reply to Mauro Carvalho Chehab from comment #18)
> Created attachment 155861 [details]
> Enable RC5-SZ decoding at rc5-decoder

Success! One issue down and one to go.

Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the problem with rc-5-sz, as long as I explicitly enable it with:

# echo "+rc-5-sz" >/sys/class/rc/rc0/protocols

To test the protocols initialization issue, which patches should I apply besides this one?
Comment 20 Mauro Carvalho Chehab 2014-10-30 13:11:39 UTC
(In reply to Rod from comment #19)
> (In reply to Mauro Carvalho Chehab from comment #18)
> > Created attachment 155861 [details]
> > Enable RC5-SZ decoding at rc5-decoder
> 
> Success! One issue down and one to go.
> 
> Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the
> problem with rc-5-sz, as long as I explicitly enable it with:
> 
> # echo "+rc-5-sz" >/sys/class/rc/rc0/protocols

This shouldn't be needed. Can you please post the value of 
   /sys/class/rc/rc0/protocols

after rebooting and before doing any changes on it?

> To test the protocols initialization issue, which patches should I apply
> besides this one?

You should also apply this one:
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b
Comment 21 Rod 2014-10-30 15:28:41 UTC
(In reply to Mauro Carvalho Chehab from comment #20)
> (In reply to Rod from comment #19)
> > (In reply to Mauro Carvalho Chehab from comment #18)
> > > Created attachment 155861 [details]
> > > Enable RC5-SZ decoding at rc5-decoder
> > 
> > Success! One issue down and one to go.
> > 
> > Using linux-3.18-rc2.tar.xz with the patch in this attachment fixed the
> > problem with rc-5-sz, as long as I explicitly enable it with:
> > 
> > # echo "+rc-5-sz" >/sys/class/rc/rc0/protocols
> 
> This shouldn't be needed. Can you please post the value of 
>    /sys/class/rc/rc0/protocols
> 
> after rebooting and before doing any changes on it?
> 

I expected this behavior since I had only applied the one patch; I only mentioned it for completeness. see below.

> > To test the protocols initialization issue, which patches should I apply
> > besides this one?
> 
> You should also apply this one:
> http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/
> ?h=fixes&id=472be605bec4bbcce0b9e403206e2e7c65afc50b

Now we're getting somewhere! Not perfect but much closer. Works.

using this config section:

CONFIG_RC_CORE=y
CONFIG_RC_MAP=y
CONFIG_RC_DECODERS=y
CONFIG_LIRC=m
# CONFIG_IR_LIRC_CODEC is not set
# CONFIG_IR_NEC_DECODER is not set
CONFIG_IR_RC5_DECODER=m
# CONFIG_IR_RC6_DECODER is not set
# CONFIG_IR_JVC_DECODER is not set
# CONFIG_IR_SONY_DECODER is not set
# CONFIG_IR_SANYO_DECODER is not set
CONFIG_IR_SHARP_DECODER=y
# CONFIG_IR_MCE_KBD_DECODER is not set
# CONFIG_IR_XMP_DECODER is not set

After applying the media_tree patch linked above, we get this initially:

# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony [rc-5-sz] sanyo sharp mce_kbd [lirc] xmp

dmesg contains:
    show_protocols: allowed - 0xfffff, enabled - 0x24

So the proper protocols are getting enabled initially but all the unavailable ones are still showing too.

You can even enable ones that aren't avaliable (oops):

# echo "+sanyo" >/sys/class/rc/rc0/protocols
# cat /sys/class/rc/rc0/protocols
other unknown rc-5 nec rc-6 jvc sony [rc-5-sz] [sanyo] sharp mce_kbd [lirc] xmp

Also, the init file for lircd (/etc/init.d/lircd on gentoo) contains the following snippet:

# start snippet
  for retval in ${LIRCD_SET_SYSCLASSRCS} ; do
          if [ -e /sys/class/rc/${retval}/protocols ] && \
          grep -qs 'lirc' /sys/class/rc/${retval}/protocols ; then
                  einfo "Setting lirc protocol active for ${retval}"
                  echo lirc >/sys/class/rc/${retval}/protocols
          fi
  done
# end snippet

The echo statement above leaves lirc enabled but turns off rc-5-sz.

I've commented this section out for testing because it shouldn't be needed with your new initialization process and it breaks things.
Comment 22 a_user 2014-11-11 07:43:23 UTC
My issue seems fixed with 3.18.0 rc4.

Thanks!

P.S. Should i mark it resolve or do you think there is still something to do?

Note You need to log in before you can comment on or make changes to this bug.