Still not working with kernel 4.6.3

Please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. Add drm.debug=14 module parameter, and attach dmesg all the way from boot to the problem. Do not add nomodeset for this.

(In reply to Philip Fackler from comment #0)
> See posts:
> https://bbs.archlinux.org/viewtopic.php?id=209853
> https://bbs.archlinux.org/viewtopic.php?id=208652
> I believe the original poster on the second thread there was having a
> different issue.

The first thread is about Broadwell, and you have Braswell/Cherrytrail, they are all probably different issues.

(In reply to Jani Nikula from comment #2)
> Please try drm-intel-nightly branch of
> http://cgit.freedesktop.org/drm-intel. Add drm.debug=14 module parameter,
> and attach dmesg all the way from boot to the problem. Do not add nomodeset
> for this.

Forgive me, but I'm going to need more detailed instructions for how to do install and test this.

(In reply to Philip Fackler from comment #4)
> (In reply to Jani Nikula from comment #2)
> > Please try drm-intel-nightly branch of
> > http://cgit.freedesktop.org/drm-intel. Add drm.debug=14 module parameter,
> > and attach dmesg all the way from boot to the problem. Do not add nomodeset
> > for this.
> 
> Forgive me, but I'm going to need more detailed instructions for how to do
> install and test this.

Just to set the record straight, generally the expectation for the upstream bugzilla is that you are able to configure, build and install your own kernels. And this is not the support line for that.

This might be a good place for generic advice http://kernelnewbies.org/KernelBuild, and there seem to be similar things for Arch at https://wiki.archlinux.org/index.php/Kernels and https://wiki.archlinux.org/index.php/Kernels/Traditional_compilation.

HTH.

This is with late KMS start. I didn't see anything that's obviously an error message, so I copied the whole log.
http://pastebin.com/GsRJS8kr

(In reply to Philip Fackler from comment #6)
> This is with late KMS start. I didn't see anything that's obviously an error
> message, so I copied the whole log.
> http://pastebin.com/GsRJS8kr

Please always attach the logs to bugzilla. (See "Add an attachment" near the top.)

You don't seem to have i915 loaded at all there. Please make sure you do that.

(In reply to Jani Nikula from comment #7)
> You don't seem to have i915 loaded at all there. Please make sure you do
> that.

Well, the screen still blacked out. If I mkinitcpio with i915 in the modules list, the log isn't even kept. Do you know of a way to save the log early?

Still won't work on 4.7.1.

(In reply to Philip Fackler from comment #9)
> Still won't work on 4.7.1.

So I was hoping to hear the results on drm-intel-nightly, or at least v4.8-rc3.

Created attachment 126050 [details]
dmesg output from drm-intel-nightly 4.8-rc3

Hi,
I may have some additional information for you. My device is Asus T100HA with Intel Atom x5-Z8500 and Intel HD Graphics Gen 8-LP. The symptoms are the same – with kms the screen turns black until reboot. I attached dmesg form kernel build from yesterdays drm-intel-nightly code (30de872fd5cf71a51994375fb4f76856c05b1c4c). There are several timeouts, so I guess there could some problem with some irq. The result is the same as if start with nomodest and reload the i915 module with modeset=1. I`ve tried to find what could be wrong but the code is too unknown for me. Please let me know if I can provide some more diagnostics, test some patches etc. I`ll be happy to help to make this work.

Thanks

Pavel

(In reply to Jani Nikula from comment #7)
> (In reply to Philip Fackler from comment #6)
> > http://pastebin.com/GsRJS8kr
> 
> Please always attach the logs to bugzilla. (See "Add an attachment" near the
> top.)

*sigh* now the pastebin is already gone.

Pavel, unfortunately there's not enough information to confirm you actually have the same issue even. Would you mind filing a new bug, so we can debug from the clean slate, with just the symptoms you have?

> Pavel, unfortunately there's not enough information to confirm you actually
> have the same issue even. Would you mind filing a new bug, so we can debug
> from the clean slate, with just the symptoms you have?

OK, done - it is bug 97529.

Thank you

Pavel

Comment on attachment 126050 [details]
dmesg output from drm-intel-nightly 4.8-rc3

Marking the logs from Pavel obsolete, tracked at another bugzilla.

Philip, how about that dmesg with drm.debug=14 from you, please?

As I indicated in a previous comment, I don't know how to generate any more information than what I already have. Let me bring it up again:

(In reply to Philip Fackler from comment #8)
> (In reply to Jani Nikula from comment #7)
> > You don't seem to have i915 loaded at all there. Please make sure you do
> > that.
> 
> Well, the screen still blacked out. If I mkinitcpio with i915 in the modules
> list, the log isn't even kept. Do you know of a way to save the log early?

I'm sorry I don't know much about all this.

(In reply to Philip Fackler from comment #17)
> As I indicated in a previous comment, I don't know how to generate any more
> information than what I already have. Let me bring it up again:
> 
> (In reply to Philip Fackler from comment #8)
> > (In reply to Jani Nikula from comment #7)
> > > You don't seem to have i915 loaded at all there. Please make sure you do
> > > that.
> > 
> > Well, the screen still blacked out. If I mkinitcpio with i915 in the modules
> > list, the log isn't even kept. Do you know of a way to save the log early?
> 
> I'm sorry I don't know much about all this.

The problem is, even if we came up with a candidate fix, you wouldn't be able to verify it. I'm tempted to just close this bug, and suggest you file a bug with your distro.

Created attachment 126916 [details]
kernel messages for 4.3.3 kernel with late KMS

The attached is the output for the kernel version that works well (perhaps it will give some insight, probably not). When I do the same thing to run your 4.7 kernel, none of the [drm] messages show up. I've tried multiple combinations of kernel parameters to try to log everything possible, but I can't figure out how to make the drm messages show up. And with early KMS, I get no log at all! It doesn't even exist. Even though I can see output on screen before the screen goes blank, as far as journald is concerned that boot never happened.

Jani the submitted added logs, it has been several months and in one of your comments you hinted that maybe this should be closed... what can be the next steps here?

I also filed a bug with Arch Linux (https://bugs.archlinux.org/task/50604), but nothing has been done with it there. If someone could tell me how to get debug messages out of the boot, I'd be happy to send those. As I lamented in my previous comment, I've been unable so far to get anything logged when the problem occurs.

The logs on this bug are on a working 1½ years old kernel. How am I supposed to extrapolate what goes wrong with later kernels based on that?

All I can do is to suggest trying latest kernels. Like the just released v4.10 or building the drm-tip branch from https://cgit.freedesktop.org/drm-tip.

I didn't expect you to extrapolate from that. I expected you to know how I could get log messages from a recent kernel (as I have repeatedly asked). It just so happens that 1 1/2 years is how long I've been unable to update my kernel. Are there not folks here who work for Intel and could test it themselves on the same hardware as me? I mean, if I am the only person with this hardware that's having this problem, I understand not caring about fixing it. But I know it's not something I'm doing on my installation because other live images of other distros also won't boot because of this same issue. But whatever, if you want to get sassy after all I've done is try to ask for help, then I won't bother you anymore. I'll just keep living with my 1 1/2 years old kernel until I can buy some better hardware. If only I could have followed the sage advice found at the bottom of this page (https://bbs.archlinux.org/viewtopic.php?pid=1622417#p1622417). I just don't have that extra money lying around at the moment.

Philip, we have Cherryview/Braswell machines in CI and use, and they work just fine. It's impossible for us to test all machines made by all OEMs out there, with all kernel configurations. If it works for us, all we have to work with is what you report and test.

This is not a unidirectional help/support line from us to you. This is a community bugzilla, where you are expected to work with us to find a resolution to the problems. Currently this bug does not have anywhere near enough information to even spend more time debugging. We don't even know if you just get a black screen or if the whole machine actually hangs. (And then there's extra irrelevant information about other bugs on other machines that one has to filter out.)

So I'm afraid you're not alone in your frustration. :(

Jani, thanks for the follow up. I'm really sorry about my outburst. You're the only one that has actually tried to help. And thanks for answering the question I've had about the hardware. It makes more sense why I haven't seen much on the internet about this problem. Anyway, I guess you should close the bug. I'm not going to spend any more time on this. It's only going to be a serious problem if my whole system gets broken and requires a reinstall (which hasn't happened on Arch so far). So, thanks for the attempt and please forgive my misdirected frustration.

Timeout - marking as resolved+worksforme.