Re: Nouveau DRM failure on 5120x1440 screen with 5.8/5.9 kernel
On Tue, 13 Oct 2020, Byron Stanoszek wrote: I'm having a problem with both the 5.8 and 5.9 kernels using the nouveau DRM driver. I have a laptop with a VGA card (specs below) connected to a 5120x1440 screen. At boot time, the card correctly detects the screen, tries to allocate fbdev fb0, then the video hangs completely for 15-30 seconds until it goes blank. This message eventually displays after a while: Workqueue: nvkm-disp nv50_disp_super RIP: 0010:nv50_disp_super_2_2+0x1b0/0x470 Code: 69 00 00 48 69 c0 d3 4d 62 10 48 c1 e8 26 49 89 c5 0f b7 43 40 44 89 e9 8d 44 02 f9 0f b7 53 46 29 d0 31 d2 48 98 49 0f af c4 <48> f7 f1 48 89 c6 0f b7 43 4e 0f b7 53 4c 83 e8 19 29 d0 31 d2 48 RSP: 0018:c95e3e08 EFLAGS: 00010206 RAX: RBX: 88841b08ed20 RCX: RDX: RSI: c90003614200 RDI: 820c1140 RBP: 88841b202060 R08: R09: 61ce R10: 0018 R11: 0018 R12: R13: R14: 88841b96b800 R15: 88841b975000 FS: () GS:88841dc0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 7f922e61e000 CR3: 0240a004 CR4: 001706b0 Call Trace: ? nvkm_dp_disable+0x5d/0x70 ? nv50_disp_super+0x137/0x220 ? process_one_work+0x19c/0x2c0 ? worker_thread+0x48/0x350 ? process_one_work+0x2c0/0x2c0 ? kthread+0x129/0x150 ? __kthread_create_worker+0x100/0x100 ? ret_from_fork+0x22/0x30 ---[ end trace dbb0d14fd1ddb445 ]--- nouveau :01:00.0: DRM: core notifier timeout Thanks, -Byron ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Nouveau DRM failure on 5120x1440 screen with 5.8/5.9 kernel
I'm having a problem with both the 5.8 and 5.9 kernels using the nouveau DRM driver. I have a laptop with a VGA card (specs below) connected to a 5120x1440 screen. At boot time, the card correctly detects the screen, tries to allocate fbdev fb0, then the video hangs completely for 15-30 seconds until it goes blank. This used to work in Linux 5.7 and earlier, although it allocated a 3840x1080 fb instead of a 5120x1440. I've attached the full dmesg. I tried commands like video=DP-2:3840x1080 but it doesn't help. Linux 5.8 boots without hanging if the laptop is not connected to the 5120x1440 screen. PCI specs: 01:00.0 0300: 10de:0dfc (rev a1) 01:00.0 VGA compatible controller: NVIDIA Corporation GF108GLM [NVS 5200M] (rev a1) xrandr available resolutions reported (from Linux 5.7 using Xorg): Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 LVDS-1 unknown connection (normal left inverted right x axis y axis) 1600x900 59.99 + 40.00 5120x1440 60.00 1360x1020 73.97 1152x864 59.97 1024x768 59.95 800x600 59.96 640x480 59.94 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 5120x1440+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm panning 5120x1440+0+0 3840x1080 59.97 + 5120x1440 29.98* 2560x1080 60.0059.9459.98 1920x1080 60.0060.0050.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) VGA-1 disconnected (normal left inverted right x axis y axis) I'm currently using 5120x1440@30. 60 Hz isn't available. But look below: xrandr resolutions from Linux 5.9 (even though screen is still blank): Screen 0: minimum 320 x 200, current 5120 x 1440, maximum 16384 x 16384 LVDS-1 unknown connection (normal left inverted right x axis y axis) 1600x900 59.99 + 40.00 5120x1440 60.00 1360x1020 73.97 1152x864 59.97 1024x768 59.95 800x600 59.96 640x480 59.94 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 connected primary 5120x1440+0+0 (normal left inverted right x axis y axis) 1200mm x 340mm panning 5120x1440+0+0 5120x1440 59.98 + 29.98* 3840x1080 59.97 + 2560x1080 60.0059.9459.98 1920x1080 60.0060.0050.0059.94 1920x1080i60.0050.0059.94 1600x1200 60.00 1280x1024 75.0260.02 1280x800 59.81 1152x864 75.00 1280x720 60.0050.0059.94 1024x768 75.0360.00 800x600 75.0060.32 720x576 50.00 720x480 60.0059.94 640x480 75.0060.0059.94 720x400 70.08 HDMI-1 disconnected (normal left inverted right x axis y axis) VGA-1 disconnected (normal left inverted right x axis y axis) Let me know if you need additional debug information/etc. Thanks, -Byron microcode: microcode updated early to revision 0x21, date = 2019-02-13 Linux version 5.9.0 (r...@iss.comtime.lan) (gcc (Gentoo 10.2.0-r2 p3) 10.2.0, GNU ld (Gentoo 2.35.1 p1) 2.35.1) #2 SMP PREEMPT Tue Oct 13 14:54:36 EDT 2020 Command line: auto BOOT_IMAGE=cti ro root=801 cti KERNEL supported cpus: Intel GenuineIntel x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. BIOS-provided physical RAM map: BIOS-e820: [mem 0x-0x0009e7ff] usable BIOS-e820: [mem 0x0009e800-0x0009] reserved BIOS-e820: [mem 0x000e-0x000f] reserved BIOS-e820: [mem 0x0010-0xc9f09fff] usable BIOS-e820: [mem 0xc9f0a000-0xc9ff] reserved BIOS-e820: [mem 0xca00-0xca752fff] usable BIOS-e820: [mem 0xca753000-0xca7f] reserved BIOS-e820: [mem 0xca80-0xcafb1fff] usable BIOS-e820: [mem 0xcafb2000-0xcaff] ACPI data BIOS-e820: [mem 0xcb00-0xcc6fbfff] usable BIOS-e820: [mem 0xcc6fc000-0xcc7f] ACPI NVS BIOS-e820: [mem 0xcc80-0xcdda0fff] usable BIOS-e820: [mem 0xcdda1000-0xce7a4fff] reserved BIOS-e820: [mem 0xce7a5000-0xce7e7fff] ACPI NVS BIOS-e820: [mem 0xce7e8000-0xcf2b2fff] usable BIOS-e820: [mem 0xcf2b3000-0xcf7e] reserved BIOS-e820: [mem
Standalone DRM application
On Thu, 18 Apr 2013, David Herrmann wrote: > You can acquire/drop DRM-Master via drmSetMaster/drmDropMaster. > > If your DRM card is a PCI device, you can use the sysfs "boot_vga" > attribute of the parent PCI device. > (/sys/class/drm/card0/device/boot_vga) David, Thanks! That was exactly what I was looking for. Both ideas work wonderfully. Regards, -Byron
Re: Standalone DRM application
On Thu, 18 Apr 2013, David Herrmann wrote: You can acquire/drop DRM-Master via drmSetMaster/drmDropMaster. If your DRM card is a PCI device, you can use the sysfs boot_vga attribute of the parent PCI device. (/sys/class/drm/card0/device/boot_vga) David, Thanks! That was exactly what I was looking for. Both ideas work wonderfully. Regards, -Byron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Standalone DRM application
David, I'm developing a small application that uses libdrm (DRM ioctls) to change the resolution of a single graphics display and show a framebuffer. I've run into two problems with this implementation that I'm hoping you can address. 1. Each application is its own process, which is designed to control 1 graphics display. This is unlike X, for instance, which could be configured to grab all of the displays in the system at once. Depending on our stackup, there can be as many as 4 displays connected to a single graphics card. One process could open /dev/dri/card0 and call drmModeSetCrtc() to initialize one of its displays to the requested resolution. However, whenever a second process calls drmModeSetCrtc() to control a second display on the same card, it gets -EPERM back from the ioctl. I've traced this down to the following line in linux/drivers/gpu/drm/drm_drv.c: DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED), If I remove the DRM_MASTER flag, then my application behaves correctly, and 4 separate processes can then control each individual display on the card without issue. My question is, is there any real benefit to restricting drm_mode_setcrtc() with DRM_MASTER, or can we lose this flag in order to support one-process-per- display programs like the above? 2. My application has the design requirement that screen 1 always refers to the card that was initialized by the PC BIOS for bootup. This is the same card that the Linux Console framebuffer will come up on by default, and therefore extra processing is required to handle VT switches (e.g. pause the display, restore original CRTC mode, etc.) Depending on the Boot Display First [Onboard] or [PCI Slot] option in the BIOS, this might mean either /dev/dri/card0 or /dev/dri/card1 becomes the default VGA card, as set by the vga_set_default_device() call in arch/x86/pci/fixup.c. Is there a way in userspace to identify which card# is the default card? Or alternatively, is there some way to get the underlying PCI bus/slot ID from a /dev/dri/card# device. Thanks, -Byron ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Standalone DRM application
David, I'm developing a small application that uses libdrm (DRM ioctls) to change the resolution of a single graphics display and show a framebuffer. I've run into two problems with this implementation that I'm hoping you can address. 1. Each application is its own process, which is designed to control 1 graphics display. This is unlike X, for instance, which could be configured to grab all of the displays in the system at once. Depending on our stackup, there can be as many as 4 displays connected to a single graphics card. One process could open /dev/dri/card0 and call drmModeSetCrtc() to initialize one of its displays to the requested resolution. However, whenever a second process calls drmModeSetCrtc() to control a second display on the same card, it gets -EPERM back from the ioctl. I've traced this down to the following line in linux/drivers/gpu/drm/drm_drv.c: DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED), If I remove the DRM_MASTER flag, then my application behaves correctly, and 4 separate processes can then control each individual display on the card without issue. My question is, is there any real benefit to restricting drm_mode_setcrtc() with DRM_MASTER, or can we lose this flag in order to support one-process-per- display programs like the above? 2. My application has the design requirement that "screen 1" always refers to the card that was initialized by the PC BIOS for bootup. This is the same card that the Linux Console framebuffer will come up on by default, and therefore extra processing is required to handle VT switches (e.g. pause the display, restore original CRTC mode, etc.) Depending on the "Boot Display First [Onboard] or [PCI Slot]" option in the BIOS, this might mean either /dev/dri/card0 or /dev/dri/card1 becomes the default VGA card, as set by the vga_set_default_device() call in arch/x86/pci/fixup.c. Is there a way in userspace to identify which card# is the default card? Or alternatively, is there some way to get the underlying PCI bus/slot ID from a /dev/dri/card# device. Thanks, -Byron
