[Nouveau] [Bug 90626] HP ZBook 15 nouveau driver hangup for kernel >= 4.1

[bugzilla-daemon]

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

--- Comment #35 from Ortwin Glück  ---
(In reply to Ilia Mirkin from comment #34)
> Hmmm... did you see a "hw bug workaround enabled" line? Are you using Linux
> 4.3? [4.2 and older didn't have the workaround logic.]

Ok works fine in 4.3!

$ dmesg | grep workaround
[4.082516] nouveau :01:00.0: pmu: hw bug workaround enabled
[4.194475] nouveau :01:00.0: pmu: hw bug workaround enabled

-- 
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] [PATCH] pci: enable c800 magic for Clevo P157SM

[Karol Herbst]

this is needed for my gpu

---
 drm/nouveau/nvkm/engine/device/pci.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drm/nouveau/nvkm/engine/device/pci.c 
b/drm/nouveau/nvkm/engine/device/pci.c
index e3c783d..d506e02 100644
--- a/drm/nouveau/nvkm/engine/device/pci.c
+++ b/drm/nouveau/nvkm/engine/device/pci.c
@@ -689,6 +689,12 @@ nvkm_device_pci_10de_1199[] = {
 };
 
 static const struct nvkm_device_pci_vendor
+nvkm_device_pci_10de_11e0[] = {
+   { 0x1558, 0x5106, NULL, { .War00C800_0 = true } },
+   {}
+};
+
+static const struct nvkm_device_pci_vendor
 nvkm_device_pci_10de_11e3[] = {
{ 0x17aa, 0x3683, "GeForce GTX 760A" },
{}
@@ -1485,7 +1491,7 @@ nvkm_device_pci_10de[] = {
{ 0x11c6, "GeForce GTX 650 Ti" },
{ 0x11c8, "GeForce GTX 650" },
{ 0x11cb, "GeForce GT 740" },
-   { 0x11e0, "GeForce GTX 770M" },
+   { 0x11e0, "GeForce GTX 770M", nvkm_device_pci_10de_11e0 },
{ 0x11e1, "GeForce GTX 765M" },
{ 0x11e2, "GeForce GTX 765M" },
{ 0x11e3, "GeForce GTX 760M", nvkm_device_pci_10de_11e3 },
-- 
2.6.2

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

[Nouveau] [PATCH 1/2] disp: activate dual link TMDS links only when possible

[Ilia Mirkin]

From: Hauke Mehrtens 

Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actual possible.

Signed-off-by: Hauke Mehrtens 
Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nv50_display.c   | 8 
 drm/nouveau/nvkm/engine/disp/gf119.c | 2 +-
 drm/nouveau/nvkm/engine/disp/nv50.c  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index c053c50..93bcfdf 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -1961,10 +1961,10 @@ nv50_sor_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *umode,
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_TMDS:
if (nv_encoder->dcb->sorconf.link & 1) {
-   if (mode->clock < 165000)
-   proto = 0x1;
-   else
-   proto = 0x5;
+   proto = 0x1;
+   if (mode->clock >= 165000 &&
+   nv_encoder->dcb->duallink_possible)
+   proto |= 0x4;
} else {
proto = 0x2;
}
diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
b/drm/nouveau/nvkm/engine/disp/gf119.c
index 186fd3a..8691b68 100644
--- a/drm/nouveau/nvkm/engine/disp/gf119.c
+++ b/drm/nouveau/nvkm/engine/disp/gf119.c
@@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (pclk >= 165000 && outp->info.duallink_possible)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
b/drm/nouveau/nvkm/engine/disp/nv50.c
index 32e73a9..ceecd0e 100644
--- a/drm/nouveau/nvkm/engine/disp/nv50.c
+++ b/drm/nouveau/nvkm/engine/disp/nv50.c
@@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (pclk >= 165000 && outp->info.duallink_possible)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
-- 
2.4.10

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

[Nouveau] [PATCH 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

[Ilia Mirkin]

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.

Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nouveau_connector.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 4c8f6ef..f5806eb 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -56,6 +56,10 @@ MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: 
enabled)");
 int nouveau_duallink = 1;
 module_param_named(duallink, nouveau_duallink, int, 0400);
 
+MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
+int nouveau_hdmimhz = 0;
+module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
+
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
 {
@@ -815,6 +819,17 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
struct nouveau_drm *drm = nouveau_drm(connector->dev);
struct dcb_output *dcb = nv_connector->detected_encoder->dcb;
 
+   if (drm_detect_hdmi_monitor(nv_connector->edid)) {
+   if (nouveau_hdmimhz > 0)
+   return nouveau_hdmimhz * 1000;
+   /* Note: these limits are conservative, some Fermi's
+* can do 297 MHz. Unclear how this can be determined.
+*/
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_KEPLER)
+   return 297000;
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_FERMI)
+   return 225000;
+   }
if (dcb->location != DCB_LOC_ON_CHIP ||
drm->device.info.chipset >= 0x46)
return 165000;
-- 
2.4.10

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

Re: [Nouveau] [PATCH 1/2] disp: activate dual link TMDS links only when possible

[Ilia Mirkin]

On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs  wrote:
> On 11/04/2015 08:41 AM, Ilia Mirkin wrote:
>> From: Hauke Mehrtens 
>>
>> Without this patch a pixel clock rate above 165 MHz on a TMDS link is
>> assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
>> supports no dual link, but it supports pixel clock rates above 165 MHz.
>> Only activate Dual Link mode when it is actual possible.
>>
>> Signed-off-by: Hauke Mehrtens 
>> Signed-off-by: Ilia Mirkin 
>> ---
>>  drm/nouveau/nv50_display.c   | 8 
>>  drm/nouveau/nvkm/engine/disp/gf119.c | 2 +-
>>  drm/nouveau/nvkm/engine/disp/nv50.c  | 2 +-
>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
>> index c053c50..93bcfdf 100644
>> --- a/drm/nouveau/nv50_display.c
>> +++ b/drm/nouveau/nv50_display.c
>> @@ -1961,10 +1961,10 @@ nv50_sor_mode_set(struct drm_encoder *encoder, 
>> struct drm_display_mode *umode,
>>   switch (nv_encoder->dcb->type) {
>>   case DCB_OUTPUT_TMDS:
>>   if (nv_encoder->dcb->sorconf.link & 1) {
>> - if (mode->clock < 165000)
>> - proto = 0x1;
>> - else
>> - proto = 0x5;
>> + proto = 0x1;
>> + if (mode->clock >= 165000 &&
>> + nv_encoder->dcb->duallink_possible)
>> + proto |= 0x4;
> This is a somewhat flaky condition, given that one could plug a
> single-link HDMI monitor into a duallink-capable TMDS connector.
>
> Still, it's an improvement :)

Yeah, FWIW I thought of that (for the second patch too). All this
stuff is pretty fragile. But... what are you gonna do. Is there some
other way of telling whether we're on HDMI or DVI?

>
>>   } else {
>>   proto = 0x2;
>>   }
>> diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
>> b/drm/nouveau/nvkm/engine/disp/gf119.c
>> index 186fd3a..8691b68 100644
>> --- a/drm/nouveau/nvkm/engine/disp/gf119.c
>> +++ b/drm/nouveau/nvkm/engine/disp/gf119.c
>> @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, 
>> u32 pclk, u32 *conf)
>>   switch (outp->info.type) {
>>   case DCB_OUTPUT_TMDS:
>>   *conf = (ctrl & 0x0f00) >> 8;
>> - if (pclk >= 165000)
>> + if (pclk >= 165000 && outp->info.duallink_possible)
>>   *conf |= 0x0100;
> I think it might be more robust to key this off the SOR protocol, rather
> than duplicating the condition above.

You mean disp->sor.lvdsconf? What do I do with that? Or did you have
something else in mind?

>
>>   break;
>>   case DCB_OUTPUT_LVDS:
>> diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
>> b/drm/nouveau/nvkm/engine/disp/nv50.c
>> index 32e73a9..ceecd0e 100644
>> --- a/drm/nouveau/nvkm/engine/disp/nv50.c
>> +++ b/drm/nouveau/nvkm/engine/disp/nv50.c
>> @@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, 
>> u32 pclk, u32 *conf)
>>   switch (outp->info.type) {
>>   case DCB_OUTPUT_TMDS:
>>   *conf = (ctrl & 0x0f00) >> 8;
>> - if (pclk >= 165000)
>> + if (pclk >= 165000 && outp->info.duallink_possible)
>>   *conf |= 0x0100;
> Same here.
>
>>   break;
>>   case DCB_OUTPUT_LVDS:
>>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help

[bugzilla-daemon]

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

--- Comment #87 from Ilia Mirkin  ---
(In reply to Julien Isorce from comment #86)
> I only tested with patch+workaround, but maybe "patch" is enough. I can try
> to confirm tomorrow. Thx!

Please do -- the workaround is necessary for a fraction of users. We're unsure
when it's safe to enable.

-- 
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] Nouveau for FreeBSD

[Curtis Hamilton]

Any progress on the FreeBSD front?

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

[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help

[bugzilla-daemon]

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

--- Comment #84 from Julien Isorce  ---
I think I now why the workaround is no applied, it is because it is only for
NVE4, 6 and 7. And my GT 750M seems to be threatened as "NVC0 (GF100)
GeForce GTX (465, 470, 480, 480M) Quadro 4000, 5000[M] (??), 6000". See
http://nouveau.freedesktop.org/wiki/CodeNames/.

Indeed it fails in gf100.c:1478/gf100_gr_init_ctxctl (i.e. GF100) instead of
going to gk104.c (i.e. NVE4 GK104, or NVE7 GK107) where the War00C800 is
handled.

Or maybe this is an expected behavior since I am not trying to use this graphic
card (GT 750M) for X11 but only for HW decoding. (the other graphic card, intel
is set to be used by the X11). 

When running LIBVA_DRIVER_NAME=gallium vainfo --display drm
It hits "case 0xe0: obj_class = NVE4_P2MF_CLASS;" in nvc0_screen_create

#0  abi16_engobj (obj=0x613d20) at abi16.c:109
#1  0x74163165 in nouveau_object_new (parent=parent@entry=0x613750,
handle=handle@entry=3203347007, oclass=41024, 
data=data@entry=0x0, length=8, length@entry=0, pobj=pobj@entry=0x613728) at
nouveau.c:295
#2  0x750ab4c9 in nvc0_screen_create (dev=0x6131e0) at
nvc0/nvc0_screen.c:722
#3  0x74fb9d59 in nouveau_drm_screen_create (fd=fd@entry=3) at
nouveau_drm_winsys.c:119
#4  0x74e59944 in pipe_nouveau_create_screen (fd=3)
at ../../../../src/gallium/auxiliary/target-helpers/inline_drm_helper.h:171
#5  dd_create_screen (fd=fd@entry=3) at
../../../../src/gallium/auxiliary/target-helpers/inline_drm_helper.h:392
#6  0x74e5a71e in __vaDriverInit_0_38 (ctx=0x604030) at context.c:152
#7  0x77bc10e8 in va_openDriver (dpy=dpy@entry=0x604220,
driver_name=) at va.c:296
#8  0x77bc1fab in vaInitialize (dpy=dpy@entry=0x604220,
major_version=major_version@entry=0x7fffb820, 
minor_version=minor_version@entry=0x7fffb824) at va.c:559
#9  0x004015d0 in main (argc=1, argv=0x7fffb978) at vainfo.c:116
(gdb) n
118dev = nouveau_object_find(obj, NOUVEAU_DEVICE_CLASS);
(gdb) n
109{
(gdb) n
111.channel = obj->parent->handle,
(gdb) n
110struct drm_nouveau_grobj_alloc req = {
(gdb) n
118dev = nouveau_object_find(obj, NOUVEAU_DEVICE_CLASS);
(gdb) n
119ret = drmCommandWrite(dev->fd, DRM_NOUVEAU_GROBJ_ALLOC,
(gdb) n
121if (ret)
(gdb) n
126}
(gdb) n
nouveau_object_new (parent=parent@entry=0x613750,
handle=handle@entry=3203347007, oclass=41024, data=data@entry=0x0, 
length=, length@entry=0, pobj=pobj@entry=0x613728) at
nouveau.c:296
296break;
(gdb) n
302if (ret) {
(gdb) n
303free(obj);
(gdb) n
309}
(gdb) n
304return ret;
(gdb) n
309}
(gdb) n
nvc0_screen_create (dev=0x6131e0) at nvc0/nvc0_screen.c:724
724   if (ret)
(gdb) n
725  FAIL_SCREEN_INIT("Error allocating PGRAPH context for M2MF: %d\n",
ret);
(gdb) 
ret is -16

Any idea ? Thx

-- 
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 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help

[bugzilla-daemon]

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

--- Comment #86 from Julien Isorce  ---
(In reply to Ilia Mirkin from comment #85)
> (In reply to Julien Isorce from comment #84)
> > Any idea ? Thx
> 
> You have a GK107. It probably needs the PGOB fix as well as another user on
> this bug needed it. See
> http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=linux-4.
> 4=3c9aca318150ba1152e957a37473ff67d8ebba30 -- should be on its way to
> linux 4.4.

Thx I can confirm it resolved my problem. I thought I was testing with darktama
branch few weeks ago but maybe not. Anyway I applied the patch you pointed in
the kernel tree directly (today git master). After a fresh build and install I
can confirm it works. HW decoding too :)

I only tested with patch+workaround, but maybe "patch" is enough. I can try to
confirm tomorrow. Thx!

-- 
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 1/2] disp: activate dual link TMDS links only when possible

[Ben Skeggs]

On 11/04/2015 10:37 AM, Ilia Mirkin wrote:
> On Tue, Nov 3, 2015 at 7:02 PM, Ben Skeggs  wrote:
>> On 11/04/2015 08:41 AM, Ilia Mirkin wrote:
>>> From: Hauke Mehrtens 
>>>
>>> Without this patch a pixel clock rate above 165 MHz on a TMDS link is
>>> assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
>>> supports no dual link, but it supports pixel clock rates above 165 MHz.
>>> Only activate Dual Link mode when it is actual possible.
>>>
>>> Signed-off-by: Hauke Mehrtens 
>>> Signed-off-by: Ilia Mirkin 
>>> ---
>>>  drm/nouveau/nv50_display.c   | 8 
>>>  drm/nouveau/nvkm/engine/disp/gf119.c | 2 +-
>>>  drm/nouveau/nvkm/engine/disp/nv50.c  | 2 +-
>>>  3 files changed, 6 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
>>> index c053c50..93bcfdf 100644
>>> --- a/drm/nouveau/nv50_display.c
>>> +++ b/drm/nouveau/nv50_display.c
>>> @@ -1961,10 +1961,10 @@ nv50_sor_mode_set(struct drm_encoder *encoder, 
>>> struct drm_display_mode *umode,
>>>   switch (nv_encoder->dcb->type) {
>>>   case DCB_OUTPUT_TMDS:
>>>   if (nv_encoder->dcb->sorconf.link & 1) {
>>> - if (mode->clock < 165000)
>>> - proto = 0x1;
>>> - else
>>> - proto = 0x5;
>>> + proto = 0x1;
>>> + if (mode->clock >= 165000 &&
>>> + nv_encoder->dcb->duallink_possible)
>>> + proto |= 0x4;
>> This is a somewhat flaky condition, given that one could plug a
>> single-link HDMI monitor into a duallink-capable TMDS connector.
>>
>> Still, it's an improvement :)
> 
> Yeah, FWIW I thought of that (for the second patch too). All this
> stuff is pretty fragile. But... what are you gonna do. Is there some
> other way of telling whether we're on HDMI or DVI?
drm_detect_hdmi_monitor() should do the trick :)

> 
>>
>>>   } else {
>>>   proto = 0x2;
>>>   }
>>> diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
>>> b/drm/nouveau/nvkm/engine/disp/gf119.c
>>> index 186fd3a..8691b68 100644
>>> --- a/drm/nouveau/nvkm/engine/disp/gf119.c
>>> +++ b/drm/nouveau/nvkm/engine/disp/gf119.c
>>> @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, 
>>> u32 pclk, u32 *conf)
>>>   switch (outp->info.type) {
>>>   case DCB_OUTPUT_TMDS:
>>>   *conf = (ctrl & 0x0f00) >> 8;
>>> - if (pclk >= 165000)
>>> + if (pclk >= 165000 && outp->info.duallink_possible)
>>>   *conf |= 0x0100;
>> I think it might be more robust to key this off the SOR protocol, rather
>> than duplicating the condition above.
> 
> You mean disp->sor.lvdsconf? What do I do with that? Or did you have
> something else in mind?
No, not that.  The "proto" field you're setting set "5" in the previous
hunk when dual-link is requested is actually
NV907D_SOR_SET_CONTROL_PROTOCOL_DUAL_TMDS - which is what is parsed here
with (ctrl & 0x0f00).

So, instead of "if (pclk >= 165000)" here, you should just be able to do
"(*conf == 5)".

I have no idea why the BIOS tables identify the dual-link data with
0x0105 instead of 0x0005, when "5" already indicates DUAL_TMDS - but anyway.

> 
>>
>>>   break;
>>>   case DCB_OUTPUT_LVDS:
>>> diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
>>> b/drm/nouveau/nvkm/engine/disp/nv50.c
>>> index 32e73a9..ceecd0e 100644
>>> --- a/drm/nouveau/nvkm/engine/disp/nv50.c
>>> +++ b/drm/nouveau/nvkm/engine/disp/nv50.c
>>> @@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, 
>>> u32 pclk, u32 *conf)
>>>   switch (outp->info.type) {
>>>   case DCB_OUTPUT_TMDS:
>>>   *conf = (ctrl & 0x0f00) >> 8;
>>> - if (pclk >= 165000)
>>> + if (pclk >= 165000 && outp->info.duallink_possible)
>>>   *conf |= 0x0100;
>> Same here.
>>
>>>   break;
>>>   case DCB_OUTPUT_LVDS:
>>>
>>



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 91236] [NVC3] Passive DP to HDMI adapter cannot use pixel clocks greater than 165 MHz

[bugzilla-daemon]

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

--- Comment #5 from Ilia Mirkin  ---
With the below pair of patches, you should be able to set any max pixel clock
you like.

http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8d5fe3328855063bb41acb00b1049138acce8e2e
http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=f787ef9b44102ed01d4255a653d0261bb6365ba3

These should apply relatively easily onto a 4.3 or even older kernel. Boot with
nouveau.hdmimhz=297.

-- 
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] [PATCH] kms: no need to check for empty edid before drm_detect_hdmi_monitor

[Ilia Mirkin]

Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nv50_display.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index bdaba91..d9cba87 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -773,7 +773,6 @@ nv50_crtc_set_scale(struct nouveau_crtc *nv_crtc, bool 
update)
 */
if (nv_connector && ( nv_connector->underscan == UNDERSCAN_ON ||
 (nv_connector->underscan == UNDERSCAN_AUTO &&
- nv_connector->edid &&
  drm_detect_hdmi_monitor(nv_connector->edid {
u32 bX = nv_connector->underscan_hborder;
u32 bY = nv_connector->underscan_vborder;
-- 
2.4.10

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

[Nouveau] [Bug 70354] [NVE6, NVE7] HUB_INIT timeout on graph init, blob fw doesn't help

[bugzilla-daemon]

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

--- Comment #85 from Ilia Mirkin  ---
(In reply to Julien Isorce from comment #84)
> Any idea ? Thx

You have a GK107. It probably needs the PGOB fix as well as another user on
this bug needed it. See
http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?h=linux-4.4=3c9aca318150ba1152e957a37473ff67d8ebba30
-- should be on its way to linux 4.4.

-- 
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] [PATCH v2 1/2] disp: activate dual link TMDS links only when possible

[Ilia Mirkin]

From: Hauke Mehrtens 

Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actually possible and requested.

Signed-off-by: Hauke Mehrtens 
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
 enable extra config bit]
Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nv50_display.c   | 18 ++
 drm/nouveau/nvkm/engine/disp/gf119.c |  2 +-
 drm/nouveau/nvkm/engine/disp/nv50.c  |  2 +-
 3 files changed, 16 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index c053c50..57781fd 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -1961,10 +1961,20 @@ nv50_sor_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *umode,
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_TMDS:
if (nv_encoder->dcb->sorconf.link & 1) {
-   if (mode->clock < 165000)
-   proto = 0x1;
-   else
-   proto = 0x5;
+   proto = 0x1;
+   /* Only enable dual-link if:
+*  - DCB says we can
+*  - Need to (i.e. rate > 165MHz)
+*  - Not an HDMI monitor, since there's no dual-link
+*on HDMI. Of course in order to determine that,
+*we need the EDID. So if no EDID, just let it
+*slide.
+*/
+   if (mode->clock >= 165000 &&
+   nv_encoder->dcb->duallink_possible &&
+   (!nv_connector->edid ||
+!drm_detect_hdmi_monitor(nv_connector->edid)))
+   proto |= 0x4;
} else {
proto = 0x2;
}
diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
b/drm/nouveau/nvkm/engine/disp/gf119.c
index 186fd3a..f031466 100644
--- a/drm/nouveau/nvkm/engine/disp/gf119.c
+++ b/drm/nouveau/nvkm/engine/disp/gf119.c
@@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (*conf == 5)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
b/drm/nouveau/nvkm/engine/disp/nv50.c
index 32e73a9..4226d21 100644
--- a/drm/nouveau/nvkm/engine/disp/nv50.c
+++ b/drm/nouveau/nvkm/engine/disp/nv50.c
@@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (*conf == 5)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
-- 
2.4.10

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

[Nouveau] [PATCH v2 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

[Ilia Mirkin]

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.

Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nouveau_connector.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 4c8f6ef..57bea79 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -56,6 +56,10 @@ MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: 
enabled)");
 int nouveau_duallink = 1;
 module_param_named(duallink, nouveau_duallink, int, 0400);
 
+MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
+int nouveau_hdmimhz = 0;
+module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
+
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
 {
@@ -809,12 +813,23 @@ nouveau_connector_get_modes(struct drm_connector 
*connector)
 }
 
 static unsigned
-get_tmds_link_bandwidth(struct drm_connector *connector)
+get_tmds_link_bandwidth(struct drm_connector *connector, bool hdmi)
 {
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(connector->dev);
struct dcb_output *dcb = nv_connector->detected_encoder->dcb;
 
+   if (hdmi) {
+   if (nouveau_hdmimhz > 0)
+   return nouveau_hdmimhz * 1000;
+   /* Note: these limits are conservative, some Fermi's
+* can do 297 MHz. Unclear how this can be determined.
+*/
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_KEPLER)
+   return 297000;
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_FERMI)
+   return 225000;
+   }
if (dcb->location != DCB_LOC_ON_CHIP ||
drm->device.info.chipset >= 0x46)
return 165000;
@@ -835,6 +850,7 @@ nouveau_connector_mode_valid(struct drm_connector 
*connector,
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
unsigned clock = mode->clock;
+   bool hdmi;
 
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -847,8 +863,11 @@ nouveau_connector_mode_valid(struct drm_connector 
*connector,
max_clock = 40;
break;
case DCB_OUTPUT_TMDS:
-   max_clock = get_tmds_link_bandwidth(connector);
-   if (nouveau_duallink && nv_encoder->dcb->duallink_possible)
+   hdmi = !nv_connector->edid ||
+   drm_detect_hdmi_monitor(nv_connector->edid);
+   max_clock = get_tmds_link_bandwidth(connector, hdmi);
+   if (!hdmi && nouveau_duallink &&
+   nv_encoder->dcb->duallink_possible)
max_clock *= 2;
break;
case DCB_OUTPUT_ANALOG:
-- 
2.4.10

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

Re: [Nouveau] [PATCH 1/2] disp: activate dual link TMDS links only when possible

[Ben Skeggs]

On 11/04/2015 08:41 AM, Ilia Mirkin wrote:
> From: Hauke Mehrtens 
> 
> Without this patch a pixel clock rate above 165 MHz on a TMDS link is
> assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
> supports no dual link, but it supports pixel clock rates above 165 MHz.
> Only activate Dual Link mode when it is actual possible.
> 
> Signed-off-by: Hauke Mehrtens 
> Signed-off-by: Ilia Mirkin 
> ---
>  drm/nouveau/nv50_display.c   | 8 
>  drm/nouveau/nvkm/engine/disp/gf119.c | 2 +-
>  drm/nouveau/nvkm/engine/disp/nv50.c  | 2 +-
>  3 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
> index c053c50..93bcfdf 100644
> --- a/drm/nouveau/nv50_display.c
> +++ b/drm/nouveau/nv50_display.c
> @@ -1961,10 +1961,10 @@ nv50_sor_mode_set(struct drm_encoder *encoder, struct 
> drm_display_mode *umode,
>   switch (nv_encoder->dcb->type) {
>   case DCB_OUTPUT_TMDS:
>   if (nv_encoder->dcb->sorconf.link & 1) {
> - if (mode->clock < 165000)
> - proto = 0x1;
> - else
> - proto = 0x5;
> + proto = 0x1;
> + if (mode->clock >= 165000 &&
> + nv_encoder->dcb->duallink_possible)
> + proto |= 0x4;
This is a somewhat flaky condition, given that one could plug a
single-link HDMI monitor into a duallink-capable TMDS connector.

Still, it's an improvement :)

>   } else {
>   proto = 0x2;
>   }
> diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
> b/drm/nouveau/nvkm/engine/disp/gf119.c
> index 186fd3a..8691b68 100644
> --- a/drm/nouveau/nvkm/engine/disp/gf119.c
> +++ b/drm/nouveau/nvkm/engine/disp/gf119.c
> @@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
> pclk, u32 *conf)
>   switch (outp->info.type) {
>   case DCB_OUTPUT_TMDS:
>   *conf = (ctrl & 0x0f00) >> 8;
> - if (pclk >= 165000)
> + if (pclk >= 165000 && outp->info.duallink_possible)
>   *conf |= 0x0100;
I think it might be more robust to key this off the SOR protocol, rather
than duplicating the condition above.

>   break;
>   case DCB_OUTPUT_LVDS:
> diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
> b/drm/nouveau/nvkm/engine/disp/nv50.c
> index 32e73a9..ceecd0e 100644
> --- a/drm/nouveau/nvkm/engine/disp/nv50.c
> +++ b/drm/nouveau/nvkm/engine/disp/nv50.c
> @@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
> pclk, u32 *conf)
>   switch (outp->info.type) {
>   case DCB_OUTPUT_TMDS:
>   *conf = (ctrl & 0x0f00) >> 8;
> - if (pclk >= 165000)
> + if (pclk >= 165000 && outp->info.duallink_possible)
>   *conf |= 0x0100;
Same here.

>   break;
>   case DCB_OUTPUT_LVDS:
> 



signature.asc
Description: OpenPGP digital signature
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v3 2/2] connector: allow 225/297MHz pixel clocks for HDMI on Fermi/Kepler

[Ilia Mirkin]

Some Fermi's apparently alow allow 297MHz clocks, so create a parameter
which allows end-users to set it themselves until we have a reliable way
to determine the board's maximum pixel clocks.

Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nouveau_connector.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drm/nouveau/nouveau_connector.c b/drm/nouveau/nouveau_connector.c
index 4c8f6ef..8dd384b 100644
--- a/drm/nouveau/nouveau_connector.c
+++ b/drm/nouveau/nouveau_connector.c
@@ -56,6 +56,10 @@ MODULE_PARM_DESC(duallink, "Allow dual-link TMDS (default: 
enabled)");
 int nouveau_duallink = 1;
 module_param_named(duallink, nouveau_duallink, int, 0400);
 
+MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz)");
+int nouveau_hdmimhz = 0;
+module_param_named(hdmimhz, nouveau_hdmimhz, int, 0400);
+
 struct nouveau_encoder *
 find_encoder(struct drm_connector *connector, int type)
 {
@@ -809,12 +813,23 @@ nouveau_connector_get_modes(struct drm_connector 
*connector)
 }
 
 static unsigned
-get_tmds_link_bandwidth(struct drm_connector *connector)
+get_tmds_link_bandwidth(struct drm_connector *connector, bool hdmi)
 {
struct nouveau_connector *nv_connector = nouveau_connector(connector);
struct nouveau_drm *drm = nouveau_drm(connector->dev);
struct dcb_output *dcb = nv_connector->detected_encoder->dcb;
 
+   if (hdmi) {
+   if (nouveau_hdmimhz > 0)
+   return nouveau_hdmimhz * 1000;
+   /* Note: these limits are conservative, some Fermi's
+* can do 297 MHz. Unclear how this can be determined.
+*/
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_KEPLER)
+   return 297000;
+   if (drm->device.info.family >= NV_DEVICE_INFO_V0_FERMI)
+   return 225000;
+   }
if (dcb->location != DCB_LOC_ON_CHIP ||
drm->device.info.chipset >= 0x46)
return 165000;
@@ -835,6 +850,7 @@ nouveau_connector_mode_valid(struct drm_connector 
*connector,
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
unsigned clock = mode->clock;
+   bool hdmi;
 
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -847,8 +863,10 @@ nouveau_connector_mode_valid(struct drm_connector 
*connector,
max_clock = 40;
break;
case DCB_OUTPUT_TMDS:
-   max_clock = get_tmds_link_bandwidth(connector);
-   if (nouveau_duallink && nv_encoder->dcb->duallink_possible)
+   hdmi = drm_detect_hdmi_monitor(nv_connector->edid);
+   max_clock = get_tmds_link_bandwidth(connector, hdmi);
+   if (!hdmi && nouveau_duallink &&
+   nv_encoder->dcb->duallink_possible)
max_clock *= 2;
break;
case DCB_OUTPUT_ANALOG:
-- 
2.4.10

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

[Nouveau] [PATCH v3 1/2] disp: activate dual link TMDS links only when possible

[Ilia Mirkin]

From: Hauke Mehrtens 

Without this patch a pixel clock rate above 165 MHz on a TMDS link is
assumed to be dual link. This is true for DVI, but not for HDMI. HDMI
supports no dual link, but it supports pixel clock rates above 165 MHz.
Only activate Dual Link mode when it is actually possible and requested.

Signed-off-by: Hauke Mehrtens 
[imirkin: check for hdmi monitor for computing proto, use sor ctrl to
 enable extra config bit]
Signed-off-by: Ilia Mirkin 
---
 drm/nouveau/nv50_display.c   | 15 +++
 drm/nouveau/nvkm/engine/disp/gf119.c |  2 +-
 drm/nouveau/nvkm/engine/disp/nv50.c  |  2 +-
 3 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/drm/nouveau/nv50_display.c b/drm/nouveau/nv50_display.c
index c053c50..bdaba91 100644
--- a/drm/nouveau/nv50_display.c
+++ b/drm/nouveau/nv50_display.c
@@ -1961,10 +1961,17 @@ nv50_sor_mode_set(struct drm_encoder *encoder, struct 
drm_display_mode *umode,
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_TMDS:
if (nv_encoder->dcb->sorconf.link & 1) {
-   if (mode->clock < 165000)
-   proto = 0x1;
-   else
-   proto = 0x5;
+   proto = 0x1;
+   /* Only enable dual-link if:
+*  - Need to (i.e. rate > 165MHz)
+*  - DCB says we can
+*  - Not an HDMI monitor, since there's no dual-link
+*on HDMI.
+*/
+   if (mode->clock >= 165000 &&
+   nv_encoder->dcb->duallink_possible &&
+   !drm_detect_hdmi_monitor(nv_connector->edid))
+   proto |= 0x4;
} else {
proto = 0x2;
}
diff --git a/drm/nouveau/nvkm/engine/disp/gf119.c 
b/drm/nouveau/nvkm/engine/disp/gf119.c
index 186fd3a..f031466 100644
--- a/drm/nouveau/nvkm/engine/disp/gf119.c
+++ b/drm/nouveau/nvkm/engine/disp/gf119.c
@@ -158,7 +158,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (*conf == 5)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
diff --git a/drm/nouveau/nvkm/engine/disp/nv50.c 
b/drm/nouveau/nvkm/engine/disp/nv50.c
index 32e73a9..4226d21 100644
--- a/drm/nouveau/nvkm/engine/disp/nv50.c
+++ b/drm/nouveau/nvkm/engine/disp/nv50.c
@@ -391,7 +391,7 @@ exec_clkcmp(struct nv50_disp *disp, int head, int id, u32 
pclk, u32 *conf)
switch (outp->info.type) {
case DCB_OUTPUT_TMDS:
*conf = (ctrl & 0x0f00) >> 8;
-   if (pclk >= 165000)
+   if (*conf == 5)
*conf |= 0x0100;
break;
case DCB_OUTPUT_LVDS:
-- 
2.4.10

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

[Nouveau] [Bug 91236] [NVC3] Passive DP to HDMI adapter cannot use pixel clocks greater than 165 MHz

[bugzilla-daemon]

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

--- Comment #6 from Andrew Boettcher  ---
I am reporting the patches worked great! Indeed I am now viewing this bug with
a screen in 297 MHz over a passive DP to HDMI connector. Before we missed the
second part where the dual link mode was activated.

This is great, thanks! I guess the next step is to figure out how to detect the
real limit, which I believe is 300 MHz on this chip.

-- 
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] Nouveau for FreeBSD

[cbergstrom]

  Is anyone actually and or actively working on this? Github.com/pathscale/pscnv is totally bitrot but waaay more portable base. Nouveau made hard Linux assumptions that will be difficult to overcome afaik.From: Curtis HamiltonSent: Wednesday, November 4, 2015 08:06To: nouveau@lists.freedesktop.orgSubject: [Nouveau] Nouveau for FreeBSDAny progress on the FreeBSD front?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Nouveau for FreeBSD

[Ilia Mirkin]

Nouveau kernel module has a largely os-agnostic "core" component (called
nvkm/nvif now) which encompasses the actual operation of the GPU. The drm
wrapper around it provides the relevant interfaces for KMS/ioctls/etc. Any
port would want the ioctl bits as well, since that's what the userspace
mesa/ddx components rely on.

That said, I'm not aware of any serious effort to port nouveau to any other
OS.

  -ilia

On Wed, Nov 4, 2015 at 2:08 AM,  wrote:

> Is anyone actually and or actively working on this?
> Github.com/pathscale/pscnv is totally bitrot but waaay more portable base.
> Nouveau made hard Linux assumptions that will be difficult to overcome
> afaik.
>
>
>
> *From: *Curtis Hamilton
> *Sent: *Wednesday, November 4, 2015 08:06
> *To: *nouveau@lists.freedesktop.org
> *Subject: *[Nouveau] Nouveau for FreeBSD
>
> Any progress on the FreeBSD front?
>
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 73373] [NVE4] GPU lockup after opening many tabs in Chromium web browser

[bugzilla-daemon]

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

--- Comment #19 from Mario Barrera  ---
(In reply to Ilia Mirkin from comment #18)
> (In reply to Mario Barrera from comment #15)
> > Maybe useful, opening about 10 tabs with embedded flash elements in Firefox
> > seems to cause the running Chromium browser to trigger the GPU lockup.
> 
> Does this still happen with a recent kernel / mesa? Among other things, mesa
> 11.0.3 fixes a number of annoying resource management issues.

I can still reproduce the issue by opening many HTML files with Firefox. It
happens always.

I have mesa 11.0.4 in Linux 4.2.5-1-ARCH.

I'm attaching the logs.

-- 
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 73373] [NVE4] GPU lockup after opening many tabs in Chromium web browser

[bugzilla-daemon]

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

--- Comment #21 from Mario Barrera  ---
Created attachment 119387
  --> https://bugs.freedesktop.org/attachment.cgi?id=119387=edit
opening several HTML files with Firefox

-- 
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 73373] [NVE4] GPU lockup after opening many tabs in Chromium web browser

[bugzilla-daemon]

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

--- Comment #20 from Mario Barrera  ---
Created attachment 119386
  --> https://bugs.freedesktop.org/attachment.cgi?id=119386=edit
opening several HTML files with Firefox

-- 
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