I just bought a Dell Venue 8 Pro - an 8" tablet based on the Bay Trail platform - to try and get Fedora running on it. After hacking things up to produce a bootable 32-bit UEFI image, next come the kernel bugs :) If I boot an image with a 3.11 or 3.12 kernel and default boot arguments, the display becomes badly garbled as soon as modesetting kicks in; it looks like it selects the wrong mode. If I boot an image with kernel 3.13.0-0.rc1.git0.1 , the screen just goes blank (backlight still working) when modesetting kicks in. For now I have no further details, as I don't have a USB hub to hand so there's no way I can get any out. I'm going to pick up a USB hub tomorrow so I can have both the boot media and a keyboard connected, and I should be able to get some more useful info at that point.
Hm, smells like a DSI panel ... Can you please boot with drm.debug=0xe and (somehow) grab the complete dmesg and attach it? Also please try to do this on the very latest kernels, preferably drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/
Created attachment 89807 [details] partial logs from a 3.13 boot with drm.debug set I'm having fun getting debug output out of the system (nice 'somehow' :>), but here's what I've got. This is what journald managed to capture from a boot of 3.13.0-0.rc1.git2.1.fc21 with drm.debug set. Boot actually fails later on with 3.13 - see https://bugzilla.kernel.org/show_bug.cgi?id=65841 - so the log isn't complete, but it may have what you need.
Well we didn't find a single panel, neither eDP or a DSI one :( Are there any external outputs to make life easier with debugging? The kernel thinks there is something ...
Didn't Jesse or Jani send a patch to fix detection of rogue eDP panels on the other DP port? I think that is in drm-intel-next.
"Are there any external outputs to make life easier with debugging?" Hah - it's like you think Dell exists to make my life _easy_ or something ;) The thing has precisely one port, which is approximately a micro USB port. I believe it may be possible to plug in an adapter that makes it act as an HDMI port, but I haven't looked into it at all yet. Maybe I'll have to? :/ Note that thing about 3.11 and 3.12 producing garbled output on the panel, not just _nothing_ - any idea if that's significant? Would similar logs from either of those kernels be any use? I can try and get a drm-intel-nightly or drm-intel-next tree built and booted today, I'll do my best.
Chris: is https://bugs.freedesktop.org/show_bug.cgi?id=71051 what you're thinking of? Just found that when I tweaked my search terms (apparently we don't believe in spaces when it comes to codenames, I should be searching for 'baytrail' not 'bay trail' :>)
Aye, that's the one. I admittedly didn't search very hard earlier...
Ok. I'll try and get a kernel built with that fix and see how it goes.
OK, so I have a 3.13rc2-based kernel built, with the patch generated from commit http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=5d8a77529bd6864361005117c3a611b6d810aa77 - "Check VBT for eDP ports on VLV" - applied. Still doesn't work, still the screen goes blank when modesetting kicks in. :/ I've managed to get the dmesg output, which I'll attach.
Created attachment 90043 [details] dmesg from 3.13rc2 + check vbt for edp patch, with drm.debug set
Good news! I did a build based off the latest Fedora kernel (few git revs past rc2) and added simplify-dp-vs-edp.patch - http://cgit.freedesktop.org/~danvet/drm-intel/commit/?h=drm-intel-fixes&id=3b32a35b31b19c8f9340d3b3a149062fce1cd89f - and that gives me working KMS. X startup fails, without any apparent useful output to any logs; Xorg.0.log just sorta ends, nothing in the journal. But at least we got further. I'll try building latest intel DDX and stuff before reporting that one. Looks like this one is OK at least with drm-intel-fixes.
Great, thanks Adam. If the new DDX still doesn't work you could try with -verbose and drm.debug=0x6 to see if anything weird is going on. Maybe it's more backlight fail.
No dice with the X issue with an F21 image that has pretty recent versions of DDX and everything else in the stack, unfortunately. I haven't had time to debug it any further, been running around fighting Fedora 20 release fires :) When things quiet down a bit I'll take another crack at it and file a bug in the appropriate place.
X is still failing with current bits from Rawhide, filed as https://bugs.freedesktop.org/show_bug.cgi?id=73133 .
Hrm. Now I'm not 100% sure this is actually fixed. I think instead another bug may have showed up and messed with us: https://bugzilla.kernel.org/show_bug.cgi?id=68291 whenever I started getting the Baytrail pinctrl driver enabled in my kernel builds - which unfortunately I'm not keeping really strict records about :( - that bug started happening to me. It's a crash early in boot when initializing the graphics hardware; once that's happened, I think modesetting becomes a dead letter. Now we've figured out a fix/workaround for that bug...I'm back to KMS producing a black screen :( That is, with a 3.13rc8 kernel and the patches for https://bugzilla.kernel.org/show_bug.cgi?id=68291 and https://bugzilla.kernel.org/show_bug.cgi?id=67911 applied, I get a blank screen when KMS kicks in. Booting with nomodeset is successful. The two patches we thought fixed this - "Check VBT for eDP ports on VLV" and "Simplify DP vs. eDP detection" - were merged into Linus' tree on 2013-11-28, so I'm pretty sure they ought to be in rc8, right?
Created attachment 92249 [details] dmesg from 3.13rc8 + fixes for 68291 and 67861 Here's my latest dmesg, anything different?
I've observed similar issues on Asus T100. For kernel 3.12 I've added parameter video=VGA-1:1368x768@60 to kernel command line, and it fixed issue with screen. For kernel 3.13-rc8 from git://people.freedesktop.org/~danvet/drm-intel branch: for-linux-next commit: 16b23af I've reverted below commit, and now I can boot without black screen. commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Sep 10 14:54:42 2013 -0700 drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT
(In reply to comment #17) > I've observed similar issues on Asus T100. > > For kernel 3.12 I've added parameter video=VGA-1:1368x768@60 to kernel > command line, and it fixed issue with screen. > > For kernel 3.13-rc8 from git://people.freedesktop.org/~danvet/drm-intel > branch: for-linux-next commit: 16b23af I've reverted below commit, and now > I can boot without black screen. Generally prefer the drm-intel-nightly branch. > commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a > Author: Jesse Barnes <jbarnes@virtuousgeek.org> > Date: Tue Sep 10 14:54:42 2013 -0700 > > drm/i915/vlv: re-enable hotplug detect based probing on VLV/BYT Adam, does reverting the above commit fix the issue for you?
Jani: I'll find that out today.
Created attachment 92711 [details] xorg.conf with 800x1280 modeset I managed to get kms + X working on a Lenovo Miix 2 today (basically same chip that the Dell Venue pro 8) with 3.13 + F20: I used both hints given by Jacek: append "video=VGA-1:800x1280@60" to the command line and revert commit 6c4a8962a4a078cacfc8eb5d4bd79f6343b8cd7a. This gives a good kms on a 3.13 kernel (no black screen anymore, console OK), but X fails with garbled display. So I just add the correct mode to xorg.conf (attached), and it's ok now. I will try later the latest intel-drm tree to see if it has been fixed upstream, but I think it is "just" that the intel CRC do not manage to get the correct EDID to the attached display.
Sorry I didn't get back yet, got distracted. I just built a new image, but I think my V8P's battery died, I'm charging it back up again now...
My latest live image just flat out doesn't boot past grub, for some reason. No idea what's going on. Two confirmations sounds good, though. I'll poke at mine tomorrow if I get the time.
OK, after I finally bashed my way past a bunch of other bugs, can confirm what others report: reverting "re-enable hotplug detect based probing on VLV/BYT" 'fixes' this for me too, and I can get KMS console and X by forcing an 800x1280 video mode after reverting that patch, I'll open a new bug for the problem with auto-detecting the mode.
https://bugs.freedesktop.org/show_bug.cgi?id=74657 for the mode detection issue.
https://bugzilla.kernel.org/show_bug.cgi?id=68451 is probably relevant here: Ville seems to have figured out that the displays on these devices are actually connected via DSI.
(In reply to comment #25) > https://bugzilla.kernel.org/show_bug.cgi?id=68451 is probably relevant here: > Ville seems to have figured out that the displays on these devices are > actually connected via DSI. They *may* be connected via DSI. To make sure, please provide register dump using 'tools/quick_dump/quick_dump.py -a' from intel-gpu-tools [1]. If this one uses a DSI panel, I'm not sure how we should handle it, as there's no VBT block for MIPI DSI: [ 8.813116] [drm:parse_mipi], No MIPI BDB found [1] http://cgit.freedesktop.org/xorg/app/intel-gpu-tools/
I've been trying. quick_dump does not run when compiled and installed as part of fedora's xorg-x11-drv-intel. it looks like its attempt to find the _chipset module that seems to be compiled into I915ChipsetPython.so does not work. I've got almost no experience with how that stuff works in python3, so I really can't fix it.
i'll get a compiled tree over to the tablet somehow and run it that way, it's just i have a nice clean setup for doing things via package builds and not so much for raw source tree builds...
(In reply to comment #28) > i'll get a compiled tree over to the tablet somehow and run it that way, > it's just i have a nice clean setup for doing things via package builds and > not so much for raw source tree builds... That would be appreciated. I've only ever used self built igt, so don't know about packaging... We should also fix intel_reg_dumper for BYT; for now only the quick_dump.py tool works.
Created attachment 93877 [details] quick_dump.py -a output on v8p Adding the quick_dump.py -a output from a v8p here too.
Note to everyone for whom the video=VGA-1:1366x768 w/a doesn't work any more: You need to add an e at the end, like this: video=VGA-1:1366x768e
I've checked today's on Asus T100TA drm-intel-nightly: 2014y-02m-11d-17h-13m-38s integration manifest with parameters: video=VGA-1:1366x768@60e or video=VGA-1:1366x768@60 and with or without reverted commit 16b23af. All of these configurations finished with black screen after i915 was loaded. When I've switched back to drm-intel-nightly: 2014y-02m-07d-17h-04m-06s integration manifest configuration with video=VGA-1:1366x768@60 and reverted commit 16b23af worked fine.
jacek: so, that sounds like a new bug in drm-intel-nightly, possibly to be filed separately? this one's already getting a tad jumbled.
Yeah, it looks like new bug, but I've no time for bisection yet.
The 'e' trick works here too, though it causes a whole bunch of warn_slowpath_common's , it looks like. More later.
er, sorry - that is, I can drop the reversion of the hotplug change and still get successful modesetting if I use the 'e' trick, but I get a bunch of warn_slowpath_commons which look like they come from the output detection code.
Oh, it's not a warn_slowpath_common, doesn't look like, just a warn. Here's the first untainted one, will attach the complete boot log: Feb 11 14:46:17 fedlet.happyassassin.net kernel: ------------[ cut here ]------------ Feb 11 14:46:17 fedlet.happyassassin.net kernel: WARNING: CPU: 0 PID: 253 at drivers/gpu/drm/i915/intel_dp.c:109 intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915]() Feb 11 14:46:17 fedlet.happyassassin.net kernel: invalid max DP link bw val 0, using 1.62Gbps Feb 11 14:46:17 fedlet.happyassassin.net kernel: Modules linked in: mmc_block i915(+) i2c_algo_bit drm_kms_helper drm i2c_core video sdhci_acpi sdhci mmc_core usb_storage Feb 11 14:46:17 fedlet.happyassassin.net kernel: CPU: 0 PID: 253 Comm: systemd-udevd Not tainted 3.14.0-0.rc2.git1.1.1awb.i686 #1 Feb 11 14:46:17 fedlet.happyassassin.net kernel: Hardware name: DellInc. Venue 8 Pro 5830/09RP78, BIOS A04 12/04/2013 Feb 11 14:46:17 fedlet.happyassassin.net kernel: c0d679c7 2230178a 00000000 f64979fc c0abbcdb f6497a3c f6497a2c c04514ee Feb 11 14:46:17 fedlet.happyassassin.net kernel: f91d7ca0 f6497a5c 000000fd f91d7abc 0000006d f919241f f919241f f6401300 Feb 11 14:46:17 fedlet.happyassassin.net kernel: 00006257 f6a6d800 f6497a48 c045154e 00000009 f6497a3c f91d7ca0 f6497a5c Feb 11 14:46:17 fedlet.happyassassin.net kernel: Call Trace: Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0abbcdb>] dump_stack+0x48/0x60 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04514ee>] warn_slowpath_common+0x7e/0xa0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f919241f>] ? intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f919241f>] ? intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c045154e>] warn_slowpath_fmt+0x3e/0x60 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f919241f>] intel_dp_max_link_bw.isra.5+0x3f/0x50 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f91928fe>] intel_dp_mode_valid+0x2e/0xd0 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f80f5167>] drm_helper_probe_single_connector_modes+0x1b7/0x360 [drm_kms_helper] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f80f75e1>] drm_fb_helper_probe_connector_modes.isra.3+0x41/0x60 [drm_kms_helper] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f80f8515>] drm_fb_helper_initial_config+0x165/0x490 [drm_kms_helper] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04a902b>] ? trace_hardirqs_on+0xb/0x10 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f91beafe>] intel_fbdev_initial_config+0x1e/0x20 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f914ffee>] i915_driver_load+0xd7e/0xdb0 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0974250>] ? intel_alloc_coherent+0x120/0x120 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f8c4b60c>] drm_dev_register+0x6c/0x140 [drm] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f8c4d6ea>] drm_get_pci_dev+0x8a/0x1e0 [drm] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04a902b>] ? trace_hardirqs_on+0xb/0x10 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f914c665>] i915_pci_probe+0x35/0x60 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0753c7f>] pci_device_probe+0x6f/0xc0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c061d475>] ? sysfs_create_link+0x25/0x40 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0825260>] driver_probe_device+0x110/0x380 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0753bd2>] ? pci_match_device+0xb2/0xc0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0825589>] __driver_attach+0x79/0x80 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0825510>] ? __device_attach+0x40/0x40 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c08234e7>] bus_for_each_dev+0x57/0xa0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0824c8e>] driver_attach+0x1e/0x20 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0825510>] ? __device_attach+0x40/0x40 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c08248a7>] bus_add_driver+0x157/0x230 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0825b69>] driver_register+0x59/0xe0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c075261a>] __pci_register_driver+0x4a/0x50 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f8c4d945>] drm_pci_init+0x105/0x110 [drm] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f85d8000>] ? 0xf85d7fff Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f85d8062>] i915_init+0x62/0x64 [i915] Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04004a2>] do_one_initcall+0xd2/0x190 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<f85d8000>] ? 0xf85d7fff Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0442f57>] ? set_memory_ro+0x37/0x40 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04dd62c>] load_module+0x1a7c/0x2480 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04d9559>] ? copy_module_from_fd.isra.46+0x109/0x1a0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c04de1dd>] SyS_finit_module+0x8d/0xd0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0564af3>] ? vm_mmap_pgoff+0x93/0xb0 Feb 11 14:46:17 fedlet.happyassassin.net kernel: [<c0acd70d>] sysenter_do_call+0x12/0x38 Feb 11 14:46:17 fedlet.happyassassin.net kernel: ---[ end trace ab0ef9173a974a7f ]--- Feb 11 14:46:17 fedlet.happyassassin.net kernel: ------------[ cut here ]------------ So yeah, it looks like the hotplug reversion is not needed if you add 'e' to the video= force.
Created attachment 93903 [details] full journalctl from a boot with 3.14.0-0.rc2.git1.1.1awb (hotplug detection enabled, video=800x1280@75e)
So...do we still need this open for anything? I don't think I'm carrying anything in Fedlet for this specific bug ATM, and we're covering the 'display detection / mode selection doesn't work because DSI' stuff in https://bugs.freedesktop.org/show_bug.cgi?id=74657 . I think we can close this one now. Let me know if there's a reason to keep it open. Is the warning worth reporting separately?
(In reply to comment #39) > So...do we still need this open for anything? I don't think I'm carrying > anything in Fedlet for this specific bug ATM, and we're covering the > 'display detection / mode selection doesn't work because DSI' stuff in > https://bugs.freedesktop.org/show_bug.cgi?id=74657 . I think we can close > this one now. Let me know if there's a reason to keep it open. > > Is the warning worth reporting separately? I'm not sure. Either it's a PEBKAC/feature or a bug. I think it's caused by you omitting the connector name in your video= parameter, which leads to connector ->fill_modes() callback for display port, which in turn fails because there is no monitor in the DP. Please try with video=VGA-1:800x1280@75e.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.