(cc's added) On Sun, 04 Sep 2011 21:02:41 +0200 Anders <aeriksson2@xxxxxxxxx> wrote: > Found this oops produced by kdump here. It seems imon related. > > > ... > > <4>[ 278.893189] Restarting tasks ... done. > <6>[ 278.994452] usb 5-1: USB disconnect, device number 2 > <3>[ 278.995191] imon:send_packet: error submitting urb(-19) > <3>[ 279.000016] imon:vfd_write: send packet failed for packet #3 > <3>[ 279.000028] imon:vfd_write: no iMON device present > <3>[ 279.000032] imon:vfd_write: no iMON device present > <3>[ 279.000036] imon:vfd_write: no iMON device present > <3>[ 279.000040] imon:vfd_write: no iMON device present > <3>[ 279.000044] imon:vfd_write: no iMON device present > <3>[ 279.000048] imon:vfd_write: no iMON device present > <3>[ 279.000053] imon:vfd_write: no iMON device present > <3>[ 279.000057] imon:vfd_write: no iMON device present > <3>[ 279.000061] imon:vfd_write: no iMON device present > <3>[ 279.000065] imon:vfd_write: no iMON device present > <3>[ 279.000069] imon:vfd_write: no iMON device present > <3>[ 279.000073] imon:vfd_write: no iMON device present > <3>[ 279.000077] imon:vfd_write: no iMON device present > <3>[ 279.000081] imon:vfd_write: no iMON device present > <3>[ 279.000085] imon:vfd_write: no iMON device present > <0>[ 279.042361] stack segment: 0000 [#1] PREEMPT SMP > <4>[ 279.042450] CPU 1 > <4>[ 279.042482] Modules linked in: saa7134_alsa tda1004x saa7134_dvb > videobuf_dvb dvb_core ir_kbd_i2c tda827x ir_lirc_codec lirc_dev tda8290 > ir_sony_decoder tuner ir_jvc_decoder snd_hda_codec_realtek > ir_rc6_decoder saa7134 videobuf_dma_sg videobuf_core v4l2_common > rc_imon_mce imon ir_rc5_decoder ir_nec_decoder rc_core videodev > snd_hda_intel parport_pc snd_hda_codec v4l2_compat_ioctl32 parport > tveeprom snd_hwdep i2c_piix4 sg pcspkr rtc_cmos atiixp asus_atk0110 > <4>[ 279.043219] > <4>[ 279.043242] Pid: 1922, comm: LCDd Not tainted 3.0.1-dirty #24 > System manufacturer System Product Name/M2A-VM HDMI > <4>[ 279.043318] RIP: 0010:[<ffffffff810231bb>] [<ffffffff810231bb>] > mutex_spin_on_owner+0x3e/0x63 > <4>[ 279.043318] RSP: 0018:ffff88004a1c3e00 EFLAGS: 00010246 > <4>[ 279.043318] RAX: ffff880074118cf0 RBX: ffff8800725d0020 RCX: > 0000000000000000 > <4>[ 279.043318] RDX: ffff8800725d0038 RSI: 65766f6d65723d4e RDI: > ffff8800725d0020 > <4>[ 279.043318] RBP: 65766f6d65723d4e R08: 0000000000000000 R09: > ffff88007308fe40 > <4>[ 279.043318] R10: 0000000000000001 R11: 0000000000000246 R12: > 0000000000000000 > <4>[ 279.043318] R13: ffff88004a1c2010 R14: ffff88004a1c2010 R15: > 0000000000000001 > <4>[ 279.043318] FS: 00007f9c84ed5700(0000) GS:ffff880077c80000(0000) > knlGS:0000000000000000 > <4>[ 279.043318] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > <4>[ 279.043318] CR2: 00007eff71e392a0 CR3: 00000000730f9000 CR4: > 00000000000006e0 > <4>[ 279.043318] DR0: 0000000000000000 DR1: 0000000000000000 DR2: > 0000000000000000 > <4>[ 279.043318] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: > 0000000000000400 > <4>[ 279.043318] Process LCDd (pid: 1922, threadinfo ffff88004a1c2000, > task ffff880074118cf0) > <0>[ 279.043318] Stack: > <4>[ 279.043318] 0000000000000286 ffff8800725d0020 ffff880074118cf0 > 65766f6d65723d4e > <4>[ 279.043318] 0000000000000000 ffffffff814c14dc 0000000000000000 > ffff8800725d0038 > <4>[ 279.043318] ffffffff81048211 ffff88004a1c3ed8 0000000000000286 > ffff880074118cf0 > <0>[ 279.043318] Call Trace: > <4>[ 279.043318] [<ffffffff814c14dc>] ? __mutex_lock_slowpath+0x57/0x17f > <4>[ 279.043318] [<ffffffff81048211>] ? lock_hrtimer_base+0x1b/0x3c > <4>[ 279.043318] [<ffffffff810482d1>] ? hrtimer_try_to_cancel+0x63/0x6c > <4>[ 279.043318] [<ffffffff814c1404>] ? mutex_lock+0x12/0x22 > <4>[ 279.043318] [<ffffffff814c1a8a>] ? do_nanosleep+0x77/0xb0 > <4>[ 279.043318] [<ffffffffa0100805>] ? vfd_write+0x63/0x1bd [imon] > <4>[ 279.043318] [<ffffffff8104877d>] ? hrtimer_nanosleep+0x9c/0x108 > <4>[ 279.043318] [<ffffffff810b22cb>] ? vfs_write+0xad/0x12e > <4>[ 279.043318] [<ffffffff810b2402>] ? sys_write+0x45/0x6e > <4>[ 279.043318] [<ffffffff814c317b>] ? system_call_fastpath+0x16/0x1b > <0>[ 279.043318] Code: 00 55 48 89 f5 53 48 89 fb 48 83 ec 08 eb 0e 49 > 8b 45 00 a8 08 74 04 31 c0 eb 2c f3 90 e8 02 38 05 00 45 31 e4 48 39 6b > 18 75 08 > <83>[ 279.043318] 7d 28 00 41 0f 95 c4 e8 60 48 05 00 45 84 e4 75 d2 > 31 c0 48 > <1>[ 279.043318] RIP [<ffffffff810231bb>] mutex_spin_on_owner+0x3e/0x63 > <4>[ 279.043318] RSP <ffff88004a1c3e00> Yes, vfd_write() appears to have got all confused and passed a garbage pointer into mutex_lock(). -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
