Bug 629980 - lirc_imon driver once again kills my system in new 2.6.34 kernel
Summary: lirc_imon driver once again kills my system in new 2.6.34 kernel
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 13
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jarod Wilson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-09-03 12:43 UTC by Tom Horsley
Modified: 2010-09-09 01:17 UTC (History)
12 users (show)

Fixed In Version: kernel-2.6.34.6-54.fc13
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-09 01:17:09 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Tom Horsley 2010-09-03 12:43:32 UTC 
Description of problem:

Seems like often a new kernel comes around and my ancient lirc_imon device
crashes and I have to rename the lirc_imon.ko file to allow the system to
boot. Once again, the new kernel dies. With my imon device:

Bus 007 Device 002: ID 0aa8:8001 TriGem Computer, Inc. TG_iMON

Renaming the lirc_imon.ko file so it can't find it makes the system boot OK.

Version-Release number of selected component (if applicable):
kernel-2.6.34.6-47.fc13.x86_64

How reproducible:
Can't ever boot, so I'd say 100%

Steps to Reproduce:
1.install updates with new kernel
2.try to reboot
3.watch system get confused after starting udev
  
Actual results:
see above

Expected results:
boots normally

Additional info:

See bug 459523, bug 520008, and bug 545599 for previous instances of this
same breakage on the same hardware (the good thing is that I now recognize
it without getting too confused :-).
Comment 1 Tom Horsley 2010-09-03 12:57:14 UTC 
Oops. Didn't notice the fedora version, it is really on fedora 13, not
14.
Comment 2 Matthew Miller 2010-09-03 13:10:42 UTC 
As you know :) the backtrace helps.....
Comment 3 Tom Horsley 2010-09-03 13:54:33 UTC 
Yea, it is hard to get though. It scrolls past on the console screen, but not
in any log I can find. I'll try renaming the module back after booting and
doing a modprobe on it to see if that gets me a backtrace somewhere where
I can capture it.
Comment 4 Tom Horsley 2010-09-03 14:07:51 UTC 
That did work, the backtrace shows up in /var/log/messages

