Jerky audio and video on GA-PCV2 motherboard (CLE-266 video)

[Arthur Hartwig]

I installed MythTV on a system with a GA-PCV2 motherboard. The motherboard has an integrated VIA CLE-266 video controller. The watchTV function worked well initially but after rebooting the audio and video were both very jerky with long pauses. The mythfrontend.log had frequent reports of:

NVP: Timed out waiting for free video buffers
NVP: Timed out waiting for free video buffers
NVP: prebuffering pause
WriteAudio: buffer underrun

In the BIOS I increased the shared video memory from 32MB to 64MB but watchtv performance didn't seem any better. I looked in the dmesg output and saw:

[ 27.000000] vt8623fb 0000:01:00.0: memory size detection failed (20 40), suppose 16 MB
[ 27.000000] fb0: VIA VT8623 on 0000:01:00.0, 16 MB RAM

which struck me as strange - why did the memory size detection fail and what was the impact of the assumption of only 16MB?

The Xorg.log file showed:

(--) VIA(0): mapping framebuffer @ 0xd8000000 with size 0x2080000
(II) VIA(0): Splitting WC range: base: 0xd8000000, size: 0x2080000
(==) VIA(0): Write-combining range (0xda000000,0x80000)
(==) VIA(0): Write-combining range (0xd8000000,0x2080000)
(--) VIA(0): Frame buffer start: 0xb5ae3000, free start: 0x59b8c0 end: 0x2080000
(--) VIA(0): mapping MMIO @ 0xdc000000 with size 0x9000
(--) VIA(0): mapping BitBlt MMIO @ 0xdc200000 with size 0x10000
(II) VIA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000

The Xorg via driver thinks the frame buffer size is 32.5MB, an unexpected number. The Xorg via driver can't figure out the correct size either.

I decided to try telling xorg there was only 16MB video ram to see what would happen if both the xorg via driver and the fb driver were working with the same sizes so I edited the xorg.conf file device section to add the line

 VideoRam 16384

On reboot the watchTV function worked much better with smooth and apparently continuous video and audio.

The xorg.0.log file reported:

