Hi Björn, On Sun, Oct 17, 2021 at 08:51:02AM +0200, Björn Wiberg wrote: > Package: src:linux > Version: 5.10.70-1 > Severity: minor > > Starting with inux-image-5.10.0-9-amd64, the ite_cir kernel module appears to > massively flood (approximately 80 log entries per second) syslog with > messages stating that a receive overflow has occurred: > > /../ > Oct 10 19:31:39 glimmer kernel: [ 3.758499] rc rc0: ITE8708 CIR > transceiver as /devices/virtual/rc/rc0 > Oct 10 19:31:39 glimmer kernel: [ 3.758557] rc rc0: lirc_dev: driver > ite-cir registered at minor = 0, raw IR receiver, raw IR transmitter > Oct 10 19:31:39 glimmer kernel: [ 3.758619] input: ITE8708 CIR transceiver > as /devices/virtual/rc/rc0/input3 > Oct 10 19:31:39 glimmer kernel: [ 3.760191] ite_cir: driver has been > successfully loaded > /../ > Oct 10 20:42:51 glimmer kernel: [ 4276.187105] rc rc0: receive overflow > Oct 10 20:42:51 glimmer kernel: [ 4276.195016] rc rc0: receive overflow > /../ (repeated receive overflow messages) > > This always occurs first after the system has been running for some time > (approximately 1½ hours). > > The logging of this condition appears to have been added to the source code > earlier this year: > https://lore.kernel.org/lkml/20210510102009.237644...@linuxfoundation.org/ > > It appears from the source code that some kind of reset is attempted, however > the outcome of this is unknown (and apparently does not succeed and/or solve > the receive overflow condition). > > The machine in question is located in a closet with no known IR sending from > other devices. > There are no known applications running that are using the input device > (/devices/virtual/rc/rc0/input3). > > Output from lsmod shows the following: > > root@glimmer:~# lsmod | grep -Ei '(ir_|_ir|rc_|_rc|ite)' | grep -v crc > ir_rc6_decoder 20480 0 > rc_rc6_mce 16384 0 > ite_cir 32768 0 > rc_core 61440 4 ite_cir,ir_rc6_decoder,rc_rc6_mce > > Possible work-arounds include blacklisting the ite_cir module (e.g. in > /etc/modprobe.d/local.conf): > blacklist ite_cir > > ...which would then disable the IR functionality altogether, or to > temporarily discard the log messages (e.g. in /etc/rsyslog.d/local.conf): > if $syslogfacility-text == 'kern' and $programname == 'kernel' and > re_match($msg, '\\] rc rc[^:]+: receive overflow$') and $syslogseverity >= 4 > then stop > > However this does not solve the underlying problem. > > I understand that the problem could potentially be because of "iffy" > hardware, but still wanted to report this, e.g. in case many others are > seeing the same thing on their systems.
I assume you get the same logged as well using newer kernel from unstable (or bullseye-backports, 5.14.9-2~bpo11+1, there are though not yet signed packages)? If so it might be best to ask upstream to rule out the iffy hardware part. Regards, Salvatore