Prev: debian architecture history question
Next: Mutt and GPG - claims ALL signatures can't be verified
From: Sven Joachim on 12 Jun 2010 04:10
On 2010-06-12 00:15 +0200, Gilbert Sullivan wrote:

> On 06/11/2010 03:08 PM, Sven Joachim wrote:
>> On 2010-06-11 19:06 +0200, Gilbert Sullivan wrote:
>>
>>> I undock from the port replicator and use the notebook's built-in
>>> 1920x1200 display, and the boot with the new kernel brings me to
>>> normal gdm login and then desktop. The only difference between
>>> appearance of boot using old kernel and new kernel is that, after the
>>> populating devices message, the text stops scrolling down the middle
>>> of the screen and starts scrolling down the left side. So I guess this
>>> is a video mode issue.
>>
>> I'm not sure I understand "middle of the screen" and "left side", but
>> the existing screen contents will be erased when nouveau is loaded.
>>
>
> This is a notebook, and I have the video set in BIOS to not "expand"
> to fill the screen. So it uses and area that's something like 800x600
> in the middle of the screen. It uses that small area for the scrolled
> messages at boot time all the way up until GDM is loaded -- that's
> when I'm using the old kernel -- with either the 1680x1050 DVI
> external LCD or the built-in 1920x1200 LCD.

Thanks, I understand now.

> When using the new kernel with the external LCD, it just goes black
> after the /dev populated message. With the built-in LCD that's the
> point where it stops using the 800x600 area and starts using the
> entire screen for the scrolled messages.

This is to be expected, because it detects and uses the display's native
resolution. This is usually what you want, but you can override it with
the video=800x600 boot parameter (or whatever other resolution you like).

> I booted the system connected to the port replicator and let it go to
> the black screen. I logged on to it via ssh and got the output of
> dmesg, which I'm attaching to this message as dmesg.txt.

Thanks. I don't see anything unusual in it, in particular nouveau
detects the 1680x1050 resolution of the external display:

> [ 7.308183] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x49000, bo f6feb600
> [ 7.319925] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
> [ 7.319929] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
> [ 7.319931] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
> [ 7.321231] Console: switching to colour frame buffer device 210x65

If you want to report a bug upstream, please see
http://nouveau.freedesktop.org/wiki/FrontPage#Bugs.

Cheers,
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/87zkz0isop.fsf(a)turtle.gmx.de
From: Gilbert Sullivan on 12 Jun 2010 09:40
On 06/12/2010 04:03 AM, Sven Joachim wrote:
> This is to be expected, because it detects and uses the display's native
> resolution. This is usually what you want, but you can override it with
> the video=800x600 boot parameter (or whatever other resolution you like).

Looks like I have a bit of searching and reading to do. I have just been
blithely rolling along with all of the upgrades in Squeeze. Whereas I
would have had an idea of how to go about this with grub I notice that a
lot of things have changed between the changes in grub and the changes
in the way video is handled.

>> I booted the system connected to the port replicator and let it go to
>> the black screen. I logged on to it via ssh and got the output of
>> dmesg, which I'm attaching to this message as dmesg.txt.
>
> Thanks. I don't see anything unusual in it, in particular nouveau
> detects the 1680x1050 resolution of the external display:
>
>> [ 7.308183] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x49000, bo f6feb600
>> [ 7.319925] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>> [ 7.319929] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
>> [ 7.319931] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>> [ 7.321231] Console: switching to colour frame buffer device 210x65

Yes, I saw that and wondered why, if it's detecting the resolution
properly, it isn't working. I guess the new frame buffer must be
incompatible with the card's driver.

I tried this:

$ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log

(II) Module nv: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 2.1.17
Module class: X.Org Video Driver
--
(II) Module vesa: vendor="X.Org Foundation"
compiled for 1.7.7, module version = 2.3.0
Module class: X.Org Video Driver

I'm not sure I understand what's going on here. Does that say I'm using
nv or vesa now?

Whichever one I'm using doesn't seem to like the change.

> If you want to report a bug upstream, please see
> http://nouveau.freedesktop.org/wiki/FrontPage#Bugs.
>
> Cheers,
> Sven

Yes, thank you, Sven. I think I will attempt to report a bug. I hope
they won't mind a bug report from a dumb ox.

I really appreciate your help.

Regards,
Gil


