Re: [Nouveau] Hard-to-find bug brings down whole kernel

[Ilia Mirkin]

"fail ttm_validate" basically means "you ran out of vram".
Unfortunately the GL driver doesn't handle this gracefully, causing
commands to get submitted which eventually hang the GPU. You can
disable hw accel in chrome which should ideally "fix" this for you.

Cheers,

  -ilia

On Fri, Dec 9, 2016 at 5:30 AM, Ognjen Galić  wrote:
> I have an older Lenovo machine, a T61, with the Nvidia Quadro NVS 140M.
> There is this random bug that would hang the whole machine, and then cause a
> panic and reboot it (the caps lock light is flashing).
>
> I can't get any kernel messages of this issue except the one in this YouTube
> video I had luck to
> film and catch the error:
>
> https://www.youtube.com/watch?v=Y1X6s7_laGw
>
> The bug can be triggered always by visiting https://www.google.com/chrome
> when
> the animation plays of the Chrome window rotating.
>
> This has been a persistent bug for me from 3.1X all the way to 4.8.12, and
> I've solved
> it before by just using the proprietary driver, but I now have trouble
> resuming Linux with that.
>
> I've tried logging the kernel messages over SSH and that did not work
> either, it just locks up.
>
> Anyone has any ideas how to catch the issue without going through the whole
> kdump procedure?
>
> Regards,
>
> Gala
>
>
> ___
> Nouveau mailing list
> Nouveau@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Zheng, Lv]

Hi, Mika

> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU 
> via Power Resources
> 
> On Thu, Oct 27, 2016 at 06:06:48PM +0200, Peter Wu wrote:
> > On Thu, Oct 27, 2016 at 12:55:08PM +0300, Mika Westerberg wrote:
> > > On Thu, Oct 27, 2016 at 09:42:28AM +, Rick Kerkhof wrote:
> > > >No, there are not. Here is the recursive directory listing:
> > >
> > > Are you able to try the following patch and send me dmesg (or attach it
> > > to that bug)? It should show if the ACPI core even tries to add those
> > > power resources.
> >
> > So Rick has tested this patch now on top of 4.8.4 (mainline fails to
> > boot due to a kbuild issue which I reported elsewhere), but the output
> > is empty. That seems to indicate that flags.power_resources is unset.
> 
> Is it completely empty or is it empty just for RP05? It should print out
> all devices with power resources.
> 
> > Given that _PS3 exists and is indeed a package with some elements, it
> > seems that acpi_extract_power_resources is failing. Note that in the
> > SSDT, the power resource NVP3 was referenced before it was defined,
> > could that result in this enumeration failure? Relevant SSDT excerpt:
> >
> > Scope (\_SB.PCI0.RP05)
> > {
> > Name (_PR3, Package (0x01)  // _PR3: Power Resources for D3hot
> > {
> > NVP3
> > })
> > // ...
> > }
> >
> > PowerResource (NVP3, 0x00, 0x)

Looks wrong order to me.

However, _PR3 is a package, for AML opcode that contains PkgLength grammar 
primitive, forward reference may be OK (for example Method).
DefPackage := PackageOp PkgLength NumElements PackageElementList
DefMethod := MethodOp PkgLength NameString MethodFlags TermList
As when it is encountered, AML interpreter may only saves entire packaged 
object.

I need to test behaviors around Package with qemu but I don't have environment 
now.
Can you help to give it a try?
By adding customize an ssdt with the above code putting under root scope,
DefinitionBlock ("ssdt-package.aml", "SSDT", 2, "INTEL ", "PACKAGE ", 
0x3000)
{
Scope (\)
{
Name (_PR3, Package (0x01) { NVP3 })
}
PowerResource (NVP3, 0x00, 0x) {}
}
Running Windows images on qemu with this ssdt appended "-acpitable 
file=ssdt-package.aml".
To see if blue screen can be resulted.

Thanks
Lv

> 
> That and the fact that they come from an SSDT instead of DSDT may cause
> this. However, I'm not expert in ACPICA so adding Bob and Lv if they
> have ideas.
> 
> Bob, Lv, the bug in question is: 
> https://bugs.freedesktop.org/show_bug.cgi?id=98398
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] 4.9-rc7 nouveau fails on arm64 64k page kernel but works with 4k

[Jeremy Linton]

Hi,

I placed a 9600GT in a softiron 3k running fedora 25, and the nouveau 
driver failed to claim the device with :


[drm] Initialized
nouveau :01:00.0: NVIDIA G94 (094100a1)
nouveau :01:00.0: bios: version 62.94.0d.00.04
nouveau: probe of :01:00.0 failed with error -22

Which with a little bit of debugging seems to be a failure in:

[77216.692605] [] ttm_bo_validate+0xb0/0x1e8 [ttm]
[77216.698697] [] ttm_bo_init+0x354/0x410 [ttm]
[77216.704706] [] nouveau_bo_new+0x1f4/0x314 [nouveau]
[77216.711308] [] nv50_display_create+0x10c/0xa1c 
[nouveau]
[77216.718340] [] nouveau_display_create+0x50c/0x59c 
[nouveau]

