| View previous topic :: View next topic |
| Author |
Message |
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
 Posted: Sun May 10, 2015 2:07 am Post subject: Acer Aspire E1-572 modesetting black screen problems |
 |
|
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
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
00:02.0 VGA compatible controller: Intel Corporation Haswell-ULT Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller])
Subsystem: Acer Incorporated [ALI] Device 0775
Flags: bus master, fast devsel, latency 0, IRQ 7
Memory at b0000000 (64-bit, non-prefetchable) [size=4M]
Memory at a0000000 (64-bit, prefetchable) [size=256M]
I/O ports at 3000 [size=64]
Expansion ROM at <unassigned> [disabled]
Capabilities: [90] MSI: Enable- Count=1/1 Maskable- 64bit-
Capabilities: [d0] Power Management version 2
Capabilities: [a4] PCI Advanced Features |
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)
00:14.0 0c03: 8086:9c31 (rev 04)
00:16.0 0780: 8086:9c3a (rev 04)
00:1b.0 0403: 8086:9c20 (rev 04)
00:1c.0 0604: 8086:9c14 (rev e4)
00:1c.3 0604: 8086:9c16 (rev e4)
00:1d.0 0c03: 8086:9c26 (rev 04)
00:1f.0 0601: 8086:9c43 (rev 04)
00:1f.2 0106: 8086:9c03 (rev 04)
00:1f.3 0c05: 8086:9c22 (rev 04)
01:00.0 0200: 14e4:16b3 (rev 01)
01:00.1 0805: 14e4:16bc (rev 01)
02:00.0 0280: 168c:0036 (rev 01) |
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. |
|
| Back to top |
|
 |
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Sun May 10, 2015 7:21 am Post subject: Re: Acer Aspire E1-572 modesetting black screen problems |
|
|
| 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 |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Sun May 10, 2015 8:01 am Post subject: Re: Acer Aspire E1-572 modesetting black screen problems |
|
|
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. |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Sun May 10, 2015 9:47 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Sun May 10, 2015 10:02 am Post subject: |
|
|
| 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? |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Sun May 10, 2015 3:58 pm Post subject: |
|
|
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 |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Mon May 11, 2015 10:48 am Post subject: |
|
|
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. 
Current config:
http://pastebin.com/58wXF0FV |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Mon May 11, 2015 1:33 pm Post subject: |
|
|
| 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 ... |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Mon May 11, 2015 7:09 pm Post subject: |
|
|
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. |
|
| Back to top |
|
|
charles17
Advocate
Joined: 02 Mar 2008
Posts: 3664
|
| Posted: Tue May 12, 2015 4:48 am Post subject: |
|
|
| You could do a git bisect like I did with my above mentioned black screen problem and post the confusion as a bug upstream. |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Tue May 12, 2015 10:25 am Post subject: |
|
|
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 ? |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Tue May 12, 2015 8:01 pm Post subject: |
|
|
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)?! |
|
| Back to top |
|
|
VoidMage
Watchman
Joined: 14 Oct 2006
Posts: 6196
|
| Posted: Wed May 13, 2015 1:49 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
kernelwarrior
n00b
Joined: 08 May 2015
Posts: 8
|
| Posted: Thu May 14, 2015 3:18 am Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
|
Kernel & Hardware
