To start with, I've searched the forum using a large variety of keywords and read a little over 120 of the over 4000 posts in the 2.6 kernel guide sticky. I've read man pages, looked for HOW-TOs, etc. If posting here doesn't garner a solution, voodoo, dancing and chanting will commence.

I'm currently using Slackware 10.1. I downloaded (some time ago) kernel 2.6.9 and compiled it fine. It looks like I may actually be able to (probably not, considering my luck with the blasted card) use the 3d acceleration on my Radeon7000. Linux actually registers my brand new WD 160gb sata hard drive. My USB mouse is detected and I can configure it easier than ever before.

Unfortunately, something major is wrong. I'm not /quite/ sure what, but here are some symptoms:

• I no longer can get a 1024x768 screen resolution when booting. (I boot into terminal, not X)
• I no longer get the penguin logo. It isn't that important, but I think it may be indicative of the larger cause.
• man no longer works. I only get one screen worth's text, a cryptic error message, and a return to bash.
• dmesg | less no longer works. I only get one screen worth's text and a return to bash.
• less no longer works. I only get one screen worth's text and a return to bash.
• After I select my newly compiled kernel from Lilo's menu, the option "vga=ask" presents me with several options, all of which produce a message informing me the option picked doesn't exist. I enter scan. Sixty seconds later, a new set of options appear. I assume more than the one I've picked works. This contradicts, I suppose, the first symptom.

My best guess is that something is wrong with the frame-buffer.

Much thanks in advance to any help. Give me a cheap thrill and add an emoticon when you tell me to RTFM because I missed something really f***ing obvious.

I remember there was an udev issue some time ago that caused the
man / less bug... Maybe you should update udev package

Now for the framebuffer, did you compile radeonfb or vesafb driver
in the kernel ?

I started out with the radeonfb, realised the error of my ways, and have been using vesafb for the last day or so.

I'll try updating the udev package.

So you use vesa and you can't see the linux logo, and you can't use 1024x768
resolution...

Did you check that all the framebuffer options were compiled in the kernel,
especially CONFIG_LOGO and CONFIG_VIDEO_SELECT ?

Also make sure that CONFIG_FB_VGA16 is not set

fb_vesa, video_select, vga_console, dummy_console, framebuffer_console, logo_linux_clut224 --all have "=y" attached to them. Along with fb_vga16. I'll go fix that. (repeats to self ad nauseum: only one framebuffer can be used at a time)

Oh, no, I can use 1024x768 now, but only after waiting sixty (+/- ten) seconds for scan to work. Lilo prompts for a mode, presents me with a list of possibilities, when a possibility are chosen, claims they do not exist, I input "scan" and a new list of possibilities are printed, at least one of which work. I haven't taken the time to try every single option. A guide to interpreting the different possibilities would be nice though (though mostly unimportant, I suppose).

cd into your kernel directory and read the lines about framebuffer modes in :

Documentation/fb/vesafb.txt

Aha! That file helped a lot. Fortunately vi still works. Reading files with more sucks. My framebuffer issues are solved. Much thanks, keefaz.

Now for less. I'm hesitant to upgrade udev because I'm not sure how to install it to /usr/local . It isn't the standard ./configure, make, make install where I can direct the install location, and I don't want to install something as important as udev without a backup solution. I warily poked about the Makefile, but paranoia kicked in and didn't edit anything.

I've now been reading bits here and there about udev. The best feature (according to me, newbie jake) is that /dev/ isn't populated with unused potential devices as it is created fresh each reboot with just the devices actually present. Probably I simply misunderstand, because on my system /dev has tons of unused spots for devices.

Alright. Google and kernel bugzilla are my friends. The bug with less is bug 3736. Unfortunately, there is no resolution yet.

Your udev tip got me to (http://kerneltrap.org/node/4026) where someone reccommends editing udev.rules. The string becomes and to finish it up, either reboot or /etc/rc.d/rc.udev restart. I rebooted because I was too excited to read past the fix for the reminder that I am running Linux, not Windows. The BIOS did its thing, Lilo did its thing, and then the screen went black. Fortunately I am skilled at using the command line with my eyes closed, and edited udev.rules back to the way it was. Maybe it worked, maybe it didn't, but the side-effects make the prescription worthless. Unless someone maybe sees something I did wrong..?

for the blank screen
http://www.linuxquestions.org/questi...t=blank+screen

[ ]'s

Ha-hah! I have managed to fix all. All I did was re-edit that line, and then restart rc.udev instead of my computer. All that is left to be answered are reasons. Why did changing "tty/s" to "pty/s" make a difference? Why was it "tty/s" in the first place if it should be "pty/s"? Restarting my computer should have also restarted rc.udev, so why did I have to [sh rc.udev restart] before I could safely reboot?

maginotjr-- Great help thread! But (oddly enough) I only had a blank screen problem when I tried to fix the bug with less, which was after I configured my kernel and Lilo correctly and the framebuffer was working fine.

yeah... sometimes we have a lot of whys but this is the Dimension we live, who understand what goes in the mind of those programmers.... LOL ..