[77216.725632] [] nouveau_drm_load+0x22c/0x8c0 [nouveau]
[77216.732286] [] drm_dev_register+0xc0/0xf0 [drm]
[77216.738409] [] drm_get_pci_dev+0xbc/0x188 [drm]
[77216.744663] [] nouveau_drm_probe+0x180/0x208 [nouveau]
[77216.751354] [] local_pci_probe+0x50/0xb4
[77216.756827] [] pci_device_probe+0xf8/0x148
[77216.762474] [] driver_probe_device+0x284/0x420
[77216.768467] [] __driver_attach+0x120/0x124
[77216.774115] [] bus_for_each_dev+0x6c/0xac
[77216.779673] [] driver_attach+0x2c/0x34
[77216.784972] [] bus_add_driver+0x244/0x2b0
[77216.790531] [] driver_register+0x68/0xfc
[77216.796004] [] __pci_register_driver+0x60/0x6c
[77216.802047] [] drm_pci_init+0x108/0x138 [drm]
[77216.808146] [] nouveau_drm_init+0x158/0x1 [nouveau]
[77216.814922] [] do_one_initcall+0x44/0x128
[77216.820483] [] do_init_module+0x68/0x1e0
[77216.825957] [] load_module+0xfac/0x12bc
[77216.831343] [] SyS_finit_module+0xe4/0xf0
[77216.836902] [] el0_svc_naked+0x24/0x28

By default fedora is using a 64k page kernel, switching to a mainline 
4.9-rc7 kernel using the same configuration the same problem exists 
(there are a couple others, mentioned briefly in the defect). Changing 
the mainline kernel from 64k to 4k pages corrects the problem and a 
terminal display can be seen.


The fedora defect is:
https://bugzilla.redhat.com/show_bug.cgi?id=1400623


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

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Rick Kerkhof]

No, there are not. Here is the recursive directory listing:
http://sprunge.us/FIRE

Op do 27 okt. 2016 11:30 schreef Mika Westerberg <
mika.westerb...@linux.intel.com>:

> On Thu, Oct 27, 2016 at 09:15:19AM +, Rick Kerkhof wrote:
> >I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and
> >power_state contains D3hot.
>
> And there are no power_resources_Dx directories under
> /sys/bus/pci/devices/:00:1c.4/firmware_node?
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH REBASED 2/2] Do not register interface if Apple GMUX detected

[Pierre Moreau]

From: Pierre Moreau 

The Apple GMUX is the one managing the backlight, so there is no need for
Nouveau to register its own backlight interface.

v2: Do not split information message on two lines as it prevents from grepping
it, as pointed out by Lukas Wunner

Signed-off-by: Pierre Moreau 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 0e69612..3c91c24 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -30,6 +30,7 @@
  * Register locations derived from NVClock by Roderick Colenbrander
  */
 
+#include 
 #include 
 #include 
 
@@ -258,6 +259,11 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = >device;
struct drm_connector *connector;
 
