date:20171124

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103897

--- Comment #4 from Andrew Randrianasulu  ---
Created attachment 135706
  --> https://bugs.freedesktop.org/attachment.cgi?id=135706&action=edit
kernel's config.gz

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103897

--- Comment #3 from Andrew Randrianasulu  ---
Created attachment 135705
  --> https://bugs.freedesktop.org/attachment.cgi?id=135705&action=edit
opreport

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103897

--- Comment #2 from Andrew Randrianasulu  ---
Created attachment 135704
  --> https://bugs.freedesktop.org/attachment.cgi?id=135704&action=edit
dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103897

--- Comment #1 from Andrew Randrianasulu  ---
Created attachment 135703
  --> https://bugs.freedesktop.org/attachment.cgi?id=135703&action=edit
X log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103897] New: Kernel 4.14 causes high cpu usage, 4.12 was OK

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103897

Bug ID: 103897
   Summary: Kernel 4.14 causes high cpu usage, 4.12 was OK
   Product: xorg
   Version: git
  Hardware: x86 (IA32)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: rand...@mail.ru
QA Contact: xorg-t...@lists.x.org

Hello. After upgrading my kernel to 4.14 I noticed strange behavior: If I load
X (KDE 3.5.10 session with built-in compositor [kompmgr], self-compiled with
many patches, X server 1.19.5, nouveau DDX git) and start to use seamonkey 2.49
(again, self-compiled with gtk2 toolkit, not default gtk3) - after some hours
of use X started to eat a lot of CPU time, new windows appear after delay,
glxgears slow down to 11 fps or so from default 60. If I restart X session -
everything back to normal, for few hours. If I quit seamonkey - CPU usage
drops. But if I start it up again - CPU load returns quickly, and not go down
until X restart.

Seamonkey use hw compositing (force-enabled) and multiprocess experimental
option. Problem is, exactly same seamonkey with same set of tabs work fine on
4.12.0 kernel!

I set architecture to ia32, even if kernel compiled for x86_64 , because all my
userspace is 32-bit.

hw:
01:00.0 0300: 10de:0606 (rev a2) (prog-if 00 [VGA controller])
aka
01:00.0 VGA compatible controller: NVIDIA Corporation G92 [GeForce 8800 GS]
(rev a2) (prog-if 00 [VGA controller])

X log, dmesg, opreport data will follow.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103896] New: [optimus, reverse PRIME] no HDMI audio

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103896

Bug ID: 103896
   Summary: [optimus, reverse PRIME] no HDMI audio
   Product: xorg
   Version: 7.7 (2012.06)
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: post+...@ralfj.de
QA Contact: xorg-t...@lists.x.org

I have a Lenovo P50 which contains an NVIDIA Quadro M2000M in reverse PRIME
configuration: The HDMI port is connected to the NVidia card.  While getting an
image onto the HDMI port works just fine, there is no audio.

I asked about this on IRC, the logs are at
.
 The summary is that I tried running the following script (after stopping X):

rmmod nouveau
setpci -s 01:00.0 0x488.l=0x200:0x200
echo 1 > /sys/bus/pci/devices/:01:00.0/remove
#echo 1 > /sys/bus/pci/devices/:00:01.0/rescan
echo 1 > /sys/bus/pci/rescan
modprobe nouveau

But that did not help.  I then started X again, and lspci still shows only

$ sudo lspci -nn -d 10de:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107GLM [Quadro
M2000M] [10de:13b0] (rev a2)

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH v3] nouveau/compiler: Allow to omit line numbers when printing instructions

2017-11-24 Thread Pierre Moreau

(Comment is a bit further down)

On 2017-11-24 — 16:55, Tobias Klausmann wrote:
> This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff!
> 
> V2:
>  - Use environmental variable (Karol Herbst)
> V3:
>  - Use the already populated nv50_ir_prog_info to forward information to the
>print pass (Pierre Moreau)
> 
> Signed-off-by: Tobias Klausmann 
> ---
>  src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h  |  1 +
>  src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 +---
>  src/gallium/drivers/nouveau/nouveau_compiler.c|  2 ++
>  src/gallium/drivers/nouveau/nv50/nv50_program.c   |  2 ++
>  src/gallium/drivers/nouveau/nvc0/nvc0_program.c   |  2 ++
>  5 files changed, 16 insertions(+), 3 deletions(-)
> 
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> index ffd53c9cd3..604a22ba89 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
> @@ -82,6 +82,7 @@ struct nv50_ir_prog_info
>  
> uint8_t optLevel; /* optimization level (0 to 3) */
> uint8_t dbgFlags;
> +   bool omitLineNum;

