console problem--maybe related to nouveau?
 

Since installing 13.37 for the first time, I've had a very strange problem: about halfway into the boot sequence, the console display is apparently changing over to a framebuffer. Since this is explicitly disabled in lilo.conf ("vga=normal") and a more or less identical lilo.conf in 13.1 didn't do this odd behavior, I'm sort of at a loss. The only hint is that nouveau is included now and lsmod shows nouveau and a host of other crap loaded without ever running X.

How do I disable this and go back to my old-fashioned VT?

Install the blacklist nouveau package from /extra

I thought about that, but that means using the Nvidia blob for X. I successfully have nouveau running on X (wrong resolution but that may be the server: logs show it bringing up both the LCD panel and TV-OUT ports and using the best common resolution), so I'd like to keep it if it runs most things ok as that would eliminate the last proprietary blob from my laptop (well, other than the bios).

I made a little progress in reading the files Doc*/console/console.txt and especially Doc*/fb/fbcon.txt in the kernel source docs, but I'm still running into walls. The best idea seemed to be adding (from memory, I know this is not right) "fbcon.map:1" to the kernel boot options in lilo.conf as mentioned in fbcon.txt, but all it does is give a dead display--it even turns off the backlight!

Examining the kernel Kconfig files show that selecting the nouveau driver auto-selects the framebuffer console option, so a recompile without going through extra hoops won't work.

My current thinking is maybe looking again at the nouveau or generic fb sources in the kernel to see if there's some var I can poke at boot time to keep it from going into fb mode. Another, crazier, idea is to figure out how to keep udev (?) from loading it but still do so when I run X. (udev on X is funny: it thinks my uvcvideo webcam is a keyboard--no idea why.)

Failing all that, my final options are to live with and customize the fb or, as you said, blacklist and remove nouveau, and run the proprietary blob, which I already know should fix my resolution problems at the cost of keeping my kernel tainted. :(

Thanks, Mike

Sent from my N900, so sorry about any errors.

The behavior you described is caused by kernel mode setting (KMS). Add the option nomodeset to your kernel options in /etc/lilo.conf.

You can set any supported resolution for the console by passing video=xresXyres to the kernel (ie. 'video=640x480'). Blacklisting nouveau, or disabling KMS (as mRgOBLIN and TobiSGD have recommended) will only cause problems if you want to use the nouveau X driver.

Adam

Don't install the blacklist nouveau package because it will uninstall the nouveau X driver which works well in your configuration, and don't put nomodeset in lilo.conf as you do need KMS to use nouveau.

Instead, only append following line:
to /etc/modprobe.d/blacklist.conf

This way :
- handover won't occur whilst booting (i.e., the nouveau framebuffer driver won't be loaded and the previously used video driver won't be unloaded)
- at X startup the nouveau X driver will be automatically loaded though (it works even if the nouveau kernel module is backlisted, I guarantee that).

I can't comment on nouveau specifically, but I know with radeon that KMS has to be fully loaded before X starts, otherwise direct rendering won't enable. Also, your solution doesn't fix the fact that if the OP drops back to the console for some reason, it's going to be high resolution again.

Adam

This is not true for nouveau. I am a nouveau user ;)

Not sure about that. I will check.
EDIT. Just checked, you are right about that.

Blacklist nouveau, then use either nv or vesa for X sessions.

In fact you can use nouveau under X (which is way better than vesa or nv for nVidia GPUs) and still keep a VGA console (no frame buffer).

This is at the expense of not using kernel mode setting (KMS).

In fact, KMS is needed to use the nouveaufb (the frame buffer driver) but is not needed to use the nouveau X driver though it be used by default.

If you want to try, do this:

1) blacklist nouveau if not already done, e.g.
2) before issuing "startx", type as root:
Then if you kill X you will go back to your VGA console.

Only caveat : in that case the GL renderer will fallback to software acceleration, instead of using Gallium 3D, as shown by "glxheads".

Still it should be possible tu use nouveau with KMS and switch to a VGA console, but you will have to unload nouveau and some other modules, which is a bit tricky in that case. See here about "Deactivating KMS and unloading Nouveau". Beware that you should adapt these instructions to Slackware, for instance there is no /etc/init.d/consolefont script in Slackware.

Dunno if my explanations shed some light for the OP, but I least I understand a little better how all that works now ;)

EDIT. I just checked again and I was wrong, at least for a recent nouveau X driver, as the one available in /testing for slackware-13.37. In that case X starts and the nouveau X driver is loaded, but then as there is no KMS drm fail to load; Thus the X server fall back to using VESA instead of NOUVEAU. This is probably why after having killed X video rendering go back to a VGA console. The nouveau kernel module, though loaded, is not used.

<duplicate post, sorry>

Thanks for the help, guys, especially you Didier. Unfortunately, none of this works.

Without spamming this message full of logs like some people like to do, I'll just describe what happens:

