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:
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."
A quick note, you might want to give drm-intel-nightly branch a shot:
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.
"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.
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.
Oh, I forgot: there's actually a backtrace earlier in boot which Alan Cox tells me is in graphics stuff:
that could be relevant.
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.
So should we close this one for now and focus on that one?
(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.