You could maybe add a comment that it only affects when printing the program
(in debug mode), but the patch is nonetheless:

Reviewed-by: Pierre Moreau 

>  
> struct {
>int16_t maxGPR; /* may be -1 if none used */
> diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp 
> b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> index 9145801b62..eb7e9057b5 100644
> --- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> +++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
> @@ -691,7 +691,7 @@ void Instruction::print() const
>  class PrintPass : public Pass
>  {
>  public:
> -   PrintPass() : serial(0) { }
> +   PrintPass(bool omitLineNum = false) : serial(0), omit_serial(omitLineNum) 
> { }
>  
> virtual bool visit(Function *);
> virtual bool visit(BasicBlock *);
> @@ -699,6 +699,7 @@ public:
>  
>  private:
> int serial;
> +   bool omit_serial;
>  };
>  
>  bool
> @@ -762,7 +763,12 @@ PrintPass::visit(BasicBlock *bb)
>  bool
>  PrintPass::visit(Instruction *insn)
>  {
> -   INFO("%3i: ", serial++);
> +   if (omit_serial) {
> +  INFO(" ");
> +  serial++;
> +   }
> +   else
> +  INFO("%3i: ", serial++);
> insn->print();
> return true;
>  }
> @@ -777,7 +783,7 @@ Function::print()
>  void
>  Program::print()
>  {
> -   PrintPass pass;
> +   PrintPass pass(driver->omitLineNum);
> init_colours();
> pass.run(this, true, false);
>  }
> diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c 
> b/src/gallium/drivers/nouveau/nouveau_compiler.c
> index 3151a6f420..1214cf3565 100644
> --- a/src/gallium/drivers/nouveau/nouveau_compiler.c
> +++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
> @@ -122,6 +122,8 @@ nouveau_codegen(int chipset, int type, struct tgsi_token 
> tokens[],
>  
> info.optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
> info.dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
> +   info.omitLineNum =
> + debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
> false;
>  
> ret = nv50_ir_generate_code(&info);
> if (ret) {
> diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c 
> b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> index 6e943a3d94..fb5c9ed777 100644
> --- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
> +++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
> @@ -367,6 +367,8 @@ nv50_program_translate(struct nv50_program *prog, 
> uint16_t chipset,
>  #ifdef DEBUG
> info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
> info->dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
> +   info->omitLineNum =
> + debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
> false;
>  #else
> info->optLevel = 3;
>  #endif
> diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
> b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> index c95a96c717..8dced66437 100644
> --- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> +++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
> @@ -575,6 +575,8 @@ nvc0_program_translate(struct nvc0_program *prog, 
> uint16_t chipset,
> info->target = debug_get_num_option("NV50_PROG_CHIPSET", chipset);
> info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
> info->dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
> +   info->omitLineNum =
> + debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
> false;
>  #else
> info->optLevel = 3;
>  #endif
> -- 
> 2.15.0
> 
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau


signature.asc
Description: PGP signature
___
Nouveau mailing list

[Nouveau] [PATCH v3] nouveau/compiler: Allow to omit line numbers when printing instructions

2017-11-24 Thread Tobias Klausmann

This comes in handy when checking "NV50_PROG_DEBUG=1" outputs with diff!

V2:
 - Use environmental variable (Karol Herbst)
V3:
 - Use the already populated nv50_ir_prog_info to forward information to the
   print pass (Pierre Moreau)

Signed-off-by: Tobias Klausmann 
---
 src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h  |  1 +
 src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp | 12 +---
 src/gallium/drivers/nouveau/nouveau_compiler.c|  2 ++
 src/gallium/drivers/nouveau/nv50/nv50_program.c   |  2 ++
 src/gallium/drivers/nouveau/nvc0/nvc0_program.c   |  2 ++
 5 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
index ffd53c9cd3..604a22ba89 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_driver.h
@@ -82,6 +82,7 @@ struct nv50_ir_prog_info
 
uint8_t optLevel; /* optimization level (0 to 3) */
uint8_t dbgFlags;
+   bool omitLineNum;
 
struct {
   int16_t maxGPR; /* may be -1 if none used */
diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp 
b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
index 9145801b62..eb7e9057b5 100644
--- a/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
+++ b/src/gallium/drivers/nouveau/codegen/nv50_ir_print.cpp
@@ -691,7 +691,7 @@ void Instruction::print() const
 class PrintPass : public Pass
 {
 public:
-   PrintPass() : serial(0) { }
+   PrintPass(bool omitLineNum = false) : serial(0), omit_serial(omitLineNum) { 
}
 
virtual bool visit(Function *);
virtual bool visit(BasicBlock *);
@@ -699,6 +699,7 @@ public:
 
 private:
int serial;
+   bool omit_serial;
 };
 
 bool
@@ -762,7 +763,12 @@ PrintPass::visit(BasicBlock *bb)
 bool
 PrintPass::visit(Instruction *insn)
 {
-   INFO("%3i: ", serial++);
+   if (omit_serial) {
+  INFO(" ");
+  serial++;
+   }
+   else
+  INFO("%3i: ", serial++);
insn->print();
return true;
 }
@@ -777,7 +783,7 @@ Function::print()
 void
 Program::print()
 {
-   PrintPass pass;
+   PrintPass pass(driver->omitLineNum);
init_colours();
pass.run(this, true, false);
 }
diff --git a/src/gallium/drivers/nouveau/nouveau_compiler.c 
b/src/gallium/drivers/nouveau/nouveau_compiler.c
index 3151a6f420..1214cf3565 100644
--- a/src/gallium/drivers/nouveau/nouveau_compiler.c
+++ b/src/gallium/drivers/nouveau/nouveau_compiler.c
@@ -122,6 +122,8 @@ nouveau_codegen(int chipset, int type, struct tgsi_token 
tokens[],
 
info.optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
info.dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
+   info.omitLineNum =
+ debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
false;
 
ret = nv50_ir_generate_code(&info);
if (ret) {
diff --git a/src/gallium/drivers/nouveau/nv50/nv50_program.c 
b/src/gallium/drivers/nouveau/nv50/nv50_program.c
index 6e943a3d94..fb5c9ed777 100644
--- a/src/gallium/drivers/nouveau/nv50/nv50_program.c
+++ b/src/gallium/drivers/nouveau/nv50/nv50_program.c
@@ -367,6 +367,8 @@ nv50_program_translate(struct nv50_program *prog, uint16_t 
chipset,
 #ifdef DEBUG
info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
info->dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
+   info->omitLineNum =
+ debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
false;
 #else
info->optLevel = 3;
 #endif
diff --git a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c 
b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
index c95a96c717..8dced66437 100644
--- a/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
+++ b/src/gallium/drivers/nouveau/nvc0/nvc0_program.c
@@ -575,6 +575,8 @@ nvc0_program_translate(struct nvc0_program *prog, uint16_t 
chipset,
info->target = debug_get_num_option("NV50_PROG_CHIPSET", chipset);
info->optLevel = debug_get_num_option("NV50_PROG_OPTIMIZE", 3);
info->dbgFlags = debug_get_num_option("NV50_PROG_DEBUG", 0);
+   info->omitLineNum =
+ debug_get_num_option("NV50_PROG_DEBUG_OMIT_LINENUM", 0) ? true : 
false;
 #else
info->optLevel = 3;
 #endif
-- 
2.15.0

___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

2017-11-24 Thread Thierry Reding

On Fri, Nov 24, 2017 at 03:08:25PM +0100, Karol Herbst wrote:
> On Fri, Nov 24, 2017 at 3:02 PM, Thierry Reding
>  wrote:
> > On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote:
> >> On my GP107 when I load nouveau after unloading it, for some reason the
> >> GPU stopped sending or the CPU stopped receiving interrupts if MSI was
> >> enabled.
> >
> > I suppose this could happen if the GPU raises an interrupt after the
> > driver's already called free_irq() on it, and hence the driver can't
> > rearm itself in the interrupt handler.
> >
> > This possibly points to a bug somewhere (the GPU should be completely
> > idle by the time free_irq() is called), but this seems like a valid
> > thing to do at initialization in any case to avoid relying on the prior
> > owner of the device to always behave properly.
> >
> 
> Yeah, this makes sense. But what I am wondering about is, why this
> isn't a bigger problem or maybe this is just due to those changes in
> the Pascal interrupt handler and this is a Pascal only problem?

Yeah, this could be some kind of race that's only triggering on Pascal.

Comparing with the nvgpu driver it seems like the MSI interrupt should
be rearmed only after all interrupts have been processed, while Nouveau
currently rearms before processing interrupts (though after masking the
interrupts). I'm not very familiar with all of this, but perhaps Pascal
has some interrupts that Nouveau doesn't mask and therefore might race.

Perhaps something like this would help:

--- >8 ---
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
index b1b1f3626b96..0b3b802c26df 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/pci/base.c
@@ -72,10 +72,10 @@ nvkm_pci_intr(int irq, void *arg)
struct nvkm_device *device = pci->subdev.device;
bool handled = false;
nvkm_mc_intr_unarm(device);
-   if (pci->msi)
-   pci->func->msi_rearm(pci);
nvkm_mc_intr(device, &handled);
nvkm_mc_intr_rearm(device);
+   if (pci->msi)
+   pci->func->msi_rearm(pci);
return handled ? IRQ_HANDLED : IRQ_NONE;
 }

--- >8 ---

> Anyway, the Nvidia driver seems to do it once on loading time as well,
> so I was quite sure we could simply do it this way and be sure that we
> are able to use the GPU from any state.

I think it's totally fine to apply as-is and leave it to further
investigation what Nouveau needs to do to properly uninitialize the
device. Like you said it can always happen that somebody else leaves
the GPU in some undefined state, in which case it's good to always
do this at initialization.

Thierry


signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

2017-11-24 Thread Karol Herbst

On Fri, Nov 24, 2017 at 3:02 PM, Thierry Reding
 wrote:
> On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote:
>> On my GP107 when I load nouveau after unloading it, for some reason the
>> GPU stopped sending or the CPU stopped receiving interrupts if MSI was
>> enabled.
>
> I suppose this could happen if the GPU raises an interrupt after the
> driver's already called free_irq() on it, and hence the driver can't
> rearm itself in the interrupt handler.
>
> This possibly points to a bug somewhere (the GPU should be completely
> idle by the time free_irq() is called), but this seems like a valid
> thing to do at initialization in any case to avoid relying on the prior
> owner of the device to always behave properly.
>

Yeah, this makes sense. But what I am wondering about is, why this
isn't a bigger problem or maybe this is just due to those changes in
the Pascal interrupt handler and this is a Pascal only problem?
Anyway, the Nvidia driver seems to do it once on loading time as well,
so I was quite sure we could simply do it this way and be sure that we
are able to use the GPU from any state.

>> Doing a rearm once before getting any interrupts fixes this.
>>
>> Signed-off-by: Karol Herbst 
>> ---
>>  drm/nouveau/nvkm/subdev/pci/base.c | 4 
>>  1 file changed, 4 insertions(+)
>
> Reviewed-by: Thierry Reding 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

2017-11-24 Thread Thierry Reding

On Fri, Nov 24, 2017 at 03:56:26AM +0100, Karol Herbst wrote:
> On my GP107 when I load nouveau after unloading it, for some reason the
> GPU stopped sending or the CPU stopped receiving interrupts if MSI was
> enabled.

I suppose this could happen if the GPU raises an interrupt after the
driver's already called free_irq() on it, and hence the driver can't
rearm itself in the interrupt handler.

This possibly points to a bug somewhere (the GPU should be completely
idle by the time free_irq() is called), but this seems like a valid
thing to do at initialization in any case to avoid relying on the prior
owner of the device to always behave properly.

> Doing a rearm once before getting any interrupts fixes this.
> 
> Signed-off-by: Karol Herbst 
> ---
>  drm/nouveau/nvkm/subdev/pci/base.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Thierry Reding 

signature.asc
Description: PGP signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103889] New: [NV50/G86] disp: ERROR 1 [] 01 [] chid 0 mthd 0000 data 00000000

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103889

Bug ID: 103889
   Summary: [NV50/G86] disp: ERROR 1 [] 01 [] chid 0 mthd 
data 
   Product: xorg
   Version: 7.7 (2012.06)
  Hardware: PowerPC
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: erhar...@mailbox.org
QA Contact: xorg-t...@lists.x.org

Created attachment 135696
  --> https://bugs.freedesktop.org/attachment.cgi?id=135696&action=edit
dmesg output

Tried a GeForce 8400 GS as 2nd card in my PowerMac G5 11,2 but I only get a
blank screen although it seems to successfully open fb1:

[   14.407485] [drm] Initialized nouveau 1.3.1 20120801 for 0001:06:00.0 on
minor 1
[   14.477817] nouveau: DRM:fb00:003d: init running...
[   14.478206] nouveau: DRM:fb00:003d: init children...
[   14.478582] nouveau: DRM:fb00:003d: init completed in 376us
[   14.480128] nouveau 0001:06:00.0: disp: ERROR 1 [] 01 [] chid 1 mthd 
data 

# lspci -vv -s 0001:06:00.0
0001:06:00.0 VGA compatible controller: NVIDIA Corporation G86 [GeForce 8400
GS] (rev a1) (prog-if 00 [VGA controller])
Subsystem: Micro-Star International Co., Ltd. [MSI] G86 [GeForce 8400
GS]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- ___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103889] [NV50/G86] disp: ERROR 1 [] 01 [] chid 0 mthd 0000 data 00000000

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=103889

--- Comment #1 from erhar...@mailbox.org ---
Created attachment 135697
  --> https://bugs.freedesktop.org/attachment.cgi?id=135697&action=edit
kernel .config

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 101601] Nvidia GT 1030 (NV138/GP108) support

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101601

--- Comment #18 from Pierre Moreau  ---
(In reply to Daniel Drake from comment #17)
> "disp/gf119-: avoid creating non-existent heads" is still not in linus tree,
> is there any news here?

It is definitely in Linus’ tree:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v4.14&id=eba5e56db65b7a44d57a98f5f382b2a2b9991321
and looking at the source from 4.14, the patch seems to be there as well:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/nouveau/nv50_display.c?h=v4.14#n4457

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 101601] Nvidia GT 1030 (NV138/GP108) support

2017-11-24 Thread bugzilla-daemon

https://bugs.freedesktop.org/show_bug.cgi?id=101601

--- Comment #17 from Daniel Drake  ---
"disp/gf119-: avoid creating non-existent heads" is still not in linus tree, is
there any news here?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

[Nouveau] [Bug 103897] Kernel 4.14 causes high cpu usage, 4.12 was OK

[Nouveau] [Bug 103897] New: Kernel 4.14 causes high cpu usage, 4.12 was OK

[Nouveau] [Bug 103896] New: [optimus, reverse PRIME] no HDMI audio

Re: [Nouveau] [PATCH v3] nouveau/compiler: Allow to omit line numbers when printing instructions

[Nouveau] [PATCH v3] nouveau/compiler: Allow to omit line numbers when printing instructions

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

Re: [Nouveau] [PATCH] pci: do a msi rearm on init

[Nouveau] [Bug 103889] New: [NV50/G86] disp: ERROR 1 [] 01 [] chid 0 mthd 0000 data 00000000

[Nouveau] [Bug 103889] [NV50/G86] disp: ERROR 1 [] 01 [] chid 0 mthd 0000 data 00000000

[Nouveau] [Bug 101601] Nvidia GT 1030 (NV138/GP108) support

[Nouveau] [Bug 101601] Nvidia GT 1030 (NV138/GP108) support

15 matches

Site Navigation

Mail list logo

Footer information