Bug 73133 - System hangs at X startup on Dell Venue 8 Pro (valleyview / baytrail tablet)
Summary: System hangs at X startup on Dell Venue 8 Pro (valleyview / baytrail tablet)
Status: CLOSED INVALID
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium blocker
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: v8p
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-30 02:31 UTC by Adam Williamson
Modified: 2017-07-24 22:56 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Williamson 2013-12-30 02:31:42 UTC
After https://bugs.freedesktop.org/show_bug.cgi?id=71977 , this is the next problem I'm hitting with graphics on the Dell Venue 8 Pro, a vlv / baytrail-based tablet. It's pretty simple: if I try and start X with modesetting enabled, the system hangs completely.

I've checked, and there's nothing useful in any log (X log or journal), even if I boot with drm.debug=15 . If I boot to runlevel 3 and run 'startx', all I see is the regular X startup process begins and when it loads the GLX extension, the system flat hangs. It's always right after GLX extension loads, for whatever that's worth. When I say 'hangs', I mean I can't get a response to anything - ctrl-c, ctrl-alt-f2, magic keys, nothing does anything. I can't check if the system responds to pings as the wireless adapter doesn't work.

I'm sure you'd want more info to debug this, but I'm not sure how I can get any more! Ideas are welcome.

X starts up fine on the system with modesetting disabled, though of course that's a very different path and uses a fallback X driver.

Note that I'm doing a 32-bit UEFI boot, which is somewhat unusual and may relate somehow. All these vlv / baytrail systems have 32-bit UEFI firmwares (and somewhere, mjg59 is weeping into his gin), so I've hacked up Fedora somewhat to be capable of 32-bit UEFI boot.

My current test images are built from Fedora Rawhide, which has a very recent X stack and kernel:

xorg-x11-server-common-1.14.99.904-1.fc21.x86_64
xorg-x11-drv-intel-2.21.15-12.fc21
libdrm-2.4.50-1.fc21.x86_64
mesa-dri-drivers-10.0.1-1.20131220.fc21.x86_64
kernel-3.13.0-0.rc5.git0.1.fc21.x86_64
Comment 1 Adam Williamson 2013-12-30 02:34:03 UTC
Oh, now I find the suggestion I knew someone had given me, in the old bug:

"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."
Comment 2 Jani Nikula 2013-12-30 09:23:37 UTC
A quick note, you might want to give drm-intel-nightly branch a shot:
http://cgit.freedesktop.org/~danvet/drm-intel/log/?h=drm-intel-nightly
Comment 3 Gilberto Tanzola 2013-12-30 14:08:06 UTC
I bet this has something to do with calling 32bit UEFI in 64bit userspace. Did you try any of this on a 32-bit Linux install? It sounds stupid because it is - the hardware is capable for crying out loud - but from what I've read there are ugly hacks required to call 32bit UEFI on a 64bit system, and I'm not familiar with how you even got this to boot.

I might be getting a Venue 8 Pro today, so if all goes well I'll hopefully be able to assist your debugging efforts.
Comment 4 Adam Williamson 2013-12-30 17:38:37 UTC
"Did you try any of this on a 32-bit Linux install?"

That's in fact precisely what I'm doing. I'm not using a 64-bit build.

Jani: I've been watching that drm-fixes and testing anything that looked relevant, but nothing's made any difference so far. It's somewhat tricky at least for me to get a build with the entirety of drm-intel-next into a Fedora image, I'm used to adding specific patches on top of the Fedora kernel build but not how you effectively 'substitute' it with an entire upstream branch, and it's not like there's some clean point from which I can just apply every single patch in drm-intel-next (I tried that, it didn't work).

If it's really important I can ask the kernel maintainers what would be the best way to try it, but if it's just a stock suggestion I'm not sure I'd go to the trouble.
Comment 5 Adam Williamson 2013-12-30 17:40:12 UTC
gilberto: I can give you a quick primer in building bootable Fedora images if you're interested, it boils down to a slightly ugly hack to Fedora's live image generation tool which causes it to spit out 32-bit live images that are UEFI bootable. The Ubuntu tweakers have been using a different approach on the t100 and similar systems where they found a build of grub2 from some random rescue CD which appears to be capable of bootstrapping a 64-bit environment from a 32-bit bootloader, but I haven't looked into that myself.
Comment 6 Adam Williamson 2013-12-30 17:45:07 UTC
Oh, I forgot: there's actually a backtrace earlier in boot which Alan Cox tells me is in graphics stuff:

https://bugzilla.kernel.org/show_bug.cgi?id=67861

that could be relevant.
Comment 7 Chris Wilson 2013-12-30 17:54:54 UTC
That backtrace is the kernel ACPI dying whilst trying to do the PCI probes for the GPU device. If that is in your boot then the driver dies before it even loads and nothing good can come of it.
Comment 8 Adam Williamson 2013-12-30 18:09:45 UTC
So should we close this one for now and focus on that one?
Comment 9 Jani Nikula 2013-12-31 13:12:16 UTC
(In reply to comment #8)
> So should we close this one for now and focus on that one?

As Chris says, if you have that in the boot, the driver has failed irrecoverably already.


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.