Description of problem: After upgrade from FC13, serial IR blaster no longer working. PVR350 IR input still works. Version-Release number of selected component (if applicable): lirc-0.8.7-1.fc14.i686 lirc-libs-0.8.7-1.fc14.i686 Running on : 2.6.35.6-48.fc14.i686 How reproducible: Hasn't worked since upgrade. Steps to Reproduce: 1. Using same setup / scripts as before, serial lamp does not flash when channel changes are sent. Actual results: Using same setup / scripts as before, serial lamp does not flash when channel changes are sent. Expected results: No different from FC13 (and Fedora all the way back to ~3) Additional info: ------------- /etc/modprobe.d/lird.conf -------- # This is for the PVR350 IR receiver alias char-major-61-0 lirc_i2c install lirc_i2c /sbin/modprobe ivtv; /sbin/modprobe --ignore-install lirc_i2c # This is for the InfraRed on the Serial Port COM1 alias char-major-61-1 lirc_serial install lirc_serial /bin/setserial /dev/ttyS0 uart none ; /sbin/modprobe --ignore-install lirc_serial options lirc_serial irq=4 io=0x3f8 ------------- /etc/rc.local -------- /sbin/modprobe lirc_i2c /sbin/modprobe lirc_serial # This will be the lirc_i2c (hauppauge receiver = INPUT) /usr/sbin/lircd --device=/dev/lirc0 --output=/dev/lirc_o0 # This will be the COM1 device (blaster = OUTPUT) /usr/sbin/lircd --device=/dev/lirc1 --output=/dev/lirc_o1 --driver=default --pidfile=/var/run/lirc_serial.pid chmod 0666 /dev/lirc0 chmod 0666 /dev/lirc1 ------------- Change Channel (called repeatedly for each digit) -------- irsend --device=/dev/lirc_o1 SEND_ONCE SA2000 1 ------------- tail /var/log/messages : -------- Nov 30 14:14:29 myth lircd-0.8.7[2794]: accepted new client on /dev/lirc_o1 Nov 30 14:14:29 myth lircd-0.8.7[2794]: removed client ------------- dmesg | grep lirc : -------- [ 42.621641] lirc_dev: IR Remote Control driver registered, major 250 [ 42.778207] lirc_i2c: module is from the staging directory, the quality is unknown, you have been warned. [ 42.785734] lirc_i2c: chip 0x0 found @ 0x18 (Hauppauge IR) [ 42.803287] i2c ir driver 3-0018: lirc_dev: driver lirc_i2c registered at minor = 0 [ 42.903906] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned. [ 43.779026] lirc_serial: auto-detected active high receiver [ 43.779202] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 1
Hrm. Interesting setup, several things that aren't valid or necessary, but it should certainly still work... Can you try the latest kernel headed to updates-testing (2.6.35.10-72 or later)? If its still broken, I'll have to dig out the serial transmitter I've got around here somewhere and investigate. (I know serial receive works, just checked on that yesterday).
Ok, I got the kernel by installing it from 'http://koji.fedoraproject.org/koji/buildinfo?buildID=210666' : yum --nogpgcheck install http://kojipkgs.fedoraproject.org/packages/kernel/2.6.35.10/72.fc14/i686/kernel-2.6.35.10-72.fc14.i686.rpm IR blaster to the PVR350 input still works. Serial output still does not flash the LED. ------------- # uname -a -------- Linux myth.herald 2.6.35.10-72.fc14.i686 #1 SMP Mon Dec 20 22:05:49 UTC 2010 i686 i686 i386 GNU/Linux ------------- # dmesg | grep lir -------- [ 56.861680] lirc_dev: IR Remote Control driver registered, major 250 [ 56.995086] lirc_i2c: module is from the staging directory, the quality is unknown, you have been warned. [ 56.998350] lirc_i2c: chip 0x0 found @ 0x18 (Hauppauge IR) [ 57.013243] i2c ir driver 3-0018: lirc_dev: driver lirc_i2c registered at minor = 0 [ 57.178212] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned. [ 58.053015] lirc_serial: auto-detected active high receiver [ 58.053231] lirc_serial lirc_serial.0: lirc_dev: driver lirc_serial registered at minor = 1 ------------- tail /var/log/messages # (when sending a channel-change) : -------- Dec 21 21:09:11 myth lircd-0.8.7[1614]: accepted new client on /dev/lirc_o1 Dec 21 21:09:11 myth lircd-0.8.7[1614]: removed client Dec 21 21:09:11 myth lircd-0.8.7[1614]: accepted new client on /dev/lirc_o1 Dec 21 21:09:11 myth lircd-0.8.7[1614]: removed client ------------- # ls -l /dev/lirc* : -------- crw-rw-rw-. 1 root root 250, 0 Dec 21 19:53 /dev/lirc0 crw-rw-rw-. 1 root root 250, 1 Dec 21 19:53 /dev/lirc1 srw-rw-rw-. 1 root root 0 Dec 21 19:53 /dev/lirc_o0 srw-rw-rw-. 1 root root 0 Dec 21 19:53 /dev/lirc_o1 Anything that you'd like me to test?
And (just FYI, and my sanity): /bin/setserial /dev/ttyS0 uart 16550A cat LARGEFILE > /dev/ttyS0 causes the (visible) LED to light up nicely...
Found my serial tx device, reproduced the problem here, will try to get to the bottom of it asap.
It look like memdup_user not working for this driver. With attached patch i reverted memdup_user and small portion of the code back to copy_from_user and all working fine. Using kernel 2.6.35.10-74.fc14.i686.
Created attachment 473733 [details] patch to fix lirc_serial
(In reply to comment #5) > It look like memdup_user not working for this driver. With attached patch i > reverted memdup_user and small portion of the code back to copy_from_user and > all working fine. Using kernel 2.6.35.10-74.fc14.i686. Interesting. Thanks for looking into this, I've not found time yet myself. I don't know that simply reverting the change is the right fix, but it definitely illustrates exactly where the problem is.
Created attachment 473905 [details] v2 patch Right its not correct solution to the problem. I recheck it again and found it was typo from you :) The v2 attached patch fixing the problem by correct way. For sure i checked also other lirc modules from staging and those was not affected by this typo.
One more hint, i have checked another drivers and there are associated kfree() to memdup_user() call. It is not in any lirc modules. Is not it a memory leak ? In memdup_user() is used function kmalloc_track_caller() with really cryptic description ...
(In reply to comment #9) > One more hint, i have checked another drivers and there are associated kfree() > to memdup_user() call. It is not in any lirc modules. Is not it a memory leak ? > In memdup_user() is used function kmalloc_track_caller() with really cryptic > description ... Yeah, looks like you're correct, those are leaks. And you're definitely correct on the typo. Will get patches for both issues sent along shortly. Thanks much!
Patches sent upstream, and included in 2.6.35.10-78.fc14, which is making its way through the build system right now.
kernel-2.6.35.11-83.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.11-83.fc14
kernel-2.6.35.11-83.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
This is fixed, so far as I know. Closing.
As the initial bug submitter : I just want to say "Thank You". Awesome!