If anyone cares, this is still 100% reproducible with 4.4.5-1-ARCH.

Still happening with 4.5.1.

Should I report against kernel or is here the right place?

(In reply to bruno.pagani from comment #2)
> Still happening with 4.5.1.
> 
> Should I report against kernel or is here the right place?

The right place. Please try a) v4.6-rc5, b) i915.enable_psr=0 module parameter.

On my current system, enable_psr is already at 0 (default value before 4.6, right?).

I’ve never compiled a kernel before, but will look around this during the WE and report.

I could be affected too by this issue!

If I close the lid nothing happens
or better doesn't happen what I expect: pc goes suspend

I attach the journalctl log. (If you need, I can attach the full log, as well as I can provide further info)

I'm on Dell XPS 13 (9343) (broadwell i5) attached to an external monitor
Arch Linux x86_64
gnome 3.20.2
latest intel driver

PS: this issue has started times (maybe 3 weeks) ago

Created attachment 124230 [details]
journalctl

Sorry for the huge delay, I finally didn’t have anytime to look into kernel compiling, but 4.6 just landed in ArchLinux.

The good news is that “i915 0000:00:02.0: BAR 6: [??? 0x00000000 flags 0x2] has bogus alignment” are gone.

The bad news is that the screen is still black on lid open. Of course, any key or mouse move bring it back to life, but that’s still not ideal.

Also, now that I have psr by default, there is a difference if I don’t disable it: instead of my desktop, after escaping the black screen, I face the screen state at session opening — that is, my login manager (SDDM) with my password in (bullet-style of course) and validated, with the clock time of the actual session opening. Here again, any key press returns to the normal situation — but that’s definitively not what should be the normal behaviour.

The log excerpt haven’t changed outside of the i915 lines being gone, but here they are just in case (psr doesn’t play any role here):

[  336.913452] pci_bus 0000:04: Allocating resources
[  336.913465] pci_bus 0000:06: Allocating resources
[  336.913478] pcieport 0000:00:1c.2: bridge window [io  0x1000-0x0fff] to [bus 06] add_size 1000
[  336.913480] pcieport 0000:00:1c.2: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 06] add_size 200000 add_align 100000
[  336.913485] pci_bus 0000:07: Allocating resources
[  336.913494] pcieport 0000:00:1c.3: bridge window [io  0x1000-0x0fff] to [bus 07] add_size 1000
[  336.913496] pcieport 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 07] add_size 200000 add_align 100000
[  336.913500] pcieport 0000:00:1c.2: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  336.913502] pcieport 0000:00:1c.2: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  336.913503] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  336.913504] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[  336.913505] pcieport 0000:00:1c.2: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[  336.913507] pcieport 0000:00:1c.2: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[  336.913508] pcieport 0000:00:1c.3: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[  336.913509] pcieport 0000:00:1c.3: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[  336.913516] pcieport 0000:00:1c.2: BAR 15: assigned [mem 0xcf600000-0xcf7fffff 64bit pref]
[  336.913531] pcieport 0000:00:1c.3: BAR 15: assigned [mem 0xcf800000-0xcf9fffff 64bit pref]
[  336.913534] pcieport 0000:00:1c.2: BAR 13: assigned [io  0x3000-0x3fff]
[  336.913535] pcieport 0000:00:1c.3: BAR 13: assigned [io  0x4000-0x4fff]
[  336.982273] pci_bus 0000:02: Allocating resources
[  338.487575] pci_bus 0000:04: Allocating resources
[  338.487589] pci_bus 0000:06: Allocating resources
[  338.487613] pci_bus 0000:07: Allocating resources
[  338.555659] pci_bus 0000:02: Allocating resources

[  381.539354] pci_bus 0000:04: Allocating resources
[  381.539370] pci_bus 0000:06: Allocating resources
[  381.539389] pci_bus 0000:07: Allocating resources
[  381.610463] pci_bus 0000:02: Allocating resources
[  382.993490] pci_bus 0000:04: Allocating resources
[  382.993513] pci_bus 0000:06: Allocating resources
[  382.993528] pci_bus 0000:07: Allocating resources
[  383.063902] pci_bus 0000:02: Allocating resources

(In reply to bruno.pagani from comment #7)
> The bad news is that the screen is still black on lid open. Of course, any
> key or mouse move bring it back to life, but that’s still not ideal.

Does your machine suspend/resume on lid close/open? In particular, I can't tell if the lid open problem is that your machine doesn't resume or that your machine resumes but display stays black until you hit a key or move mouse.

> Also, now that I have psr by default, there is a difference if I don’t
> disable it: instead of my desktop, after escaping the black screen, I face
> the screen state at session opening — that is, my login manager (SDDM) with
> my password in (bullet-style of course) and validated, with the clock time
> of the actual session opening. Here again, any key press returns to the
> normal situation — but that’s definitively not what should be the normal
> behaviour.

You mean that when the display comes back, it initially contains a stale image back from when you last entered your password in the login screen?

My machine does suspend/resume on lid close/open only if on battery, which isn’t the case for all my tests here. So all I describe is when plugged on AC, and there isn’t anything suspend related here. ;)

