Description of problem: Nouveau does not load at all on this hardware. Booting is done without KMS, both on Fedora 14 live cd and installed rawhide, and I get a Xorg using the VESA driver. Version-Release number of selected component (if applicable): xorg-x11-drv-nouveau-0.0.16-13.20101010git8c8f15c.fc14.i686 xorg-x11-server-Xorg-1.9.1-2.fc15.i686 kernel-2.6.36-1.fc15.i686 How reproducible: Always Steps to Reproduce: 1. Boot system Actual results: Xorg is using VESA driver Expected results: KMS on ttys, plymouth, Xorg using nouveau driver Additional info: Dmesg doesn't say anything at all about nouveau. If I try to "modprobe nouveau" I get: WARNING: Error inserting i2c_algo_bit (/lib/modules/2.6.36-1.fc15.i686/kernel/drivers/i2c/algos/i2c-algo-bit.ko): No such device WARNING: Error inserting drm (/lib/modules/2.6.36-1.fc15.i686/kernel/drivers/gpu/drm/drm.ko): No such device WARNING: Error inserting drm_kms_helper (/lib/modules/2.6.36-1.fc15.i686/kernel/drivers/gpu/drm/drm_kms_helper.ko): No such device WARNING: Error inserting ttm (/lib/modules/2.6.36-1.fc15.i686/kernel/drivers/gpu/drm/ttm/ttm.ko): No such device FATAL: Error inserting nouveau (/lib/modules/2.6.36-1.fc15.i686/kernel/drivers/gpu/drm/nouveau/nouveau.ko): No such device and Xorg.0.log says [ 241.879] (II) NOUVEAU driver [ 241.879] (II) NOUVEAU driver for NVIDIA chipset families : [ 241.879] RIVA TNT (NV04) [ 241.880] RIVA TNT2 (NV05) [ 241.880] GeForce 256 (NV10) [ 241.880] GeForce 2 (NV11, NV15) [ 241.880] GeForce 4MX (NV17, NV18) [ 241.881] GeForce 3 (NV20) [ 241.881] GeForce 4Ti (NV25, NV28) [ 241.881] GeForce FX (NV3x) [ 241.881] GeForce 6 (NV4x) [ 241.882] GeForce 7 (G7x) [ 241.882] GeForce 8 (G8x) [ 241.882] (II) VESA: driver for VESA chipsets: vesa [ 241.883] (II) FBDEV: driver for framebuffer: fbdev [ 241.884] (--) using VT number 1 [ 241.915] drmOpenDevice: node name is /dev/dri/card0 [ 242.008] (WW) LoadKernelModule: Setting of real/effective user Id to 0/0 failed [ 242.100] [drm] failed to load kernel module "nouveau" [ 242.100] (EE) [drm] failed to open device and then switches to VESA Smolts: http://www.smolts.org/client/show/pub_15837f0f-d833-4384-a6e5-2cbde5b3a08d
Created attachment 458442 [details] Xorg.0.log
Created attachment 458443 [details] lspci.txt
Created attachment 458444 [details] dmesg.txt
Created attachment 458445 [details] lsmod
This is rather weird. Can you post "lspci -vvn" output please.
Created attachment 458890 [details] Output of 'lspci -vvn'
I have a "me too" .. similar results. Not sure if it is a bug or lack of knowledge on implementation(since shifting from F12 nvidia to F14 nouveau drivers) Note .. this on a x86_64 installation rather than i386. Using F14 release. kernel 2.6.35.6-48.fc14.x86_64 Nvidia Card G84 (GeForce 8600 GT xorg-x11-drv-nouveau-0.0.16-11.20100826git065576d.fc14.x86_64 xorg-x11-server-Xorg-1.9.1-2.fc14.x86_64 modprobe nouveau gives the same messages with the path being /lib/modules/2.6.35.6-48.fc14.x86_64/kernel/.... What further information would you require to help diagnose this
requested info was provided. I note, though, Ivo, you say "Booting is done without KMS". You mean, KMS doesn't seem to kick in, rather than you disabled it with 'nomodeset'? Using nouveau without KMS is no longer supported, so if you're manually disabling KMS, this wouldn't be a bug... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
(In reply to comment #8) > requested info was provided. I note, though, Ivo, you say "Booting is done > without KMS". You mean, KMS doesn't seem to kick in, rather than you disabled > it with 'nomodeset'? Using nouveau without KMS is no longer supported, so if > you're manually disabling KMS, this wouldn't be a bug... > > > > -- > Fedora Bugzappers volunteer triage team > https://fedoraproject.org/wiki/BugZappers Yes, I mean that I did not change (or disable) anything, and KMS just wouldn't start up as it does on other supported hardware.
Cool, thanks for the clarification. Over to Ben. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Adam, I think the problem is elsewhere than nouveau. There's a -ENODEV from various other modules that nouveau depends on, hence, it can't load.
ben: so do we re-assign to kernel and throw it to kyle or chuck or something? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I think this bug (Nouveau does not load) is no longer the case, as documented in #770197 ... although the new behavior might be even worse.
I gave a comptuer with the same chipset (NV11, 32MB VRAM), and ran into the same problem in Fedora 18, it worked in previous versions until then. The problem is nouveau needs acpi - The machine is so old (2000) the validitor couldn't parse the BIOS date an thought it was "too old" and so disabled ACPI. Yours has a similar problem: ACPI: BIOS age (1997) fails cutoff (1999), acpi=force is required to enable ACPI Applying acpi=force as suggested in the dmesg fixed thed this problem.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.