LinuxQuestions.org
Visit the LQ Articles and Editorials section
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 04-03-2013, 11:48 AM   #1
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Rep: Reputation: 15
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

I should mention 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/.

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

Last edited by rshepard; 04-03-2013 at 11:49 AM.
 
Old 04-03-2013, 11:54 AM   #2
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
/etc/vga/ is used only for svgalib and is not likely to be related to your problem, or even anything that you're running. It's hardly used these days.

I'd make sure that vga=normal and get rid of nomodeset in lilo.conf, and reinstall lilo.
 
Old 04-03-2013, 12:44 PM   #3
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by volkerdi View Post
/etc/vga/ is used only for svgalib and is not likely to be related to your problem, or even anything that you're running. It's hardly used these days.

I'd make sure that vga=normal and get rid of nomodeset in lilo.conf, and reinstall lilo.
I changed from vga=773 to vga=normal and removed nomodeset from the append line. Then ran /sbin/lilo. Rebooting still hangs at the same error.

For context, I think it was -12.0 that I first installed on this laptop and has no problems upgrading distributions through 13.37. I did not see anything in the CHANGES_AND_HINTS file relating to this issue. Also, I'm trying to boot the generic-smp kernel, not the huge kernel; I used the script in the UPGRADE file to make a new initrd.

Booting with the 3.2.29 huge kernel makes it one line past the fb error before it, too, hangs. The huge kernel hangs here:

input: PS/2 Generic Mouse as /devices/platform/i8042/serio1/input/input7

Rich
 
Old 04-03-2013, 02:09 PM   #4
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,661

Rep: Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236
I'd try blacklisting the Intel driver and see what happens.

Till this problem be solved you could use the vesa driver for X as a fall back.

Last edited by Didier Spaier; 04-03-2013 at 02:11 PM.
 
Old 04-03-2013, 02:38 PM   #5
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by Didier Spaier View Post
I'd try blacklisting the Intel driver and see what happens.

Till this problem be solved you could use the vesa driver for X as a fall back.
Didier,

