From: Greg O. <oli...@gm...> - 2010-10-08 02:47:18
|
I've been testing ubuntu beta 10.10 on one of mythtv systems. It is supposedly using a cvs snapshot of 0.8.7 with a couple of patches (ioctl kernel update or something or other).. The ir_core module is OOPSing for me all the time with my mceusb transceiver.. Unloading of any lirc modules becomes impossible, and a system reboot is required to bring back a functioning remote. With the changes and stuff migrating to the kernel, I guess I am just looking for some recommendations as to how to go about alleviating the issue. What are recommended versions of everything? Do I need a newer kernel as well as userspace? Thanks for any info. -Greg |
From: Jarod W. <ja...@wi...> - 2010-10-08 03:29:29
|
On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: > I've been testing ubuntu beta 10.10 on one of mythtv systems. > > It is supposedly using a cvs snapshot of 0.8.7 with a couple of > patches (ioctl kernel update or something or other).. > > The ir_core module is OOPSing for me all the time with my mceusb > transceiver.. Unloading of any lirc modules becomes impossible, and a > system reboot is required to bring back a functioning remote. > > With the changes and stuff migrating to the kernel, I guess I am just > looking for some recommendations as to how to go about alleviating the > issue. What are recommended versions of everything? Do I need a > newer kernel as well as userspace? Userspace shouldn't matter, an oops is purely a kernel issue. Get me the full oops trace, and I'll see if I can figure out what's going on. Its definitely not happening with newer kernels, so there's likely a fix already available, just needs to be added to the Ubuntu kernel. -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-08 03:33:59
|
On Thu, Oct 7, 2010 at 10:29 PM, Jarod Wilson <ja...@wi...> wrote: > On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: >> I've been testing ubuntu beta 10.10 on one of mythtv systems. >> >> It is supposedly using a cvs snapshot of 0.8.7 with a couple of >> patches (ioctl kernel update or something or other).. >> >> The ir_core module is OOPSing for me all the time with my mceusb >> transceiver.. Unloading of any lirc modules becomes impossible, and a >> system reboot is required to bring back a functioning remote. >> >> With the changes and stuff migrating to the kernel, I guess I am just >> looking for some recommendations as to how to go about alleviating the >> issue. What are recommended versions of everything? Do I need a >> newer kernel as well as userspace? > > Userspace shouldn't matter, an oops is purely a kernel issue. Get me > the full oops trace, and I'll see if I can figure out what's going on. > Its definitely not happening with newer kernels, so there's likely a > fix already available, just needs to be added to the Ubuntu kernel. This is all I get (it is the same every time though..) [ 679.182037] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [ 679.182050] IP: [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] [ 679.182070] PGD 1f7454067 PUD 21046d067 PMD 0 [ 679.182080] Oops: 0000 [#1] SMP [ 679.182087] last sysfs file: /sys/devices/virtual/rc/rc0/protocols [ 679.182094] CPU 2 [ 679.182097] Modules linked in: kvm_amd kvm snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec nvidia(P) snd_hwdep snd_pcm ir_lirc_codec lirc_dev snd_seq_midi ir_sony_decoder snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore snd_page_alloc ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder rc_rc6_mce ir_nec_decoder mceusb ir_core i2c_piix4 edac_core edac_mce_amd k10temp psmouse serio_raw lp parport usbhid hid pata_atiixp r8169 mii ahci libahci [ 679.182162] [ 679.182170] Pid: 2435, comm: lirc Tainted: P 2.6.35-22-generic #33-Ubuntu TA880GB+/TA880GB+ [ 679.182177] RIP: 0010:[<ffffffffa00c41b8>] [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] [ 679.182193] RSP: 0018:ffff8801f74ede48 EFLAGS: 00010202 [ 679.182198] RAX: 0000000000000000 RBX: ffff880225f2d001 RCX: 0000000000000001 [ 679.182204] RDX: ffff88022bba09c0 RSI: ffffffffa00c5254 RDI: ffff880225f2d004 [ 679.182209] RBP: ffff8801f74ede88 R08: 0000000000000035 R09: 0000000000000035 [ 679.182215] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88022d8ab000 [ 679.182220] R13: 0000000000000001 R14: 0000000000000005 R15: 0000000000000000 [ 679.182227] FS: 00007fa48d903700(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000 [ 679.182233] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 679.182239] CR2: 0000000000000060 CR3: 00000001f7417000 CR4: 00000000000006e0 [ 679.182245] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 679.182251] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 679.182257] Process lirc (pid: 2435, threadinfo ffff8801f74ec000, task ffff8801f75d0000) [ 679.182262] Stack: [ 679.182266] ffff8801f74ede78 0000000000000001 ffff8801f774a740 ffff8801f774a740 [ 679.182274] <0> ffff8801f74edf48 ffff88022de87410 ffffffff8164ac00 ffff88022d8ab010 [ 679.182284] <0> ffff8801f74ede98 ffffffff81383b00 ffff8801f74edee8 ffffffff811bd8d2 [ 679.182294] Call Trace: [ 679.182309] [<ffffffff81383b00>] dev_attr_store+0x20/0x30 [ 679.182320] [<ffffffff811bd8d2>] sysfs_write_file+0xf2/0x180 [ 679.182329] [<ffffffff81152948>] vfs_write+0xb8/0x1a0 [ 679.182339] [<ffffffff8158ceae>] ? do_page_fault+0x15e/0x350 [ 679.182347] [<ffffffff811531c1>] sys_write+0x51/0x80 [ 679.182358] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b [ 679.182362] Code: 44 ff ff ff eb 05 90 90 90 90 90 45 84 ff 48 8b 5d c8 0f 84 68 ff ff ff 48 f7 d3 48 21 c3 e9 5d ff ff ff 49 8b 84 24 90 02 00 00 <48> 8b 40 60 e9 3c ff ff ff eb 05 90 90 90 90 90 48 83 c3 01 45 [ 679.182430] RIP [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] [ 679.182441] RSP <ffff8801f74ede48> [ 679.182445] CR2: 0000000000000060 [ 679.182465] ---[ end trace fd4c49a5969b35df ]--- Thanks! |
From: Jarod W. <ja...@wi...> - 2010-10-08 03:43:06
|
On Thu, Oct 7, 2010 at 11:33 PM, Greg Oliver <oli...@gm...> wrote: > On Thu, Oct 7, 2010 at 10:29 PM, Jarod Wilson <ja...@wi...> wrote: >> On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: >>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>> >>> It is supposedly using a cvs snapshot of 0.8.7 with a couple of >>> patches (ioctl kernel update or something or other).. >>> >>> The ir_core module is OOPSing for me all the time with my mceusb >>> transceiver.. Unloading of any lirc modules becomes impossible, and a >>> system reboot is required to bring back a functioning remote. >>> >>> With the changes and stuff migrating to the kernel, I guess I am just >>> looking for some recommendations as to how to go about alleviating the >>> issue. What are recommended versions of everything? Do I need a >>> newer kernel as well as userspace? >> >> Userspace shouldn't matter, an oops is purely a kernel issue. Get me >> the full oops trace, and I'll see if I can figure out what's going on. >> Its definitely not happening with newer kernels, so there's likely a >> fix already available, just needs to be added to the Ubuntu kernel. > > This is all I get (it is the same every time though..) > > > [ 679.182037] BUG: unable to handle kernel NULL pointer dereference > at 0000000000000060 > [ 679.182050] IP: [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] > [ 679.182070] PGD 1f7454067 PUD 21046d067 PMD 0 > [ 679.182080] Oops: 0000 [#1] SMP > [ 679.182087] last sysfs file: /sys/devices/virtual/rc/rc0/protocols Hrm. Does this box by chance have multiple entries under /sys/devices/virtual/rc/ ? This sounds like the issue this patch is supposed to fix: http://git.linuxtv.org/media_tree.git?a=commitdiff;h=7a1f9f0810216466647512688dbb3179527f4e51 Something like an imon device would trip on that when the ubuntu 10.10 lirc initscript starts up. -- Jarod Wilson ja...@wi... |
From: Jarod W. <ja...@wi...> - 2010-10-08 03:45:24
|
On Thu, Oct 7, 2010 at 11:42 PM, Jarod Wilson <ja...@wi...> wrote: > On Thu, Oct 7, 2010 at 11:33 PM, Greg Oliver <oli...@gm...> wrote: >> On Thu, Oct 7, 2010 at 10:29 PM, Jarod Wilson <ja...@wi...> wrote: >>> On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: >>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>> >>>> It is supposedly using a cvs snapshot of 0.8.7 with a couple of >>>> patches (ioctl kernel update or something or other).. >>>> >>>> The ir_core module is OOPSing for me all the time with my mceusb >>>> transceiver.. Unloading of any lirc modules becomes impossible, and a >>>> system reboot is required to bring back a functioning remote. >>>> >>>> With the changes and stuff migrating to the kernel, I guess I am just >>>> looking for some recommendations as to how to go about alleviating the >>>> issue. What are recommended versions of everything? Do I need a >>>> newer kernel as well as userspace? >>> >>> Userspace shouldn't matter, an oops is purely a kernel issue. Get me >>> the full oops trace, and I'll see if I can figure out what's going on. >>> Its definitely not happening with newer kernels, so there's likely a >>> fix already available, just needs to be added to the Ubuntu kernel. >> >> This is all I get (it is the same every time though..) >> >> >> [ 679.182037] BUG: unable to handle kernel NULL pointer dereference >> at 0000000000000060 >> [ 679.182050] IP: [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] >> [ 679.182070] PGD 1f7454067 PUD 21046d067 PMD 0 >> [ 679.182080] Oops: 0000 [#1] SMP >> [ 679.182087] last sysfs file: /sys/devices/virtual/rc/rc0/protocols > > Hrm. Does this box by chance have multiple entries under > /sys/devices/virtual/rc/ ? This sounds like the issue this patch is > supposed to fix: > > http://git.linuxtv.org/media_tree.git?a=commitdiff;h=7a1f9f0810216466647512688dbb3179527f4e51 > > Something like an imon device would trip on that when the ubuntu 10.10 > lirc initscript starts up. Er, no, I think imon wouldn't, it has props and driver_type filled in. But something else might... -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-08 03:49:46
|
On Thu, Oct 7, 2010 at 10:45 PM, Jarod Wilson <ja...@wi...> wrote: > On Thu, Oct 7, 2010 at 11:42 PM, Jarod Wilson <ja...@wi...> wrote: >> On Thu, Oct 7, 2010 at 11:33 PM, Greg Oliver <oli...@gm...> wrote: >>> On Thu, Oct 7, 2010 at 10:29 PM, Jarod Wilson <ja...@wi...> wrote: >>>> On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: >>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>>> >>>>> It is supposedly using a cvs snapshot of 0.8.7 with a couple of >>>>> patches (ioctl kernel update or something or other).. >>>>> >>>>> The ir_core module is OOPSing for me all the time with my mceusb >>>>> transceiver.. Unloading of any lirc modules becomes impossible, and a >>>>> system reboot is required to bring back a functioning remote. >>>>> >>>>> With the changes and stuff migrating to the kernel, I guess I am just >>>>> looking for some recommendations as to how to go about alleviating the >>>>> issue. What are recommended versions of everything? Do I need a >>>>> newer kernel as well as userspace? >>>> >>>> Userspace shouldn't matter, an oops is purely a kernel issue. Get me >>>> the full oops trace, and I'll see if I can figure out what's going on. >>>> Its definitely not happening with newer kernels, so there's likely a >>>> fix already available, just needs to be added to the Ubuntu kernel. >>> >>> This is all I get (it is the same every time though..) >>> >>> >>> [ 679.182037] BUG: unable to handle kernel NULL pointer dereference >>> at 0000000000000060 >>> [ 679.182050] IP: [<ffffffffa00c41b8>] store_protocols+0x188/0x3e0 [ir_core] >>> [ 679.182070] PGD 1f7454067 PUD 21046d067 PMD 0 >>> [ 679.182080] Oops: 0000 [#1] SMP >>> [ 679.182087] last sysfs file: /sys/devices/virtual/rc/rc0/protocols >> >> Hrm. Does this box by chance have multiple entries under >> /sys/devices/virtual/rc/ ? This sounds like the issue this patch is >> supposed to fix: >> >> http://git.linuxtv.org/media_tree.git?a=commitdiff;h=7a1f9f0810216466647512688dbb3179527f4e51 >> >> Something like an imon device would trip on that when the ubuntu 10.10 >> lirc initscript starts up. > > Er, no, I think imon wouldn't, it has props and driver_type filled in. > But something else might... > Just rc0 there.. I has been steadily happening all night. The only modifications I have made to the box since yesterday was kvm. I just removed it and we'll see how it goes.. btw: this is one of the same topseed devices I sent you a while back... Next time it oops'es, I'll grab a later kernel and throw it on to see if it helps.. I'm digging through release notes to see if it has been addressed anywhere yet.. -Greg |
From: Greg O. <oli...@gm...> - 2010-10-08 12:29:08
|
On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: > On Thu, Oct 7, 2010 at 10:45 PM, Jarod Wilson <ja...@wi...> wrote: >> On Thu, Oct 7, 2010 at 11:42 PM, Jarod Wilson <ja...@wi...> wrote: >>> On Thu, Oct 7, 2010 at 11:33 PM, Greg Oliver <oli...@gm...> wrote: >>>> On Thu, Oct 7, 2010 at 10:29 PM, Jarod Wilson <ja...@wi...> wrote: >>>>> On Thu, Oct 7, 2010 at 10:47 PM, Greg Oliver <oli...@gm...> wrote: >>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >> >> Er, no, I think imon wouldn't, it has props and driver_type filled in. >> But something else might... >> > > Just rc0 there.. I has been steadily happening all night. The only > modifications I have made to the box since yesterday was kvm. I just > removed it and we'll see how it goes.. > > btw: this is one of the same topseed devices I sent you a while > back... Next time it oops'es, I'll grab a later kernel and throw it > on to see if it helps.. I'm digging through release notes to see if > it has been addressed anywhere yet.. Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It always oops'es at least 2x an hour usually.. This morning, I reloaded kvm and kvm_amd.. Oopses again... :( I guess I need to file an ubuntu bug for this.. -Greg |
From: Jarod W. <ja...@wi...> - 2010-10-08 14:02:22
|
On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver <oli...@gm...> wrote: > On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: ... >>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>> >>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>> But something else might... >>> >> >> Just rc0 there.. I has been steadily happening all night. The only >> modifications I have made to the box since yesterday was kvm. I just >> removed it and we'll see how it goes.. >> >> btw: this is one of the same topseed devices I sent you a while >> back... Next time it oops'es, I'll grab a later kernel and throw it >> on to see if it helps.. I'm digging through release notes to see if >> it has been addressed anywhere yet.. > > Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I > blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It > always oops'es at least 2x an hour usually.. This morning, I reloaded > kvm and kvm_amd.. Oopses again... :( > > I guess I need to file an ubuntu bug for this.. ?!? That's a bit of a head-scratcher... Not a clue why kvm would be causing that. I'll look at the trace again closer, wonder if I can reproduce that here... -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-08 14:34:10
|
On Fri, Oct 8, 2010 at 8:30 AM, Jarod Wilson <ja...@wi...> wrote: > On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver <oli...@gm...> wrote: >> On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: > ... >>>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>> >>>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>>> But something else might... >>>> >>> >>> Just rc0 there.. I has been steadily happening all night. The only >>> modifications I have made to the box since yesterday was kvm. I just >>> removed it and we'll see how it goes.. >>> >>> btw: this is one of the same topseed devices I sent you a while >>> back... Next time it oops'es, I'll grab a later kernel and throw it >>> on to see if it helps.. I'm digging through release notes to see if >>> it has been addressed anywhere yet.. >> >> Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I >> blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It >> always oops'es at least 2x an hour usually.. This morning, I reloaded >> kvm and kvm_amd.. Oopses again... :( >> >> I guess I need to file an ubuntu bug for this.. > > ?!? That's a bit of a head-scratcher... Not a clue why kvm would be > causing that. I'll look at the trace again closer, wonder if I can > reproduce that here... I can reproduce it here easily - could be motherboard related as well I suppose.. It's an amd phenomIIx4 based system.. I will submit the info that I had to set the acpi version to 1.0 versus 3.0 in the bios to get stability out of this thing to begin with.. This is the last *inexpensively* built computer I ever make.. It also has IR onboard, but I have it disabled in the bios and it does not show up on the system's pnp isa list.. There is no userspace kvm stuff happening, just loaded modules when it triggers. Thanks -Greg |
From: Greg O. <oli...@gm...> - 2010-10-09 02:23:26
|
On Fri, Oct 8, 2010 at 9:34 AM, Greg Oliver <oli...@gm...> wrote: > On Fri, Oct 8, 2010 at 8:30 AM, Jarod Wilson <ja...@wi...> wrote: >> On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver <oli...@gm...> wrote: >>> On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: >> ... >>>>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>>> >>>>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>>>> But something else might... >>>>> >>>> >>>> Just rc0 there.. I has been steadily happening all night. The only >>>> modifications I have made to the box since yesterday was kvm. I just >>>> removed it and we'll see how it goes.. >>>> >>>> btw: this is one of the same topseed devices I sent you a while >>>> back... Next time it oops'es, I'll grab a later kernel and throw it >>>> on to see if it helps.. I'm digging through release notes to see if >>>> it has been addressed anywhere yet.. >>> >>> Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I >>> blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It >>> always oops'es at least 2x an hour usually.. This morning, I reloaded >>> kvm and kvm_amd.. Oopses again... :( >>> >>> I guess I need to file an ubuntu bug for this.. >> >> ?!? That's a bit of a head-scratcher... Not a clue why kvm would be >> causing that. I'll look at the trace again closer, wonder if I can >> reproduce that here... > > I can reproduce it here easily - could be motherboard related as well > I suppose.. It's an amd phenomIIx4 based system.. I will submit the > info that I had to set the acpi version to 1.0 versus 3.0 in the bios > to get stability out of this thing to begin with.. This is the last > *inexpensively* built computer I ever make.. It also has IR onboard, > but I have it disabled in the bios and it does not show up on the > system's pnp isa list.. > > There is no userspace kvm stuff happening, just loaded modules when it triggers. > Well, after almost 24 hours of good times, it started again.... (without kvm :( [81516.752207] usb 5-3: USB disconnect, address 3 [81517.560197] usb 5-3: new full speed USB device using ohci_hcd and address 4 [81517.752548] usb 5-3: config 1 interface 0 altsetting 0 endpoint 0x1 has an invalid bInterval 0, changing to 32 [81517.752554] usb 5-3: config 1 interface 0 altsetting 0 endpoint 0x82 has an invalid bInterval 0, changing to 32 [81517.766532] Registered IR keymap rc-rc6-mce [81517.766607] input: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/virtual/rc/rc0/input6 [81517.766654] rc0: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008) as /devices/virtual/rc/rc0 [81517.766678] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at minor = 0 [81517.766695] mceusb 5-3:1.0: Registered Topseed Technology Corp. eHome Infrared Transceiver on usb5:4 [81634.630708] usb 5-3: USB disconnect, address 4 [81634.635117] BUG: unable to handle kernel NULL pointer dereference at 0000000000000060 [81634.635121] IP: [<ffffffffa009a1b8>] store_protocols+0x188/0x3e0 [ir_core] [81634.635128] PGD 673b067 PUD 5b91067 PMD 0 [81634.635131] Oops: 0000 [#1] SMP [81634.635133] last sysfs file: /sys/devices/virtual/rc/rc0/protocols [81634.635135] CPU 1 [81634.635136] Modules linked in: nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs snd_hda_codec_nvhdmi nvidia(P) snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi ir_lirc_codec lirc_dev snd_rawmidi snd_seq_midi_event ir_sony_decoder snd_seq snd_timer snd_seq_device ir_jvc_decoder rc_rc6_mce ir_rc6_decoder edac_core ir_rc5_decoder edac_mce_amd snd i2c_piix4 ir_nec_decoder mceusb ir_core soundcore snd_page_alloc k10temp psmouse serio_raw lp parport usbhid hid ahci r8169 libahci mii pata_atiixp [81634.635156] [81634.635159] Pid: 27273, comm: lirc Tainted: P 2.6.35-22-generic #33-Ubuntu TA880GB+/TA880GB+ [81634.635161] RIP: 0010:[<ffffffffa009a1b8>] [<ffffffffa009a1b8>] store_protocols+0x188/0x3e0 [ir_core] [81634.635165] RSP: 0018:ffff880042b33e48 EFLAGS: 00010202 [81634.635166] RAX: 0000000000000000 RBX: ffff8800067c9001 RCX: 0000000000000001 [81634.635168] RDX: ffff880225592000 RSI: ffffffffa009b254 RDI: ffff8800067c9004 [81634.635170] RBP: ffff880042b33e88 R08: 0000000000000035 R09: 0000000000000035 [81634.635171] R10: 0000000000000001 R11: 0000000000000000 R12: ffff88017e944000 [81634.635172] R13: 0000000000000001 R14: 0000000000000005 R15: 0000000000000000 [81634.635174] FS: 00007fcb4edf7700(0000) GS:ffff880001e40000(0000) knlGS:0000000000000000 [81634.635176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [81634.635178] CR2: 0000000000000060 CR3: 00000000067d1000 CR4: 00000000000006e0 [81634.635179] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [81634.635181] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [81634.635183] Process lirc (pid: 27273, threadinfo ffff880042b32000, task ffff8800022d16e0) [81634.635184] Stack: [81634.635185] ffff880042b33e78 0000000000000001 ffff8802255922c0 ffff8802255922c0 [81634.635187] <0> ffff880042b33f48 ffff8801e4994870 ffffffff8164ac00 ffff88017e944010 [81634.635190] <0> ffff880042b33e98 ffffffff81383b00 ffff880042b33ee8 ffffffff811bd8d2 [81634.635193] Call Trace: [81634.635199] [<ffffffff81383b00>] dev_attr_store+0x20/0x30 [81634.635203] [<ffffffff811bd8d2>] sysfs_write_file+0xf2/0x180 [81634.635206] [<ffffffff81152948>] vfs_write+0xb8/0x1a0 [81634.635210] [<ffffffff8158ceae>] ? do_page_fault+0x15e/0x350 [81634.635212] [<ffffffff811531c1>] sys_write+0x51/0x80 [81634.635216] [<ffffffff8100a0f2>] system_call_fastpath+0x16/0x1b [81634.635217] Code: 44 ff ff ff eb 05 90 90 90 90 90 45 84 ff 48 8b 5d c8 0f 84 68 ff ff ff 48 f7 d3 48 21 c3 e9 5d ff ff ff 49 8b 84 24 90 02 00 00 <48> 8b 40 60 e9 3c ff ff ff eb 05 90 90 90 90 90 48 83 c3 01 45 [81634.635235] RIP [<ffffffffa009a1b8>] store_protocols+0x188/0x3e0 [ir_core] [81634.635239] RSP <ffff880042b33e48> [81634.635240] CR2: 0000000000000060 [81634.635242] ---[ end trace c95938c3dd8ebe32 ]--- |
From: Jarod W. <ja...@wi...> - 2010-10-12 21:07:34
|
On Oct 8, 2010, at 10:23 PM, Greg Oliver wrote: > On Fri, Oct 8, 2010 at 9:34 AM, Greg Oliver <oli...@gm...> wrote: >> On Fri, Oct 8, 2010 at 8:30 AM, Jarod Wilson <ja...@wi...> wrote: >>> On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver <oli...@gm...> wrote: >>>> On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: >>> ... >>>>>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>>>> >>>>>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>>>>> But something else might... >>>>>> >>>>> >>>>> Just rc0 there.. I has been steadily happening all night. The only >>>>> modifications I have made to the box since yesterday was kvm. I just >>>>> removed it and we'll see how it goes.. >>>>> >>>>> btw: this is one of the same topseed devices I sent you a while >>>>> back... Next time it oops'es, I'll grab a later kernel and throw it >>>>> on to see if it helps.. I'm digging through release notes to see if >>>>> it has been addressed anywhere yet.. >>>> >>>> Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I >>>> blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It >>>> always oops'es at least 2x an hour usually.. This morning, I reloaded >>>> kvm and kvm_amd.. Oopses again... :( >>>> >>>> I guess I need to file an ubuntu bug for this.. >>> >>> ?!? That's a bit of a head-scratcher... Not a clue why kvm would be >>> causing that. I'll look at the trace again closer, wonder if I can >>> reproduce that here... >> >> I can reproduce it here easily - could be motherboard related as well >> I suppose.. It's an amd phenomIIx4 based system.. I will submit the >> info that I had to set the acpi version to 1.0 versus 3.0 in the bios >> to get stability out of this thing to begin with.. This is the last >> *inexpensively* built computer I ever make.. It also has IR onboard, >> but I have it disabled in the bios and it does not show up on the >> system's pnp isa list.. >> >> There is no userspace kvm stuff happening, just loaded modules when it triggers. >> > > Well, after almost 24 hours of good times, it started again.... > (without kvm :( So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-12 22:25:35
|
On Tue, Oct 12, 2010 at 4:07 PM, Jarod Wilson <ja...@wi...> wrote: > On Oct 8, 2010, at 10:23 PM, Greg Oliver wrote: > >> On Fri, Oct 8, 2010 at 9:34 AM, Greg Oliver <oli...@gm...> wrote: >>> On Fri, Oct 8, 2010 at 8:30 AM, Jarod Wilson <ja...@wi...> wrote: >>>> On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver <oli...@gm...> wrote: >>>>> On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver <oli...@gm...> wrote: >>>> ... >>>>>>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>>>>> >>>>>>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>>>>>> But something else might... >>>>>>> >>>>>> >>>>>> Just rc0 there.. I has been steadily happening all night. The only >>>>>> modifications I have made to the box since yesterday was kvm. I just >>>>>> removed it and we'll see how it goes.. >>>>>> >>>>>> btw: this is one of the same topseed devices I sent you a while >>>>>> back... Next time it oops'es, I'll grab a later kernel and throw it >>>>>> on to see if it helps.. I'm digging through release notes to see if >>>>>> it has been addressed anywhere yet.. >>>>> >>>>> Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I >>>>> blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It >>>>> always oops'es at least 2x an hour usually.. This morning, I reloaded >>>>> kvm and kvm_amd.. Oopses again... :( >>>>> >>>>> I guess I need to file an ubuntu bug for this.. >>>> >>>> ?!? That's a bit of a head-scratcher... Not a clue why kvm would be >>>> causing that. I'll look at the trace again closer, wonder if I can >>>> reproduce that here... >>> >>> I can reproduce it here easily - could be motherboard related as well >>> I suppose.. It's an amd phenomIIx4 based system.. I will submit the >>> info that I had to set the acpi version to 1.0 versus 3.0 in the bios >>> to get stability out of this thing to begin with.. This is the last >>> *inexpensively* built computer I ever make.. It also has IR onboard, >>> but I have it disabled in the bios and it does not show up on the >>> system's pnp isa list.. >>> >>> There is no userspace kvm stuff happening, just loaded modules when it triggers. >>> >> >> Well, after almost 24 hours of good times, it started again.... >> (without kvm :( > > So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). > They pushed a kernel today that exhibits the same behavior. I never enable their pre or testing repos though, so it may well be there already. I'm not too sure where to get patches for all of this now that it is in the kernel. I assume the same location in your "A Call to testers" thread? Thanks again! |
From: Jarod W. <ja...@wi...> - 2010-10-13 01:13:55
|
On Tue, Oct 12, 2010 at 6:25 PM, Greg Oliver <oli...@gm...> wrote: > On Tue, Oct 12, 2010 at 4:07 PM, Jarod Wilson <ja...@wi...> wrote: >> On Oct 8, 2010, at 10:23 PM, Greg Oliver wrote: ... >> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >> > > They pushed a kernel today that exhibits the same behavior. I never > enable their pre or testing repos though, so it may well be there > already. Not likely. They're still discussing/considering how to approach this, and I don't see anything committed in the main maverick kernel git tree. > I'm not too sure where to get patches for all of this now > that it is in the kernel. I assume the same location in your "A Call > to testers" thread? Nope. These bits are all in the upstream kernel or in a subsystem maintainer's tree, pending pull for 2.6.37-rc1 when the merge window opens. I've got backports of these that I put into the Fedora 14 kernels, and posted somewhere for the Ubuntu folks to take a look at. Patches are here: http://people.redhat.com/~jwilson/misc/ir-core-2.6.35/ The ir-core-update-2, ir-core-update-3 and lirc-ioctl-compat-fixups are the three not already in the Ubuntu kernels, and one of those carries the changes that I *think* will prevent the oops you're seeing. -- Jarod Wilson ja...@wi... |
From: Douglas P. <Dou...@pe...> - 2010-10-13 11:03:58
|
On 13/10/2010 11:25 a.m., Greg Oliver wrote: > On Tue, Oct 12, 2010 at 4:07 PM, Jarod Wilson<ja...@wi...> wrote: >> On Oct 8, 2010, at 10:23 PM, Greg Oliver wrote: >> >>> On Fri, Oct 8, 2010 at 9:34 AM, Greg Oliver<oli...@gm...> wrote: >>>> On Fri, Oct 8, 2010 at 8:30 AM, Jarod Wilson<ja...@wi...> wrote: >>>>> On Fri, Oct 8, 2010 at 8:29 AM, Greg Oliver<oli...@gm...> wrote: >>>>>> On Thu, Oct 7, 2010 at 10:49 PM, Greg Oliver<oli...@gm...> wrote: >>>>> ... >>>>>>>>>>>> I've been testing ubuntu beta 10.10 on one of mythtv systems. >>>>>>>> Er, no, I think imon wouldn't, it has props and driver_type filled in. >>>>>>>> But something else might... >>>>>>>> >>>>>>> Just rc0 there.. I has been steadily happening all night. The only >>>>>>> modifications I have made to the box since yesterday was kvm. I just >>>>>>> removed it and we'll see how it goes.. >>>>>>> >>>>>>> btw: this is one of the same topseed devices I sent you a while >>>>>>> back... Next time it oops'es, I'll grab a later kernel and throw it >>>>>>> on to see if it helps.. I'm digging through release notes to see if >>>>>>> it has been addressed anywhere yet.. >>>>>> Hmmmm... I hate to say it, but kvm was to blame.. At last oops, I >>>>>> blacklisted kvm and kvm_amd before reboot.. 4 hours of goodness. It >>>>>> always oops'es at least 2x an hour usually.. This morning, I reloaded >>>>>> kvm and kvm_amd.. Oopses again... :( >>>>>> >>>>>> I guess I need to file an ubuntu bug for this.. >>>>> ?!? That's a bit of a head-scratcher... Not a clue why kvm would be >>>>> causing that. I'll look at the trace again closer, wonder if I can >>>>> reproduce that here... >>>> I can reproduce it here easily - could be motherboard related as well >>>> I suppose.. It's an amd phenomIIx4 based system.. I will submit the >>>> info that I had to set the acpi version to 1.0 versus 3.0 in the bios >>>> to get stability out of this thing to begin with.. This is the last >>>> *inexpensively* built computer I ever make.. It also has IR onboard, >>>> but I have it disabled in the bios and it does not show up on the >>>> system's pnp isa list.. >>>> >>>> There is no userspace kvm stuff happening, just loaded modules when it triggers. >>>> >>> Well, after almost 24 hours of good times, it started again.... >>> (without kvm :( >> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >> > They pushed a kernel today that exhibits the same behavior. I never > enable their pre or testing repos though, so it may well be there > already. I'm not too sure where to get patches for all of this now > that it is in the kernel. I assume the same location in your "A Call > to testers" thread? > > Thanks again! > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb Would this be related to https://bugs.launchpad.net/bugs/642517 ? Cheers Douglas. |
From: Jarod W. <ja...@wi...> - 2010-10-13 13:09:58
|
On Wednesday, October 13, 2010, Douglas Pearless <Dou...@pe...> wrote: ... >>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>> >> They pushed a kernel today that exhibits the same behavior. I never >> enable their pre or testing repos though, so it may well be there >> already. I'm not too sure where to get patches for all of this now >> that it is in the kernel. I assume the same location in your "A Call >> to testers" thread? >> >> > > Would this be related to > > https://bugs.launchpad.net/bugs/642517 ? Yeah, looks like the same issue. Greg, did you have a bug filed too? They ought to be duped together. --jarod -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-13 16:10:42
|
On Wed, Oct 13, 2010 at 8:09 AM, Jarod Wilson <ja...@wi...> wrote: > On Wednesday, October 13, 2010, Douglas Pearless > <Dou...@pe...> wrote: > ... >>>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>>> >>> They pushed a kernel today that exhibits the same behavior. I never >>> enable their pre or testing repos though, so it may well be there >>> already. I'm not too sure where to get patches for all of this now >>> that it is in the kernel. I assume the same location in your "A Call >>> to testers" thread? >>> >>> >> >> Would this be related to >> >> https://bugs.launchpad.net/bugs/642517 ? > > Yeah, looks like the same issue. Greg, did you have a bug filed too? > They ought to be duped together. > Yes, that is the bug I subscribed to. Odd thing though. Once I actually *looked* at the oops(es) - I noticed it always started with a "usb disconnect" as the first line. This seemed strange, and was what was causing lirc to oops. Not the other way around. My entire USB subsystem was dead. The keyboard and mouse (bios providing legacy service) were both still operational, but no new devices would work. I disabled acpi power on/off from USB as well as from the keyboard/mouse and the issue has gone (or not shown up since then).. Looks like a larger kernel issue with this USB combo. I guess ir_core should not die from something like this, but like I said, it seems it is a sympton of a larger issue. Ubuntu does not ship USB modules any longer, so I am going to recompile it again with USB as modules and debug turned on to see if I can get some more relevant into. It has been working since I changed the setting last night, and I'll let it run on until it either dies again (and I'll be wrong once more!), or 1 full day. It is the first time it has ever remained running overnight though.. Work has me running today, so I probably will not get to any of this until tonight though. Thanks -Greg |
From: Greg O. <oli...@gm...> - 2010-10-14 01:16:06
|
On Wed, Oct 13, 2010 at 11:10 AM, Greg Oliver <oli...@gm...> wrote: > On Wed, Oct 13, 2010 at 8:09 AM, Jarod Wilson <ja...@wi...> wrote: >> On Wednesday, October 13, 2010, Douglas Pearless >> <Dou...@pe...> wrote: >> ... >>>>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>>>> >>>> They pushed a kernel today that exhibits the same behavior. I never >>>> enable their pre or testing repos though, so it may well be there >>>> already. I'm not too sure where to get patches for all of this now >>>> that it is in the kernel. I assume the same location in your "A Call >>>> to testers" thread? >>>> >>>> >>> >>> Would this be related to >>> >>> https://bugs.launchpad.net/bugs/642517 ? >> >> Yeah, looks like the same issue. Greg, did you have a bug filed too? >> They ought to be duped together. >> > > Yes, that is the bug I subscribed to. Odd thing though. Once I > actually *looked* at the oops(es) - I noticed it always started with a > "usb disconnect" as the first line. This seemed strange, and was what > was causing lirc to oops. Not the other way around. > > My entire USB subsystem was dead. The keyboard and mouse (bios > providing legacy service) were both still operational, but no new > devices would work. I disabled acpi power on/off from USB as well as > from the keyboard/mouse and the issue has gone (or not shown up since > then).. Looks like a larger kernel issue with this USB combo. > > I guess ir_core should not die from something like this, but like I > said, it seems it is a sympton of a larger issue. Ubuntu does not > ship USB modules any longer, so I am going to recompile it again with > USB as modules and debug turned on to see if I can get some more > relevant into. > > It has been working since I changed the setting last night, and I'll > let it run on until it either dies again (and I'll be wrong once > more!), or 1 full day. It is the first time it has ever remained > running overnight though.. > > Work has me running today, so I probably will not get to any of this > until tonight though. > Hi Jarod - Would you still like me to test these patches with my system. I can easily re-flip the bios switches and give it a go.. The problem is even though ir_core may oops (or hopefully will not???), my whole usb system dies. Not sure how to proceed with this one.. Something in my bios and 2.6.35's USB are not playing nice. Just let me know and I will still give it a go. |
From: Greg O. <oli...@gm...> - 2010-10-14 01:58:37
|
On Wed, Oct 13, 2010 at 8:15 PM, Greg Oliver <oli...@gm...> wrote: > On Wed, Oct 13, 2010 at 11:10 AM, Greg Oliver <oli...@gm...> wrote: >> On Wed, Oct 13, 2010 at 8:09 AM, Jarod Wilson <ja...@wi...> wrote: >>> On Wednesday, October 13, 2010, Douglas Pearless >>> <Dou...@pe...> wrote: >>> ... >>>>>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>>>>> >>>>> They pushed a kernel today that exhibits the same behavior. I never >>>>> enable their pre or testing repos though, so it may well be there >>>>> already. I'm not too sure where to get patches for all of this now >>>>> that it is in the kernel. I assume the same location in your "A Call >>>>> to testers" thread? >>>>> >>>>> >>>> >>>> Would this be related to >>>> >>>> https://bugs.launchpad.net/bugs/642517 ? >>> >>> Yeah, looks like the same issue. Greg, did you have a bug filed too? >>> They ought to be duped together. >>> >> >> Yes, that is the bug I subscribed to. Odd thing though. Once I >> actually *looked* at the oops(es) - I noticed it always started with a >> "usb disconnect" as the first line. This seemed strange, and was what >> was causing lirc to oops. Not the other way around. >> >> My entire USB subsystem was dead. The keyboard and mouse (bios >> providing legacy service) were both still operational, but no new >> devices would work. I disabled acpi power on/off from USB as well as >> from the keyboard/mouse and the issue has gone (or not shown up since >> then).. Looks like a larger kernel issue with this USB combo. >> >> I guess ir_core should not die from something like this, but like I >> said, it seems it is a sympton of a larger issue. Ubuntu does not >> ship USB modules any longer, so I am going to recompile it again with >> USB as modules and debug turned on to see if I can get some more >> relevant into. >> >> It has been working since I changed the setting last night, and I'll >> let it run on until it either dies again (and I'll be wrong once >> more!), or 1 full day. It is the first time it has ever remained >> running overnight though.. >> >> Work has me running today, so I probably will not get to any of this >> until tonight though. >> > > Hi Jarod - > > Would you still like me to test these patches with my system. I can > easily re-flip the bios switches and give it a go.. The problem is > even though ir_core may oops (or hopefully will not???), my whole usb > system dies. Not sure how to proceed with this one.. Something in my > bios and 2.6.35's USB are not playing nice. > > Just let me know and I will still give it a go. > Nevermind - it just happened again. I'll be testing the patches as soon as my current recordings stop. |
From: Greg O. <oli...@gm...> - 2010-10-14 03:57:51
|
On Wed, Oct 13, 2010 at 8:58 PM, Greg Oliver <oli...@gm...> wrote: > On Wed, Oct 13, 2010 at 8:15 PM, Greg Oliver <oli...@gm...> wrote: >> On Wed, Oct 13, 2010 at 11:10 AM, Greg Oliver <oli...@gm...> wrote: >>> On Wed, Oct 13, 2010 at 8:09 AM, Jarod Wilson <ja...@wi...> wrote: >>>> On Wednesday, October 13, 2010, Douglas Pearless >>>> <Dou...@pe...> wrote: >>>> ... >>>>>>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>>>>>> >>>>>> They pushed a kernel today that exhibits the same behavior. I never >>>>>> enable their pre or testing repos though, so it may well be there >>>>>> already. I'm not too sure where to get patches for all of this now >>>>>> that it is in the kernel. I assume the same location in your "A Call >>>>>> to testers" thread? >>>>>> >>>>>> >>>>> >>>>> Would this be related to >>>>> >>>>> https://bugs.launchpad.net/bugs/642517 ? >>>> >>>> Yeah, looks like the same issue. Greg, did you have a bug filed too? >>>> They ought to be duped together. >>>> >>> >>> Yes, that is the bug I subscribed to. Odd thing though. Once I >>> actually *looked* at the oops(es) - I noticed it always started with a >>> "usb disconnect" as the first line. This seemed strange, and was what >>> was causing lirc to oops. Not the other way around. >>> >>> My entire USB subsystem was dead. The keyboard and mouse (bios >>> providing legacy service) were both still operational, but no new >>> devices would work. I disabled acpi power on/off from USB as well as >>> from the keyboard/mouse and the issue has gone (or not shown up since >>> then).. Looks like a larger kernel issue with this USB combo. >>> >>> I guess ir_core should not die from something like this, but like I >>> said, it seems it is a sympton of a larger issue. Ubuntu does not >>> ship USB modules any longer, so I am going to recompile it again with >>> USB as modules and debug turned on to see if I can get some more >>> relevant into. >>> >>> It has been working since I changed the setting last night, and I'll >>> let it run on until it either dies again (and I'll be wrong once >>> more!), or 1 full day. It is the first time it has ever remained >>> running overnight though.. >>> >>> Work has me running today, so I probably will not get to any of this >>> until tonight though. >>> >> >> Hi Jarod - >> >> Would you still like me to test these patches with my system. I can >> easily re-flip the bios switches and give it a go.. The problem is >> even though ir_core may oops (or hopefully will not???), my whole usb >> system dies. Not sure how to proceed with this one.. Something in my >> bios and 2.6.35's USB are not playing nice. >> >> Just let me know and I will still give it a go. >> > > Nevermind - it just happened again. I'll be testing the patches as > soon as my current recordings stop. > OK, with the patches, I get 2 key presses played for every 1 real press, plus the same oops eventually with more debugs in the modules though.. [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode 0x69 [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote Transceiver (1784:0008): key down event, key 0x0069, scancode 0x800f0420 [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) [ 3165.110588] usb 5-1: USB disconnect, address 2 [ 3165.111120] ir_input_unregister: Freed keycode table [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] [ 3165.145305] PGD d848067 PUD d934067 PMD 0 [ 3165.145315] Oops: 0000 [#1] SMP [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols [ 3165.145328] CPU 2 [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii libahci [ 3165.145408] [ 3165.145416] Pid: 3069, comm: lirc Tainted: P 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) knlGS:0000000000000000 [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, task ffff8801932fc4a0) [ 3165.145509] Stack: [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 0000000001883ad0 [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 ffff88022dac79b0 [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 ffff88022ad12410 [ 3165.145542] Call Trace: [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 c3 80 [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] [ 3165.145699] RSP <ffff880037b33e18> [ 3165.145703] CR2: 0000000000000048 [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- |
From: Douglas P. <Dou...@pe...> - 2010-10-14 07:04:07
|
I have just upgraded to new kernel (yesterday) and my problem has stopped, perhaps you could try the same? Cheers Douglas On 14/10/2010 4:57 p.m., Greg Oliver wrote: > On Wed, Oct 13, 2010 at 8:58 PM, Greg Oliver<oli...@gm...> wrote: >> On Wed, Oct 13, 2010 at 8:15 PM, Greg Oliver<oli...@gm...> wrote: >>> On Wed, Oct 13, 2010 at 11:10 AM, Greg Oliver<oli...@gm...> wrote: >>>> On Wed, Oct 13, 2010 at 8:09 AM, Jarod Wilson<ja...@wi...> wrote: >>>>> On Wednesday, October 13, 2010, Douglas Pearless >>>>> <Dou...@pe...> wrote: >>>>> ... >>>>>>>> So I'm still not sure *why* this is triggering, but my best guess is that *something* is attempting to write a null (or otherwise unexpectedly formatted) string to /sys/devices/virtual/rc/rc0/protocols, which is triggering the oops in store_protocols. There's been updates to that function upstream that should avoid this problem (though I also just spotted another problem in there that I'm going to send a patch upstream for). The patches I've pointed the Canonical kernel folks at ought to remedy this, but its unclear right now if they're going to merge the patches in an updated kernel, build a dkms module, or what (or when). >>>>>>>> >>>>>>> They pushed a kernel today that exhibits the same behavior. I never >>>>>>> enable their pre or testing repos though, so it may well be there >>>>>>> already. I'm not too sure where to get patches for all of this now >>>>>>> that it is in the kernel. I assume the same location in your "A Call >>>>>>> to testers" thread? >>>>>>> >>>>>>> >>>>>> Would this be related to >>>>>> >>>>>> https://bugs.launchpad.net/bugs/642517 ? >>>>> Yeah, looks like the same issue. Greg, did you have a bug filed too? >>>>> They ought to be duped together. >>>>> >>>> Yes, that is the bug I subscribed to. Odd thing though. Once I >>>> actually *looked* at the oops(es) - I noticed it always started with a >>>> "usb disconnect" as the first line. This seemed strange, and was what >>>> was causing lirc to oops. Not the other way around. >>>> >>>> My entire USB subsystem was dead. The keyboard and mouse (bios >>>> providing legacy service) were both still operational, but no new >>>> devices would work. I disabled acpi power on/off from USB as well as >>>> from the keyboard/mouse and the issue has gone (or not shown up since >>>> then).. Looks like a larger kernel issue with this USB combo. >>>> >>>> I guess ir_core should not die from something like this, but like I >>>> said, it seems it is a sympton of a larger issue. Ubuntu does not >>>> ship USB modules any longer, so I am going to recompile it again with >>>> USB as modules and debug turned on to see if I can get some more >>>> relevant into. >>>> >>>> It has been working since I changed the setting last night, and I'll >>>> let it run on until it either dies again (and I'll be wrong once >>>> more!), or 1 full day. It is the first time it has ever remained >>>> running overnight though.. >>>> >>>> Work has me running today, so I probably will not get to any of this >>>> until tonight though. >>>> >>> Hi Jarod - >>> >>> Would you still like me to test these patches with my system. I can >>> easily re-flip the bios switches and give it a go.. The problem is >>> even though ir_core may oops (or hopefully will not???), my whole usb >>> system dies. Not sure how to proceed with this one.. Something in my >>> bios and 2.6.35's USB are not playing nice. >>> >>> Just let me know and I will still give it a go. >>> >> Nevermind - it just happened again. I'll be testing the patches as >> soon as my current recordings stop. >> > OK, with the patches, I get 2 key presses played for every 1 real > press, plus the same oops eventually with more debugs in the modules > though.. > > [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) > [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome > Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode > 0x69 > [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote > Transceiver (1784:0008): key down event, key 0x0069, scancode > 0x800f0420 > [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) > [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) > [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) > [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) > [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) > [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.110588] usb 5-1: USB disconnect, address 2 > [ 3165.111120] ir_input_unregister: Freed keycode table > [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference > at 0000000000000048 > [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145305] PGD d848067 PUD d934067 PMD 0 > [ 3165.145315] Oops: 0000 [#1] SMP > [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols > [ 3165.145328] CPU 2 > [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache > nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq > snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp > sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder > ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder > i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb > serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii > libahci > [ 3165.145408] > [ 3165.145416] Pid: 3069, comm: lirc Tainted: P > 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ > [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] > store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 > [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 > [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 > [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 > [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 > [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 > [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) > knlGS:0000000000000000 > [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 > [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, > task ffff8801932fc4a0) > [ 3165.145509] Stack: > [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 > 0000000001883ad0 > [ 3165.145521]<0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 > ffff88022dac79b0 > [ 3165.145531]<0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 > ffff88022ad12410 > [ 3165.145542] Call Trace: > [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 > [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 > [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 > [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 > [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 > [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 > [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b > [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 > a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 > 98 02 00 00<48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 > c3 80 > [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145699] RSP<ffff880037b33e18> > [ 3165.145703] CR2: 0000000000000048 > [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2& L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today. > http://p.sf.net/sfu/beautyoftheweb |
From: Jarod W. <ja...@wi...> - 2010-10-14 14:54:20
|
On Oct 13, 2010, at 11:57 PM, Greg Oliver wrote: ... > OK, with the patches, I get 2 key presses played for every 1 real > press, Is it really 2 key presses, or is it press + repeat? ir-core doesn't do any repeat filtering, and there was actually a repeat bug fixed in those patches, so this isn't entirely unexpected. > plus the same oops eventually with more debugs in the modules > though.. Okay, so it seems the usb disconnect is what's triggering this. And I think I'm starting to get a decent idea of why I'm not seeing this myself. The ubuntu lirc packages have some udev bits that re-run the lirc initscript on device plug/unplug, and one of the things the initscript does is poke the protocols sysfs node, which is what triggers the call to store_protocols. I think we're racing with the disconnect here. I'm not sure if we need to add some locking, or just bail from store_protocols if ir_dev is NULL and call it good. > [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) > [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome > Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode > 0x69 > [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote > Transceiver (1784:0008): key down event, key 0x0069, scancode > 0x800f0420 > [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) > [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) > [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) > [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) > [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) > [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) > [ 3165.110588] usb 5-1: USB disconnect, address 2 > [ 3165.111120] ir_input_unregister: Freed keycode table > [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference > at 0000000000000048 > [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145305] PGD d848067 PUD d934067 PMD 0 > [ 3165.145315] Oops: 0000 [#1] SMP > [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols > [ 3165.145328] CPU 2 > [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache > nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec > snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq > snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp > sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder > ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder > i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb > serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii > libahci > [ 3165.145408] > [ 3165.145416] Pid: 3069, comm: lirc Tainted: P > 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ > [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] > store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 > [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 > [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 > [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 > [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 > [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 > [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) > knlGS:0000000000000000 > [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 > [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 > [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 > [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, > task ffff8801932fc4a0) > [ 3165.145509] Stack: > [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 > 0000000001883ad0 > [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 > ffff88022dac79b0 > [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 > ffff88022ad12410 > [ 3165.145542] Call Trace: > [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 > [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 > [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 > [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 > [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 > [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 > [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b > [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 > a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 > 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 > c3 80 > [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] > [ 3165.145699] RSP <ffff880037b33e18> > [ 3165.145703] CR2: 0000000000000048 > [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-14 14:54:24
|
On Thu, Oct 14, 2010 at 9:47 AM, Jarod Wilson <ja...@wi...> wrote: > On Oct 13, 2010, at 11:57 PM, Greg Oliver wrote: > ... >> OK, with the patches, I get 2 key presses played for every 1 real >> press, > > Is it really 2 key presses, or is it press + repeat? ir-core doesn't do any repeat filtering, and there was actually a repeat bug fixed in those patches, so this isn't entirely unexpected. > > >> plus the same oops eventually with more debugs in the modules >> though.. > > Okay, so it seems the usb disconnect is what's triggering this. And I think I'm starting to get a decent idea of why I'm not seeing this myself. The ubuntu lirc packages have some udev bits that re-run the lirc initscript on device plug/unplug, and one of the things the initscript does is poke the protocols sysfs node, which is what triggers the call to store_protocols. I think we're racing with the disconnect here. I'm not sure if we need to add some locking, or just bail from store_protocols if ir_dev is NULL and call it good. I could not take it anymore last night, and just reverted to the old modules... I am willing to test stuff out though - I can switch back and forth to test if you need me to - just let me know.. >> [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) >> [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome >> Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode >> 0x69 >> [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote >> Transceiver (1784:0008): key down event, key 0x0069, scancode >> 0x800f0420 >> [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) >> [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) >> [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) >> [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) >> [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) >> [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.110588] usb 5-1: USB disconnect, address 2 >> [ 3165.111120] ir_input_unregister: Freed keycode table >> [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference >> at 0000000000000048 >> [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145305] PGD d848067 PUD d934067 PMD 0 >> [ 3165.145315] Oops: 0000 [#1] SMP >> [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols >> [ 3165.145328] CPU 2 >> [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache >> nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec >> snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq >> snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp >> sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder >> ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder >> i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb >> serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii >> libahci >> [ 3165.145408] >> [ 3165.145416] Pid: 3069, comm: lirc Tainted: P >> 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ >> [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] >> store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 >> [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 >> [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 >> [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 >> [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 >> [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 >> [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) >> knlGS:0000000000000000 >> [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 >> [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, >> task ffff8801932fc4a0) >> [ 3165.145509] Stack: >> [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 >> 0000000001883ad0 >> [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 >> ffff88022dac79b0 >> [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 >> ffff88022ad12410 >> [ 3165.145542] Call Trace: >> [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 >> [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 >> [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 >> [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 >> [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 >> [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 >> [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b >> [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 >> a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 >> 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 >> c3 80 >> [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145699] RSP <ffff880037b33e18> >> [ 3165.145703] CR2: 0000000000000048 >> [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- > > -- |
From: Mauro C. C. <mc...@re...> - 2010-10-14 15:06:54
|
Em 14-10-2010 11:47, Jarod Wilson escreveu: > On Oct 13, 2010, at 11:57 PM, Greg Oliver wrote: > ... >> OK, with the patches, I get 2 key presses played for every 1 real >> press, > > Is it really 2 key presses, or is it press + repeat? ir-core doesn't do any repeat filtering, and there was actually a repeat bug fixed in those patches, so this isn't entirely unexpected. > > >> plus the same oops eventually with more debugs in the modules >> though.. > > Okay, so it seems the usb disconnect is what's triggering this. And I think I'm starting to get a decent idea of why I'm not seeing this myself. The ubuntu lirc packages have some udev bits that re-run the lirc initscript on device plug/unplug, and one of the things the initscript does is poke the protocols sysfs node, which is what triggers the call to store_protocols. I think we're racing with the disconnect here. I'm not sure if we need to add some locking, or just bail from store_protocols if ir_dev is NULL and call it good. > > >> [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) >> [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome >> Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode >> 0x69 >> [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote >> Transceiver (1784:0008): key down event, key 0x0069, scancode >> 0x800f0420 >> [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) >> [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) >> [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) >> [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) >> [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) >> [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >> [ 3165.110588] usb 5-1: USB disconnect, address 2 >> [ 3165.111120] ir_input_unregister: Freed keycode table >> [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference >> at 0000000000000048 >> [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145305] PGD d848067 PUD d934067 PMD 0 >> [ 3165.145315] Oops: 0000 [#1] SMP >> [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols >> [ 3165.145328] CPU 2 >> [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache >> nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec >> snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq >> snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp >> sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder >> ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder >> i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb >> serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii >> libahci >> [ 3165.145408] >> [ 3165.145416] Pid: 3069, comm: lirc Tainted: P >> 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ >> [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] >> store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 >> [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 >> [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 >> [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 >> [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 >> [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 >> [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) >> knlGS:0000000000000000 >> [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 >> [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >> [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, >> task ffff8801932fc4a0) >> [ 3165.145509] Stack: >> [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 >> 0000000001883ad0 >> [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 >> ffff88022dac79b0 >> [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 >> ffff88022ad12410 >> [ 3165.145542] Call Trace: >> [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 >> [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 >> [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 >> [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 >> [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 >> [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 >> [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b >> [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 >> a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 >> 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 >> c3 80 >> [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >> [ 3165.145699] RSP <ffff880037b33e18> >> [ 3165.145703] CR2: 0000000000000048 >> [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- > Hmm... see if the enclosed patch helps. --- V4L/DVB: ir: avoid race conditions at device disconnect It is possible that, while ir_unregister_class() is handling, some application could try to access the sysfs nodes, causing an OOPS. Signed-off-by: Mauro Carvalho Chehab <mc...@re...> diff --git a/drivers/media/IR/ir-sysfs.c b/drivers/media/IR/ir-sysfs.c index dab074e..949b055 100644 --- a/drivers/media/IR/ir-sysfs.c +++ b/drivers/media/IR/ir-sysfs.c @@ -68,6 +68,10 @@ static ssize_t show_protocols(struct device *d, char *tmp = buf; int i; + /* Device is being removed */ + if (!ir_dev) + return -EINVAL; + if (ir_dev->props->driver_type == RC_DRIVER_SCANCODE) { enabled = ir_dev->rc_tab.ir_type; allowed = ir_dev->props->allowed_protos; @@ -122,6 +126,10 @@ static ssize_t store_protocols(struct device *d, int rc, i, count = 0; unsigned long flags; + /* Device is being removed */ + if (!ir_dev) + return -EINVAL; + if (ir_dev->props && ir_dev->props->driver_type == RC_DRIVER_SCANCODE) type = ir_dev->rc_tab.ir_type; else @@ -305,6 +313,7 @@ void ir_unregister_class(struct input_dev *input_dev) { struct ir_input_dev *ir_dev = input_get_drvdata(input_dev); + input_set_drvdata(input_dev, NULL); clear_bit(ir_dev->devno, &ir_core_dev_number); input_unregister_device(input_dev); device_del(&ir_dev->dev); |
From: Jarod W. <ja...@wi...> - 2010-10-14 15:19:07
|
On Oct 14, 2010, at 11:06 AM, Mauro Carvalho Chehab wrote: > Em 14-10-2010 11:47, Jarod Wilson escreveu: >> On Oct 13, 2010, at 11:57 PM, Greg Oliver wrote: >> ... >>> OK, with the patches, I get 2 key presses played for every 1 real >>> press, >> >> Is it really 2 key presses, or is it press + repeat? ir-core doesn't do any repeat filtering, and there was actually a repeat bug fixed in those patches, so this isn't entirely unexpected. >> >> >>> plus the same oops eventually with more debugs in the modules >>> though.. >> >> Okay, so it seems the usb disconnect is what's triggering this. And I think I'm starting to get a decent idea of why I'm not seeing this myself. The ubuntu lirc packages have some udev bits that re-run the lirc initscript on device plug/unplug, and one of the things the initscript does is poke the protocols sysfs node, which is what triggers the call to store_protocols. I think we're racing with the disconnect here. I'm not sure if we need to add some locking, or just bail from store_protocols if ir_dev is NULL and call it good. >> >> >>> [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) >>> [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome >>> Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode >>> 0x69 >>> [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote >>> Transceiver (1784:0008): key down event, key 0x0069, scancode >>> 0x800f0420 >>> [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) >>> [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) >>> [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) >>> [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) >>> [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) >>> [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>> [ 3165.110588] usb 5-1: USB disconnect, address 2 >>> [ 3165.111120] ir_input_unregister: Freed keycode table >>> [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference >>> at 0000000000000048 >>> [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >>> [ 3165.145305] PGD d848067 PUD d934067 PMD 0 >>> [ 3165.145315] Oops: 0000 [#1] SMP >>> [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols >>> [ 3165.145328] CPU 2 >>> [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache >>> nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec >>> snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq >>> snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp >>> sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder >>> ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder >>> i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb >>> serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii >>> libahci >>> [ 3165.145408] >>> [ 3165.145416] Pid: 3069, comm: lirc Tainted: P >>> 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ >>> [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] >>> store_protocols+0x20a/0x2d0 [ir_core] >>> [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 >>> [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 >>> [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 >>> [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 >>> [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 >>> [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 >>> [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) >>> knlGS:0000000000000000 >>> [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>> [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 >>> [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>> [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>> [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, >>> task ffff8801932fc4a0) >>> [ 3165.145509] Stack: >>> [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 >>> 0000000001883ad0 >>> [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 >>> ffff88022dac79b0 >>> [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 >>> ffff88022ad12410 >>> [ 3165.145542] Call Trace: >>> [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 >>> [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 >>> [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 >>> [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 >>> [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 >>> [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 >>> [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b >>> [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 >>> a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 >>> 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 >>> c3 80 >>> [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >>> [ 3165.145699] RSP <ffff880037b33e18> >>> [ 3165.145703] CR2: 0000000000000048 >>> [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- >> > > Hmm... see if the enclosed patch helps. > > --- > > V4L/DVB: ir: avoid race conditions at device disconnect > > It is possible that, while ir_unregister_class() is handling, some application > could try to access the sysfs nodes, causing an OOPS. > > Signed-off-by: Mauro Carvalho Chehab <mc...@re...> Yeah, I'm reasonably sure that'll do the trick, since clearly, store_protocols is getting called after we've already started working our way through ir_input_unregister, so if drvdata is set to NULL before we enter ir_input_unregister and we check for NULL ir_dev in {store,show}_protocols, we should be good. Acked-by: Jarod Wilson <ja...@re...> and/or Reviewed-by: Jarod Wilson <ja...@re...> -- Jarod Wilson ja...@wi... |
From: Greg O. <oli...@gm...> - 2010-10-14 21:58:13
|
On Thu, Oct 14, 2010 at 10:19 AM, Jarod Wilson <ja...@wi...> wrote: > On Oct 14, 2010, at 11:06 AM, Mauro Carvalho Chehab wrote: > >> Em 14-10-2010 11:47, Jarod Wilson escreveu: >>> On Oct 13, 2010, at 11:57 PM, Greg Oliver wrote: >>> ... >>>> OK, with the patches, I get 2 key presses played for every 1 real >>>> press, >>> >>> Is it really 2 key presses, or is it press + repeat? ir-core doesn't do any repeat filtering, and there was actually a repeat bug fixed in those patches, so this isn't entirely unexpected. >>> >>> >>>> plus the same oops eventually with more debugs in the modules >>>> though.. >>> >>> Okay, so it seems the usb disconnect is what's triggering this. And I think I'm starting to get a decent idea of why I'm not seeing this myself. The ubuntu lirc packages have some udev bits that re-run the lirc initscript on device plug/unplug, and one of the things the initscript does is poke the protocols sysfs node, which is what triggers the call to store_protocols. I think we're racing with the disconnect here. I'm not sure if we need to add some locking, or just bail from store_protocols if ir_dev is NULL and call it good. >>> >>> >>>> [ 3165.068079] ir_rc6_decode: RC6(6A) scancode 0x800f0420 (toggle: 0) >>>> [ 3165.068088] ir_g_keycode_from_table: Media Center Ed. eHome >>>> Infrared Remote Transceiver (1784:0008): scancode 0x800f0420 keycode >>>> 0x69 >>>> [ 3165.068114] ir_keydown: Media Center Ed. eHome Infrared Remote >>>> Transceiver (1784:0008): key down event, key 0x0069, scancode >>>> 0x800f0420 >>>> [ 3165.071059] ir_rc5_decode: RC5(x) decode failed at state 1 (1761us pulse) >>>> [ 3165.072055] ir_rc5_decode: RC5(x) decode failed at state 0 (900us space) >>>> [ 3165.073059] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.074072] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.081112] ir_rc5_decode: RC5(x) decode failed at state 2 (400us space) >>>> [ 3165.083086] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.084065] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.086064] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.089088] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.090061] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.093131] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.100057] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.103071] ir_rc5_decode: RC5(x) decode failed at state 2 (400us pulse) >>>> [ 3165.104060] ir_rc5_decode: RC5(x) decode failed at state 0 (500us space) >>>> [ 3165.105048] ir_rc5_decode: RC5(x) decode failed at state 1 (400us space) >>>> [ 3165.110588] usb 5-1: USB disconnect, address 2 >>>> [ 3165.111120] ir_input_unregister: Freed keycode table >>>> [ 3165.145273] BUG: unable to handle kernel NULL pointer dereference >>>> at 0000000000000048 >>>> [ 3165.145286] IP: [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >>>> [ 3165.145305] PGD d848067 PUD d934067 PMD 0 >>>> [ 3165.145315] Oops: 0000 [#1] SMP >>>> [ 3165.145322] last sysfs file: /sys/devices/virtual/rc/rc0/protocols >>>> [ 3165.145328] CPU 2 >>>> [ 3165.145331] Modules linked in: nfsd exportfs nfs lockd fscache >>>> nfs_acl auth_rpcgss snd_hda_codec_nvhdmi snd_hda_intel snd_hda_codec >>>> snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq >>>> snd_timer snd_seq_device nvidia(P) snd soundcore snd_page_alloc shpchp >>>> sunrpc ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder >>>> ir_rc6_decoder usb_debug edac_core edac_mce_amd ir_rc5_decoder >>>> i2c_piix4 usbserial ir_nec_decoder rc_rc6_mce k10temp psmouse mceusb >>>> serio_raw ir_core lp parport usbhid hid pata_atiixp ahci r8169 mii >>>> libahci >>>> [ 3165.145408] >>>> [ 3165.145416] Pid: 3069, comm: lirc Tainted: P >>>> 2.6.36-020636rc7-generic #201010070908 TA880GB+/TA880GB+ >>>> [ 3165.145423] RIP: 0010:[<ffffffffa0044fca>] [<ffffffffa0044fca>] >>>> store_protocols+0x20a/0x2d0 [ir_core] >>>> [ 3165.145439] RSP: 0018:ffff880037b33e18 EFLAGS: 00010202 >>>> [ 3165.145445] RAX: 0000000000000000 RBX: ffff88022dac79b0 RCX: 0000000000000005 >>>> [ 3165.145451] RDX: ffff88022ad12400 RSI: ffffffffa0046d80 RDI: ffff88022ad12400 >>>> [ 3165.145456] RBP: ffff880037b33e78 R08: 0000000000000001 R09: ffffea00002f4af0 >>>> [ 3165.145462] R10: 0000000000000000 R11: 0000000000000246 R12: ffff88021f4239c0 >>>> [ 3165.145468] R13: 00000000ffffffed R14: ffffffff8164b520 R15: ffff88022ad12410 >>>> [ 3165.145475] FS: 00007fa4cb4e7700(0000) GS:ffff880001e80000(0000) >>>> knlGS:0000000000000000 >>>> [ 3165.145481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >>>> [ 3165.145486] CR2: 0000000000000048 CR3: 000000000da52000 CR4: 00000000000006e0 >>>> [ 3165.145492] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >>>> [ 3165.145498] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 >>>> [ 3165.145504] Process lirc (pid: 3069, threadinfo ffff880037b32000, >>>> task ffff8801932fc4a0) >>>> [ 3165.145509] Stack: >>>> [ 3165.145512] ffffffff81a48f60 0000000000000005 ffff88022ad12400 >>>> 0000000001883ad0 >>>> [ 3165.145521] <0> ffff880037b33e68 ffffffff8113cee3 ffff88000d832000 >>>> ffff88022dac79b0 >>>> [ 3165.145531] <0> ffff88021f4239c0 00000000ffffffed ffffffff8164b520 >>>> ffff88022ad12410 >>>> [ 3165.145542] Call Trace: >>>> [ 3165.145556] [<ffffffff8113cee3>] ? alloc_pages_current+0xa3/0x110 >>>> [ 3165.145567] [<ffffffff81388390>] dev_attr_store+0x20/0x30 >>>> [ 3165.145576] [<ffffffff811c1d32>] flush_write_buffer+0x62/0x90 >>>> [ 3165.145584] [<ffffffff811c1e76>] sysfs_write_file+0x66/0xa0 >>>> [ 3165.145592] [<ffffffff81156a7c>] vfs_write+0xcc/0x190 >>>> [ 3165.145600] [<ffffffff81157485>] sys_write+0x55/0x90 >>>> [ 3165.145609] [<ffffffff8100b0f2>] system_call_fastpath+0x16/0x1b >>>> [ 3165.145614] Code: c7 c7 78 65 04 a0 31 c0 e8 94 ea 01 e1 48 8b 45 >>>> a8 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 48 8b 55 b0 48 8b 82 >>>> 98 02 00 00 <48> 8b 40 48 48 89 45 c0 e9 31 fe ff ff 48 8b 5d b0 48 81 >>>> c3 80 >>>> [ 3165.145687] RIP [<ffffffffa0044fca>] store_protocols+0x20a/0x2d0 [ir_core] >>>> [ 3165.145699] RSP <ffff880037b33e18> >>>> [ 3165.145703] CR2: 0000000000000048 >>>> [ 3165.145709] ---[ end trace 0241a6f763d5403b ]--- >>> >> >> Hmm... see if the enclosed patch helps. >> >> --- >> >> V4L/DVB: ir: avoid race conditions at device disconnect >> >> It is possible that, while ir_unregister_class() is handling, some application >> could try to access the sysfs nodes, causing an OOPS. >> >> Signed-off-by: Mauro Carvalho Chehab <mc...@re...> > > Yeah, I'm reasonably sure that'll do the trick, since clearly, store_protocols is getting called after we've already started working our way through ir_input_unregister, so if drvdata is set to NULL before we enter ir_input_unregister and we check for NULL ir_dev in {store,show}_protocols, we should be good. > > Acked-by: Jarod Wilson <ja...@re...> > > and/or > > Reviewed-by: Jarod Wilson <ja...@re...> So, I am pulling all of this down to try again, but I fear the root cause of my situation is more kernel USB related. Even with the 0.8.7-pre3 lirc modules running, I still get the constant disconnects (althout lirc recovers when the reconnect occurs and lirc_mceusb picks it back up), but eventually with this set of modules, the system freezes completely!!! It has happened twice since I switched back last night. So, with the in-kernel stuff, my USB subsystem completely dies, and with 0.8.7-pre3 modules, my system freezes (although a lot less).. I may have to just back down to a "heavily patched for my SATA controller" 2.6.32 kernel again. I never paid attention before, but are the frequent disconnects from the transceiver common? Also, all of my minimyth systems use 2.6.35 with the same transceivers and do not exhibit any of this.. They are all configured to use /dev/input at boot though.. My ubuntu system winds up using lirc0 somehow.. Thanks -Greg |