* 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, Andy Walls, Randy Dunlap, linux-kernel
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 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
* 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
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;
as well as URLs for NNTP newsgroup(s).