+   if (apple_gmux_present()) {
+   NV_INFO(drm, "Apple GMUX detected: not registering Nouveau 
backlight interface");
+   return 0;
+   }
+
INIT_LIST_HEAD(>bl_connectors);
 
list_for_each_entry(connector, >mode_config.connector_list, head) {
-- 
2.10.2

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

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Rick Kerkhof]

Op do 27 okt. 2016 om 11:59 schreef Mika Westerberg <
mika.westerb...@linux.intel.com>:

> On Thu, Oct 27, 2016 at 09:42:28AM +, Rick Kerkhof wrote:
> >No, there are not. Here is the recursive directory listing:
>
> Are you able to try the following patch and send me dmesg (or attach it
> to that bug)? It should show if the ACPI core even tries to add those
> power resources.
>
> diff --git a/drivers/acpi/power.c b/drivers/acpi/power.c
> index fcd4ce6f78d5..af9c3e15dd74 100644
> --- a/drivers/acpi/power.c
> +++ b/drivers/acpi/power.c
> @@ -444,6 +444,9 @@ void acpi_power_add_remove_device(struct acpi_device
> *adev, bool add)
> if (!adev->power.flags.power_resources)
> return;
>
> +   acpi_handle_info(adev->handle, "Adding power resources for %s\n",
> +dev_name(>dev));
> +
> for (state = ACPI_STATE_D0; state <= ACPI_STATE_D3_HOT; state++)
> acpi_power_expose_hide(adev,
>
>  >power.states[state].resources,
>

Thank you for the patch, I have applied it to the kernel sources but I'm
not sure how to proceed from now on. Should I compile the whole kernel or
can I just build an out-of-tree acpi module?
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH v3 1/2] nouveau/bl: Assign different names to interfaces

[Pierre Moreau]

From: Pierre Moreau 

Currently, every backlight interface created by Nouveau uses the same name,
nv_backlight. This leads to a sysfs warning as it tries to create an already
existing folder. This patch adds a incremented number to the name, but keeps
the initial name as nv_backlight, to avoid possibly breaking userspace; the
second interface will be named nv_backlight1, and so on.

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

v2:
* Switch to using ida for generating unique IDs, as suggested by Ilia Mirkin;
* Allocate backlight name on the stack, as suggested by Ilia Mirkin;
* Move `nouveau_get_backlight_name()` to avoid forward declaration, as
  suggested by Ilia Mirkin;
* Fix reference to bug report formatting, as reported by Nick Tenney.

v3:
* Define a macro for the size of the backlight name, to avoid defining
  it multiple times;
* Use snprintf in place of sprintf.

Signed-off-by: Pierre Moreau 
---
 drivers/gpu/drm/nouveau/nouveau_backlight.c | 65 +++--
 drivers/gpu/drm/nouveau/nouveau_display.h   | 10 +
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  2 +
 drivers/gpu/drm/nouveau/nouveau_drv.h   |  1 +
 4 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c 
b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 5e2c568..0e69612 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -31,11 +31,32 @@
  */
 
 #include 
+#include 
 
 #include "nouveau_drv.h"
 #include "nouveau_reg.h"
 #include "nouveau_encoder.h"
 
+static struct ida bl_ida;
+#define BL_NAME_SIZE 15 // 12 for name + 2 for digits + 1 for '\0'
+
+struct backlight_connector {
+   struct list_head head;
+   int id;
+};
+
+static void
+nouveau_get_backlight_name(char backlight_name[BL_NAME_SIZE], struct
+   backlight_connector *connector)
+{
+   const int nb = ida_simple_get(_ida, 0, 0, GFP_KERNEL);
+   if (nb > 0 && nb < 100)
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight%d", nb);
+   else
+   snprintf(backlight_name, BL_NAME_SIZE, "nv_backlight");
+   connector->id = nb;
+}
+
 static int
 nv40_get_intensity(struct backlight_device *bd)
 {
@@ -74,6 +95,8 @@ nv40_backlight_init(struct drm_connector *connector)
struct nvif_object *device = >device.object;
struct backlight_properties props;
struct backlight_device *bd;
+   struct backlight_connector bl_connector;
+   char backlight_name[BL_NAME_SIZE];
 
if (!(nvif_rd32(device, NV40_PMC_BACKLIGHT) & NV40_PMC_BACKLIGHT_MASK))
return 0;
@@ -81,10 +104,16 @@ nv40_backlight_init(struct drm_connector *connector)
memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 31;
-   bd = backlight_device_register("nv_backlight", connector->kdev, drm,
+   nouveau_get_backlight_name(backlight_name, _connector);
+   bd = backlight_device_register(backlight_name , connector->kdev, drm,
   _bl_ops, );
-   if (IS_ERR(bd))
+
+   if (IS_ERR(bd)) {
+   if (bl_connector.id > 0)
+   ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
+   }
+   list_add(_connector.head, >bl_connectors);
drm->backlight = bd;
bd->props.brightness = nv40_get_intensity(bd);
backlight_update_status(bd);
@@ -182,6 +211,8 @@ nv50_backlight_init(struct drm_connector *connector)
struct backlight_properties props;
struct backlight_device *bd;
const struct backlight_ops *ops;
+   struct backlight_connector bl_connector;
+   char backlight_name[BL_NAME_SIZE];
 
nv_encoder = find_encoder(connector, DCB_OUTPUT_LVDS);
if (!nv_encoder) {
@@ -203,11 +234,17 @@ nv50_backlight_init(struct drm_connector *connector)
memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
props.max_brightness = 100;
-   bd = backlight_device_register("nv_backlight", connector->kdev,
+   nouveau_get_backlight_name(backlight_name, _connector);
+   bd = backlight_device_register(backlight_name , connector->kdev,
   nv_encoder, ops, );
-   if (IS_ERR(bd))
+
+   if (IS_ERR(bd)) {
+   if (bl_connector.id > 0)
+   ida_simple_remove(_ida, bl_connector.id);
return PTR_ERR(bd);
+   }
 
+   list_add(_connector.head, >bl_connectors);
drm->backlight = bd;
bd->props.brightness = bd->ops->get_brightness(bd);
backlight_update_status(bd);
@@ -221,6 +258,8 @@ nouveau_backlight_init(struct drm_device *dev)
struct nvif_device *device = >device;
struct drm_connector *connector;
 
+   INIT_LIST_HEAD(>bl_connectors);
+

[Nouveau] [PATCH] drm/nouveau: Add Lenovo P70 to apply_dcb_encoder_quirks

[Hans de Goede]

The Lenono P70's HDMI connector is listed twice, both as DP and as
DVI connector. Ignore the DVI entry, making all ports show up as
DP ports, like on the non-broken P50 model.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_bios.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 23ffe85..ef2e6fd 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -1746,6 +1746,17 @@ apply_dcb_encoder_quirks(struct drm_device *dev, int 
idx, u32 *conn, u32 *conf)
*conn = 0x02000312;
}
 
+   /*
+* Lenovo P70: HMDI connector listed as both DP and DVI,
+* ignore the DVI entry.
+*/
+   if (nv_match_device(dev, 0x13f9, 0x17aa, 0x222d)) {
+   if (idx == 7) {
+   *conn = 0x000f;
+   *conf = 0x;
+   }
+   }
+
return true;
 }
 
-- 
2.9.3

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

[Nouveau] [PATCH 1/2] drm/nouveau: Rename acpi_work to hpd_work

[Hans de Goede]

We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops. For runtime-resume
(which gets called on resume from normal suspend too) we must call
drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock.

Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI
blocks to make it suitable for generic work.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_display.c | 32 +++
 drivers/gpu/drm/nouveau/nouveau_drv.h |  2 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c 
b/drivers/gpu/drm/nouveau/nouveau_display.c
index a0be029..3cd2b8a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_display.c
+++ b/drivers/gpu/drm/nouveau/nouveau_display.c
@@ -359,21 +359,10 @@ static struct nouveau_drm_prop_enum_list dither_depth[] = 
{
}  \
 } while(0)
 
-#ifdef CONFIG_ACPI
-
-/*
- * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
- * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
- * This should be dropped once that is merged.
- */
-#ifndef ACPI_VIDEO_NOTIFY_PROBE
-#define ACPI_VIDEO_NOTIFY_PROBE0x81
-#endif
-
 static void
-nouveau_display_acpi_work(struct work_struct *work)
+nouveau_display_hpd_work(struct work_struct *work)
 {
-   struct nouveau_drm *drm = container_of(work, typeof(*drm), acpi_work);
+   struct nouveau_drm *drm = container_of(work, typeof(*drm), hpd_work);
 
pm_runtime_get_sync(drm->dev->dev);
 
@@ -383,6 +372,17 @@ nouveau_display_acpi_work(struct work_struct *work)
pm_runtime_put_sync(drm->dev->dev);
 }
 
+#ifdef CONFIG_ACPI
+
+/*
+ * Hans de Goede: This define belongs in acpi/video.h, I've submitted a patch
+ * to the acpi subsys to move it there from drivers/acpi/acpi_video.c .
+ * This should be dropped once that is merged.
+ */
+#ifndef ACPI_VIDEO_NOTIFY_PROBE
+#define ACPI_VIDEO_NOTIFY_PROBE0x81
+#endif
+
 static int
 nouveau_display_acpi_ntfy(struct notifier_block *nb, unsigned long val,
  void *data)
@@ -395,9 +395,9 @@ nouveau_display_acpi_ntfy(struct notifier_block *nb, 
unsigned long val,
/*
 * This may be the only indication we receive of a
 * connector hotplug on a runtime suspended GPU,
-* schedule acpi_work to check.
+* schedule hpd_work to check.
 */
-   schedule_work(>acpi_work);
+   schedule_work(>hpd_work);
 
/* acpi-video should not generate keypresses for this */
return NOTIFY_BAD;
@@ -587,8 +587,8 @@ nouveau_display_create(struct drm_device *dev)
}
 
nouveau_backlight_init(dev);
+   INIT_WORK(>hpd_work, nouveau_display_hpd_work);
 #ifdef CONFIG_ACPI
-   INIT_WORK(>acpi_work, nouveau_display_acpi_work);
drm->acpi_nb.notifier_call = nouveau_display_acpi_ntfy;
register_acpi_notifier(>acpi_nb);
 #endif
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 71d4532..0c17ca1 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -163,9 +163,9 @@ struct nouveau_drm {
struct nvbios vbios;
struct nouveau_display *display;
struct backlight_device *backlight;
+   struct work_struct hpd_work;
 #ifdef CONFIG_ACPI
struct notifier_block acpi_nb;
-   struct work_struct acpi_work;
 #endif
 
/* power management */
-- 
2.9.3

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

[Nouveau] Hard-to-find bug brings down whole kernel

[Ognjen Galić]

I have an older Lenovo machine, a T61, with the Nvidia Quadro NVS 140M.
There is this random bug that would hang the whole machine, and then 
cause a

panic and reboot it (the caps lock light is flashing).

I can't get any kernel messages of this issue except the one in this 
YouTube video I had luck to

film and catch the error:

https://www.youtube.com/watch?v=Y1X6s7_laGw

The bug can be triggered always by visiting 
https://www.google.com/chrome when

the animation plays of the Chrome window rotating.

This has been a persistent bug for me from 3.1X all the way to 4.8.12, 
and I've solved
it before by just using the proprietary driver, but I now have trouble 
resuming Linux with that.


I've tried logging the kernel messages over SSH and that did not work 
either, it just locks up.


Anyone has any ideas how to catch the issue without going through the 
whole kdump procedure?


Regards,

Gala


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

[Nouveau] [PATCH 2/2] drm/nouveau: Queue hpd_work on (runtime) resume

[Hans de Goede]

We need to call drm_helper_hpd_irq_event() on resume to properly detect
monitor connection / disconnection on some laptops, use hpd_work for
this to avoid deadlocks.

Signed-off-by: Hans de Goede 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index 3100fd88..b564ab8 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -692,7 +692,12 @@ nouveau_pmops_resume(struct device *dev)
return ret;
pci_set_master(pdev);
 
-   return nouveau_do_resume(drm_dev, false);
+   ret = nouveau_do_resume(drm_dev, false);
+
+   /* Monitors may have been connected / disconnected during suspend */
+   schedule_work(_drm(drm_dev)->hpd_work);
+
+   return ret;
 }
 
 static int
@@ -766,6 +771,10 @@ nouveau_pmops_runtime_resume(struct device *dev)
nvif_mask(>object, 0x088488, (1 << 25), (1 << 25));
vga_switcheroo_set_dynamic_switch(pdev, VGA_SWITCHEROO_ON);
drm_dev->switch_power_state = DRM_SWITCH_POWER_ON;
+
+   /* Monitors may have been connected / disconnected during suspend */
+   schedule_work(_drm(drm_dev)->hpd_work);
+
return ret;
 }
 
-- 
2.9.3

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

[Nouveau] [PATCH 02/39] Annotate hardware config module parameters in arch/x86/mm/

[David Howells]

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in arch/x86/mm/.

Suggested-by: One Thousand Gnomes 
Signed-off-by: David Howells 
cc: Steven Rostedt 
cc: Ingo Molnar 
cc: Thomas Gleixner 
cc: "H. Peter Anvin" 
cc: x...@kernel.org
cc: linux-ker...@vger.kernel.org
cc: nouveau@lists.freedesktop.org
---

 arch/x86/mm/testmmiotrace.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/mm/testmmiotrace.c b/arch/x86/mm/testmmiotrace.c
index 38868adf07ea..f6ae6830b341 100644
--- a/arch/x86/mm/testmmiotrace.c
+++ b/arch/x86/mm/testmmiotrace.c
@@ -9,7 +9,7 @@
 #include 
 
 static unsigned long mmio_address;
-module_param(mmio_address, ulong, 0);
+module_param_hw(mmio_address, ulong, iomem, 0);
 MODULE_PARM_DESC(mmio_address, " Start address of the mapping of 16 kB "
"(or 8 MB if read_far is non-zero).");
 

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

[Nouveau] [PATCH] drm/nouveau: use designated initializers

[Kees Cook]

Prepare to mark sensitive kernel structures for randomization by making
sure they're using designated initializers. These were identified during
allyesconfig builds of x86, arm, and arm64, with most initializer fixes
extracted from grsecurity.

Signed-off-by: Kees Cook 
---
 drivers/gpu/drm/nouveau/nouveau_ttm.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_ttm.c 
b/drivers/gpu/drm/nouveau/nouveau_ttm.c
index a6dbe8258040..ec4668a41e01 100644
--- a/drivers/gpu/drm/nouveau/nouveau_ttm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_ttm.c
@@ -107,10 +107,10 @@ nouveau_vram_manager_new(struct ttm_mem_type_manager *man,
 }
 
 const struct ttm_mem_type_manager_func nouveau_vram_manager = {
-   nouveau_vram_manager_init,
-   nouveau_vram_manager_fini,
-   nouveau_vram_manager_new,
-   nouveau_vram_manager_del,
+   .init = nouveau_vram_manager_init,
+   .takedown = nouveau_vram_manager_fini,
+   .get_node = nouveau_vram_manager_new,
+   .put_node = nouveau_vram_manager_del,
 };
 
 static int
@@ -184,11 +184,11 @@ nouveau_gart_manager_debug(struct ttm_mem_type_manager 
*man, const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nouveau_gart_manager = {
-   nouveau_gart_manager_init,
-   nouveau_gart_manager_fini,
-   nouveau_gart_manager_new,
-   nouveau_gart_manager_del,
-   nouveau_gart_manager_debug
+   .init = nouveau_gart_manager_init,
+   .takedown = nouveau_gart_manager_fini,
+   .get_node = nouveau_gart_manager_new,
+   .put_node = nouveau_gart_manager_del,
+   .debug = nouveau_gart_manager_debug
 };
 
 /*XXX*/
@@ -257,11 +257,11 @@ nv04_gart_manager_debug(struct ttm_mem_type_manager *man, 
const char *prefix)
 }
 
 const struct ttm_mem_type_manager_func nv04_gart_manager = {
-   nv04_gart_manager_init,
-   nv04_gart_manager_fini,
-   nv04_gart_manager_new,
-   nv04_gart_manager_del,
-   nv04_gart_manager_debug
+   .init = nv04_gart_manager_init,
+   .takedown = nv04_gart_manager_fini,
+   .get_node = nv04_gart_manager_new,
+   .put_node = nv04_gart_manager_del,
+   .debug = nv04_gart_manager_debug
 };
 
 int
-- 
2.7.4


-- 
Kees Cook
Nexus Security
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Zheng, Lv]

