[256.25 7600GT agp] Unable to play xv video

[Stephen Warren]

It'd be useful to know exactly which X API is failing in MPlayer. Are you able to debug MPlayer and find out? The following link might help making X protocol synchronous, which will help to keep errors and their triggering functionality together in time: http://www.rahul.net/kenton/perrors....ynchronization (assuming that debug variable still exists in recent code...)

[Stephen Warren]

An alternative to debugging would be to (a) Enable TCP connections to your X server (b) Set your DISPLAY to 127.0.0.1:0 instead of :0 (c) set up Wireshark to capture on lo0 interface port 6000 (d) Run MPlayer again so that it fails (e) Give me the Wireshark capture results, which include all the X protocol.

[kriko]

That was easyier than first suggestion, thanks.
I've uploaded to rapidshare since it's too big to fit here:
http://rapidshare.com/files/39997643...mp.tar.gz.html

The result is the same, I can see BadAlloc in capture.

[Stephen Warren]

Sorry, I can't access rapidshare from work. Can you please upload the file to the NVIDIA file drop (see the VDPAU sticky post in this forum). Thanks.

[kriko]

Done, file nvidia256_xv.dump.tar.gz

[Stephen Warren]

Thanks. Can you please try another experiment; in your mplayer command-line, replace "-vo xv" with "-vo xv:port=N" where N is a number derived from your xvinfo output. You should run xvinfo and double-check the numbers in case they changed, but given the following output:

  Adaptor #0: "NV17 Video Texture"
    number of ports: 32
    port base: 355
...
  Adaptor #1: "NV05 Video Blitter"
    number of ports: 32
    port base: 387

I want you to try both "port base" numbers, i.e. 355 and 387. Thanks..

[kriko]

I've installed the latest 256.35 and retested.
Double checked if the ports are correct and the capture result of 1s clip playback is included
in file 256.35_port_test.dump.tar.gz.
Uploaded as before.

[Stephen Warren]

OK, can you please try one more experiment. We need to you:

a) Stop the existing X server completely
b) Run bare X under "strace" (see below)
c) Attempt to run an application using Xv, and have it fail

Then, the strace log might possibly tell us what's failing.

(you'll probably want to do most of this under SSH from a different machine if at all possible)

To stop X, perhaps "sudo init 3", "sudo /etc/init.d/gdm stop", "sudo stop gdm", or whatever your distro uses. (This will kill/terminate all your running applications).

To run a bare X server under strace, do "sudo strace -eopen,ioctl,close X > xv_strace.txt"

Then, run your Xv application and reproduce the problem.

Then, press CTRL-C in the session where X/strace are running.

Then, restart X, perhaps "sudo init 5", "sudo /etc/init.d/gdm start", "sudo start gdm", or whatever your distro uses.

Hopefully this will tell us something, although I'm not sure how much...

[kriko]

Done and attached.
Hope this helps.

[Stephen Warren]

kriko,

What kernel are you running? Does OpenSUSE have different "streams" of kernels (desktop, server, PAE, ...) Can you try a different kernel, even a standard kernel.org kernel without any patches from SUSE?

[kriko]

Found the problem.

I've blacklisted the amd64_agp drivers, since with option:
Option "NvAGP" "3"
or 1 (doesn't matter) nVagp driver was not being picked up until I did that.

Now with 256.x seems that the problem is in nVagp - when it's loaded XV fails.
If I disable AGP (forcing NvAGP option to 1 with blacklisted driver) then mplayer works, using AGPGART also works.
So my suspect is nVagp.

Btw, is there still any performance advantage when using nVagp instead of AGPGART with recent kernels?

Thanks.

[Stephen Warren]

Aha. Thanks for the NvAGP information. We now believe we've reproduced the problem in-house. There's a bug filed, so hopefully this will get resolved soon. Thanks!