(--) VIA(0): mapping framebuffer @ 0xd8000000 with size 0x1000000
(==) VIA(0): Write-combining range (0xd8000000,0x1000000)
(--) VIA(0): Frame buffer start: 0xb6ac0000, free start: 0x59b8c0 end: 0x1000000
(--) VIA(0): mapping MMIO @ 0xdc000000 with size 0x9000
(--) VIA(0): mapping BitBlt MMIO @ 0xdc200000 with size 0x10000
(II) VIA(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000

The frame buffer size was the expected 16MB.

Some other differences between the Xorg.0.log.old (default videoRam size) file and Xorg.0.log (specified 16MB VideoRam) were: (I don't know how significant these are).

*** 525,532 ****
        Offscreen Pixmaps
        Setting up tile and stipple cache:
                32 128x128 slots
! 19 256x256 slots
! 5 512x512 slots
                32 8x8 color pattern slots
  (==) VIA(0): Backing store disabled
  (**) Option "dpms"
--- 523,529 ----
        Offscreen Pixmaps
        Setting up tile and stipple cache:
                32 128x128 slots
! 9 256x256 slots
                32 8x8 color pattern slots
  (==) VIA(0): Backing store disabled
  (**) Option "dpms"
***************
*** 544,550 ****
  (WW) VIA(0): [drm] The DRM Heap and Pixmap cache memory could be too small
  (WW) VIA(0): [drm] for optimal performance. Please increase the frame buffer
  (WW) VIA(0): [drm] memory area in BIOS.
! (II) VIA(0): [drm] Using 13960448 bytes for DRM memory heap.
  (II) VIA(0): [dri] frame buffer initialized.
  (II) VIA(0): X context handle = 0x1
  (II) VIA(0): [drm] installed DRM signal handler
--- 541,547 ----
  (WW) VIA(0): [drm] The DRM Heap and Pixmap cache memory could be too small
  (WW) VIA(0): [drm] for optimal performance. Please increase the frame buffer
  (WW) VIA(0): [drm] memory area in BIOS.
! (II) VIA(0): [drm] Using 5305344 bytes for DRM memory heap.
  (II) VIA(0): [dri] frame buffer initialized.
  (II) VIA(0): X context handle = 0x1
  (II) VIA(0): [drm] installed DRM signal handler
***************
*** 554,565 ****
  (II) VIA(0): direct rendering enabled
  (II) VIA(0): [Xv] Using PCI DMA for Xv image transfer.
  (II) VIA(0): Benchmarking video copy. Less is better.
! (--) VIA(0): Timed libc YUV420 copy... 4266892. Throughput: 139.4 MiB/s.
! (--) VIA(0): Timed kernel YUV420 copy... 4289050. Throughput: 138.6 MiB/s.
! (--) VIA(0): Timed SSE YUV420 copy... 2787518. Throughput: 213.3 MiB/s.
! (--) VIA(0): Timed MMX YUV420 copy... 4241355. Throughput: 140.2 MiB/s.
  (--) VIA(0): Ditch 3DNow! YUV420 copy... Not supported by CPU.
! (--) VIA(0): Timed MMX2 YUV420 copy... 2507891. Throughput: 237.1 MiB/s.
  (--) VIA(0): Using MMX2 YUV42X copy for video.
  (II) VIA(0): [XvMC] Registering viaXvMC.
  (II) VIA(0): [XvMC] Initialized XvMC extension.
--- 551,562 ----
  (II) VIA(0): direct rendering enabled
  (II) VIA(0): [Xv] Using PCI DMA for Xv image transfer.
  (II) VIA(0): Benchmarking video copy. Less is better.
! (--) VIA(0): Timed libc YUV420 copy... 4564197. Throughput: 130.3 MiB/s.
! (--) VIA(0): Timed kernel YUV420 copy... 4542740. Throughput: 130.9 MiB/s.
! (--) VIA(0): Timed SSE YUV420 copy... 2654457. Throughput: 224.0 MiB/s.
! (--) VIA(0): Timed MMX YUV420 copy... 3983200. Throughput: 149.3 MiB/s.
  (--) VIA(0): Ditch 3DNow! YUV420 copy... Not supported by CPU.
! (--) VIA(0): Timed MMX2 YUV420 copy... 2614880. Throughput: 227.4 MiB/s.
  (--) VIA(0): Using MMX2 YUV42X copy for video.
  (II) VIA(0): [XvMC] Registering viaXvMC.
  (II) VIA(0): [XvMC] Initialized XvMC extension.
***************
*** 624,634 ****
  (II) XINPUT: Adding extended input device "Configured Mouse" (type: MOUSE)
  (II) XINPUT: Adding extended input device "Generic Keyboard" (type: KEYBOARD)
  (II) Configured Mouse: ps2EnableDataReporting: succeeded
- SetGrabKeysState - disabled
- viaWaitVideoCommandFire: Timeout.
- (II) VIA(0): [drm] Freeing agp memory
- (II) VIA(0): [drm] Releasing agp module
- (II) VIA(0): [drm] removed 1 reserved context for kernel
- (II) VIA(0): [drm] unmapping 8192 bytes of SAREA 0xe2dde000 at 0xb7fc7000
- (II) VIA(0): [drm] Irq handler uninstalled.
- FreeFontPath: FPE "/usr/share/fonts/X11/misc" refcount is 2, should be 1; fixing.
--- 621,623 ----

A bit of hunting around the internet found a couple of emails that seem relevant: the first gives some background to the second:

From <email address hidden> Wed Nov 24 11:24:01 2004
From: <email address hidden> (Dave Ashley)
Date: Wed Nov 24 11:24:01 2004
Subject: linuxbios vs award bios on EPIA-M
Message-ID: <email address hidden>

The VIA XFree86 module for CLE266 used on the epia-m makes some
assumptions about certain of the VGA registers containing information
that would have been set by the bios. Specifically here is a code
snippet from XFree86 4.3.0:

    /* Next go on to detect amount of installed ram */
    if (pScrn->videoRam < 16384 || pScrn->videoRam > 65536) {
        bMemSize = BIOS_GetVideoMemSize(pScrn);
        if (bMemSize) {
            pScrn->videoRam = bMemSize << 6;
        }
        else {
            VGAOUT8(0x3C4, 0x39);
            bMemSize = VGAIN8(0x3c5);
            if (bMemSize > 16 && bMemSize <= 128) {
                pScrn->videoRam = (bMemSize + 1) << 9;
            }
            else if (bMemSize > 0 && bMemSize < 31){
                pScrn->videoRam = bMemSize << 12;
            }
            else {
                DEBUG(xf86DrvMsg(pScrn->scrnIndex, X_ERROR,
                "bMemSize = %d\nGet Video Memory Size by default.\n", bMemSize));
                pScrn->videoRam = VIAGetMemSize();
            }
        }
    }

And here is from XFree86 4.4.0:

    /* detect amount of installed ram */
    if (pScrn->videoRam < 16384 || pScrn->videoRam > 65536) {
 if(pVia->Chipset == VIA_CLE266)
     bMemSize = hwp->readSeq(hwp, 0x34);
 else
     bMemSize = hwp->readSeq(hwp, 0x39);

 if (bMemSize > 16 && bMemSize <= 128)
     pScrn->videoRam = (bMemSize + 1) << 9;
 else if (bMemSize > 0 && bMemSize < 31)
     pScrn->videoRam = bMemSize << 12;
 else {
     xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "Memory size detection failed: using

16MB\n");
     pScrn->videoRam = 16 << 10; /* Assume the base 16Mb */
 }
    }

So the older version tries to query the BIOS first. The newer version
doesn't even bother with the bios and assumes the VGA Seq registers
0x39 or 0x34 contain the memory size.

3c5.34 is Scratch Pad Register 3
3c5.39 is BIOS reserved register 0

XF4.4.0 seems to abstract how the VGA sequence registers are accessed.
Even the logic seems strange, XF4.3.0 assumes seq 0x39 has the info,
but XF4.4.0 assumes seq 0x39 has the info.

linuxbios isn't initializing either as far as I know. To handle this
safely it would seem it must set the ram size in both seq registers.

This seems really weird, using vga seq scratch registers to convey information from the BIOS to XFree86. Is this common or something specific to VIA?

-Dave

From libv at skynet.be Tue Feb 6 15:51:53 2007
From: libv at skynet.be (Luc Verhaegen)
Date: Tue, 6 Feb 2007 15:51:53 +0100
Subject: [Openchrome-users] Memory size detection failed: using 16MB,
 system has 8MB
In-Reply-To: <email address hidden>
References: <email address hidden> <email address hidden>
 <email address hidden>
Message-ID: <email address hidden>

On Tue, Feb 06, 2007 at 02:51:04PM +0100, Mark Huijgen wrote:
>
> With the code in Luc's driver I managed to fix the openchrome driver for
> my chip regarding video memory detection.
> The problem is that on my system
> hwp->readSeq(hwp, 0x34);
> Failes to get the memory size, Luc's driver falls back in this case to
> call 0x39 used for other types of chips.
> This correctly detects the 8Mb video ram in my system.
>
> Attached is a patch that adds this fallback to via_driver.c against
> current svn, maybe usefull to include in the tree.
>
> regards,
> Mark

Oh, you're wrong, and you're right, at the same time.

Yes, somewhere around the time the VT7205 came out, some VIA BIOS
developers decided to change which scratch register was responsible for
the FB size. They probably accidentally changed one value in a table,
and then no-one knew why or how it had changed, as the usage of scratch
registers was notso straightforward before the K8M890.

This was one of the first issues i put right (to some extent) back when
xfree86 was alive.

The trouble is that on the common CLE266 based devices, the old scratch
is being used, and on some newer, less common semi-embedded things
(igel thin clients perhaps?) the new scratch register is being used.

So yes, a long while ago i introduced that change.

However, the only correct solution is to not depend on those weird
scratch registers at all.

See, I talk to the ram controller directly. No fuss, no failure. Rock
solid. This was something VIA introduced in their code a year or so
ago, but they originally messed up theirs as they hadn't bothered to
test it.

Nowadays, i get everything i need (FB size, ram type, direct access
address) from the ramcontroller directly.

The only reason those scratch registers are still used is to gloat:
"Ooh, look, another wonky BIOS."

Luc Verhaegen.

Summary: Both the kernel vt8623fb driver and the Xorg via driver should be changed to correctly determine the amount of video memory. Luc's patch (apparently to the openchrome driver) might provide a base for a suitable change.

[Bjorn Helgaas (bjorn-helgaas)]

I'd like to fix the kernel vt8623fb driver. It sounds like it'd be best to read the information directly from the RAM controller. Can you point me at any code that does that?

I found some code here: git://people.freedesktop.org/~libv/xf86-video-unichrome/, but it looks like this (from ViaScratchGet() in src/via_driver.c):

    /*
     * Get Memory size first. Should really use the RAM controller pci config.
     */
    if (pVia->Chipset == VT3122) {
        tmp = hwp->readSeq(hwp, 0x34);

        if (!tmp) {
            xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "%s: VideoRam Scratch area"
                       " uninitialised. Trying CR39.\n", __func__);
            tmp = hwp->readSeq(hwp, 0x39);
        }
    } else
        tmp = hwp->readSeq(hwp, 0x39);

    if ((tmp > 16) && (tmp <= 128))
        Scratch->VideoRam = (tmp + 1) << 9;
    else if ((tmp > 0) && (tmp < 31))
        Scratch->VideoRam = tmp << 12;
    else {
        xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "%s: VideoRam Scratch area"
                   " uninitialised.\n", __func__);
        Scratch->VideoRam = 16 << 10;
    }

That looks like it still reads the scratch registers, not the RAM controller.

[Arthur Hartwig (a-hartwig)]

G'day Bjorn,
    I've seen source for doing this sort of thing in the OpenChrome
driver. The source repository can be accessed through
http://www.openchrome.org/trac
and the particular file at
http://www.openchrome.org/trac/browser/trunk/src/via_driver.c
The size of the video ram is calculated inVIAPreInit() in the switch
statement at file line 1093

I have used lspci to look at the pci configuration registers and can
verify that the bits referenced in this code accurately reflect the
video ram settings of the BIOS.

    I understand Via has recently released some programming
documentation on some of the video chips. See
http://linux.via.com.tw/support/downloadFiles.action

Hope this is helpful,
Arthur

Bjorn Helgaas wrote:

>I'd like to fix the kernel vt8623fb driver. It sounds like it'd be best
>to read the information directly from the RAM controller. Can you point
>me at any code that does that?
>
>I found some code here: git://people.freedesktop.org/~libv/xf86-video-
>unichrome/, but it looks like this (from ViaScratchGet() in
>src/via_driver.c):
>
> /*
> * Get Memory size first. Should really use the RAM controller pci config.
> */
> if (pVia->Chipset == VT3122) {
> tmp = hwp->readSeq(hwp, 0x34);
>
> if (!tmp) {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "%s: VideoRam Scratch area"
> " uninitialised. Trying CR39.\n", __func__);
> tmp = hwp->readSeq(hwp, 0x39);
> }
> } else
> tmp = hwp->readSeq(hwp, 0x39);
>
> if ((tmp > 16) && (tmp <= 128))
> Scratch->VideoRam = (tmp + 1) << 9;
> else if ((tmp > 0) && (tmp < 31))
> Scratch->VideoRam = tmp << 12;
> else {
> xf86DrvMsg(pScrn->scrnIndex, X_WARNING, "%s: VideoRam Scratch area"
> " uninitialised.\n", __func__);
> Scratch->VideoRam = 16 << 10;
> }
>
>That looks like it still reads the scratch registers, not the RAM
>controller.
>
>
>

[laga (laga)]

Does this still happen with Mythbuntu 8.04 or later (8.10)? If it does, then the xserver-xorg people should take a look at this.

[lamestllama (eric-eparsonage)]

This is still a problem with this exact hardware on Mythbuntu 8.04 and all updates to 14/1/09. Does anybody know how to fix this properly with 32 or 64MB of video memory ?

[Arthur Hartwig (a-hartwig)]

I was never able to get Mythbuntu 8.04 working on my GA-PCV2 motherboard. I did get Mythbuntu 8.10 working.

Have you enabled VIA Xvmc, the MPEG acceleration hardware in the CLE-266? see http://ubuntuforums.org/showthread.php?t=973129

I have had this working with SD digital TV. If I recall correctly 32MB is enough video memory; even 16MB may be enough.

[MarcRandolph (mrand)]

Marking as fixed with 8.10. If this turns out not to be the case, please feel free to re-open this ticket.