# nouveau drm mode switch messages

## wcg

gpu: GE6150SE-nforce 430

kernel: 2.6.36-gentoo-r5

drm and nouveaufb is all working ok (for my modest requirements

of X and the text-mode framebuffer), but when I have X running

on one virtual console and I switch back to a text mode console,

I find that the nouveau driver has spammed the text-mode virtual

consoles with messages like:

```

[drm] nouveau 0000:00:0d.0: Setting dpms mode 3 on vga encoder (output 0)

[drm] nouveau 0000:00:0d.0: Setting dpms mode 0 on vga encoder (output 0)

[drm] nouveau 0000:00:0d.0: Output VGA-1 is running on CRTC 0 using output A

```

(I assume that the first line is from the previous mode switch

for the console where X is running and the two lines following

are from the mode switch back to text mode when I do a ctrl-alt-F?

virtual console switch back to a text-mode console.)

I don't care if those messages show up in /var/log/kern.log or

/var/log/debug or whatever, but I do not want them showing

up on my text-mode display unless I specifically tell the kernel

"I am debugging the nouveau driver; show me everything,"

(with some write to a /proc/ or /sys/ file or a kernel command

line option or whatever).

Is there some way I can disable or redirect these messages

without completely disabling kernel debugging in the kernel

config? (I like to keep a few kernel debugging options enabled,

mostly sanity checks at boot and similar.)

----------

## chithanh

If you start a system logger, those messages should at least not be printed to the console any longer.

----------

## wcg

syslogd and klogd are both started at boot.

I do not know why the nouveau printk() output

is going around klogd and printing direct to the

console display. Maybe some function argument

to the printk() in the nouveau driver that

prints those messages?

Is there an equivalent to syslog.conf for klogd?

----------

## chithanh

You are using in-kernel drm, yes? Not the nouveau-drm package (which has some debug options permanently enabled).

----------

## wcg

 *Quote:*   

> You are using in-kernel drm, yes?

 

Yes.

I did re-emerge several packages that have linux-headers

as a direct dependency over the weekend and rebooted,

and I see that the messages are going to /var/log/syslog today.

I still do not know why they were appearing on the console

(sysklogd was not in that list of packages that directly depend

on linux-headers), but it is behaving the way I would want it to

at the moment.

If the behavior reappears I will bump this thread.

----------

## wcg

This behavior is back. Apparently it was only the reboot

after emerging that temporarily fixed it, and it had nothing

to do with re-emerging several packages that depend on

linux-headers.

(Run "equery depends -d linux-headers" to see a list of what

all depends directly on linux-headers and should possibly

be recompiled when linux-headers is updated.)

Another detail: mode switch message printk()s from

the nouveau driver are still appearing in /var/log/syslog,

it is just that something happens and they start getting

printed to all of the virtual consoles, too.

(It is annoying when you are editing something in a text

mode virtual console, switch to X to look something up online,

then switch back to your virtual console and find those mode

switch messages in your editing buffer.)

edit:

/var/log/syslog is showing a "PFIFO_CACHE_ERROR" message

from the nouveau driver, too. (This is probably where the

real problem starts.)

----------

## dylan_stark

I'm having a similar problem.

My syslog is getting hammered with error messages 

```

 kernel: [410105.057158] [drm] nouveau 0000:00:05.0: PFIFO_CACHE_ERROR - Ch 1/3 Mthd 0x0d8c Data 0x00000000
```

and disk get full within half an hour.

I'm using gentoo-sources 2.6.36-r5 and x11-drivers/xf86-video-nouveau 0.0.16_pre20101130

----------

## dE_logics

Why don't you use the non free drivers?

----------

## dylan_stark

Don't like them   :Smile: 

But I'll have to if I can't solve this.

----------

## wcg

The kernel developers have been telling us for more than

a decade that using closed source binary drivers makes

your kernel debug-challenged. (Bug reports are worthless

to them when they cannot see the source that a kernel

module or compiled-in subsystem was compiled from.)

Without casting aspersions on the ethics of any specific

closed source linux developers, including pre-compiled

binary code in the kernel would seem to weaken security,

too, even if only by accident. Without all of the sets of eyes

reading the code that open source kernel code gets, closed

