LinuxQuestions.org
View the Most Wanted LQ Wiki articles.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices



Reply
 
Search this Thread
Old 05-21-2013, 12:35 AM   #1
Eldarby
LQ Newbie
 
Registered: May 2011
Distribution: Arch
Posts: 25

Rep: Reputation: 1
Unhappy Upgrading Slackware 14 to Kernel 3.2.45 resulted in black screen on boot.


I just grabbed the latest kernel upgrade for Slackware 14.0 over slackpkg. It was released a few hours ago, by the way. All I did was grab the updated packages, I didn't muck around in menuconfig or anything crazy like that. After rebooting, I get a black screen part way through the boot process. It happens so fast I can't figure out exactly at what part everything goes black, but the system does boot up properly, I just can't see anything. I can tell it's not hung because pressing (not holding) the power button and waiting patiently makes it turn off eventually, as if it were going through its shutdown scripts for a clean shutdown.

I made sure to do all the necessary steps after upgrading the kernel packages, too. I re-ran mkinitrd. I changed the System.map, config and vmlinuz symlinks to point to their generic counterparts. After that, I ran lilo, then rebooted. Pretty sure I'm not missing anything here, but now I've got this black screen keeping me from using my laptop.

I've made sure to have vga=normal in my lilo.conf (it was always like that anyway). I also tried falling back on the huge kernel but that gives me the same problem. I even changed the rc.modules symlink in /etc to point to the new rc.modules file, and I don't even know if I'm supposed to do that or not, but I tried it nonetheless and I still have the same issue. Forgot to mention, I'm also using runlevel 3, not 4, so this certainly isn't a KDM issue.

I can boot into my installation by using a Slackware DVD but I'm going to have to solve this so I can boot into the new, upgraded kernel from the hard drive.

As I was typing this, I thought of one thing that *might* be causing trouble but it's just a shot in the dark (ha ha). I have a larger than normal console font I chose during the Slackware setup. It's possible that the screen is going blank when the font is about to change, because I can see *some* of the boot output while the font looks like it's at its default. So I can see if this is causing the problem, could someone please tell me how to revert back to the default font, to make it as if I'd never ran setconsolefont in the first place? Success or fail I'll come back here to report what I find, in case anyone else is running into this problem after making this upgrade.

I'm running an Asus EeePC 1000HE. In case it helps, here's the output of lspci|grep VGA:
00:02.0 VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03)

Thanks to anyone who can help.

Last edited by Eldarby; 05-21-2013 at 12:25 PM. Reason: Because it's just not an Eldarby post without being edited. :p
 
Old 05-21-2013, 12:38 AM   #2
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,650
Blog Entries: 2

Rep: Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095Reputation: 4095
This sounds like a problem with kernel mode setting. Try to add
Code:
video=1024x768@60
as a boot parameter (replace the 1024x768 with your native screen resolution).
 
Old 05-21-2013, 04:33 AM   #3
Diantre
Member
 
Registered: Jun 2011
Distribution: Slackware64 14.1
Posts: 396

Rep: Reputation: 153Reputation: 153
Quote:
Originally Posted by Eldarby View Post
So I can see if this is causing the problem, could someone please tell me how to revert back to the default font, to make it as if I'd never ran setconsolefont in the first place?
Code:
# chmod -x /etc/rc.d/rc.font
 
Old 05-21-2013, 05:25 AM   #4
zakame
Member
 
Registered: Apr 2012
Distribution: Debian, Ubuntu, Slackware
Posts: 134

Rep: Reputation: 53
Confirming this with my update from 3.2.29 to 3.2.45 on my ThinkPad X61. I can work around it with the nomodeset kernel parameter for now.
 
Old 05-21-2013, 05:37 AM   #5
faefae
LQ Newbie
 
Registered: Jul 2009
Posts: 3

Rep: Reputation: 0
Unhappy

And I have same issue with my Dell Inspiron 6400 (intel kms) and kernel 3.2.45

btw: another thread
http://www.linuxquestions.org/questi...en-4175462798/

Last edited by faefae; 05-21-2013 at 06:11 AM.
 
Old 05-21-2013, 09:18 AM   #6
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,274

Rep: Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587
I have the same issue on my Dell Optiplex GX620, upgrading from 3.2.29 to 3.2.45.
 
Old 05-21-2013, 09:46 AM   #7
digger95
Member
 
Registered: Oct 2007
Location: Indiana, PA
Distribution: Slackware 14
Posts: 330

Rep: Reputation: 45
Yikes! I was going to upgrade my kernel today but after reading these posts I think I will avoid it!
 
Old 05-21-2013, 10:33 AM   #8
PrinceCruise
Member
 
