similar to: PROM vbios fetching issues

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

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

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

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

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

Reported-by: Dan Carpenter <dan.carpenter at oracle.com> Signed-off-by: Martin Peres <martin.peres at free.fr> --- nvkm/subdev/bios/base.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/nvkm/subdev/bios/base.c b/nvkm/subdev/bios/base.c index 3de7d81..5f8643d 100644 --- a/nvkm/subdev/bios/base.c +++ b/nvkm/subdev/bios/base.c @@ -183,10 +183,11 @@

https://bugs.freedesktop.org/show_bug.cgi?id=77494 Priority: medium Bug ID: 77494 Assignee: nouveau at lists.freedesktop.org Summary: [NVE7] fails to load due to unknown opcode 0xc4 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mpredosin at

On Tue, May 27, 2014 at 7:15 PM, Martin Peres <martin.peres at free.fr> wrote: > Le 03/04/2014 22:12, Martin Peres a ?crit : > >> Reported-by: Dan Carpenter <dan.carpenter at oracle.com> >> Signed-off-by: Martin Peres <martin.peres at free.fr> >> --- >> nvkm/subdev/bios/base.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-)

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 (still has the x86 opcodes), which makes this a low-risk way to try to obtain a valid vbios image. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76475 Signed-off-by: Ilia Mirkin

https://bugs.freedesktop.org/show_bug.cgi?id=77529 Priority: medium Bug ID: 77529 Assignee: nouveau at lists.freedesktop.org Summary: NVS 510 DP-3 output doesn't work QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: All Reporter: tex at sergio.spb.ru

From: Andrea Tacconi <tacconet at libero.it> Subject: [PATCH] drm/nouveau: fix vbios load and check functions on PowerPC On PowerPC the Bios signature reports a wrong lenght of video rom. Fix this by reading the correct size from Open Firmware. Set Pramin as primary vbios searching method, because it's the only working method on PowerPC. The nv_cksum function always fails. Fix this

Hi, same for me. The screen does not freeze anymore and the boot succeeds. But now I have this kernel message during boot (for the second card): [ 24.382045] pci_pm_runtime_suspend(): nouveau_pmops_runtime_suspend+0x0/0xe0 [nouveau] returns -22 Do you want to have the complete dmesg log? I think this is a new bug. Your patch works for the previous one, so you can close it. Yours, Claas On

After 5addcf0a (nouveau: add runtime PM support (v0.9)) I'm getting kernel panics immediately after resuming from suspend. Unfortunately it happens so early that I don't get any more info than the blinking keyboard lights... The nouveau tree still panics up to 2fb9d6c, which fails before I can test it. Any ideas? Martin $ lspci 00:00.0 Host bridge: Intel Corporation 3rd Gen Core

https://bugs.freedesktop.org/show_bug.cgi?id=76475 Priority: medium Bug ID: 76475 Assignee: nouveau at lists.freedesktop.org Summary: Nouveau fails to load due to unknown opcode 0x80 QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All) Reporter: patrick.clara at

https://bugs.freedesktop.org/show_bug.cgi?id=75511 Priority: medium Bug ID: 75511 Assignee: nouveau at lists.freedesktop.org Summary: Screen freezes during boot with an 3.13 kernel (Arch Linux) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS: Linux (All)

Hi guys and gals, I'm working on improving nouveau's support for MXM (Mobile PCI Express Module) chips and need some more data to check my implementation. To see if you can help, the first thing to do is jump over to /sys/firmware/acpi/tables and run "grep MXMS *". [root at nisroch tables]# grep MXMS * Binary file DSDT matches [root at nisroch tables]# If this isn't

Le 03/04/2014 22:12, Martin Peres a ?crit : > Reported-by: Dan Carpenter <dan.carpenter at oracle.com> > Signed-off-by: Martin Peres <martin.peres at free.fr> > --- > nvkm/subdev/bios/base.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/nvkm/subdev/bios/base.c b/nvkm/subdev/bios/base.c > index 3de7d81..5f8643d 100644 >

https://bugs.freedesktop.org/show_bug.cgi?id=70354 Priority: medium Bug ID: 70354 Assignee: nouveau at lists.freedesktop.org Summary: Failed to initialise context object: 2D_NVC0 (0) (for my GeForce GT 750M) QA Contact: xorg-team at lists.x.org Severity: normal Classification: Unclassified OS:

Hello everyone! I'm trying to get tinc running, but couldn't make it until now... My current situation is: all tincs are connected, but there ist (almost) no traffic: Only two PCs are able to ping to another, but not to itself. Let me explain, what I'm planning to do: I've got four networks: PROM: 10.69.0.0/16 PAN: 192.168.30.0/24 (I'm afraid, I can't change PAN to

From: Martin Peres <martin.peres at labri.fr> This should fix a deadlock that has been reported to us where fan_update() would hold the fan lock and try to grab the alarm_program_lock to reschedule an update. On an other CPU, the alarm_program_lock would have been taken before calling fan_update(), leading to a deadlock. We should Cc: <stable at vger.kernel.org> # 3.9+ Reported-by: