Having removed smp_lock.h from lirc_atiusb.c as per bug #369179 the module compiles fine, but when loaded it crashes and produces the attached output in dmesg. The system still seems to run fine, but the module subsequently can not be unloaded and doesnt't produce the expected /dev/lirc0 node. I've tried the latest lirc git sources, which incidentally also need patching for the smp_lock.h, and the resulting lirc_atiusb loads fine and produces the /dev/lirc0 node as expected. This works at least in kernel 2.6.39-gentoo-r3. Probably the patch at http://lirc.git.sourceforge.net/git/gitweb.cgi?p=lirc/lirc;a=commit;h=ec3c5660e67c122e2d5eb9cfa838c9709fccf8e0 produces the fix for this problem, and I would hazard a guess that it would also work from kernels 2.6.36 onwards. Kernel series 2.6.35 was the last which worked with the standard lirc ebuulds regarding the lirc_atiusb module. Reproducible: Always Steps to Reproduce: 1. Emerge lirc with LIRC_DEVICES="xboxusb" 2. Insert appropriate USB device (in this case XBOX ir remote) 3. Check dmesg for crash debug (assuming module has been auto-loaded). Actual Results: No device node /dev/lirc0 was created Expected Results: /dev/lirc0 should be created CHOST="x86_64-pc-linux-gnu" CFLAGS="-march=barcelona -O2 -pipe -fomit-frame-pointer" ACCEPT_KEYWORDS="~amd64"
Created attachment 281543 [details] dmesg debug output produced when loading lirc_atiusb module
Created attachment 281545 [details, diff] Patch against lirc-0.9.0 to fix lirc_atiusb module in kernel 2.6.39
+ 17 Jul 2012; Ian Stakenvicius <axs@gentoo.org> lirc-0.9.0-r1.ebuild, + +files/lirc-0.9.0-atiusb_kfifo.patch: + Applied upstream patch to fix bug 377033 + Since it's an upstream patch it seems pretty safe to apply. I added #if's on the KERNEL_VERSION so that it will still compile identically for older kernels, just in case.
Upstream only mentions 2.6.38 (and later), so I did not apply the fix for 2.6.36-2.6.37 or above
