# Acer Aspire E1-572 modesetting black screen problems

## kernelwarrior

Freshly minted Gentoo-hardened from May 1st stage3, running kernel 3.18.9-hardened once all of the updates have finished.

Acer Aspire E1-572/EA50_HW, BIOS V2.14 01/15/2014

This is a Haswell incarnation with i3-4010U.

lspci -v:

 *Quote:*   

> 00:00.0 Host bridge: Intel Corporation Haswell-ULT DRAM Controller (rev 09)
> 
>         Subsystem: Acer Incorporated [ALI] Device 0775
> 
>         Flags: bus master, fast devsel, latency 0
> ...

 

lspci -n:

 *Quote:*   

> 00:00.0 0600: 8086:0a04 (rev 09)
> 
> 00:02.0 0300: 8086:0a16 (rev 09)
> 
> 00:03.0 0403: 8086:0a0c (rev 09)
> ...

 

I've tried every combination of frame buffer/fbcon driver, but once I boot the new kernel, I'm always left with a black screen before the startup sequence completes.

GRUB Setting:

GRUB_CMDLINE_LINUX="acpi_osi=Linux acpi_backlight=vendor"

Only adding a nomodeset fixes the problem, but obviously this solves the problem by throwing it out of the window.

Kernel configuration: HERE

I found desperate attempts to mitigate problems like this before in previous kernels, such as i915.i915_ignore_edp_bpp=1, but this code is not present in this kernel's i915 driver.

I'm surprised to see problems like this still happening.

----------

## charles17

 *kernelwarrior wrote:*   

> 
> 
> I've tried every combination of frame buffer/fbcon driver, but once I boot the new kernel, I'm always left with a black screen before the startup sequence completes.
> 
> 

 Would also external monitors stay black? See https://forums.gentoo.org/viewtopic-t-1000108.html

----------

## kernelwarrior

 *charles17 wrote:*   

> Would also external monitors stay black? See https://forums.gentoo.org/viewtopic-t-1000108.html

 I've never used the external monitor port, ever.  This is a brand new laptop, and gentoo's the first operating system I've loaded on it.  I'm not using EFI, by the way.

I can try plugging something into the port just for kicks, of course.

----------

## VoidMage

 *kernelwarrior wrote:*   

> I'm not using EFI, by the way. 

 

Why ?...Actually, can you even do that on anything produced in the last couple years?

Anyway, I'd say CONFIG_FB_EFI is the thing you're looking for.

Setting both COFIG_FB_SIMPLE and CONFIG_X86_SYSFB shouldn't hurt either.

----------

## kernelwarrior

 *VoidMage wrote:*   

> Why ?...Actually, can you even do that on anything produced in the last couple years?
> 
> Anyway, I'd say CONFIG_FB_EFI is the thing you're looking for.
> 
> Setting both COFIG_FB_SIMPLE and CONFIG_X86_SYSFB shouldn't hurt either.

 This laptop is a "transitional" model that lets me select what sort of BIOS/startup environment to use.  I associate EFI with all sorts of painful hassles with "secure loaders", etc, that I want no part of.

This laptop powers and starts up like every other old-school PC BIOS system in its current configuration.

Are you saying that even when it uses the "classic" BIOS to boot, I would need to build + install the FB_EFI driver as well?

----------

## VoidMage

The so called "Secure Boot" is but a side issue in UEFI, with only a potential danger of Microsoft using it to inflict vendor lock-in upon users.

Well, I'm not quite sure about transitional mixes, as my old machine was pure BIOS and the new went straight to UEFI/GPT, but "left with a black screen before the startup sequence completes" sure sounds like "boots as UEFI without CONFIG_FB_EFI" to me. Though if that's a hybrid problem, then no idea

----------

## kernelwarrior

Weird.  Enabling CONFIG_FB_EFI seemed to fix the problem.

I'd still like to know why, since I don't see EFI being involved in the boot process at all.  :Sad: 

Current config:

http://pastebin.com/58wXF0FV

----------

## charles17

 *kernelwarrior wrote:*   

> Weird.  Enabling CONFIG_FB_EFI seemed to fix the problem.
> 
> I'd still like to know why, since I don't see EFI being involved in the boot process at all.  

 

Have you checked the kernel buglist?  Maybe it's a known issue ...

----------

## kernelwarrior

There don't seem to be any open bugs for the i915 driver that resemble this problem.  I'm puzzled why despite generally "good" support of Linux by Intel for their hardware, there are so many problems with the i915 driver.  Going through the various kernels, I see midden heaps of broken bodies and tanker trucks' worth of blood harvested from those trying to get their hardware fully supported without issues.

The laptop (netbook?) is a cheap-and-cheerful Haswell ($350-ish, so no fancy hybrid GPUs, etc), but its CPU DOES offer PCID support for strong UDEREF, which is why I took the plunge on it.

I have no complaints other than the issues with the display driver.  I don't use X on it, but fear how much drama that would entail.

----------

## charles17

You could do a git bisect like I did with my above mentioned black screen problem and post the confusion as a bug upstream.

----------

## VoidMage

TBH, I don't think this is a bug, more like a case of things working is a way different than you understand it.

Anyway, are you sure your system isn't booting in UEFI mode or do you just think so ?

----------

## kernelwarrior

What would be a conclusive test that would determine how things are working, actually?  When set to "Classic" BIOS startup "mode", the notebook starts, boots from USB/DVD/UNDI (I used PXE to bootstrap it) as configured.  When started in EFI mode, none of this seems to work.

Are you saying that the "Classic BIOS" versus "EFI" is just a "GUI" and basic operational toggle rather than changing the way a fundamental way the system is initialised and whatever "runtime environment" is available to stage 1 boot loaders?

Besides which, why aren't these display drivers taking over the task of display configuration and initialisation anyway?  I am accustomed to Linux "taking over" complete control over devices, especially things like display controllers once the kernel's started.  Surely, it's not making callbacks into the BIOS (EFI or otherwise)?!

----------

## VoidMage

 *kernelwarrior wrote:*   

> Are you saying that the "Classic BIOS" versus "EFI" is just a "GUI" and basic operational toggle rather than changing the way a fundamental way the system is initialised and whatever "runtime environment" is available to stage 1 boot loaders? 

 

Where did you get that idea from ? I was just trying to verify if you didn't mix things up.

As for the drivers, if they were built as modules, they're taking over once the modules are getting loaded, which is happens in a fairly late stage of boot.

----------

## kernelwarrior

 *VoidMage wrote:*   

> As for the drivers, if they were built as modules, they're taking over once the modules are getting loaded, which is happens in a fairly late stage of boot.

 I know that's what they should be doing, but why then the need for an "EFI framebuffer driver" when the hardware is i915?  I would expect that any driver would perform "cold" setup/initialisation of the hardware no matter what the BIOS of the machine did to it.  Is this a peculiarity of laptops?  I've never had to enable "EFI" drivers on desktop systems with discrete NVIDIA graphics cards.  I'd never have imagined needing to enable such a thing, actually.

I realise there are some aspects of the lowest levels of the machine, CPU + "North Bridge" memory controller related things that are probably "one-off" setups that the BIOS sets and cannot be changed by subsequent stages.

----------

