similar to: [3.19-rcX+] New VBIOS dmesg warnings

On 25/03/2014 23:24, Ilia Mirkin wrote: > On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres <martin.peres at free.fr> wrote: >> Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, > Maxwell or Kepler? Damn, I meant Kepler. I updated the patch in my git tree: http://cgit.freedesktop.org/~mperes/nouveau/commit/?id=661a5c599565686f72e729600b0dd6aa6e472f0c

On Tue, Mar 25, 2014 at 6:11 PM, Martin Peres <martin.peres at free.fr> wrote: > Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, Maxwell or Kepler? > let's only use 32-bit accesses to fetch the vbios from PROM. > > This fixes vbios fetching on my nve7 which failed in certain specific > conditions. > > I suggest we Cc stable, for all

Other kind of accesses are unreliable on Maxwell cards. As advised by NVIDIA, let's only use 32-bit accesses to fetch the vbios from PROM. This fixes vbios fetching on my nve7 which failed in certain specific conditions. I suggest we Cc stable, for all kernels they still maintain after the big rewrite. Suggested-by: Christian Zander <czander at nvidia.com> Signed-off-by: Martin Peres

Coefficients are based on the formula: uV = 0.1 * arg[0] + 150.5 * arg[1] + 22.65025 * arg[2] It seems to be rounded downwards. I have no idea why the voltage isn't specified in the bios directly. Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> ---- diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/vmap.c b/drivers/gpu/drm/nouveau/core/subdev/bios/vmap.c

On 25/03/2014 17:17, Christian Zander wrote: > On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: >> Hello, >> >> One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM >> at boot time but, if I blacklist the module and load it myself later on, >> it always succeeds. To make things weirder, the same card works great on >> another

On Sat, Apr 5, 2014 at 7:53 AM, Claas Lorenz <cllorenz at uni-potsdam.de> wrote: > Hi, same for me. The screen does not freeze anymore and the boot Great! And that's without the nouveau.config=NvBios= stuff that you added as a workaround, right? > succeeds. But now I have this kernel message during boot (for the second > card): > > [ 24.382045]

I have tested this patch. I can confirm that now nouveau loads correctly without errors. Thank you 2014-03-27 0:37 GMT+01:00 Ilia Mirkin <imirkin at alum.mit.edu>: > There appear to be a crop of new hardware where the vbios is not > available from PROM/PRAMIN, but there is a valid _ROM method in ACPI. > The data read from PCIROM almost invariably contains invalid > instructions

On 20 Nov 2014 01:31, "李金华" <goodqt at outlook.com> wrote: > > Hello everyone, > > The code is at /core/subdev/bios/init.c. > When the executable is 0,these functions that parse the VBIOS init table seems to do nothing except the parsing. Correct. We do not handle every opcode, only the ones that have been observed so far. The purpose is to be able to test whether

On Mon, Mar 24, 2014 at 11:59:46AM -0700, Martin Peres wrote: > > Hello, > > One of my GPU (GK107/NVE7) fails to properly fetch its vbios from PROM > at boot time but, if I blacklist the module and load it myself later on, > it always succeeds. To make things weirder, the same card works great on > another computer. > > Here is the relevant code in Nouveau to fetch

Intel has VBIOS updates available that end-users typically cannot use unless their vendor includes it in a system BIOS update. The only exception is being able to use a DOS TSR (terminate and stay resident) executable, which doesn?t work e.g. in NT-based Windows. However, I do not know if this also applies to Linux (and that may be a question to ask elsewhere). However, regarding MEMDISK, would it

Turns out some VBIOSes don't actually set the bit in question in 2240c. Use the nv50-style detection to try avoiding running the vbios twice. Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97620 Cc: stable at vger.kernel.org # v4.6+ Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>

Turns out some VBIOSes don't actually set the bit in question in 2240c. Use the nv50-style detection to try avoiding running the vbios twice. Fixes: a6a0f67ca7aa ("drm/nouveau/devinit/gf100-: detect if BIOS invoked devinit") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97620 Cc: <stable at vger.kernel.org> # v4.6+ Signed-off-by: Ilia Mirkin <imirkin at

On 29/09/16 03:41, Martin Peres wrote: > This seems to be absolutely necessary for a lot of NV40. > > Reported-by: gsgf on IRC/freenode > Signed-off-by: Martin Peres <martin.peres at free.fr> I of course forgot to tag this patch for stable. The thing has been broken on some nv40 ... forever? > --- > drm/nouveau/nvkm/subdev/therm/base.c | 22 +++++++++++++++++++--- >

Hi, Is there any method to prevent from flashing vbios(nvidia cards) in a virtual machine? Could someone give me some advices? Thanks, Zongyong Wu -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/nouveau/attachments/20170609/6c90e2dc/attachment.html>

Signed-off-by: Karol Herbst <karolherbst at gmail.com> --- drm/nouveau/nvkm/subdev/bios/vpstate.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drm/nouveau/nvkm/subdev/bios/vpstate.c b/drm/nouveau/nvkm/subdev/bios/vpstate.c index 20b6fc82..71524548 100644 --- a/drm/nouveau/nvkm/subdev/bios/vpstate.c +++ b/drm/nouveau/nvkm/subdev/bios/vpstate.c @@ -58,8

To whom it may concern I hope here is the right place to ask about envytools. I am working on securing our GPUs in the case of an OpenStack infrastructure, where GPUs can be bound and unbound to VMs from different clients. I wanted to use envytools to retrieve the VBIOS our cards, then check after each VM deletion if somebody changed the VBIOS (potentially a threat). The VBIOS would be read

https://bugs.freedesktop.org/show_bug.cgi?id=92386 Bug ID: 92386 Summary: Integrated sensor on nv43 doesn't work (wrong vbios parsing?) Product: xorg Version: git Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component:

On 17/11/17 02:04, Karol Herbst wrote: Please add here something like this: If the entry size is too small, default to invalid values for both boost_id and tdp_id, so as to default to the base clock in both cases. > Signed-off-by: Karol Herbst <karolherbst at gmail.com> With the better commit message, this patch is: Signed-off-by: Martin Peres <martin.peres at free.fr> > ---

Hello everyone, The code is at /core/subdev/bios/init.c. When the executable is 0,these functions that parse the VBIOS init table seems to do nothing except the parsing. And in my opinion,init_exec_force does nothing,too! Then I tried to test it on my computer,when the VBIOS parser tries to change a MMIO register or call a function of struct nouveau_devinit (such as devinit->pll_set,etc.),it

This is a small patch series that adds a strap_peek file into our debugfs, and sets the size of the vbios.rom debugfs file so that nvbios can easily be used to parse the vbios even on systems where the normal BIOS retrieval methods (for example, laptops that need ACPI to access the vbios for the nvidia GPU) won't work. This should make it a little easier to collect vbioses. Lyude Paul (2):