Bug 97941

Created attachment 177431 [details]
dmesg 20150519


attach dmesg of drm-intel-nightly

Created attachment 178211 [details]
dmesg with drm.debug=0xff


update dmesg with drm.debug=0xff option

dmesg seems to point out that there is unexpected entry in VBIOS, thus I tried to dump VBIOS folowing :

https://01.org/linuxgraphics/documentation/development/how-dump-video-bios

But I get an I/O error.

Best regards

(In reply to Benoit Gschwind from comment #3)
> dmesg seems to point out that there is unexpected entry in VBIOS, thus I
> tried to dump VBIOS folowing :
> 
> https://01.org/linuxgraphics/documentation/development/how-dump-video-bios
> 
> But I get an I/O error.
> 
> Best regards

Just
cat /sys/kernel/debug/dri/0/i915_opregion > file
is enough

Created attachment 178901 [details]
OpRegion dump

Hello,

I attached the OpRegion dump of Surface 3

Best regards

I'm hitting this on a Surface 3 as well, using kernel 4.2-rc3.

As the fallback LLVM mesa support is also broken:
https://bugzilla.redhat.com/show_bug.cgi?id=1178347
No graphical mode at all for me.

Let me know if you need any more information.

I'm having the same problems, my dumps are all the same as the attached ones in kernel 4.1.5, I only disabled extra AMD hardware support and NVIDIA support for my specific build to disable 'bloat' that isn't needed as well as the Surface Type Cover fix.

I can also confirm this has been the same problem since kernel 3.16, and was an issue in 3.19

After looking through the relevant code, the device ID 22b0 is listed in the kernel driver PCI IDs, yet isn't loading i915, so if we don't sent nomodeset, the kernel just loads to a black screen.

Please try the patches in the thread starting at

http://mid.gmane.org/1438077670-12953-1-git-send-email-m.deepak@intel.com

Created attachment 186501 [details]
4.2.0 log

Tested the patches on top of 4.2.0 (after small rebasing).

Sep 01 20:43:03 localhost kernel: [drm:vlv_enable_dsi_pll [i915]] *ERROR* DSI PLL lock failed
Sep 01 20:43:03 localhost kernel: [drm:dpi_send_cmd.constprop.8 [i915]] *ERROR* Video mode command 0x00000042 send failed.

Created attachment 186511 [details]
4.2.0 log with drm.debug=14

Sep 02 10:13:31 localhost kernel: [drm:vlv_update_cdclk] Current CD clock rate: 266667 kHz
Sep 02 10:13:31 localhost kernel: [drm:intel_dsi_pre_pll_enable] 
Sep 02 10:13:31 localhost kernel: [drm:intel_dsi_prepare] pipe B
Sep 02 10:13:31 localhost kernel: [drm:vlv_enable_dsi_pll] 
Sep 02 10:13:31 localhost kernel: [drm:vlv_configure_dsi_pll] dsi pll div 000001ab, ctrl 00020080
Sep 02 10:13:31 localhost kernel: [drm:vlv_enable_dsi_pll [i915]] *ERROR* DSI PLL lock failed

Created attachment 186521 [details]
kernel-4.3-pre drm debug log

With the patch in http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/66645 added to the original patch series.

Created attachment 186681 [details]
kernel 4.1.6 dmesg with patchset

The path set of comment 8 was aplyed without any modification to the vanilla kernel 4.1.6

Best regards.

Another one that might help 
http://mid.gmane.org/1441306216-6581-4-git-send-email-ville.syrjala@linux.intel.com

Created attachment 186711 [details]
kernel-4.3-pre drm debug log (third build)

(In reply to Jani Nikula from comment #14)
> Another one that might help 
> http://mid.gmane.org/1441306216-6581-4-git-send-email-ville.syrjala@linux.
> intel.com

Still failing with that patch added to the ones mentioned in comment 8 and comment 12.

(In reply to Bastien Nocera from comment #16)
> (In reply to Jani Nikula from comment #14)
> > Another one that might help 
> > http://mid.gmane.org/1441306216-6581-4-git-send-email-ville.syrjala@linux.
> > intel.com
> 
> Still failing with that patch added to the ones mentioned in comment 8 and
> comment 12.

It says gen=8 in the dmesg so this is CHT not BYT. You should definitely try my entire branch (which already includes that earlier patch of mine):
git://github.com/vsyrjala/linux.git vlv_chv_dsi_dpll

It should at least fix all of that DPIO spew, and if we're lucky it might also fix something else.

Though you will need to merge that with the other stuff you've already picked up. Not sure how bad it'll conflict.

I couldn't figure out how to s/byt/cht/ in the bug title, so someone else should do it.

(In reply to Ville Syrjala from comment #17)
> (In reply to Bastien Nocera from comment #16)
> > (In reply to Jani Nikula from comment #14)
> > > Another one that might help 
> > >
> http://mid.gmane.org/1441306216-6581-4-git-send-email-ville.syrjala@linux.
> > > intel.com
> > 
> > Still failing with that patch added to the ones mentioned in comment 8 and
> > comment 12.
> 
> It says gen=8 in the dmesg so this is CHT not BYT.

I didn't even notice. Jani changed it, likely in error, when he first commented:
https://bugzilla.kernel.org/show_activity.cgi?id=97941

The Surface 3 is indeed CherryTrail:
https://en.wikipedia.org/wiki/Surface_3

> You should definitely try
> my entire branch (which already includes that earlier patch of mine):
> git://github.com/vsyrjala/linux.git vlv_chv_dsi_dpll

From 38090edf0488bc28313f75f177072f1b4f233713 (excluded) up to the tip of the branch?

> It should at least fix all of that DPIO spew, and if we're lucky it might
> also fix something else.
> 
> Though you will need to merge that with the other stuff you've already
> picked up. Not sure how bad it'll conflict.

I'll try this out then.

> I couldn't figure out how to s/byt/cht/ in the bug title, so someone else
> should do it.

No bugzilla rights to do that either.

(In reply to Bastien Nocera from comment #18)
> (In reply to Ville Syrjala from comment #17)
> > You should definitely try
> > my entire branch (which already includes that earlier patch of mine):
> > git://github.com/vsyrjala/linux.git vlv_chv_dsi_dpll
> 
> From 38090edf0488bc28313f75f177072f1b4f233713 (excluded) up to the tip of
> the branch?

Yep.

Either I did something wrong rebasing or there's a bug in that branch.

I rebased all the patches mentioned in comment 16 (the patch series, plus the 2 independent patches on top) on top of the vlv_chv_dsi_dpll branch. But the machine must be crashing in the middle of setting up the display.

For the record, this is what the patch on top of the branch looks like:
http://paste.fedoraproject.org/263933/44849914

Is there a way to load force the i915 driver to do modesetting *after* the machine has been booted with nomodeset? This would allow me to connect to the machine through ssh and capture at least the early parts of the modesetting setup.

(In reply to Bastien Nocera from comment #20)
> Either I did something wrong rebasing or there's a bug in that branch.
> 
> I rebased all the patches mentioned in comment 16 (the patch series, plus
> the 2 independent patches on top) on top of the vlv_chv_dsi_dpll branch. But
> the machine must be crashing in the middle of setting up the display.
> 
> For the record, this is what the patch on top of the branch looks like:
> http://paste.fedoraproject.org/263933/44849914
> 
> Is there a way to load force the i915 driver to do modesetting *after* the
> machine has been booted with nomodeset? This would allow me to connect to
> the machine through ssh and capture at least the early parts of the
> modesetting setup.

Hello Bastien,

You have to compile i915 and drm as module and black list them in 

/etc/modprobe.d/blacklist.conf

by adding :

blacklist drm
blacklist i915

then load modules manually

# modprobe drm debug=0xff
# modprobe i915

that's it

No real need to blacklist drm, i915 is enough. It can also be done from the kernel command line with "modprobe.blacklist=i915".

Also make sure you disable plymouth, X etc. from automatically starting as they will load the module behind your back despite the blacklisting.

(In reply to Ville Syrjala from comment #22)
> No real need to blacklist drm, i915 is enough. It can also be done from the
> kernel command line with "modprobe.blacklist=i915".
> 
> Also make sure you disable plymouth, X etc. from automatically starting as
> they will load the module behind your back despite the blacklisting.

I forgot to disable starting X in my test, but the postponing meant that it errored after the Wi-Fi had been brought up. Log attached (it can detect the display correctly this time!).

Created attachment 186831 [details]
kernel-4.2.0-rc8+ drm debug log (fourth build)

(In reply to Bastien Nocera from comment #18)
> (In reply to Ville Syrjala from comment #17)
> > It says gen=8 in the dmesg so this is CHT not BYT.
> 
> I didn't even notice. Jani changed it, likely in error, when he first
> commented:
> https://bugzilla.kernel.org/show_activity.cgi?id=97941

Bah, is_valleyview in dmesg keeps throwing me off.

So I have the vlv_chv_dsi_dpll branch, plus the patchset at:
http://mid.gmane.org/1441841070-11532-1-git-send-email-m.deepak@intel.com
and http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/66645

http://article.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/68903
is already in the vlv_chv_dsi_dpll branch.

Building now.

Created attachment 187861 [details]
drm-debug-log

Any progress on this?  I have a Surface 3 and would be willing to help test any patches or debug settings.  Really want to see Linux running smoothly on this thing!

We'll probably get a Surface 3 to play with sometime soon, maybe that'll help...

Echoing the hope that this gets sorted - I'm quite interested in picking up a Surface but would need to have graphics support on the thing for it to be of any use to me at all.

Hi all, please try drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel *and* the 15-patch series from http://patchwork.freedesktop.org/series/1998/ on top.

No, don't get your hopes up just yet, I don't think it will work. But I'd appreciate the dmesg resulting from running that with drm.debug=14 module parameter set.

Created attachment 197981 [details]
Dmesg after Comment #31

I've attached the dmesg after using the instructions from Comment #31. The system was booted with i915 blacklisted, and right before the dmesg was generated, I ran modprobe i915. Note that the screen resolution switch actually worked and the screen is no longer blank.

It still looks like there's some errors in the logs.

Weston runs now as well as the weston demo programs. GDM is running too. I'll have to do more playing around. I guess this means that functionally everything works?

Very nice. I recently grabbed a Surface and have been running W10 on it until this bug was resolved... looks like I'll have to build a Arch ISO remix tonight :)

If someone has an external monitor they could try, that would be good to test.

Obviously there's probably still some bugs here and there, but in just super excited to finally be able to run a decent desktop on this thing.

Whoa, I never even dreamed that my patchset would make it work; I just thought it was a necessary intermediate step. A happy surprise for once. :)

If anyone has a working image file and can share, that would be much appreciated!  It's been a little while since I've compiled a kernel..

I would really appreciate that as well. I'm happy that I'll be finally able to use Linux on my Surface.

Yes this would make many people happy.  Hopefully this change can make it into a distribution soon.

Created attachment 198471 [details]
Dmesg w/ External Monitor, GNOME

I've spent a little bit more time testing this patch, and it looks like external displays are working (I acquired a mini-DP to DVI adapter to test with).

The display brightness control does not appear to be working at this point.

I'm attaching another dmesg, because there are some unusual looking logs towards the end which weren't in the previous dmesg. They showed up after launching Gnome.

I didn't have much time to test this, but it's working well enough for me. The EDID of the panel isn't propagated properly (xrandr claims 0mm x 0mm) but at least the interface shows up in the native resolution.

(In reply to Bastien Nocera from comment #40)
> The EDID of the panel isn't propagated properly (xrandr claims 0mm x 0mm)

FYI, DSI has no EDID.

(In reply to Jani Nikula from comment #41)
> (In reply to Bastien Nocera from comment #40)
> > The EDID of the panel isn't propagated properly (xrandr claims 0mm x 0mm)
> 
> FYI, DSI has no EDID.

Is the data about the physical size of the panel available somewhere else? If not, do we have a place somewhere in the driver code base to put it?

The Surface 3 uses a 10.9 inch 1920 x 1280 panel, which, if my maths[1] are right would be 8.99" × 5.99", or 22.82cm × 15.22cm.

[1]: OK, https://www.sven.de/dpi/

We get the supported mode of the display from the VBT (video bios table), because DSI has no auto-discovery to get that info out of the display itself.

Unfortunately the VBT does not seem to have information about the physical dimensions.

(In reply to Jani Nikula from comment #43)
> We get the supported mode of the display from the VBT (video bios table),
> because DSI has no auto-discovery to get that info out of the display itself.
> 
> Unfortunately the VBT does not seem to have information about the physical
> dimensions.

Can we fill that in based on the DMI information, somewhere in the driver? The DPI should be detected as > 200 DPI, and kick GNOME into hi-dpi mode.

(In reply to Bastien Nocera from comment #44)
> (In reply to Jani Nikula from comment #43)
> > We get the supported mode of the display from the VBT (video bios table),
> > because DSI has no auto-discovery to get that info out of the display
> itself.
> > 
> > Unfortunately the VBT does not seem to have information about the physical
> > dimensions.
> 
> Can we fill that in based on the DMI information, somewhere in the driver?
> The DPI should be detected as > 200 DPI, and kick GNOME into hi-dpi mode.

It would eventually become one giant monster of a DMI match table. I'd rather not start on that path in the kernel.

(In reply to Jani Nikula from comment #31)
> Hi all, please try drm-intel-nightly branch of
> http://cgit.freedesktop.org/drm-intel *and* the 15-patch series from
> http://patchwork.freedesktop.org/series/1998/ on top.
> 
> No, don't get your hopes up just yet, I don't think it will work. But I'd
> appreciate the dmesg resulting from running that with drm.debug=14 module
> parameter set.

Most of the patches have now been pushed to drm-intel-nightly with minor modifications. Please try drm-intel-nightly again, and report back.

If that does *not* work, please add the one remaining patch [1] on top, and try again.

[1] http://patchwork.freedesktop.org/patch/msgid/1452519005-17244-1-git-send-email-jani.nikula@intel.com

Ping, anyone up for testing drm-intel-nightly again?

My plan is to close this bug as soon as I get confirmation that we no longer get a black screen. That's kind of the pivotal point in debugging everything else. After that I urge people to file new bugs, one bug per report for any remaining issues, at the freedesktop.org bugzilla [1], and they will be easier to manage one by one.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

(In reply to Jani Nikula from comment #47)
> Ping, anyone up for testing drm-intel-nightly again?

I was traveling, and now the laptop keeps shutting down when I'm compiling because it's too hot. Will let you know when I manage to get something compiled and tested...

(In reply to Jani Nikula from comment #47)
> Ping, anyone up for testing drm-intel-nightly again?
> 
> My plan is to close this bug as soon as I get confirmation that we no longer
> get a black screen.

After this:
https://twitter.com/hadessuk/status/688070076906520576/photo/1

I managed to compile and run the drm-intel-nightly. It works well enough to show a couple of Tuxes at boot, and a GNOME desktop afterwards. I didn't need to apply any more patches.

Created attachment 199831 [details]
dmesg drm-intel-nightly-20160116

Hello,

The drm-intel-nightly work for me with warning as attached dmesg show.

Best regards.

Awesome, thanks for testing. As promised, I'm closing this one as fixed. Please file new bugs at the freedesktop.org bugzilla for the remaining graphics issues (like the warnings), one bug per issue:

https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

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