--
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/4C138DDD.4050900(a)comcast.net
From: Steven on 12 Jun 2010 12:50
On Fri, 2010-06-11 at 22:30 +0200, Andreas Rönnquist wrote:
> On Fri, 11 Jun 2010 13:06:04 -0400
> Gilbert Sullivan <whirlygig(a)comcast.net> wrote:
>
> > Running Squeeze with Xfce desktop environment (only) on Dell Latitude
> > D810. Nvidia video card running the VESA driver (though there's a bunch
> > of verbiage in dmesg about nouveau). System is normally connected to a
> > port replicator and DVI display (1680x1050).
> >
> > Upgraded from 2.6.32-3 to 2.6.32-6 this morning, saying yes to
> > reconfiguration.
> >
> > Upon reboot I see the normal scrolling of messages in the middle of the
> > screen, but (after populating devices message) the screen goes black.
> >
> ----->8------
> >
> > Many thanks for clues.
> >
> >
> Hi!
>
> I've ran into this too, and got this solved by blacklisting the nouveau
> module in
>
> /etc/modprobe.d/blacklist.conf
>
> (adding a line containing just "blacklist nouveau"),
> and adding modeset=0 to my kernel line in /boot/grub/menu.lst (I am
> still on grub-legacy, don't know how it is done on grub-2 unfortunately)
>
> This made the system boot fine, but X didn't start before reinstalling
> the nvidia drivers. Doing so and rebooted I was in a functional X, just
> like before the upgrade of the kernel.
>
> best regards
> --
> Andreas Rönnquist <gusnan(a)gusnan.se>
>
>

Thank you Andres :)

I experienced a similar problem after upgrading to a new kernel today in
squeeze, I noticed the resolution of the screen in text-mode had
changed, and X wouldn't load.
Since it was a kernel update, I'd figure I would recompile my nvidia
driver modules (proprietary nvidia driver). The nvidia installer failed
however and looking on this list I saw your message, blacklisting
nouveau allows me to load the nvidia driver again (I need some of it's
features, nouveau doesn't handle my setup very well yet, mostly 3D
acceleration).

It looks to me like the nouveau module is conflicting with (any?) other
drivers.

Regards,
Steven


--
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/1276360896.2710.8.camel(a)portable-steven.LAN
From: Sven Joachim on 12 Jun 2010 13:50
On 2010-06-12 15:38 +0200, Gilbert Sullivan wrote:

> On 06/12/2010 04:03 AM, Sven Joachim wrote:
>>
>> Thanks. I don't see anything unusual in it, in particular nouveau
>> detects the 1680x1050 resolution of the external display:
>>
>>> [ 7.308183] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x49000, bo f6feb600
>>> [ 7.319925] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>>> [ 7.319929] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
>>> [ 7.319931] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>>> [ 7.321231] Console: switching to colour frame buffer device 210x65
>
> Yes, I saw that and wondered why, if it's detecting the resolution
> properly, it isn't working. I guess the new frame buffer must be
> incompatible with the card's driver.

Nouveau _is_ the card's driver. Or are you talking about X.Org?

> I tried this:
>
> $ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
>
> (II) Module nv: vendor="X.Org Foundation"
> compiled for 1.7.7, module version = 2.1.17
> Module class: X.Org Video Driver
> --
> (II) Module vesa: vendor="X.Org Foundation"
> compiled for 1.7.7, module version = 2.3.0
> Module class: X.Org Video Driver
>
> I'm not sure I understand what's going on here. Does that say I'm
> using nv or vesa now?

Both will not work correctly, and the newest versions of these drivers
will refuse to load if nouveau is present. You need to install
xserver-xorg-video-nouveau or xserver-xorg-video-fbdev, those are the
only X drivers that work with the nouveau kernel module.

> Whichever one I'm using doesn't seem to like the change.

