| View previous topic :: View next topic |
| Author |
Message |
geoffp
n00b
Joined: 10 Oct 2004
Posts: 47
|
 Posted: Sun Jul 22, 2007 1:56 am Post subject: PVR-150 + Kernel 2.6.22 = lirc_i2c segfault! |
 |
|
I just upgraded to gentoo-sources-2.6.22-r1 on my myth box, and everything works, except that "modprobe lirc_i2c" now segfaults, whether at boot time or thereafter. After a short time, this will freeze up the whole machine.
The error message served is this:
| Code: |
lirc_dev: IR Remote Control driver registered, at major 61
lirc_i2c: no version for "lirc_unregister_plugin" found: kernel tainted.
bttv: driver version 0.9.17 loaded
bttv: using 8 buffers with 2080k (520 pages) each for capture
cx2388x v4l2 driver version 0.0.6 loaded
lirc_i2c: chip found @ 0x71 (Hauppauge IR (PVR150))
BUG: unable to handle kernel NULL pointer dereference at virtual address 0000000
0
printing eip:
c03b7f9a
*pde = 00000000
Oops: 0002 [#1]
PREEMPT
Modules linked in: cx8800 cx88xx bttv video_buf ir_common compat_ioctl32 btcx_ri
sc lirc_i2c(F) lirc_dev realtime wm8775 cx25840 tuner nvidia(P) i2c_viapro snd_e
mu10k1 snd_rawmidi snd_ac97_codec ac97_bus snd_pcm snd_seq_device snd_timer snd_
page_alloc snd_util_mem snd_hwdep snd ohci1394 ieee1394 amd64_agp agpgart emu10k
1_gp gameport ivtv firmware_class cx2341x tveeprom videodev v4l2_common v4l1_com
pat joydev
CPU: 0
EIP: 0060:[<c03b7f9a>] Tainted: PF VLI
EFLAGS: 00010202 (2.6.22-gentoo-r1 #2)
EIP is at __mutex_lock_slowpath+0x2a/0xc0
eax: ffffffff ebx: dfa60055 ecx: ffffffff edx: 00000000
esi: de522460 edi: c17eea00 ebp: dfa60059 esp: db46ac4c
ds: 007b es: 007b fs: 0000 gs: 0033 ss: 0068
Process modprobe (pid: 3829, ti=db46a000 task=c17eea00 task.ti=db46a000)
Stack: dfa60059 00000000 00000001 de522400 de522460 dfa60029 fffffff0 c03b7de9
c0340a39 00000001 db46ae9f 00000282 de522400 e17c512c de52247a dfa60055
de522400 e17c512c de52247a de522460 e17c41e5 e17c5220 00000071 de522464
Call Trace:
[<c03b7de9>] mutex_lock+0x9/0x10
[<c0340a39>] i2c_attach_client+0x29/0x190
[<e17c41e5>] cleanup_module+0x1d5/0x570 [lirc_i2c]
[<e17c4696>] init_module+0x116/0x984 [lirc_i2c]
[<c01bd7dc>] journal_cancel_revoke+0xbc/0xe0
[<c03412b5>] i2c_register_driver+0xd5/0x120
[<e17c45c2>] init_module+0x42/0x984 [lirc_i2c]
[<c0137c55>] sys_init_module+0x145/0x1740
[<c0149a12>] __alloc_pages+0x62/0x300
[<e17bf6d0>] lirc_register_plugin+0x0/0x4e0 [lirc_dev]
[<c01028ce>] sysenter_past_esp+0x5f/0x85
=======================
Code: 90 55 57 56 53 89 c3 83 ec 0c 89 e0 25 00 f0 ff ff 8b 3d 00 e0 45 c0 ff 40
14 8d 6b 04 b8 ff ff ff ff 8b 55 04 89 2c 24 89 65 04 <89> 22 89 54 24 04 89 7c
24 08 87 03 48 74 34 be ff ff ff ff 89
EIP: [<c03b7f9a>] __mutex_lock_slowpath+0x2a/0xc0 SS:ESP 0068:db46ac4c
note: modprobe[3829] exited with preempt_count 1
|
lirc_i2c is the lirc module that's needed to drive the IR hardware on the PVR-150.
Is anyone else seeing this issue? |
|
| Back to top |
|
 |
dshay
n00b
Joined: 08 Dec 2005
Posts: 9
|
| Posted: Sun Jul 22, 2007 3:38 am Post subject: |
|
|
Yes, I'm seeing the same thing (well the segfault, not the whole machine freeze-up). Not that I have a solution...
I have tried every version of lirc, as well as one specifically for the lirc pvr150 in IR blaster mode, as well as CVS of lirc, to no avail. |
|
| Back to top |
|
|
geoffp
n00b
Joined: 10 Oct 2004
Posts: 47
|
| Posted: Mon Jul 23, 2007 2:07 am Post subject: |
|
|
I can't find a solution either. I'm trying to figure out if it's a kernel configuration issue, but I'm not turning up anything.
I'm back at 2.6.20 for now, since I can't give up lirc, but the search continues, since I do still want to upgrade my kernel someday...
EDIT: We are not the only ones: http://www.nabble.com/forum/Search.jtp?forum=2054&local=y&query=2.6.22 |
|
| Back to top |
|
|
thedopefishlives
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 84
|
| Posted: Mon Jul 23, 2007 2:38 pm Post subject: |
|
|
I fixed this. The culprit is a change in the kernel from 2.6.21 to 2.6.22, where they modified the length of the "name" field in one of the i2c structures. This causes a buffer overflow in the LIRC driver. I'll attach the patch and ebuild when I get home.
EDIT: I also tried to contact the LIRC developers, but I don't think my message got through. If there's anyone reading this that's on the lirc mailing list, could you please let them know?
EDIT 2: I couldn't wait to post the changes... Here you go:
Modified ebuild
Patch file |
|
| Back to top |
|
|
geoffp
n00b
Joined: 10 Oct 2004
Posts: 47
|
| Posted: Wed Jul 25, 2007 12:52 am Post subject: |
|
|
Excellent work, dopefish! I'll try your patch tonight.
Out of sheer curiosity, how in the hell did you track this down? I'm interested in how one would go about debugging a driver like lirc. |
|
| Back to top |
|
|
geoffp
n00b
Joined: 10 Oct 2004
Posts: 47
|
| Posted: Wed Jul 25, 2007 4:54 am Post subject: Works! |
|
|
| Hey, your patch works great! It would be criminal for the lirc people not to accept it. |
|
| Back to top |
|
|
thedopefishlives
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 84
|
| Posted: Wed Jul 25, 2007 4:30 pm Post subject: |
|
|
See, on my system, I had the advantage that it didn't crash the kernel; it just hung when I ran modprobe. So I was able to switch to another terminal and run dmesg to see how far the driver got. That told me what function in lirc_i2c.c to look in. Then I started putting in calls to printk() before and after every line of code, to see how far into the function it got. I saw it hung on a call to i2c_attach_client(), which is in the kernel source in drivers/i2c/i2c_core.c. So I went there, found the function, and put in calls to printk() to find out how far it was getting there. The thing that failed was a call to mutex_lock().
I now know where the lockup is - trying to lock the mutex in the I2C structure. Now it was time to find out why. So I went back to the lirc_i2c.c file and put in debugging printk() calls, testing the value of the mutex at various times during the function. I noticed that the mutex changed value after the driver did a strcpy() of the string "Hauppage IR (PVR150)" into the name field, and the first thing that came to mind was "buffer overflow". So I diff'd the i2c.h header file (found in the linux source in the include/linux folder) from 2.6.21 to 2.6.22, and found that they had changed the buffer length to 20. I shortened the LIRC name string, recompiled, and everything worked. |
|
| Back to top |
|
|
thedopefishlives
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 84
|
| Posted: Thu Jul 26, 2007 12:59 pm Post subject: |
|
|
| Just as an addendum to this - the LIRC developers accepted my patch. It should be in the next version. |
|
| Back to top |
|
|
geoffp
n00b
Joined: 10 Oct 2004
Posts: 47
|
| Posted: Thu Jul 26, 2007 7:30 pm Post subject: |
|
|
That's great news! And thanks for the explanation; maybe next time I'll have enough courage to go and dig through the code myself.  |
|
| Back to top |
|
|
Tetti
n00b
Joined: 06 Aug 2007
Posts: 1
|
| Posted: Mon Aug 06, 2007 6:30 pm Post subject: |
|
|
Thank you for investigating the problem creating this patch, dopefish. It works for me, too.
I have created an issue for this in gentoo bugzilla (https://bugs.gentoo.org/show_bug.cgi?id=187822) and added your patches as attachements. Maybe they can use them to create a lirc-0.8.2-r1.ebuild. |
|
| Back to top |
|
|
|
Multimedia
