mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael B. Trausch" <mike@trausch.us>
To: Alistair John Strachan <alistair@devzero.co.uk>
Cc: linux-kernel@vger.kernel.org, pazke@ports.donpac.ru, ariveira@gmail.com
Subject: Re: Linux 2.6.28-rc7
Date: Tue, 2 Dec 2008 12:11:11 -0500	[thread overview]
Message-ID: <20081202121111.245d2ecc@zest.spicerack.trausch.us> (raw)
In-Reply-To: <fa.98CeSgxJ/GGaLLyZ97s1oHgh7hE@ifi.uio.no>

[-- Attachment #1: Type: text/plain, Size: 3446 bytes --]

On Tue, 02 Dec 2008 15:30:35 UTC
Alistair John Strachan <alistair@devzero.co.uk> wrote:
> One thing I would point out is that your distro kernel (presumably
> 2.6.27 or older) would probably have had the NVIDIA module to hand
> and would not drop into safe mode, right? In this case, VT switching
> behaviour may be entirely different.

Ubuntu 8.10 comes with a 2.6.27 kernel as packaged by Ubuntu.

> Could you please find out what framebuffer driver your distro is
> loading (probably nvidiafb, I'd guess) before starting X, and what
> Xorg driver Ubuntu use in this "safe graphics mode" (nv, vesa)? Also,
> could you try removing the nvidia module in the older kernel and
> confirm that the same VT corruption does not occur, so Rafael can
> identify this as a regression?

The stock Ubuntu install includes vesafb support, but Alejandro's dmesg
doesn't indicate that he's using vesafb at all.  The NVIDIA kernel
module refuses to work with the nvidiafb driver (claiming a conflict)
so if the NVIDIA module loads, nvidiafb isn't present.  (In fact, the
NVIDIA kernel module linkage will refuse to build against a kernel that
was even configured for nvidiafb).

I'm using 2.6.28-rc7 successfully on Ubuntu with the NVIDIA kernel
module as packaged by Ubuntu (Ubuntu 8.10 uses DKMS to manage the
module).  A single change to the linkage's C code was necessary, and
it is also necessary to either instruct the linkage where to find
relocated kernel headers or to create some symlinks:

 $ cd /lib/modules/2.6.28-rc7/source/include/asm-x86
 $ ln -s ../../arch/x86/include/asm/* .

(This may be different for a 32-bit configuration; mine is a 64-bit
x86-64 kernel.  I don't think it is different, though.)  I have it
working both using the standard 80x25 VGA console and with the vesafb
driver providing a significantly larger console.

> (Maybe things have changed over the years, but my understanding was
> that for the majority of Xorg drivers, mode setting was still done by
> the Xorg driver, not the kernel, and the X server is responsible for
> restoring the VT correctly, not the kernel's framebuffer driver. So
> this may possibly not be a kernel bug at all.)

NVIDIA still does mode setting in X.org, by default detecting the
native resolution of the attached monitor and using that.

This doesn't affect the VGA console... however, I have run into
NVIDIA-based graphics boards that don't like mode changes very much.
Some of the really finicky cards require using vesafb in the kernel and
then telling X.org to use the kernel-provided framebuffer to get it to
work correctly.

Also, the VESA X.org driver doesn't play nicely with all NVIDIA
boards; this might explain why the system didn't switch cleanly to a VT
after starting in "safe mode" --- which is Ubuntu's way of saying,
"640x480 using the vesa X.org driver".

Alejandro, can you switch back to VTs again after rebuilding your
NVIDIA module?  Also, you seem to have mentioned that you're not using
Ubuntu's packaged NVIDIA driver... this may mean that you've
overwritten and/or moved other files that Ubuntu uses, since the NVIDIA
driver installer does this automatically.  Can you try using a stock
system, updated kernel, and let DKMS build the NVIDIA module?  You'll
need to make some alterations, but I can help with those.

	HTH,
	Mike

-- 
My sigfile ran away and is on hiatus.
http://www.trausch.us/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

       reply	other threads:[~2008-12-02 17:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.IDjfwzrT2B02+NHfmYwtICnzOOA@ifi.uio.no>
     [not found] ` <fa.J8MFTCUT8El3sK8BuYDBvaMRaB8@ifi.uio.no>
     [not found]   ` <fa.q/4H3AtoJGSJ+i8tlXR4X35LFFU@ifi.uio.no>
     [not found]     ` <fa.98CeSgxJ/GGaLLyZ97s1oHgh7hE@ifi.uio.no>
2008-12-02 17:11       ` Michael B. Trausch [this message]
2008-12-02 18:06         ` Alejandro Riveira Fernández
2008-12-02 18:56           ` Michael B. Trausch
2008-12-02  4:11 Linus Torvalds
2008-12-02 12:14 ` Alejandro Riveira Fernández
2008-12-02 13:11   ` pazke
2008-12-02 14:48     ` Alejandro Riveira Fernández
2008-12-02 15:20       ` Alistair John Strachan
2008-12-02 15:50         ` Alejandro Riveira Fernández
2008-12-02 16:14           ` Alistair John Strachan
2008-12-02 15:54         ` Alejandro Riveira Fernández
2008-12-02 15:50   ` Linus Torvalds
2008-12-02 15:56     ` Alejandro Riveira Fernández
2008-12-02 16:13       ` Linus Torvalds
2008-12-02 18:49         ` Alejandro Riveira Fernández
2008-12-02 19:22           ` Alejandro Riveira Fernández
2008-12-02 19:23           ` Linus Torvalds
2008-12-02 19:45             ` Alejandro Riveira Fernández
2008-12-02 20:40               ` Linus Torvalds
2008-12-02 20:29             ` Al Viro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081202121111.245d2ecc@zest.spicerack.trausch.us \
    --to=mike@trausch.us \
    --cc=alistair@devzero.co.uk \
    --cc=ariveira@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pazke@ports.donpac.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®