On Sun, 2008-05-18 at 09:33 +0100, tim moore wrote:
> IVTV - Problem Unable to handle kernel paging request at 0000001788338e28
>
> So the issue I am seeing is a problem with ivtv and a winpvr-250.
> As the card loads I get a stack trace from the card when it tries to
> initialise the tuner.
>
> Many thanks for looking. any help appreciated.
>
>
> Previous to this I have installed a dvb-t usb with no problem,
> currently this is unplugged to prevent confusion.
>
> Linux zen 2.6.22.17-0.1-default #1 SMP 2008/02/10 20:01:04 UTC x86_64
> x86_64 x86_64 GNU/Linux
>
> openSuSe 10.3 Kernel
>
> UK based PAL tv standard.
>
> Intel MB Tyan S5150 #Tomcat i7221
>
> Hauppauge Win PVR-250
>
> Using V4L via mercurial. have updated from the tree -
>
> make release
> make ivtv-update
> make update
>
> make clean
> make allmodconfig
> make install
>
> depmod -a
> mkinitrd
>
> reboot.
Please do a
$ find /lib/modules -name "*tuner*ko" -print
and look for duplicate versions of the tuner modules in the same kernel
version tree. I'm betting you're using old, incompatible versions from
under "video" than from under "common". The tuner modules moved
recently. You should delete or move the older tuner modules out of the
way if you are otherwise using newer v4l-dvb modules.
That's the short answer. You can stop here if you want. :)
Below is how I "read the tea leaves" of the logs and kernel ooops. If
you think I got any of the below wrong, please correct me. (I'm not too
old to learn).
> more info from logs
>
> <6>ivtv: ==================== START INIT IVTV ====================
> <6>ivtv: version 1.0.0 (2.6.22.17-0.1-default SMP mod_unload ) loading
> <6>ivtv0: Autodetected Hauppauge card (cx23416 based)
> <6>ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 21 (level, low) -> IRQ 21
> <6>ivtv0: Unreasonably low latency timer, setting to 64 (was 32)
> <6>ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
> <6>ivtv0: Encoder revision: 0x02060039
> <6>ivtv i2c driver #0: Test OK
> <6>tveeprom 1-0050: Hauppauge model 32035, rev B135, serial# 6937649
> <6>tveeprom 1-0050: tuner model is Temic 4066FY5 (idx 35, type 18)
> <6>tveeprom 1-0050: TV standards PAL(I) (eeprom 0x10)
> <6>tveeprom 1-0050: audio processor is MSP3415 (idx 6)
> <6>tveeprom 1-0050: decoder processor is SAA7115 (idx 19)
> <6>tveeprom 1-0050: has no radio, has IR receiver, has no IR transmitter
> <6>ivtv0: Autodetected Hauppauge WinTV PVR-250
> <6>tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0)
What follows is a kernel oops emitted from the architecture specific
linux/arch/x86_64/mm/fault.c:do_page_fault(). The most likely path
within do_page_fault() to the fault you experienced, is a kernel access
to a kernel space memory area that is not part of the VMALLOC area and
is not mapped.
> <1>Unable to handle kernel paging request at 0000001788338e28
The offending virtual address that the kernel code attempted to access
was:
0x0000001788338e28 = 0x00000017ffffffe8 + 0xffffffff88338e40
in two's complement addition (ignore the carry out of the msb). See
below to see where these two numbers come from.
As I understand it (and I could be wrong), kernel linear addresses start
at PAGE_OFFSET, usually
0xc0000000
on 32 bit machines, and as much of of physical memory as possible,
starting at physical address 0x0, is mapped for kernel mode access
starting at 0xc0000000. The bad address is certainly above this and
well into kernel space. And I can infer that it probably isn't in the
VMALLOC space since it's not near the top of memory, so it lands in a
huge gap in the linear address space around the 94th Gigabyte of linear
address space. So unless you have ~95 GB of physical memory, no page
will likely be mapped there.
> RIP:
> <1> [_end+130280350/2129733592] :tuner:default_tuner_init+0x1e/0xaa
The bad address access happened in module tuner.ko in the function
default_tuner_init() at offset 0x1e in the machine code for the
function.
> <4>PGD b922b067 PUD 0
> <0>Oops: 0000 [1] SMP
> <0>last sysfs file:
> /devices/pci0000:00/0000:00:1e.0/0000:06:01.0/firmware/0000:06:01.0/loading
> <4>CPU 0
> <4>Modules linked in: tuner ivtv firmware_class i2c_algo_bit cx2341x
> tveeprom parport_pc videodev v4l2_common parport rtc_cmos rtc_core
> button snd_usb_audio i2c_i801 v4l1_compat i2c_core rtc_lib iTCO_wdt
> iTCO_vendor_support snd_pcm snd_timer snd_page_alloc snd_usb_lib
> sr_mod cdrom snd_rawmidi snd_seq_device snd_hwdep shpchp snd
> pci_hotplug soundcore tg3 floppy sg usbhid hid ff_memless ehci_hcd
> sd_mod uhci_hcd usbcore edd ext3 mbcache jbd fan ata_piix ahci libata
> scsi_mod thermal processor
> <4>Pid: 2063, comm: modprobe Tainted: G N 2.6.22.17-0.1-default #1
> <4>RIP: 0010:[_end+130280350/2129733592] [_end+130280350/2129733592]
^^^^
Segment 0010 is the kernel code segment, so kernel code definitely
caused the fault.
> :tuner:default_tuner_init+0x1e/0xaa
In tuner.ko (or tuner-simple.ko) in default_tuner_init()
> <4>RSP: 0000:ffff8100bc05dcc8 EFLAGS: 00010206
> <4>RAX: 00000017ffffffe8 RBX: ffff8100bc852000 RCX: 000000000000003f
^^^^^^^^^^^^^^^^
|
RAX looks bogus -+
> <4>RDX: 000000000000001b RSI: 00000000000000d0 RDI: ffff8100bc852000
> <4>RBP: ffff8100bc852000 R08: 00000000ffffffff R09: 0000000000000001
> <4>R10: ffffffff804db340 R11: ffffffff8036b19f R12: ffff8100bc852000
> <4>R13: ffff8100bc852000 R14: 00000000ffffffff R15: 000000000000000e
RBX, RBP, RDI, R12, R13 all appear to point to local variable storage in
the function and thus are all OK.
RCX, RDX, RSI, R08, R09, R14, R15 are all pretty small and non-zero, so
they are probably OK as well.
> <4>FS: 00002b1f06cfd6f0(0000) GS:ffffffff80500000(0000)
> knlGS:0000000000000000
> <4>CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> <4>CR2: 0000001788338e28 CR3: 00000000b5bc1000 CR4: 00000000000006e0
^^^^^^^^^^^^^^^^
The offending memory reference is stored here
> <4>Process modprobe (pid: 2063, threadinfo ffff8100bc05c000, task
> ffff8100bb088080)
Kernel code invoked by modprobe had the problem
> <4>Stack: ffff8100bc852000 ffff8100bad48800 ffff8100bc852000 ffffffff8832ac27
> <4> 0000000000000000 0000000000000061 ffff8100bc852000 ffff8100b9cf2df0
> <4> 00000000fffffff0 0000000000000061 ffff8100bc852000 0000000000000061
> <4>Call Trace:
> <4> [_end+130274303/2129733592] :tuner:set_type+0x317/0x3c8
> <4> [_end+130275018/2129733592] :tuner:tuner_attach+0x0/0x2c9
> <4> [_end+130275714/2129733592] :tuner:tuner_attach+0x2b8/0x2c9
> <4> [_end+130275018/2129733592] :tuner:tuner_attach+0x0/0x2c9
> <4> [_end+129421699/2129733592] :i2c_core:i2c_probe_address+0xb9/0xfd
> <4> [_end+129425395/2129733592] :i2c_core:i2c_probe+0x162/0x175
> <4> [_end+130275018/2129733592] :tuner:tuner_attach+0x0/0x2c9
The multiple pushes of a return address of "tuner_attach+0x0" on the
stack implies some recursive calls which may be part of the problem.
> <4> [_end+129424348/2129733592] :i2c_core:i2c_register_driver+0xb2/0xed
> <4> [sys_init_module+5864/6103] sys_init_module+0x16e8/0x17d7
> <4> [system_call+126/131] system_call+0x7e/0x83
modprobe started this whole sequence by making a "system_call" to init a
module, probably "tuner.ko".
> <4>
> <4>
> <4>Code: 4c 8b 88 40 8e 33 88 4d 85 c9 74 43 48 8b 43 18 0f b7 4b 02
The more recent kernels I have source and objects for don't have a
default_tuner_init() in tuner.ko or tuner-simple.ko. But using the code
from above, we can see what the final instruction leading up to the
problem is:
$ echo "4c 8b 88 40 8e 33 88 4d 85 c9 74 43 48 8b 43 18 0f b7 4b 02" | xxd -r
-p > a.bin
$ objdump -D -b binary -m i386:x86-64 --adjust-vma=0x1e a.bin
a.bin: file format binary
Disassembly of section .data:
000000000000001e <.data>:
1e: 4c 8b 88 40 8e 33 88 mov 0xffffffff88338e40(%rax),%r9
25: 4d 85 c9 test %r9,%r9
28: 74 43 je 0x6d
2a: 48 8b 43 18 mov 0x18(%rbx),%rax
2e: 0f b7 4b 02 movzwl 0x2(%rbx),%ecx
It's the "mov", which tries to access offset 0xffffffff88338e40 of the
structure at %rax, that causes the page fault. The RAX holds a bad
pointer.
I could elaborate more, if you can provide the source for your kernel
that corresponds to tuner.c or tuner-simple.c, which ever has the
default_tuner_init() function in it, and the disassembly of default
tuner_init from an "objdump -d " from the proper tuner.ko or
tuner-simple.ko under /lib/modules.
Again, I think you're just using an older version of the tuner modules,
that newer drivers are simply passing the newer type of data structures.
If this is the case, then perhaps data objects in the new structure may
be interpreted as pointers by the older module functions and causing the
bad address reference.
Regards,
Andy
> <1>RIP [_end+130280350/2129733592] :tuner:default_tuner_init+0x1e/0xaa
> <4> RSP <ffff8100bc05dcc8>
> <0>CR2: 0000001788338e28
> <3>ivtv0: Failed to load module tuner
_______________________________________________
ivtv-users mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-users
