LinuxQuestions.org
Review your favorite Linux distribution.
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 05-12-2011, 02:56 AM   #1
storkus
Member
 
Registered: Jun 2008
Posts: 310

Rep: Reputation: 45
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?
 
Old 05-12-2011, 03:17 AM   #2
mRgOBLIN
Slackware Contributor
 
Registered: Jun 2002
Location: New Zealand
Distribution: Slackware
Posts: 999

Rep: Reputation: 227Reputation: 227Reputation: 227
Install the blacklist nouveau package from /extra
 
Old 05-12-2011, 07:44 AM   #3
storkus
Member
 
Registered: Jun 2008
Posts: 310

Original Poster
Rep: Reputation: 45
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.
 
Old 05-12-2011, 07:51 AM   #4
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,619
Blog Entries: 2

Rep: Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076Reputation: 4076
The behavior you described is caused by kernel mode setting (KMS). Add the option nomodeset to your kernel options in /etc/lilo.conf.
 
Old 05-12-2011, 08:09 AM   #5
adamk75
Senior Member
 
Registered: May 2006
Posts: 3,091

Rep: Reputation: 397Reputation: 397Reputation: 397Reputation: 397
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
 
Old 05-12-2011, 08:42 AM   #6
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,533

Rep: Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190
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:
Code:
modprobe nouveau
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).
 
Old 05-12-2011, 08:45 AM   #7
adamk75
Senior Member
 
Registered: May 2006
Posts: 3,091

Rep: Reputation: 397Reputation: 397Reputation: 397Reputation: 397
Quote:
Originally Posted by Didier Spaier View Post
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:
Code:
modprobe nouveau
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
 
Old 05-12-2011, 08:51 AM   #8
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,533

Rep: Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190
Quote:
Originally Posted by adamk75 View Post
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.
This is not true for nouveau. I am a nouveau user

Quote:
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.
Not sure about that. I will check.
EDIT. Just checked, you are right about that.

Last edited by Didier Spaier; 05-12-2011 at 04:27 PM.
 
Old 05-12-2011, 05:30 PM   #9
disturbed1
Senior Member
 
Registered: Mar 2005
Location: USA
Distribution: Slackware
Posts: 1,133
Blog Entries: 6

Rep: Reputation: 223Reputation: 223Reputation: 223
Blacklist nouveau, then use either nv or vesa for X sessions.
 
Old 05-12-2011, 06:20 PM   #10
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,533

Rep: Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190
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.
Code:
echo -e "\nblacklist nouveau">>/etc/modprobe.d/blacklist.conf #if not already done
2) before issuing "startx", type as root:
Code:
modprobe nouveau modeset=0
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.

Last edited by Didier Spaier; 05-15-2011 at 06:05 AM.
 
1 members found this post helpful.
Old 05-12-2011, 06:22 PM   #11
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,533

Rep: Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190
<duplicate post, sorry>

Last edited by Didier Spaier; 05-12-2011 at 06:25 PM.
 
Old 05-14-2011, 11:10 PM   #12
storkus
Member
 
Registered: Jun 2008
Posts: 310

Original Poster
Rep: Reputation: 45
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
 
Old 05-15-2011, 06:31 AM   #13
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,533

Rep: Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190Reputation: 1190
Quote:
Originally Posted by storkus View Post
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.
You are right and I was wrong here, I double checked and edited my last post accordingly

Quote:
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.
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.

Last edited by Didier Spaier; 05-15-2011 at 07:00 AM.
 
1 members found this post helpful.
Old 05-15-2011, 04:07 PM   #14
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 308

Rep: Reputation: 22
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.
 
Old 05-15-2011, 05:43 PM   #15
storkus
Member
 
Registered: Jun 2008
Posts: 310

Original Poster
Rep: Reputation: 45
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

Last edited by storkus; 05-15-2011 at 05:49 PM.
 
  


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
Three Problem Perhaps Related john_f_somers Ubuntu 1 11-09-2010 07:40 PM
iptables related problem Barq Linux - Networking 2 06-21-2009 06:16 AM
non root related problem xeonx Linux - General 2 05-26-2009 11:23 AM
Network related problem vijaya_svk Linux - Software 1 08-01-2008 11:53 PM
Problem related with subnetting myself_rajat Linux - Networking 1 12-07-2004 05:23 AM


All times are GMT -5. The time now is 07:41 PM.

Main Menu
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