Description of problem: I just updated to kernel 2.6.29.6-217.2.16.fc11.x86_64 and during udev I see a stack trace spew past. I expected to find it in boot.log, but I guess that stuff doesn't make it into boot.log :-(. What is in boot.log is this line that probably matches where I saw the stack trace: Starting udev: udevd-event[396]: '/sbin/modprobe -b usb:v0AA8p8001d0202dc00dsc00dp00ic00isc00ip00' abnormal exit aside from the stack trace, I also see an awful lot of messages being spewed which have always been suppressed previously with the "quiet" kernel boot option (which is indeed in the grub.conf file on the newest kernel). Despite all the alarms during boot, I haven't yet found anything that isn't working normally now that the system has actually booted. Version-Release number of selected component (if applicable): kernel-2.6.29.6-217.2.16.fc11.x86_64 How reproducible: I've only booted once, but I have no reason to believe it wouldn't happen every time. Steps to Reproduce: 1. see above Actual results: Loads of weird messages at boot time, including stack trace. Expected results: Normal boot with just Started...[OK] lines scrolling past. Additional info:
I think I found it in the dmesg file, looks like the lirc_imon driver blowed up: lirc_imon: Driver for SoundGraph iMON MultiMedia IR/Display, v0.6 lirc_dev: lirc_register_driver: sample_rate: 0 lirc_imon: Registered iMON driver (lirc minor: 0) input: iMON PAD IR Mouse (0aa8:8001) as /devices/pci0000:00/0000:00:02.0/usb2/2-10/2-10:1.0/input/input11 usbcore: registered new interface driver uvcvideo USB Video Class driver (v0.1.0) BUG: unable to handle kernel NULL pointer dereference at 0000000000000002 IP: [<ffffffffa024ce75>] send_packet+0x29/0x205 [lirc_imon] PGD 7d0e1067 PUD 7cd95067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/pci0000:00/0000:00:02.1/usb1/1-2/1-2:1.3/bInterfaceClass CPU 1 Modules linked in: lirc_imon(+) firewire_ohci(+) firewire_core snd_usb_audio(+) uvcvideo snd_usb_lib videodev v4l1_compat snd_intel8x0(+) v4l2_compat_ioctl32 snd_ac97_codec ac97_bus snd_pcm snd_rawmidi snd_timer snd_seq_device snd_hwdep ppdev snd parport_pc k8temp lirc_dev i2c_nforce2 e1000e soundcore snd_page_alloc crc_itu_t serio_raw parport hwmon pcspkr joydev pata_amd ata_generic pata_acpi sata_nv radeon drm i2c_algo_bit i2c_core [last unloaded: scsi_wait_scan] Pid: 397, comm: modprobe Not tainted 2.6.29.6-217.2.16.fc11.x86_64 #1 RIP: 0010:[<ffffffffa024ce75>] [<ffffffffa024ce75>] send_packet+0x29/0x205 [lirc_imon] RSP: 0000:ffff88007d0d9c18 EFLAGS: 00010246 RAX: 8600000000000000 RBX: ffff88007d140400 RCX: 0000000000000000 RDX: 000000007d86c780 RSI: ffff88007debe800 RDI: ffff88007d140400 RBP: ffff88007d0d9c38 R08: ffff88007d812490 R09: 0000000000000000 R10: ffff88007d86c780 R11: ffff88007d812460 R12: ffff88007debe800 R13: ffff88007d05a3c0 R14: ffff88007e0dc300 R15: ffff88007d664000 FS: 00007f81539a56f0(0000) GS:ffff88007f801e80(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 0000000000000002 CR3: 000000007cda8000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process modprobe (pid: 397, threadinfo ffff88007d0d8000, task ffff88007d37c500) Stack: ffff88007ac33000 ffff88007d140400 ffff88007debe800 ffff88007d05a3c0 ffff88007d0d9c68 ffffffffa024d20b 8600000000000000 ffff88007d664000 ffff88007d0d9c68 ffff88007d140400 ffff88007d0d9d18 ffffffffa024eae5 Call Trace: [<ffffffffa024d20b>] imon_set_ir_protocol+0xfb/0x11b [lirc_imon] [<ffffffffa024eae5>] imon_probe+0xce1/0xdac [lirc_imon] [<ffffffff812a455b>] usb_probe_interface+0x107/0x151 [<ffffffff81253fc5>] driver_probe_device+0xce/0x156 [<ffffffff812540b4>] __driver_attach+0x67/0x91 [<ffffffff8125404d>] ? __driver_attach+0x0/0x91 [<ffffffff81253829>] bus_for_each_dev+0x51/0x86 [<ffffffff81253dfe>] driver_attach+0x1e/0x20 [<ffffffff8125316e>] bus_add_driver+0xb7/0x1ea [<ffffffff812542e9>] driver_register+0x92/0xff [<ffffffff812a42e4>] usb_register_driver+0x93/0xfa [<ffffffffa00f6000>] ? imon_init+0x0/0x4e [lirc_imon] [<ffffffffa00f602c>] imon_init+0x2c/0x4e [lirc_imon] [<ffffffff8100a05b>] do_one_initcall+0x5b/0x142 [<ffffffff8105fc3e>] ? up_read+0xe/0x10 [<ffffffff810606dc>] ? __blocking_notifier_call_chain+0x5b/0x67 [<ffffffff8106f387>] sys_init_module+0xaa/0x1cd [<ffffffff8101133a>] system_call_fastpath+0x16/0x1b Code: c9 c3 55 48 89 e5 41 55 41 54 53 48 83 ec 08 0f 1f 44 00 00 83 bf 98 00 00 00 00 48 89 fb 0f 85 8e 00 00 00 48 8b 4f 78 48 8b 37 <0f> b6 41 02 8b 16 0f b6 49 06 c1 e2 08 c1 e0 0f 09 c2 48 8b 87 RIP [<ffffffffa024ce75>] send_packet+0x29/0x205 [lirc_imon] RSP <ffff88007d0d9c18> CR2: 0000000000000002 ---[ end trace 1e688b6a41386690 ]--- Sure enough, if I run my little program to test the remote, it doesn't work.
I renamed lirc_imon.ko to NOTlirc_imon.koNOT and rebooted, and all is well. No more stack trace, no more extra messages spewed at any point during the boot, so it definitely appears to be a lirc_imon problem.
https://www.redhat.com/archives/fedora-test-list/2009-August/msg00811.html Apparently this happens in rawhide as well. The above note was about the latest updates failing in my fedora 12 alpha boot partition on the same machine, so as a test I renamed the fedora 12 lirc_imon.ko as well and tried booting again, and it booted with no problems, so it seems to fail more drastically in fedora 12 alpha with the 2.6.31-0.180.rc7.git4.fc12.x86_64 kernel, but the failure is still due to lirc_imon.
Hrm. I'm running what's basically an identical lirc_imon here myself without any problems, but you've got the first original imon device I've ever seen reported anywhere (0aa8:8001), which I believe is IR-only, and is definitely not using control endpoints like the newer devices (such as mine). Seems I must have missed something somewhere in the handling of older devices, will see what I can come up with for a fix...
Its built into my TNN-500 quiet computer case, but I don't actually use it for anything other than occasional testing. I suppose if the old and new imon devices are that different, worst case would be to split the driver code and leave the old driver alone as lirc_oldimon or something :-). If you come up with something you want me to test, I'd feel safer doing most testing in the fedora 12 rawhide partition since it is mainly for testing anyway.
(In reply to comment #5) > Its built into my TNN-500 quiet computer case, but I don't actually use it > for anything other than occasional testing. I suppose if the old and new imon > devices are that different, worst case would be to split the driver code and > leave the old driver alone as lirc_oldimon or something :-). No, that's the wrong way to go. They're not THAT different, and maintaining more drivers sucks. Besides, after looking at your backtrace closer and at the lirc_imon code a bit, I see exactly what's happening, its an easy fix. > If you come up with something you want me to test, I'd feel safer doing > most testing in the fedora 12 rawhide partition since it is mainly for > testing anyway. Just committed the fix to the rawhide kernel tree, should be good to go in kernel-2.6.31-0.191.rc8.fc12 and later, once built.
Just got the rawhide update for 2.6.31-0.199.rc8.git2.fc12.x86_64 and everything seems to be working fine. irrecord will prints dots when I press buttons, and there are no tracebacks during boot.
Good deal, thanks for confirming the fix!