Rich Shepard | 3 Apr 01:24 2013

Distribution Upgrade: Frame Buffer Glitch

   I just upgraded my Dell Latitude from Slackware-13.37/X86_64 to
-14.0/X86_64, changed the links in /boot, modified /etc/lilo.conf, and ran
/sbin/lilo. When booting now the system hangs at this line:

fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver

   Not having encounted this issue before when upgrading a system I'm at a
loss of how to fix the problem. Pointers to a solution greatly appreciated!

Rich
Rich Shepard | 3 Apr 17:30 2013

Re: Distribution Upgrade: Frame Buffer Glitch

On Tue, 2 Apr 2013, Rich Shepard wrote:

>   Not having encounted this issue before when upgrading a system I'm at a
> loss of how to fix the problem. Pointers to a solution greatly
> appreciated!

   I should have mentioned that I searched the Web for this error and found
references to it happening with Red Hat, Ubuntu, and Slackware. Looking at
the linuxquestions.org thread for the latter (from 2010) I tried the
solution recommended there (uncommenting 'chipset VGA' in
/etc/vga/libvga.config) to no avail. Still hangs.

   In /etc/lilo.conf I still have an append line with nomodeset on it.

   I'd like to get this running today or tomorrow as I have a business trip
next week on which I'll need to use the laptop. Suggestions on what to check
are certainly appreciated.

   BTW, since the system will not complete booting I need an alternative way
of viewing and checking files. I boot the Slackware-14.0/x86_64 dvd and
accept defaults until I can log in as root. I then 'mount /dev/sda1 /mnt'
and this allows me to navigate to where changes need to be made, for
example, /mnt/etc/vga/.

Rich
Daniel Hedlund | 3 Apr 18:35 2013

Re: Distribution Upgrade: Frame Buffer Glitch

On Wed, Apr 3, 2013 at 8:30 AM, Rich Shepard <rshepard <at> appl-ecosys.com>wrote:

>    I'd like to get this running today or tomorrow as I have a business trip
>  next week on which I'll need to use the laptop. Suggestions on what to
> check
> are certainly appreciated.
>

I recently had to figure out how to disable the framebuffer completely
under Arch when trying to do a remote install inside a KVM guest over SSH.
 Yay for bookmarks.  See if any of the suggestions in the following post
help (including those mentioned in the original question):
http://serverfault.com/questions/361089/qemu-kvm-linux-virtualization-on-the-command-line
Rich Shepard | 3 Apr 18:56 2013

Re: Distribution Upgrade: Frame Buffer Glitch

On Wed, 3 Apr 2013, Daniel Hedlund wrote:

> I recently had to figure out how to disable the framebuffer completely
> under Arch when trying to do a remote install inside a KVM guest over SSH.
> Yay for bookmarks. See if any of the suggestions in the following post
> help (including those mentioned in the original question):
> http://serverfault.com/questions/361089/qemu-kvm-linux-virtualization-on-the-command-line

   Thanks, Daniel. I wonder how arch-specific that thread is.

   I've asked for help in the Slackware forum on linuxquestions.org and Pat
Volkerding provided one suggestion that did not work; I'm waiting for more
feedback to my latest update there.

   I've not had this issue on this laptop before so why it should suddenly
appear after the previous half-dozen or so distribution upgrades escapes my
knowledge base.

Rich
Dale Snell | 3 Apr 20:28 2013

Re: Distribution Upgrade: Frame Buffer Glitch

On Wed, 3 Apr 2013 09:56:30 -0700 (PDT)
Rich Shepard <rshepard <at> appl-ecosys.com> wrote:

> On Wed, 3 Apr 2013, Daniel Hedlund wrote:
> 
> > I recently had to figure out how to disable the framebuffer
> > completely under Arch when trying to do a remote install inside a
> > KVM guest over SSH. Yay for bookmarks. See if any of the
> > suggestions in the following post help (including those mentioned
> > in the original question):
> > http://serverfault.com/questions/361089/qemu-kvm-linux-virtualization-on-the-command-line
> 
>    Thanks, Daniel. I wonder how arch-specific that thread is.
> 
>    I've asked for help in the Slackware forum on linuxquestions.org
> and Pat Volkerding provided one suggestion that did not work; I'm
> waiting for more feedback to my latest update there.
> 
>    I've not had this issue on this laptop before so why it should
> suddenly appear after the previous half-dozen or so distribution
> upgrades escapes my knowledge base.
> 
> Rich

Rich,

This appears to be a kernel bug.  The line about "fb: conflicting fb
hw usage..." is a red herring.  It's simply the last line that gets
recorded before the kernel goes bye-bye.  It doesn't matter what
graphics chipset one uses, nor whether one boots with Grub, Grub2, or
(Continue reading)

Rich Shepard | 3 Apr 20:34 2013