Does X even start? I suppose it doesn't if you only have the nv and
vesa drivers.

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/87k4q4cfky.fsf(a)turtle.gmx.de
From: Gilbert Sullivan on 12 Jun 2010 15:10
On 06/12/2010 01:42 PM, Sven Joachim wrote:
> On 2010-06-12 15:38 +0200, Gilbert Sullivan wrote:
>
>> On 06/12/2010 04:03 AM, Sven Joachim wrote:
>>>
>>> Thanks. I don't see anything unusual in it, in particular nouveau
>>> detects the 1680x1050 resolution of the external display:
>>>
>>>> [ 7.308183] [drm] nouveau 0000:01:00.0: allocated 1680x1050 fb: 0x49000, bo f6feb600
>>>> [ 7.319925] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>>>> [ 7.319929] [drm] nouveau 0000:01:00.0: Setting dpms mode 0 on tmds encoder (output 2)
>>>> [ 7.319931] [drm] nouveau 0000:01:00.0: Output DVI-D-1 is running on CRTC 0 using output A
>>>> [ 7.321231] Console: switching to colour frame buffer device 210x65
>>
>> Yes, I saw that and wondered why, if it's detecting the resolution
>> properly, it isn't working. I guess the new frame buffer must be
>> incompatible with the card's driver.
>
> Nouveau _is_ the card's driver. Or are you talking about X.Org?
>
>> I tried this:
>>
>> $ grep -B2 'Module class: X.Org Video Driver' /var/log/Xorg.0.log
>>
>> (II) Module nv: vendor="X.Org Foundation"
>> compiled for 1.7.7, module version = 2.1.17
>> Module class: X.Org Video Driver
>> --
>> (II) Module vesa: vendor="X.Org Foundation"
>> compiled for 1.7.7, module version = 2.3.0
>> Module class: X.Org Video Driver
>>
>> I'm not sure I understand what's going on here. Does that say I'm
>> using nv or vesa now?
>
> Both will not work correctly, and the newest versions of these drivers
> will refuse to load if nouveau is present. You need to install
> xserver-xorg-video-nouveau or xserver-xorg-video-fbdev, those are the
> only X drivers that work with the nouveau kernel module.

I have both xserver-xorg-video-nouveau and xser-xorg-video-fbdev
installed (just confirmed it in aptitude), but it doesn't appear that
they are being used.

I did try using the 4-line minimal xorg.conf file suggested at the
nouveau.freedesktop.org location to force nouveau to be used. When I
booted I got a blue text-graphics screen which said that X had failed to
start and which asked if I wanted to view the log (with a choice of yes
/ no). However, I didn't get a chance to answer because I was then
unceremoniously dumped at the console logon prompt. I logged on as root
and removed the 4-line file, and then everything was as it had been before.

I would trying turning KMS off just to see if I could learn anything,
but I haven't yet found out how to do it with a grub 2 system.

>
>> Whichever one I'm using doesn't seem to like the change.
>
> Does X even start? I suppose it doesn't if you only have the nv and
> vesa drivers.
>

X apparently *always* starts (except for the one time when I tried to
specify use of nouveau in /etc/X11/xorg.conf). I'm showing the nv and
vesa drivers in the log in both situations (docked and undocked, new
kernel and old kernel). When I'm undocked and using the 1920x1200
display I can boot with the new kernel and everything works perfectly.
When I'm docked, booting the new kernel, and using the 1680x1050 display
all I get after the waiting for /dev to be populated message is a black
screen (on the external display).

I just tried lifting the lid of the notebook while it was docked (hard
to do because of the physical location of the port replicator) and saw
that it, too, was black. When I lifted it further I saw the backlight
come on, but no information was being displayed on the screen. I tried
using the keyboard toggle to force the external screen to be used, but
nothing happened.

I logged on to the notebook remotely again and was able to launch
graphical applications on the system in the ssh -X session.

It looks to me as though X is always loaded, but that something about
the new KMS (or whatever it is) doesn't like my docked hardware
configuration and won't allow output to any screen when the system is
docked. (I may be guilty of assuming more than I should, but I'll admit
I'm pretty ignorant of the way all of this stuff works these days.)

I'm looking at the link you gave me to see if I can file a meaningful
bug report, but so much of the documentation there concerns the process
of getting nouveau to work at a time before all of the new packages were
released that I'm not sure I know how to proceed without merely making a
pest of myself.

In the meantime, I boot with the old kernel when docked and the new
kernel when undocked, and the system behaves perfectly. I'll keep
chipping away at it in the hope of learning something useful or posting
a reasonably meaningful bug report.

If you have any suggestions regarding testing that I might do I'm
willing to give it a shot. I'm wondering what would happen if I
performed a fresh installation of Squeeze on the system. But I would
*much* rather learn why it's behaving the way it is. I should point out
that I have never used proprietary nvidia drivers on this system since
the beginning of this netinst of Squeeze. And, as far as I knew, I was
using the vesa drivers only. I would swear that the appearance of nv in
that log has to be very recent.

Thank you again, 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/4C13DAB8.3040606(a)comcast.net
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: debian architecture history question
Next: Mutt and GPG - claims ALL signatures can't be verified