On Tue, 2008-09-09 at 15:04 +0100, John Allman wrote: > Hi all, > > I just installed a fresh copy of knoppmyth R5.5 on my pvr. It had > previously been running an older version and was working fine, but > then my hard drive died. I've gotten tv out to work after making a few > changes (I'm using PAL, not NTSC) but I can't get proper playback > without using the hardware mpeg 2 decoder. I would rather not use that > as I get better audio quality using the output directly. Even if I do > use that for content I recorded, I can't playback anything else (like > mpeg4 movies) > without a traceback from the kernel in syslog and extremely slow > video. > > I can confirm that this is *playback* related, and not recording > related as I can use mythfrontend on my laptop to connect to the > server and play back recorded content just fine. > > I have ivtv xorg driver 1.0.0~svn4049-3 installed > > My kernel version is 2.6.23-chw-4 > > from dmesg output (see below) I believe the ivtv kernel module version is > 1.2.0 > > Here's an example traceback I see in syslog when I try to play back anything.
> Aug 27 19:23:14 mythtv kernel: PREEMPT SMP > Aug 27 19:23:14 mythtv kernel: Modules linked in: autofs4 ipv6 efs via > drm af_packet fuse usbhid ff_memless pcmcia yenta_socket > rsrc_nonstatic pcmcia_core video output sbs fan dock container battery > ac aufs sbp2 usb_storage ohci_hcd nvram cx8800 cx88xx bttv ir_common > compat_ioctl32 videobuf_dma_sg videobuf_core btcx_risc lirc_i2c > lirc_dev ivtvfb snd_via82xx gameport snd_ac97_codec ac97_bus > snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc snd_mpu401_uart > snd_seq_dummy snd_seq_oss saa7127 snd_seq_midi snd_seq_midi_event ivtv > parport_pc parport snd_seq saa7115 snd_timer snd_rawmidi msp3400 > i2c_viapro snd_seq_device tuner tea5767 tda8290 tda18271 tda827x > 8250_pnp button tuner_xc2028 thermal 8250 serial_core tda9887 > tuner_simple mt20xx tea5761 processor firmware_class i2c_algo_bit > cx2341x tveeprom videodev v4l2_common ohci1394 ehci_hcd via_ircc > uhci_hcd i2c_core pcspkr via_agp agpgart v4l1_compat ieee1394 snd irda > shpchp pci_hotplug usbcore soundcore rtc_cmos rtc_core rtc_lib evdev > tsdev > Aug 27 19:23:14 mythtv kernel: CPU: 0 > Aug 27 19:23:14 mythtv kernel: EIP: 0060:[<fa0fa86a>] Not tainted VLI > Aug 27 19:23:14 mythtv kernel: EFLAGS: 00010286 (2.6.23-chw-4 #1) > Aug 27 19:23:14 mythtv kernel: EIP is at via_driver_vblank_wait+0x2a/0x150 > [via] > Aug 27 19:23:14 mythtv kernel: eax: 00000000 ebx: f4d40000 ecx: > fa0fa840 edx: e7f8bf08 > Aug 27 19:23:14 mythtv kernel: esi: f4d10c00 edi: 00000000 ebp: > e7f8bf08 esp: e7f8beb0 > Aug 27 19:23:14 mythtv kernel: ds: 007b es: 007b fs: 00d8 gs: > 0033 ss: 0068 > Aug 27 19:23:14 mythtv kernel: Process mythfrontend (pid: 3713, > ti=e7f8a000 task=ec1c21b0 task.ti=e7f8a000) > Aug 27 19:23:14 mythtv kernel: Stack: f6092c10 efaf3180 fa0f0c40 > fa0eb143 000000ff c0186a70 00000001 00000000 > Aug 27 19:23:14 mythtv kernel: f4cfe520 00000000 00000000 > f4d10c00 fa0f7490 fa0ec098 f6092c10 00000000 > Aug 27 19:23:14 mythtv kernel: c0186d60 c018273d c18a5da0 > f670363c 00000000 00000000 00000001 b7f071b8 > Aug 27 19:23:14 mythtv kernel: Call Trace: > Aug 27 19:23:14 mythtv kernel: [<fa0eb143>] drm_stub_open+0x173/0x1a0 [drm] > Aug 27 19:23:14 mythtv kernel: [<c0186a70>] exact_match+0x0/0x10 > Aug 27 19:23:14 mythtv kernel: [<fa0ec098>] drm_wait_vblank+0x278/0x2b0 [drm] > Aug 27 19:23:14 mythtv kernel: [<c0186d60>] chrdev_open+0x0/0x1b0 > Aug 27 19:23:14 mythtv kernel: [<c018273d>] __dentry_open+0x16d/0x1f0 > Aug 27 19:23:14 mythtv kernel: [<fa0ebe20>] drm_wait_vblank+0x0/0x2b0 [drm] > Aug 27 19:23:14 mythtv kernel: [<fa0ea5f0>] drm_ioctl+0xb0/0x200 [drm] Some process is trying to call a drm_ioctl() > Aug 27 19:23:14 mythtv kernel: [<c010643a>] do_invalid_op+0x1a/0x90 > Aug 27 19:23:14 mythtv kernel: [<c010643a>] do_invalid_op+0x1a/0x90 Backtraces that include "do_invalid_op()" aren't comforting: it may indicate invalid opcode handling had to take place. :P > Aug 27 19:23:14 mythtv kernel: [<c01918d8>] do_ioctl+0x78/0x90 > Aug 27 19:23:14 mythtv kernel: [<c0191b1e>] vfs_ioctl+0x22e/0x2b0 > Aug 27 19:23:14 mythtv kernel: [<c018299e>] do_sys_open+0xbe/0xe0 > Aug 27 19:23:14 mythtv kernel: [<c0191bfd>] sys_ioctl+0x5d/0x70 > Aug 27 19:23:14 mythtv kernel: [<c0104412>] syscall_call+0x7/0xb > Aug 27 19:23:14 mythtv kernel: [<c010643a>] do_invalid_op+0x1a/0x90 > Aug 27 19:23:14 mythtv kernel: ======================= > Aug 27 19:23:14 mythtv kernel: Code: 00 55 89 d5 57 56 89 c6 53 83 ec > 24 8b 3d 84 87 0f fa 8b 98 84 02 00 00 85 ff 0f 85 e1 00 00 00 85 db > 0f 84 f9 00 00 00 8b 43 0c <8b> 50 10 8b 82 00 02 00 00 0b 83 cc fc 00 > 00 89 82 00 02 00 00 This disassembles to: 0: 55 push %ebp 1: 89 d5 mov %edx,%ebp 3: 57 push %edi 4: 56 push %esi 5: 89 c6 mov %eax,%esi 7: 53 push %ebx 8: 83 ec 24 sub $0x24,%esp b: 8b 3d 84 87 0f fa mov 0xfa0f8784,%edi 11: 8b 98 84 02 00 00 mov 0x284(%eax),%ebx 17: 85 ff test %edi,%edi 19: 0f 85 e1 00 00 00 jne 0x100 1f: 85 db test %ebx,%ebx 21: 0f 84 f9 00 00 00 je 0x120 27: 8b 43 0c mov 0xc(%ebx),%eax 2a: 8b 50 10 mov 0x10(%eax),%edx <------ Problem 2d: 8b 82 00 02 00 00 mov 0x200(%edx),%eax 33: 0b 83 cc fc 00 00 or 0xfccc(%ebx),%eax 39: 89 82 00 02 00 00 mov %eax,0x200(%edx) %eax is 0 so this is a NULL pointer dereference in linux/drivers/char/drm/via_irq.c:via_driver_vblank_wait() My kernel's compiled version of this function looks way different (our source probably differs too), so it's hard to see where exactly the failure is happening. This chipset specific vblank_wait() function is called when something that calls the the Direct Rendering Management in the kernel wants to tell the DRM to notify them when a vertical blank on the hardware occurs. > Aug 27 19:23:14 mythtv kernel: EIP: [<fa0fa86a>] > via_driver_vblank_wait+0x2a/0x150 [via] SS:ESP 0068:e7f8beb0 > > In dmesg I see: > > EIP: 0060:[<fa0fa86a>] Not tainted VLI > EFLAGS: 00010286 (2.6.23-chw-4 #1) > EIP is at via_driver_vblank_wait+0x2a/0x150 [via] > eax: 00000000 ebx: f4d40000 ecx: fa0fa840 edx: e7f8bf08 > esi: f4d10c00 edi: 00000000 ebp: e7f8bf08 esp: e7f8beb0 > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > Process mythfrontend (pid: 3713, ti=e7f8a000 task=ec1c21b0 task.ti=e7f8a000) The kernel was performing the drm_ioctl() and hence the via_driver_vblank_wait() call on behalf of the mythfrontend process. Mythfrontend may have been calling some sort of X library. But since the process making the drm_ioctl() call is not X, any supposed library did not send a message to the X server to ask it to do it. It's mythfrontend or one of the many, many libraries it calls trying to use DRM. You try to disable loading DRM via the Xorg.conf file and maybe blacklist and unload the drm modules to see if you can get things working. Regards, Andy > Stack: f6092c10 efaf3180 fa0f0c40 fa0eb143 000000ff c0186a70 00000001 00000000 > f4cfe520 00000000 00000000 f4d10c00 fa0f7490 fa0ec098 f6092c10 00000000 > c0186d60 c018273d c18a5da0 f670363c 00000000 00000000 00000001 b7f071b8 > Call Trace: > [<fa0eb143>] drm_stub_open+0x173/0x1a0 [drm] > [<c0186a70>] exact_match+0x0/0x10 > [<fa0ec098>] drm_wait_vblank+0x278/0x2b0 [drm] > [<c0186d60>] chrdev_open+0x0/0x1b0 > [<c018273d>] __dentry_open+0x16d/0x1f0 > [<fa0ebe20>] drm_wait_vblank+0x0/0x2b0 [drm] > [<fa0ea5f0>] drm_ioctl+0xb0/0x200 [drm] > [<c010643a>] do_invalid_op+0x1a/0x90 > [<c010643a>] do_invalid_op+0x1a/0x90 > [<c01918d8>] do_ioctl+0x78/0x90 > [<c0191b1e>] vfs_ioctl+0x22e/0x2b0 > [<c018299e>] do_sys_open+0xbe/0xe0 > [<c0191bfd>] sys_ioctl+0x5d/0x70 > [<c0104412>] syscall_call+0x7/0xb > [<c010643a>] do_invalid_op+0x1a/0x90 > ======================= > Code: 00 55 89 d5 57 56 89 c6 53 83 ec 24 8b 3d 84 87 0f fa 8b 98 84 > 02 00 00 85 ff 0f 85 e1 00 00 00 85 db 0f 84 f9 00 00 00 8b 43 0c <8b> > 50 10 8b 82 00 02 00 00 0b 83 cc fc 00 00 89 82 00 02 00 00 > EIP: [<fa0fa86a>] via_driver_vblank_wait+0x2a/0x150 [via] SS:ESP 0068:e7f8beb0 > mythfrontend[3420]: segfault at 106858a0 eip 0831771c esp b241822c error 6 > > > lspci output: > > 00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266] > 00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP] > 00:0d.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host > Controller (rev 80) > 00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 80) > 00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 80) > 00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 > Controller (rev 80) > 00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82) > 00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge > 00:11.1 IDE interface: VIA Technologies, Inc. > VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) > 00:11.5 Multimedia audio controller: VIA Technologies, Inc. > VT8233/A/8235/8237 AC97 Audio Controller (rev 50) > 00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74) > 00:13.0 Multimedia video controller: Internext Compression Inc iTVC15 > MPEG-2 Encoder (rev 01) > 01:00.0 VGA compatible controller: VIA Technologies, Inc. VT8623 > [Apollo CLE266] integrated CastleRock graphics (rev 03) > > Relevant sections of xorg.conf: > > > Section "Module" > # Comments: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=346408 > Load "dbe" # Double Buffering Extension, very important. > Load "dri" # This shouldn't be available choice if user has > selected driver vga, vesa or nv. > Load "glx" # GLX Extension. > Load "freetype" # Freetype fonts. > Load "type1" # Type 1 fonts > Load "record" # Developer extension, usually not needed > # Load "extmod" # This is okay, but if you look into "man xorg.conf" > you'll find option NOT to include DGA extension with extmod, and for a > good reason.. DGA causes instability as it access videoram without > consulting X about it. > SubSection "extmod" > Option "omit xfree86-dga" > EndSubSection > # Load "speedo" # Speedo fonts, this module doesn't exist in Xorg > 7.0.17 > # The following are deprecated/unstable/unneeded in Xorg 7.0 > # Load "ddc" # ddc probing of monitor, this should be never > present, as it gets automatically loaded. > # Load "GLcore" # This should be never present, as it gets > automatically loaded. > # Load "bitmap" # Should be never present, as it gets > automatically loaded. This is a font module, and loading it in > xorg.conf makes X try to load it twice. > EndSection > > > > Section "ServerFlags" > Option "AllowMouseOpenFail" "true" > Option "IgnoreABI" "true" > EndSection > Section "Monitor" > Identifier "PAL Monitor" > HorizSync 30-68 > VertRefresh 50-120 > Mode "720x576" > DotClock 42.6 > HTimings 720 760 832 944 > VTimings 576 577 580 602 > Flags "-HSync" "-VSync" > EndMode > EndSection > > Section "Device" > Identifier "Hauppauge PVR 350 iTVC15 Framebuffer" > Driver "ivtv" > > ### change fb1 to whatever number you got in the previous section > Option "fbdev" "/dev/fb0" > Option "VideoOverlay" "on" > Option "XVideo" "1" > > ### change the busid to whatever is reported by lspci. Note that > ### output of lspci is hex, so add a preceding "0x" to the BusID > BusID "PCI:0:19:0" > > # Screen 0 > EndSection > > Section "Screen" > Identifier "TV Screen" > Device "Hauppauge PVR 350 iTVC15 Framebuffer" > Monitor "PAL Monitor" > DefaultDepth 24 > DefaultFbbpp 32 > Subsection "Display" > Depth 24 > FbBpp 32 > Modes "720x576" > EndSubsection > EndSection > > Section "DRI" > Mode 0666 > EndSection > > > In dmesg, I see the following relating to the ivtv module: > > ivtv: Start initialization, version 1.2.0 > ivtv0: Initializing card #0 > ivtv0: Autodetected Hauppauge card (cx23415 based) > ivtv0: Unreasonably low latency timer, setting to 64 (was 32) > ivtv0: YUV filter table not found in firmware. > tveeprom 1-0050: has radio, has IR receiver, has no IR transmitter > ivtv0: Autodetected Hauppauge WinTV PVR-350 > saa7115 1-0021: saa7115 found (1f7115d0e100000) @ 0x42 (ivtv i2c driver #0) > saa7127 1-0044: saa7129 found @ 0x88 (ivtv i2c driver #0) > msp3400 1-0040: MSP4418G-B3 found @ 0x80 (ivtv i2c driver #0) > tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #0) > tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #0) > ivtv0: Registered device video0 for encoder MPG (4096 kB) > ivtv0: Registered device video32 for encoder YUV (2048 kB) > ivtv0: Registered device vbi0 for encoder VBI (1024 kB) > ivtv0: Registered device video24 for encoder PCM (320 kB) > ivtv0: Registered device radio0 for encoder radio > ivtv0: Registered device video16 for decoder MPG (1024 kB) > ivtv0: Registered device vbi8 for decoder VBI (64 kB) > ivtv0: Registered device vbi16 for decoder VOUT > ivtv0: Registered device video48 for decoder YUV (1024 kB) > ivtv0: Initialized card #0: Hauppauge WinTV PVR-350 > ivtv: End initialization > ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes) > ivtv0: Loaded v4l-cx2341x-dec.fw firmware (262144 bytes) > ivtv0: Encoder revision: 0x02060039 > ivtv0: Decoder revision: 0x02020023 > ivtv0: Loaded v4l-cx2341x-init.mpg firmware (155648 bytes) > ivtvfb0: Framebuffer at 0xdd510000, mapped to 0xf9c90000, size 1665k > ivtvfb0: Framebuffer registered on ivtv card id 0 > > The motherboard is a via epia m1000. It has its own video out, but I'm > using the pvr 350s tv out. > > I really am quite stumped here. I know the hardware is fast enough to > do this as it used to work fine - this must be a software problem (or, > more likely, a configuration problem) but I'm not getting it. > > I've included all the information I could thing you might possibly > find useful (sorry for the long post as a result) but if there's > anything else you need, please don't hesitate to let me know. > > Thanks, > > John > > _______________________________________________ > ivtv-users mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-users > _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