Sep  3 09:58:55 zooty kernel: lirc_imon: Driver for SoundGraph iMON MultiMedia IR/Display, v0.8
Sep  3 09:58:55 zooty kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
Sep  3 09:58:55 zooty kernel: IP: [<ffffffffa0141b59>] imon_probe+0x32/0x8ad [lirc_imon]
Sep  3 09:58:55 zooty kernel: PGD 21e163067 PUD 2110e0067 PMD 0 
Sep  3 09:58:55 zooty kernel: Oops: 0002 [#1] SMP 
Sep  3 09:58:55 zooty kernel: last sysfs file: /sys/module/lirc_dev/initstate
Sep  3 09:58:55 zooty kernel: CPU 3 
Sep  3 09:58:55 zooty kernel: Modules linked in: lirc_imon(+) ebtable_nat ebtables nfsd lockd nfs_acl auth_rpcgss exportfs hwmon_vid coretemp sunrpc cpufreq_ondemand acpi_cpufreq freq_table bridge stp llc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm uinput usblp snd_hda_codec_realtek uvcvideo snd_hda_intel videodev e1000e snd_hda_codec v4l1_compat v4l2_compat_ioctl32 snd_usb_audio snd_usb_lib snd_ca0106 snd_ac97_codec ppdev parport_pc parport snd_rawmidi ac97_bus snd_hwdep snd_seq snd_seq_device snd_pcm shpchp i2c_i801 lirc_dev iTCO_wdt iTCO_vendor_support snd_timer snd serio_raw joydev soundcore snd_page_alloc microcode pata_acpi ata_generic usb_storage pata_jmicron radeon ttm drm_kms_helper drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan]
Sep  3 09:58:55 zooty kernel:
Sep  3 09:58:55 zooty kernel: Pid: 4383, comm: modprobe Not tainted 2.6.34.6-47.fc13.x86_64 #1 TP43D2-A7/TP43D2-A7
Sep  3 09:58:55 zooty kernel: RIP: 0010:[<ffffffffa0141b59>]  [<ffffffffa0141b59>] imon_probe+0x32/0x8ad [lirc_imon]
Sep  3 09:58:55 zooty kernel: RSP: 0018:ffff88021e2b5ca8  EFLAGS: 00010282
Sep  3 09:58:55 zooty kernel: RAX: ffffffffa01432b0 RBX: ffff8802320b1030 RCX: 0000000000000002
Sep  3 09:58:55 zooty kernel: RDX: 0000000000000003 RSI: ffffffffa01432b0 RDI: ffff8802331d3000
Sep  3 09:58:55 zooty kernel: RBP: ffff88021e2b5d48 R08: 0000000000000000 R09: ffff880002190820
Sep  3 09:58:55 zooty kernel: R10: 0000000000003692 R11: ffff880236d4def8 R12: ffff8802320b1000
Sep  3 09:58:55 zooty kernel: R13: ffff8802320b1000 R14: ffffffffa01431f8 R15: ffff8802331d3000
Sep  3 09:58:55 zooty kernel: FS:  00007f682d780700(0000) GS:ffff880002180000(0000) knlGS:0000000000000000
Sep  3 09:58:55 zooty kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Sep  3 09:58:55 zooty kernel: CR2: 0000000000000008 CR3: 00000002213c1000 CR4: 00000000000406e0
Sep  3 09:58:55 zooty kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Sep  3 09:58:55 zooty kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Sep  3 09:58:55 zooty kernel: Process modprobe (pid: 4383, threadinfo ffff88021e2b4000, task ffff880221122ee0)
Sep  3 09:58:55 zooty kernel: Stack:
Sep  3 09:58:55 zooty kernel: ffff88021e2b5d08 ffffffff81164045 ffff88021e2b5d08 ffffffff81164220
Sep  3 09:58:55 zooty kernel: <0> ffff88021e2b5cf8 ffff8802331d3090 ffff8802331d3090 0000000000000246
Sep  3 09:58:55 zooty kernel: <0> ffff88021e2b5d48 ffffffff812ca788 ffff880200000000 0000000000000246
Sep  3 09:58:55 zooty kernel: Call Trace:
Sep  3 09:58:55 zooty kernel: [<ffffffff81164045>] ? sysfs_addrm_finish+0x2f/0xb9
Sep  3 09:58:55 zooty kernel: [<ffffffff81164220>] ? sysfs_add_one+0x21/0xf3
Sep  3 09:58:55 zooty kernel: [<ffffffff812ca788>] ? __pm_runtime_set_status+0x148/0x167
Sep  3 09:58:55 zooty kernel: [<ffffffff81321be9>] usb_probe_interface+0x153/0x22b
Sep  3 09:58:55 zooty kernel: [<ffffffff812c3c22>] driver_probe_device+0xea/0x217
Sep  3 09:58:55 zooty kernel: [<ffffffff812c3dac>] __driver_attach+0x5d/0x81
Sep  3 09:58:55 zooty kernel: [<ffffffff812c3d4f>] ? __driver_attach+0x0/0x81
Sep  3 09:58:55 zooty kernel: [<ffffffff812c3048>] bus_for_each_dev+0x53/0x88
Sep  3 09:58:55 zooty kernel: [<ffffffff812c39b2>] driver_attach+0x1e/0x20
Sep  3 09:58:55 zooty kernel: [<ffffffff812c3346>] bus_add_driver+0x11d/0x282
Sep  3 09:58:55 zooty kernel: [<ffffffff812c40ad>] driver_register+0x9e/0x10f
Sep  3 09:58:55 zooty kernel: [<ffffffff813218a1>] usb_register_driver+0x93/0x154
Sep  3 09:58:55 zooty kernel: [<ffffffffa005b000>] ? imon_init+0x0/0x4e [lirc_imon]
Sep  3 09:58:55 zooty kernel: [<ffffffffa005b02c>] imon_init+0x2c/0x4e [lirc_imon]
Sep  3 09:58:55 zooty kernel: [<ffffffff81002069>] do_one_initcall+0x5e/0x159
Sep  3 09:58:55 zooty kernel: [<ffffffff8107cfdf>] sys_init_module+0xd6/0x237
Sep  3 09:58:55 zooty kernel: [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b
Sep  3 09:58:55 zooty kernel: Code: 56 41 55 41 54 53 48 83 ec 78 0f 1f 44 00 00 48 c7 c6 b0 32 14 a0 48 8d 47 30 49 89 fd 48 89 45 c0 e8 7d ed 1d e1 48 85 c0 74 0d <c7> 04 25 08 00 00 00 00 00 00 00 eb 07 c7 40 08 01 00 00 00 49 
Sep  3 09:58:55 zooty kernel: RIP  [<ffffffffa0141b59>] imon_probe+0x32/0x8ad [lirc_imon]
Sep  3 09:58:55 zooty kernel: RSP <ffff88021e2b5ca8>
Sep  3 09:58:55 zooty kernel: CR2: 0000000000000008
Sep  3 09:58:55 zooty kernel: ---[ end trace a8d709957e7f5c15 ]---

No doubt the NULL pointer dereference is attempting to fiddle with some
hardware that doesn't exist on this old IR-only imon device (at least that
was my impression the last few times I got this same bug).
Comment 5 Jarod Wilson 2010-09-03 15:20:48 UTC 
Hell. Apologies, I'm not sure how this got broken *again*. Will look at it more in-depth as soon as I can.
Comment 6 Chuck Ebbert 2010-09-03 15:40:54 UTC 
drivers/input/lirc/lirc_imon.c: 728:

        struct imon_context *context = NULL;
        struct imon_context *first_if_context = NULL;
        int i;
        u16 vendor, product;

        /*
         * Try to auto-detect the type of display if the user hasn't set
         * it by hand via the display_type modparam. Default is VFD.
         */
        if (usb_match_id(interface, ir_only_list))
OOPS==>         context->display = 0;
        else
                context->display = 1;


context is always NULL there
Comment 7 Kyle McMartin 2010-09-03 16:01:38 UTC 
Please fetch the scratch build from here which should fix things:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2445446
Comment 8 Tom Horsley 2010-09-03 17:46:00 UTC 
That seems to work. I'm running kernel-2.6.34.6-50.fc13.x86_64 now from
that koji build and it booted with no problems, and I can even run xmode2
and see it draw waveforms when I press a remote button.
Comment 9 Jarod Wilson 2010-09-05 23:33:04 UTC 
Figured out the root cause of this cropping up again. It was already fixed in the 2.6.33.x builds after 2.6.34.x was branched, and the updated patches in 2.6.33.x didn't get pulled into the 2.6.34.x branch. This has now been remedied.
Comment 10 Fedora Update System 2010-09-06 20:53:48 UTC 
kernel-2.6.34.6-54.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/kernel-2.6.34.6-54.fc13
Comment 11 Chuck Ebbert 2010-09-07 03:53:01 UTC 
Bodhi will close the bug when the update gets pushed to -stable.
Comment 12 Fedora Update System 2010-09-08 02:21:15 UTC 
kernel-2.6.34.6-54.fc13 has been pushed to the Fedora 13 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update kernel'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/kernel-2.6.34.6-54.fc13
Comment 13 Fedora Update System 2010-09-09 01:16:12 UTC 
kernel-2.6.34.6-54.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.