From: Arthur Barlow on
I recently updated my kernel from 2.6.32-3 to 2.6.32-5, (Squeeze on an x86
platform). I noticed on reboot that shortly after the kernel booted the
screen switched to a frame buffer for the remaining loading messages. I
have a desktop system that runs GNOME and so gdm started as usual and I
logged in. However, I have three different CPUs that go through a kvm
switch and I usually have to reset modeline settings via "xvidtune" in X for
my Debian CPU.

xvidtune no longer worked. I am using an Nvidia GeForce4 MX 4000 card. I
hunted around and found that some combination of Freedesktop.org and the X
group are now using kernel based X drivers or the KMS modes. It also
appears that the "nv" driver disappeared and was replace by the "nouveau"
driver. This new driver seems to be the source of my xvidtune problems.
Does anyone on this list know who the appropriate group to send a "bug
report" to would be? Thanks.
From: Stephen Powell on
On Thu, 17 Jun 2010 17:11:56 -0400 (EDT), Arthur Barlow wrote:
>
> I recently updated my kernel from 2.6.32-3 to 2.6.32-5, (Squeeze on an x86
> platform). I noticed on reboot that shortly after the kernel booted the
> screen switched to a frame buffer for the remaining loading messages. I
> have a desktop system that runs GNOME and so gdm started as usual and I
> logged in. However, I have three different CPUs that go through a kvm
> switch and I usually have to reset modeline settings via "xvidtune" in X for
> my Debian CPU.
>
> xvidtune no longer worked. I am using an Nvidia GeForce4 MX 4000 card. I
> hunted around and found that some combination of Freedesktop.org and the X
> group are now using kernel based X drivers or the KMS modes. It also
> appears that the "nv" driver disappeared and was replace by the "nouveau"
> driver. This new driver seems to be the source of my xvidtune problems.
> Does anyone on this list know who the appropriate group to send a "bug
> report" to would be? Thanks.

I experienced a similar problem on an older Nvidia card. If you want to
get the old behavior back, create a file in /etc/modprobe.d with an extension
of .conf. For example: /etc/modprobe.d/local.conf. Then turn off kernel
mode setting with a line in this file that looks like this:

options nouveau modeset=0

This will give you the hardware text-mode video modes on the text consoles
(1-6 by default) as before. Then, as root, run

update-initramfs -u

against the 2.6.32-5 initial RAM file system. Then, shutdown and reboot.
The nouveau video driver in X won't work if the nouveau kernel module doesn't
do mode setting. This should get your nv driver back. Blacklisting the
nouveau kernel module might work too, but using modeset=0 as an option was
how I solved it. (Make sure that /etc/modprobe.conf does not exist. If it
does, then files in /etc/modprobe.d will be ignored.)

--
.''`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/1921342650.84518.1276811574136.JavaMail.root(a)md01.wow.synacor.com
From: Kelly Clowers on
On Thu, Jun 17, 2010 at 14:11, Arthur Barlow <arthurbarlow(a)gmail.com> wrote:
> I recently updated my kernel from 2.6.32-3 to 2.6.32-5, (Squeeze on an x86
> platform).  I noticed on reboot that shortly after the kernel booted the
> screen switched to a frame buffer for the remaining loading messages.  I
> have a desktop system that runs GNOME and so gdm started as usual and I
> logged in.  However, I have three different CPUs that go through a kvm
> switch and I usually have to reset modeline settings via "xvidtune" in X for
> my Debian CPU.

Can't you use xrandr for that?

> xvidtune no longer worked.  I am using an Nvidia GeForce4 MX 4000 card.  I
> hunted around and found that some combination of Freedesktop.org and the X
> group are now using kernel based X drivers or the KMS modes.  It also
> appears that the "nv" driver disappeared and was replace by the "nouveau"
> driver.  This new driver seems to be the source of my xvidtune problems.
>  Does anyone on this list know who the appropriate group to send a "bug
> report" to would be?  Thanks.

Yes, Nvidia stopped maintaining nv, so people are moving to the community
project Nouveau, which exclusively uses Kernel Mode Setting.

You should probably report the bug to Debian with the "reportbug" utility,
they will forward it upstream if they have to. The question, though, is is this
a bug for xserver-xorg-video-nouveau, x11-xserver-utils (the package
containing xvidtune), or even the kernel (the KMS interface)? Is there any
sort of error when you try to use xvidtune, or anything in /var/log/Xorg.0.log?


Cheers,
Kelly Clowers


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/AANLkTimn3WjnmKE_Umm49rrm7SP-qWc775EwQ3KCUW4H(a)mail.gmail.com
From: Stephen Powell on
On Thu, 17 Jun 2010 17:52:54 -0400 (EDT), Stephen Powell wrote:
>
> I experienced a similar problem on an older Nvidia card. If you want to
> get the old behavior back, create a file in /etc/modprobe.d with an extension
> of .conf. For example: /etc/modprobe.d/local.conf. Then turn off kernel
> mode setting with a line in this file that looks like this:
>
> options nouveau modeset=0
>
> This will give you the hardware text-mode video modes on the text consoles
> (1-6 by default) as before. Then, as root, run
>
> update-initramfs -u
>
> against the 2.6.32-5 initial RAM file system. Then, shutdown and reboot.
> The nouveau video driver in X won't work if the nouveau kernel module doesn't
> do mode setting. This should get your nv driver back. Blacklisting the
> nouveau kernel module might work too, but using modeset=0 as an option was
> how I solved it. (Make sure that /etc/modprobe.conf does not exist. If it
> does, then files in /etc/modprobe.d will be ignored.)

I just did another

aptitude update
aptitude full-upgrade

sequence today, and I find that the solution listed above is no longer complete.
I find that I now must specify

driver = "nv"

in the "Device" section of /etc/X11/xorg.conf to get the nv driver back.
The nouveau X driver now apparently works even if modeset=0 is specified
as a nouveau kernel module parameter. I also found by experimentation
that blacklisting the driver does not work. The nouveau X server
explicitly loads it. You must explicitly specify the nv driver in
/etc/X11/xorg.conf if you want to use it instead of nouveau. But
specifying modeset=0 as a kernel module parameter does seem to get the
hardware text video modes back on the text console, even if the nouveau
driver is used by X.

--
.''`. Stephen Powell
: :' :
`. `'`
`-


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/1812490758.86016.1276815714691.JavaMail.root(a)md01.wow.synacor.com
From: Sven Joachim on
On 2010-06-18 01:01 +0200, Stephen Powell wrote:

> The nouveau X driver now apparently works even if modeset=0 is specified
> as a nouveau kernel module parameter.

It does not, unless the module is loaded with modesetting enabled
somehow. Maybe you got the vesa driver instead of nv.

> I also found by experimentation that blacklisting the driver does not
> work. The nouveau X server explicitly loads it.

X runs modprobe without the "-b" option, so blacklisted modules that are
not loaded when udev starts will be loaded now. IMO this is a bug.

> You must explicitly specify the nv driver in
> /etc/X11/xorg.conf if you want to use it instead of nouveau. But
> specifying modeset=0 as a kernel module parameter does seem to get the
> hardware text video modes back on the text console, even if the nouveau
> driver is used by X.

This means that the option works when the module is loaded by udev.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/87vd9h55mz.fsf(a)turtle.gmx.de