Hi,

> From: linux-acpi-ow...@vger.kernel.org 
> [mailto:linux-acpi-ow...@vger.kernel.org] On Behalf Of Mika
> Westerberg
> Subject: Re: Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU 
> via Power Resources
> 
> On Fri, Oct 28, 2016 at 02:30:41PM +0200, Peter Wu wrote:
> > It was correctly applied. I did some testing with QEMU, it seems that
> > the \_OSI check is problematic. Removing it makes things work again.
> 
> I hope Bob and Lv can answer why _OSI fails.
> 
> In the meantime I think we should check flags.power_resources in nouveau
> driver (in addition to _PR3) so that it falls back to _DSM if there are
> no power resources (or if we failed to evaluate them for some reason).

IMO, the problem wasn't _OSI, the problem was "If".
"If" is module level here.
So execution order of it in current Linux upstream may be different from 
Windows.

You can try to modify acpi_gbl_parse_table_as_term_list to TRUE.
To see if this can be solved.

Thanks and best regards
Lv

> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Rick Kerkhof]

I can confirm what Peter said, path contains \_SB_.PCI0.RP05 and
power_state contains D3hot.

Op do 27 okt. 2016 11:06 schreef Peter Wu :

> On Thu, Oct 27, 2016 at 11:17:48AM +0300, Mika Westerberg wrote:
> > On Thu, Oct 27, 2016 at 12:56:41AM +0200, Peter Wu wrote:
> > > Hi PCI/ACPI PM experts,
> > >
> > > Since Linux 4.8, nouveau switched to rely on the PCIe port driver to
> > > transition to D3cold. This however does not happen for an Acer Aspire
> > > V7-582PG (Haswell, NVIDIA GTX 750M) from Rick.
> > >
> > > Any idea why? acpidump, lspci, dmesg and other details can be found in
> > > the linked bug below.
> >
> > >
> > > Kind regards,
> > > Peter
> > >
> > > On Wed, Oct 26, 2016 at 10:42:07PM +,
> bugzilla-dae...@freedesktop.org wrote:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=98398
> > > >
> > > > --- Comment #11 from Peter Wu  ---
> > > > So 4.7 and before used the "DSM" method on runtime-suspend:
> > > > - \_SB.PCI0.RP05.PEGP._DSM would be invoked to enable Optimus
> > > > - \_SB.PCI0.RP05.PEGP._PS3 is then invoked which would enter D3cold
> > > > (note, this method is still used in 4.8 on older laptops or with the
> > > > pcie_pm_port=off kernel option)
> > > >
> > > > Since 4.8, _DSM is not called anymore by nouveau (when support from
> the PCI
> > > > core is detected) and this sequence should instead happen:
> > > > - \_SB.PCI0.RP05.PEGP._PS3 (does nothing besides updating _STA)
> > > > - PCIe core removes power for the PCIe port since all its children
> are in
> > > >   D3 and are willing to transition to D3cold. It does so by invoking
> > > >   \NVP3._OFF (where \NVP3 is the power resource from
> \_SB.PCI0.RP05._PR3)
> > > >
> > > > That is how I think it should work in theory, but on Ricks laptop
> running
> > > > 4.8.4,
> > > > /sys/bus/devices/:1c.4/firmware_node/ does not have
> power_resources_D0
> > > > devices (which I do have on my own laptop for :01:0).
> > > >
> > > > The SSDT1 of Rick's Acer laptop shows this structure:
> > > >
> > > > If (\_OSI ("Windows 2013"))
> > > > {
> > > > Scope (\_SB.PCI0.RP05)
> > > > {
> > > > //...
> > > > Name (_PR0, Package (0x01)  // _PR0: Power Resources for
> D0
> > > > {
> > > > NVP3
> > > > })
> > > > Name (_PR2, Package (0x01)  // _PR2: Power Resources for
> D2
> > > > {
> > > > NVP2
> > > > })
> > > > Name (_PR3, Package (0x01)  // _PR3: Power Resources for
> D3hot
> > > > {
> > > > NVP3
> > > > })
> > > > // ...
> > > > Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
> > > > {
> > > > }
> > > >
> > > > Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
> > > > {
> > > > }
> > > > }
> > > >
> > > > Name (MSD3, Zero)
> > > > PowerResource (NVP3, 0x00, 0x)
> > > > {
> > > > Name (_STA, One)  // _STA: Status
> > > > // ...
> > > >
> > > > Method (_ON, 0, NotSerialized)  // _ON_: Power On
> > > > {
> > > > // ...
> > > > }
> > > >
> > > > Method (_OFF, 0, NotSerialized)  // _OFF: Power Off
> > > > {
> > > > // ...
> > > > }
> > > > }
> > > >
> > > > The dmesg does show "ACPI: Power Resource [NVP3] (on)", so I guess
> that the
> > > > methods are found. It is a mystery to me why the
> "power_resources_Dx" files are
> > > > not created, possibly breaking PM.
> >
> > The ASL code looks right to me (except for the NVP2 which never set _STA
> > to 0 but should not affect here).
> >
> > I wonder what does /sys/bus/pci/devices/:00:1c.4/firmware_node/path
> contain?
>
> The value is as expected, \_SB.PCI0.RP05:
>
> /sys/bus/pci/devices/:00:1c.4/firmware_node/path:\_SB_.PCI0.RP05
> /sys/bus/pci/devices/:00:1c.4/firmware_node/power_state:D3hot
> --
> Kind regards,
> Peter Wu
> https://lekensteyn.nl
>
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [PATCH] drm/nouveau: fix unknown chipset for GTX 1060

[Chris Chiu]

Nouveau driver shows unknown chipset (136000a1) for GTX 1060, so it
only gives VGA resolution on screen. Use the same chipset as nv134
then it shows FullHD. This commit copies fields from nv134_chipset
to nv136_chipset for GTX 1060.

Signed-off-by: Chris Chiu 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/base.c | 29 +++
 1 file changed, 29 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
index 7218a06..7c6eece 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/base.c
@@ -2209,6 +2209,34 @@ nv134_chipset = {
.fifo = gp100_fifo_new,
 };
 
+static const struct nvkm_device_chip
+nv136_chipset = {
+   .name = "GP104",
+   .bar = gf100_bar_new,
+   .bios = nvkm_bios_new,
+   .bus = gf100_bus_new,
+   .devinit = gm200_devinit_new,
+   .fb = gp104_fb_new,
+   .fuse = gm107_fuse_new,
+   .gpio = gk104_gpio_new,
+   .i2c = gm200_i2c_new,
+   .ibus = gm200_ibus_new,
+   .imem = nv50_instmem_new,
+   .ltc = gp100_ltc_new,
+   .mc = gp100_mc_new,
+   .mmu = gf100_mmu_new,
+   .pci = gp100_pci_new,
+   .timer = gk20a_timer_new,
+   .top = gk104_top_new,
+   .ce[0] = gp104_ce_new,
+   .ce[1] = gp104_ce_new,
+   .ce[2] = gp104_ce_new,
+   .ce[3] = gp104_ce_new,
+   .disp = gp104_disp_new,
+   .dma = gf119_dma_new,
+   .fifo = gp100_fifo_new,
+};
+
 static int
 nvkm_device_event_ctor(struct nvkm_object *object, void *data, u32 size,
   struct nvkm_notify *notify)
@@ -2644,6 +2672,7 @@ nvkm_device_ctor(const struct nvkm_device_func *func,
case 0x12b: device->chip = _chipset; break;
case 0x130: device->chip = _chipset; break;
case 0x134: device->chip = _chipset; break;
+   case 0x136: device->chip = _chipset; break;
default:
nvdev_error(device, "unknown chipset (%08x)\n", boot0);
goto done;
-- 
2.1.4

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

[Nouveau] How to disable L2 cache on Nvidia GPUs

[Vishwas .]

Hi, 
I would like to know, is there a low level command / instruction to disable the L2 cache in Nvidia GPUs(Kepler and above arch). 
Can a certain section of RAM be made non cacheable. L2 has write back policy which I don't need. 
If there is a way can you please give me a pointer on how to handle it. 
Can anyone help me please.
Thank you,
Vishwas

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

Re: [Nouveau] [PATCH] acpi: video: Move ACPI_VIDEO_NOTIFY_* defines to acpi/video.h

[Rafael J. Wysocki]

On Wednesday, November 09, 2016 06:15:56 PM Hans de Goede wrote:
> acpi_video.c passed the ACPI_VIDEO_NOTIFY_* defines as type code to
> acpi_notifier_call_chain(). Move these defines to acpi/video.h so
> that acpi_notifier listeners can check the type code using these
> defines.
> 
> Signed-off-by: Hans de Goede 

I've applied this one, but I'd like to get an ACK from the DRM folks on
the second one.

Thanks,
Rafael

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

[Nouveau] Fan speed control Nvidia GeForce GTX 760

[ilje]

hi i have problem with nouveau drivers gpu fan always runs at maximum speed
my pc OS: fedora 25 wayland/xorg
lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX
760] (rev a1) (prog-if 00 [VGA controller])
Subsystem: CardExpert Technology Device 1187
Flags: bus master, fast devsel, latency 0, IRQ 29
Memory at f600 (32-bit, non-prefetchable) [size=16M]
Memory at e800 (64-bit, prefetchable) [size=128M]
Memory at f000 (64-bit, prefetchable) [size=32M]
I/O ports at e000 [size=128]
Expansion ROM at 000c [disabled] [size=128K]
Capabilities: [60] Power Management version 3
Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [78] Express Endpoint, MSI 00
Capabilities: [b4] Vendor Specific Information: Len=14 
Capabilities: [100] Virtual Channel
Capabilities: [128] Power Budgeting 
Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 
Capabilities: [900] #19
Kernel driver in use: nouveau
Kernel modules: nouveau

nouveau-pci-0100
Adapter: PCI adapter
GPU core: +0.85 V  (min =  +0.82 V, max =  +1.21 V)
fan1:2280 RPM
temp1:+34.0°C  (high = +95.0°C, hyst =  +3.0°C)
   (crit = +105.0°C, hyst =  +5.0°C)
   (emerg = +135.0°C, hyst =  +5.0°C)
power1:9.01 W
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] Acer Aspire V7-582PG (Haswell, GTX 750M) fails to power off GPU via Power Resources

