Bug 109407 - GTX 1050 fails to initialise acceleration
Summary: GTX 1050 fails to initialise acceleration
Status: RESOLVED MOVED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/nouveau (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-21 20:17 UTC by Tom Hughes
Modified: 2019-12-04 09:47 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Kernel log (153.02 KB, text/plain)
2019-01-21 20:17 UTC, Tom Hughes
no flags Details
Video BIOS (233.00 KB, application/octet-stream)
2019-01-21 20:18 UTC, Tom Hughes
no flags Details

Description Tom Hughes 2019-01-21 20:17:52 UTC
Created attachment 143179 [details]
Kernel log

I have a GTX 1050 card that seems to be failing to initialise acceleration leading Gnome to fallback to software rendering. The card is:

43:00.0 VGA compatible controller: NVIDIA Corporation GP107 [GeForce GTX 1050 3GB] (rev a1)

and an extract of relevant looking log messages:

Jan 21 19:27:17 localhost.localdomain kernel: MXM: GUID detected in BIOS
Jan 21 19:27:17 localhost.localdomain kernel: nouveau 0000:43:00.0: NVIDIA GP107 (137000a1)
Jan 21 19:27:17 localhost.localdomain kernel: nouveau 0000:43:00.0: bios: version 86.07.61.00.25
Jan 21 19:27:17 localhost.localdomain kernel: nouveau 0000:43:00.0: fb: 3072 MiB GDDR5
Jan 21 19:27:18 localhost.localdomain kernel: [TTM] Zone  kernel: Available graphics memory: 65973248 kiB
Jan 21 19:27:18 localhost.localdomain kernel: [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
Jan 21 19:27:18 localhost.localdomain kernel: [TTM] Initializing pool allocator
Jan 21 19:27:18 localhost.localdomain kernel: [TTM] Initializing DMA pool allocator
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: VRAM: 3072 MiB
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: GART: 536870912 MiB
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: BIT table 'A' not found
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: BIT table 'L' not found
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: TMDS table version 2.0
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB version 4.1
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB outp 00: 01000f42 04620030
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB outp 01: 02011f62 04620010
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB outp 02: 02822f76 04600020
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB outp 03: 02022f72 04620020
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB conn 00: 00001031
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB conn 01: 00010161
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: DCB conn 02: 00020246
Jan 21 19:27:18 localhost.localdomain kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
Jan 21 19:27:18 localhost.localdomain kernel: [drm] Driver supports precise vblank timestamp query.
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: MM: using COPY for buffer copies
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: secboot: SEC2 failed to start
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: sec2: unhandled intr 00000010
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: gr: init failed, -22
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: DRM: allocated 2560x1600 fb: 0x200000, bo 00000000f94c15a8
Jan 21 19:27:18 localhost.localdomain kernel: fbcon: nouveaufb (fb0) is primary device
Jan 21 19:27:18 localhost.localdomain kernel: Console: switching to colour frame buffer device 320x100
Jan 21 19:27:18 localhost.localdomain kernel: nouveau 0000:43:00.0: fb0: nouveaufb frame buffer device
Jan 21 19:27:18 localhost.localdomain kernel: [drm] Initialized nouveau 1.3.1 20120801 for 0000:43:00.0 on minor 0
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: nvc0_screen_create:983 - Error allocating PGRAPH context for M2MF: -16
Jan 21 19:27:21 localhost.localdomain kernel: nouveau 0000:43:00.0: gr: FECS falcon already acquired by gr!
Jan 21 19:27:21 localhost.localdomain kernel: nouveau 0000:43:00.0: gr: init failed, -16
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: glamor: No eglstream capable devices found
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: glamor: 'wl_drm' not supported
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: Missing Wayland requirements for glamor GBM backend
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: Missing Wayland requirements for glamor EGLStream backend
Jan 21 19:27:21 localhost.localdomain org.gnome.Shell.desktop[1930]: Failed to initialize glamor, falling back to sw

Full kernel logs are attached, along with the VBIOS.
Comment 1 Tom Hughes 2019-01-21 20:18:36 UTC
Created attachment 143180 [details]
Video BIOS
Comment 2 Ilia Mirkin 2019-01-21 20:28:40 UTC
Hm - this is probably not good:

nouveau 0000:43:00.0: secboot: SEC2 failed to start

There's a comment in the code before this happens:

        /*
         * There is a bug where the LS firmware sometimes require to be started
         * twice (this happens only on SEC). Detect and workaround that
         * condition.
         *
         * Once started, the falcon will end up in STOPPED condition (bit 5)
         * if successful, or in HALT condition (bit 4) if not.
         */

And then it goes on to try to re-start things, and when *that* fails, you get the "SEC2 failed to start" message. This code was contributed by NVIDIA, I don't think we know much about it.

Make sure you have the latest firmware from linux-firmware, as it occasionally does get updated. However I'm not sure I've seen this particular failure before.
Comment 3 Tom Hughes 2019-01-21 20:33:13 UTC
Yes I already found that comment... I should have mentioned that this is 4.19.15-300.fc29.x86_64 and it's using the current Fedora 29 linux-firmware (linux-firmware-20181219-89.git0f22c852.fc29.noarch) but I'll have a look at upstream at see if there's anything newer.
Comment 4 Tom Hughes 2019-01-21 20:36:58 UTC
No changes to anything under nvidia since then :-(

Of course it works with the nvidia drivers.
Comment 5 John Connett 2019-05-07 22:11:33 UTC
Seeing similar behaviour with a PNY Quadro P620 card in a Supermicro X11SPM-TF motherboard running openSUSE Tumbleweed (VERSION="20190505").  Slightly different BIOS version:

    nouveau 0000:65:00.0: NVIDIA GP107 (137000a1)
    nouveau 0000:65:00.0: bios: version 86.07.51.00.04
    nouveau 0000:65:00.0: fb: 2048 MiB GDDR5
    [...]
    nouveau 0000:65:00.0: secboot: SEC2 failed to start
    nouveau 0000:65:00.0: sec2: unhandled intr 00000010
    nouveau 0000:65:00.0: gr: init failed, -22
    
Might be some further confusion as this motherboard has an onboard ASPEED AST 2500, a Server Management Processor which also provides a 2D Video Graphics Adapter.

Please let me know if I might be able to provide more information to identify the problem.
Comment 6 Martin Peres 2019-12-04 09:47:58 UTC
-- 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/476.


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.