Console issues after a compile

[FUBAR]

I'm sure someone here has run into this issue, and fixed it. I did once but can't remember how.

I have a fresh Redhat 7.2 box that I custom compiled a kernel for. Most everything works fine, except the console. I can get it to run in default mode, but if I do a vga= option (I like 0x317 and 0x307) it gives me no display. The graphics card can handle it, as I do it with the stock kernel, and the kernel is booting, since it's up proper if I wait long enough.

If it helps, these are some of the boot messages:

With the default kernel, I get this at vga=0x317
Mar 31 22:35:49 isis kernel: Console: colour dummy device 80x25

then later, as expected:
Mar 31 22:35:50 isis kernel: vesafb: framebuffer at 0xe6000000, mapped to 0xc8800000, size 4096k
Mar 31 22:35:50 isis kernel: vesafb: mode is 1024x768x16, linelength=2048, pages=0
Mar 31 22:35:50 isis kernel: vesafb: protected mode interface info at c000:4d86
Mar 31 22:35:50 isis keytable: Loading system font: succeeded
Mar 31 22:35:50 isis kernel: vesafb: scrolling: redraw
Mar 31 22:35:50 isis kernel: vesafb: directcolor: size=0:5:6:5, shift=0:11:5:0
Mar 31 22:35:50 isis kernel: Console: switching to colour frame buffer device 128x48
Mar 31 22:35:50 isis kernel: fb0: VESA VGA frame buffer device

I don;t think these show up when I use my kernel, but I'll check later, not at home now.

Has anyone ever run into this? I'm sure it's an option I'm missing but I don't know which one...

 

[cleverhandle]

Sounds like the default kernel uses the framebuffer on the console. It's a submenu of "console drivers" in the kernel configuration screens. So check to see if you've got that enabled. There might be some other configuration to do as well, but never having used it, I can't help you with that.

 

[LNXman]

You mostlikely chose one of the experimental console frame buffer drivers such the ones for NVidia, Matrox, ATI, etc. Those are experimental and will not let you choose high resolutions for the console output, or they will not display at all in some cases.
You should just use the known to work default VESA/VGA driver only until the kernel guys get to the other card specific drivers. Besides, I don't see the point on using high end drivers for pure text console output. You should just let XFree86 handle that.

GL

 

[Barnaby W. Füi]

yeah get rid of the framebuffer, its hardly useful and can cause problems.

i just add "vga=1" to lilo.conf and its pretty nice.

 

[cleverhandle]

Clear something up for me... I was reading his report as indicating that the old kernel had the experimental framebuffer, and his custom kernel did not, since the lines he quoted were from the stock RH kernel. Correct? So his choices are to either enable the framebuffer in his new kernel, or go with standard VGA by specifying vga=1, as BBWF stated.

 

[Barnaby W. Füi]

<< Clear something up for me... I was reading his report as indicating that the old kernel had the experimental framebuffer, and his custom kernel did not, since the lines he quoted were from the stock RH kernel. Correct? So his choices are to either enable the framebuffer in his new kernel, or go with standard VGA by specifying vga=1, as BBWF stated. >>


well no, to disable framebuffer you have to remove it from your kernel, the vga=1 makes standard console 80x50 instead of standard 80x25...much nicer IMO

 

[Barnaby W. Füi]

whoopsie galeon crashed when i posted my last post so i didnt think it went through

 

[cleverhandle]

<<

<< Clear something up for me... I was reading his report as indicating that the old kernel had the experimental framebuffer, and his custom kernel did not, since the lines he quoted were from the stock RH kernel. Correct? So his choices are to either enable the framebuffer in his new kernel, or go with standard VGA by specifying vga=1, as BBWF stated. >>


well no, to disable framebuffer you have to remove it from your kernel, the vga=1 makes standard console 80x50 instead of standard 80x25...much nicer IMO >>



Right. I know vga=0 is standard. I'm just saying that his post makes it sound like his *new* kernel does not have framebuffer support. Hence, when he enters vga=0x317, it won't display. So he doesn't need to disable framebuffer, because it's already gone. He just needs to enter the old-school vga numbers instead of the experimental ones.

 

[BlackOmen]

If you want to just let your framebuffer upon the advice others, then disregard my post. To solve the problem, in your kernel config:

Under Code maturity level options enable Prompt for development and/or incomplete code/drivers

Then, under Console drivers enable Video mode selection support (I usually leave VGA text console enabled).

Then choose Frame-buffer support, enable:
VESA VGA graphics console, Advanced low level driver options
Go down and select 8,16,24,32 bpp pixels support as a built-in option.
Monochrome,2,4 bpp pixels support aren't necessary, however I build them as modules.

Go down further and enable Select compiled-in fonts.
Select VGA 8x8 and VGA 8x16 fonts. The other font drivers will be unused and can be disabled.

Go through the build process again (make dep; make bzImage; etc.........)
Hope it helps.

 

[FUBAR]

Well, for those that say that I don't need high res terms and I should use X, blech, X sucks, the console is where it's at!

You're half right tho, most of the time it's headless, so I don't *need* the high res console anyway, my term windows so 1600x1200 in putty but seriously, X is not really an option since it's a server. I just like to have the high res for when I have to plug in direct for something, and this is a problem that has been bugging me on a few different compiles for a few different boxes.

BlackOmen, that sounds like the section I am thinking of, but I didn't think I had to turn on experimental, maybe I did it by accident... who knows :-/

Anyway, hopefully I'll have a chance to test this soon, but now I have to get my migration from my old crapped out hard drive done so I can showcase some of my basic web-dev skillz for a job opening...

Thanks for the help dudes

 

[LNXman]

You misunderstood me.
I did not suggest using XFree86 instead to handle high resolution text view. What I said was that I dont think high end drivers are needed for pure console text output. The generic VESA/VGA driver can do what you want at high res. BlackOmen, re-iterated what I suggested, but in detail (NICE man! )
To put it in simple terms, I suggest you not use experimental high end frame buffer drivers for console output, because (1) they are experimental, and (2) it does not make sense to do so since all you are doing is looking at text (unless you are planning to play GLdoom). Just read some of the documentation under /usr/src/linux/Documentation/ so you know why something is experimental before you compile.

GL

 

[BlackOmen]

<< I suggest you not use experimental high end frame buffer drivers for console output >>

Agreed. The VESA/VGA driver is mature and has been stable for quite some time now. The other framebuffer drivers are very experimental, unstable, and in my case when i accidentally enabled the nvidia driver, quite broken. If you enable only what I mentioned, you'll get the framebuffer console; enable more and well, just don't.

FUBAR: You do need to enable experimental because the generic framebuffer drivers are nestled in with lots of broken stuff under Framebuffer support. It doesn't make sense to me either............