Le 25 janvier 2012 18:10, Sven Joachim <[email protected]> a écrit : > On 2012-01-25 18:04 +0100, Rémi Moyen wrote: > >> I am also guessing, based on this (why didn't I think about that >> earlier?) that in the 3.1 kernel, my card is supposed to be supported >> by nouveau, hence it tries to use it (and this causes all my problems) >> whereas in 2.6.32 it doesn't even try to use nouveau and falls back to >> vesafb or something like it, hence it still manages to display >> something. Does this makes sense, or is this gibberish? > > It makes sense, but since you seem to have the problem even with > "nomodeset", it might not actually be the cause.
OK, actually... it does seem to work now! What I did is, I booted with the 3.1 kernel, remotely logged in, checked that nouveau was blacklisted (by an nvidia-smthg file in /etc/modprobe.d), ran depmod & update-initramfs, then rebooted. At that point, I still had the problem. dmseg was however indicating that it was loading the nvidia module, and there was absolutely not a single line implying that nouveau was used in anyway. Then I tried again to pass nomodeset to the kernel, and... it worked! The system boots correctly, I get my login prompt, it says it is using the nvidia module. I am now installing X to see if that works as well, but I am reasonably hopeful now! I could swear that I did try the nomodeset option, especially since another computer in the house had a similar problem that required a similar solution (it was a Fedora and for some reason it requires a rdblacklist=nouveau option in addition to the nomodeset). Well, either I somehow mistyped that the first time, or maybe some of the other manipulations (such as installing nvidia, blacklisting nouveau, running depmod...) were needed in addition to that parameter? Anyway, I seem to have a running system, so the problem seems solved. Many thanks for spending some time helping me to get there! >> Where did you find this information? > > On upstream's wikią there is a link to the relevant kernel commit˛. OK, thanks for the info. >> Kernel 3.2 seems to be still in unstable, I'd rather not install >> something from there if I can avoid it. > > No, 3.2 has been in testing for six days, 3.1 is not supported anymore. But linux-image-am64 still seems to be in version 3.1 and depends from linux-image-3.1.0-1-amd64? I don't want to nominally install the 3.2 kernel, I only want the latest one, so I think I'll stick to linux-image-amd64 and wait until that updates to 3.2. Should be quite soon, I guess. >> * To blacklist nouveau, there needs to be a "blacklist nouveau" line >> somewhere in a file in /etc/modprobe.d. The nvidia DKMS package does >> this (or I did that manually), but apparently this is not enough. > > It is enough to prevent udev from loading the module, but X will still > try to load it if you don't specify a different driver in xorg.xonf. Good point. I guess though that now that I have added nomodeset, nouveau will not be available to X, so it shouldn't even try to load it? >> I've yet to try running depmod -ae and regenerating the initrd >> afterwards, could not doing it be a reason why nouveau is not properly >> blacklisted? > > Only if you have added the module to the initramfs yourself, which is > unlikely. If you see the message "INIT: version 2.88 booting" in text > mode, your initramfs does not load it. I certainly have not added it myself. However I don't remember seeing the message. But on the other hand, some text was flashing on the screen, much too fast for me to read it. Maybe that was in there? >> * To completely disable nouveau, I should pass nomodeset to the >> kernel. I tried doing this by modifying the GRUB_CMDLINE_LINUX_DEFAULT >> (or GRUB_CMDLINE_LINUX) in /etc/default/grub and then running >> update-grub, this does not seem to work (then rebooting). Is it the >> right way to set this parameter? > > If you want to set it permanently, yes. Well, since it does not really seem to work with the nvidia module anyway, I don't see any point in keeping it. Again, thanks for your help! (and to everybody else who helped) -- Rémi Moyen -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/caobzh+mb0_5dvs-je9jndqi_uezurj_mt1uwr7btqgmos+d...@mail.gmail.com
