I'll test with 3.17 when I can, but the current Fedora 3.17 build appears to be completely DOA on the system (fails long before KMS), so I can't test currently.

(In reply to comment #1)
> I'll test with 3.17 when I can, but the current Fedora 3.17 build appears to
> be completely DOA on the system (fails long before KMS), so I can't test
> currently.

Adam, any luck with 3.17-rc now?

Vijay, here's a candidate display bug for your team to look at. If you want to decline or don't have the bandwidth, please just re-assign using "Reset Assignee to default". Thanks.

Jani: no, 3.17 is still busted (Jan-Michael Brummer and Bastien Nocera confirm the bug, too): https://bugzilla.kernel.org/show_bug.cgi?id=84241

So just took another look at this to see if I can figure out what the hell's going on, and I can't, but something odd happened.

I booted (with 3.17rc6) and got a successful accelerated boot - the first time that's ever happened. Performance was *very* slow, though - way slower than with nomodeset.

Then I booted again, and it black screened again.

I grabbed logs from both boots, I'll attach them. I did some dumb grep and cut on the logs so they were vaguely comparable and ran a diff, and the diff is weirdly small, and mostly just things happening in a different order - I just can't see a lot of difference between the 'failure' and 'success' cases. Very strange.

Created attachment 106968 [details]
log of a failed boot with 3.17rc6

Created attachment 106969 [details]
log of a 'successful' (though very very slow performance) boot with 3.17rc6

To describe the 'success' case in more detail, every animation that occurred in GDM and GNOME was very slow, but smooth (not jerky). it'd take like 10 seconds for a menu to slowly slide into place. After a bit, it seemed to stop responding entirely, so I had to force power off.

So I just made a bit of a discovery in testing 3.18 on my V8P.

If I boot normally, or go through the firmware UI (hold down volume *up* key when booting):

* Early boot, all the way from Dell logo to the point where KMS tries to kick in, looks to be in native resolution (800x1280)
* KMS fails as described in this bug, screen blanks when it kicks in

But! If I boot through the boot device menu (hold down volume *down* key when booting):

* Early boot is in some other resolution - lower, and not the right ratio, text is squashed
* KMS works! When it kicks in, the display switches to native resolution (800x1280) and I get a successful boot, all the way into a fully accelerated GNOME session

So not sure if that helps anyone figure out what the bug is, but hey, at least it's a workaround for me for now. I'll attach updated drm.debug logs from 3.18 soon.

This means that now we can change gfxpayload=keep to gfxpayload=text in grub cfg and it should work every time. I'll check in 5 minutes.

I'm sorry, but your solution does not work for me. I mean, there is a difference - now, I do not have a black screen, I see loads plymouth and Gnome, but the screen is like a broken TV - flying lines.

Are you using a Venue 8 Pro? If not, what device? Also, make sure you drop any 'video=' parameter from the command line (that you might have had for the old hacky video support from 3.14 and earlier).

Yes, it's Dell Venue 8 PRO. I've tried with 08 Bios and now I'm on 09 Bios with the same issue. And I've tried with grub.cfg you provided in ISO.

Have you compiled kernel with this? https://bugzilla.kernel.org/show_bug.cgi?id=68291#c46

I am also experiencing this behavior on a 3.18 kernel built by Adam. Will attach the trace to this bz.

Adam, the "slow boot" in your case may be caused by this:

Sep 27 07:05:54 fedlet.happyassassin.net kernel: Clocksource tsc unstable (delta = 64072097 ns)
Sep 27 07:05:54 fedlet.happyassassin.net kernel: Switched to clocksource refined-jiffies

In my case the clocksource was also switching to refined-jiffies which made huge timing issues, i worked around it by sticking with tsc (added clocksource=tsc cmdline) because in my case hpet is not available, probably due to buggy BIOS.

Created attachment 111132 [details]
vblank timed out on i915

Created attachment 113510 [details]
vblank wait timed out

Comment on attachment 113510 [details]
vblank wait timed out

My WinBook TW802/TW802 probably hit the same bug.

*** Bug 89573 has been marked as a duplicate of this bug. ***

I'm being optimistic and presume we've fixed this upstream. Please reopen if the problem persists with latest kernels.

On Vacation during WW42 (no email access) and on business trip during WW43 (limited mail access). Please contact:

Ganesh S T for Display GEN TR (GEN11, 11.5, 12) queries
Megha Aggarwal & Arun Murthy for CHT power optimization TF queries
Ganesh S T for VBT spec review approvals & queries

I will be back in office during WW44.1.

Thanks,
Vijay

It still behaves exactly as per #c8 at least in kernel 4.1, which is the last I checked. I'll get around to building a 4.2 Fedlet image some time...

(In reply to Adam Williamson from comment #20)
> It still behaves exactly as per #c8 at least in kernel 4.1, which is the
> last I checked. I'll get around to building a 4.2 Fedlet image some time...

I have regular rc kernels here:
http://copr.fedoraproject.org/coprs/hadess/32bit-boot/builds/
with BayTrail and CherryTrail patches

And you can update existing images, if you've added the persistent overlay like so:
https://fedoraproject.org/wiki/How_to_create_and_use_Live_USB
(look for Kernel Updates at the bottom)

Is an updated user space also required? If so, which Xorg server/driver versions specifically? How about mesa? I haven't used my tablet in a while so it's still on Debian Jessie with the exception of xserver-xorg-video-intel-2.99.917 from experimental as of March this year.

Cheers,
Rene

I don't imagine new userspace being required; however please go for latest upstream kernel, preferably v4.3-rc7.

On my tablet, a Winbook with a Atom Z3735G cpu, the screen goes blank when the Intel DRM driver is loaded but no issues with modesetting disabled with kernel 4.3-rc7.  So it seems this problem still exists.

I'm sorry it took me so long to test this. With my Venue 8 Pro 3845, I'm afraid the problem persists with 4.4.0-rc5-amd64 version 4.4~rc5-1~exp1 from Debian experimental. Unless I pass 'nomodeset' on the kernel command line I still get a black screen when X starts. Reopening as requested in Comment 19.

So there's tons of DSI related fixes in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel. Please try that and report back.

Still broken with same symptom in 4.6.0-rc7 drm-intel-nightly as of 2016-05-12.

(In reply to bs666_1 from comment #27)
> Still broken with same symptom in 4.6.0-rc7 drm-intel-nightly as of
> 2016-05-12.

Care to attach dmesg with drm.debug=14 module parameter set as well please?

Created attachment 123802 [details]
dmesg 4.6.0-rc7 drm-intel-nightly

Added dmesg

(In reply to bs666_1 from comment #29)
> Created attachment 123802 [details]
> dmesg 4.6.0-rc7 drm-intel-nightly
> 
> Added dmesg

Unrelated to this bug, but I noticed in your dmesg that your BYT is running with a 333 MHz CZ clock. I've been looking for one of those to confirm how the minimum GPU frequency behaves.

[    5.328217] [drm:intel_update_czclk] CZ clock rate: 333333 kHz
[    5.462363] [drm:vlv_init_gpll_ref_freq] GPLL reference freq: 20833 kHz
[    5.466068] [drm:valleyview_init_gt_powersave] DDR speed: 1333 MHz
[    5.470064] [drm:valleyview_init_gt_powersave] max GPU freq: 646 MHz (214)
[    5.478082] [drm:valleyview_init_gt_powersave] RPe GPU freq: 646 MHz (214)
[    5.478104] [drm:valleyview_init_gt_powersave] RP1(Guar Freq) GPU freq: 312 MHz (198)
[    5.478121] [drm:valleyview_init_gt_powersave] min GPU freq: 187 MHz (192)

Can you do a 'grep . /sys/class/drm/card0/gt_*' and
'intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30 nc:0x34'
when the GPU is idle?

I can't really be certain the GPU was idle as the screen was blank but the values were stable and I'm fairly sure it was at a fbcon vt.

$ sudo ./intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30 nc:0x34 --spec=registers
        punit:0x000000d3 (0x04:0x000000d3): 0x000000bf
        punit:0x000000d4 (0x04:0x000000d4): 0x000000bf
        punit:0x000000d8 (0x04:0x000000d8): 0x0000c0d0
           nc:0x0000001c (0x11:0x0000001c): 0xbbfe36b4
           nc:0x00000030 (0x11:0x00000030): 0xb378ad39
           nc:0x00000034 (0x11:0x00000034): 0xfc0eb636
$ sudo grep . /sys/class/drm/card0/gt_*
/sys/class/drm/card0/gt_act_freq_mhz:187
/sys/class/drm/card0/gt_cur_freq_mhz:167
/sys/class/drm/card0/gt_max_freq_mhz:645
/sys/class/drm/card0/gt_min_freq_mhz:167
/sys/class/drm/card0/gt_RP0_freq_mhz:645
/sys/class/drm/card0/gt_RP1_freq_mhz:312
/sys/class/drm/card0/gt_RPn_freq_mhz:167

(In reply to bs666_1 from comment #31)
> I can't really be certain the GPU was idle as the screen was blank but the
> values were stable and I'm fairly sure it was at a fbcon vt.
> 
> $ sudo ./intel_reg read punit:0xd3 punit:0xd4 punit:0xd8 nc:0x1c nc:0x30
> nc:0x34 --spec=registers
>         punit:0x000000d3 (0x04:0x000000d3): 0x000000bf
>         punit:0x000000d4 (0x04:0x000000d4): 0x000000bf
>         punit:0x000000d8 (0x04:0x000000d8): 0x0000c0d0
>            nc:0x0000001c (0x11:0x0000001c): 0xbbfe36b4
>            nc:0x00000030 (0x11:0x00000030): 0xb378ad39
>            nc:0x00000034 (0x11:0x00000034): 0xfc0eb636
> $ sudo grep . /sys/class/drm/card0/gt_*
> /sys/class/drm/card0/gt_act_freq_mhz:187
> /sys/class/drm/card0/gt_cur_freq_mhz:167
> /sys/class/drm/card0/gt_max_freq_mhz:645
> /sys/class/drm/card0/gt_min_freq_mhz:167
> /sys/class/drm/card0/gt_RP0_freq_mhz:645
> /sys/class/drm/card0/gt_RP1_freq_mhz:312
> /sys/class/drm/card0/gt_RPn_freq_mhz:167

I take it that was with 4.4 or earlier kernel? Anyway, based on those the register values it does look like our current code is in fact correct also for the cz=333 case.

Hi, did you ever get this problem solved?

I have the same on ODYS WinTab 8 with Intel Atom Baytrail-T Z3735E CPU.

Any(tried many different distro including all ubuntu, slacko(and other puppy), android, phoenix, remix, x86) linux boots, then end up in black screen - If I add nomodeset to grub.cfg on the LiveUSB(made with Unetbootin) then it boots into desktop - but then I can't change resolution or rotation. If I remove nomodeset and add i915.modeset=0 then its the same - still can't rotate or change resolution.

This is on 16.04 Linuxium 64bit, Unity, gnome, xubuntu.

On Kubuntu 16.10 linuxium 64bit resolution are available but not working - rotation is there but not working either. This doesn't work on Unity, gnome, xubuntu - I have not tried Lubuntu or MATE.

My thoughts is that the screen/display/monitor/panel or what you will call it, is not getting discovered correctly by the kernel. It is only found as default.

It is not possible to get 

I worked on this problem and some other ones with this tablet(sound, wi-fi bluetooth), for over 2½ month. Bluetooth and wi-fi works in linuxium - sound do not.

My effort on getting slacko to work on this can be followed below, that page also have hardware list:

http://www.murga-linux.com/puppy/viewtopic.php?t=108295&sid=6a8c4349d9a2e5799295a020318d3185

My effort on getting linuxium to work:
https://linuxiumcomau.blogspot.com/2016/10/running-ubuntu-on-intel-bay-trail-and.html?showComment=1477057433854#c5416952429820429838

Jan - I would propose that you file new bug for your problem if it still persist.
bs666_1@hotmail.com - please check if the problem still persist with the latest kernel (preferable from drm-tip).

Plenty of DSI fixes have landed in drm-tip branch of https://cgit.freedesktop.org/drm/drm-tip lately. Please use that.

There's the remaining bug 96571 that requires specific kernel config options, be sure to use them.

I don't have time to do any real testing but the screen doesn't go black and I can interact with the console with modesetting enabled so it looks very promising.  My current linux install on the machine is very old and X doesn't even start so I'd have to upgrade it to be sure.

Everything seems to work properly now KMS, DRM, X and Wayland with the drm-tip tree.  Think bug can be closed.

Adam, Dell's exe files with BIOS update can be run from Windows and FreeDOS. You also can find "BIOS Updater" item in boot menu, run it, select this exe, and BIOS will get updated.

As for DV8P, display of DV8P5830 works since https://patchwork.kernel.org/patch/9458597/ got merged, and display of DV8P58305855 works since Linux 4.12rc1. This bug can be closed.

I don't think this has anything to do with the firmware version on the Dell Venue 8 5130. Mine is working fine, but as reported e.g. also in bug 101205 (which is really about Pipo devices) their are 2 different versions of the Dell Venue 8 5130. With different panels, the working one has:

Jan 01 01:42:14 phone kernel: [drm:intel_bios_init [i915]] Found MIPI Config block, panel index = 5
Jan 01 01:42:14 phone kernel: [drm:intel_bios_init [i915]] No MIPI Sequence found, parsing complete

Where as the broken one has:

Mar 10 10:10:24 phone kernel: [drm:intel_bios_init [i915]] Found MIPI Config block, panel index = 3
Mar 10 10:10:24 phone kernel: [drm:intel_bios_init [i915]] Found MIPI sequence block v1

Note different panel indexes and if you look at the logs in bug 101205, which contains logs for both a good and a bad unit then you will also see different timings.

Jan Brummer has send me a Dell Venue 8 5130 with the trouble-some screen so that I could take a shot at fixing this.

I've actually managed to find the problem and I've a patch ready, but it is not pretty...

In the mean time lets open this bug for proper tracking of this until the problem is fixed on units with a panel index of 3.

Created attachment 136952 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence

Here is the patch for this which I intend to submit upstream soon.

Created attachment 136958 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence

Created attachment 136969 [details] [review]
[PATCH] drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v2

Here is a new version of the patch, with some changes because of upstream review, functionally it should be unchanged.

i can confirm, that it fixes the problem on my 5830 dell venue 8 pro, which had the blank screen syndrome before - thaks a lot! i was hoping, that maybe it helps too with my trekstor twin 10.1 from https://bugs.freedesktop.org/show_bug.cgi?id=104807 which has very similar symptoms, but sadly it does not fix the problem there ... most probably the reason for the blank screen there is a different one.

(In reply to hexdump from comment #43)
> i can confirm, that it fixes the problem on my 5830 dell venue 8 pro, which
> had the blank screen syndrome before - thaks a lot!

Thank you for testing.

> i was hoping, that maybe
> it helps too with my trekstor twin 10.1 from
> https://bugs.freedesktop.org/show_bug.cgi?id=104807 which has very similar
> symptoms, but sadly it does not fix the problem there ... most probably the
> reason for the blank screen there is a different one.

Looking at the drm.debug log you've attached there that indeed is a different problem, the MIPI sequences there do have a de-assert sequence.

Presumed fixed by

commit ee622fe757f6de612dad0f01805eea815a5b3025
Author: Hans de Goede <j.w.r.degoede@gmail.com>
Date:   Wed Feb 14 09:21:51 2018 +0100

    drm/i915: Fix DSI panels with v1 MIPI sequences without a DEASSERT sequence v3

in drm-fixes, headed to v4.16-rc2.

Thanks for the report, closing, please reopen if the problem persists with that.

Thanks for fixing this, Hans!