upgrade to latest current (kernel 3.10.5): black screen
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
upgrade to latest current (kernel 3.10.5): black screen
I happily upgraded from 3.9.10 to the new kernel plus related upgrades, via slackpkg.
The machine is an asus zenbook, efi, i915... no troubles prior to the upgrade
All looked nice, the boot process whisked by, and then, suddenly there only was a black screen. Being in runmode 4, I switched to Console 1 (Ctrl-Alt-F1) which did not change this. All is black....
Rebooted from a setup usb, boots from the root at the hard disk, X is black also. But the console is readable. So I could change the runlevel to 3. Which worked only for the setup usb. The new kernel configuration went black again, this time without X...
[ 0.000000] Console: colour dummy device 80x25
[ 0.000000] console [tty0] enabled
[ 0.389454] efifb: probing for efifb
[ 0.397610] efifb: framebuffer at 0xe0000000, mapped to 0xffffc90009780000, using 16200k, total 65536k
[ 0.397614] efifb: mode is 1920x1080x32, linelength=7680, pages=1
[ 0.397616] efifb: scrolling: redraw
[ 0.397619] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 0.403992] Console: switching to colour frame buffer device 240x67
[ 0.409856] fb0: EFI VGA frame buffer device
This seems to show me the console text during the boot process, small letters....
[ 4.134164] fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
[ 4.135943] Console: switching to colour dummy device 80x25
[ 4.225918] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[ 4.225921] [drm] Driver supports precise vblank timestamp query.
[ 4.225966] vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 4.272584] fbcon: inteldrmfb (fb0) is primary device
[ 5.732026] [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
[ 6.258481] Console: switching to colour frame buffer device 240x67
[ 6.266437] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 6.266476] i915 0000:00:02.0: registered panic notifier
[ 6.276051] acpi device:28: registered as cooling_device5
[ 6.280574] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
[ 6.280646] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input10
[ 6.280748] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
This seems to be the stuff I cannot see.... and I don't know what of this is relevant.
I don't know how to move on from here. Way out of my depth
Thank you for any pointers in the right direction!
Distribution: Slint64-14.2beta3 on Lenovo Thinkpad W520
Two things you could try:
(1) append "nomodeset" (without the quotes) to your command line at boot time. This should prevent loading a framebuffer driver so handover won't occur and at least at run level 3 you shouldn't have a black screen. if that works you could set "vga = normal" (again, without the quotes) in /etc/lilo.conf.
(2) If that prevents X to start, fall back to a VESA X driver.
For that, just do this:
mv /etc/X11/xorg.conf-vesa /etc/X11/xorg.conf
Of course these suggestions are only temporary workarounds.
Last edited by Didier Spaier; 08-08-2013 at 05:24 PM.
First would suggest to (temporarily) remove all settings concerning the dreaded i915 module from kernel params as there were many changes in last releases. Guess you didn't forget to rerun lilo after a kernel update
Hmmmm, with or without the i915-related options, the kernel option "nomodeset" creates a console, X does not come up (no screens), and without nomodeset the console is black also. Various logs as seen above.
From inspecting /var/log/messages, the nomodeset option comes up with the dummy console. The efifb creates the unreadable console (I suppose).
PS. elilo does not have to be rerun. Only elilo.conf has to contain the correct kernel information.
I wonder if removing CONFIG_EFI_FB from the kernel configuration would help? To be honest, I'm not sure under what circumstances (if any) that is actually needed. I'm still experimenting with UEFI through emulation here, but even when I do get UEFI hardware I'll have limited configurations to be able to test with. Anyone know how important having the EFI FB enabled actually is?
IIRC VirtualBox in EFI-mode needs CONFIG_FB_EFI=y or you boot to a black screen. I found this comment that seems to suggest it (rwebber is commenting back when 13.37 was the latest stable, which did not have CONFIG_FB_EFI on):
Originally Posted by rwebber
It seems that an EFI system does not have normal VGA, or text mode or VESA framebuffer support, but requires the new EFI frame buffer support. It's even worse on VirtualBox because its video mode is not supported by Linux until you load the guest additions from a virtual CD. I suppose that someone with a real EFI system with a real video card that is supported in the kernel might have an easier time of it, though your screen may be black until the kernel finished loading.
Let me give some additional information. I seem to have given a wrong pointer to the efifb. This provides the working console. I did a thorough comparison between the black screen and the nomodeset version of /var/log/messages. A diff of video related stuff plus some log lines present in both versions will hopefully clear that up.
< kernel:  Linux version 3.10.5 (root@hive64) (gcc version 4.8.1 (GCC) ) #2 SMP Sun Aug 4 15:38:19 Ckernel:  Command line: BOOT_IMAGE=dev000:\EFI\BOOT\vmlinuz-huge-3.10.5 root=/dev/sda2 add_efi_mem
< kernel:  e820: BIOS-provided physical RAM map:
> kernel:  Linux version 3.10.5 (root@hive64) (gcc version 4.8.1 (GCC) ) #2 SMP Sun Aug 4 15:38:19 Ckernel:  Command line: BOOT_IMAGE=dev000:\EFI\BOOT\vmlinuz-huge-3.10.5 root=/dev/sda2 nomodeset akernel:  e820: BIOS-provided physical RAM map:
< kernel:  Kernel command line: BOOT_IMAGE=dev000:\EFI\BOOT\vmlinuz-huge-3.10.5 root=/dev/sda2 add_
kernel:  PCIe ASPM is forcibly enabled
> kernel:  Kernel command line: BOOT_IMAGE=dev000:\EFI\BOOT\vmlinuz-huge-3.10.5 root=/dev/sda2 nomo
kernel:  PCIe ASPM is forcibly enabled
in both versions fail and nomodeset:
kernel:  Console: colour dummy device 80x25
kernel:  console [tty0] enabled
kernel:  efifb: probing for efifb
kernel:  efifb: framebuffer at 0xe0000000, mapped to 0xffffc90009780000, using 16200k, total 65536kernel:  efifb: mode is 1920x1080x32, linelength=7680, pages=1
kernel:  efifb: scrolling: redraw
kernel:  efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
kernel:  Console: switching to colour frame buffer device 240x67
kernel:  fb0: EFI VGA frame buffer device
kernel:  GHES: HEST is not enabled!
< kernel:  [drm] Memory usable by graphics device = 2048M
< kernel:  fb: conflicting fb hw usage inteldrmfb vs EFI VGA - removing generic driver
< kernel:  Console: switching to colour dummy device 80x25
< kernel:  [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
< kernel:  [drm] Driver supports precise vblank timestamp query.
< kernel:  vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=iokernel:  fbcon: inteldrmfb (fb0) is primary device
< kernel:  [drm] Enabling RC6 states: RC6 on, RC6p off, RC6pp off
< kernel:  Console: switching to colour frame buffer device 240x67
< kernel:  i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
< kernel:  i915 0000:00:02.0: registered panic notifier
< kernel:  acpi device:28: registered as cooling_device5
< kernel:  ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no)
< kernel:  input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input10
< kernel:  [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0
< kernel:  [drm] GMBUS [i915 gmbus dpd] timed out, falling back to bit banging on pin 6
< kernel:  [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5
< kernel:  [drm] GMBUS [i915 gmbus panel] timed out, falling back to bit banging on pin 3
I hope someone will see this who can make sense of it....
Did the old kernel work? If all else fails, you could always disable your efi, unless of course you need it for something else. I have a Zenbook myself, and I set it in Legacy BIOS mode and have none of these complications. It's running 3.10.5 right now with no issues.
Incidentally, you do not need the i915_enable_rc6 kernel parameter anymore. That option is now enabled by default.
Thank you for asking, BN. Went back to 3.9.10 and it works nicely. Just used the -huge- config from 3.10.5
I haven't checked the details. I think there is some tweaking possible with newer kernels. While reading i saw some drivers to replace the usual generic ones. But I'm not sure if they apply to my machine ....
I think I'm quite happy with the efi stuff. After getting used to it, it is working nicely. Actually, I don't think it is connected to the present troubles. (efifb worked all the time)
I'll keep you updated if something new comes up...