1. Using "nomodeset" AKA "modeset=0", indeed the nouveau driver seems to load but not take over the screen with a framebuffer. Likewise, X starts up fine. Looking at the X-server logs, however, shows that nouveau is NOT working, and that the screen is being driven by the generic VESA driver. That is, the nouveau group's assertion that KMS is required is absolutely true because when this option isn't used, nouveau takes over just fine.

2. Putting "blacklist nouveau" into "/etc/modprobe.d/blacklist.conf"--same thing as the "blacklist-nouveau" package does?--keeps the nouveau module and its dependencies from loading just fine. Surprisingly, when X is run even as non-root, the server will happily load nouveau and friends and take over the screen. Unsurprisingly, when exiting X, you're back to the framebuffer again.

3. Executing "rmmod -f nouveau" will get you out of the frame buffer and back to the regular VGA VT without messing with /sys; however, it only works the first time, it would seem.

4. I have had no luck playing in /sys like some directions say. It looks more and more like, to get consistent operation, "vbetool" may have to be employed--yuck!

I feel what this boils down to is this:

A. The nouveau people feel like you should be console in a framebuffer--WHETHER YOU LIKE IT OR NOT! Someone correct me if I'm wrong, but why else would they make it so incredibly difficult?

B. The only other "reasonable" alternative without making some ugly hack scripts is to recompile the kernel with fbcon(sole) disabled. I intend to compile a new kernel anyway, so it's not a big deal for me, but for others...

C. The old stand by, bringing in the blob. I haven't testing rendering speed on my laptop with nouveau yet so I don't know yet how it compares to the blob; this mainly applies to the Mesa drivers and ioquake3-based games, and watching videos with software rendering because my chip doesn't have ANY hardware decode capability (i.e., not a driver issue, it really isn't there).

Having resigned myself to living with the fb, I need to get it to use the full screen size (it only takes up about a third), and creating a xorg.conf file because of the aforementioned default dual-head problem with the SVGA TV-OUT port forcing a non-native resolution. Of course, using the blob will make this problem go away too, and it's veeeeeeery tempting...

Mike

You are right and I was wrong here, I double checked and edited my last post accordingly

Putting "blacklist nouveau" into "/etc/modprobe.d/blacklist.conf" is not the same thing as uprading to the "blacklist-nouveau" package, as in the latter case, in addition the xf86-video-nouveau package is removed.
And it is not surprising that when X is run even as non-root, the server will happily load nouveau and friends and take over the screen, it's is intended by the developers. That way you don't have to take care yourself of loading the nouveau kernel module before starting X, provided that either the nouveau driver be explicitly chosen in xorg.conf, or the x server be built in such a way that it be chosen by priority in case of a nVidia card - which is done in Slackware-13.37.

storkus, just wondering do you using LILO to boot up linux? If so, when LILO loads and prints a lot of dots, does it misses one of dot?(I have fillings that dot correspondents to video drivers) I have similar problem: starting X without xorg.conf graphics is broken, but when I uninstall x video driver, I forgotten which I uninstall nv or nouveau, it works.

FeyFre: You're confused: the dots are each sector (?) loaded by LILO before it hands over control to the kernel; the kernel is in the process of being loaded into memory and there is no video driver in use yet other than the video BIOS. You can make your machine load MUCH faster by uncommenting "COMPACT" in lilo.conf and running lilo again to save it. This should probably be among, if not THE, first thing you do once you boot for the first time. (Leaving "COMPACT" commented is just for backwards compatibility with VERY old hardware.)

Also, unless your hardware is very new or very unusual, X should start fine without an xorg.conf: this is by design. If it does not, the usual reason is your hardware is too new and only the closed binary blob will drive it--as late as the last Slackware, 13.1, neither nv nor nouveau would drive my NV67 AKA GeForce 7000M / nForce 610M integrated southbridge. Now nouveau does and even though nv is present, it knows to select nouveau and unload nv. YMMV, of course.

Didier: In my sleep-deprived and Benadryl-induced delirium I conveniently forgot X is SUID--of course it would load the modules! *smacks forehead*

Anyway, I'm hoping to ask this question to the nouveau developers directly. I went onto their IRC channel, but being Saturday night no one was home. I'll try again tonight or Monday. In retrospect, perhaps I should have done that directly, but at the time I didn't quite realize this wasn't a distro-specific problem. Oh, and thanks for cluing me in about the nouveau-blacklist package--I really need to actually look at it and see what it does.

Oh, one more thing: after doing a bit more research, it looks like getting my various outputs and resolutions, unlike the fb problem, will be easy. I'll have to write an xorg.conf, but it can still be a lot more sparse than it was back in the old days. :) It basically revolves around putting RandR stuff into the xorg.conf, and there are lots of howtos and code out there for it. If you're interested, I can post links here, but I found everything by simple Googling and links from the nouveau site, of all things.

Mike