| Summary: | nouveau kernel module won't load (not available) on Sony laptop with NVIDIA G86M [GeForce 8400M GT] ID: 10de:0426 | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Felix Miata <mrmazda> |
| Component: | Driver/nouveau | Assignee: | Nouveau Project <nouveau> |
| Status: | RESOLVED MOVED | QA Contact: | Xorg Project Team <xorg-team> |
| Severity: | major | ||
| Priority: | not set | ||
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | |||
|
Description
Felix Miata
2019-09-29 14:14:35 UTC
I see no record of nouveau loading in the kernel logs. This most likely means that it's blacklisted somehow. How? e.g. on Tumbleweed: Nothing in /etc/mo*/ contains veau Nothing in /etc/ is named *veau* # lspci | grep -i vidia 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [GeForce 8400M GT] (rev a1) # uname -a Linux vaio 5.3.1-2.g3354216-vanilla #1 SMP Thu Sep 26 06:05:47 UTC 2019 (3354216) x86_64 x86_64 x86_64 GNU/Linux # cat /proc/cmdline root=/dev/sda9 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto consoleblank=0 drm.debug=0x1e log_buf_len=1M acpi=off 3 # pwd /lib/modules/5.3.1-2.g3354216-vanilla/kernel/drivers/gpu/drm/nouveau ls -l | grep veau -rw-r--r-- 1 root root 645980 Sep 27 05:03 nouveau.ko.xz # zcat /proc/config.gz | grep -i veau CONFIG_DRM_NOUVEAU=m # CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set CONFIG_NOUVEAU_DEBUG=5 CONFIG_NOUVEAU_DEBUG_DEFAULT=3 # CONFIG_NOUVEAU_DEBUG_MMU is not set CONFIG_DRM_NOUVEAU_BACKLIGHT=y CONFIG_DRM_NOUVEAU_SVM=y # modprobe nouveau modprobe: ERROR: could not insert 'nouveau': No such device How could it be blacklisted, and why does modprobe claim there is no such device? does anything in dmesg show the reason? On Sun, Sep 29, 2019 at 10:41 PM <bugzilla-daemon@freedesktop.org> wrote: > > Comment # 2 on bug 111853 from Felix Miata > > How? > e.g. on Tumbleweed: > Nothing in /etc/mo*/ contains veau > Nothing in /etc/ is named *veau* > # lspci | grep -i vidia > 01:00.0 VGA compatible controller: NVIDIA Corporation G86M [GeForce 8400M GT] > (rev a1) > # uname -a > Linux vaio 5.3.1-2.g3354216-vanilla #1 SMP Thu Sep 26 06:05:47 UTC 2019 > (3354216) x86_64 x86_64 x86_64 GNU/Linux > # cat /proc/cmdline > root=/dev/sda9 ipv6.disable=1 net.ifnames=0 noresume mitigations=auto > consoleblank=0 drm.debug=0x1e log_buf_len=1M acpi=off 3 > # pwd > /lib/modules/5.3.1-2.g3354216-vanilla/kernel/drivers/gpu/drm/nouveau > ls -l | grep veau > -rw-r--r-- 1 root root 645980 Sep 27 05:03 nouveau.ko.xz > # zcat /proc/config.gz | grep -i veau > CONFIG_DRM_NOUVEAU=m > # CONFIG_NOUVEAU_LEGACY_CTX_SUPPORT is not set > CONFIG_NOUVEAU_DEBUG=5 > CONFIG_NOUVEAU_DEBUG_DEFAULT=3 > # CONFIG_NOUVEAU_DEBUG_MMU is not set > CONFIG_DRM_NOUVEAU_BACKLIGHT=y > CONFIG_DRM_NOUVEAU_SVM=y > # modprobe nouveau > modprobe: ERROR: could not insert 'nouveau': No such device > > How could it be blacklisted, and why does modprobe claim there is no such > device? > > ________________________________ > You are receiving this mail because: > > You are the assignee for the bug. > > _______________________________________________ > Nouveau mailing list > Nouveau@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/nouveau Created attachment 145584 [details] dmesg following modprobe nouveau running vanilla kernel 5.3.1 (In reply to kherbst from comment #3) > does anything in dmesg show the reason? Not only is nothing showing any reason, but nothing showing modprobe nouveau was even attempted. Last line in journal ls initial login, and in dmesg, sky2 0000:02:00.0 eth0: Link is up at 1000 Mbps, full duplex, flow control both The only thing I can think of is the vesafb usage. However I thought there was a mechanism for us to kick out such a driver. But perhaps not, and perhaps it broke somehow. Can you try not booting with video=? Also, perhaps something's VERY wrong with the device, s.t. something fails very early in nouveau's attempts -- try loading nouveau with debug=trace (or, if putting into the kernel cmdline, nouveau.debug=trace) which should spam the kernel log pretty hard. (In reply to Ilia Mirkin from comment #5) > The only thing I can think of is the vesafb usage. However I thought there > was a mechanism for us to kick out such a driver. But perhaps not, and > perhaps it broke somehow. Can you try not booting with video=? That results in use of 80x25 text mode that is corrupted, random letters get shifted by one character from what they should have been, e.g. "t" drawn where "s" should be, or "d" drawn where "c" should be, and many clearly wrong characters, such as 15-30% of a screen full of "!!". The BIOS logo also has vertical lines through the SONY image, and the !! pairs appear on the otherwise black screen between BIOS splash and GFX Grub menu, and plain text mode Grub. > Also, perhaps something's VERY wrong with the device, s.t. something fails > very early in nouveau's attempts -- try loading nouveau with > debug=trace (or, if putting into the kernel cmdline, nouveau.debug=trace) > which should spam the kernel log pretty hard. It didn't, 331 bytes less than that of comment 4, only two lines containing "veau", both included on Kernel command line. This laptop isn't mine. It belongs to my church. It came to me to repair because of video corruption in Windows 7 that appeared only after warmup. I took out its HD and put in my SSD to facilitate troubleshooting after having the same trouble with Knoppix as is happening in openSUSE, and taking a long time to boot each time from Knoppix DVD. I quickly decided the Windows video corruption seemed to be nothing but overheating, so I've been running it most of the time with a 4" fan blowing on its bottom after having blown through its airways with compressed air when I first got it. Without the 4" fan, I can't tell if the heat coming from the vent is simply radiation, or from its fan. In 1024x768 VESA mode (with vga=) the video output doesn't get corrupted either on vttys or in Xorg. When I plug in a display to its HDMI port, the external display wakes up only to report "no HDMI signal", which it repeats going into or out of Xorg. Created attachment 145591 [details]
dmesg without vga= & with nouveau.debug=trace
A fresh installation of Windows 7 uses the panel's native 1440x900 mode via its "VGA" driver, though the HDMI port sends nothing to a display more than what's necessary to make it complain mode not supported. This is weird: [ 0.519104] pci 0000:01:00.0: BAR 6: no space for [mem size 0x00020000 pref] [ 0.519109] pci 0000:01:00.0: BAR 6: failed to assign [mem size 0x00020000 pref] Not sure if it's related. Created attachment 145757 [details] Xorg.0.log from live LMDE 2 Betsy boot # uname -a Linux stresslinux 2.6.37.6-0.5-default #1 SMP 2011-04-25 21:48:33 +0200 x86_64 x86_64 x86_64 GNU/Linux # lsmod | sort | grep veau button 6797 1 nouveau drm 229676 3 nouveau,ttm,drm_kms_helper drm_kms_helper 36630 1 nouveau i2c_algo_bit 6342 1 nouveau nouveau 678496 1 ttm 72581 1 nouveau video 15865 1 nouveau But Stresslinux 0.7.106 has no X :-( # uname -a Linux mint 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux # lsmod | sort | grep veau button 12944 1 nouveau drm 249955 3 ttm,drm_kms_helper,nouveau drm_kms_helper 49210 1 nouveau i2c_algo_bit 12751 1 nouveau i2c_core 46012 7 drm,i2c_i801,drm_kms_helper,i2c_algo_bit,v4l2_common,nouveau,videodev mxm_wmi 12515 1 nouveau nouveau 1122419 0 ttm 77862 1 nouveau video 18096 1 nouveau wmi 17339 2 mxm_wmi,nouveau # inxi -GxxS System: Host: mint Kernel: 3.16.0-4-amd64 x86_64 (64 bit gcc: 4.8.4) Desktop: MATE 1.8.1 (Gtk 3.14.5+4) dm: mdm Distro: LinuxMint 2 betsy Graphics: Card: NVIDIA G86M [GeForce 8400M GT] bus-ID: 01:00.0 chip-ID: 10de:0426 Display Server: X.Org 1.16.4 drivers: fbdev,vesa,nouveau Resolution: 1024x768@61.00hz GLX Renderer: Gallium 0.4 on llvmpipe (LLVM 3.5, 128 bits) GLX Version: 3.0 Mesa 10.3.2 Direct Rendering: Yes With this old live distro, nouveau loads, but there's no /dev/dri/card0 or /dev/fb0, so it's stuck in VESA 1024x768. Created attachment 145758 [details] Xorg.0.log from live Knoppix 7.6.1 # lsmod | sort | grep veau drm_kms_helper 70712 1 nouveau mxm_wmi 1635 1 nouveau nouveau 1033769 0 ttm 60685 1 nouveau wmi 7363 2 mxm_wmi,nouveau # inxi -c0 -GxxSM System: Host: Microknoppix Kernel: 4.2.6-64 x86_64 (64 bit gcc: 5.2.1) Console: tty 3 dm: kdm Distro: Debian GNU/Linux stretch/sid Machine: System: Sony (portable) product: VGN-AR730E v: C3LR1E11 serial: 28272434-3101919 Mobo: Sony model: VAIO Bios: Phoenix v: R2090J8 date: 02/26/2008 Chassis: type: 10 Graphics: Card: NVIDIA G86M [GeForce 8400M GT] bus-ID: 01:00.0 chip-ID: 10de:0426 Display Server: X.org 1.17.3 drivers: vesa,nouveau (unloaded: fbdev) tty size: 80x25 Advanced Data: N/A for root out of X # dmesg | grep ailed [ 0.770863] acpi PNP0A08:00: _OSC failed (AE_SUPPORT); disabling ASPM [ 0.849357] pci 0000:01:00.0: BAR 6: failed to assign [mem size 0x00020000 pref] [ 1.607734] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SATA.PRT0._SDD] (Node ffff8800bf08f338), AE_NOT_FOUND (20150619/psparse-536) [ 1.609103] ACPI Error: Method parse/execution failed [\_SB_.PCI0.SATA.PRT0._SDD] (Node ffff8800bf08f338), AE_NOT_FOUND (20150619/psparse-536) [ 37.465961] systemd-udevd[2004]: Process '/usr/sbin/alsactl -E HOME=/var/run/alsa restore 0' failed with exit code 99. [ 38.226541] systemd-udevd[2008]: Process '/sbin/crda' failed with exit code 249. [ 38.229603] systemd-udevd[2008]: Process '/sbin/crda' failed with exit code 249. [ 42.469065] systemd-udevd[2086]: Process '/usr/sbin/alsactl -E HOME=/var/run/alsa restore 0' failed with exit code 99. [ 69.564168] systemd-logind[2229]: Failed to start user service, ignoring: Unknown unit: user@1000.service [ 100.435441] uvcvideo: Failed to query (129) UVC probe control : -32 (exp. 26). [ 100.435443] uvcvideo: Failed to initialize the device (-5). Again, nouveau loads, but X video is scrambled VESA, again with no /dev/dri/card0 or /dev/fb0. AFAICT, the last or nearly the last tty message before screen stops responding without acpi=off follows this line: fb: switching to nouveaufb from VESA VGA at least, it does if I include vga=791 to try to get a reasonable text size on the vttys, and avoid all the !!!!!s. In the currently installed (on owner's HD alongside Win7) openSUSE 15.1 I tried disabling the built-in video camera with: module_blacklist=uvcvideo,videobuf2_core,videobuf2_memops,videobuf2_v4l2,videobuf2_vmalloc,videodev on cmdline instead of acpi=off, but it had no apparent impact. -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/507. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.