source code does not provide the same level of assurance

that there are no exploitable security holes in the code

that the closed source modules were compiled from.

Finally, they tend to not keep up. Kludges that should

have gone away years ago persist in closed source drivers,

while the open source drivers for the same classes of

hardware have moved on to newer, more efficient,

safer, more scalable, less cpu-hungry, less power-hungry

ways of handling specific tasks that come up at runtime.

Those kludges persist when the companies that funded

the development do not provide sufficient funding for

maintenance programming to keep their drivers current

with the kernel's changes in how it does things across

subsystems like graphics, hard drives, network interfaces,

devices in general, and so on.

I have no specific bias against the nvidia binary gpu drivers,

it is just pre-compiled binary code in general that I only

use if I have to (because there is no open source driver

that will operate some specific bit of hardware, but there

is a closed source Linux driver for it, and replacing it

with some other hardware for which there is a working

open source Linux driver would be impractical).

While I have these occasional issues with nouveau

(and will have eventually with the nv driver as Xorg

advances past it), they work well enough with this

(GE6150SE-nforce 430) gpu and chipset for my

usual set of graphic mode applications that I do not

have  to use a pre-compiled binary driver for it.

From my perspective, having a working open source

driver for the hardware is like getting to ride up front

in the cab of a truck, where I can see where we are going,

instead of in back with the freight.

----------

## wcg

A discussion in another thread brought sysklogd to mind

as a possible source of the problem here.

Those debug printk()s from the nouveau driver are

called with KERN_DEBUG as the loglevel for printk(),

and I assume that this translates to facility LOG_KERN

with priority LOG_DEBUG for klogd. klogd is setup in

/etc/conf.d/sysklogd to log to syslogd. It forwards

log messages from the kernel to syslogd, which

then logs them wherever according to /etc/syslog.conf.

/etc/syslog.conf contains this line:

```

kern.*           -/var/log/kern.log

```

So all messages from klogd to syslogd should have

been logged to /var/log/kern.log. (We also  have

```

*.*; auth, authpriv.none  -/var/log/syslog

```

so apparently they could go to /var/log/syslog, too.)

/etc/conf.d/sysklogd specifies starting klogd as

```

klogd -c 3 -2

```

The "-c 3" should tell klogd to only print messages with

priority 2 or higher directly to /dev/console (LOG_CRIT, LOG_ALERT,

or LOG_EMERG). That does not include LOG_DEBUG, priority 7

according to /usr/include/sys/syslog.h.

So, I changed that klogd command in /etc/conf.d/sysklogd to be

```

klogd -c 3 -f /var/log/kern.log -2

```

and commented out the kern.* line in /etc/syslog.conf.

Now klogd has /var/log/kern.log open, instead of syslogd,

and all kernel messages should go only there (and/or to the

console for messages with priority higher than 3).

We will see if that fixes it. At least the picture of what is

happening should be more clear, since the messages from

the kernel and nouveau driver are not getting sprayed around

into various log files in /var/log/ (and elsewhere, hopefully).

If I still get messages to the console with priority LOG_DEBUG,

that points squarely at klogd as the confused process.

I potentially lose some performance this way, because klogd

probably writes all kernel messages synchronously to whatever

file is specified with the "-f pathname" option (no batching).

Better that than chaos, though.

----------

## wcg

So, 5 days, this seems to be working (having klogd open /var/log/kern.log

directly with the "-f /var/log/kern.log" option to klogd in /etc/conf.d/sysklogd

and commenting out the "kern.*" line /etc/syslog.conf).

Before it would be a few hours before something would happen that

would trigger getting nouveau debug mode switch messages spamming

the text-mode consoles. Now they are all going to /var/log/kern.log.

(I have not seen the PFIFO_CACHE error message from the nouveau driver,

either.)

It looks like the problem could have been in syslogd or in the

communication between klogd and syslogd. (I am wondering

if the start-stop sequence in /etc/cron.daily/syslog.cron to

rotate /var/log/syslog and then restart both daemons is

when the problem with syslogd handling kern.debug messages

from klogd starts. Just a guess, though. Putting it back the old

way and running both klogd and syslogd in debug mode would

provide more definitive information.)

----------