Please point me to where I blacklist the Intel driver (it's not in lilo.conf that I can see) and how I tell the system to use the VESA driver. If it matters, I boot into runlevel 3, not 4.

It was suggested that this might be a kernel issue but that seems to be with the 3.5.x kernel series and when I upgraded the Sony Vaio laptop here to -14.0 there was no issue.

Thanks,

Rich

Last edited by rshepard; 04-03-2013 at 02:41 PM.
 
Old 04-03-2013, 02:49 PM   #6
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Do you still have xf86-video-fbdev installed? That was removed way back before Slackware 13.0 was released, and causes known conflicts with newer versions of X. Among other things, it prevents X from starting up without an xorg.conf, which is the preferred way of doing things now. If you have an old xorg.conf, you should at least rename it to try running without it since it probably has references to obsolete drivers.

Also, you didn't say, but if you're trying to boot into runlevel 4, I'd recommend changing /etc/inittab to use runlevel 3 until the machine is booting properly.
 
Old 04-03-2013, 03:00 PM   #7
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by volkerdi View Post
Do you still have xf86-video-fbdev installed? That was removed way back before Slackware 13.0 was released, and causes known conflicts with newer versions of X. Among other things, it prevents X from starting up without an xorg.conf, which is the preferred way of doing things now. If you have an old xorg.conf, you should at least rename it to try running without it since it probably has references to obsolete drivers.

Also, you didn't say, but if you're trying to boot into runlevel 4, I'd recommend changing /etc/inittab to use runlevel 3 until the machine is booting properly.
Pat,

xf86-video-fbdev is in /var/cache/packages/extra/, but apparently not installed. There no longer is an xorg.conf file; that was removed in, I believe, 13.0. As I wrote in my response to Didier I boot into runlevel 3.

Thanks,

Rich
 
Old 04-03-2013, 03:20 PM   #8
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
How long have you waited after the machine halts? Some of the messages I read about this (there are a couple thousand out there referencing this error, for every distribution!) said that the boot may continue after a few minutes.

If this has anything to do with that firmware loading delay the udev maintainers inserted to punish us all (or for some other reason that's not clear), then perhaps putting the i915 module into your initrd could help. It'll probably pull in a lot of other related modules as well.

Just a guess... I'm not finding a lot of solutions in the threads that talk about this.
 
Old 04-03-2013, 04:10 PM   #9
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by volkerdi View Post
How long have you waited after the machine halts? Some of the messages I read about this (there are a couple thousand out there referencing this error, for every distribution!) said that the boot may continue after a few minutes.

If this has anything to do with that firmware loading delay the udev maintainers inserted to punish us all (or for some other reason that's not clear), then perhaps putting the i915 module into your initrd could help. It'll probably pull in a lot of other related modules as well.

Just a guess... I'm not finding a lot of solutions in the threads that talk about this.
Wait time: about 45 minutes now (lunch break).

Given that I've booted from the distribution DVD, how do I add the i915 module into the initrd?

Is there a way to turn off the framebuffer on the boot line? Or, any other option on the boot line that might provide more insight into what broke here?

Thanks,

Rich
 
Old 04-03-2013, 05:03 PM   #10
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Considering you said your lilo.conf was using vga=normal, there shouldn't be a framebuffer. But just in case -- when you boot, do you see penguins? If so, you're running a framebuffer. In that case I'd double check the lilo.conf to make sure there isn't maybe a duplicate vga= line lurking somewhere.
 
Old 04-03-2013, 05:06 PM   #11
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Oh, and the question about how to recreate the initrd. I'd mount the root partition on /mnt and chroot into it with "chroot /mnt", then run /usr/share/mkinitrd/mkinitrd_command_generator.sh to see the recommended command line to make the initrd. Use that line, but add to the list of modules :i915

First make sure you're not somehow starting up with a framebuffer active, because if you are that should be disabled first to see if that's the cause of the problem.
 
Old 04-03-2013, 05:09 PM   #12
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by volkerdi View Post
If this has anything to do with that firmware loading delay the udev maintainers inserted to punish us all (or for some other reason that's not clear), then perhaps putting the i915 module into your initrd could help. It'll probably pull in a lot of other related modules as well.
Pat,

I rebooted from the distribution DVD with the command line suggested above the boot: prompt, but I added 'fd=off' to the end. A lot of display flashing followed, then the system booted to a point where it told me that the boot disk was already loaded rw (I specified ro per the example) and showed that the Intel i915 driver was loaded. When I pressed the [Enter] key, it finished booting!

So, do I need to turn off all frame buffers with 'fb=off' on the append line? This might work as a temporary kludge, but I would really like to know why frame buffers are causing this laptop to not boot with this new distribution. I will gladly make all tests you want to isolate the reason for this issue and to allow for a fix.

Rich
 
Old 04-03-2013, 05:19 PM   #13
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
vga=normal in the lilo.conf is all that should be needed to not use a VESA framebuffer... which is why I was curious about whether you see penguins when you boot the machine without the installation DVD. Penguins == framebuffer.
 
Old 04-03-2013, 05:50 PM   #14
rshepard
Member
 
Registered: Oct 2007
Location: Troutdale, Oregon
Distribution: Slackware
Posts: 130

Original Poster
Rep: Reputation: 15
Quote:
Originally Posted by volkerdi View Post
vga=normal in the lilo.conf is all that should be needed to not use a VESA framebuffer... which is why I was curious about whether you see penguins when you boot the machine without the installation DVD. Penguins == framebuffer.
Pat,

I had changed lilo.conf from vga=773 to vga=normal but the system still did not boot to completion. I'll try again ... OK! Now it works. The initial font resolution looks like 640x400, then the screen blanks and continues at 1024x768.

Yes, I would see 4 penguins when the system booted up to this upgrade. Now, with vga = normal working there are no Tux visible. I certainly do not need to see the number of cores when the system boots so I'll just keep it like this.

Is this issue something that the dev team would want to address in a patch some time?

Many thanks for your help,

Rich
 
Old 04-03-2013, 06:24 PM   #15
volkerdi
Slackware Maintainer
 
Registered: Dec 2002
Location: Minnesota
Distribution: Slackware! :-)
Posts: 876

Rep: Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826Reputation: 1826
Quote:
Originally Posted by rshepard View Post
Yes, I would see 4 penguins when the system booted up to this upgrade. Now, with vga = normal working there are no Tux visible. I certainly do not need to see the number of cores when the system boots so I'll just keep it like this.

Is this issue something that the dev team would want to address in a patch some time?
Glad to hear it's working!

Other than taking the choice of using a VESA framebuffer away, I'm not sure what we could do. Some time ago when issues relating to using the framebuffer with KMS modules/drivers first began to occur, I did make some changes to liloconfig. It defaults to vga=normal, says that is "the safe choice", and warns that some drivers are not compatible with a framebuffer.

I guess I could try to word it more strongly, but it would probably still be README-encrypted.
 
  


Reply


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
about frame buffer yugandhar Linux - Kernel 2 06-03-2006 06:07 PM
frame buffer problem sureshraju Linux - Software 3 06-29-2005 10:17 AM
problems with frame buffer hostprotect Linux - Laptop and Netbook 2 11-16-2004 03:28 AM
Frame buffer bkeating Linux - Newbie 6 04-22-2003 07:09 PM
lilo (frame buffer maybe??) watashiwaotaku7 Linux - Software 6 03-10-2003 05:25 PM


All times are GMT -5. The time now is 06:19 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