On lid close, the screen goes black, which is expected. Then, on lid open, it stays black until I hit a key or move mouse, which is the issue I’m reporting.

And for the second point (with PSR enabled), it’s exactly that you described. After hitting a key or moving the mouse a first time, the screen isn’t black anymore, but « contains a stale image back from when I last entered my password in the login screen », which also disappear when hitting a key or moving the mouse. Sorry if I wasn’t very clear in my previous message, english isn’t my mother tongue at all.

To be a bit more exhaustive, I’ve tried on battery. Lid close, screen goes black and computer suspend. Lid open, nothing happens (which might be an issue in fact, but probably for a different report — I expect my computer to resume on lid open). Power button: resumes directly to the lock screen, without any black screen or stale image.

In dmesg, I have this on lid close:
[ 6789.942085] pci_bus 0000:04: Allocating resources
[ 6789.942121] pci_bus 0000:06: Allocating resources
[ 6789.942168] pcieport 0000:00:1c.2: bridge window [io  0x1000-0x0fff] to [bus 06] add_size 1000
[ 6789.942176] pcieport 0000:00:1c.2: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 06] add_size 200000 add_align 100000
[ 6789.942188] pci_bus 0000:07: Allocating resources
[ 6789.942291] pcieport 0000:00:1c.3: bridge window [io  0x1000-0x0fff] to [bus 07] add_size 1000
[ 6789.942299] pcieport 0000:00:1c.3: bridge window [mem 0x00100000-0x000fffff 64bit pref] to [bus 07] add_size 200000 add_align 100000
[ 6789.942319] pcieport 0000:00:1c.2: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[ 6789.942327] pcieport 0000:00:1c.2: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[ 6789.942334] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x000fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[ 6789.942341] pcieport 0000:00:1c.3: res[15]=[mem 0x00100000-0x002fffff 64bit pref] res_to_dev_res add_size 200000 min_align 100000
[ 6789.942349] pcieport 0000:00:1c.2: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[ 6789.942356] pcieport 0000:00:1c.2: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[ 6789.942363] pcieport 0000:00:1c.3: res[13]=[io  0x1000-0x0fff] res_to_dev_res add_size 1000 min_align 1000
[ 6789.942371] pcieport 0000:00:1c.3: res[13]=[io  0x1000-0x1fff] res_to_dev_res add_size 1000 min_align 1000
[ 6789.942408] pcieport 0000:00:1c.2: BAR 15: assigned [mem 0xcf600000-0xcf7fffff 64bit pref]
[ 6789.942436] pcieport 0000:00:1c.3: BAR 15: assigned [mem 0xcf800000-0xcf9fffff 64bit pref]
[ 6789.942449] pcieport 0000:00:1c.2: BAR 13: assigned [io  0x3000-0x3fff]
[ 6789.942459] pcieport 0000:00:1c.3: BAR 13: assigned [io  0x4000-0x4fff]
[ 6790.016680] pci_bus 0000:02: Allocating resources

Then suspend/resume stuff, but the second part (from other messages here) isn’t present, which I kind of expect since no black screen. However, any further lid close (whether on battery or AC) leads to the same first part as other second attempts:
[ 6880.004203] pci_bus 0000:04: Allocating resources
[ 6880.004231] pci_bus 0000:06: Allocating resources
[ 6880.004262] pci_bus 0000:07: Allocating resources
[ 6880.075329] pci_bus 0000:02: Allocating resources

And when on AC (nothing on battery), on lid open:
[ 6881.087919] pci_bus 0000:04: Allocating resources
[ 6881.087955] pci_bus 0000:06: Allocating resources
[ 6881.087992] pci_bus 0000:07: Allocating resources
[ 6881.159286] pci_bus 0000:02: Allocating resources

I suspect that if it was resuming on lid open, the black screen issue could be present too.

Just thought I should let you know that I have another laptop affected (an old Dell Latitude, currently running Ubuntu 16.04 with a 4.4 kernel, so that one still has the “bogus alignment” messages).

Also, since I’ve started running 4.6 on my main laptop, I’ve found a very strange issue related to all this: before the first lid close/open cycle, setting the screen brightness has no effect and the system never goes into PC6. After that cycle, setting the brightness works and the system goes into PC6 again when it can. So, this bug have moved from “some annoying lines in dmesg+one event needed to get the screen back“ to a much bigger thing.

Maybe this is the same issue?

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

Ref that bug I posted, have you guys tested booting with intel_iommu=igfx_off ?

