| Summary: | System hangs at X startup on Dell Venue 8 Pro (valleyview / baytrail tablet) | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Adam Williamson <adamw> |
| Component: | DRM/Intel | Assignee: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Status: | CLOSED INVALID | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | blocker | ||
| Priority: | medium | CC: | intel-gfx-bugs |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | v8p | ||
| i915 platform: | i915 features: | ||
|
Description
Adam Williamson
2013-12-30 02:31:42 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." 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 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: https://bugzilla.kernel.org/show_bug.cgi?id=67861 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. |
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.