[Rick Kerkhof]

Op do 27 okt. 2016 om 12:12 schreef Mika Westerberg <
mika.westerb...@linux.intel.com>:

> On Thu, Oct 27, 2016 at 10:07:45AM +, Rick Kerkhof wrote:
> >Thank you for the patch, I have applied it to the kernel sources but
> >I'm not sure how to proceed from now on. Should I compile the whole
> >kernel or can I just build an out-of-tree acpi module?
>
> You need to build the whole kernel, install and reboot.
>

Thanks, it's compiling now, I'll take it for a test drive once it is done
and installed and provide you with a dmesg log.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

Re: [Nouveau] [PATCH] drm/nouveau/acpi: fix check for power resources support

[Rick Kerkhof]

Op za 29 okt. 2016 om 01:40 schreef Peter Wu :

> Check whether the kernel really supports power resources for a device,
> otherwise the power might not be removed when the device is runtime
> suspended (DSM should still work in these cases where PR does not).
>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
> Fixes: 692a17dcc292 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
> Signed-off-by: Peter Wu 
> ---
> Hi,
>
> Maybe Cc: stable (4.8+)?
>
> Compile-tested only. Rick, can you test if this patch fixes the problem
> for you?
>
> This check was actually in the original patch, but it was changed:
> https://lists.freedesktop.org/archives/nouveau/2016-May/025125.html
> Re-adding the check as suggested by Mika.
>
> Kind regards,
> Peter
> ---
>  drivers/gpu/drm/nouveau/nouveau_acpi.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> index dc57b62..193573d 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_acpi.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_acpi.c
> @@ -240,7 +240,8 @@ static bool nouveau_pr3_present(struct pci_dev *pdev)
> if (!parent_adev)
> return false;
>
> -   return acpi_has_method(parent_adev->handle, "_PR3");
> +   return parent_adev->power.flags.power_resources &&
> +   acpi_has_method(parent_adev->handle, "_PR3");
>  }
>
>  static void nouveau_dsm_pci_probe(struct pci_dev *pdev, acpi_handle
> *dhandle_out,
> --
> 2.10.1
>
> Hi Peter,

This patch indeed does fix the issue for me, thank you.

Kind regards,
Rick

Tested-by: Rick Kerkhof 
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/nouveau

[Nouveau] [Bug 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #7 from Gleb  ---
lspci doesn't hang when I invoke it from console. I also tried startx and
startxfce4 from console and it worked, so it probably some other thing?


I can confirm that the issue occured on 4.9.0 and did not occur on 4.8.14 on
the same userspace stuff. I only started upgrading it after multiple
unseccessfull reboots into 4.9.0. So I had stable stuff, tested 4.8.14 (no
problem) and 4.9.0 (problem persist). Then upgraded stuff, tested on 4.8.14 (no
problem) and 4.9.0 (problem persist).


I also recompiled 4.9.0 at some point before testing lspci (but not
specifically for that, I will try to revert the changes) so that it includes
nouveau into kernel and not as a module, though it still have the same issue.
Does it matter in what form nouveau is presented?


I want to clarify that the only process that hangs is Xorg (and probably
another which I noticed right now -- libvirtd, it also has red D symbol). The
system continue to work, I have access to console and can run stuff from there.

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #6 from Peter Wu  ---
Nothing unusual in logs. Can you reproduce the lockup issue if you boot to a
console (disable sddm), then invoke "lspci", wait for at least 5 seconds, then
repeat "lspci" again? (Have a look at dmesg for unusual messages.)

If lspci hangs, then there is a problem (and hopefully dmesg is more helpful).
Can you also confirm that downgrading just the kernel (while keeping the rest
of userspace the same) makes the problem disappear?

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #5 from Gleb  ---
Well, I may need some guide or a at least some sort of explanation (probably
short) what to do as this is completely new for me. Will this guide work for
this task?
https://wiki.gentoo.org/wiki/Kernel_git-bisect

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #4 from Karol Herbst  ---
(In reply to Gleb from comment #3)
> Yes, kernel boots with this option. The only disadvantage is that in this
> case nvidia GPU will always stay powered on, probably could be solved with
> bbswitch.

bbswitch won't help if nouveau is loaded.

If this is indeed a regression in 4.9, could you try and bisect this?

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #3 from Gleb  ---
Yes, kernel boots with this option. The only disadvantage is that in this case
nvidia GPU will always stay powered on, probably could be solved with bbswitch.

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #2 from Karol Herbst  ---
does booting with nouveau not blacklisted and with "nouveau.runpm=0" help?

-- 
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 99147] xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

--- Comment #1 from Gleb  ---
Created attachment 128564
  --> https://bugs.freedesktop.org/attachment.cgi?id=128564=edit
kernel syslog

-- 
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 99147] New: xorg hangs at initial startup on linux-4.9.0

[bugzilla-daemon]

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

Bug ID: 99147
   Summary: xorg hangs at initial startup on linux-4.9.0
   Product: xorg
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Driver/nouveau
  Assignee: nouveau@lists.freedesktop.org
  Reporter: g...@fastmail.com
QA Contact: xorg-t...@lists.x.org

Created attachment 128563
  --> https://bugs.freedesktop.org/attachment.cgi?id=128563=edit
nouveau

The issue start to appear after upgrading to Kernel 4.9.0. Before that, on
4.8.14 everything seems to be fine.

I have Lenovo B560 laptop with Intel Core i5 560M and Iron Lake GPU, Nvidia
310M, so it's an Optimus laptop. I have external monitor connected to HDMI
port.

Components when the probelm could be reproduced:
- gentoo almost stable
- mesa 12.0.1 or 13.0.2;
- libdrm 2.4.68 or 2.4.73
- xorg 1.18.4 or 1.19.0
- intel xf86 driver snapshot or modesetting driver
- nouveau 1.0.12 or 1.0.13
- libinput 1.5.3, libevdev 1.5.2
- xfce, polkit, consolekit, dbus, etc.


So just after all services started and lightdm expected to appear with login
screen, instead I can only see console login screen and nothing appears on tty7
also.

Xorg.log.0 shows no errors, dmesg is also empy (even with debug level 4). I
can't reboot system after that as Xorg has red D symbol and cannot be killed,
so SysRq is used.

I blacklisted nouveau driver and it helped, so I can boot to the system
normally and after that I can load the nouveau module manually and even restart
Xorg.

Xorg.log.0 hangs on the following item:
[14.361] (II) xfree86: Adding drm device (/dev/dri/card1)

syslog kernel with nouveau filtered (only one time I enabled debug level when
the I had the problem).

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