Suspend works now on my XPS 15 9550 :)

No change for me using intel_iommu=igfx_off.

However, I’ve a bit more precisions regarding the situation: no resuming from suspend on lid open seems to be fixed, while the brightness/power saving issue is still present but also goes way when the screen goes black because of inactivity, not only on lid open/close.

So this might be a separate issue, I can open another bug report for this one if you want. The bug is in a NEEDINFO state for ages: did I missed something that you would want to know?

Bruno yes please open a new bug for the other issue, this bug will be closed. Sorry for the so late reponse.

Why closed? The issue main is not fixed. I’ll open a new one for the backlight bug, but I’m still having a stale screen from my login manager when doing a lid close/open cycle (not sure about the black screen, it seems to be here but goes away very fast, will recheck with next boot).

(In reply to Bruno Pagani from comment #9)
> On lid close, the screen goes black, which is expected. Then, on lid open,
> it stays black until I hit a key or move mouse, which is the issue I’m
> reporting.

NOTOURBUG seems more appropriate.

If it’s not your bug, who’s one it is? Where should I report it?

(In reply to Bruno Pagani from comment #17)
> If it’s not your bug, who’s one it is? Where should I report it?

That would depend on whether the machine wakes up from suspend on lid open. If yes, I think it's in your desktop environment or thereabouts. If not, the lid open is not a wakeup source for your machine, and I'm not even sure where that should happen.

Like I’ve said in https://bugs.freedesktop.org/show_bug.cgi?id=93555#c13, waking up on lid open is fixed.

What remains is:

– a black screen;
– an additional stale image from login manager when PSR is enabled.

So you would say this is DE dependent? Interesting, I’ll have to look a bit more into that.

Regarding backlight, I’ve filed https://bugzilla.kernel.org/show_bug.cgi?id=194675.

(In reply to Bruno Pagani from comment #19)
> Like I’ve said in https://bugs.freedesktop.org/show_bug.cgi?id=93555#c13,
> waking up on lid open is fixed.
> 
> What remains is:
> 
> – a black screen;
> – an additional stale image from login manager when PSR is enabled.
> 
> So you would say this is DE dependent? Interesting, I’ll have to look a bit
> more into that.

The kernel driver does not enable the displays on its own upon resume. The userspace has to ask for it.

> Regarding backlight, I’ve filed
> https://bugzilla.kernel.org/show_bug.cgi?id=194675.

Is it an ACPI backlight you have? What does 'ls /sys/class/backlight' say?

(In reply to Jani Nikula from comment #20)
> (In reply to Bruno Pagani from comment #19)
> > Like I’ve said in https://bugs.freedesktop.org/show_bug.cgi?id=93555#c13,
> > waking up on lid open is fixed.
> > 
> > What remains is:
> > 
> > – a black screen;
> > – an additional stale image from login manager when PSR is enabled.
> > 
> > So you would say this is DE dependent? Interesting, I’ll have to look a bit
> > more into that.
> 
> The kernel driver does not enable the displays on its own upon resume. The
> userspace has to ask for it.

I see. I suppose userspace is responsible for turning the display off on lid close too? What about the stale image in PSR case? Is this a PSR bug? Device specific?

> > Regarding backlight, I’ve filed
> > https://bugzilla.kernel.org/show_bug.cgi?id=194675.
> 
> Is it an ACPI backlight you have? What does 'ls /sys/class/backlight' say?

Not ACPI, intel_backlight.

(In reply to Bruno Pagani from comment #21)
> I see. I suppose userspace is responsible for turning the display off on lid
> close too? What about the stale image in PSR case? Is this a PSR bug? Device
> specific?

Please file PSR bugs on DRM/Intel in this bugzilla.

> 
> > > Regarding backlight, I’ve filed
> > > https://bugzilla.kernel.org/show_bug.cgi?id=194675.
> > 
> > Is it an ACPI backlight you have? What does 'ls /sys/class/backlight' say?
> 
> Not ACPI, intel_backlight.

Please file intel_backlight bugs on DRM/Intel in this bugzilla.

(In reply to Jani Nikula from comment #22)
> (In reply to Bruno Pagani from comment #21)
> > I see. I suppose userspace is responsible for turning the display off on lid
> > close too? What about the stale image in PSR case? Is this a PSR bug? Device
> > specific?
> 
> Please file PSR bugs on DRM/Intel in this bugzilla.

OK.

> > 
> > > > Regarding backlight, I’ve filed
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=194675.
> > > 
> > > Is it an ACPI backlight you have? What does 'ls /sys/class/backlight' say?
> > 
> > Not ACPI, intel_backlight.
> 
> Please file intel_backlight bugs on DRM/Intel in this bugzilla.

What about the PC6 part? It could be an issue caused by DRM/Intel too?