Comment # 12 on bug 1004933 from Luis Rodriguez

(In reply to John H. from comment #11)
> (In reply to Luis Rodriguez from comment #10)
> > (In reply to John H. from comment #9)
> > > although this maybe due to gdm switching to wayland.
> > 
> > Perhaps but how? The issue I saw with this code path which seemed rather
> > racy path with getting EDID info on bootup/suspend.
> 
> yes, i guess a race problem, too. wayland may simply be slower (or later or
> loading wayland-lib takes longer) then X when requesting information on
> screens.

Ok since this is no suspend then definitely a race on init, and I've looked at
the interal firmware code to know that very well -- I cannot think of any
possible modern issue upstream there yet... so the the next step is to review
the DRM code use of the API. The only thing I can think of as a possible
culprit to the issue would be feeing the firmware before usage, or freeing of
the firmware name passed. But to study this its best to use the latest and
greatest -- so once you test the latest kernel I suggested we can move forward
with that.

> > To this end I have had
> > some changes I've made to firmware_class which I'd like you to test. Is it
> > possible for you to test random kernel trees ?
> > 
> > If so can you test this branch ?
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/mcgrof/linux-next.git/log/
> > ?h=20170329-driver-data-v2-try2
> 
> havn't build a kernel in a while, but i'll try.

It would be appreciated, at this point this is an issue upstream, so we need to
engage and fix that there and using upstream kernels will help a lot here.

If its hard for you to do this though let me know and I can provide some kernel
builds, that will just take time though.

Note that using linux-next is very likely to not even boot, not due to a driver
issue specific to this issue but also due to many churn in code not yet ironed
out in line waiting to get upstream. So thanks for testing -- but if you run
into issues with it don't be surprised.

> > > just had this while trying to access a tty
> > > from X.
> > 
> > How exactly did this happen. You booted up, and after a while you switch to
> > a tty from X ? No suspend / resume at all ?
> 
> no suspend / resume. i just wanted to switch to another runlevel so i
> pressed ctrl + alt + f1 from X and then all rendering stopped because of the
> above bug. i sshd into the machine and saw i had to reboot...

Using CTLR + ALT + F1 will not switch run levels, it will just spawn a tty for
you. You can also use /usr/bin/chvt for the same these days as some distros do
not allow to trap CTRL + ALT + F1 anymore.

The equivalent to CTRL + ALT + F1 now:
chvt 1

And going back to CTRL + ALT + F7
chvt 7