Re: [Nouveau] Is binary firmware still necessary for GTX660 card (NVE0 family) in order to use DRM and/or VDPAU video acceleration?
Le 12/12/2013 08:58, Matthias Nagel a écrit : Hi Martin, if you refer to my kernel version. 3.10.17 is the latest, stable version in the official gentoo repository for the amd64 architeture. See here ... [4] https://packages.gentoo.org/package/sys-kernel/gentoo-sources?full_cat As long as I do not miss any features, I stay with the stable version. Indeed, you are doing the right thing, I guess. But if you encounter any sort of crash, I really advise you to go against gentoo on this and update your kernel to the latest official release (3.12.x at the moment). FYI, the 3.12 brings performance improvements to Nouveau too. Hence, if I understand you correctly, there are kernel version (newer than some unknown point in time) that already include the firmware? If this is the case, someone who knows the exact kernel version should mention that point on [1] http://nouveau.freedesktop.org/wiki/InstallDRM/ [2] http://nouveau.freedesktop.org/wiki/VideoAcceleration/ [3] https://bugs.gentoo.org/show_bug.cgi?id=480832 and update the information. What I wanted to say is that adding good fw support usually spans across multiple kernels. Even 3.13 has kepler fw fixes IIRC and 3.14 will receive some more updates to support new chipsets. It isn't a binary thing so this is hard to tell we support a feature... I guess we could tell when is the first free implementation (with the possible fallback of using the blob's firmware[1]) and then when we added support for all chipsets of the family and it has been fairly-extensively tested and bug-free. Some cards would never pass the test though :s [1] NvGrUseFw, http://nouveau.freedesktop.org/wiki/KernelModuleParameters/ Cheers, Martin http://nouveau.freedesktop.org/wiki/KernelModuleParameters/ ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Is binary firmware still necessary for GTX660 card (NVE0 family) in order to use DRM and/or VDPAU video acceleration?
On Thu, Dec 12, 2013 at 2:32 AM, Matthias Nagel matthias.h.na...@gmail.com wrote: Hello, I run the Gentoo Linux distribution and use a self-compiled Linux 3.10.17 kernel. According to [1] http://nouveau.freedesktop.org/wiki/InstallDRM/ [2] http://nouveau.freedesktop.org/wiki/VideoAcceleration/ I need the original firmware from the binary driver in order to sucessully use DRM and to use VDPAU video acceleration. I used the python script from [2] and I had a look at the ebuild from [3] https://bugs.gentoo.org/show_bug.cgi?id=480832 to extract the firmware and to place it at /lib/firmware/nouveau. But I do not see any dmesg output about loading the firmware. I do not see any dmesg output about nouveau failing to do so either. I neither do no see any nouveau pci id: firmware: requesting nouveau/ in my kernel output. Try booting with nouveau.debug=PVP=debug,PBSP=debug,=debug Note the new-found kernel output. Anyway VDPAU seems to work. If I call mplayer with -vo vdpau -vc ffmpeg12vdpau,..., I don't get any error message and my CPU load drops from 30% to 7% for a recent mpeg transport stream 1080p video. In conclusion, do I still need the firmware? Do the information given at [1], [2] still apply or are they outdated? You definitely need firmware to do vdpau (just try removing it and reboot, and see what happens) on all NV84+ cards. AFAIK there is no active work being done to replace the firmware on VP5 cards (nvd0+), although that is the one that is probably the most feasible since the actual video decoding is done with firmware that's on the card (or with dedicated hardware, who knows) so all that's left is providing the little os running on the connected falcon processors. Unless you're booting with nouveau.NvGrUseFW=1, you don't need the pgraph firmware. It generally tends to work for nve0 cards nowadays, although some people have issues with hangs (e.g. https://bugs.freedesktop.org/show_bug.cgi?id=70354, https://bugs.freedesktop.org/show_bug.cgi?id=72180). I believe there were a bunch of fixes to the fuc ucode in 3.11, which is probably why Martin suggested you use a more recent kernel. But if it's working fine for you, no need to worry about it. -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 --- Comment #15 from torsten.stocklo...@gmail.com --- HI, I wonder if this is still alive ?? Any news on this cheers T -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 torsten.stocklo...@gmail.com changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58378] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Severity|critical|normal Priority|high|medium --- Comment #16 from Ilia Mirkin imir...@alum.mit.edu --- Messing with priority just annoys the developers. In the meanwhile, try new kernels. I only see up to 3.8 tested. Do a bisect. There was a major driver rewrite in 3.7, but it might have been something else that causes the issue. Make sure you're running an updated DDX. As you might imagine, none of the devs are seeing this, so you'll have to do the debugging if you want it fixed. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 58378] [NV86] Distorted graphics on NVIDIA GeForce 8400M G after upgrade the kernel to 3.7.0 version
https://bugs.freedesktop.org/show_bug.cgi?id=58378 Ilia Mirkin imir...@alum.mit.edu changed: What|Removed |Added Summary|Distorted graphics on |[NV86] Distorted graphics |NVIDIA GeForce 8400M G |on NVIDIA GeForce 8400M G |after upgrade the kernel to |after upgrade the kernel to |3.7.0 version |3.7.0 version -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72651] New: [NV11] Hang during suspend/resume on Geforce 2 MX200 MX400
https://bugs.freedesktop.org/show_bug.cgi?id=72651
Priority: medium
Bug ID: 72651
Assignee: nouveau@lists.freedesktop.org
Summary: [NV11] Hang during suspend/resume on Geforce 2 MX200
MX400
QA Contact: xorg-t...@lists.x.org
Severity: normal
Classification: Unclassified
OS: Linux (All)
Reporter: welni...@students.mimuw.edu.pl
Hardware: x86 (IA32)
Status: NEW
Version: unspecified
Component: Driver/nouveau
Product: xorg
Created attachment 90680
-- https://bugs.freedesktop.org/attachment.cgi?id=90680action=edit
Serial console dump from MX200 card (boot + crash)
Hibernation and suspend/resume always hangs on a GeForce2 MX200/MX400 (NV11)
with nouveau loaded.
Steps to reproduce:
- boot a kernel, load nouveau
- echo disk /sys/power/state
- machine hangs after suspending devices but before the image writing begins
- after several seconds, the monitor complains about input signal out of
range
Same thing happens with echo freeze /sys/power/state.
If nouveau is unloaded before hibernation, everything works fine.
This happens on two different systems with a GeForce2 MX200/400:
1) Athlon XP 1700+ on an Asrock K7VT2,
GeForce2 MX400 64MB AGP, with VGA output
2) Pentium II 400 on a 440BX-based Gigabyte GA-BX2000+,
GeForce2 MX200 32MB AGP, with VGA and TV-out (S-Video + Cinch)
I'm using CentOS 6 userspace, and various kernels:
linux-2.6.32-358.18.1.el6
linux-3.0.x
linux-3.10.x
linux-3.12.1
linux-3.12.4
Using a serial console I was able to narrow down the hang to run_tmds_table(),
called from nv04_dfp_restore().
Dmesg output and VBIOS of both cards is attached.
Note that neither of my cards has DVI/HDMI.
It seems that the flat panel connector is wrongly fabricated in
nouveau_bios.c:fabricate_dcb_encoder_table().
Commenting out the call to fabricate_dcb_output(dcb, DCB_OUTPUT_TMDS, ...)
makes hibernation work fine (patch attached).
The current condition of checking bios-tmds.output{0,1}_script_ptr seems
wrong. But since I don't have any NV11 with DVI output, I'm not sure what to
key creating the TMDS output on.
--
You are receiving this mail because:
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72651] [NV11] Hang during suspend/resume on Geforce 2 MX200 MX400
https://bugs.freedesktop.org/show_bug.cgi?id=72651 --- Comment #1 from Michal Welnicki welni...@students.mimuw.edu.pl --- Created attachment 90681 -- https://bugs.freedesktop.org/attachment.cgi?id=90681action=edit Serial console dump from MX400 card (crash only) -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72651] [NV11] Hang during suspend/resume on Geforce 2 MX200 MX400
https://bugs.freedesktop.org/show_bug.cgi?id=72651 --- Comment #2 from Michal Welnicki welni...@students.mimuw.edu.pl --- Created attachment 90682 -- https://bugs.freedesktop.org/attachment.cgi?id=90682action=edit VBIOS from MX200 card -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72651] [NV11] Hang during suspend/resume on Geforce 2 MX200 MX400
https://bugs.freedesktop.org/show_bug.cgi?id=72651 --- Comment #3 from Michal Welnicki welni...@students.mimuw.edu.pl --- Created attachment 90683 -- https://bugs.freedesktop.org/attachment.cgi?id=90683action=edit VBIOS from MX400 card -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 72651] [NV11] Hang during suspend/resume on Geforce 2 MX200 MX400
https://bugs.freedesktop.org/show_bug.cgi?id=72651 --- Comment #4 from Michal Welnicki welni...@students.mimuw.edu.pl --- Created attachment 90684 -- https://bugs.freedesktop.org/attachment.cgi?id=90684action=edit Workaround: don't create the TMDS output -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [PATCH] drm/nouveau: only runtime suspend by default in optimus configuration
Hi On Thursday 12 December 2013, Ilia Mirkin wrote: The intent was to only enable it by default for optimus, e.g. see the runtime_idle callback. The suspend callback may be called directly, e.g. as a result of nouveau_crtc_set_config. Reported-by: Stefan Lippers-Hollmann s@gmx.de Signed-off-by: Ilia Mirkin imir...@alum.mit.edu Cc: sta...@vger.kernel.org --- See http://lists.freedesktop.org/archives/dri-devel/2013-November/049738.html for my analysis of the situation. Since this has been around since 3.12, I'm tagging it for stable. […] Thanks a lot, this works fine on the affected system[1] (with and without a monitor attached and without the nouveau.runpm=0 workaround); feel free to add Tested-by: Stefan Lippers-Hollmann s@gmx.de Regards Stefan Lippers-Hollmann [1] trivially rebased against 3.12.4 ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
