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.

This sounds like a problem with kernel mode setting. Try to add as a boot parameter (replace the 1024x768 with your native screen resolution).

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.

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/

I have the same issue on my Dell Optiplex GX620, upgrading from 3.2.29 to 3.2.45.

Yikes! I was going to upgrade my kernel today but after reading these posts I think I will avoid it!

Yeah me too. Will hold on the urge of upgrading for some more time.

Regards.

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:

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.

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

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>

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
Rebooted, came up clean, working just fine (writing this on it with Xfce running).

Hope this helps.

I am affected by this as well on my Asus 1000he.

despite the name, the files has the same content (try with diff).