Re: Distribution Upgrade: Frame Buffer Glitch

On Wed, 3 Apr 2013, Dale Snell wrote:

> This appears to be a kernel bug. The line about "fb: conflicting fb hw
> usage..." is a red herring. It's simply the last line that gets recorded
> before the kernel goes bye-bye. It doesn't matter what graphics chipset
> one uses, nor whether one boots with Grub, Grub2, or Lilo. The guilty
> kernels seem to be 3.5 and up. From some of the comments on Red Hat's
> Bugzilla, it appears that the bug was introduced in an early, non-release
> version of 3.5.0.

Dale,

   Well, that makes sense to me.

> Can you downgrade your kernel? That seems the most likely fix. 3.4.8
> should work (knock plastic!).

   The default kernel in Slackware-14.0 is 3.2.29 and that's what is
installed. It is interesting that the same kernel in the Sony Vaio booted
with no issues what-so-ever.

Thanks,

Rich
Rich Shepard | 3 Apr 23:15 2013

Re: Distribution Upgrade: Frame Buffer Glitch [RESOLVED ... SORTA']

On Wed, 3 Apr 2013, Dale Snell wrote:

> This appears to be a kernel bug.  The line about "fb: conflicting fb
> hw usage..." is a red herring.

Dale, et al.:

   I stumbled upon a kludge that works -- for now. When booting from the
Slackware distribution DVD one can specify options on the boot: command
line. I used the example on that display page and added the final option of
'fb=off' (without the quotes, of course). The system paused during the boot
process because I had specified to load the boot partition read only and it
was already mounted read-write. Pressing the [Enter] key allow the system to
complete the boot process.

   So, on this Dell Latitude with this Slackware distribution (-14.0/x86_64)
there is a definite problem with specifying a frame buffer (in my case the
VESA line is 'vga=773'). I reported this to Pat and the development team and
offered to perform other tests to identify just why there's a problem so
they can fix it.

Rich
Dale Snell | 4 Apr 02:10 2013

Re: Distribution Upgrade: Frame Buffer Glitch [RESOLVED ... SORTA']

On Wed, 3 Apr 2013 14:15:44 -0700 (PDT)
Rich Shepard <rshepard <at> appl-ecosys.com> wrote:

> On Wed, 3 Apr 2013, Dale Snell wrote:
> 
> > This appears to be a kernel bug.  The line about "fb: conflicting fb
> > hw usage..." is a red herring.
> 
> Dale, et al.:
> 
>    I stumbled upon a kludge that works -- for now. When booting from
> the Slackware distribution DVD one can specify options on the boot:
> command line. I used the example on that display page and added the
> final option of 'fb=off' (without the quotes, of course). The system
> paused during the boot process because I had specified to load the
> boot partition read only and it was already mounted read-write.
> Pressing the [Enter] key allow the system to complete the boot
> process.

Huzzah!  Glad to hear it!  From what I've been reading, this bug is
one of those really NASTY race problems that shows up whenever it
bloody well pleases.  Or when the moons all line up and beam bozo rays
into (some of) the systems.  Horrible problems to find.

>    So, on this Dell Latitude with this Slackware distribution
> (-14.0/x86_64) there is a definite problem with specifying a frame
> buffer (in my case the VESA line is 'vga=773'). I reported this to
> Pat and the development team and offered to perform other tests to
> identify just why there's a problem so they can fix it.

(Continue reading)

Rich Shepard | 4 Apr 02:45 2013

Re: Distribution Upgrade: Frame Buffer Glitch [RESOLVED ... SORTA']

On Wed, 3 Apr 2013, Dale Snell wrote:

> Huzzah!  Glad to hear it!  From what I've been reading, this bug is one of
> those really NASTY race problems that shows up whenever it bloody well
> pleases.  Or when the moons all line up and beam bozo rays into (some of)
> the systems.  Horrible problems to find.

Dale,

   Yeah. Pat Volkerding said he found > 2,000 forum messages on this bug
occuring in every linux distribution. It may be related to udev, but that's
way above my pay grade to understand.

> Best of luck. There are a lot of folks looking into this, but every
> little bit helps.

   The 'fix' is to set vga = normal in lilo.conf and not use any frame
buffers. If I correctly understand the situation the only thing frame
buffers do is show a penquin for each CPU core and use the defined screen
resolution from the beginning of the boot process. Turning off frame buffers
means no Tux and the screen resolution starts at 640x400 before switching to
a higher resolution about half way through the boot process.

> Once again, congratulations in getting your machine to run.

   Thanks. I need to take it on a business trip next week so having it fully
functional (except for virtualbox) is a Good Thing(TM).

   Tomorrow I'll boot it up again and try to find why it cannot find a
virtualbox library when it boots. Must be something in the core distribution
(Continue reading)


Gmane