|
|
#1 | |
|
Registered User
|
I think I have reported this before, but what about VDPAU + suspend 2 RAM or suspend 2 disk?
Right now there is a 50% chance that VDPAU will not work after resuming. MPlayer gives me the attached output. Excerpt: Code:
VIDEO: [avc1] 1280x720 24bpp 23.976 fps 0.0 kbps ( 0.0 kbyte/s)
VDPAU capture: Enabled
vdp_imp_device_create_x11(0x1871d00, 0, -, -)
VDPAU nvidia: Version: NVIDIA VDPAU Driver Shared Library 190.42 Tue Oct 20 21:20:26 PDT 2009
VDPAU nvidia: Error detected 0 5525
VDPAU nvidia: Backtrace:
-> 1
[vdpau] Error when calling vdp_device_create_x11: 1
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
open: No such file or directory
[MGA] Couldn't open: /dev/mga_vid
[VO_TDFXFB] Can't open /dev/fb0: No such file or directory.
s3fb: can't open /dev/fb0: No such file or directory
VDPAU trace: Multiple devices created; will return get_proc_address results from the latest only
vdp_imp_device_create_x11(0x1871d00, 0, -, -)
VDPAU nvidia: Version: NVIDIA VDPAU Driver Shared Library 190.42 Tue Oct 20 21:20:26 PDT 2009
VDPAU nvidia: Error detected 0 5525
VDPAU nvidia: Backtrace:
-> 1
|
|
|
|
|
|
|
#2 | |
|
Registered User
|
Please disregard the log file, this specific issue was caused by Debian overwriting my VDPAU files.
That being said the suspend/resume issue really exists. |
|
|
|
|
|
|
#3 |
|
Moderator
Join Date: Aug 2005
Posts: 1,327
|
LubosD,
Can you please supply an nvidia-bug-report file so that we can see details of your HW. Also, exactly what do you mean by suspend2ram/suspend2disk (historically, there have been a variety of ways that those features were implemented). Specifically, which Linux distro and version are you using, and how are you invoking suspend/hibernate (e.g. Gnome menu, running a specific command in a shell, etc.)? Finally, is any VDPAU application running when you suspend? Or, does the issue occur if you quit all VDPAU apps, suspend, resume, then try to start another VDPAU app? Thanks. |
|
|
|
|
|
#4 | |
|
Registered User
|
I use Debian Stable with uswsusp.
I suspend to RAM by doing 'echo mem >/sys/power/state' and to disk using 's2disk'. Both directly from the terminal. 1) A VDPAU app doesn't need to be running for this bug to be triggered. It is completely random. Restarting X doesn't help, you need to reload the driver. 2) Granted, suspending/resuming with a VDPAU app running makes the video disappear, giving me just a green rectangle. This is a separate issue. Restarting MPlayer fixes this problem provided that "1)" wasn't also triggered in the process. I can't seem to get "1)" happen right now, so I'm attaching an older log file I sent to nVidia several months ago. |
|
|
|
|
|
|
#5 |
|
FFmpeg developer
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
|
|
|
|
|
|
|
#6 | |
|
Moderator
Join Date: Aug 2005
Posts: 1,327
|
Carl, I suspect his MPlayer version is prior to your implementation of preemption recovery.
LubosD, what version of the driver is "log.txt.bz2" from? Your bug report indicates 195.22. However, the content of log.txt.bz2 does not match that; with 195.22, there should be lines beginning "VDPAU nvidia: Version ...". Also, the error numbers in your logs don't make sense for version 195.22. Are you sure that you have the driver installed correctly; in particular, is your libvdpau_nvidia.so.* from a different driver than the kernel driver? |
|
|
|
|
|
|
#7 |
|
FFmpeg developer
Join Date: Jan 2009
Location: Vienna, Austria
Posts: 467
|
|
|
|
|
![]() |
| Thread Tools | |
|
|