Registered: Aug 2009
Location: /Universe/Earth/India/Pune
Distribution: Slackware64 14.1/Current, CentOS 6.5/7.0
Posts: 792

Rep: Reputation: Disabled
Yeah me too. Will hold on the urge of upgrading for some more time.

Regards.
 
Old 05-21-2013, 10:39 AM   #9
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,902

Rep: Reputation: 963Reputation: 963Reputation: 963Reputation: 963Reputation: 963Reputation: 963Reputation: 963Reputation: 963
I upgraded the kernel earlier on one of my Slackware64 14.0 installs and while I could boot successfully into runlevel 3, if I tried to run X the screen froze after a few minutes. After a forced reboot I found the following line in my syslog:

Code:
May 21 14:16:06 slack-netbook kernel: [  208.230583] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Rather than spend too much time on this I decided to just upgrade to the 3.8.13 kernel packages from Slackware64-current. So far so good with 3.18.13.
 
Old 05-21-2013, 11:13 AM   #10
hitest
Senior Member
 
Registered: Mar 2004
Location: Prince Rupert, B.C., Canada
Distribution: Slackware, OpenBSD
Posts: 4,274

Rep: Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587Reputation: 587
Quote:
Originally Posted by ruario View Post
Rather than spend too much time on this I decided to just upgrade to the 3.8.13 kernel packages from Slackware64-current. So far so good with 3.18.13.
That was my solution as well, that is, I upgraded my main box to Slackware-current(32 bit). All is well now. I do have one Slackware 14.0 box that I have not upgraded.
 
Old 05-21-2013, 11:36 AM   #11
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
I don't have any intel hardware here to make some tests, but my bet is that reverting one of the last 8 days commits from here will help

https://git.kernel.org/cgit/linux/ke...qt=grep&q=i915
 
Old 05-21-2013, 11:43 AM   #12
blancamolinos
LQ Newbie
 
Registered: Mar 2011
Posts: 7

Rep: Reputation: 1
Here are the 5 changes in the ChangeLog for the 3.2.45 kernel in relation to drm/i915:


commit 53e587aa5ca81497d0ea6e340320ec5778d1f311
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Nov 15 11:32:18 2012 +0000

drm/i915: Fix detection of base of stolen memory

commit e12a2d53ae45a69aea499b64f75e7222cca0f12f upstream.

The routine to query the base of stolen memory was using the wrong
registers and the wrong encodings on virtually every platform.

It was not until the G33 refresh, that a PCI config register was
introduced that explicitly said where the stolen memory was. Prior to
865G there was not even a register that said where the end of usable
low memory was and where the stolen memory began (or ended depending
upon chipset). Before then, one has to look at the BIOS memory maps to
find the Top of Memory. Alas that is not exported by arch/x86 and so we
have to resort to disabling stolen memory on gen2 for the time being.

Then SandyBridge enlarged the PCI register to a full 32-bits and change
the encoding of the address, so even though we happened to be querying
the right register, we read the wrong bits and ended up using address 0
for our stolen data, i.e. notably FBC.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2: adjust filename, context]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

---------------------------------------------------------------------------------------
commit fcf565be6168313624ac7c0d34d64c92fc967a81
Author: David Müller (ELSOFT AG) <d.mueller@elsoft.ch>
Date: Fri Apr 19 10:41:50 2013 +0200

drm/i915: Fall back to bit banging mode for DVO transmitter detection

commit e4bfff54ed3f5de88f5358504c78c2cb037813aa upstream.

As discussed in this thread
http://lists.freedesktop.org/archive...il/037411.html
GMBUS based DVO transmitter detection seems to be unreliable which could
result in an unusable DVO port.

The attached patch fixes this by falling back to bit banging mode for
the time DVO transmitter detection is in progress.

Signed-off-by: David Müller <d.mueller@elsoft.ch>
Tested-by: David Müller <d.mueller@elsoft.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
-------------------------------------------------------------------------
commit 19c42ce9869ff30f43a08fb774d08f35b92b5ff6
Author: Jani Nikula <jani.nikula@intel.com>
Date: Fri Apr 12 15:18:38 2013 +0300

drm/i915: ensure single initialization and cleanup of backlight device

commit dc652f90e088798bfa31f496ba994ddadd5d5680 upstream.

Backlight cleanup in the eDP connector destroy callback caused the
backlight device to be removed on some systems that first initialized LVDS
and then attempted to initialize eDP. Prevent multiple backlight
initializations, and ensure backlight cleanup is only done once by moving
it to modeset cleanup.

