Jerky audio and video on GA-PCV2 motherboard (CLE-266 video)
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mythbuntu |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
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,
(==) VIA(0): Write-combining range (0xd8000000,
(--) 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,
(--) 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: ps2EnableDataRe
- SetGrabKeysState - disabled
- viaWaitVideoCom
- (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/
--- 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_GetVideoMe
if (bMemSize) {
}
else {
if (bMemSize > 16 && bMemSize <= 128) {
}
else if (bMemSize > 0 && bMemSize < 31){
}
else {
}
}
}
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-
else if (bMemSize > 0 && bMemSize < 31)
pScrn-
else {
xf86DrvMsg
16MB\n");
pScrn-
}
}
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.
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;
Scratch- >VideoRam = tmp << 12;
xf86DrvMsg( pScrn-> scrnIndex, X_WARNING, "%s: VideoRam Scratch area"
" uninitialised.\n", __func__);
Scratch- >VideoRam = 16 << 10;
else if ((tmp > 0) && (tmp < 31))
else {
}
That looks like it still reads the scratch registers, not the RAM controller.