Red Hat Bugzilla – Bug 508952
Oopsed yanked remote receiver
Last modified: 2009-08-12 10:02:35 EDT
kernel-2.6.29.5-191.fc11.x86_64 lirc-0.8.5-2.fc11.x86_64 Using the lirc_streamzap module. I yanked out the USB receiver from my Streamzap remote after I finished testing with it, and the kernel oopsed a couple of seconds later. general protection fault: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/irq CPU 0 Modules linked in: lirc_streamzap lirc_dev tun nls_utf8 udf crc_itu_t vfat fat hidp fuse rfcomm bridge stp llc bnep sco l2cap sunrpc ipv6 dm_multipath uinput btusb bluetooth ppdev snd_intel8x0 snd_ac97_codec dcdbas snd_usb_audio pcspkr uvcvideo videodev snd_usb_lib serio_raw snd_rawmidi i2c_i801 iTCO_wdt parport_pc v4l1_compat ac97_bus v4l2_compat_ioctl32 parport snd_seq_device snd_hwdep usb_storage iTCO_vendor_support tg3 snd_pcm joydev snd_timer snd soundcore snd_page_alloc ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core video output [last unloaded: freq_table] Pid: 16402, comm: lircd Not tainted 2.6.29.5-191.fc11.x86_64 #1 OptiPlex GX620 RIP: 0010:[<ffffffffa02f3a0d>] [<ffffffffa02f3a0d>] lirc_dev_fop_open+0xc6/0x1d8 [lirc_dev] RSP: 0018:ffff880045a77d28 EFLAGS: 00010282 RAX: ffff88003f0044f8 RBX: ffff880075d54c00 RCX: ffff880045a77d38 RDX: 0000000000000000 RSI: 000000000000012d RDI: ffffffff814d4f2d RBP: ffff880045a77d38 R08: ffff880045a77c98 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: f5319f100a080204 R13: 0000000000000000 R14: ffff88006d008a18 R15: ffff88002d8a29c0 FS: 00007fa1632806f0(0000) GS:ffffffff817b7000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55fd7b1cb6 CR3: 000000000f4c2000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process lircd (pid: 16402, threadinfo ffff880045a76000, task ffff88000440c500) Stack: 0000000000000000 ffff880075d54cd0 ffff880045a77d88 ffffffff810d7c6b ffff880045a77d78 ffffffff811869cc ffff88007b861b00 ffff88007b861b00 ffff88002d441780 ffff88002d8a29c0 ffffffff810d7b19 ffff88006d008a18 Call Trace: [<ffffffff810d7c6b>] chrdev_open+0x152/0x171 [<ffffffff811869cc>] ? selinux_dentry_open+0xe7/0xf0 [<ffffffff810d7b19>] ? chrdev_open+0x0/0x171 [<ffffffff810d37ea>] __dentry_open+0x143/0x273 [<ffffffff810d39ea>] nameidata_to_filp+0x42/0x53 [<ffffffff810df085>] do_filp_open+0x3fd/0x7b8 [<ffffffff810e9e5c>] ? mntput_no_expire+0x36/0x150 [<ffffffff811b9602>] ? might_fault+0x1f/0x21 [<ffffffff811b9701>] ? __strncpy_from_user+0x1e/0x49 [<ffffffff810e8464>] ? alloc_fd+0x11b/0x12d [<ffffffff810d35da>] do_sys_open+0x59/0xda [<ffffffff810d368e>] sys_open+0x20/0x22 [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b Code: 28 ff 0f 84 24 01 00 00 83 bb 94 00 00 00 00 41 bc f0 ff ff ff 0f 85 17 01 00 00 48 8b 83 b0 00 00 00 4c 8b 60 28 4d 85 e4 74 2b <49> 8b 7c 24 18 e8 4b 85 0b e1 49 8b 7c 24 18 41 c7 44 24 10 00 RIP [<ffffffffa02f3a0d>] lirc_dev_fop_open+0xc6/0x1d8 [lirc_dev] RSP <ffff880045a77d28> ---[ end trace df882a9e6cc7b241 ]---
In lirc_dev.c line 466: lirc_buffer_clear(ir->buf); lirc_dev.h: static void lirc_buffer_clear(struct lirc_buffer *buf) { if (buf->fifo) kfifo_reset(buf->fifo); buf->fifo is not null but it doesn't contain a valid address.
Ugh. lirc_streamzap is... not the best code around. I might have a fix, but while working on the fix, I went nuts killing a bunch of insanity in lirc_streamzap. I really should get some hardware to test on, but meh. I'll throw the modified code into rawhide, and it can get tested there, then backported as needed...
kernel-2.6.31-0.48.rc2.git2.fc12 and later carry a patch to lirc_streamzap that in theory addresses this problem, but it also changes a LOT of other stuff, so there's a decent chance it completely breaks it. Most of the changes make the driver a lot more like lirc_imon and lirc_mceusb though... diffstat: drivers/input/lirc/lirc_streamzap.c | 207 +++++++++++++++++++---------------- 1 files changed, 112 insertions(+), 95 deletions(-) I'd appreciate testing feedback, even if its "omg, now its completely and totally unusable".
I just got a streamzap receiver off eBay myself. The patch does indeed seem to remedy this particular problem. I still have an issue if I pull the receiver while the ir device is open, but that's a more general issue that needs dealing with for all receivers, not just this one. This patch appears to be good to go, and does fix the oops when the receiver is pulled w/o the ir device open.