A small wrinkle is the introduced asymmetry in backlight
setup/cleanup. This could be solved by adding refcounting, but it seems
overkill considering that there should only ever be one backlight device.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Peter Verthez <peter.verthez@skynet.be>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2:
- Adjust context
- s/dev_priv->backlight\.device/dev_priv->backlight/]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
-------------------------------------------------------------------------
commit 0bdb6ae5a6447214693e9de94df3611cea80357a
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Apr 4 21:31:03 2013 +0100

drm/i915: Workaround incoherence between fences and LLC across multiple CPUs

commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06 upstream.

In order to fully serialize access to the fenced region and the update
to the fence register we need to take extreme measures on SNB+, and
manually flush writes to memory prior to writing the fence register in
conjunction with the memory barriers placed around the register write.

Fixes i-g-t/gem_fence_thrash

v2: Bring a bigger gun
v3: Switch the bigger gun for heavier bullets (Arjan van de Ven)
v4: Remove changes for working generations.
v5: Reduce to a per-cpu wbinvd() call prior to updating the fences.
v6: Rewrite comments to ellide forgotten history.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=62191
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Tested-by: Jon Bloomfield <jon.bloomfield@intel.com> (v2)
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
[bwh: Backported to 3.2: insert the cache flush in i915_gem_object_get_fence()]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---------------------------------------------------------------------------------
commit d05fd48ac4d98b09ace5320a7b9f5bd52032007c
Author: Christian Lamparter <chunkeey@googlemail.com>
Date: Wed Apr 3 14:34:11 2013 +0200

drm/i915: Add no-lvds quirk for Fujitsu Esprimo Q900

commit 9e9dd0e889c76c786e8f2e164c825c3c06dea30c upstream.

The "Mobile Sandy Bridge CPUs" in the Fujitsu Esprimo Q900
mini desktop PCs are probably misleading the LVDS detection
code in intel_lvds_supported. Nothing is connected to the
LVDS ports in these systems.

Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
 
Old 05-21-2013, 11:48 AM   #13
tronayne
Senior Member
 
Registered: Oct 2003
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
Posts: 3,119

Rep: Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818Reputation: 818
Don't know if this will help anybody else but... (see http://www.linuxquestions.org/questi...9/#post4955810.

When one of my data base servers (the only one I've updated) wouldn't boot, booted from the DVD, I went looking and found that /etc/rc.modules was still linked to rc.modules-3.2.29-smp. Re-did that to
Code:
cd /etc/rc.d
ls -al rc.modu*
lrwxrwxrwx 1 root root    21 May 21 11:28 rc.modules -> rc.modules-3.2.45-smp*
-rwxr-xr-x 1 root root 35406 Sep 17  2012 rc.modules-3.2.29*
-rwxr-xr-x 1 root root 35406 Sep 17  2012 rc.modules-3.2.29-smp*
-rwxr-xr-x 1 root root 35406 May 18 03:10 rc.modules-3.2.45*
-rwxr-xr-x 1 root root 35406 May 18 02:10 rc.modules-3.2.45-smp*
Rebooted, came up clean, working just fine (writing this on it with Xfce running).

Hope this helps.
 
Old 05-21-2013, 11:53 AM   #14
ryanpcmcquen
Member
 
Registered: Apr 2013
Distribution: Slackware
Posts: 74

Rep: Reputation: Disabled
I am affected by this as well on my Asus 1000he.
 
Old 05-21-2013, 12:01 PM   #15
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,498

Rep: Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912Reputation: 912
Quote:
Originally Posted by tronayne View Post
Code:
cd /etc/rc.d
ls -al rc.modu*
lrwxrwxrwx 1 root root    21 May 21 11:28 rc.modules -> rc.modules-3.2.45-smp*
-rwxr-xr-x 1 root root 35406 Sep 17  2012 rc.modules-3.2.29*
-rwxr-xr-x 1 root root 35406 Sep 17  2012 rc.modules-3.2.29-smp*
-rwxr-xr-x 1 root root 35406 May 18 03:10 rc.modules-3.2.45*
-rwxr-xr-x 1 root root 35406 May 18 02:10 rc.modules-3.2.45-smp*
despite the name, the files has the same content (try with diff).
 
  


Reply

Tags
black screen, kernel, slackware 14, upgrade


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Laptop with via chrome9 slackware black screen on boot splintercdo Linux - Laptop and Netbook 14 02-05-2011 09:07 AM
Activated desktop effects in Ubuntu and resulted in black screen Mooney Linux - Newbie 1 05-23-2008 12:25 PM
PC failed to boot with a dark screen resulted satimis Linux - Hardware 9 05-16-2007 09:59 PM
Slackware 9.1 new kernel compile displays black screen on boot. Krenn Slackware 3 03-29-2004 03:33 PM
Black screen during boot up after new 2.6.1 kernel cjdock Slackware 17 02-01-2004 04:36 PM


All times are GMT -5. The time now is 08:09 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration