* Re: Imon module Oops and kernel hang [not found] <4E1B978C.2030407@psychogeeks.com> @ 2011-07-12 15:03 ` Randy Dunlap 2011-07-12 19:55 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Randy Dunlap @ 2011-07-12 15:03 UTC (permalink / raw) To: Chris W, linux-media; +Cc: linux-kernel [add linux-media mailing list] On Tue, 12 Jul 2011 10:38:36 +1000 Chris W wrote: > Hello All, > > The following report applies to 2.6.39.3 (vanilla code). I also see it > consistently on 2.6.39.2 and 2.6.38-gentoo-r6. > > I am trying to switch to using the in-kernel modules for my remote > control and vfd display needs. I have built the kernel with the mceusb > module for the MCE remote that I use to control the machine and the imon > module to provide an LCD interface for lcdproc (I don't use that actual > remote). There's also another, unused, remote interface on one of my DVB > cards (rc_winfast module). Kernel modules for the MCE and other remote > load fine. > > Attempting to load the imon module crashes Linux hard (no recovery other > than hard reset). Details are below. It seems to be related to > keytables. The iMon device is an older VFD device in a Silverstone > case, with mouse control on the remote, no volume knob. Details of the > iMon USB device are below the crash details. > > I hope this is a dumb mistake on my part. I would appreciate any > assistance. > Regards, > Chris > > > root@kepler # modprobe -v imon debug=1 > (I have also tried specifying display_type=1) > > root@newton # cat /var/log/kepler-netconsole.log > Jul 12 09:44:20 kepler BUG: unable to handle kernel > Jul 12 09:44:20 kepler NULL pointer dereference > Jul 12 09:44:20 kepler at 000000dc > Jul 12 09:44:20 kepler IP: > Jul 12 09:44:20 kepler [<f8fbe46e>] rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 12 09:44:20 kepler *pde = 00000000 > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler Oops: 0000 [#1] > Jul 12 09:44:20 kepler PREEMPT > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler last sysfs file: > /sys/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input6/capabilities/key > Jul 12 09:44:20 kepler Modules linked in: > Jul 12 09:44:20 kepler imon(+) > Jul 12 09:44:20 kepler netconsole > Jul 12 09:44:20 kepler asb100 > Jul 12 09:44:20 kepler hwmon_vid > Jul 12 09:44:20 kepler cx22702 > Jul 12 09:44:20 kepler dvb_pll > Jul 12 09:44:20 kepler mt352 > Jul 12 09:44:20 kepler cx88_dvb > Jul 12 09:44:20 kepler cx88_vp3054_i2c > Jul 12 09:44:20 kepler rc_winfast > Jul 12 09:44:20 kepler ir_lirc_codec > Jul 12 09:44:20 kepler lirc_dev > Jul 12 09:44:20 kepler ir_sony_decoder > Jul 12 09:44:20 kepler videobuf_dvb > Jul 12 09:44:20 kepler ir_jvc_decoder > Jul 12 09:44:20 kepler ir_rc6_decoder > Jul 12 09:44:20 kepler snd_via82xx > Jul 12 09:44:20 kepler cx8802 > Jul 12 09:44:20 kepler cx8800 > Jul 12 09:44:20 kepler ir_rc5_decoder > Jul 12 09:44:20 kepler ir_nec_decoder > Jul 12 09:44:20 kepler snd_ac97_codec > Jul 12 09:44:20 kepler ac97_bus > Jul 12 09:44:20 kepler cx88xx > Jul 12 09:44:20 kepler rc_core > Jul 12 09:44:20 kepler b44 > Jul 12 09:44:20 kepler i2c_algo_bit > Jul 12 09:44:20 kepler snd_mpu401_uart > Jul 12 09:44:20 kepler tveeprom > Jul 12 09:44:20 kepler snd_rawmidi > Jul 12 09:44:20 kepler btcx_risc > Jul 12 09:44:20 kepler i2c_viapro > Jul 12 09:44:20 kepler videobuf_dma_sg > Jul 12 09:44:20 kepler ssb > Jul 12 09:44:20 kepler mii > Jul 12 09:44:20 kepler videobuf_core > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler Pid: 2981, comm: input_id Not tainted 2.6.39.3 #2 > Jul 12 09:44:20 kepler System Manufacturer System Name > Jul 12 09:44:20 kepler /A7V8X > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler EIP: 0060:[<f8fbe46e>] EFLAGS: 00010002 CPU: 0 > Jul 12 09:44:20 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 12 09:44:20 kepler EAX: 00000000 EBX: f57f2000 ECX: 00000008 EDX: > 00000000 > Jul 12 09:44:20 kepler ESI: 00000000 EDI: 00000000 EBP: f7007e48 ESP: > f7007e18 > Jul 12 09:44:20 kepler DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 > Jul 12 09:44:20 kepler Process input_id (pid: 2981, ti=f7006000 > task=f5101a40 task.ti=f5102000) > Jul 12 09:44:20 kepler Stack: > Jul 12 09:44:20 kepler 00000001 > Jul 12 09:44:20 kepler f7007e30 > Jul 12 09:44:20 kepler c101e9ae > Jul 12 09:44:20 kepler f7088a60 > Jul 12 09:44:20 kepler 00000001 > Jul 12 09:44:20 kepler f7088a60 > Jul 12 09:44:20 kepler 00000000 > Jul 12 09:44:20 kepler 00000086 > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler f7007e50 > Jul 12 09:44:20 kepler f57f2000 > Jul 12 09:44:20 kepler 00000000 > Jul 12 09:44:20 kepler 00000000 > Jul 12 09:44:20 kepler f7007e58 > Jul 12 09:44:20 kepler f87c259c > Jul 12 09:44:20 kepler f57f2000 > Jul 12 09:44:20 kepler f57f2041 > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler f7007edc > Jul 12 09:44:20 kepler f87c26dc > Jul 12 09:44:20 kepler f68880a4 > Jul 12 09:44:20 kepler f7007e6c > Jul 12 09:44:20 kepler c11a0865 > Jul 12 09:44:20 kepler f7007e74 > Jul 12 09:44:20 kepler f68880a4 > Jul 12 09:44:20 kepler f7007e98 > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler Call Trace: > Jul 12 09:44:20 kepler [<c101e9ae>] ? T.889+0x2e/0x50 > Jul 12 09:44:20 kepler [<f87c259c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 12 09:44:20 kepler [<f87c26dc>] imon_incoming_packet+0x5c/0xe10 [imon] > Jul 12 09:44:20 kepler [<c11a0865>] ? blk_complete_request+0x15/0x20 > Jul 12 09:44:20 kepler [<c12572c8>] ? atapi_qc_complete+0x58/0x2b0 > Jul 12 09:44:20 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 > Jul 12 09:44:20 kepler [<f87c3563>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 12 09:44:20 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 12 09:44:20 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 > Jul 12 09:44:20 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 > Jul 12 09:44:20 kepler [<c128cfd1>] uhci_irq+0x91/0x170 > Jul 12 09:44:20 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 > Jul 12 09:44:20 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 > Jul 12 09:44:20 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 > Jul 12 09:44:20 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 > Jul 12 09:44:20 kepler [<c1051382>] handle_irq_event+0x32/0x60 > Jul 12 09:44:20 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 > Jul 12 09:44:20 kepler <IRQ> > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 > Jul 12 09:44:20 kepler [<c1089fcd>] ? sys_read+0x3d/0x70 > Jul 12 09:44:20 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 > Jul 12 09:44:20 kepler Code: > Jul 12 09:44:20 kepler ff > Jul 12 09:44:20 kepler ff > Jul 12 09:44:20 kepler 8d > Jul 12 09:44:20 kepler 74 > Jul 12 09:44:20 kepler 26 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 8d > Jul 12 09:44:20 kepler bc > Jul 12 09:44:20 kepler 27 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 55 > Jul 12 09:44:20 kepler 89 > Jul 12 09:44:20 kepler e5 > Jul 12 09:44:20 kepler 57 > Jul 12 09:44:20 kepler 56 > Jul 12 09:44:20 kepler 53 > Jul 12 09:44:20 kepler 83 > Jul 12 09:44:20 kepler ec > Jul 12 09:44:20 kepler 24 > Jul 12 09:44:20 kepler 89 > Jul 12 09:44:20 kepler 45 > Jul 12 09:44:20 kepler e8 > Jul 12 09:44:20 kepler 9c > Jul 12 09:44:20 kepler 8f > Jul 12 09:44:20 kepler 45 > Jul 12 09:44:20 kepler ec > Jul 12 09:44:20 kepler fa > Jul 12 09:44:20 kepler 89 > Jul 12 09:44:20 kepler e0 > Jul 12 09:44:20 kepler 25 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler e0 > Jul 12 09:44:20 kepler ff > Jul 12 09:44:20 kepler ff > Jul 12 09:44:20 kepler ff > Jul 12 09:44:20 kepler 40 > Jul 12 09:44:20 kepler 14 > Jul 12 09:44:20 kepler 8b > Jul 12 09:44:20 kepler 45 > Jul 12 09:44:20 kepler e8 > Jul 12 09:44:20 kepler syslog-ng[2061]: Error processing log message: <8b> > Jul 12 09:44:20 kepler 80 > Jul 12 09:44:20 kepler dc > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 00 > Jul 12 09:44:20 kepler 89 > Jul 12 09:44:20 kepler c3 > Jul 12 09:44:20 kepler 89 > Jul 12 09:44:20 kepler 45 > Jul 12 09:44:20 kepler f0 > Jul 12 09:44:20 kepler 4b > Jul 12 09:44:20 kepler 78 > Jul 12 09:44:20 kepler 38 > Jul 12 09:44:20 kepler 8b > Jul 12 09:44:20 kepler 45 > Jul 12 09:44:20 kepler e8 > Jul 12 09:44:20 kepler 31 > Jul 12 09:44:20 kepler c9 > Jul 12 09:44:20 kepler 8b > Jul 12 09:44:20 kepler b0 > Jul 12 09:44:20 kepler > Jul 12 09:44:20 kepler EIP: [<f8fbe46e>] > Jul 12 09:44:20 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 12 09:44:20 kepler SS:ESP 0068:f7007e18 > Jul 12 09:44:20 kepler CR2: 00000000000000dc > Jul 12 09:44:20 kepler ---[ end trace 3be02180d283b5a7 ]--- > Jul 12 09:44:20 kepler Kernel panic - not syncing: Fatal exception in > interrupt > Jul 12 09:44:20 kepler Pid: 2981, comm: input_id Tainted: G D > 2.6.39.3 #2 > Jul 12 09:44:20 kepler Call Trace: > Jul 12 09:44:20 kepler [<c13d6279>] panic+0x61/0x145 > Jul 12 09:44:20 kepler [<c1004ff0>] oops_end+0x80/0x80 > Jul 12 09:44:20 kepler [<c101906e>] no_context+0xbe/0x150 > Jul 12 09:44:20 kepler [<c101918f>] __bad_area_nosemaphore+0x8f/0x130 > Jul 12 09:44:20 kepler [<c1019242>] bad_area_nosemaphore+0x12/0x20 > Jul 12 09:44:20 kepler [<c10195fb>] do_page_fault+0x24b/0x410 > Jul 12 09:44:20 kepler [<c128bdf6>] ? uhci_alloc_td+0x16/0x40 > Jul 12 09:44:20 kepler [<c10400e5>] ? T.312+0x15/0x1b0 > Jul 12 09:44:20 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 > Jul 12 09:44:20 kepler [<c13d85f4>] error_code+0x58/0x60 > Jul 12 09:44:20 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 > Jul 12 09:44:20 kepler [<f8fbe46e>] ? rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 12 09:44:20 kepler [<c101e9ae>] ? T.889+0x2e/0x50 > Jul 12 09:44:20 kepler [<f87c259c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 12 09:44:20 kepler [<f87c26dc>] imon_incoming_packet+0x5c/0xe10 [imon] > Jul 12 09:44:20 kepler [<c11a0865>] ? blk_complete_request+0x15/0x20 > Jul 12 09:44:20 kepler [<c12572c8>] ? atapi_qc_complete+0x58/0x2b0 > Jul 12 09:44:20 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 > Jul 12 09:44:20 kepler [<f87c3563>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 12 09:44:20 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 12 09:44:20 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 > Jul 12 09:44:20 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 > Jul 12 09:44:20 kepler [<c128cfd1>] uhci_irq+0x91/0x170 > Jul 12 09:44:20 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 > Jul 12 09:44:20 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 > Jul 12 09:44:20 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 > Jul 12 09:44:20 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 > Jul 12 09:44:20 kepler [<c1051382>] handle_irq_event+0x32/0x60 > Jul 12 09:44:20 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 > Jul 12 09:44:20 kepler <IRQ> > Jul 12 09:44:20 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 > Jul 12 09:44:20 kepler [<c1089fcd>] ? sys_read+0x3d/0x70 > Jul 12 09:44:20 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 > > > > > root@kepler # lsusb -v -d 15c2:ffdc > Bus 004 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 1.10 > bDeviceClass 0 (Defined at Interface level) > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 8 > idVendor 0x15c2 SoundGraph Inc. > idProduct 0xffdc iMON PAD Remote Controller > bcdDevice 0.00 > iManufacturer 0 > iProduct 0 > iSerial 0 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 41 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0x80 > (Bus Powered) > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 2 > bInterfaceClass 0 (Defined at Interface level) > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > ** UNRECOGNIZED: 09 21 00 01 00 01 22 25 00 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x02 EP 2 OUT > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 10 > Device Status: 0x0000 > (Bus Powered) > > > > # Kernel options from Media/RC > # > # Multimedia drivers > # > CONFIG_RC_CORE=m > CONFIG_LIRC=m > CONFIG_RC_MAP=m > CONFIG_IR_NEC_DECODER=m > CONFIG_IR_RC5_DECODER=m > CONFIG_IR_RC6_DECODER=m > CONFIG_IR_JVC_DECODER=m > CONFIG_IR_SONY_DECODER=m > CONFIG_IR_RC5_SZ_DECODER=m > CONFIG_IR_LIRC_CODEC=m > # CONFIG_IR_ENE is not set > CONFIG_IR_IMON=m > CONFIG_IR_MCEUSB=m > # CONFIG_IR_ITE_CIR is not set > # CONFIG_IR_NUVOTON is not set > # CONFIG_IR_STREAMZAP is not set > # CONFIG_IR_WINBOND_CIR is not set > # CONFIG_RC_LOOPBACK is not set > > > # cat /proc/cpuinfo > processor : 0 > vendor_id : AuthenticAMD > cpu family : 6 > model : 8 > model name : AMD Athlon(TM) XP 2400+ > stepping : 1 > cpu MHz : 2000.091 > cache size : 256 KB > fdiv_bug : no > hlt_bug : no > f00f_bug : no > coma_bug : no > fpu : yes > fpu_exception : yes > cpuid level : 1 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca > cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow > bogomips : 4000.18 > clflush size : 32 > cache_alignment : 32 > address sizes : 34 bits physical, 32 bits virtual > power management: ts > > -- > Chris Williams > Brisbane, Australia > > -- --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-12 15:03 ` Imon module Oops and kernel hang Randy Dunlap @ 2011-07-12 19:55 ` Jarod Wilson 2011-07-12 22:35 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-12 19:55 UTC (permalink / raw) To: Chris W; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap On Jul 12, 2011, at 11:03 AM, Randy Dunlap wrote: > [add linux-media mailing list] > > On Tue, 12 Jul 2011 10:38:36 +1000 Chris W wrote: > >> Hello All, >> >> The following report applies to 2.6.39.3 (vanilla code). I also see it >> consistently on 2.6.39.2 and 2.6.38-gentoo-r6. >> >> I am trying to switch to using the in-kernel modules for my remote >> control and vfd display needs. I have built the kernel with the mceusb >> module for the MCE remote that I use to control the machine and the imon >> module to provide an LCD interface for lcdproc (I don't use that actual >> remote). There's also another, unused, remote interface on one of my DVB >> cards (rc_winfast module). Kernel modules for the MCE and other remote >> load fine. >> >> Attempting to load the imon module crashes Linux hard (no recovery other >> than hard reset). Details are below. It seems to be related to >> keytables. The iMon device is an older VFD device in a Silverstone >> case, with mouse control on the remote, no volume knob. Details of the >> iMon USB device are below the crash details. >> >> I hope this is a dumb mistake on my part. I would appreciate any >> assistance. I don't see any rc_imon_pad or rc_imon_mce modules there, and I've not seen any panics with multiple imon devices here, so I'm guessing you didn't build either of the possible imon keymaps, and having a null keymap is interacting badly with rc_g_keycode_from_table. >> root@kepler # modprobe -v imon debug=1 >> (I have also tried specifying display_type=1) >> >> root@newton # cat /var/log/kepler-netconsole.log >> Jul 12 09:44:20 kepler BUG: unable to handle kernel >> Jul 12 09:44:20 kepler NULL pointer dereference >> Jul 12 09:44:20 kepler at 000000dc >> Jul 12 09:44:20 kepler IP: >> Jul 12 09:44:20 kepler [<f8fbe46e>] rc_g_keycode_from_table+0x1e/0xe0 >> [rc_core] >> Jul 12 09:44:20 kepler *pde = 00000000 >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler Oops: 0000 [#1] >> Jul 12 09:44:20 kepler PREEMPT >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler last sysfs file: >> /sys/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input6/capabilities/key >> Jul 12 09:44:20 kepler Modules linked in: >> Jul 12 09:44:20 kepler imon(+) >> Jul 12 09:44:20 kepler netconsole >> Jul 12 09:44:20 kepler asb100 >> Jul 12 09:44:20 kepler hwmon_vid >> Jul 12 09:44:20 kepler cx22702 >> Jul 12 09:44:20 kepler dvb_pll >> Jul 12 09:44:20 kepler mt352 >> Jul 12 09:44:20 kepler cx88_dvb >> Jul 12 09:44:20 kepler cx88_vp3054_i2c >> Jul 12 09:44:20 kepler rc_winfast >> Jul 12 09:44:20 kepler ir_lirc_codec >> Jul 12 09:44:20 kepler lirc_dev >> Jul 12 09:44:20 kepler ir_sony_decoder >> Jul 12 09:44:20 kepler videobuf_dvb >> Jul 12 09:44:20 kepler ir_jvc_decoder >> Jul 12 09:44:20 kepler ir_rc6_decoder >> Jul 12 09:44:20 kepler snd_via82xx >> Jul 12 09:44:20 kepler cx8802 >> Jul 12 09:44:20 kepler cx8800 >> Jul 12 09:44:20 kepler ir_rc5_decoder >> Jul 12 09:44:20 kepler ir_nec_decoder >> Jul 12 09:44:20 kepler snd_ac97_codec >> Jul 12 09:44:20 kepler ac97_bus >> Jul 12 09:44:20 kepler cx88xx >> Jul 12 09:44:20 kepler rc_core >> Jul 12 09:44:20 kepler b44 >> Jul 12 09:44:20 kepler i2c_algo_bit >> Jul 12 09:44:20 kepler snd_mpu401_uart >> Jul 12 09:44:20 kepler tveeprom >> Jul 12 09:44:20 kepler snd_rawmidi >> Jul 12 09:44:20 kepler btcx_risc >> Jul 12 09:44:20 kepler i2c_viapro >> Jul 12 09:44:20 kepler videobuf_dma_sg >> Jul 12 09:44:20 kepler ssb >> Jul 12 09:44:20 kepler mii >> Jul 12 09:44:20 kepler videobuf_core >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler Pid: 2981, comm: input_id Not tainted 2.6.39.3 #2 >> Jul 12 09:44:20 kepler System Manufacturer System Name >> Jul 12 09:44:20 kepler /A7V8X >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler EIP: 0060:[<f8fbe46e>] EFLAGS: 00010002 CPU: 0 >> Jul 12 09:44:20 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] >> Jul 12 09:44:20 kepler EAX: 00000000 EBX: f57f2000 ECX: 00000008 EDX: >> 00000000 >> Jul 12 09:44:20 kepler ESI: 00000000 EDI: 00000000 EBP: f7007e48 ESP: >> f7007e18 >> Jul 12 09:44:20 kepler DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 >> Jul 12 09:44:20 kepler Process input_id (pid: 2981, ti=f7006000 >> task=f5101a40 task.ti=f5102000) >> Jul 12 09:44:20 kepler Stack: >> Jul 12 09:44:20 kepler 00000001 >> Jul 12 09:44:20 kepler f7007e30 >> Jul 12 09:44:20 kepler c101e9ae >> Jul 12 09:44:20 kepler f7088a60 >> Jul 12 09:44:20 kepler 00000001 >> Jul 12 09:44:20 kepler f7088a60 >> Jul 12 09:44:20 kepler 00000000 >> Jul 12 09:44:20 kepler 00000086 >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler f7007e50 >> Jul 12 09:44:20 kepler f57f2000 >> Jul 12 09:44:20 kepler 00000000 >> Jul 12 09:44:20 kepler 00000000 >> Jul 12 09:44:20 kepler f7007e58 >> Jul 12 09:44:20 kepler f87c259c >> Jul 12 09:44:20 kepler f57f2000 >> Jul 12 09:44:20 kepler f57f2041 >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler f7007edc >> Jul 12 09:44:20 kepler f87c26dc >> Jul 12 09:44:20 kepler f68880a4 >> Jul 12 09:44:20 kepler f7007e6c >> Jul 12 09:44:20 kepler c11a0865 >> Jul 12 09:44:20 kepler f7007e74 >> Jul 12 09:44:20 kepler f68880a4 >> Jul 12 09:44:20 kepler f7007e98 >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler Call Trace: >> Jul 12 09:44:20 kepler [<c101e9ae>] ? T.889+0x2e/0x50 >> Jul 12 09:44:20 kepler [<f87c259c>] imon_remote_key_lookup+0x1c/0x70 [imon] >> Jul 12 09:44:20 kepler [<f87c26dc>] imon_incoming_packet+0x5c/0xe10 [imon] >> Jul 12 09:44:20 kepler [<c11a0865>] ? blk_complete_request+0x15/0x20 >> Jul 12 09:44:20 kepler [<c12572c8>] ? atapi_qc_complete+0x58/0x2b0 >> Jul 12 09:44:20 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 >> Jul 12 09:44:20 kepler [<f87c3563>] usb_rx_callback_intf0+0x63/0x70 [imon] >> Jul 12 09:44:20 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 >> Jul 12 09:44:20 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 >> Jul 12 09:44:20 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 >> Jul 12 09:44:20 kepler [<c128cfd1>] uhci_irq+0x91/0x170 >> Jul 12 09:44:20 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 >> Jul 12 09:44:20 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 >> Jul 12 09:44:20 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 >> Jul 12 09:44:20 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 >> Jul 12 09:44:20 kepler [<c1051382>] handle_irq_event+0x32/0x60 >> Jul 12 09:44:20 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 >> Jul 12 09:44:20 kepler <IRQ> >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 >> Jul 12 09:44:20 kepler [<c1089fcd>] ? sys_read+0x3d/0x70 >> Jul 12 09:44:20 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 >> Jul 12 09:44:20 kepler Code: >> Jul 12 09:44:20 kepler ff >> Jul 12 09:44:20 kepler ff >> Jul 12 09:44:20 kepler 8d >> Jul 12 09:44:20 kepler 74 >> Jul 12 09:44:20 kepler 26 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 8d >> Jul 12 09:44:20 kepler bc >> Jul 12 09:44:20 kepler 27 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 55 >> Jul 12 09:44:20 kepler 89 >> Jul 12 09:44:20 kepler e5 >> Jul 12 09:44:20 kepler 57 >> Jul 12 09:44:20 kepler 56 >> Jul 12 09:44:20 kepler 53 >> Jul 12 09:44:20 kepler 83 >> Jul 12 09:44:20 kepler ec >> Jul 12 09:44:20 kepler 24 >> Jul 12 09:44:20 kepler 89 >> Jul 12 09:44:20 kepler 45 >> Jul 12 09:44:20 kepler e8 >> Jul 12 09:44:20 kepler 9c >> Jul 12 09:44:20 kepler 8f >> Jul 12 09:44:20 kepler 45 >> Jul 12 09:44:20 kepler ec >> Jul 12 09:44:20 kepler fa >> Jul 12 09:44:20 kepler 89 >> Jul 12 09:44:20 kepler e0 >> Jul 12 09:44:20 kepler 25 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler e0 >> Jul 12 09:44:20 kepler ff >> Jul 12 09:44:20 kepler ff >> Jul 12 09:44:20 kepler ff >> Jul 12 09:44:20 kepler 40 >> Jul 12 09:44:20 kepler 14 >> Jul 12 09:44:20 kepler 8b >> Jul 12 09:44:20 kepler 45 >> Jul 12 09:44:20 kepler e8 >> Jul 12 09:44:20 kepler syslog-ng[2061]: Error processing log message: <8b> >> Jul 12 09:44:20 kepler 80 >> Jul 12 09:44:20 kepler dc >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 00 >> Jul 12 09:44:20 kepler 89 >> Jul 12 09:44:20 kepler c3 >> Jul 12 09:44:20 kepler 89 >> Jul 12 09:44:20 kepler 45 >> Jul 12 09:44:20 kepler f0 >> Jul 12 09:44:20 kepler 4b >> Jul 12 09:44:20 kepler 78 >> Jul 12 09:44:20 kepler 38 >> Jul 12 09:44:20 kepler 8b >> Jul 12 09:44:20 kepler 45 >> Jul 12 09:44:20 kepler e8 >> Jul 12 09:44:20 kepler 31 >> Jul 12 09:44:20 kepler c9 >> Jul 12 09:44:20 kepler 8b >> Jul 12 09:44:20 kepler b0 >> Jul 12 09:44:20 kepler >> Jul 12 09:44:20 kepler EIP: [<f8fbe46e>] >> Jul 12 09:44:20 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] >> Jul 12 09:44:20 kepler SS:ESP 0068:f7007e18 >> Jul 12 09:44:20 kepler CR2: 00000000000000dc >> Jul 12 09:44:20 kepler ---[ end trace 3be02180d283b5a7 ]--- >> Jul 12 09:44:20 kepler Kernel panic - not syncing: Fatal exception in >> interrupt >> Jul 12 09:44:20 kepler Pid: 2981, comm: input_id Tainted: G D >> 2.6.39.3 #2 >> Jul 12 09:44:20 kepler Call Trace: >> Jul 12 09:44:20 kepler [<c13d6279>] panic+0x61/0x145 >> Jul 12 09:44:20 kepler [<c1004ff0>] oops_end+0x80/0x80 >> Jul 12 09:44:20 kepler [<c101906e>] no_context+0xbe/0x150 >> Jul 12 09:44:20 kepler [<c101918f>] __bad_area_nosemaphore+0x8f/0x130 >> Jul 12 09:44:20 kepler [<c1019242>] bad_area_nosemaphore+0x12/0x20 >> Jul 12 09:44:20 kepler [<c10195fb>] do_page_fault+0x24b/0x410 >> Jul 12 09:44:20 kepler [<c128bdf6>] ? uhci_alloc_td+0x16/0x40 >> Jul 12 09:44:20 kepler [<c10400e5>] ? T.312+0x15/0x1b0 >> Jul 12 09:44:20 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 >> Jul 12 09:44:20 kepler [<c13d85f4>] error_code+0x58/0x60 >> Jul 12 09:44:20 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 >> Jul 12 09:44:20 kepler [<f8fbe46e>] ? rc_g_keycode_from_table+0x1e/0xe0 >> [rc_core] >> Jul 12 09:44:20 kepler [<c101e9ae>] ? T.889+0x2e/0x50 >> Jul 12 09:44:20 kepler [<f87c259c>] imon_remote_key_lookup+0x1c/0x70 [imon] >> Jul 12 09:44:20 kepler [<f87c26dc>] imon_incoming_packet+0x5c/0xe10 [imon] >> Jul 12 09:44:20 kepler [<c11a0865>] ? blk_complete_request+0x15/0x20 >> Jul 12 09:44:20 kepler [<c12572c8>] ? atapi_qc_complete+0x58/0x2b0 >> Jul 12 09:44:20 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 >> Jul 12 09:44:20 kepler [<f87c3563>] usb_rx_callback_intf0+0x63/0x70 [imon] >> Jul 12 09:44:20 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 >> Jul 12 09:44:20 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 >> Jul 12 09:44:20 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 >> Jul 12 09:44:20 kepler [<c128cfd1>] uhci_irq+0x91/0x170 >> Jul 12 09:44:20 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 >> Jul 12 09:44:20 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 >> Jul 12 09:44:20 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 >> Jul 12 09:44:20 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 >> Jul 12 09:44:20 kepler [<c1051382>] handle_irq_event+0x32/0x60 >> Jul 12 09:44:20 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 >> Jul 12 09:44:20 kepler <IRQ> >> Jul 12 09:44:20 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 >> Jul 12 09:44:20 kepler [<c1089fcd>] ? sys_read+0x3d/0x70 >> Jul 12 09:44:20 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 >> >> >> >> >> root@kepler # lsusb -v -d 15c2:ffdc >> Bus 004 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller >> Device Descriptor: >> bLength 18 >> bDescriptorType 1 >> bcdUSB 1.10 >> bDeviceClass 0 (Defined at Interface level) >> bDeviceSubClass 0 >> bDeviceProtocol 0 >> bMaxPacketSize0 8 >> idVendor 0x15c2 SoundGraph Inc. >> idProduct 0xffdc iMON PAD Remote Controller >> bcdDevice 0.00 >> iManufacturer 0 >> iProduct 0 >> iSerial 0 >> bNumConfigurations 1 >> Configuration Descriptor: >> bLength 9 >> bDescriptorType 2 >> wTotalLength 41 >> bNumInterfaces 1 >> bConfigurationValue 1 >> iConfiguration 0 >> bmAttributes 0x80 >> (Bus Powered) >> MaxPower 100mA >> Interface Descriptor: >> bLength 9 >> bDescriptorType 4 >> bInterfaceNumber 0 >> bAlternateSetting 0 >> bNumEndpoints 2 >> bInterfaceClass 0 (Defined at Interface level) >> bInterfaceSubClass 0 >> bInterfaceProtocol 0 >> iInterface 0 >> ** UNRECOGNIZED: 09 21 00 01 00 01 22 25 00 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x81 EP 1 IN >> bmAttributes 3 >> Transfer Type Interrupt >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0008 1x 8 bytes >> bInterval 10 >> Endpoint Descriptor: >> bLength 7 >> bDescriptorType 5 >> bEndpointAddress 0x02 EP 2 OUT >> bmAttributes 3 >> Transfer Type Interrupt >> Synch Type None >> Usage Type Data >> wMaxPacketSize 0x0008 1x 8 bytes >> bInterval 10 >> Device Status: 0x0000 >> (Bus Powered) >> >> >> >> # Kernel options from Media/RC >> # >> # Multimedia drivers >> # >> CONFIG_RC_CORE=m >> CONFIG_LIRC=m >> CONFIG_RC_MAP=m >> CONFIG_IR_NEC_DECODER=m >> CONFIG_IR_RC5_DECODER=m >> CONFIG_IR_RC6_DECODER=m >> CONFIG_IR_JVC_DECODER=m >> CONFIG_IR_SONY_DECODER=m >> CONFIG_IR_RC5_SZ_DECODER=m >> CONFIG_IR_LIRC_CODEC=m >> # CONFIG_IR_ENE is not set >> CONFIG_IR_IMON=m >> CONFIG_IR_MCEUSB=m >> # CONFIG_IR_ITE_CIR is not set >> # CONFIG_IR_NUVOTON is not set >> # CONFIG_IR_STREAMZAP is not set >> # CONFIG_IR_WINBOND_CIR is not set >> # CONFIG_RC_LOOPBACK is not set >> >> >> # cat /proc/cpuinfo >> processor : 0 >> vendor_id : AuthenticAMD >> cpu family : 6 >> model : 8 >> model name : AMD Athlon(TM) XP 2400+ >> stepping : 1 >> cpu MHz : 2000.091 >> cache size : 256 KB >> fdiv_bug : no >> hlt_bug : no >> f00f_bug : no >> coma_bug : no >> fpu : yes >> fpu_exception : yes >> cpuid level : 1 >> wp : yes >> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca >> cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow >> bogomips : 4000.18 >> clflush size : 32 >> cache_alignment : 32 >> address sizes : 34 bits physical, 32 bits virtual >> power management: ts >> >> -- >> Chris Williams >> Brisbane, Australia >> >> -- > > > --- > ~Randy > *** Remember to use Documentation/SubmitChecklist when testing your code *** > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Jarod Wilson jarod@wilsonet.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-12 19:55 ` Jarod Wilson @ 2011-07-12 22:35 ` Chris W 2011-07-13 4:20 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-12 22:35 UTC (permalink / raw) To: Jarod Wilson; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap Thanks for the reply. On 13/07/11 05:55, Jarod Wilson wrote: > > I don't see any rc_imon_pad or rc_imon_mce modules there, and I've not > seen any panics with multiple imon devices here, so I'm guessing you > didn't build either of the possible imon keymaps, and having a null > keymap is interacting badly with rc_g_keycode_from_table. There is only one imon device in this machine. kepler ~ $ lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 003 Device 002: ID 0471:0815 Philips (or NXP) eHome Infrared Receiver Bus 004 Device 002: ID 0dc6:2011 Precision Squared Technology Corp. Bus 004 Device 003: ID 15c2:ffdc SoundGraph Inc. iMON PAD Remote Controller The Philips device is a Microsoft branded MCE remote dongle. The Precision Squared device is the media control keypad on the case (claimed by USB HID). The rc keymap modules have been built (en masse as a result of CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not get automatically loaded. kepler ~ # ls -l /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/ total 352 --8<-- snip -rw-r--r-- 1 root root 3018 Jul 12 09:34 rc-imon-mce.ko -rw-r--r-- 1 root root 3146 Jul 12 09:34 rc-imon-pad.ko --8<-- snip The ir_*_decoder and rc_winfast modules you can see loaded have been automatically loaded during boot (udev I assume). Loading the mceusb module automatically loads the rc_rc6_mce keymap module. I just tried this: kepler ~ # rmmod rc_winfast ir_lirc_codec lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder kepler ~ # modprobe -v rc-imon-pad insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-pad.ko kepler ~ # modprobe -v rc-imon-mce insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-mce.ko kepler ~ # lsmod Module Size Used by rc_imon_mce 1161 0 rc_imon_pad 1289 0 asb100 8772 0 hwmon_vid 2016 1 asb100 nvidia 7029915 24 cx22702 4117 1 dvb_pll 7836 3 mt352 4637 2 cx88_dvb 19835 3 cx88_vp3054_i2c 1295 1 cx88_dvb videobuf_dvb 3778 1 cx88_dvb snd_via82xx 16242 0 cx8800 23903 0 snd_ac97_codec 86082 1 snd_via82xx cx8802 11067 1 cx88_dvb ac97_bus 770 1 snd_ac97_codec b44 22202 0 cx88xx 65916 3 cx88_dvb,cx8800,cx8802 snd_mpu401_uart 4679 1 snd_via82xx ssb 27969 1 b44 rc_core 12781 4 rc_imon_mce,rc_imon_pad,cx88xx i2c_algo_bit 4248 2 cx88_vp3054_i2c,cx88xx tveeprom 10545 1 cx88xx snd_rawmidi 15080 1 snd_mpu401_uart btcx_risc 2671 3 cx8800,cx8802,cx88xx videobuf_dma_sg 6392 4 cx88_dvb,cx8800,cx8802,cx88xx videobuf_core 13519 5 videobuf_dvb,cx8800,cx8802,cx88xx,videobuf_dma_sg mii 3271 1 b44 i2c_viapro 4523 0 kepler ~ # modprobe netconsole kepler ~ # modprobe -v imon debug=1 insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/imon.ko debug=1 with the same crash (below). (I have the tainting nvidia driver loaded today but it was absent yesterday) Perhaps there something else in the kernel config that must be on in order to support the keymaps? Any other thoughts? Regards, Chris Jul 13 08:21:14 kepler BUG: unable to handle kernel Jul 13 08:21:14 kepler NULL pointer dereference Jul 13 08:21:14 kepler at 000000dc Jul 13 08:21:14 kepler IP: Jul 13 08:21:14 kepler [<f8f9d46e>] rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 13 08:21:14 kepler *pde = 00000000 Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler Oops: 0000 [#1] Jul 13 08:21:14 kepler PREEMPT Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler last sysfs file: /sys/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input6/capabilities/key Jul 13 08:21:14 kepler Modules linked in: Jul 13 08:21:14 kepler imon(+) Jul 13 08:21:14 kepler netconsole Jul 13 08:21:14 kepler rc_imon_mce Jul 13 08:21:14 kepler rc_imon_pad Jul 13 08:21:14 kepler asb100 Jul 13 08:21:14 kepler hwmon_vid Jul 13 08:21:14 kepler nvidia(P) Jul 13 08:21:14 kepler cx22702 Jul 13 08:21:14 kepler dvb_pll Jul 13 08:21:14 kepler mt352 Jul 13 08:21:14 kepler cx88_dvb Jul 13 08:21:14 kepler cx88_vp3054_i2c Jul 13 08:21:14 kepler videobuf_dvb Jul 13 08:21:14 kepler snd_via82xx Jul 13 08:21:14 kepler cx8800 Jul 13 08:21:14 kepler snd_ac97_codec Jul 13 08:21:14 kepler cx8802 Jul 13 08:21:14 kepler ac97_bus Jul 13 08:21:14 kepler b44 Jul 13 08:21:14 kepler cx88xx Jul 13 08:21:14 kepler snd_mpu401_uart Jul 13 08:21:14 kepler ssb Jul 13 08:21:14 kepler rc_core Jul 13 08:21:14 kepler i2c_algo_bit Jul 13 08:21:14 kepler tveeprom Jul 13 08:21:14 kepler snd_rawmidi Jul 13 08:21:14 kepler btcx_risc Jul 13 08:21:14 kepler videobuf_dma_sg Jul 13 08:21:14 kepler videobuf_core Jul 13 08:21:14 kepler mii Jul 13 08:21:14 kepler i2c_viapro Jul 13 08:21:14 kepler [last unloaded: rc_imon_pad] Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler Pid: 2513, comm: udevd Tainted: P 2.6.39.3 #2 Jul 13 08:21:14 kepler System Manufacturer System Name Jul 13 08:21:14 kepler /A7V8X Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler EIP: 0060:[<f8f9d46e>] EFLAGS: 00010002 CPU: 0 Jul 13 08:21:14 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 13 08:21:14 kepler EAX: 00000000 EBX: f39a2000 ECX: 00000008 EDX: 00000000 Jul 13 08:21:14 kepler ESI: 00000000 EDI: 00000000 EBP: f7007e48 ESP: f7007e18 Jul 13 08:21:14 kepler DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Jul 13 08:21:14 kepler Process udevd (pid: 2513, ti=f7006000 task=f724fa60 task.ti=f5a68000) Jul 13 08:21:14 kepler Stack: Jul 13 08:21:14 kepler 00000001 Jul 13 08:21:14 kepler f7007e30 Jul 13 08:21:14 kepler c101e9ae Jul 13 08:21:14 kepler f71f2280 Jul 13 08:21:14 kepler 00000001 Jul 13 08:21:14 kepler f71f2280 Jul 13 08:21:14 kepler 00000000 Jul 13 08:21:14 kepler 00000086 Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler 00000082 Jul 13 08:21:14 kepler f39a2000 Jul 13 08:21:14 kepler 00000000 Jul 13 08:21:14 kepler 00000000 Jul 13 08:21:14 kepler f7007e58 Jul 13 08:21:14 kepler f8e3759c Jul 13 08:21:14 kepler f39a2000 Jul 13 08:21:14 kepler f39a2041 Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler f7007edc Jul 13 08:21:14 kepler f8e376dc Jul 13 08:21:14 kepler f7007e90 Jul 13 08:21:14 kepler f7007e80 Jul 13 08:21:14 kepler f68f8b20 Jul 13 08:21:14 kepler fbcde004 Jul 13 08:21:14 kepler f69e5008 Jul 13 08:21:14 kepler f69e5000 Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler Call Trace: Jul 13 08:21:14 kepler [<c101e9ae>] ? T.889+0x2e/0x50 Jul 13 08:21:14 kepler [<f8e3759c>] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 13 08:21:14 kepler [<f8e376dc>] imon_incoming_packet+0x5c/0xe10 [imon] Jul 13 08:21:14 kepler [<fbcde004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 13 08:21:14 kepler [<fbcde030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 13 08:21:14 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 Jul 13 08:21:14 kepler [<f8e38563>] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 13 08:21:14 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 Jul 13 08:21:14 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 Jul 13 08:21:14 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 Jul 13 08:21:14 kepler [<c128cfd1>] uhci_irq+0x91/0x170 Jul 13 08:21:14 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 Jul 13 08:21:14 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 Jul 13 08:21:14 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 Jul 13 08:21:14 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 Jul 13 08:21:14 kepler [<c1051382>] handle_irq_event+0x32/0x60 Jul 13 08:21:14 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 Jul 13 08:21:14 kepler <IRQ> Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 Jul 13 08:21:14 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 Jul 13 08:21:14 kepler [<c10d517e>] ? sysfs_dentry_revalidate+0xbe/0xd0 Jul 13 08:21:14 kepler [<c1092ce9>] ? do_lookup+0x149/0x250 Jul 13 08:21:14 kepler [<c1093254>] ? link_path_walk+0x164/0x8c0 Jul 13 08:21:14 kepler [<c109547d>] ? path_init+0x2dd/0x3b0 Jul 13 08:21:14 kepler [<c109559c>] ? path_lookupat+0x4c/0x720 Jul 13 08:21:14 kepler [<c1076124>] ? handle_pte_fault+0x2a4/0x590 Jul 13 08:21:14 kepler [<c1095c95>] ? do_path_lookup+0x25/0x70 Jul 13 08:21:14 kepler [<c1096736>] ? user_path_at+0x36/0x70 Jul 13 08:21:14 kepler [<c108d221>] ? sys_readlinkat+0x31/0xa0 Jul 13 08:21:14 kepler [<c108d2b7>] ? sys_readlink+0x27/0x30 Jul 13 08:21:14 kepler [<c13d8850>] ? sysenter_do_call+0x12/0x26 Jul 13 08:21:14 kepler Code: Jul 13 08:21:14 kepler ff Jul 13 08:21:14 kepler ff Jul 13 08:21:14 kepler 8d Jul 13 08:21:14 kepler 74 Jul 13 08:21:14 kepler 26 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 8d Jul 13 08:21:14 kepler bc Jul 13 08:21:14 kepler 27 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 55 Jul 13 08:21:14 kepler 89 Jul 13 08:21:14 kepler e5 Jul 13 08:21:14 kepler 57 Jul 13 08:21:14 kepler 56 Jul 13 08:21:14 kepler 53 Jul 13 08:21:14 kepler 83 Jul 13 08:21:14 kepler ec Jul 13 08:21:14 kepler 24 Jul 13 08:21:14 kepler 89 Jul 13 08:21:14 kepler 45 Jul 13 08:21:14 kepler e8 Jul 13 08:21:14 kepler 9c Jul 13 08:21:14 kepler 8f Jul 13 08:21:14 kepler 45 Jul 13 08:21:14 kepler ec Jul 13 08:21:14 kepler fa Jul 13 08:21:14 kepler 89 Jul 13 08:21:14 kepler e0 Jul 13 08:21:14 kepler 25 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler e0 Jul 13 08:21:14 kepler ff Jul 13 08:21:14 kepler ff Jul 13 08:21:14 kepler ff Jul 13 08:21:14 kepler 40 Jul 13 08:21:14 kepler 14 Jul 13 08:21:14 kepler 8b Jul 13 08:21:14 kepler 45 Jul 13 08:21:14 kepler e8 Jul 13 08:21:14 kepler syslog-ng[2058]: Error processing log message: <8b> Jul 13 08:21:14 kepler 80 Jul 13 08:21:14 kepler dc Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 00 Jul 13 08:21:14 kepler 89 Jul 13 08:21:14 kepler c3 Jul 13 08:21:14 kepler 89 Jul 13 08:21:14 kepler 45 Jul 13 08:21:14 kepler f0 Jul 13 08:21:14 kepler 4b Jul 13 08:21:14 kepler 78 Jul 13 08:21:14 kepler 38 Jul 13 08:21:14 kepler 8b Jul 13 08:21:14 kepler 45 Jul 13 08:21:14 kepler e8 Jul 13 08:21:14 kepler 31 Jul 13 08:21:14 kepler c9 Jul 13 08:21:14 kepler 8b Jul 13 08:21:14 kepler b0 Jul 13 08:21:14 kepler Jul 13 08:21:14 kepler EIP: [<f8f9d46e>] Jul 13 08:21:14 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 13 08:21:14 kepler SS:ESP 0068:f7007e18 Jul 13 08:21:14 kepler CR2: 00000000000000dc Jul 13 08:21:14 kepler ---[ end trace 05456f0fc2588a75 ]--- Jul 13 08:21:14 kepler Kernel panic - not syncing: Fatal exception in interrupt Jul 13 08:21:14 kepler Pid: 2513, comm: udevd Tainted: P D 2.6.39.3 #2 Jul 13 08:21:14 kepler Call Trace: Jul 13 08:21:14 kepler [<c13d6279>] panic+0x61/0x145 Jul 13 08:21:14 kepler [<c1004ff0>] oops_end+0x80/0x80 Jul 13 08:21:14 kepler [<c101906e>] no_context+0xbe/0x150 Jul 13 08:21:14 kepler [<c101918f>] __bad_area_nosemaphore+0x8f/0x130 Jul 13 08:21:14 kepler [<c1019242>] bad_area_nosemaphore+0x12/0x20 Jul 13 08:21:14 kepler [<c10195fb>] do_page_fault+0x24b/0x410 Jul 13 08:21:14 kepler [<c128bdf6>] ? uhci_alloc_td+0x16/0x40 Jul 13 08:21:14 kepler [<c10400e5>] ? T.312+0x15/0x1b0 Jul 13 08:21:14 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 Jul 13 08:21:14 kepler [<c13d85f4>] error_code+0x58/0x60 Jul 13 08:21:14 kepler [<c10193b0>] ? mm_fault_error+0xe0/0xe0 Jul 13 08:21:14 kepler [<f8f9d46e>] ? rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 13 08:21:14 kepler [<c101e9ae>] ? T.889+0x2e/0x50 Jul 13 08:21:14 kepler [<f8e3759c>] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 13 08:21:14 kepler [<f8e376dc>] imon_incoming_packet+0x5c/0xe10 [imon] Jul 13 08:21:14 kepler [<fbcde004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 13 08:21:14 kepler [<fbcde030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 13 08:21:14 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 Jul 13 08:21:14 kepler [<f8e38563>] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 13 08:21:14 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 Jul 13 08:21:14 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 Jul 13 08:21:14 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 Jul 13 08:21:14 kepler [<c128cfd1>] uhci_irq+0x91/0x170 Jul 13 08:21:14 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 Jul 13 08:21:14 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 Jul 13 08:21:14 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 Jul 13 08:21:14 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 Jul 13 08:21:14 kepler [<c1051382>] handle_irq_event+0x32/0x60 Jul 13 08:21:14 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 Jul 13 08:21:14 kepler <IRQ> Jul 13 08:21:14 kepler [<c1003cea>] ? do_IRQ+0x3a/0xb0 Jul 13 08:21:14 kepler [<c13d8d69>] ? common_interrupt+0x29/0x30 Jul 13 08:21:14 kepler [<c10d517e>] ? sysfs_dentry_revalidate+0xbe/0xd0 Jul 13 08:21:14 kepler [<c1092ce9>] ? do_lookup+0x149/0x250 Jul 13 08:21:14 kepler [<c1093254>] ? link_path_walk+0x164/0x8c0 Jul 13 08:21:14 kepler [<c109547d>] ? path_init+0x2dd/0x3b0 Jul 13 08:21:14 kepler [<c109559c>] ? path_lookupat+0x4c/0x720 Jul 13 08:21:14 kepler [<c1076124>] ? handle_pte_fault+0x2a4/0x590 Jul 13 08:21:14 kepler [<c1095c95>] ? do_path_lookup+0x25/0x70 Jul 13 08:21:14 kepler [<c1096736> Jul 13 08:21:14 kepler ] ? user_path_at+0x36/0x70 Jul 13 08:21:14 kepler [<c108d221>] ? sys_readlinkat+0x31/0xa0 Jul 13 08:21:14 kepler [<c108d2b7>] ? sys_readlink+0x27/0x30 Jul 13 08:21:14 kepler [<c13d8850>] ? sysenter_do_call+0x12/0x26 -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-12 22:35 ` Chris W @ 2011-07-13 4:20 ` Jarod Wilson 2011-07-13 5:42 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-13 4:20 UTC (permalink / raw) To: Chris W; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap On Jul 12, 2011, at 6:35 PM, Chris W wrote: > Thanks for the reply. > > On 13/07/11 05:55, Jarod Wilson wrote: >> >> I don't see any rc_imon_pad or rc_imon_mce modules there, and I've not >> seen any panics with multiple imon devices here, so I'm guessing you >> didn't build either of the possible imon keymaps, and having a null >> keymap is interacting badly with rc_g_keycode_from_table. > > > There is only one imon device in this machine. Understood. What I meant is that *I* have multiple imon devices, and haven't seen any such panic with any of them. :) > The rc keymap modules have been built (en masse as a result of > CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not > get automatically loaded. Huh. That's unexpected. They get auto-loaded here, last I knew. I'll have to give one of my devices a spin tomorrow, not sure exactly what the last kernel I tried one of them on was. Pretty sure they're working fine with the Fedora 15 2.6.38.x kernels and vanilla (but Fedora-configured) 3.0-rc kernels though. > I just tried this: > > kepler ~ # rmmod rc_winfast ir_lirc_codec lirc_dev ir_sony_decoder > ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder > > kepler ~ # modprobe -v rc-imon-pad > insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-pad.ko > > kepler ~ # modprobe -v rc-imon-mce > insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-mce.ko ... > kepler ~ # modprobe -v imon debug=1 > insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/imon.ko debug=1 > > with the same crash (below). (I have the tainting nvidia driver loaded > today but it was absent yesterday) > > Perhaps there something else in the kernel config that must be on in > order to support the keymaps? > > Any other thoughts? Not at the moment. That T.889 line is... odd. No clue what the heck that thing is. Lemme see what I can see tomorrow (just past midnight here at the moment), if I don't hit anything, I might need a copy of your kernel config to repro. > Jul 13 08:21:14 kepler Call Trace: > Jul 13 08:21:14 kepler [<c101e9ae>] ? T.889+0x2e/0x50 > Jul 13 08:21:14 kepler [<f8e3759c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 13 08:21:14 kepler [<f8e376dc>] imon_incoming_packet+0x5c/0xe10 [imon] > Jul 13 08:21:14 kepler [<fbcde004>] ? _nv004358rm+0x24/0x70 [nvidia] > Jul 13 08:21:14 kepler [<fbcde030>] ? _nv004358rm+0x50/0x70 [nvidia] > Jul 13 08:21:14 kepler [<c124f353>] ? __ata_qc_complete+0x73/0x110 > Jul 13 08:21:14 kepler [<f8e38563>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 13 08:21:14 kepler [<c1272cc8>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 13 08:21:14 kepler [<c128a5ee>] uhci_giveback_urb+0x8e/0x220 > Jul 13 08:21:14 kepler [<c128ac16>] uhci_scan_schedule+0x396/0x9a0 > Jul 13 08:21:14 kepler [<c128cfd1>] uhci_irq+0x91/0x170 > Jul 13 08:21:14 kepler [<c1271de1>] usb_hcd_irq+0x21/0x50 > Jul 13 08:21:14 kepler [<c1051246>] handle_irq_event_percpu+0x36/0x140 > Jul 13 08:21:14 kepler [<c1015f06>] ? __io_apic_modify_irq+0x76/0x90 > Jul 13 08:21:14 kepler [<c1053000>] ? handle_edge_irq+0x100/0x100 > Jul 13 08:21:14 kepler [<c1051382>] handle_irq_event+0x32/0x60 > Jul 13 08:21:14 kepler [<c1053045>] handle_fasteoi_irq+0x45/0xc0 -- Jarod Wilson jarod@wilsonet.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-13 4:20 ` Jarod Wilson @ 2011-07-13 5:42 ` Chris W 2011-07-13 22:11 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-13 5:42 UTC (permalink / raw) To: Jarod Wilson; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap On 13/07/11 14:20, Jarod Wilson wrote: >> Chris W wrote: >> The rc keymap modules have been built (en masse as a result of >> CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not >> get automatically loaded. > > Huh. That's unexpected. They get auto-loaded here, last I knew. I'll > have to give one of my devices a spin tomorrow, not sure exactly what > the last kernel I tried one of them on was. Pretty sure they're > working fine with the Fedora 15 2.6.38.x kernels and vanilla (but > Fedora-configured) 3.0-rc kernels though. I just ran depmod to make sure things were straight in this dept. kepler ~ # depmod -F System.map -e -av 2.6.39.3 There are no reported errors. The modules rc-imon-mce.ko, rc-imon-pad.ko and imon.ko depend only on rc-core.ko according to the output. There don't seem to be any explicit dependencies to the keymaps (not a kernel dev so I don't know if there should be) >> I just tried this: >> >> kepler ~ # rmmod rc_winfast ir_lirc_codec lirc_dev ir_sony_decoder >> ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder ir_nec_decoder >> >> kepler ~ # modprobe -v rc-imon-pad >> insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-pad.ko >> >> kepler ~ # modprobe -v rc-imon-mce >> insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/keymaps/rc-imon-mce.ko > ... >> kepler ~ # modprobe -v imon debug=1 >> insmod /lib/modules/2.6.39.3/kernel/drivers/media/rc/imon.ko debug=1 >> >> with the same crash (below). (I have the tainting nvidia driver >> loaded today but it was absent yesterday) >> >> Perhaps there something else in the kernel config that must be on in >> order to support the keymaps? >> >> Any other thoughts? > > Not at the moment. That T.889 line is... odd. No clue what the heck > that thing is. Lemme see what I can see tomorrow (just past midnight > here at the moment), if I don't hit anything, I might need a copy of > your kernel config to repro. I can only see the "T.889" string in the System.map, kernel binary and kernel/sched.o (but not the source?). I have sent the config file off-list to Jarod. I will try a Gentoo out-of-the-box kernel config when I finish work also. Thanks once again for your time Regards, -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-13 5:42 ` Chris W @ 2011-07-13 22:11 ` Jarod Wilson 2011-07-14 2:41 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-13 22:11 UTC (permalink / raw) To: Chris W; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap On Jul 13, 2011, at 1:42 AM, Chris W wrote: > > On 13/07/11 14:20, Jarod Wilson wrote: > >>> Chris W wrote: >>> The rc keymap modules have been built (en masse as a result of >>> CONFIG_RC_MAP=m) but I am not explicitly loading them and they do not >>> get automatically loaded. >> >> Huh. That's unexpected. They get auto-loaded here, last I knew. I'll >> have to give one of my devices a spin tomorrow, not sure exactly what >> the last kernel I tried one of them on was. Pretty sure they're >> working fine with the Fedora 15 2.6.38.x kernels and vanilla (but >> Fedora-configured) 3.0-rc kernels though. > > > I just ran depmod to make sure things were straight in this dept. > > kepler ~ # depmod -F System.map -e -av 2.6.39.3 > > There are no reported errors. The modules rc-imon-mce.ko, > rc-imon-pad.ko and imon.ko depend only on rc-core.ko according to the > output. There don't seem to be any explicit dependencies to the keymaps > (not a kernel dev so I don't know if there should be) Yeah, imon depends on rc-core, and requests its keymap via rc-core, so rc-core should then load up rc-imon-pad. Just tried on 3.0-rc7+ here, and everything is happy: [10791.866789] imon 3-2:1.0: usb_probe_interface [10791.868944] imon 3-2:1.0: usb_probe_interface - got id [10791.871332] input: iMON Panel, Knob and Mouse(15c2:0042) as /devices/pci0000:00/0000:00:03.1/usb3/3-2/3-2:1.0/input/input18 [10791.916037] Registered IR keymap rc-imon-pad [10791.918709] input: iMON Remote (15c2:0042) as /devices/pci0000:00/0000:00:03.1/usb3/3-2/3-2:1.0/rc/rc6/input19 [10791.921331] rc6: iMON Remote (15c2:0042) as /devices/pci0000:00/0000:00:03.1/usb3/3-2/3-2:1.0/rc/rc6 [10791.930038] imon 3-2:1.0: iMON device (15c2:0042, intf0) on usb<3:3> initialized [10791.932507] imon 3-2:1.1: usb_probe_interface [10791.934949] imon 3-2:1.1: usb_probe_interface - got id [10791.937416] imon 3-2:1.1: iMON device (15c2:0042, intf1) on usb<3:3> initialized [10791.939996] usbcore: registered new interface driver imon Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm not aware of any relevant imon changes between 2.6.39 and 3.0. >>> Perhaps there something else in the kernel config that must be on in >>> order to support the keymaps? >>> >>> Any other thoughts? >> >> Not at the moment. That T.889 line is... odd. No clue what the heck >> that thing is. Lemme see what I can see tomorrow (just past midnight >> here at the moment), if I don't hit anything, I might need a copy of >> your kernel config to repro. > > I can only see the "T.889" string in the System.map, kernel binary and > kernel/sched.o (but not the source?). I have sent the config file > off-list to Jarod. Looks like I'll probably have to give that a spin, since I'm not seeing the problem here (I can also switch to an 0xffdc device, which is actually handled a bit differently by the driver). -- Jarod Wilson jarod@wilsonet.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-13 22:11 ` Jarod Wilson @ 2011-07-14 2:41 ` Chris W 2011-07-17 0:43 ` Andy Walls 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-14 2:41 UTC (permalink / raw) To: Jarod Wilson; +Cc: Linux Media Mailing List, linux-kernel, Randy Dunlap On 14/07/11 08:11, Jarod Wilson wrote: > On Jul 13, 2011, at 1:42 AM, Chris W wrote: > Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm > not aware of any relevant imon changes between 2.6.39 and 3.0. I just tried 3.0.0-rc7 with the same result (used defaults for new config items. I manually loaded both keymaps before imon. I looks like the mystery T889 has become a T886... compiler generated temporary name perhaps? > Looks like I'll probably have to give that a spin, since I'm not > seeing the problem here (I can also switch to an 0xffdc device, which > is actually handled a bit differently by the driver). I understand that the 0xffdc device covers a multitude of physical variants. Is there any information from the device itself that drives the selected keymap? If so, how do I extract it? Regards, Chris Jul 14 11:19:38 kepler BUG: unable to handle kernel Jul 14 11:19:38 kepler NULL pointer dereference Jul 14 11:19:38 kepler at 000000dc Jul 14 11:19:38 kepler IP: Jul 14 11:19:38 kepler [<f8f1949e>] rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler *pde = 00000000 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Oops: 0000 [#1] Jul 14 11:19:38 kepler PREEMPT Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Modules linked in: Jul 14 11:19:38 kepler imon(+) Jul 14 11:19:38 kepler rc_imon_pad Jul 14 11:19:38 kepler rc_imon_mce Jul 14 11:19:38 kepler netconsole Jul 14 11:19:38 kepler asb100 Jul 14 11:19:38 kepler hwmon_vid Jul 14 11:19:38 kepler cx22702 Jul 14 11:19:38 kepler dvb_pll Jul 14 11:19:38 kepler mt352 Jul 14 11:19:38 kepler cx88_dvb Jul 14 11:19:38 kepler cx88_vp3054_i2c Jul 14 11:19:38 kepler videobuf_dvb Jul 14 11:19:38 kepler snd_via82xx Jul 14 11:19:38 kepler snd_ac97_codec Jul 14 11:19:38 kepler cx8800 Jul 14 11:19:38 kepler cx8802 Jul 14 11:19:38 kepler cx88xx Jul 14 11:19:38 kepler ac97_bus Jul 14 11:19:38 kepler snd_mpu401_uart Jul 14 11:19:38 kepler snd_rawmidi Jul 14 11:19:38 kepler b44 Jul 14 11:19:38 kepler ssb Jul 14 11:19:38 kepler rc_core Jul 14 11:19:38 kepler i2c_algo_bit Jul 14 11:19:38 kepler mii Jul 14 11:19:38 kepler tveeprom Jul 14 11:19:38 kepler btcx_risc Jul 14 11:19:38 kepler i2c_viapro Jul 14 11:19:38 kepler videobuf_dma_sg Jul 14 11:19:38 kepler videobuf_core Jul 14 11:19:38 kepler [last unloaded: ir_nec_decoder] Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Not tainted 3.0.0-rc7 #1 Jul 14 11:19:38 kepler System Manufacturer System Name Jul 14 11:19:38 kepler /A7V8X Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler EIP: 0060:[<f8f1949e>] EFLAGS: 00010002 CPU: 0 Jul 14 11:19:38 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler EAX: 00000000 EBX: f5610800 ECX: 00000008 EDX: 00000000 Jul 14 11:19:38 kepler ESI: 00000000 EDI: 00000000 EBP: f7009e48 ESP: f7009e18 Jul 14 11:19:38 kepler DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 Jul 14 11:19:38 kepler Process modprobe (pid: 2885, ti=f7008000 task=f708ada0 task.ti=f5706000) Jul 14 11:19:38 kepler Stack: Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler 00000082 Jul 14 11:19:38 kepler 00000002 Jul 14 11:19:38 kepler f7009e2c Jul 14 11:19:38 kepler c101eabb Jul 14 11:19:38 kepler f71cc8c0 Jul 14 11:19:38 kepler 00000000 Jul 14 11:19:38 kepler 00000086 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler 00000086 Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler 00000000 Jul 14 11:19:38 kepler 00000000 Jul 14 11:19:38 kepler f7009e58 Jul 14 11:19:38 kepler f87be59c Jul 14 11:19:38 kepler f5610800 Jul 14 11:19:38 kepler f5610841 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler f7009edc Jul 14 11:19:38 kepler f87be6dc Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e6c Jul 14 11:19:38 kepler f68c5760 Jul 14 11:19:38 kepler f7009e74 Jul 14 11:19:38 kepler f68c00a4 Jul 14 11:19:38 kepler f7009e98 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler Call Trace: Jul 14 11:19:38 kepler [<c101eabb>] ? T.886+0x1b/0x30 Jul 14 11:19:38 kepler [<f87be59c>] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 14 11:19:38 kepler [<f87be6dc>] imon_incoming_packet+0x5c/0xe20 [imon] Jul 14 11:19:38 kepler [<c1259cc8>] ? atapi_qc_complete+0x58/0x2b0 Jul 14 11:19:38 kepler [<c1251d23>] ? __ata_qc_complete+0x73/0x110 Jul 14 11:19:38 kepler [<f87bf573>] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 14 11:19:38 kepler [<c1275848>] usb_hcd_giveback_urb+0x48/0xb0 Jul 14 11:19:38 kepler [<c128d29e>] uhci_giveback_urb+0x8e/0x220 Jul 14 11:19:38 kepler [<c128d896>] uhci_scan_schedule+0x366/0x9e0 Jul 14 11:19:38 kepler [<c12900e1>] uhci_irq+0x91/0x170 Jul 14 11:19:38 kepler [<c1274961>] usb_hcd_irq+0x21/0x50 Jul 14 11:19:38 kepler [<c1052a36>] handle_irq_event_percpu+0x36/0x140 Jul 14 11:19:38 kepler [<c1016570>] ? __io_apic_modify_irq+0x80/0x90 Jul 14 11:19:38 kepler [<c10548c0>] ? handle_edge_irq+0x100/0x100 Jul 14 11:19:38 kepler [<c1052b72>] handle_irq_event+0x32/0x60 Jul 14 11:19:38 kepler [<c1054905>] handle_fasteoi_irq+0x45/0xc0 Jul 14 11:19:38 kepler <IRQ> Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler [<c1003c8a>] ? do_IRQ+0x3a/0xb0 Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 Jul 14 11:19:38 kepler [<c13ddf29>] ? common_interrupt+0x29/0x30 Jul 14 11:19:38 kepler [<c11b3d3e>] ? mmx_clear_page+0x7e/0x120 Jul 14 11:19:38 kepler [<c1068222>] ? get_page_from_freelist+0x1f2/0x480 Jul 14 11:19:38 kepler [<c12206d3>] ? extract_buf+0x83/0xd0 Jul 14 11:19:38 kepler [<c1068585>] ? __alloc_pages_nodemask+0xd5/0x5a0 Jul 14 11:19:38 kepler [<c10802f5>] ? anon_vma_prepare+0xc5/0x150 Jul 14 11:19:38 kepler [<c10782f0>] ? handle_pte_fault+0x440/0x590 Jul 14 11:19:38 kepler [<c10b0a9d>] ? __find_get_block+0xad/0x1c0 Jul 14 11:19:38 kepler [<c10787d4>] ? handle_mm_fault+0x74/0xb0 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c101959a>] ? do_page_fault+0xfa/0x3c0 Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 Jul 14 11:19:38 kepler [<c10e8d35>] ? ext3fs_dirhash+0x115/0x240 Jul 14 11:19:38 kepler [<c10e8ae0>] ? ext3_follow_link+0x20/0x20 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c13dd7c4>] ? error_code+0x58/0x60 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c1061f95>] ? file_read_actor+0x25/0xe0 Jul 14 11:19:38 kepler [<c10623dc>] ? find_get_page+0x5c/0xa0 Jul 14 11:19:38 kepler [<c106423e>] ? generic_file_aio_read+0x2be/0x720 Jul 14 11:19:38 kepler [<c10a54d3>] ? mntput+0x13/0x30 Jul 14 11:19:38 kepler [<c108af0c>] ? do_sync_read+0x9c/0xd0 Jul 14 11:19:38 kepler [<c108afa3>] ? rw_verify_area+0x63/0x110 Jul 14 11:19:38 kepler [<c108ba87>] ? vfs_read+0x97/0x140 Jul 14 11:19:38 kepler [<c108ae70>] ? do_sync_write+0xd0/0xd0 Jul 14 11:19:38 kepler [<c108bbed>] ? sys_read+0x3d/0x70 Jul 14 11:19:38 kepler [<c13dda10>] ? sysenter_do_call+0x12/0x26 Jul 14 11:19:38 kepler Code: Jul 14 11:19:38 kepler 8d Jul 14 11:19:38 kepler b6 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 8d Jul 14 11:19:38 kepler bc Jul 14 11:19:38 kepler 27 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 55 Jul 14 11:19:38 kepler 89 Jul 14 11:19:38 kepler e5 Jul 14 11:19:38 kepler 57 Jul 14 11:19:38 kepler 56 Jul 14 11:19:38 kepler 53 Jul 14 11:19:38 kepler 83 Jul 14 11:19:38 kepler ec Jul 14 11:19:38 kepler 24 Jul 14 11:19:38 kepler 89 Jul 14 11:19:38 kepler 45 Jul 14 11:19:38 kepler e8 Jul 14 11:19:38 kepler 9c Jul 14 11:19:38 kepler 8f Jul 14 11:19:38 kepler 45 Jul 14 11:19:38 kepler ec Jul 14 11:19:38 kepler fa Jul 14 11:19:38 kepler 89 Jul 14 11:19:38 kepler e0 Jul 14 11:19:38 kepler 25 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler e0 Jul 14 11:19:38 kepler ff Jul 14 11:19:38 kepler ff Jul 14 11:19:38 kepler ff Jul 14 11:19:38 kepler 40 Jul 14 11:19:38 kepler 14 Jul 14 11:19:38 kepler 8b Jul 14 11:19:38 kepler 45 Jul 14 11:19:38 kepler e8 Jul 14 11:19:38 kepler syslog-ng[1931]: Error processing log message: <8b> Jul 14 11:19:38 kepler 80 Jul 14 11:19:38 kepler dc Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 00 Jul 14 11:19:38 kepler 89 Jul 14 11:19:38 kepler c3 Jul 14 11:19:38 kepler 89 Jul 14 11:19:38 kepler 45 Jul 14 11:19:38 kepler f0 Jul 14 11:19:38 kepler 4b Jul 14 11:19:38 kepler 78 Jul 14 11:19:38 kepler 38 Jul 14 11:19:38 kepler 8b Jul 14 11:19:38 kepler 45 Jul 14 11:19:38 kepler e8 Jul 14 11:19:38 kepler 31 Jul 14 11:19:38 kepler c9 Jul 14 11:19:38 kepler 8b Jul 14 11:19:38 kepler b0 Jul 14 11:19:38 kepler Jul 14 11:19:38 kepler EIP: [<f8f1949e>] Jul 14 11:19:38 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler SS:ESP 0068:f7009e18 Jul 14 11:19:38 kepler CR2: 00000000000000dc Jul 14 11:19:38 kepler ---[ end trace 7467312b172b0d0f ]--- Jul 14 11:19:38 kepler Kernel panic - not syncing: Fatal exception in interrupt Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Tainted: G D 3.0.0-rc7 #1 Jul 14 11:19:38 kepler Call Trace: Jul 14 11:19:38 kepler [<c13db3a7>] panic+0x61/0x145 Jul 14 11:19:38 kepler [<c1004f30>] oops_end+0x80/0x80 Jul 14 11:19:38 kepler [<c101910e>] no_context+0xbe/0x150 Jul 14 11:19:38 kepler [<c101922f>] __bad_area_nosemaphore+0x8f/0x130 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c10192e2>] bad_area_nosemaphore+0x12/0x20 Jul 14 11:19:38 kepler [<c1019709>] do_page_fault+0x269/0x3c0 Jul 14 11:19:38 kepler [<c1040d85>] ? T.314+0x15/0x1b0 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c13dd7c4>] error_code+0x58/0x60 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<f8f1949e>] ? rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 14 11:19:38 kepler [<c101eabb>] ? T.886+0x1b/0x30 Jul 14 11:19:38 kepler [<f87be59c>] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 14 11:19:38 kepler [<f87be6dc>] imon_incoming_packet+0x5c/0xe20 [imon] Jul 14 11:19:38 kepler [<c1259cc8>] ? atapi_qc_complete+0x58/0x2b0 Jul 14 11:19:38 kepler [<c1251d23>] ? __ata_qc_complete+0x73/0x110 Jul 14 11:19:38 kepler [<f87bf573>] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 14 11:19:38 kepler [<c1275848>] usb_hcd_giveback_urb+0x48/0xb0 Jul 14 11:19:38 kepler [<c128d29e>] uhci_giveback_urb+0x8e/0x220 Jul 14 11:19:38 kepler [<c128d896>] uhci_scan_schedule+0x366/0x9e0 Jul 14 11:19:38 kepler [<c12900e1>] uhci_irq+0x91/0x170 Jul 14 11:19:38 kepler [<c1274961>] usb_hcd_irq+0x21/0x50 Jul 14 11:19:38 kepler [<c1052a36>] handle_irq_event_percpu+0x36/0x140 Jul 14 11:19:38 kepler [<c1016570>] ? __io_apic_modify_irq+0x80/0x90 Jul 14 11:19:38 kepler [<c10548c0>] ? handle_edge_irq+0x100/0x100 Jul 14 11:19:38 kepler [<c1052b72>] handle_irq_event+0x32/0x60 Jul 14 11:19:38 kepler [<c1054905>] handle_fasteoi_irq+0x45/0xc0 Jul 14 11:19:38 kepler <IRQ> Jul 14 11:19:38 kepler [<c1003c8a>] ? do_IRQ+0x3a/0xb0 Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 Jul 14 11:19:38 kepler [<c13ddf29>] ? common_interrupt+0x29/0x30 Jul 14 11:19:38 kepler [<c11b3d3e>] ? mmx_clear_page+0x7e/0x120 Jul 14 11:19:38 kepler [<c1068222>] ? get_page_from_freelist+0x1f2/0x480 Jul 14 11:19:38 kepler [<c12206d3>] ? extract_buf+0x83/0xd0 Jul 14 11:19:38 kepler [<c1068585>] ? __alloc_pages_nodemask+0xd5/0x5a0 Jul 14 11:19:38 kepler [<c10802f5>] ? anon_vma_prep Jul 14 11:19:38 kepler are+0xc5/0x150 Jul 14 11:19:38 kepler [<c10782f0>] ? handle_pte_fault+0x440/0x590 Jul 14 11:19:38 kepler [<c10b0a9d>] ? __find_get_block+0xad/0x1c0 Jul 14 11:19:38 kepler [<c10787d4>] ? handle_mm_fault+0x74/0xb0 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c101959a>] ? do_page_fault+0xfa/0x3c0 Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 Jul 14 11:19:38 kepler [<c10e8d35>] ? ext3fs_dirhash+0x115/0x240 Jul 14 11:19:38 kepler [<c10e8ae0>] ? ext3_follow_link+0x20/0x20 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c13dd7c4>] ? error_code+0x58/0x60 Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 Jul 14 11:19:38 kepler [<c1061f95>] ? file_read_actor+0x25/0xe0 Jul 14 11:19:38 kepler [<c10623dc>] ? find_get_page+0x5c/0xa0 Jul 14 11:19:38 kepler [<c106423e>] ? generic_file_aio_read+0x2be/0x720 Jul 14 11:19:38 kepler [<c10a54d3>] ? mntput+0x13/0x30 Jul 14 11:19:38 kepler [<c108af0c>] ? do_sync_read+0x9c/0xd0 Jul 14 11:19:38 kepler [<c108afa3>] ? rw_verify_area+0x63/0x110 Jul 14 11:19:38 kepler [<c108ba87>] ? vfs_read+0x97/0x140 Jul 14 11:19:38 kepler [<c108ae70>] ? do_sync_write+0xd0/0xd0 Jul 14 11:19:38 kepler [<c108bbed>] ? sys_read+0x3d/0x70 Jul 14 11:19:38 kepler [<c13dda10>] ? sysenter_do_call+0x12/0x26 -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-14 2:41 ` Chris W @ 2011-07-17 0:43 ` Andy Walls 2011-07-17 1:38 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Andy Walls @ 2011-07-17 0:43 UTC (permalink / raw) To: Chris W; +Cc: Jarod Wilson, Linux Media Mailing List, linux-kernel, Randy Dunlap On Thu, 2011-07-14 at 12:41 +1000, Chris W wrote: > On 14/07/11 08:11, Jarod Wilson wrote: > > On Jul 13, 2011, at 1:42 AM, Chris W wrote: > > Just noticed your report is for 2.6.39.x and 2.6.38.x only, but I'm > > not aware of any relevant imon changes between 2.6.39 and 3.0. > > I just tried 3.0.0-rc7 with the same result (used defaults for new > config items. I manually loaded both keymaps before imon. I looks like > the mystery T889 has become a T886... compiler generated temporary name > perhaps? > > > Looks like I'll probably have to give that a spin, since I'm not > > seeing the problem here (I can also switch to an 0xffdc device, which > > is actually handled a bit differently by the driver). > > I understand that the 0xffdc device covers a multitude of physical > variants. Is there any information from the device itself that drives > the selected keymap? If so, how do I extract it? > > Regards, > Chris > > This is an obviously repeatable NULL pointer dereference in rc_g_keycode_from_table(). The faulting line of code in both cases disasembles to: 1e: 8b 80 dc 00 00 00 mov 0xdc(%eax),%eax %eax obviously holds the value 0 (NULL). But I'm having a hard time telling to where exactly that line of assembly corresponds in rc_g_keycode_from_table(). And I can't tell from the source which data structure has something at offset 0xdc that gets derefernced early: struct rc_dev or struct rc_map. Could you provide the output of $ locate rc-core.ko $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko for the rc_g_keycode_from_table() function? Regards, Andy > Jul 14 11:19:38 kepler BUG: unable to handle kernel > Jul 14 11:19:38 kepler NULL pointer dereference > Jul 14 11:19:38 kepler at 000000dc > Jul 14 11:19:38 kepler IP: > Jul 14 11:19:38 kepler [<f8f1949e>] rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 14 11:19:38 kepler *pde = 00000000 > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler Oops: 0000 [#1] > Jul 14 11:19:38 kepler PREEMPT > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler Modules linked in: > Jul 14 11:19:38 kepler imon(+) > Jul 14 11:19:38 kepler rc_imon_pad > Jul 14 11:19:38 kepler rc_imon_mce > Jul 14 11:19:38 kepler netconsole > Jul 14 11:19:38 kepler asb100 > Jul 14 11:19:38 kepler hwmon_vid > Jul 14 11:19:38 kepler cx22702 > Jul 14 11:19:38 kepler dvb_pll > Jul 14 11:19:38 kepler mt352 > Jul 14 11:19:38 kepler cx88_dvb > Jul 14 11:19:38 kepler cx88_vp3054_i2c > Jul 14 11:19:38 kepler videobuf_dvb > Jul 14 11:19:38 kepler snd_via82xx > Jul 14 11:19:38 kepler snd_ac97_codec > Jul 14 11:19:38 kepler cx8800 > Jul 14 11:19:38 kepler cx8802 > Jul 14 11:19:38 kepler cx88xx > Jul 14 11:19:38 kepler ac97_bus > Jul 14 11:19:38 kepler snd_mpu401_uart > Jul 14 11:19:38 kepler snd_rawmidi > Jul 14 11:19:38 kepler b44 > Jul 14 11:19:38 kepler ssb > Jul 14 11:19:38 kepler rc_core > Jul 14 11:19:38 kepler i2c_algo_bit > Jul 14 11:19:38 kepler mii > Jul 14 11:19:38 kepler tveeprom > Jul 14 11:19:38 kepler btcx_risc > Jul 14 11:19:38 kepler i2c_viapro > Jul 14 11:19:38 kepler videobuf_dma_sg > Jul 14 11:19:38 kepler videobuf_core > Jul 14 11:19:38 kepler [last unloaded: ir_nec_decoder] > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Not tainted 3.0.0-rc7 #1 > Jul 14 11:19:38 kepler System Manufacturer System Name > Jul 14 11:19:38 kepler /A7V8X > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler EIP: 0060:[<f8f1949e>] EFLAGS: 00010002 CPU: 0 > Jul 14 11:19:38 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 14 11:19:38 kepler EAX: 00000000 EBX: f5610800 ECX: 00000008 EDX: > 00000000 > Jul 14 11:19:38 kepler ESI: 00000000 EDI: 00000000 EBP: f7009e48 ESP: > f7009e18 > Jul 14 11:19:38 kepler DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 0068 > Jul 14 11:19:38 kepler Process modprobe (pid: 2885, ti=f7008000 > task=f708ada0 task.ti=f5706000) > Jul 14 11:19:38 kepler Stack: > Jul 14 11:19:38 kepler f71cc8c0 > Jul 14 11:19:38 kepler 00000082 > Jul 14 11:19:38 kepler 00000002 > Jul 14 11:19:38 kepler f7009e2c > Jul 14 11:19:38 kepler c101eabb > Jul 14 11:19:38 kepler f71cc8c0 > Jul 14 11:19:38 kepler 00000000 > Jul 14 11:19:38 kepler 00000086 > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler 00000086 > Jul 14 11:19:38 kepler f5610800 > Jul 14 11:19:38 kepler 00000000 > Jul 14 11:19:38 kepler 00000000 > Jul 14 11:19:38 kepler f7009e58 > Jul 14 11:19:38 kepler f87be59c > Jul 14 11:19:38 kepler f5610800 > Jul 14 11:19:38 kepler f5610841 > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler f7009edc > Jul 14 11:19:38 kepler f87be6dc > Jul 14 11:19:38 kepler f68c00a4 > Jul 14 11:19:38 kepler f7009e6c > Jul 14 11:19:38 kepler f68c5760 > Jul 14 11:19:38 kepler f7009e74 > Jul 14 11:19:38 kepler f68c00a4 > Jul 14 11:19:38 kepler f7009e98 > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler Call Trace: > Jul 14 11:19:38 kepler [<c101eabb>] ? T.886+0x1b/0x30 > Jul 14 11:19:38 kepler [<f87be59c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 14 11:19:38 kepler [<f87be6dc>] imon_incoming_packet+0x5c/0xe20 [imon] > Jul 14 11:19:38 kepler [<c1259cc8>] ? atapi_qc_complete+0x58/0x2b0 > Jul 14 11:19:38 kepler [<c1251d23>] ? __ata_qc_complete+0x73/0x110 > Jul 14 11:19:38 kepler [<f87bf573>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 14 11:19:38 kepler [<c1275848>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 14 11:19:38 kepler [<c128d29e>] uhci_giveback_urb+0x8e/0x220 > Jul 14 11:19:38 kepler [<c128d896>] uhci_scan_schedule+0x366/0x9e0 > Jul 14 11:19:38 kepler [<c12900e1>] uhci_irq+0x91/0x170 > Jul 14 11:19:38 kepler [<c1274961>] usb_hcd_irq+0x21/0x50 > Jul 14 11:19:38 kepler [<c1052a36>] handle_irq_event_percpu+0x36/0x140 > Jul 14 11:19:38 kepler [<c1016570>] ? __io_apic_modify_irq+0x80/0x90 > Jul 14 11:19:38 kepler [<c10548c0>] ? handle_edge_irq+0x100/0x100 > Jul 14 11:19:38 kepler [<c1052b72>] handle_irq_event+0x32/0x60 > Jul 14 11:19:38 kepler [<c1054905>] handle_fasteoi_irq+0x45/0xc0 > Jul 14 11:19:38 kepler <IRQ> > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler [<c1003c8a>] ? do_IRQ+0x3a/0xb0 > Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 > Jul 14 11:19:38 kepler [<c13ddf29>] ? common_interrupt+0x29/0x30 > Jul 14 11:19:38 kepler [<c11b3d3e>] ? mmx_clear_page+0x7e/0x120 > Jul 14 11:19:38 kepler [<c1068222>] ? get_page_from_freelist+0x1f2/0x480 > Jul 14 11:19:38 kepler [<c12206d3>] ? extract_buf+0x83/0xd0 > Jul 14 11:19:38 kepler [<c1068585>] ? __alloc_pages_nodemask+0xd5/0x5a0 > Jul 14 11:19:38 kepler [<c10802f5>] ? anon_vma_prepare+0xc5/0x150 > Jul 14 11:19:38 kepler [<c10782f0>] ? handle_pte_fault+0x440/0x590 > Jul 14 11:19:38 kepler [<c10b0a9d>] ? __find_get_block+0xad/0x1c0 > Jul 14 11:19:38 kepler [<c10787d4>] ? handle_mm_fault+0x74/0xb0 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c101959a>] ? do_page_fault+0xfa/0x3c0 > Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 > Jul 14 11:19:38 kepler [<c10e8d35>] ? ext3fs_dirhash+0x115/0x240 > Jul 14 11:19:38 kepler [<c10e8ae0>] ? ext3_follow_link+0x20/0x20 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c13dd7c4>] ? error_code+0x58/0x60 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c1061f95>] ? file_read_actor+0x25/0xe0 > Jul 14 11:19:38 kepler [<c10623dc>] ? find_get_page+0x5c/0xa0 > Jul 14 11:19:38 kepler [<c106423e>] ? generic_file_aio_read+0x2be/0x720 > Jul 14 11:19:38 kepler [<c10a54d3>] ? mntput+0x13/0x30 > Jul 14 11:19:38 kepler [<c108af0c>] ? do_sync_read+0x9c/0xd0 > Jul 14 11:19:38 kepler [<c108afa3>] ? rw_verify_area+0x63/0x110 > Jul 14 11:19:38 kepler [<c108ba87>] ? vfs_read+0x97/0x140 > Jul 14 11:19:38 kepler [<c108ae70>] ? do_sync_write+0xd0/0xd0 > Jul 14 11:19:38 kepler [<c108bbed>] ? sys_read+0x3d/0x70 > Jul 14 11:19:38 kepler [<c13dda10>] ? sysenter_do_call+0x12/0x26 > Jul 14 11:19:38 kepler Code: > Jul 14 11:19:38 kepler 8d > Jul 14 11:19:38 kepler b6 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 8d > Jul 14 11:19:38 kepler bc > Jul 14 11:19:38 kepler 27 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 55 > Jul 14 11:19:38 kepler 89 > Jul 14 11:19:38 kepler e5 > Jul 14 11:19:38 kepler 57 > Jul 14 11:19:38 kepler 56 > Jul 14 11:19:38 kepler 53 > Jul 14 11:19:38 kepler 83 > Jul 14 11:19:38 kepler ec > Jul 14 11:19:38 kepler 24 > Jul 14 11:19:38 kepler 89 > Jul 14 11:19:38 kepler 45 > Jul 14 11:19:38 kepler e8 > Jul 14 11:19:38 kepler 9c > Jul 14 11:19:38 kepler 8f > Jul 14 11:19:38 kepler 45 > Jul 14 11:19:38 kepler ec > Jul 14 11:19:38 kepler fa > Jul 14 11:19:38 kepler 89 > Jul 14 11:19:38 kepler e0 > Jul 14 11:19:38 kepler 25 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler e0 > Jul 14 11:19:38 kepler ff > Jul 14 11:19:38 kepler ff > Jul 14 11:19:38 kepler ff > Jul 14 11:19:38 kepler 40 > Jul 14 11:19:38 kepler 14 > Jul 14 11:19:38 kepler 8b > Jul 14 11:19:38 kepler 45 > Jul 14 11:19:38 kepler e8 > Jul 14 11:19:38 kepler syslog-ng[1931]: Error processing log message: <8b> > Jul 14 11:19:38 kepler 80 > Jul 14 11:19:38 kepler dc > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 00 > Jul 14 11:19:38 kepler 89 > Jul 14 11:19:38 kepler c3 > Jul 14 11:19:38 kepler 89 > Jul 14 11:19:38 kepler 45 > Jul 14 11:19:38 kepler f0 > Jul 14 11:19:38 kepler 4b > Jul 14 11:19:38 kepler 78 > Jul 14 11:19:38 kepler 38 > Jul 14 11:19:38 kepler 8b > Jul 14 11:19:38 kepler 45 > Jul 14 11:19:38 kepler e8 > Jul 14 11:19:38 kepler 31 > Jul 14 11:19:38 kepler c9 > Jul 14 11:19:38 kepler 8b > Jul 14 11:19:38 kepler b0 > Jul 14 11:19:38 kepler > Jul 14 11:19:38 kepler EIP: [<f8f1949e>] > Jul 14 11:19:38 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 14 11:19:38 kepler SS:ESP 0068:f7009e18 > Jul 14 11:19:38 kepler CR2: 00000000000000dc > Jul 14 11:19:38 kepler ---[ end trace 7467312b172b0d0f ]--- > Jul 14 11:19:38 kepler Kernel panic - not syncing: Fatal exception in > interrupt > Jul 14 11:19:38 kepler Pid: 2885, comm: modprobe Tainted: G D > 3.0.0-rc7 #1 > Jul 14 11:19:38 kepler Call Trace: > Jul 14 11:19:38 kepler [<c13db3a7>] panic+0x61/0x145 > Jul 14 11:19:38 kepler [<c1004f30>] oops_end+0x80/0x80 > Jul 14 11:19:38 kepler [<c101910e>] no_context+0xbe/0x150 > Jul 14 11:19:38 kepler [<c101922f>] __bad_area_nosemaphore+0x8f/0x130 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c10192e2>] bad_area_nosemaphore+0x12/0x20 > Jul 14 11:19:38 kepler [<c1019709>] do_page_fault+0x269/0x3c0 > Jul 14 11:19:38 kepler [<c1040d85>] ? T.314+0x15/0x1b0 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c13dd7c4>] error_code+0x58/0x60 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<f8f1949e>] ? rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 14 11:19:38 kepler [<c101eabb>] ? T.886+0x1b/0x30 > Jul 14 11:19:38 kepler [<f87be59c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 14 11:19:38 kepler [<f87be6dc>] imon_incoming_packet+0x5c/0xe20 [imon] > Jul 14 11:19:38 kepler [<c1259cc8>] ? atapi_qc_complete+0x58/0x2b0 > Jul 14 11:19:38 kepler [<c1251d23>] ? __ata_qc_complete+0x73/0x110 > Jul 14 11:19:38 kepler [<f87bf573>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 14 11:19:38 kepler [<c1275848>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 14 11:19:38 kepler [<c128d29e>] uhci_giveback_urb+0x8e/0x220 > Jul 14 11:19:38 kepler [<c128d896>] uhci_scan_schedule+0x366/0x9e0 > Jul 14 11:19:38 kepler [<c12900e1>] uhci_irq+0x91/0x170 > Jul 14 11:19:38 kepler [<c1274961>] usb_hcd_irq+0x21/0x50 > Jul 14 11:19:38 kepler [<c1052a36>] handle_irq_event_percpu+0x36/0x140 > Jul 14 11:19:38 kepler [<c1016570>] ? __io_apic_modify_irq+0x80/0x90 > Jul 14 11:19:38 kepler [<c10548c0>] ? handle_edge_irq+0x100/0x100 > Jul 14 11:19:38 kepler [<c1052b72>] handle_irq_event+0x32/0x60 > Jul 14 11:19:38 kepler [<c1054905>] handle_fasteoi_irq+0x45/0xc0 > Jul 14 11:19:38 kepler <IRQ> > Jul 14 11:19:38 kepler [<c1003c8a>] ? do_IRQ+0x3a/0xb0 > Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 > Jul 14 11:19:38 kepler [<c13ddf29>] ? common_interrupt+0x29/0x30 > Jul 14 11:19:38 kepler [<c11b3d3e>] ? mmx_clear_page+0x7e/0x120 > Jul 14 11:19:38 kepler [<c1068222>] ? get_page_from_freelist+0x1f2/0x480 > Jul 14 11:19:38 kepler [<c12206d3>] ? extract_buf+0x83/0xd0 > Jul 14 11:19:38 kepler [<c1068585>] ? __alloc_pages_nodemask+0xd5/0x5a0 > Jul 14 11:19:38 kepler [<c10802f5>] ? anon_vma_prep > Jul 14 11:19:38 kepler are+0xc5/0x150 > Jul 14 11:19:38 kepler [<c10782f0>] ? handle_pte_fault+0x440/0x590 > Jul 14 11:19:38 kepler [<c10b0a9d>] ? __find_get_block+0xad/0x1c0 > Jul 14 11:19:38 kepler [<c10787d4>] ? handle_mm_fault+0x74/0xb0 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c101959a>] ? do_page_fault+0xfa/0x3c0 > Jul 14 11:19:38 kepler [<c1065c93>] ? zone_watermark_ok+0x23/0x30 > Jul 14 11:19:38 kepler [<c10e8d35>] ? ext3fs_dirhash+0x115/0x240 > Jul 14 11:19:38 kepler [<c10e8ae0>] ? ext3_follow_link+0x20/0x20 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c13dd7c4>] ? error_code+0x58/0x60 > Jul 14 11:19:38 kepler [<c10194a0>] ? mm_fault_error+0x130/0x130 > Jul 14 11:19:38 kepler [<c1061f95>] ? file_read_actor+0x25/0xe0 > Jul 14 11:19:38 kepler [<c10623dc>] ? find_get_page+0x5c/0xa0 > Jul 14 11:19:38 kepler [<c106423e>] ? generic_file_aio_read+0x2be/0x720 > Jul 14 11:19:38 kepler [<c10a54d3>] ? mntput+0x13/0x30 > Jul 14 11:19:38 kepler [<c108af0c>] ? do_sync_read+0x9c/0xd0 > Jul 14 11:19:38 kepler [<c108afa3>] ? rw_verify_area+0x63/0x110 > Jul 14 11:19:38 kepler [<c108ba87>] ? vfs_read+0x97/0x140 > Jul 14 11:19:38 kepler [<c108ae70>] ? do_sync_write+0xd0/0xd0 > Jul 14 11:19:38 kepler [<c108bbed>] ? sys_read+0x3d/0x70 > Jul 14 11:19:38 kepler [<c13dda10>] ? sysenter_do_call+0x12/0x26 > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-17 0:43 ` Andy Walls @ 2011-07-17 1:38 ` Chris W 2011-07-17 13:36 ` Andy Walls 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-17 1:38 UTC (permalink / raw) To: Andy Walls Cc: Jarod Wilson, Linux Media Mailing List, linux-kernel, Randy Dunlap On 17/07/11 10:43, Andy Walls wrote: > This is an obviously repeatable NULL pointer dereference in > rc_g_keycode_from_table(). The faulting line of code in both cases > disasembles to: > > 1e: 8b 80 dc 00 00 00 mov 0xdc(%eax),%eax > > %eax obviously holds the value 0 (NULL). But I'm having a hard time > telling to where exactly that line of assembly corresponds in > rc_g_keycode_from_table(). And I can't tell from the source which data > structure has something at offset 0xdc that gets derefernced early: > struct rc_dev or struct rc_map. > > Could you provide the output of > > $ locate rc-core.ko > $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko > > for the rc_g_keycode_from_table() function? I have a few copies lying about now. kepler ~ # locate rc-core.ko /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko /lib/modules/2.6.39.3/kernel/drivers/media/rc/rc-core.ko /lib/modules/3.0.0-rc7/kernel/drivers/media/rc/rc-core.ko /usr/src/linux-2.6.38-gentoo-r6/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-2.6.38-gentoo-r6/drivers/media/rc/rc-core.ko /usr/src/linux-2.6.39.3/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-2.6.39.3/drivers/media/rc/rc-core.ko /usr/src/linux-3.0-rc7/drivers/media/rc/.rc-core.ko.cmd /usr/src/linux-3.0-rc7/drivers/media/rc/rc-core.ko This is from my current running kernel /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko and the partial objdump and corresponding oops/crash output: 00000450 <rc_g_keycode_from_table>: rc_g_keycode_from_table(): 450: 55 push %ebp 451: 89 e5 mov %esp,%ebp 453: 57 push %edi 454: 56 push %esi 455: 53 push %ebx 456: 83 ec 24 sub $0x24,%esp 459: 89 45 e8 mov %eax,-0x18(%ebp) 45c: 9c pushf 45d: 8f 45 ec popl -0x14(%ebp) 460: fa cli 461: 89 e0 mov %esp,%eax 463: 25 00 e0 ff ff and $0xffffe000,%eax 468: ff 40 14 incl 0x14(%eax) 46b: 8b 45 e8 mov -0x18(%ebp),%eax 46e: 8b 80 d4 00 00 00 mov 0xd4(%eax),%eax 474: 89 c3 mov %eax,%ebx 476: 89 45 f0 mov %eax,-0x10(%ebp) 479: 4b dec %ebx 47a: 78 38 js 4b4 <rc_g_keycode_from_table+0x64> 47c: 8b 45 e8 mov -0x18(%ebp),%eax 47f: 31 c9 xor %ecx,%ecx 481: 8b b0 cc 00 00 00 mov 0xcc(%eax),%esi 487: eb 0e jmp 497 <rc_g_keycode_from_table+0x47> 489: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi 490: 8d 48 01 lea 0x1(%eax),%ecx 493: 39 d9 cmp %ebx,%ecx 495: 7f 1d jg 4b4 <rc_g_keycode_from_table+0x64> 497: 8d 04 0b lea (%ebx,%ecx,1),%eax 49a: 89 c7 mov %eax,%edi 49c: c1 ef 1f shr $0x1f,%edi 49f: 8d 04 07 lea (%edi,%eax,1),%eax 4a2: d1 f8 sar %eax 4a4: 8d 3c c6 lea (%esi,%eax,8),%edi 4a7: 3b 17 cmp (%edi),%edx 4a9: 77 e5 ja 490 <rc_g_keycode_from_table+0x40> 4ab: 73 3b jae 4e8 <rc_g_keycode_from_table+0x98> 4ad: 8d 58 ff lea -0x1(%eax),%ebx 4b0: 39 d9 cmp %ebx,%ecx 4b2: 7e e3 jle 497 <rc_g_keycode_from_table+0x47> 4b4: 31 db xor %ebx,%ebx 4b6: ff 75 ec pushl -0x14(%ebp) 4b9: 9d popf 4ba: 89 e0 mov %esp,%eax 4bc: 25 00 e0 ff ff and $0xffffe000,%eax 4c1: ff 48 14 decl 0x14(%eax) 4c4: 8b 40 08 mov 0x8(%eax),%eax 4c7: a8 08 test $0x8,%al 4c9: 75 52 jne 51d <rc_g_keycode_from_table+0xcd> 4cb: 85 db test %ebx,%ebx 4cd: 74 0a je 4d9 <rc_g_keycode_from_table+0x89> 4cf: 8b 3d 00 00 00 00 mov 0x0,%edi 4d5: 85 ff test %edi,%edi 4d7: 7f 19 jg 4f2 <rc_g_keycode_from_table+0xa2> 4d9: 83 c4 24 add $0x24,%esp 4dc: 89 d8 mov %ebx,%eax 4de: 5b pop %ebx 4df: 5e pop %esi 4e0: 5f pop %edi 4e1: c9 leave 4e2: c3 ret 4e3: 90 nop 4e4: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi 4e8: 3b 45 f0 cmp -0x10(%ebp),%eax 4eb: 73 c7 jae 4b4 <rc_g_keycode_from_table+0x64> 4ed: 8b 5f 04 mov 0x4(%edi),%ebx 4f0: eb c4 jmp 4b6 <rc_g_keycode_from_table+0x66> 4f2: 89 54 24 0c mov %edx,0xc(%esp) 4f6: 8b 55 e8 mov -0x18(%ebp),%edx 4f9: 89 5c 24 10 mov %ebx,0x10(%esp) 4fd: 8b 82 b4 00 00 00 mov 0xb4(%edx),%eax 503: c7 44 24 04 19 01 00 movl $0x119,0x4(%esp) 50a: 00 50b: c7 04 24 bc 00 00 00 movl $0xbc,(%esp) 512: 89 44 24 08 mov %eax,0x8(%esp) 516: e8 fc ff ff ff call 517 <rc_g_keycode_from_table+0xc7> 51b: eb bc jmp 4d9 <rc_g_keycode_from_table+0x89> 51d: 89 55 e4 mov %edx,-0x1c(%ebp) 520: e8 fc ff ff ff call 521 <rc_g_keycode_from_table+0xd1> 525: 8b 55 e4 mov -0x1c(%ebp),%edx 528: eb a1 jmp 4cb <rc_g_keycode_from_table+0x7b> 52a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi chrisw@newton ~ $ cat /var/log/kepler-netconsole.log Jul 17 11:34:56 kepler BUG: unable to handle kernel Jul 17 11:34:56 kepler NULL pointer dereference Jul 17 11:34:56 kepler at 000000d4 Jul 17 11:34:56 kepler IP: Jul 17 11:34:56 kepler [<f881446e>] rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 17 11:34:56 kepler *pde = 00000000 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler Oops: 0000 [#1] Jul 17 11:34:56 kepler PREEMPT Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler last sysfs file: /sys/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input7/name Jul 17 11:34:56 kepler Modules linked in: Jul 17 11:34:56 kepler imon(+) Jul 17 11:34:56 kepler netconsole Jul 17 11:34:56 kepler asb100 Jul 17 11:34:56 kepler hwmon_vid Jul 17 11:34:56 kepler nvidia(P) Jul 17 11:34:56 kepler cx22702 Jul 17 11:34:56 kepler dvb_pll Jul 17 11:34:56 kepler mt352 Jul 17 11:34:56 kepler cx88_dvb Jul 17 11:34:56 kepler cx88_vp3054_i2c Jul 17 11:34:56 kepler rc_winfast Jul 17 11:34:56 kepler videobuf_dvb Jul 17 11:34:56 kepler rc_rc6_mce Jul 17 11:34:56 kepler cx8800 Jul 17 11:34:56 kepler cx8802 Jul 17 11:34:56 kepler snd_via82xx Jul 17 11:34:56 kepler cx88xx Jul 17 11:34:56 kepler mceusb Jul 17 11:34:56 kepler b44 Jul 17 11:34:56 kepler i2c_algo_bit Jul 17 11:34:56 kepler tveeprom Jul 17 11:34:56 kepler snd_ac97_codec Jul 17 11:34:56 kepler ir_rc6_decoder Jul 17 11:34:56 kepler btcx_risc Jul 17 11:34:56 kepler ac97_bus Jul 17 11:34:56 kepler ssb Jul 17 11:34:56 kepler snd_mpu401_uart Jul 17 11:34:56 kepler videobuf_dma_sg Jul 17 11:34:56 kepler videobuf_core Jul 17 11:34:56 kepler rc_core Jul 17 11:34:56 kepler snd_rawmidi Jul 17 11:34:56 kepler i2c_viapro Jul 17 11:34:56 kepler mii Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler Pid: 2841, comm: usb_id Tainted: P 2.6.38-gentoo-r6 #11 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler System Manufacturer System Name Jul 17 11:34:56 kepler / Jul 17 11:34:56 kepler A7V8X Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler EIP: 0060:[<f881446e>] EFLAGS: 00010002 CPU: 0 Jul 17 11:34:56 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 17 11:34:56 kepler EAX: 00000000 EBX: f5e0f400 ECX: 00000008 EDX: 00000000 Jul 17 11:34:56 kepler ESI: 00000000 EDI: 00000000 EBP: f7007e60 ESP: f7007e30 Jul 17 11:34:56 kepler DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 Jul 17 11:34:56 kepler Process usb_id (pid: 2841, ti=f7006000 task=f68bf4a0 task.ti=f7036000) Jul 17 11:34:56 kepler Stack: Jul 17 11:34:56 kepler 00000001 Jul 17 11:34:56 kepler f7007e48 Jul 17 11:34:56 kepler c101e63e Jul 17 11:34:56 kepler f71b0a80 Jul 17 11:34:56 kepler 00000097 Jul 17 11:34:56 kepler 001b0a80 Jul 17 11:34:56 kepler 00000000 Jul 17 11:34:56 kepler 00000086 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler 00000004 Jul 17 11:34:56 kepler f5e0f400 Jul 17 11:34:56 kepler 00000000 Jul 17 11:34:56 kepler 00000000 Jul 17 11:34:56 kepler f7007e70 Jul 17 11:34:56 kepler f87ea59c Jul 17 11:34:56 kepler f5e0f400 Jul 17 11:34:56 kepler f5e0f441 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler f7007ef4 Jul 17 11:34:56 kepler f87ea6dc Jul 17 11:34:56 kepler c132d67f Jul 17 11:34:56 kepler 00000004 Jul 17 11:34:56 kepler 00000002 Jul 17 11:34:56 kepler fa6de004 Jul 17 11:34:56 kepler f6a7e008 Jul 17 11:34:56 kepler f6a7e000 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler Call Trace: Jul 17 11:34:56 kepler [<c101e63e>] ? T.855+0x2e/0x50 Jul 17 11:34:56 kepler [<f87ea59c>] imon_remote_key_lookup+0x1c/0x70 [imon] Jul 17 11:34:56 kepler [<f87ea6dc>] imon_incoming_packet+0x5c/0xe10 [imon] Jul 17 11:34:56 kepler [<c132d67f>] ? pci_read+0x2f/0x40 Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de0b5>] ? _nv004356rm+0x28/0x43 [nvidia] Jul 17 11:34:56 kepler [<f87eb563>] usb_rx_callback_intf0+0x63/0x70 [imon] Jul 17 11:34:56 kepler [<c12853bc>] ? uhci_free_urb_priv+0x9c/0xb0 Jul 17 11:34:56 kepler [<c126e1c8>] usb_hcd_giveback_urb+0x48/0xb0 Jul 17 11:34:56 kepler [<c128545e>] uhci_giveback_urb+0x8e/0x220 Jul 17 11:34:56 kepler [<fa6de187>] ? _nv004352rm+0x19/0x1d [nvidia] Jul 17 11:34:56 kepler [<c1285a86>] uhci_scan_schedule+0x396/0x9a0 Jul 17 11:34:56 kepler [<c1287e41>] uhci_irq+0x91/0x170 Jul 17 11:34:56 kepler [<c126d961>] usb_hcd_irq+0x21/0x60 Jul 17 11:34:56 kepler [<c10501ee>] handle_IRQ_event+0x2e/0xc0 Jul 17 11:34:56 kepler [<c10166ad>] ? ack_apic_level+0x3d/0x100 Jul 17 11:34:56 kepler [<c1052180>] ? handle_fasteoi_irq+0x0/0xf0 Jul 17 11:34:56 kepler [<c10521df>] handle_fasteoi_irq+0x5f/0xf0 Jul 17 11:34:56 kepler <IRQ> Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler [<c100430a>] ? do_IRQ+0x3a/0xb0 Jul 17 11:34:56 kepler [<c1003169>] ? common_interrupt+0x29/0x30 Jul 17 11:34:56 kepler [<c106fbb0>] ? vma_prio_tree_remove+0x0/0x100 Jul 17 11:34:56 kepler [<c1078b16>] ? __remove_shared_vm_struct+0x36/0x50 Jul 17 11:34:56 kepler [<c1078b4e>] ? unlink_file_vma+0x1e/0x40 Jul 17 11:34:56 kepler [<c1076cc3>] ? free_pgtables+0x43/0x90 Jul 17 11:34:56 kepler [<c1078840>] ? exit_mmap+0xe0/0x160 Jul 17 11:34:56 kepler [<c1021366>] ? mmput+0x26/0xb0 Jul 17 11:34:56 kepler [<c1024ed0>] ? exit_mm+0xe0/0x100 Jul 17 11:34:56 kepler [<c1026ad5>] ? do_exit+0x5a5/0x680 Jul 17 11:34:56 kepler [<c1088530>] ? vfs_write+0x100/0x140 Jul 17 11:34:56 kepler [<c1087a10>] ? do_sync_write+0x0/0xd0 Jul 17 11:34:56 kepler [<c1026bdc>] ? do_group_exit+0x2c/0x90 Jul 17 11:34:56 kepler [<c1026c53>] ? sys_exit_group+0x13/0x20 Jul 17 11:34:56 kepler [<c1002c50>] ? sysenter_do_call+0x12/0x26 Jul 17 11:34:56 kepler Code: Jul 17 11:34:56 kepler ff Jul 17 11:34:56 kepler ff Jul 17 11:34:56 kepler 8d Jul 17 11:34:56 kepler 74 Jul 17 11:34:56 kepler 26 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 8d Jul 17 11:34:56 kepler bc Jul 17 11:34:56 kepler 27 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 55 Jul 17 11:34:56 kepler 89 Jul 17 11:34:56 kepler e5 Jul 17 11:34:56 kepler 57 Jul 17 11:34:56 kepler 56 Jul 17 11:34:56 kepler 53 Jul 17 11:34:56 kepler 83 Jul 17 11:34:56 kepler ec Jul 17 11:34:56 kepler 24 Jul 17 11:34:56 kepler 89 Jul 17 11:34:56 kepler 45 Jul 17 11:34:56 kepler e8 Jul 17 11:34:56 kepler 9c Jul 17 11:34:56 kepler 8f Jul 17 11:34:56 kepler 45 Jul 17 11:34:56 kepler ec Jul 17 11:34:56 kepler fa Jul 17 11:34:56 kepler 89 Jul 17 11:34:56 kepler e0 Jul 17 11:34:56 kepler 25 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler e0 Jul 17 11:34:56 kepler ff Jul 17 11:34:56 kepler ff Jul 17 11:34:56 kepler ff Jul 17 11:34:56 kepler 40 Jul 17 11:34:56 kepler 14 Jul 17 11:34:56 kepler 8b Jul 17 11:34:56 kepler 45 Jul 17 11:34:56 kepler e8 Jul 17 11:34:56 kepler syslog-ng[2255]: Error processing log message: <8b> Jul 17 11:34:56 kepler 80 Jul 17 11:34:56 kepler d4 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 00 Jul 17 11:34:56 kepler 89 Jul 17 11:34:56 kepler c3 Jul 17 11:34:56 kepler 89 Jul 17 11:34:56 kepler 45 Jul 17 11:34:56 kepler f0 Jul 17 11:34:56 kepler 4b Jul 17 11:34:56 kepler 78 Jul 17 11:34:56 kepler 38 Jul 17 11:34:56 kepler 8b Jul 17 11:34:56 kepler 45 Jul 17 11:34:56 kepler e8 Jul 17 11:34:56 kepler 31 Jul 17 11:34:56 kepler c9 Jul 17 11:34:56 kepler 8b Jul 17 11:34:56 kepler b0 Jul 17 11:34:56 kepler Jul 17 11:34:56 kepler EIP: [<f881446e>] Jul 17 11:34:56 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 17 11:34:56 kepler SS:ESP 0068:f7007e30 Jul 17 11:34:56 kepler CR2: 00000000000000d4 Jul 17 11:34:56 kepler ---[ end trace ce1de56c8de1850d ]--- Jul 17 11:34:56 kepler Kernel panic - not syncing: Fatal exception in interrupt Jul 17 11:34:56 kepler Pid: 2841, comm: usb_id Tainted: P D 2.6.38-gentoo-r6 #11 Jul 17 11:34:56 kepler Call Trace: Jul 17 11:34:56 kepler [<c13c7c78>] ? panic+0x61/0x145 Jul 17 11:34:56 kepler [<c10057f0>] ? oops_begin+0x0/0x40 Jul 17 11:34:56 kepler [<c1018dce>] ? no_context+0xbe/0x150 Jul 17 11:34:56 kepler [<c1018eef>] ? __bad_area_nosemaphore+0x8f/0x130 Jul 17 11:34:56 kepler [<c1018fa2>] ? bad_area_nosemaphore+0x12/0x20 Jul 17 11:34:56 kepler [<c101936b>] ? do_page_fault+0x25b/0x420 Jul 17 11:34:56 kepler [<c1286c66>] ? uhci_alloc_td+0x16/0x40 Jul 17 11:34:56 kepler [<c1286c66>] ? uhci_alloc_td+0x16/0x40 Jul 17 11:34:56 kepler [<c1286fef>] ? uhci_submit_common+0x22f/0x340 Jul 17 11:34:56 kepler [<c1019110>] ? do_page_fault+0x0/0x420 Jul 17 11:34:56 kepler [<c13ca0b4>] ? error_code+0x58/0x60 Jul 17 11:34:56 kepler [<c1019110>] ? do_page_fault+0x0/0x420 Jul 17 11:34:56 kepler [<f881446e>] ? rc_g_keycode_from_table+0x1e/0xe0 [rc_core] Jul 17 11:34:56 kepler [<c101e63e>] ? T.855+0x2e/0x50 Jul 17 11:34:56 kepler [<f87ea59c>] ? imon_remote_key_lookup+0x1c/0x70 [imon] Jul 17 11:34:56 kepler [<f87ea6dc>] ? imon_incoming_packet+0x5c/0xe10 [imon] Jul 17 11:34:56 kepler [<c132d67f>] ? pci_read+0x2f/0x40 Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] Jul 17 11:34:56 kepler [<fa6de0b5>] ? _nv004356rm+0x28/0x43 [nvidia] Jul 17 11:34:56 kepler [<f87eb563>] ? usb_rx_callback_intf0+0x63/0x70 [imon] Jul 17 11:34:56 kepler [<c12853bc>] ? uhci_free_urb_priv+0x9c/0xb0 Jul 17 11:34:56 kepler [<c126e1c8>] ? usb_hcd_giveback_urb+0x48/0xb0 Jul 17 11:34:56 kepler [<c128545e>] ? uhci_giveback_urb+0x8e/0x220 Jul 17 11:34:56 kepler [<fa6de187>] ? _nv004352rm+0x19/0x1d [nvidia] Jul 17 11:34:56 kepler [<c1285a86>] ? uhci_scan_schedule+0x396/0x9a0 Jul 17 11:34:56 kepler [<c1287e41>] ? uhci_irq+0x91/0x170 Jul 17 11:34:56 kepler [<c126d961>] ? usb_hcd_irq+0x21/0x60 Jul 17 11:34:56 kepler [<c10501ee>] ? handle_IRQ_event+0x2e/0xc0 Jul 17 11:34:56 kepler [<c10166ad>] ? ack_apic_level+0x3d/0x100 Jul 17 11:34:56 kepler [<c1052180>] ? handle_fasteoi_irq+0x0/0xf0 Jul 17 11:34:56 kepler [<c10521df>] ? handle_fasteoi_irq+0x5f/0xf0 Jul 17 11:34:56 kepler <IRQ> Jul 17 11:34:56 kepler [<c100430a>] ? do_IRQ+0x3a/0xb0 Jul 17 11:34:56 kepler [<c1003169>] ? common_interrupt+0x29/0x30 Jul 17 11:34:56 kepler [<c106fbb0>] ? vma_prio_tree_remove+0x0/0x100 Jul 17 11:34:56 kepler [<c1078b16>] ? __remove_shared_vm_struct+0x36/0x50 Jul 17 11:34:56 kepler [<c1078b4e>] ? unlink_file_vma+0x1e/0x40 Jul 17 11:34:56 kepler [<c1076cc3>] ? free_pgtables+0x43/0x90 Jul 17 11:34:56 kepler [<c1078840>] ? exit_mmap+0xe0/0x160 Jul 17 11:34:56 kepler [<c1021366>] ? mmput+0x26/0xb0 Jul 17 11:34:56 kepler [<c1024ed0>] ? exit_mm+0xe0/0x100 Jul 17 11:34:56 kepler [<c1026ad5>] ? do_exit+0x5a5/0x680 Jul 17 11:34:56 kepler [<c1088530>] ? vfs_write+0x100/0x140 Jul 17 11:34:56 kepler [<c1087a10>] ? do_sync_write+0x0/0xd0 Jul 17 11:34:56 kepler [<c1026bdc>] ? do_group_exit+0x2c/0x90 Jul 17 11:34:56 kepler [<c1026c53>] ? sys_exit_group+0x13/0x20 Jul 17 11:34:56 kepler [<c1002c50>] ? sysenter_do_call+0x12/0x26 n -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-17 1:38 ` Chris W @ 2011-07-17 13:36 ` Andy Walls 2011-07-18 15:04 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Andy Walls @ 2011-07-17 13:36 UTC (permalink / raw) To: Chris W; +Cc: Jarod Wilson, Linux Media Mailing List, linux-kernel, Randy Dunlap On Sun, 2011-07-17 at 11:38 +1000, Chris W wrote: > On 17/07/11 10:43, Andy Walls wrote: > > This is an obviously repeatable NULL pointer dereference in > > rc_g_keycode_from_table(). The faulting line of code in both cases > > disasembles to: > > > > 1e: 8b 80 dc 00 00 00 mov 0xdc(%eax),%eax > > > > %eax obviously holds the value 0 (NULL). But I'm having a hard time > > telling to where exactly that line of assembly corresponds in > > rc_g_keycode_from_table(). And I can't tell from the source which data > > structure has something at offset 0xdc that gets derefernced early: > > struct rc_dev or struct rc_map. > > > > Could you provide the output of > > > > $ locate rc-core.ko > > $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko > > > > for the rc_g_keycode_from_table() function? > > > I have a few copies lying about now. > This is from my current running kernel > /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko > > and the partial objdump and corresponding oops/crash output: Thanks. > 00000450 <rc_g_keycode_from_table>: > rc_g_keycode_from_table(): > 450: 55 push %ebp > 451: 89 e5 mov %esp,%ebp > 453: 57 push %edi > 454: 56 push %esi > 455: 53 push %ebx > 456: 83 ec 24 sub $0x24,%esp Store the (struct rc_dev *) "dev" input argument on the stack > 459: 89 45 e8 mov %eax,-0x18(%ebp) local_irq_save(flags): > 45c: 9c pushf > 45d: 8f 45 ec popl -0x14(%ebp) > 460: fa cli preempt_disable(): > 461: 89 e0 mov %esp,%eax > 463: 25 00 e0 ff ff and $0xffffe000,%eax > 468: ff 40 14 incl 0x14(%eax) Move (struct rc_dev *) dev into %eax > 46b: 8b 45 e8 mov -0x18(%ebp),%eax &dev->rc_map->lock > 46e: 8b 80 d4 00 00 00 mov 0xd4(%eax),%eax But that's where the Oops always happens, so the "dev" input argument to the function is NULL. Someone familiar with the driver/media/rc/imon.c file needs to figure out how rc_g_keycode_from_table() can be called with a NULL first argument: ictx->rdev is NULL when rc_g_keycode_from_table(ictx->rdev,...) is called. There might be some race at driver initialization, given that at first look ictx-rdev being NULL seems impossible. Your stack backtraces always indicate some sort of IRQ context, so maybe that matters. Regards, Andy > 474: 89 c3 mov %eax,%ebx > 476: 89 45 f0 mov %eax,-0x10(%ebp) > 479: 4b dec %ebx > 47a: 78 38 js 4b4 <rc_g_keycode_from_table+0x64> > 47c: 8b 45 e8 mov -0x18(%ebp),%eax > 47f: 31 c9 xor %ecx,%ecx > 481: 8b b0 cc 00 00 00 mov 0xcc(%eax),%esi > 487: eb 0e jmp 497 <rc_g_keycode_from_table+0x47> > 489: 8d b4 26 00 00 00 00 lea 0x0(%esi,%eiz,1),%esi > 490: 8d 48 01 lea 0x1(%eax),%ecx > 493: 39 d9 cmp %ebx,%ecx > 495: 7f 1d jg 4b4 <rc_g_keycode_from_table+0x64> > 497: 8d 04 0b lea (%ebx,%ecx,1),%eax > 49a: 89 c7 mov %eax,%edi > 49c: c1 ef 1f shr $0x1f,%edi > 49f: 8d 04 07 lea (%edi,%eax,1),%eax > 4a2: d1 f8 sar %eax > 4a4: 8d 3c c6 lea (%esi,%eax,8),%edi > 4a7: 3b 17 cmp (%edi),%edx > 4a9: 77 e5 ja 490 <rc_g_keycode_from_table+0x40> > 4ab: 73 3b jae 4e8 <rc_g_keycode_from_table+0x98> > 4ad: 8d 58 ff lea -0x1(%eax),%ebx > 4b0: 39 d9 cmp %ebx,%ecx > 4b2: 7e e3 jle 497 <rc_g_keycode_from_table+0x47> > 4b4: 31 db xor %ebx,%ebx > 4b6: ff 75 ec pushl -0x14(%ebp) > 4b9: 9d popf > 4ba: 89 e0 mov %esp,%eax > 4bc: 25 00 e0 ff ff and $0xffffe000,%eax > 4c1: ff 48 14 decl 0x14(%eax) > 4c4: 8b 40 08 mov 0x8(%eax),%eax > 4c7: a8 08 test $0x8,%al > 4c9: 75 52 jne 51d <rc_g_keycode_from_table+0xcd> > 4cb: 85 db test %ebx,%ebx > 4cd: 74 0a je 4d9 <rc_g_keycode_from_table+0x89> > 4cf: 8b 3d 00 00 00 00 mov 0x0,%edi > 4d5: 85 ff test %edi,%edi > 4d7: 7f 19 jg 4f2 <rc_g_keycode_from_table+0xa2> > 4d9: 83 c4 24 add $0x24,%esp > 4dc: 89 d8 mov %ebx,%eax > 4de: 5b pop %ebx > 4df: 5e pop %esi > 4e0: 5f pop %edi > 4e1: c9 leave > 4e2: c3 ret > 4e3: 90 nop > 4e4: 8d 74 26 00 lea 0x0(%esi,%eiz,1),%esi > 4e8: 3b 45 f0 cmp -0x10(%ebp),%eax > 4eb: 73 c7 jae 4b4 <rc_g_keycode_from_table+0x64> > 4ed: 8b 5f 04 mov 0x4(%edi),%ebx > 4f0: eb c4 jmp 4b6 <rc_g_keycode_from_table+0x66> > 4f2: 89 54 24 0c mov %edx,0xc(%esp) > 4f6: 8b 55 e8 mov -0x18(%ebp),%edx > 4f9: 89 5c 24 10 mov %ebx,0x10(%esp) > 4fd: 8b 82 b4 00 00 00 mov 0xb4(%edx),%eax > 503: c7 44 24 04 19 01 00 movl $0x119,0x4(%esp) > 50a: 00 > 50b: c7 04 24 bc 00 00 00 movl $0xbc,(%esp) > 512: 89 44 24 08 mov %eax,0x8(%esp) > 516: e8 fc ff ff ff call 517 <rc_g_keycode_from_table+0xc7> > 51b: eb bc jmp 4d9 <rc_g_keycode_from_table+0x89> > 51d: 89 55 e4 mov %edx,-0x1c(%ebp) > 520: e8 fc ff ff ff call 521 <rc_g_keycode_from_table+0xd1> > 525: 8b 55 e4 mov -0x1c(%ebp),%edx > 528: eb a1 jmp 4cb <rc_g_keycode_from_table+0x7b> > 52a: 8d b6 00 00 00 00 lea 0x0(%esi),%esi > chrisw@newton ~ $ > > > > cat /var/log/kepler-netconsole.log > Jul 17 11:34:56 kepler BUG: unable to handle kernel > Jul 17 11:34:56 kepler NULL pointer dereference > Jul 17 11:34:56 kepler at 000000d4 > Jul 17 11:34:56 kepler IP: > Jul 17 11:34:56 kepler [<f881446e>] rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 17 11:34:56 kepler *pde = 00000000 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler Oops: 0000 [#1] > Jul 17 11:34:56 kepler PREEMPT > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler last sysfs file: > /sys/devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input7/name > Jul 17 11:34:56 kepler Modules linked in: > Jul 17 11:34:56 kepler imon(+) > Jul 17 11:34:56 kepler netconsole > Jul 17 11:34:56 kepler asb100 > Jul 17 11:34:56 kepler hwmon_vid > Jul 17 11:34:56 kepler nvidia(P) > Jul 17 11:34:56 kepler cx22702 > Jul 17 11:34:56 kepler dvb_pll > Jul 17 11:34:56 kepler mt352 > Jul 17 11:34:56 kepler cx88_dvb > Jul 17 11:34:56 kepler cx88_vp3054_i2c > Jul 17 11:34:56 kepler rc_winfast > Jul 17 11:34:56 kepler videobuf_dvb > Jul 17 11:34:56 kepler rc_rc6_mce > Jul 17 11:34:56 kepler cx8800 > Jul 17 11:34:56 kepler cx8802 > Jul 17 11:34:56 kepler snd_via82xx > Jul 17 11:34:56 kepler cx88xx > Jul 17 11:34:56 kepler mceusb > Jul 17 11:34:56 kepler b44 > Jul 17 11:34:56 kepler i2c_algo_bit > Jul 17 11:34:56 kepler tveeprom > Jul 17 11:34:56 kepler snd_ac97_codec > Jul 17 11:34:56 kepler ir_rc6_decoder > Jul 17 11:34:56 kepler btcx_risc > Jul 17 11:34:56 kepler ac97_bus > Jul 17 11:34:56 kepler ssb > Jul 17 11:34:56 kepler snd_mpu401_uart > Jul 17 11:34:56 kepler videobuf_dma_sg > Jul 17 11:34:56 kepler videobuf_core > Jul 17 11:34:56 kepler rc_core > Jul 17 11:34:56 kepler snd_rawmidi > Jul 17 11:34:56 kepler i2c_viapro > Jul 17 11:34:56 kepler mii > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler Pid: 2841, comm: usb_id Tainted: P > 2.6.38-gentoo-r6 #11 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler System Manufacturer System Name > Jul 17 11:34:56 kepler / > Jul 17 11:34:56 kepler A7V8X > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler EIP: 0060:[<f881446e>] EFLAGS: 00010002 CPU: 0 > Jul 17 11:34:56 kepler EIP is at rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 17 11:34:56 kepler EAX: 00000000 EBX: f5e0f400 ECX: 00000008 EDX: > 00000000 > Jul 17 11:34:56 kepler ESI: 00000000 EDI: 00000000 EBP: f7007e60 ESP: > f7007e30 > Jul 17 11:34:56 kepler DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 > Jul 17 11:34:56 kepler Process usb_id (pid: 2841, ti=f7006000 > task=f68bf4a0 task.ti=f7036000) > Jul 17 11:34:56 kepler Stack: > Jul 17 11:34:56 kepler 00000001 > Jul 17 11:34:56 kepler f7007e48 > Jul 17 11:34:56 kepler c101e63e > Jul 17 11:34:56 kepler f71b0a80 > Jul 17 11:34:56 kepler 00000097 > Jul 17 11:34:56 kepler 001b0a80 > Jul 17 11:34:56 kepler 00000000 > Jul 17 11:34:56 kepler 00000086 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler 00000004 > Jul 17 11:34:56 kepler f5e0f400 > Jul 17 11:34:56 kepler 00000000 > Jul 17 11:34:56 kepler 00000000 > Jul 17 11:34:56 kepler f7007e70 > Jul 17 11:34:56 kepler f87ea59c > Jul 17 11:34:56 kepler f5e0f400 > Jul 17 11:34:56 kepler f5e0f441 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler f7007ef4 > Jul 17 11:34:56 kepler f87ea6dc > Jul 17 11:34:56 kepler c132d67f > Jul 17 11:34:56 kepler 00000004 > Jul 17 11:34:56 kepler 00000002 > Jul 17 11:34:56 kepler fa6de004 > Jul 17 11:34:56 kepler f6a7e008 > Jul 17 11:34:56 kepler f6a7e000 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler Call Trace: > Jul 17 11:34:56 kepler [<c101e63e>] ? T.855+0x2e/0x50 > Jul 17 11:34:56 kepler [<f87ea59c>] imon_remote_key_lookup+0x1c/0x70 [imon] > Jul 17 11:34:56 kepler [<f87ea6dc>] imon_incoming_packet+0x5c/0xe10 [imon] > Jul 17 11:34:56 kepler [<c132d67f>] ? pci_read+0x2f/0x40 > Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de0b5>] ? _nv004356rm+0x28/0x43 [nvidia] > Jul 17 11:34:56 kepler [<f87eb563>] usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 17 11:34:56 kepler [<c12853bc>] ? uhci_free_urb_priv+0x9c/0xb0 > Jul 17 11:34:56 kepler [<c126e1c8>] usb_hcd_giveback_urb+0x48/0xb0 > Jul 17 11:34:56 kepler [<c128545e>] uhci_giveback_urb+0x8e/0x220 > Jul 17 11:34:56 kepler [<fa6de187>] ? _nv004352rm+0x19/0x1d [nvidia] > Jul 17 11:34:56 kepler [<c1285a86>] uhci_scan_schedule+0x396/0x9a0 > Jul 17 11:34:56 kepler [<c1287e41>] uhci_irq+0x91/0x170 > Jul 17 11:34:56 kepler [<c126d961>] usb_hcd_irq+0x21/0x60 > Jul 17 11:34:56 kepler [<c10501ee>] handle_IRQ_event+0x2e/0xc0 > Jul 17 11:34:56 kepler [<c10166ad>] ? ack_apic_level+0x3d/0x100 > Jul 17 11:34:56 kepler [<c1052180>] ? handle_fasteoi_irq+0x0/0xf0 > Jul 17 11:34:56 kepler [<c10521df>] handle_fasteoi_irq+0x5f/0xf0 > Jul 17 11:34:56 kepler <IRQ> > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler [<c100430a>] ? do_IRQ+0x3a/0xb0 > Jul 17 11:34:56 kepler [<c1003169>] ? common_interrupt+0x29/0x30 > Jul 17 11:34:56 kepler [<c106fbb0>] ? vma_prio_tree_remove+0x0/0x100 > Jul 17 11:34:56 kepler [<c1078b16>] ? __remove_shared_vm_struct+0x36/0x50 > Jul 17 11:34:56 kepler [<c1078b4e>] ? unlink_file_vma+0x1e/0x40 > Jul 17 11:34:56 kepler [<c1076cc3>] ? free_pgtables+0x43/0x90 > Jul 17 11:34:56 kepler [<c1078840>] ? exit_mmap+0xe0/0x160 > Jul 17 11:34:56 kepler [<c1021366>] ? mmput+0x26/0xb0 > Jul 17 11:34:56 kepler [<c1024ed0>] ? exit_mm+0xe0/0x100 > Jul 17 11:34:56 kepler [<c1026ad5>] ? do_exit+0x5a5/0x680 > Jul 17 11:34:56 kepler [<c1088530>] ? vfs_write+0x100/0x140 > Jul 17 11:34:56 kepler [<c1087a10>] ? do_sync_write+0x0/0xd0 > Jul 17 11:34:56 kepler [<c1026bdc>] ? do_group_exit+0x2c/0x90 > Jul 17 11:34:56 kepler [<c1026c53>] ? sys_exit_group+0x13/0x20 > Jul 17 11:34:56 kepler [<c1002c50>] ? sysenter_do_call+0x12/0x26 > Jul 17 11:34:56 kepler Code: > Jul 17 11:34:56 kepler ff > Jul 17 11:34:56 kepler ff > Jul 17 11:34:56 kepler 8d > Jul 17 11:34:56 kepler 74 > Jul 17 11:34:56 kepler 26 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 8d > Jul 17 11:34:56 kepler bc > Jul 17 11:34:56 kepler 27 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 55 > Jul 17 11:34:56 kepler 89 > Jul 17 11:34:56 kepler e5 > Jul 17 11:34:56 kepler 57 > Jul 17 11:34:56 kepler 56 > Jul 17 11:34:56 kepler 53 > Jul 17 11:34:56 kepler 83 > Jul 17 11:34:56 kepler ec > Jul 17 11:34:56 kepler 24 > Jul 17 11:34:56 kepler 89 > Jul 17 11:34:56 kepler 45 > Jul 17 11:34:56 kepler e8 > Jul 17 11:34:56 kepler 9c > Jul 17 11:34:56 kepler 8f > Jul 17 11:34:56 kepler 45 > Jul 17 11:34:56 kepler ec > Jul 17 11:34:56 kepler fa > Jul 17 11:34:56 kepler 89 > Jul 17 11:34:56 kepler e0 > Jul 17 11:34:56 kepler 25 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler e0 > Jul 17 11:34:56 kepler ff > Jul 17 11:34:56 kepler ff > Jul 17 11:34:56 kepler ff > Jul 17 11:34:56 kepler 40 > Jul 17 11:34:56 kepler 14 > Jul 17 11:34:56 kepler 8b > Jul 17 11:34:56 kepler 45 > Jul 17 11:34:56 kepler e8 > Jul 17 11:34:56 kepler syslog-ng[2255]: Error processing log message: <8b> > Jul 17 11:34:56 kepler 80 > Jul 17 11:34:56 kepler d4 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 00 > Jul 17 11:34:56 kepler 89 > Jul 17 11:34:56 kepler c3 > Jul 17 11:34:56 kepler 89 > Jul 17 11:34:56 kepler 45 > Jul 17 11:34:56 kepler f0 > Jul 17 11:34:56 kepler 4b > Jul 17 11:34:56 kepler 78 > Jul 17 11:34:56 kepler 38 > Jul 17 11:34:56 kepler 8b > Jul 17 11:34:56 kepler 45 > Jul 17 11:34:56 kepler e8 > Jul 17 11:34:56 kepler 31 > Jul 17 11:34:56 kepler c9 > Jul 17 11:34:56 kepler 8b > Jul 17 11:34:56 kepler b0 > Jul 17 11:34:56 kepler > Jul 17 11:34:56 kepler EIP: [<f881446e>] > Jul 17 11:34:56 kepler rc_g_keycode_from_table+0x1e/0xe0 [rc_core] > Jul 17 11:34:56 kepler SS:ESP 0068:f7007e30 > Jul 17 11:34:56 kepler CR2: 00000000000000d4 > Jul 17 11:34:56 kepler ---[ end trace ce1de56c8de1850d ]--- > Jul 17 11:34:56 kepler Kernel panic - not syncing: Fatal exception in > interrupt > Jul 17 11:34:56 kepler Pid: 2841, comm: usb_id Tainted: P D > 2.6.38-gentoo-r6 #11 > Jul 17 11:34:56 kepler Call Trace: > Jul 17 11:34:56 kepler [<c13c7c78>] ? panic+0x61/0x145 > Jul 17 11:34:56 kepler [<c10057f0>] ? oops_begin+0x0/0x40 > Jul 17 11:34:56 kepler [<c1018dce>] ? no_context+0xbe/0x150 > Jul 17 11:34:56 kepler [<c1018eef>] ? __bad_area_nosemaphore+0x8f/0x130 > Jul 17 11:34:56 kepler [<c1018fa2>] ? bad_area_nosemaphore+0x12/0x20 > Jul 17 11:34:56 kepler [<c101936b>] ? do_page_fault+0x25b/0x420 > Jul 17 11:34:56 kepler [<c1286c66>] ? uhci_alloc_td+0x16/0x40 > Jul 17 11:34:56 kepler [<c1286c66>] ? uhci_alloc_td+0x16/0x40 > Jul 17 11:34:56 kepler [<c1286fef>] ? uhci_submit_common+0x22f/0x340 > Jul 17 11:34:56 kepler [<c1019110>] ? do_page_fault+0x0/0x420 > Jul 17 11:34:56 kepler [<c13ca0b4>] ? error_code+0x58/0x60 > Jul 17 11:34:56 kepler [<c1019110>] ? do_page_fault+0x0/0x420 > Jul 17 11:34:56 kepler [<f881446e>] ? rc_g_keycode_from_table+0x1e/0xe0 > [rc_core] > Jul 17 11:34:56 kepler [<c101e63e>] ? T.855+0x2e/0x50 > Jul 17 11:34:56 kepler [<f87ea59c>] ? imon_remote_key_lookup+0x1c/0x70 > [imon] > Jul 17 11:34:56 kepler [<f87ea6dc>] ? imon_incoming_packet+0x5c/0xe10 [imon] > Jul 17 11:34:56 kepler [<c132d67f>] ? pci_read+0x2f/0x40 > Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de004>] ? _nv004358rm+0x24/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de030>] ? _nv004358rm+0x50/0x70 [nvidia] > Jul 17 11:34:56 kepler [<fa6de0b5>] ? _nv004356rm+0x28/0x43 [nvidia] > Jul 17 11:34:56 kepler [<f87eb563>] ? usb_rx_callback_intf0+0x63/0x70 [imon] > Jul 17 11:34:56 kepler [<c12853bc>] ? uhci_free_urb_priv+0x9c/0xb0 > Jul 17 11:34:56 kepler [<c126e1c8>] ? usb_hcd_giveback_urb+0x48/0xb0 > Jul 17 11:34:56 kepler [<c128545e>] ? uhci_giveback_urb+0x8e/0x220 > Jul 17 11:34:56 kepler [<fa6de187>] ? _nv004352rm+0x19/0x1d [nvidia] > Jul 17 11:34:56 kepler [<c1285a86>] ? uhci_scan_schedule+0x396/0x9a0 > Jul 17 11:34:56 kepler [<c1287e41>] ? uhci_irq+0x91/0x170 > Jul 17 11:34:56 kepler [<c126d961>] ? usb_hcd_irq+0x21/0x60 > Jul 17 11:34:56 kepler [<c10501ee>] ? handle_IRQ_event+0x2e/0xc0 > Jul 17 11:34:56 kepler [<c10166ad>] ? ack_apic_level+0x3d/0x100 > Jul 17 11:34:56 kepler [<c1052180>] ? handle_fasteoi_irq+0x0/0xf0 > Jul 17 11:34:56 kepler [<c10521df>] ? handle_fasteoi_irq+0x5f/0xf0 > Jul 17 11:34:56 kepler <IRQ> > Jul 17 11:34:56 kepler [<c100430a>] ? do_IRQ+0x3a/0xb0 > Jul 17 11:34:56 kepler [<c1003169>] ? common_interrupt+0x29/0x30 > Jul 17 11:34:56 kepler [<c106fbb0>] ? vma_prio_tree_remove+0x0/0x100 > Jul 17 11:34:56 kepler [<c1078b16>] ? __remove_shared_vm_struct+0x36/0x50 > Jul 17 11:34:56 kepler [<c1078b4e>] ? unlink_file_vma+0x1e/0x40 > Jul 17 11:34:56 kepler [<c1076cc3>] ? free_pgtables+0x43/0x90 > Jul 17 11:34:56 kepler [<c1078840>] ? exit_mmap+0xe0/0x160 > Jul 17 11:34:56 kepler [<c1021366>] ? mmput+0x26/0xb0 > Jul 17 11:34:56 kepler [<c1024ed0>] ? exit_mm+0xe0/0x100 > Jul 17 11:34:56 kepler [<c1026ad5>] ? do_exit+0x5a5/0x680 > Jul 17 11:34:56 kepler [<c1088530>] ? vfs_write+0x100/0x140 > Jul 17 11:34:56 kepler [<c1087a10>] ? do_sync_write+0x0/0xd0 > Jul 17 11:34:56 kepler [<c1026bdc>] ? do_group_exit+0x2c/0x90 > Jul 17 11:34:56 kepler [<c1026c53>] ? sys_exit_group+0x13/0x20 > Jul 17 11:34:56 kepler [<c1002c50>] ? sysenter_do_call+0x12/0x26 > n > ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Imon module Oops and kernel hang 2011-07-17 13:36 ` Andy Walls @ 2011-07-18 15:04 ` Jarod Wilson 2011-07-18 16:46 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-18 15:04 UTC (permalink / raw) To: Andy Walls; +Cc: Chris W, Linux Media Mailing List, linux-kernel, Randy Dunlap On Jul 17, 2011, at 9:36 AM, Andy Walls wrote: > On Sun, 2011-07-17 at 11:38 +1000, Chris W wrote: >> On 17/07/11 10:43, Andy Walls wrote: >>> This is an obviously repeatable NULL pointer dereference in >>> rc_g_keycode_from_table(). The faulting line of code in both cases >>> disasembles to: >>> >>> 1e: 8b 80 dc 00 00 00 mov 0xdc(%eax),%eax >>> >>> %eax obviously holds the value 0 (NULL). But I'm having a hard time >>> telling to where exactly that line of assembly corresponds in >>> rc_g_keycode_from_table(). And I can't tell from the source which data >>> structure has something at offset 0xdc that gets derefernced early: >>> struct rc_dev or struct rc_map. >>> >>> Could you provide the output of >>> >>> $ locate rc-core.ko >>> $ objdump -d -l /blah/blah/drivers/media/rc/rc-core.ko >>> >>> for the rc_g_keycode_from_table() function? >> >> >> I have a few copies lying about now. > >> This is from my current running kernel >> /lib/modules/2.6.38-gentoo-r6/kernel/drivers/media/rc/rc-core.ko >> >> and the partial objdump and corresponding oops/crash output: > > Thanks. > > >> 00000450 <rc_g_keycode_from_table>: >> rc_g_keycode_from_table(): >> 450: 55 push %ebp >> 451: 89 e5 mov %esp,%ebp >> 453: 57 push %edi >> 454: 56 push %esi >> 455: 53 push %ebx >> 456: 83 ec 24 sub $0x24,%esp > > Store the (struct rc_dev *) "dev" input argument on the stack >> 459: 89 45 e8 mov %eax,-0x18(%ebp) > > local_irq_save(flags): >> 45c: 9c pushf >> 45d: 8f 45 ec popl -0x14(%ebp) >> 460: fa cli > > preempt_disable(): >> 461: 89 e0 mov %esp,%eax >> 463: 25 00 e0 ff ff and $0xffffe000,%eax >> 468: ff 40 14 incl 0x14(%eax) > > Move (struct rc_dev *) dev into %eax >> 46b: 8b 45 e8 mov -0x18(%ebp),%eax > > &dev->rc_map->lock >> 46e: 8b 80 d4 00 00 00 mov 0xd4(%eax),%eax > > But that's where the Oops always happens, so the "dev" input argument to > the function is NULL. > > Someone familiar with the driver/media/rc/imon.c file needs to figure > out how rc_g_keycode_from_table() can be called with a NULL first > argument: ictx->rdev is NULL when > rc_g_keycode_from_table(ictx->rdev,...) is called. > > There might be some race at driver initialization, given that at first > look ictx-rdev being NULL seems impossible. Your stack backtraces > always indicate some sort of IRQ context, so maybe that matters. Thanks much for the analysis, Andy. I see the problem now. The intf0 urb callback is wired up before the rc_dev is, and the callback is what makes the rc_g_keycode_from_table call. And as far as I know, all 0xffdc devices have the nasty trait of constantly triggering interrupts, even when there's no valid keydata. (SoundGraph fixed that in later devices). The code has been like this for some time, and I do have 0xffdc devices, none of which have hit this somehow, but the fix looks simple and obvious enough. I'll try to get something sent along later today. -- Jarod Wilson jarod@wilsonet.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] [media] imon: don't submit urb before rc_dev set up 2011-07-18 15:04 ` Jarod Wilson @ 2011-07-18 16:46 ` Jarod Wilson 2011-07-18 22:29 ` Chris W 2011-07-22 14:06 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson 0 siblings, 2 replies; 20+ messages in thread From: Jarod Wilson @ 2011-07-18 16:46 UTC (permalink / raw) To: linux-media; +Cc: Jarod Wilson, Andy Walls, Chris W, Randy Dunlap, linux-kernel The interface 0 urb callback was being wired up before the rc_dev device was allocated, meaning the callback could be called with a null rc_dev, leading to an oops. This likely only ever happens on the older 0xffdc SoundGraph devices, which continually trigger interrupts even when they have no valid keydata, and the window in which it could happen is small, but its actually happening regularly for at least one user, and its an obvious fix. Compile and sanity-tested with one of my own imon devices. CC: Andy Walls <awalls@md.metrocast.net> CC: Chris W <lkml@psychogeeks.com> CC: Randy Dunlap <rdunlap@xenotime.net> CC: linux-kernel@vger.kernel.org Reported-by: Chris W <lkml@psychogeeks.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> --- drivers/media/rc/imon.c | 28 ++++++++++++++-------------- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c index caa3e3a..26238f5 100644 --- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -2132,6 +2132,18 @@ static struct imon_context *imon_init_intf0(struct usb_interface *intf) goto find_endpoint_failed; } + ictx->idev = imon_init_idev(ictx); + if (!ictx->idev) { + dev_err(dev, "%s: input device setup failed\n", __func__); + goto idev_setup_failed; + } + + ictx->rdev = imon_init_rdev(ictx); + if (!ictx->rdev) { + dev_err(dev, "%s: rc device setup failed\n", __func__); + goto rdev_setup_failed; + } + usb_fill_int_urb(ictx->rx_urb_intf0, ictx->usbdev_intf0, usb_rcvintpipe(ictx->usbdev_intf0, ictx->rx_endpoint_intf0->bEndpointAddress), @@ -2145,26 +2157,14 @@ static struct imon_context *imon_init_intf0(struct usb_interface *intf) goto urb_submit_failed; } - ictx->idev = imon_init_idev(ictx); - if (!ictx->idev) { - dev_err(dev, "%s: input device setup failed\n", __func__); - goto idev_setup_failed; - } - - ictx->rdev = imon_init_rdev(ictx); - if (!ictx->rdev) { - dev_err(dev, "%s: rc device setup failed\n", __func__); - goto rdev_setup_failed; - } - mutex_unlock(&ictx->lock); return ictx; +urb_submit_failed: + rc_unregister_device(ictx->rdev); rdev_setup_failed: input_unregister_device(ictx->idev); idev_setup_failed: - usb_kill_urb(ictx->rx_urb_intf0); -urb_submit_failed: find_endpoint_failed: mutex_unlock(&ictx->lock); usb_free_urb(tx_urb); -- 1.7.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't submit urb before rc_dev set up 2011-07-18 16:46 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson @ 2011-07-18 22:29 ` Chris W 2011-07-19 12:23 ` Jarod Wilson 2011-07-22 14:06 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson 1 sibling, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-18 22:29 UTC (permalink / raw) To: Jarod Wilson; +Cc: linux-media, Andy Walls, Randy Dunlap, linux-kernel On 19/07/11 02:46, Jarod Wilson wrote: > The interface 0 urb callback was being wired up before the rc_dev device > was allocated, meaning the callback could be called with a null rc_dev, > leading to an oops. This likely only ever happens on the older 0xffdc > SoundGraph devices, which continually trigger interrupts even when they > have no valid keydata, and the window in which it could happen is small, > but its actually happening regularly for at least one user, and its an > obvious fix. Compile and sanity-tested with one of my own imon devices. As the "at least one user" I can confirm that the patch has indeed corrected the problem on my 2.6.38-gentoo-r6, 2.6.39.3 vanilla, and 3.0.0-rc7 kernels. This is what loading the module with the "debug=1" option outputs: input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input7 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2/input8 rc2: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized usbcore: registered new interface driver imon intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 ... The decoded packet lines are fast and furious with no deliberate IR input (the VFD is in use), which might explain how this device managed to break the code in the small window available. Thank you Jarod and Andy for taking the time to track this problem down to give it a drubbing. Regards, Chris -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't submit urb before rc_dev set up 2011-07-18 22:29 ` Chris W @ 2011-07-19 12:23 ` Jarod Wilson 2011-07-19 16:12 ` [PATCH] [media] imon: don't parse scancodes until intf configured Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-19 12:23 UTC (permalink / raw) To: Chris W Cc: Jarod Wilson, linux-media@vger.kernel.org, Andy Walls, Randy Dunlap, linux-kernel@vger.kernel.org On Jul 18, 2011, at 6:29 PM, Chris W <lkml@psychogeeks.com> wrote: > On 19/07/11 02:46, Jarod Wilson wrote: >> The interface 0 urb callback was being wired up before the rc_dev device >> was allocated, meaning the callback could be called with a null rc_dev, >> leading to an oops. This likely only ever happens on the older 0xffdc >> SoundGraph devices, which continually trigger interrupts even when they >> have no valid keydata, and the window in which it could happen is small, >> but its actually happening regularly for at least one user, and its an >> obvious fix. Compile and sanity-tested with one of my own imon devices. > > As the "at least one user" I can confirm that the patch has indeed > corrected the problem on my 2.6.38-gentoo-r6, 2.6.39.3 vanilla, and > 3.0.0-rc7 kernels. > > This is what loading the module with the "debug=1" option outputs: > > input: iMON Panel, Knob and Mouse(15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input7 > imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) Ugh, damn, that change broke the ffdc device auto-detection... Better than a crash, but lemme see if I can alter things slightly so we can have our cake and eat it too... > Registered IR keymap rc-imon-pad > input: iMON Remote (15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2/input8 > rc2: iMON Remote (15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc2 > imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized > usbcore: registered new interface driver imon > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 > ... > > The decoded packet lines are fast and furious with no deliberate IR > input (the VFD is in use), which might explain how this device managed > to break the code in the small window available. Yep. I hate hate hate hate the ffdc imon hardware, for this and multiple other reasons (including the nasty hack used for ffdc device type auto-detection)... My ffdc devices do similar constant spewing, but never triggered the oops, so maybe yours is even worse, or your system is faster, or a kernel config change made a difference here... > Thank you Jarod and Andy for taking the time to track this problem down > to give it a drubbing. Thanks for the testing and patience, hopefully just one more patch to test out before we can say case closed here... --jarod ^ permalink raw reply [flat|nested] 20+ messages in thread
* [PATCH] [media] imon: don't parse scancodes until intf configured 2011-07-19 12:23 ` Jarod Wilson @ 2011-07-19 16:12 ` Jarod Wilson 2011-07-19 22:05 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-19 16:12 UTC (permalink / raw) To: linux-media; +Cc: Jarod Wilson, Andy Walls, Chris W The imon devices have either 1 or 2 usb interfaces on them, each wired up to its own urb callback. The interface 0 urb callback is wired up before the imon context's rc_dev pointer is filled in, which is necessary for imon 0xffdc device auto-detection to work properly, but we need to make sure we don't actually run the callback routines until we've entirely filled in the necessary bits for each given interface, lest we wind up oopsing. Technically, any imon device could have hit this, but the issue is exacerbated on the 0xffdc devices, which send a constant stream of interrupts, even when they have no valid key data. CC: Andy Walls <awalls@md.metrocast.net> CC: Chris W <lkml@psychogeeks.com> Reported-by: Chris W <lkml@psychogeeks.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> --- drivers/media/rc/imon.c | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/drivers/media/rc/imon.c b/drivers/media/rc/imon.c index caa3e3a..6ed9646 100644 --- a/drivers/media/rc/imon.c +++ b/drivers/media/rc/imon.c @@ -1658,7 +1658,7 @@ static void usb_rx_callback_intf0(struct urb *urb) return; ictx = (struct imon_context *)urb->context; - if (!ictx) + if (!ictx || !ictx->dev_present_intf0) return; switch (urb->status) { @@ -1690,7 +1690,7 @@ static void usb_rx_callback_intf1(struct urb *urb) return; ictx = (struct imon_context *)urb->context; - if (!ictx) + if (!ictx || !ictx->dev_present_intf1) return; switch (urb->status) { @@ -2118,7 +2118,6 @@ static struct imon_context *imon_init_intf0(struct usb_interface *intf) ictx->dev = dev; ictx->usbdev_intf0 = usb_get_dev(interface_to_usbdev(intf)); - ictx->dev_present_intf0 = true; ictx->rx_urb_intf0 = rx_urb; ictx->tx_urb = tx_urb; ictx->rf_device = false; @@ -2157,6 +2156,8 @@ static struct imon_context *imon_init_intf0(struct usb_interface *intf) goto rdev_setup_failed; } + ictx->dev_present_intf0 = true; + mutex_unlock(&ictx->lock); return ictx; @@ -2200,7 +2201,6 @@ static struct imon_context *imon_init_intf1(struct usb_interface *intf, } ictx->usbdev_intf1 = usb_get_dev(interface_to_usbdev(intf)); - ictx->dev_present_intf1 = true; ictx->rx_urb_intf1 = rx_urb; ret = -ENODEV; @@ -2229,6 +2229,8 @@ static struct imon_context *imon_init_intf1(struct usb_interface *intf, goto urb_submit_failed; } + ictx->dev_present_intf1 = true; + mutex_unlock(&ictx->lock); return ictx; -- 1.7.1 ^ permalink raw reply related [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't parse scancodes until intf configured 2011-07-19 16:12 ` [PATCH] [media] imon: don't parse scancodes until intf configured Jarod Wilson @ 2011-07-19 22:05 ` Chris W 2011-07-20 13:18 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-19 22:05 UTC (permalink / raw) To: Jarod Wilson; +Cc: linux-media, Andy Walls On 20/07/11 02:12, Jarod Wilson wrote: > The imon devices have either 1 or 2 usb interfaces on them, each wired > up to its own urb callback. The interface 0 urb callback is wired up > before the imon context's rc_dev pointer is filled in, which is > necessary for imon 0xffdc device auto-detection to work properly, but > we need to make sure we don't actually run the callback routines until > we've entirely filled in the necessary bits for each given interface, > lest we wind up oopsing. Technically, any imon device could have hit > this, but the issue is exacerbated on the 0xffdc devices, which send a > constant stream of interrupts, even when they have no valid key data. OK. The patch applies and everything continues to work. There is no obvious difference in the dmesg output on module load, with my device remaining unidentified. I don't know if that is indicative of anything. input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input9 imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input10 rc3: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized usbcore: registered new interface driver imon intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 intf0 decoded packet: 00 00 00 00 00 00 24 01 Regards, Chris -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't parse scancodes until intf configured 2011-07-19 22:05 ` Chris W @ 2011-07-20 13:18 ` Jarod Wilson 2011-07-20 22:56 ` Chris W 0 siblings, 1 reply; 20+ messages in thread From: Jarod Wilson @ 2011-07-20 13:18 UTC (permalink / raw) To: Chris W; +Cc: linux-media, Andy Walls On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: > On 20/07/11 02:12, Jarod Wilson wrote: > > The imon devices have either 1 or 2 usb interfaces on them, each wired > > up to its own urb callback. The interface 0 urb callback is wired up > > before the imon context's rc_dev pointer is filled in, which is > > necessary for imon 0xffdc device auto-detection to work properly, but > > we need to make sure we don't actually run the callback routines until > > we've entirely filled in the necessary bits for each given interface, > > lest we wind up oopsing. Technically, any imon device could have hit > > this, but the issue is exacerbated on the 0xffdc devices, which send a > > constant stream of interrupts, even when they have no valid key data. > > > > OK. The patch applies and everything continues to work. There is no > obvious difference in the dmesg output on module load, with my device > remaining unidentified. I don't know if that is indicative of anything. Did you apply this patch on top of the earlier patch, or instead of it? > input: iMON Panel, Knob and Mouse(15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input9 > imon 4-2:1.0: Unknown 0xffdc device, defaulting to VFD and iMON IR (id 0x00) The 'id 0x00' part should read 'id 0x24', as the ongoing spew below has in index 6, which makes me think you still have the earlier patch applied. You actually want only the newer patch applied. If you only have the newer one applied, then I'll have to take another look to see what's up. > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 > intf0 decoded packet: 00 00 00 00 00 00 24 01 One other amusing tidbit: you get continuous spew like the above, because to date, I thought all the ffdc devices had "nothing to report" spew that started with 0xffffff, which we filter out. Sigh. I hate imon hardware... -- Jarod Wilson jarod@redhat.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't parse scancodes until intf configured 2011-07-20 13:18 ` Jarod Wilson @ 2011-07-20 22:56 ` Chris W 2011-07-26 17:57 ` Jarod Wilson 0 siblings, 1 reply; 20+ messages in thread From: Chris W @ 2011-07-20 22:56 UTC (permalink / raw) To: Jarod Wilson; +Cc: linux-media, Andy Walls On 20/07/11 23:18, Jarod Wilson wrote: > On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: >> On 20/07/11 02:12, Jarod Wilson wrote: >>> The imon devices have either 1 or 2 usb interfaces on them, each wired >>> up to its own urb callback. The interface 0 urb callback is wired up >>> before the imon context's rc_dev pointer is filled in, which is >>> necessary for imon 0xffdc device auto-detection to work properly, but >>> we need to make sure we don't actually run the callback routines until >>> we've entirely filled in the necessary bits for each given interface, >>> lest we wind up oopsing. Technically, any imon device could have hit >>> this, but the issue is exacerbated on the 0xffdc devices, which send a >>> constant stream of interrupts, even when they have no valid key data. >> >> >> >> OK. The patch applies and everything continues to work. There is no >> obvious difference in the dmesg output on module load, with my device >> remaining unidentified. I don't know if that is indicative of anything. > > Did you apply this patch on top of the earlier patch, or instead of it? On top of it. I've reversed the patches and installed just the last one with this result on loading the module: input: iMON Panel, Knob and Mouse(15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input8 imon 4-2:1.0: 0xffdc iMON VFD, iMON IR (id 0x24) Registered IR keymap rc-imon-pad input: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input9 rc3: iMON Remote (15c2:ffdc) as /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3 imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized usbcore: registered new interface driver imon Much better. >> intf0 decoded packet: 00 00 00 00 00 00 24 01 >> intf0 decoded packet: 00 00 00 00 00 00 24 01 >> intf0 decoded packet: 00 00 00 00 00 00 24 01 > > One other amusing tidbit: you get continuous spew like the above, because > to date, I thought all the ffdc devices had "nothing to report" spew that > started with 0xffffff, which we filter out. Sigh. I hate imon hardware... I am beginning to understand why. That output was only printed with the "debug=1" option and is not printed with the patched module. Regards, Chris -- Chris Williams Brisbane, Australia ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't parse scancodes until intf configured 2011-07-20 22:56 ` Chris W @ 2011-07-26 17:57 ` Jarod Wilson 0 siblings, 0 replies; 20+ messages in thread From: Jarod Wilson @ 2011-07-26 17:57 UTC (permalink / raw) To: Chris W; +Cc: linux-media, Andy Walls Chris W wrote: > On 20/07/11 23:18, Jarod Wilson wrote: >> On Wed, Jul 20, 2011 at 08:05:43AM +1000, Chris W wrote: >>> On 20/07/11 02:12, Jarod Wilson wrote: >>>> The imon devices have either 1 or 2 usb interfaces on them, each wired >>>> up to its own urb callback. The interface 0 urb callback is wired up >>>> before the imon context's rc_dev pointer is filled in, which is >>>> necessary for imon 0xffdc device auto-detection to work properly, but >>>> we need to make sure we don't actually run the callback routines until >>>> we've entirely filled in the necessary bits for each given interface, >>>> lest we wind up oopsing. Technically, any imon device could have hit >>>> this, but the issue is exacerbated on the 0xffdc devices, which send a >>>> constant stream of interrupts, even when they have no valid key data. >>> >>> >>> OK. The patch applies and everything continues to work. There is no >>> obvious difference in the dmesg output on module load, with my device >>> remaining unidentified. I don't know if that is indicative of anything. >> Did you apply this patch on top of the earlier patch, or instead of it? > > On top of it. I've reversed the patches and installed just the last > one with this result on loading the module: > > input: iMON Panel, Knob and Mouse(15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/input/input8 > imon 4-2:1.0: 0xffdc iMON VFD, iMON IR (id 0x24) > Registered IR keymap rc-imon-pad > input: iMON Remote (15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3/input9 > rc3: iMON Remote (15c2:ffdc) as > /devices/pci0000:00/0000:00:10.2/usb4/4-2/4-2:1.0/rc/rc3 > imon 4-2:1.0: iMON device (15c2:ffdc, intf0) on usb<4:3> initialized > usbcore: registered new interface driver imon > > Much better. Yeah, that looks sane now. We missed 3.0, but I'll try to flag this one to go into the various stable trees when it gets merged for 3.1. >>> intf0 decoded packet: 00 00 00 00 00 00 24 01 >>> intf0 decoded packet: 00 00 00 00 00 00 24 01 >>> intf0 decoded packet: 00 00 00 00 00 00 24 01 >> One other amusing tidbit: you get continuous spew like the above, because >> to date, I thought all the ffdc devices had "nothing to report" spew that >> started with 0xffffff, which we filter out. Sigh. I hate imon hardware... > > I am beginning to understand why. That output was only printed with the > "debug=1" option and is not printed with the patched module. Yup. The additional filtering was added because my own ffdc imon devices were so noisy, it was next to impossible to see what was going on when trying to debug anything. -- Jarod Wilson jarod@redhat.com ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: [PATCH] [media] imon: don't submit urb before rc_dev set up 2011-07-18 16:46 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson 2011-07-18 22:29 ` Chris W @ 2011-07-22 14:06 ` Jarod Wilson 1 sibling, 0 replies; 20+ messages in thread From: Jarod Wilson @ 2011-07-22 14:06 UTC (permalink / raw) To: linux-media; +Cc: Andy Walls, Chris W Jarod Wilson wrote: > The interface 0 urb callback was being wired up before the rc_dev device > was allocated, meaning the callback could be called with a null rc_dev, > leading to an oops. This likely only ever happens on the older 0xffdc > SoundGraph devices, which continually trigger interrupts even when they > have no valid keydata, and the window in which it could happen is small, > but its actually happening regularly for at least one user, and its an > obvious fix. Compile and sanity-tested with one of my own imon devices. Explicit self-nak on this one, just to crystal-clear, since this is handled without breaking ffdc device detection by a later patch. -- Jarod Wilson jarod@redhat.com ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2011-07-26 17:57 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4E1B978C.2030407@psychogeeks.com>
2011-07-12 15:03 ` Imon module Oops and kernel hang Randy Dunlap
2011-07-12 19:55 ` Jarod Wilson
2011-07-12 22:35 ` Chris W
2011-07-13 4:20 ` Jarod Wilson
2011-07-13 5:42 ` Chris W
2011-07-13 22:11 ` Jarod Wilson
2011-07-14 2:41 ` Chris W
2011-07-17 0:43 ` Andy Walls
2011-07-17 1:38 ` Chris W
2011-07-17 13:36 ` Andy Walls
2011-07-18 15:04 ` Jarod Wilson
2011-07-18 16:46 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson
2011-07-18 22:29 ` Chris W
2011-07-19 12:23 ` Jarod Wilson
2011-07-19 16:12 ` [PATCH] [media] imon: don't parse scancodes until intf configured Jarod Wilson
2011-07-19 22:05 ` Chris W
2011-07-20 13:18 ` Jarod Wilson
2011-07-20 22:56 ` Chris W
2011-07-26 17:57 ` Jarod Wilson
2011-07-22 14:06 ` [PATCH] [media] imon: don't submit urb before rc_dev set up Jarod Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox