* Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics @ 2019-11-07 2:29 John Donnelly 2019-11-07 7:54 ` Thomas Zimmermann 0 siblings, 1 reply; 20+ messages in thread From: John Donnelly @ 2019-11-07 2:29 UTC (permalink / raw) To: dri-devel Hi, I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” on a number of servers using this driver. Specifically starting the GNOME desktop. This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. I don’t see any specific errors in the gdm logs or message file other than this: mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b000000 -> 0x9bffffff mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c810000 -> 0x9c813fff mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c000000 -> 0x9c7fffff fb0: switching to mgag200drmfb from EFI VGA mgag200 0000:04:00.0: vgaarb: deactivate vga console fbcon: mgag200drmfb (fb0) is primary device mgag200 0000:04:00.0: fb0: mgag200drmfb frame buffer device [drm] Initialized mgag200 1.0.0 20110418 for 0000:04:00.0 on minor 0 The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 2:29 Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics John Donnelly @ 2019-11-07 7:54 ` Thomas Zimmermann 2019-11-07 13:12 ` John Donnelly 0 siblings, 1 reply; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-07 7:54 UTC (permalink / raw) To: John Donnelly, dri-devel [-- Attachment #1.1.1: Type: text/plain, Size: 2437 bytes --] Hi John, apparently the vgaarb was not the problem. Am 07.11.19 um 03:29 schrieb John Donnelly: > Hi, > > I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” > on a number of servers using this driver. Specifically starting the GNOME desktop. When you say "text mode", do you mean VGA text mode or the graphical console that emulates text mode? When you enable graphics mode, does it set the correct resolution? A lot of work went into memory management recently. I could imagine that the driver sets the correct resolution, but then fails to display the correct framebuffer. If possible, could you try to update to the latest drm-tip and attach the output of /sys/kernel/debug/dri/0/vram-mm before and after switching to graphics mode. The file lists the allocated regions of the VRAM. > > This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. > > I don’t see any specific errors in the gdm logs or message file other than this: You can boot with drm.debug=0xff on the kernel command line to enable more warnings. > > > mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 0: 0x9b000000 -> 0x9bffffff > mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 1: 0x9c810000 -> 0x9c813fff > mgag200 0000:04:00.0: remove_conflicting_pci_framebuffers: bar 2: 0x9c000000 -> 0x9c7fffff Could you please attach the output of lspci -v for the VGA adapter? Best regards Thomas > > fb0: switching to mgag200drmfb from EFI VGA > mgag200 0000:04:00.0: vgaarb: deactivate vga console > fbcon: mgag200drmfb (fb0) is primary device > mgag200 0000:04:00.0: fb0: mgag200drmfb frame buffer device > [drm] Initialized mgag200 1.0.0 20110418 for 0000:04:00.0 on minor 0 > > The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 7:54 ` Thomas Zimmermann @ 2019-11-07 13:12 ` John Donnelly 2019-11-07 13:42 ` Thomas Zimmermann 0 siblings, 1 reply; 20+ messages in thread From: John Donnelly @ 2019-11-07 13:12 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen [-- Attachment #1: Type: text/plain, Size: 1385 bytes --] Hi Thomas ; Thank you for reaching out. See inline: > On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi John, > > apparently the vgaarb was not the problem. > > Am 07.11.19 um 03:29 schrieb John Donnelly: >> Hi, >> >> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >> on a number of servers using this driver. Specifically starting the GNOME desktop. > > When you say "text mode", do you mean VGA text mode or the graphical > console that emulates text mode? > I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. > When you enable graphics mode, does it set the correct resolution? A lot > of work went into memory management recently. I could imagine that the > driver sets the correct resolution, but then fails to display the > correct framebuffer. There is no display at all ; so there is no resolution to mention. > > If possible, could you try to update to the latest drm-tip and attach > the output of > > /sys/kernel/debug/dri/0/vram-mm I don’t see that file ; Is there something else I need to do ? I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; [-- Attachment #2: Xorg.0.log --] [-- Type: application/octet-stream, Size: 16385 bytes --] [ 237.684] (--) Log file renamed from "/var/lib/gdm/.local/share/xorg/Xorg.pid-2344.log" to "/var/lib/gdm/.local/share/xorg/Xorg.0.log" [ 237.684] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [ 237.684] Build Operating System: 4.18.0-32.el8.x86_64 [ 237.684] Current Operating System: Linux ca-dev55 5.3.0+ #4 SMP Wed Nov 6 19:07:28 PST 2019 x86_64 [ 237.684] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff [ 237.685] Build Date: 19 July 2019 09:31:20PM [ 237.685] Build ID: xorg-x11-server 1.20.3-5.2.el8_0 [ 237.685] Current version of pixman: 0.36.0 [ 237.685] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 237.685] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 237.685] (==) Log file: "/var/lib/gdm/.local/share/xorg/Xorg.0.log", Time: Thu Nov 7 04:45:23 2019 [ 237.686] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 237.686] (==) No Layout section. Using the first Screen section. [ 237.686] (==) No screen section available. Using defaults. [ 237.686] (**) |-->Screen "Default Screen Section" (0) [ 237.686] (**) | |-->Monitor "<default monitor>" [ 237.686] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 237.686] (==) Automatically adding devices [ 237.686] (==) Automatically enabling devices [ 237.686] (==) Automatically adding GPU devices [ 237.686] (==) Automatically binding GPU devices [ 237.686] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 237.686] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 237.686] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 237.686] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 237.686] (II) Loader magic: 0x557906a4e020 [ 237.686] (II) Module ABI versions: [ 237.686] X.Org ANSI C Emulation: 0.4 [ 237.686] X.Org Video Driver: 24.0 [ 237.686] X.Org XInput driver : 24.1 [ 237.686] X.Org Server Extension : 10.0 [ 237.687] (++) using VT number 1 [ 237.688] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [ 237.688] (II) xfree86: Adding drm device (/dev/dri/card0) [ 237.689] (II) Platform probe for /sys/devices/pci0000:00/0000:00:1c.7/0000:3d:00.0/drm/card0 [ 237.689] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [ 237.702] (--) PCI:*(61@0:0:0) 102b:0522:108e:4852 rev 5, Mem @ 0xc5000000/16777216, 0xc6810000/16384, 0xc6000000/8388608, BIOS @ 0x????????/65536 [ 237.702] (II) LoadModule: "glx" [ 237.703] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 237.709] (II) Module glx: vendor="X.Org Foundation" [ 237.709] compiled for 1.20.3, module version = 1.0.0 [ 237.709] ABI class: X.Org Server Extension, version 10.0 [ 237.709] (==) Matched modesetting as autoconfigured driver 0 [ 237.709] (==) Matched fbdev as autoconfigured driver 1 [ 237.709] (==) Matched vesa as autoconfigured driver 2 [ 237.709] (==) Assigned the driver to the xf86ConfigLayout [ 237.709] (II) LoadModule: "modesetting" [ 237.709] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 237.710] (II) Module modesetting: vendor="X.Org Foundation" [ 237.710] compiled for 1.20.3, module version = 1.20.3 [ 237.710] Module class: X.Org Video Driver [ 237.710] ABI class: X.Org Video Driver, version 24.0 [ 237.710] (II) LoadModule: "fbdev" [ 237.710] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 237.710] (II) Module fbdev: vendor="X.Org Foundation" [ 237.710] compiled for 1.20.2, module version = 0.5.0 [ 237.710] Module class: X.Org Video Driver [ 237.710] ABI class: X.Org Video Driver, version 24.0 [ 237.710] (II) LoadModule: "vesa" [ 237.710] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 237.712] (II) Module vesa: vendor="X.Org Foundation" [ 237.712] compiled for 1.20.2, module version = 2.4.0 [ 237.712] Module class: X.Org Video Driver [ 237.712] ABI class: X.Org Video Driver, version 24.0 [ 237.712] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 237.712] (II) FBDEV: driver for framebuffer: fbdev [ 237.712] (II) VESA: driver for VESA chipsets: vesa [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) [ 237.712] (II) modeset(0): using drv /dev/dri/card0 [ 237.712] (WW) Falling back to old probe method for fbdev [ 237.712] (II) Loading sub module "fbdevhw" [ 237.712] (II) LoadModule: "fbdevhw" [ 237.712] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 237.712] (II) Module fbdevhw: vendor="X.Org Foundation" [ 237.712] compiled for 1.20.3, module version = 0.0.2 [ 237.712] ABI class: X.Org Video Driver, version 24.0 [ 237.712] (EE) open /dev/fb0: Permission denied [ 237.712] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 237.712] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 237.712] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 237.712] (==) modeset(0): RGB weight 888 [ 237.712] (==) modeset(0): Default visual is TrueColor [ 237.712] (II) Loading sub module "glamoregl" [ 237.712] (II) LoadModule: "glamoregl" [ 237.712] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 237.715] (II) Module glamoregl: vendor="X.Org Foundation" [ 237.715] compiled for 1.20.3, module version = 1.0.1 [ 237.715] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.858] (II) modeset(0): Refusing to try glamor on llvmpipe [ 237.859] (EE) modeset(0): glamor initialization failed [ 237.859] (II) modeset(0): ShadowFB: preferred YES, enabled YES [ 237.859] (II) modeset(0): Double-buffered shadow updates: on [ 237.861] (II) modeset(0): Output VGA-1 has no monitor section [ 237.862] (II) modeset(0): EDID for output VGA-1 [ 237.863] (II) modeset(0): Printing probed modes for output VGA-1 [ 237.863] (II) modeset(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 237.863] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 237.863] (II) modeset(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 237.863] (II) modeset(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 237.863] (II) modeset(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 237.863] (II) modeset(0): Output VGA-1 connected [ 237.863] (II) modeset(0): Using exact sizes for initial modes [ 237.863] (II) modeset(0): Output VGA-1 using initial mode 1024x768 +0+0 [ 237.863] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 237.863] (==) modeset(0): DPI set to (96, 96) [ 237.863] (II) Loading sub module "fb" [ 237.863] (II) LoadModule: "fb" [ 237.863] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 237.863] (II) Module fb: vendor="X.Org Foundation" [ 237.863] compiled for 1.20.3, module version = 1.0.0 [ 237.863] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.863] (II) Loading sub module "shadow" [ 237.863] (II) LoadModule: "shadow" [ 237.863] (II) Loading /usr/lib64/xorg/modules/libshadow.so [ 237.863] (II) Module shadow: vendor="X.Org Foundation" [ 237.863] compiled for 1.20.3, module version = 1.1.0 [ 237.863] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.863] (II) UnloadModule: "fbdev" [ 237.863] (II) Unloading fbdev [ 237.863] (II) UnloadSubModule: "fbdevhw" [ 237.863] (II) Unloading fbdevhw [ 237.863] (II) UnloadModule: "vesa" [ 237.863] (II) Unloading vesa [ 237.863] (==) modeset(0): Backing store enabled [ 237.863] (==) modeset(0): Silken mouse enabled [ 237.864] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [ 237.864] (==) modeset(0): DPMS enabled [ 237.864] (II) Initializing extension Generic Event Extension [ 237.864] (II) Initializing extension SHAPE [ 237.864] (II) Initializing extension MIT-SHM [ 237.864] (II) Initializing extension XInputExtension [ 237.864] (II) Initializing extension XTEST [ 237.864] (II) Initializing extension BIG-REQUESTS [ 237.864] (II) Initializing extension SYNC [ 237.864] (II) Initializing extension XKEYBOARD [ 237.865] (II) Initializing extension XC-MISC [ 237.865] (II) Initializing extension XFIXES [ 237.865] (II) Initializing extension RENDER [ 237.865] (II) Initializing extension RANDR [ 237.865] (II) Initializing extension COMPOSITE [ 237.865] (II) Initializing extension DAMAGE [ 237.865] (II) Initializing extension MIT-SCREEN-SAVER [ 237.865] (II) Initializing extension DOUBLE-BUFFER [ 237.865] (II) Initializing extension RECORD [ 237.865] (II) Initializing extension DPMS [ 237.865] (II) Initializing extension Present [ 237.865] (II) Initializing extension DRI3 [ 237.865] (II) Initializing extension X-Resource [ 237.866] (II) Initializing extension XVideo [ 237.866] (II) Initializing extension XVideo-MotionCompensation [ 237.866] (II) Initializing extension SELinux [ 237.866] (II) SELinux: Disabled on system [ 237.866] (II) Initializing extension GLX [ 237.866] (II) AIGLX: Screen 0 is not DRI2 capable [ 237.869] (II) IGLX: Loaded and initialized swrast [ 237.869] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 237.869] (II) Initializing extension XFree86-VidModeExtension [ 237.869] (II) Initializing extension XFree86-DGA [ 237.869] (II) Initializing extension XFree86-DRI [ 237.869] (II) Initializing extension DRI2 [ 237.870] (II) modeset(0): Damage tracking initialized [ 237.870] (II) modeset(0): Setting screen physical size to 270 x 203 [ 237.904] (II) config/udev: Adding input device Power Button (/dev/input/event1) [ 237.904] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 237.904] (II) LoadModule: "libinput" [ 237.904] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so [ 237.908] (II) Module libinput: vendor="X.Org Foundation" [ 237.908] compiled for 1.20.2, module version = 0.28.0 [ 237.908] Module class: X.Org XInput Driver [ 237.908] ABI class: X.Org XInput driver, version 24.1 [ 237.908] (II) Using input driver 'libinput' for 'Power Button' [ 237.909] (II) systemd-logind: got fd for /dev/input/event1 13:65 fd 20 paused 0 [ 237.909] (**) Power Button: always reports core events [ 237.909] (**) Option "Device" "/dev/input/event1" [ 237.909] (**) Option "_source" "server/udev" [ 237.913] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 237.913] (II) event1 - Power Button: device is a keyboard [ 237.913] (II) event1 - Power Button: device removed [ 237.913] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1" [ 237.913] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6) [ 237.914] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 237.914] (II) event1 - Power Button: device is a keyboard [ 237.914] (II) config/udev: Adding input device Power Button (/dev/input/event0) [ 237.914] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 237.914] (II) Using input driver 'libinput' for 'Power Button' [ 237.915] (II) systemd-logind: got fd for /dev/input/event0 13:64 fd 23 paused 0 [ 237.915] (**) Power Button: always reports core events [ 237.915] (**) Option "Device" "/dev/input/event0" [ 237.915] (**) Option "_source" "server/udev" [ 237.915] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 237.915] (II) event0 - Power Button: device is a keyboard [ 237.915] (II) event0 - Power Button: device removed [ 237.915] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0" [ 237.915] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 7) [ 237.916] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 237.916] (II) event0 - Power Button: device is a keyboard [ 237.916] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event3) [ 237.916] (**) Oracle P3rKM : Applying InputClass "libinput keyboard catchall" [ 237.916] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 237.917] (II) systemd-logind: got fd for /dev/input/event3 13:67 fd 24 paused 0 [ 237.917] (**) Oracle P3rKM : always reports core events [ 237.917] (**) Option "Device" "/dev/input/event3" [ 237.917] (**) Option "_source" "server/udev" [ 237.918] (II) event3 - Oracle P3rKM : is tagged by udev as: Keyboard [ 237.918] (II) event3 - Oracle P3rKM : device is a keyboard [ 237.918] (II) event3 - Oracle P3rKM : device removed [ 237.918] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.0/0003:0430:A101.0001/input/input3/event3" [ 237.918] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: KEYBOARD, id 8) [ 237.919] (II) event3 - Oracle P3rKM : is tagged by udev as: Keyboard [ 237.919] (II) event3 - Oracle P3rKM : device is a keyboard [ 237.919] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event4) [ 237.919] (**) Oracle P3rKM : Applying InputClass "libinput pointer catchall" [ 237.919] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 237.972] (II) systemd-logind: got fd for /dev/input/event4 13:68 fd 25 paused 0 [ 237.972] (**) Oracle P3rKM : always reports core events [ 237.972] (**) Option "Device" "/dev/input/event4" [ 237.972] (**) Option "_source" "server/udev" [ 237.973] (II) event4 - Oracle P3rKM : is tagged by udev as: Mouse [ 237.973] (II) event4 - Oracle P3rKM : device is a pointer [ 237.973] (II) event4 - Oracle P3rKM : device removed [ 237.973] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.1/0003:0430:A101.0002/input/input4/event4" [ 237.973] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: MOUSE, id 9) [ 237.973] (**) Option "AccelerationScheme" "none" [ 237.973] (**) Oracle P3rKM : (accel) selected scheme none/0 [ 237.973] (**) Oracle P3rKM : (accel) acceleration factor: 2.000 [ 237.973] (**) Oracle P3rKM : (accel) acceleration threshold: 4 [ 237.974] (II) event4 - Oracle P3rKM : is tagged by udev as: Mouse [ 237.974] (II) event4 - Oracle P3rKM : device is a pointer [ 237.974] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/mouse0) [ 237.974] (II) No input driver specified, ignoring this device. [ 237.974] (II) This device may have been added with another device file. [ 237.975] (II) config/udev: Adding input device PC Speaker (/dev/input/event2) [ 237.975] (II) No input driver specified, ignoring this device. [ 237.975] (II) This device may have been added with another device file. [ 239.880] (II) modeset(0): Disabling kernel dirty updates, not required. [ 260.158] (**) Option "fd" "20" [ 260.158] (II) event1 - Power Button: device removed [ 260.158] (**) Option "fd" "23" [ 260.158] (II) event0 - Power Button: device removed [ 260.158] (**) Option "fd" "24" [ 260.158] (II) event3 - Oracle P3rKM : device removed [ 260.158] (**) Option "fd" "25" [ 260.158] (II) event4 - Oracle P3rKM : device removed [ 260.159] (II) UnloadModule: "libinput" [ 260.159] (II) systemd-logind: releasing fd for 13:68 [ 260.174] (II) UnloadModule: "libinput" [ 260.174] (II) systemd-logind: releasing fd for 13:67 [ 260.230] (II) UnloadModule: "libinput" [ 260.230] (II) systemd-logind: releasing fd for 13:64 [ 260.241] (II) UnloadModule: "libinput" [ 260.241] (II) systemd-logind: releasing fd for 13:65 [ 260.532] (II) Server terminated successfully (0). Closing log file. [-- Attachment #3: Type: text/plain, Size: 4380 bytes --] Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . # cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. > > before and after switching to graphics mode. The file lists the > allocated regions of the VRAM. > >> >> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >> >> I don’t see any specific errors in the gdm logs or message file other than this: > > You can boot with drm.debug=0xff on the kernel command line to enable > more warnings. > > > Could you please attach the output of lspci -v for the VGA adapter? > Here is the output from the current machine; The previous addresses were from another model using the same SE device: Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console lspci -s 3d:00.0 -vvv -k 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) Subsystem: Oracle/SUN Device 4852 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 NUMA node: 0 Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] Expansion ROM at 000c0000 [disabled] [size=128K] Capabilities: [dc] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- Address: 00000000 Data: 0000 Kernel driver in use: mgag200 Kernel modules: mgag200 > Best regards > Thomas > >> >> fb0: switching to mgag200drmfb from EFI VGA >> mgag200 0000:04:00.0: vgaarb: deactivate vga console >> fbcon: mgag200drmfb (fb0) is primary device >> mgag200 0000:04:00.0: fb0: mgag200drmfb frame buffer device >> [drm] Initialized mgag200 1.0.0 20110418 for 0000:04:00.0 on minor 0 >> >> The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. >> _______________________________________________ >> dri-devel mailing list >> dri-devel@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/dri-devel >> > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > [-- Attachment #4: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 13:12 ` John Donnelly @ 2019-11-07 13:42 ` Thomas Zimmermann 2019-11-07 16:13 ` John Donnelly 0 siblings, 1 reply; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-07 13:42 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, allen [-- Attachment #1.1.1: Type: text/plain, Size: 7094 bytes --] Hi John Am 07.11.19 um 14:12 schrieb John Donnelly: > Hi Thomas ; Thank you for reaching out. > > See inline: > >> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Hi John, >> >> apparently the vgaarb was not the problem. >> >> Am 07.11.19 um 03:29 schrieb John Donnelly: >>> Hi, >>> >>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>> on a number of servers using this driver. Specifically starting the GNOME desktop. >> >> When you say "text mode", do you mean VGA text mode or the graphical >> console that emulates text mode? >> > > > I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. Yes. > > >> When you enable graphics mode, does it set the correct resolution? A lot >> of work went into memory management recently. I could imagine that the >> driver sets the correct resolution, but then fails to display the >> correct framebuffer. > > There is no display at all ; so there is no resolution to mention. > > > >> >> If possible, could you try to update to the latest drm-tip and attach >> the output of >> >> /sys/kernel/debug/dri/0/vram-mm > > I don’t see that file ; Is there something else I need to do ? That file is fairly new and maybe it's not in the mainline kernel yet. See below for how to get it. > > I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; Good! Looking through that log file, the card is found at line 79 and the generic X modesetting driver initializes below. That works as expected. I notices that several operations are not permitted (lines 78 and 87). I guess you're starting X from a regular user account? IIRC special permission is required to acquire control of the display. What happens if you start X as root user? > > > > > Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . > > # cat /proc/cmdline > BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > > When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. The latest and greatest DRM code is in the drm-tip branch at git://anongit.freedesktop.org/drm/drm-tip If you build this version you should find /sys/kernel/debug/dri/0/vram-mm on the device. You have to build with debugfs enabled and maybe have to mount debugfs at /sys/kernel/debug. > > >> >> before and after switching to graphics mode. The file lists the >> allocated regions of the VRAM. >> >>> >>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>> >>> I don’t see any specific errors in the gdm logs or message file other than this: >> >> You can boot with drm.debug=0xff on the kernel command line to enable >> more warnings. >> >> >> Could you please attach the output of lspci -v for the VGA adapter? >> > > > Here is the output from the current machine; The previous addresses were from another model using the same SE device: > > > Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff > Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff > Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff > Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console > > > lspci -s 3d:00.0 -vvv -k > 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) > Subsystem: Oracle/SUN Device 4852 > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > Latency: 0, Cache Line Size: 64 bytes > Interrupt: pin A routed to IRQ 16 > NUMA node: 0 > Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] > Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] > Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] > Expansion ROM at 000c0000 [disabled] [size=128K] > Capabilities: [dc] Power Management version 2 > Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 > DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us > ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- > DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- > RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > MaxPayload 128 bytes, MaxReadReq 128 bytes > DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns > ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- > Address: 00000000 Data: 0000 > Kernel driver in use: mgag200 > Kernel modules: mgag200 Looks all normal. Best regards Thomas > > >> Best regards >> Thomas >> >>> >>> fb0: switching to mgag200drmfb from EFI VGA >>> mgag200 0000:04:00.0: vgaarb: deactivate vga console >>> fbcon: mgag200drmfb (fb0) is primary device >>> mgag200 0000:04:00.0: fb0: mgag200drmfb frame buffer device >>> [drm] Initialized mgag200 1.0.0 20110418 for 0000:04:00.0 on minor 0 >>> >>> The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. >>> _______________________________________________ >>> dri-devel mailing list >>> dri-devel@lists.freedesktop.org >>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>> >> >> -- >> Thomas Zimmermann >> Graphics Driver Developer >> SUSE Software Solutions Germany GmbH >> Maxfeldstr. 5, 90409 Nürnberg, Germany >> (HRB 36809, AG Nürnberg) >> Geschäftsführer: Felix Imendörffer >> > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 13:42 ` Thomas Zimmermann @ 2019-11-07 16:13 ` John Donnelly 2019-11-07 22:14 ` John Donnelly 0 siblings, 1 reply; 20+ messages in thread From: John Donnelly @ 2019-11-07 16:13 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen [-- Attachment #1: Type: text/plain, Size: 3942 bytes --] > On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi John > > Am 07.11.19 um 14:12 schrieb John Donnelly: >> Hi Thomas ; Thank you for reaching out. >> >> See inline: >> >>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi John, >>> >>> apparently the vgaarb was not the problem. >>> >>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>> Hi, >>>> >>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>> >>> When you say "text mode", do you mean VGA text mode or the graphical >>> console that emulates text mode? >>> >> >> >> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. > > Yes. > > >> >> >>> When you enable graphics mode, does it set the correct resolution? A lot >>> of work went into memory management recently. I could imagine that the >>> driver sets the correct resolution, but then fails to display the >>> correct framebuffer. >> >> There is no display at all ; so there is no resolution to mention. >> >> >> >>> >>> If possible, could you try to update to the latest drm-tip and attach >>> the output of >>> >>> /sys/kernel/debug/dri/0/vram-mm >> >> I don’t see that file ; Is there something else I need to do ? > > That file is fairly new and maybe it's not in the mainline kernel yet. > See below for how to get it. I built your “tip” ; Still no graphics displayed . mount -t debugfs none /sys/kernel cat /proc/cmdline BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff cat /sys/kernel/dri/0/vram-mm In VGA mode : cat /sys/kernel/dri/0/vram-mm 0x0000000000000000-0x0000000000000300: 768: used 0x0000000000000300-0x0000000000000600: 768: used 0x0000000000000600-0x00000000000007ee: 494: free 0x00000000000007ee-0x00000000000007ef: 1: used 0x00000000000007ef-0x00000000000007f0: 1: used In GRAPHICS mode ( if it matters ) cat /sys/kernel/dri/0/vram-mm 0x0000000000000000-0x0000000000000300: 768: used 0x0000000000000300-0x0000000000000600: 768: used 0x0000000000000600-0x00000000000007ee: 494: free 0x00000000000007ee-0x00000000000007ef: 1: used 0x00000000000007ef-0x00000000000007f0: 1: used total: 2032, used 1538 free 494 > > >> >> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; > > Good! Looking through that log file, the card is found at line 79 and > the generic X modesetting driver initializes below. That works as expected. > > I notices that several operations are not permitted (lines 78 and 87). I > guess you're starting X from a regular user account? IIRC special > permission is required to acquire control of the display. What happens > if you start X as root user? I am starting GNOME as root by doing “init 5” from either the console session or from ssh . The default runlevel is 3 on boot . On failing session running your 5.4.0.rc6. 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 237.712] (EE) open /dev/fb0: Permission denied Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) 87 [ 101.334] (EE) open /dev/fb0: Permission denied What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! [-- Attachment #2: Xorg.0.log.bad --] [-- Type: application/octet-stream, Size: 16385 bytes --] [ 237.684] (--) Log file renamed from "/var/lib/gdm/.local/share/xorg/Xorg.pid-2344.log" to "/var/lib/gdm/.local/share/xorg/Xorg.0.log" [ 237.684] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [ 237.684] Build Operating System: 4.18.0-32.el8.x86_64 [ 237.684] Current Operating System: Linux ca-dev55 5.3.0+ #4 SMP Wed Nov 6 19:07:28 PST 2019 x86_64 [ 237.684] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff [ 237.685] Build Date: 19 July 2019 09:31:20PM [ 237.685] Build ID: xorg-x11-server 1.20.3-5.2.el8_0 [ 237.685] Current version of pixman: 0.36.0 [ 237.685] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 237.685] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 237.685] (==) Log file: "/var/lib/gdm/.local/share/xorg/Xorg.0.log", Time: Thu Nov 7 04:45:23 2019 [ 237.686] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 237.686] (==) No Layout section. Using the first Screen section. [ 237.686] (==) No screen section available. Using defaults. [ 237.686] (**) |-->Screen "Default Screen Section" (0) [ 237.686] (**) | |-->Monitor "<default monitor>" [ 237.686] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 237.686] (==) Automatically adding devices [ 237.686] (==) Automatically enabling devices [ 237.686] (==) Automatically adding GPU devices [ 237.686] (==) Automatically binding GPU devices [ 237.686] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 237.686] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 237.686] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 237.686] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 237.686] (II) Loader magic: 0x557906a4e020 [ 237.686] (II) Module ABI versions: [ 237.686] X.Org ANSI C Emulation: 0.4 [ 237.686] X.Org Video Driver: 24.0 [ 237.686] X.Org XInput driver : 24.1 [ 237.686] X.Org Server Extension : 10.0 [ 237.687] (++) using VT number 1 [ 237.688] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [ 237.688] (II) xfree86: Adding drm device (/dev/dri/card0) [ 237.689] (II) Platform probe for /sys/devices/pci0000:00/0000:00:1c.7/0000:3d:00.0/drm/card0 [ 237.689] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [ 237.702] (--) PCI:*(61@0:0:0) 102b:0522:108e:4852 rev 5, Mem @ 0xc5000000/16777216, 0xc6810000/16384, 0xc6000000/8388608, BIOS @ 0x????????/65536 [ 237.702] (II) LoadModule: "glx" [ 237.703] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 237.709] (II) Module glx: vendor="X.Org Foundation" [ 237.709] compiled for 1.20.3, module version = 1.0.0 [ 237.709] ABI class: X.Org Server Extension, version 10.0 [ 237.709] (==) Matched modesetting as autoconfigured driver 0 [ 237.709] (==) Matched fbdev as autoconfigured driver 1 [ 237.709] (==) Matched vesa as autoconfigured driver 2 [ 237.709] (==) Assigned the driver to the xf86ConfigLayout [ 237.709] (II) LoadModule: "modesetting" [ 237.709] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 237.710] (II) Module modesetting: vendor="X.Org Foundation" [ 237.710] compiled for 1.20.3, module version = 1.20.3 [ 237.710] Module class: X.Org Video Driver [ 237.710] ABI class: X.Org Video Driver, version 24.0 [ 237.710] (II) LoadModule: "fbdev" [ 237.710] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 237.710] (II) Module fbdev: vendor="X.Org Foundation" [ 237.710] compiled for 1.20.2, module version = 0.5.0 [ 237.710] Module class: X.Org Video Driver [ 237.710] ABI class: X.Org Video Driver, version 24.0 [ 237.710] (II) LoadModule: "vesa" [ 237.710] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 237.712] (II) Module vesa: vendor="X.Org Foundation" [ 237.712] compiled for 1.20.2, module version = 2.4.0 [ 237.712] Module class: X.Org Video Driver [ 237.712] ABI class: X.Org Video Driver, version 24.0 [ 237.712] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 237.712] (II) FBDEV: driver for framebuffer: fbdev [ 237.712] (II) VESA: driver for VESA chipsets: vesa [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) [ 237.712] (II) modeset(0): using drv /dev/dri/card0 [ 237.712] (WW) Falling back to old probe method for fbdev [ 237.712] (II) Loading sub module "fbdevhw" [ 237.712] (II) LoadModule: "fbdevhw" [ 237.712] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 237.712] (II) Module fbdevhw: vendor="X.Org Foundation" [ 237.712] compiled for 1.20.3, module version = 0.0.2 [ 237.712] ABI class: X.Org Video Driver, version 24.0 [ 237.712] (EE) open /dev/fb0: Permission denied [ 237.712] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 237.712] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 237.712] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 237.712] (==) modeset(0): RGB weight 888 [ 237.712] (==) modeset(0): Default visual is TrueColor [ 237.712] (II) Loading sub module "glamoregl" [ 237.712] (II) LoadModule: "glamoregl" [ 237.712] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 237.715] (II) Module glamoregl: vendor="X.Org Foundation" [ 237.715] compiled for 1.20.3, module version = 1.0.1 [ 237.715] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.858] (II) modeset(0): Refusing to try glamor on llvmpipe [ 237.859] (EE) modeset(0): glamor initialization failed [ 237.859] (II) modeset(0): ShadowFB: preferred YES, enabled YES [ 237.859] (II) modeset(0): Double-buffered shadow updates: on [ 237.861] (II) modeset(0): Output VGA-1 has no monitor section [ 237.862] (II) modeset(0): EDID for output VGA-1 [ 237.863] (II) modeset(0): Printing probed modes for output VGA-1 [ 237.863] (II) modeset(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 237.863] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 237.863] (II) modeset(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 237.863] (II) modeset(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 237.863] (II) modeset(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 237.863] (II) modeset(0): Output VGA-1 connected [ 237.863] (II) modeset(0): Using exact sizes for initial modes [ 237.863] (II) modeset(0): Output VGA-1 using initial mode 1024x768 +0+0 [ 237.863] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 237.863] (==) modeset(0): DPI set to (96, 96) [ 237.863] (II) Loading sub module "fb" [ 237.863] (II) LoadModule: "fb" [ 237.863] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 237.863] (II) Module fb: vendor="X.Org Foundation" [ 237.863] compiled for 1.20.3, module version = 1.0.0 [ 237.863] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.863] (II) Loading sub module "shadow" [ 237.863] (II) LoadModule: "shadow" [ 237.863] (II) Loading /usr/lib64/xorg/modules/libshadow.so [ 237.863] (II) Module shadow: vendor="X.Org Foundation" [ 237.863] compiled for 1.20.3, module version = 1.1.0 [ 237.863] ABI class: X.Org ANSI C Emulation, version 0.4 [ 237.863] (II) UnloadModule: "fbdev" [ 237.863] (II) Unloading fbdev [ 237.863] (II) UnloadSubModule: "fbdevhw" [ 237.863] (II) Unloading fbdevhw [ 237.863] (II) UnloadModule: "vesa" [ 237.863] (II) Unloading vesa [ 237.863] (==) modeset(0): Backing store enabled [ 237.863] (==) modeset(0): Silken mouse enabled [ 237.864] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [ 237.864] (==) modeset(0): DPMS enabled [ 237.864] (II) Initializing extension Generic Event Extension [ 237.864] (II) Initializing extension SHAPE [ 237.864] (II) Initializing extension MIT-SHM [ 237.864] (II) Initializing extension XInputExtension [ 237.864] (II) Initializing extension XTEST [ 237.864] (II) Initializing extension BIG-REQUESTS [ 237.864] (II) Initializing extension SYNC [ 237.864] (II) Initializing extension XKEYBOARD [ 237.865] (II) Initializing extension XC-MISC [ 237.865] (II) Initializing extension XFIXES [ 237.865] (II) Initializing extension RENDER [ 237.865] (II) Initializing extension RANDR [ 237.865] (II) Initializing extension COMPOSITE [ 237.865] (II) Initializing extension DAMAGE [ 237.865] (II) Initializing extension MIT-SCREEN-SAVER [ 237.865] (II) Initializing extension DOUBLE-BUFFER [ 237.865] (II) Initializing extension RECORD [ 237.865] (II) Initializing extension DPMS [ 237.865] (II) Initializing extension Present [ 237.865] (II) Initializing extension DRI3 [ 237.865] (II) Initializing extension X-Resource [ 237.866] (II) Initializing extension XVideo [ 237.866] (II) Initializing extension XVideo-MotionCompensation [ 237.866] (II) Initializing extension SELinux [ 237.866] (II) SELinux: Disabled on system [ 237.866] (II) Initializing extension GLX [ 237.866] (II) AIGLX: Screen 0 is not DRI2 capable [ 237.869] (II) IGLX: Loaded and initialized swrast [ 237.869] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 237.869] (II) Initializing extension XFree86-VidModeExtension [ 237.869] (II) Initializing extension XFree86-DGA [ 237.869] (II) Initializing extension XFree86-DRI [ 237.869] (II) Initializing extension DRI2 [ 237.870] (II) modeset(0): Damage tracking initialized [ 237.870] (II) modeset(0): Setting screen physical size to 270 x 203 [ 237.904] (II) config/udev: Adding input device Power Button (/dev/input/event1) [ 237.904] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 237.904] (II) LoadModule: "libinput" [ 237.904] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so [ 237.908] (II) Module libinput: vendor="X.Org Foundation" [ 237.908] compiled for 1.20.2, module version = 0.28.0 [ 237.908] Module class: X.Org XInput Driver [ 237.908] ABI class: X.Org XInput driver, version 24.1 [ 237.908] (II) Using input driver 'libinput' for 'Power Button' [ 237.909] (II) systemd-logind: got fd for /dev/input/event1 13:65 fd 20 paused 0 [ 237.909] (**) Power Button: always reports core events [ 237.909] (**) Option "Device" "/dev/input/event1" [ 237.909] (**) Option "_source" "server/udev" [ 237.913] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 237.913] (II) event1 - Power Button: device is a keyboard [ 237.913] (II) event1 - Power Button: device removed [ 237.913] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1" [ 237.913] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6) [ 237.914] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 237.914] (II) event1 - Power Button: device is a keyboard [ 237.914] (II) config/udev: Adding input device Power Button (/dev/input/event0) [ 237.914] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 237.914] (II) Using input driver 'libinput' for 'Power Button' [ 237.915] (II) systemd-logind: got fd for /dev/input/event0 13:64 fd 23 paused 0 [ 237.915] (**) Power Button: always reports core events [ 237.915] (**) Option "Device" "/dev/input/event0" [ 237.915] (**) Option "_source" "server/udev" [ 237.915] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 237.915] (II) event0 - Power Button: device is a keyboard [ 237.915] (II) event0 - Power Button: device removed [ 237.915] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0" [ 237.915] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 7) [ 237.916] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 237.916] (II) event0 - Power Button: device is a keyboard [ 237.916] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event3) [ 237.916] (**) Oracle P3rKM : Applying InputClass "libinput keyboard catchall" [ 237.916] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 237.917] (II) systemd-logind: got fd for /dev/input/event3 13:67 fd 24 paused 0 [ 237.917] (**) Oracle P3rKM : always reports core events [ 237.917] (**) Option "Device" "/dev/input/event3" [ 237.917] (**) Option "_source" "server/udev" [ 237.918] (II) event3 - Oracle P3rKM : is tagged by udev as: Keyboard [ 237.918] (II) event3 - Oracle P3rKM : device is a keyboard [ 237.918] (II) event3 - Oracle P3rKM : device removed [ 237.918] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.0/0003:0430:A101.0001/input/input3/event3" [ 237.918] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: KEYBOARD, id 8) [ 237.919] (II) event3 - Oracle P3rKM : is tagged by udev as: Keyboard [ 237.919] (II) event3 - Oracle P3rKM : device is a keyboard [ 237.919] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event4) [ 237.919] (**) Oracle P3rKM : Applying InputClass "libinput pointer catchall" [ 237.919] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 237.972] (II) systemd-logind: got fd for /dev/input/event4 13:68 fd 25 paused 0 [ 237.972] (**) Oracle P3rKM : always reports core events [ 237.972] (**) Option "Device" "/dev/input/event4" [ 237.972] (**) Option "_source" "server/udev" [ 237.973] (II) event4 - Oracle P3rKM : is tagged by udev as: Mouse [ 237.973] (II) event4 - Oracle P3rKM : device is a pointer [ 237.973] (II) event4 - Oracle P3rKM : device removed [ 237.973] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.1/0003:0430:A101.0002/input/input4/event4" [ 237.973] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: MOUSE, id 9) [ 237.973] (**) Option "AccelerationScheme" "none" [ 237.973] (**) Oracle P3rKM : (accel) selected scheme none/0 [ 237.973] (**) Oracle P3rKM : (accel) acceleration factor: 2.000 [ 237.973] (**) Oracle P3rKM : (accel) acceleration threshold: 4 [ 237.974] (II) event4 - Oracle P3rKM : is tagged by udev as: Mouse [ 237.974] (II) event4 - Oracle P3rKM : device is a pointer [ 237.974] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/mouse0) [ 237.974] (II) No input driver specified, ignoring this device. [ 237.974] (II) This device may have been added with another device file. [ 237.975] (II) config/udev: Adding input device PC Speaker (/dev/input/event2) [ 237.975] (II) No input driver specified, ignoring this device. [ 237.975] (II) This device may have been added with another device file. [ 239.880] (II) modeset(0): Disabling kernel dirty updates, not required. [ 260.158] (**) Option "fd" "20" [ 260.158] (II) event1 - Power Button: device removed [ 260.158] (**) Option "fd" "23" [ 260.158] (II) event0 - Power Button: device removed [ 260.158] (**) Option "fd" "24" [ 260.158] (II) event3 - Oracle P3rKM : device removed [ 260.158] (**) Option "fd" "25" [ 260.158] (II) event4 - Oracle P3rKM : device removed [ 260.159] (II) UnloadModule: "libinput" [ 260.159] (II) systemd-logind: releasing fd for 13:68 [ 260.174] (II) UnloadModule: "libinput" [ 260.174] (II) systemd-logind: releasing fd for 13:67 [ 260.230] (II) UnloadModule: "libinput" [ 260.230] (II) systemd-logind: releasing fd for 13:64 [ 260.241] (II) UnloadModule: "libinput" [ 260.241] (II) systemd-logind: releasing fd for 13:65 [ 260.532] (II) Server terminated successfully (0). Closing log file. [-- Attachment #3: Xorg.0.log.Ok --] [-- Type: application/octet-stream, Size: 16802 bytes --] [ 101.303] (--) Log file renamed from "/var/lib/gdm/.local/share/xorg/Xorg.pid-2519.log" to "/var/lib/gdm/.local/share/xorg/Xorg.0.log" [ 101.304] X.Org X Server 1.20.3 X Protocol Version 11, Revision 0 [ 101.304] Build Operating System: 4.18.0-32.el8.x86_64 [ 101.304] Current Operating System: Linux ca-dev55 4.18.0-80.11.2.el8_0.x86_64 #1 SMP Fri Sep 20 22:48:55 GMT 2019 x86_64 [ 101.304] Kernel command line: BOOT_IMAGE=(hd0,msdos1)/vmlinuz-4.18.0-80.11.2.el8_0.x86_64 root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff [ 101.304] Build Date: 19 July 2019 09:31:20PM [ 101.304] Build ID: xorg-x11-server 1.20.3-5.2.el8_0 [ 101.304] Current version of pixman: 0.36.0 [ 101.304] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 101.304] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 101.304] (==) Log file: "/var/lib/gdm/.local/share/xorg/Xorg.0.log", Time: Thu Nov 7 07:59:45 2019 [ 101.305] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 101.305] (==) No Layout section. Using the first Screen section. [ 101.305] (==) No screen section available. Using defaults. [ 101.305] (**) |-->Screen "Default Screen Section" (0) [ 101.305] (**) | |-->Monitor "<default monitor>" [ 101.305] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 101.305] (==) Automatically adding devices [ 101.305] (==) Automatically enabling devices [ 101.305] (==) Automatically adding GPU devices [ 101.305] (==) Automatically binding GPU devices [ 101.305] (==) Max clients allowed: 256, resource mask: 0x1fffff [ 101.305] (==) FontPath set to: catalogue:/etc/X11/fontpath.d, built-ins [ 101.305] (==) ModulePath set to "/usr/lib64/xorg/modules" [ 101.305] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 101.305] (II) Loader magic: 0x55716e249020 [ 101.305] (II) Module ABI versions: [ 101.305] X.Org ANSI C Emulation: 0.4 [ 101.305] X.Org Video Driver: 24.0 [ 101.305] X.Org XInput driver : 24.1 [ 101.305] X.Org Server Extension : 10.0 [ 101.306] (++) using VT number 1 [ 101.307] (II) systemd-logind: took control of session /org/freedesktop/login1/session/c1 [ 101.308] (II) xfree86: Adding drm device (/dev/dri/card0) [ 101.308] (II) Platform probe for /sys/devices/pci0000:00/0000:00:1c.7/0000:3d:00.0/drm/card0 [ 101.308] (II) systemd-logind: got fd for /dev/dri/card0 226:0 fd 12 paused 0 [ 101.324] (--) PCI:*(61@0:0:0) 102b:0522:108e:4852 rev 5, Mem @ 0xc5000000/16777216, 0xc6810000/16384, 0xc6000000/8388608, BIOS @ 0x????????/65536 [ 101.324] (II) LoadModule: "glx" [ 101.325] (II) Loading /usr/lib64/xorg/modules/extensions/libglx.so [ 101.331] (II) Module glx: vendor="X.Org Foundation" [ 101.331] compiled for 1.20.3, module version = 1.0.0 [ 101.331] ABI class: X.Org Server Extension, version 10.0 [ 101.331] (==) Matched modesetting as autoconfigured driver 0 [ 101.331] (==) Matched fbdev as autoconfigured driver 1 [ 101.331] (==) Matched vesa as autoconfigured driver 2 [ 101.331] (==) Assigned the driver to the xf86ConfigLayout [ 101.331] (II) LoadModule: "modesetting" [ 101.331] (II) Loading /usr/lib64/xorg/modules/drivers/modesetting_drv.so [ 101.332] (II) Module modesetting: vendor="X.Org Foundation" [ 101.332] compiled for 1.20.3, module version = 1.20.3 [ 101.332] Module class: X.Org Video Driver [ 101.332] ABI class: X.Org Video Driver, version 24.0 [ 101.332] (II) LoadModule: "fbdev" [ 101.332] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so [ 101.332] (II) Module fbdev: vendor="X.Org Foundation" [ 101.332] compiled for 1.20.2, module version = 0.5.0 [ 101.332] Module class: X.Org Video Driver [ 101.332] ABI class: X.Org Video Driver, version 24.0 [ 101.332] (II) LoadModule: "vesa" [ 101.332] (II) Loading /usr/lib64/xorg/modules/drivers/vesa_drv.so [ 101.334] (II) Module vesa: vendor="X.Org Foundation" [ 101.334] compiled for 1.20.2, module version = 2.4.0 [ 101.334] Module class: X.Org Video Driver [ 101.334] ABI class: X.Org Video Driver, version 24.0 [ 101.334] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 101.334] (II) FBDEV: driver for framebuffer: fbdev [ 101.334] (II) VESA: driver for VESA chipsets: vesa [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) [ 101.334] (II) modeset(0): using drv /dev/dri/card0 [ 101.334] (WW) Falling back to old probe method for fbdev [ 101.334] (II) Loading sub module "fbdevhw" [ 101.334] (II) LoadModule: "fbdevhw" [ 101.334] (II) Loading /usr/lib64/xorg/modules/libfbdevhw.so [ 101.334] (II) Module fbdevhw: vendor="X.Org Foundation" [ 101.334] compiled for 1.20.3, module version = 0.0.2 [ 101.334] ABI class: X.Org Video Driver, version 24.0 [ 101.334] (EE) open /dev/fb0: Permission denied [ 101.334] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 101.334] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 101.334] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 101.334] (==) modeset(0): RGB weight 888 [ 101.334] (==) modeset(0): Default visual is TrueColor [ 101.334] (II) Loading sub module "glamoregl" [ 101.334] (II) LoadModule: "glamoregl" [ 101.334] (II) Loading /usr/lib64/xorg/modules/libglamoregl.so [ 101.337] (II) Module glamoregl: vendor="X.Org Foundation" [ 101.337] compiled for 1.20.3, module version = 1.0.1 [ 101.337] ABI class: X.Org ANSI C Emulation, version 0.4 [ 101.475] (II) modeset(0): Refusing to try glamor on llvmpipe [ 101.476] (EE) modeset(0): glamor initialization failed [ 101.476] (II) modeset(0): ShadowFB: preferred YES, enabled YES [ 101.476] (II) modeset(0): Double-buffered shadow updates: on [ 101.477] (II) modeset(0): Output VGA-1 has no monitor section [ 101.479] (II) modeset(0): EDID for output VGA-1 [ 101.479] (II) modeset(0): Printing probed modes for output VGA-1 [ 101.479] (II) modeset(0): Modeline "1024x768"x60.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) [ 101.479] (II) modeset(0): Modeline "800x600"x60.3 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (37.9 kHz e) [ 101.479] (II) modeset(0): Modeline "800x600"x56.2 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (35.2 kHz e) [ 101.479] (II) modeset(0): Modeline "848x480"x60.0 33.75 848 864 976 1088 480 486 494 517 +hsync +vsync (31.0 kHz e) [ 101.479] (II) modeset(0): Modeline "640x480"x59.9 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (31.5 kHz e) [ 101.479] (II) modeset(0): Output VGA-1 connected [ 101.479] (II) modeset(0): Using exact sizes for initial modes [ 101.479] (II) modeset(0): Output VGA-1 using initial mode 1024x768 +0+0 [ 101.479] (==) modeset(0): Using gamma correction (1.0, 1.0, 1.0) [ 101.479] (==) modeset(0): DPI set to (96, 96) [ 101.479] (II) Loading sub module "fb" [ 101.479] (II) LoadModule: "fb" [ 101.479] (II) Loading /usr/lib64/xorg/modules/libfb.so [ 101.479] (II) Module fb: vendor="X.Org Foundation" [ 101.479] compiled for 1.20.3, module version = 1.0.0 [ 101.480] ABI class: X.Org ANSI C Emulation, version 0.4 [ 101.480] (II) Loading sub module "shadow" [ 101.480] (II) LoadModule: "shadow" [ 101.480] (II) Loading /usr/lib64/xorg/modules/libshadow.so [ 101.480] (II) Module shadow: vendor="X.Org Foundation" [ 101.480] compiled for 1.20.3, module version = 1.1.0 [ 101.480] ABI class: X.Org ANSI C Emulation, version 0.4 [ 101.480] (II) UnloadModule: "fbdev" [ 101.480] (II) Unloading fbdev [ 101.480] (II) UnloadSubModule: "fbdevhw" [ 101.480] (II) Unloading fbdevhw [ 101.480] (II) UnloadModule: "vesa" [ 101.480] (II) Unloading vesa [ 101.480] (==) modeset(0): Backing store enabled [ 101.480] (==) modeset(0): Silken mouse enabled [ 101.480] (II) modeset(0): Initializing kms color map for depth 24, 8 bpc. [ 101.480] (==) modeset(0): DPMS enabled [ 101.480] (II) Initializing extension Generic Event Extension [ 101.480] (II) Initializing extension SHAPE [ 101.480] (II) Initializing extension MIT-SHM [ 101.480] (II) Initializing extension XInputExtension [ 101.481] (II) Initializing extension XTEST [ 101.481] (II) Initializing extension BIG-REQUESTS [ 101.481] (II) Initializing extension SYNC [ 101.481] (II) Initializing extension XKEYBOARD [ 101.481] (II) Initializing extension XC-MISC [ 101.481] (II) Initializing extension XFIXES [ 101.481] (II) Initializing extension RENDER [ 101.481] (II) Initializing extension RANDR [ 101.481] (II) Initializing extension COMPOSITE [ 101.481] (II) Initializing extension DAMAGE [ 101.481] (II) Initializing extension MIT-SCREEN-SAVER [ 101.482] (II) Initializing extension DOUBLE-BUFFER [ 101.482] (II) Initializing extension RECORD [ 101.482] (II) Initializing extension DPMS [ 101.482] (II) Initializing extension Present [ 101.482] (II) Initializing extension DRI3 [ 101.482] (II) Initializing extension X-Resource [ 101.482] (II) Initializing extension XVideo [ 101.482] (II) Initializing extension XVideo-MotionCompensation [ 101.482] (II) Initializing extension SELinux [ 101.482] (II) SELinux: Disabled on system [ 101.482] (II) Initializing extension GLX [ 101.482] (II) AIGLX: Screen 0 is not DRI2 capable [ 101.485] (II) IGLX: Loaded and initialized swrast [ 101.485] (II) GLX: Initialized DRISWRAST GL provider for screen 0 [ 101.485] (II) Initializing extension XFree86-VidModeExtension [ 101.485] (II) Initializing extension XFree86-DGA [ 101.485] (II) Initializing extension XFree86-DRI [ 101.485] (II) Initializing extension DRI2 [ 101.486] (II) modeset(0): Damage tracking initialized [ 101.486] (II) modeset(0): Setting screen physical size to 270 x 203 [ 101.522] (II) config/udev: Adding input device Power Button (/dev/input/event1) [ 101.522] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 101.522] (II) LoadModule: "libinput" [ 101.522] (II) Loading /usr/lib64/xorg/modules/input/libinput_drv.so [ 101.527] (II) Module libinput: vendor="X.Org Foundation" [ 101.527] compiled for 1.20.2, module version = 0.28.0 [ 101.527] Module class: X.Org XInput Driver [ 101.527] ABI class: X.Org XInput driver, version 24.1 [ 101.527] (II) Using input driver 'libinput' for 'Power Button' [ 101.527] (II) systemd-logind: got fd for /dev/input/event1 13:65 fd 20 paused 0 [ 101.527] (**) Power Button: always reports core events [ 101.527] (**) Option "Device" "/dev/input/event1" [ 101.527] (**) Option "_source" "server/udev" [ 101.531] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 101.531] (II) event1 - Power Button: device is a keyboard [ 101.531] (II) event1 - Power Button: device removed [ 101.531] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXPWRBN:00/input/input1/event1" [ 101.531] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 6) [ 101.532] (II) event1 - Power Button: is tagged by udev as: Keyboard [ 101.532] (II) event1 - Power Button: device is a keyboard [ 101.532] (II) config/udev: Adding input device Power Button (/dev/input/event0) [ 101.532] (**) Power Button: Applying InputClass "libinput keyboard catchall" [ 101.532] (II) Using input driver 'libinput' for 'Power Button' [ 101.533] (II) systemd-logind: got fd for /dev/input/event0 13:64 fd 23 paused 0 [ 101.533] (**) Power Button: always reports core events [ 101.533] (**) Option "Device" "/dev/input/event0" [ 101.533] (**) Option "_source" "server/udev" [ 101.533] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 101.533] (II) event0 - Power Button: device is a keyboard [ 101.534] (II) event0 - Power Button: device removed [ 101.534] (**) Option "config_info" "udev:/sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0C:00/input/input0/event0" [ 101.534] (II) XINPUT: Adding extended input device "Power Button" (type: KEYBOARD, id 7) [ 101.534] (II) event0 - Power Button: is tagged by udev as: Keyboard [ 101.534] (II) event0 - Power Button: device is a keyboard [ 101.535] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event2) [ 101.535] (**) Oracle P3rKM : Applying InputClass "libinput keyboard catchall" [ 101.535] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 101.535] (II) systemd-logind: got fd for /dev/input/event2 13:66 fd 24 paused 0 [ 101.535] (**) Oracle P3rKM : always reports core events [ 101.535] (**) Option "Device" "/dev/input/event2" [ 101.535] (**) Option "_source" "server/udev" [ 101.536] (II) event2 - Oracle P3rKM : is tagged by udev as: Keyboard [ 101.536] (II) event2 - Oracle P3rKM : device is a keyboard [ 101.537] (II) event2 - Oracle P3rKM : device removed [ 101.537] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.0/0003:0430:A101.0001/input/input2/event2" [ 101.537] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: KEYBOARD, id 8) [ 101.537] (II) event2 - Oracle P3rKM : is tagged by udev as: Keyboard [ 101.537] (II) event2 - Oracle P3rKM : device is a keyboard [ 101.538] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/event3) [ 101.538] (**) Oracle P3rKM : Applying InputClass "libinput pointer catchall" [ 101.538] (II) Using input driver 'libinput' for 'Oracle P3rKM ' [ 101.591] (II) systemd-logind: got fd for /dev/input/event3 13:67 fd 25 paused 0 [ 101.591] (**) Oracle P3rKM : always reports core events [ 101.591] (**) Option "Device" "/dev/input/event3" [ 101.591] (**) Option "_source" "server/udev" [ 101.592] (II) event3 - Oracle P3rKM : is tagged by udev as: Mouse [ 101.592] (II) event3 - Oracle P3rKM : device is a pointer [ 101.592] (II) event3 - Oracle P3rKM : device removed [ 101.592] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.7/2-1.7:1.1/0003:0430:A101.0002/input/input3/event3" [ 101.592] (II) XINPUT: Adding extended input device "Oracle P3rKM " (type: MOUSE, id 9) [ 101.592] (**) Option "AccelerationScheme" "none" [ 101.592] (**) Oracle P3rKM : (accel) selected scheme none/0 [ 101.592] (**) Oracle P3rKM : (accel) acceleration factor: 2.000 [ 101.592] (**) Oracle P3rKM : (accel) acceleration threshold: 4 [ 101.593] (II) event3 - Oracle P3rKM : is tagged by udev as: Mouse [ 101.593] (II) event3 - Oracle P3rKM : device is a pointer [ 101.593] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/js0) [ 101.593] (II) No input driver specified, ignoring this device. [ 101.593] (II) This device may have been added with another device file. [ 101.594] (II) config/udev: Adding input device Oracle P3rKM (/dev/input/mouse0) [ 101.594] (II) No input driver specified, ignoring this device. [ 101.594] (II) This device may have been added with another device file. [ 101.594] (II) config/udev: Adding input device PC Speaker (/dev/input/event4) [ 101.594] (II) No input driver specified, ignoring this device. [ 101.594] (II) This device may have been added with another device file. [ 102.726] (II) modeset(0): Disabling kernel dirty updates, not required. [ 159.503] (**) Option "fd" "20" [ 159.503] (II) event1 - Power Button: device removed [ 159.503] (**) Option "fd" "23" [ 159.503] (II) event0 - Power Button: device removed [ 159.503] (**) Option "fd" "24" [ 159.503] (II) event2 - Oracle P3rKM : device removed [ 159.503] (**) Option "fd" "25" [ 159.503] (II) event3 - Oracle P3rKM : device removed [ 159.504] (II) UnloadModule: "libinput" [ 159.504] (II) systemd-logind: releasing fd for 13:67 [ 159.536] (II) UnloadModule: "libinput" [ 159.536] (II) systemd-logind: releasing fd for 13:66 [ 159.548] (II) UnloadModule: "libinput" [ 159.548] (II) systemd-logind: releasing fd for 13:64 [ 159.556] (II) UnloadModule: "libinput" [ 159.556] (II) systemd-logind: releasing fd for 13:65 [ 160.252] (WW) xf86CloseConsole: VT_GETMODE failed: Input/output error [ 160.252] (WW) xf86CloseConsole: VT_ACTIVATE failed: Input/output error [ 160.275] (II) Server terminated successfully (0). Closing log file. [-- Attachment #4: Type: text/plain, Size: 5438 bytes --] > > >> >> >> >> >> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >> >> # cat /proc/cmdline >> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >> >> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. > > The latest and greatest DRM code is in the drm-tip branch at > > git://anongit.freedesktop.org/drm/drm-tip > > If you build this version you should find > > /sys/kernel/debug/dri/0/vram-mm > > on the device. You have to build with debugfs enabled and > maybe have to mount debugfs at /sys/kernel/debug. > > >> >> >>> >>> before and after switching to graphics mode. The file lists the >>> allocated regions of the VRAM. >>> >>>> >>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>> >>>> I don’t see any specific errors in the gdm logs or message file other than this: >>> >>> You can boot with drm.debug=0xff on the kernel command line to enable >>> more warnings. >>> >>> >>> Could you please attach the output of lspci -v for the VGA adapter? >>> >> >> >> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >> >> >> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >> >> >> lspci -s 3d:00.0 -vvv -k >> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >> Subsystem: Oracle/SUN Device 4852 >> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >> Latency: 0, Cache Line Size: 64 bytes >> Interrupt: pin A routed to IRQ 16 >> NUMA node: 0 >> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >> Expansion ROM at 000c0000 [disabled] [size=128K] >> Capabilities: [dc] Power Management version 2 >> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >> MaxPayload 128 bytes, MaxReadReq 128 bytes >> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >> Address: 00000000 Data: 0000 >> Kernel driver in use: mgag200 >> Kernel modules: mgag200 > > Looks all normal. > > Best regards > Thomas > >> >> >>> Best regards >>> Thomas >>> >>>> >>>> fb0: switching to mgag200drmfb from EFI VGA >>>> mgag200 0000:04:00.0: vgaarb: deactivate vga console >>>> fbcon: mgag200drmfb (fb0) is primary device >>>> mgag200 0000:04:00.0: fb0: mgag200drmfb frame buffer device >>>> [drm] Initialized mgag200 1.0.0 20110418 for 0000:04:00.0 on minor 0 >>>> >>>> The systems worked fine with 4.18 kernels and a recent Linux 5.2.18 ; The symptom first appears in 5.3.6. and onward. >>>> _______________________________________________ >>>> dri-devel mailing list >>>> dri-devel@lists.freedesktop.org >>>> https://lists.freedesktop.org/mailman/listinfo/dri-devel >>>> >>> >>> -- >>> Thomas Zimmermann >>> Graphics Driver Developer >>> SUSE Software Solutions Germany GmbH >>> Maxfeldstr. 5, 90409 Nürnberg, Germany >>> (HRB 36809, AG Nürnberg) >>> Geschäftsführer: Felix Imendörffer >>> >> > > -- > Thomas Zimmermann > Graphics Driver Developer > SUSE Software Solutions Germany GmbH > Maxfeldstr. 5, 90409 Nürnberg, Germany > (HRB 36809, AG Nürnberg) > Geschäftsführer: Felix Imendörffer > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel [-- Attachment #5: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 16:13 ` John Donnelly @ 2019-11-07 22:14 ` John Donnelly 2019-11-08 7:46 ` Thomas Zimmermann 0 siblings, 1 reply; 20+ messages in thread From: John Donnelly @ 2019-11-07 22:14 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen > On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: > > > >> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Hi John >> >> Am 07.11.19 um 14:12 schrieb John Donnelly: >>> Hi Thomas ; Thank you for reaching out. >>> >>> See inline: >>> >>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> >>>> Hi John, >>>> >>>> apparently the vgaarb was not the problem. >>>> >>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>> Hi, >>>>> >>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>> >>>> When you say "text mode", do you mean VGA text mode or the graphical >>>> console that emulates text mode? >>>> >>> >>> >>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >> >> Yes. >> >> >>> >>> >>>> When you enable graphics mode, does it set the correct resolution? A lot >>>> of work went into memory management recently. I could imagine that the >>>> driver sets the correct resolution, but then fails to display the >>>> correct framebuffer. >>> >>> There is no display at all ; so there is no resolution to mention. >>> >>> >>> >>>> >>>> If possible, could you try to update to the latest drm-tip and attach >>>> the output of >>>> >>>> /sys/kernel/debug/dri/0/vram-mm >>> >>> I don’t see that file ; Is there something else I need to do ? >> >> That file is fairly new and maybe it's not in the mainline kernel yet. >> See below for how to get it. > > I built your “tip” ; Still no graphics displayed . > > > mount -t debugfs none /sys/kernel > > cat /proc/cmdline > BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > > > cat /sys/kernel/dri/0/vram-mm > > In VGA mode : > > > cat /sys/kernel/dri/0/vram-mm > 0x0000000000000000-0x0000000000000300: 768: used > 0x0000000000000300-0x0000000000000600: 768: used > 0x0000000000000600-0x00000000000007ee: 494: free > 0x00000000000007ee-0x00000000000007ef: 1: used > 0x00000000000007ef-0x00000000000007f0: 1: used > > > In GRAPHICS mode ( if it matters ) > > > cat /sys/kernel/dri/0/vram-mm > 0x0000000000000000-0x0000000000000300: 768: used > 0x0000000000000300-0x0000000000000600: 768: used > 0x0000000000000600-0x00000000000007ee: 494: free > 0x00000000000007ee-0x00000000000007ef: 1: used > 0x00000000000007ef-0x00000000000007f0: 1: used > total: 2032, used 1538 free 494 > > > > >> >> >>> >>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >> >> Good! Looking through that log file, the card is found at line 79 and >> the generic X modesetting driver initializes below. That works as expected. >> >> I notices that several operations are not permitted (lines 78 and 87). I >> guess you're starting X from a regular user account? IIRC special >> permission is required to acquire control of the display. What happens >> if you start X as root user? > > > I am starting GNOME as root by doing “init 5” from either the console session or from ssh . > > The default runlevel is 3 on boot . > > On failing session running your 5.4.0.rc6. > > 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > > 87 [ 237.712] (EE) open /dev/fb0: Permission denied > > Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log > > 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > > 87 [ 101.334] (EE) open /dev/fb0: Permission denied > > > What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! > > > > > <Xorg.0.log.bad><Xorg.0.log.Ok> > > > > > >> >> >>> >>> >>> >>> >>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>> >>> # cat /proc/cmdline >>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>> >>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >> >> The latest and greatest DRM code is in the drm-tip branch at >> >> git://anongit.freedesktop.org/drm/drm-tip >> >> If you build this version you should find >> >> /sys/kernel/debug/dri/0/vram-mm >> >> on the device. You have to build with debugfs enabled and >> maybe have to mount debugfs at /sys/kernel/debug. >> >> >>> >>> >>>> >>>> before and after switching to graphics mode. The file lists the >>>> allocated regions of the VRAM. >>>> >>>>> >>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>> >>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>> >>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>> more warnings. >>>> >>>> >>>> Could you please attach the output of lspci -v for the VGA adapter? >>>> >>> >>> >>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>> >>> >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>> >>> >>> lspci -s 3d:00.0 -vvv -k >>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>> Subsystem: Oracle/SUN Device 4852 >>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>> Latency: 0, Cache Line Size: 64 bytes >>> Interrupt: pin A routed to IRQ 16 >>> NUMA node: 0 >>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>> Expansion ROM at 000c0000 [disabled] [size=128K] >>> Capabilities: [dc] Power Management version 2 >>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>> Address: 00000000 Data: 0000 >>> Kernel driver in use: mgag200 >>> Kernel modules: mgag200 >> >> Looks all normal. >> >> Best regards >> Thomas >> ============== Snip =========== Hi Thomas , I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 I started to bisect this range on by date, by day , based on the changes done in : drivers/gpu/drm/ fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. JD. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-07 22:14 ` John Donnelly @ 2019-11-08 7:46 ` Thomas Zimmermann [not found] ` <81D853E0-34F0-4894-B692-7E560AC2D9A1@oracle.com> 0 siblings, 1 reply; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-08 7:46 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, allen [-- Attachment #1.1.1: Type: text/plain, Size: 10147 bytes --] Hi John Am 07.11.19 um 23:14 schrieb John Donnelly: > > >> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >> >> >> >>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi John >>> >>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>> Hi Thomas ; Thank you for reaching out. >>>> >>>> See inline: >>>> >>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> >>>>> Hi John, >>>>> >>>>> apparently the vgaarb was not the problem. >>>>> >>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>> Hi, >>>>>> >>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>> >>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>> console that emulates text mode? >>>>> >>>> >>>> >>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>> >>> Yes. >>> >>> >>>> >>>> >>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>> of work went into memory management recently. I could imagine that the >>>>> driver sets the correct resolution, but then fails to display the >>>>> correct framebuffer. >>>> >>>> There is no display at all ; so there is no resolution to mention. >>>> >>>> >>>> >>>>> >>>>> If possible, could you try to update to the latest drm-tip and attach >>>>> the output of >>>>> >>>>> /sys/kernel/debug/dri/0/vram-mm >>>> >>>> I don’t see that file ; Is there something else I need to do ? >>> >>> That file is fairly new and maybe it's not in the mainline kernel yet. >>> See below for how to get it. >> >> I built your “tip” ; Still no graphics displayed . >> >> >> mount -t debugfs none /sys/kernel >> >> cat /proc/cmdline >> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >> >> >> cat /sys/kernel/dri/0/vram-mm >> >> In VGA mode : >> >> >> cat /sys/kernel/dri/0/vram-mm >> 0x0000000000000000-0x0000000000000300: 768: used >> 0x0000000000000300-0x0000000000000600: 768: used >> 0x0000000000000600-0x00000000000007ee: 494: free >> 0x00000000000007ee-0x00000000000007ef: 1: used >> 0x00000000000007ef-0x00000000000007f0: 1: used >> >> >> In GRAPHICS mode ( if it matters ) >> >> >> cat /sys/kernel/dri/0/vram-mm >> 0x0000000000000000-0x0000000000000300: 768: used >> 0x0000000000000300-0x0000000000000600: 768: used >> 0x0000000000000600-0x00000000000007ee: 494: free >> 0x00000000000007ee-0x00000000000007ef: 1: used >> 0x00000000000007ef-0x00000000000007f0: 1: used >> total: 2032, used 1538 free 494 >> This is interesting. In the graphics mode, you see two buffers of 768 pages each. That's the main framebuffers as used by X (it's double buffered). Then there's a free area and finally two pages for cursor images (also double buffered). That looks as expected. The thing is that in text mode, the areas are allocated. But the driver shouldn't be active, so the file shouldn't exist or only show a single free area. >> >> >> >>> >>> >>>> >>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>> >>> Good! Looking through that log file, the card is found at line 79 and >>> the generic X modesetting driver initializes below. That works as expected. >>> >>> I notices that several operations are not permitted (lines 78 and 87). I >>> guess you're starting X from a regular user account? IIRC special >>> permission is required to acquire control of the display. What happens >>> if you start X as root user? >> >> >> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >> >> The default runlevel is 3 on boot . >> >> On failing session running your 5.4.0.rc6. >> >> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >> >> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >> >> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >> >> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >> >> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >> >> >> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >> >> >> >> >> <Xorg.0.log.bad><Xorg.0.log.Ok> >> >> >> >> >> >>> >>> >>>> >>>> >>>> >>>> >>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>> >>>> # cat /proc/cmdline >>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>> >>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>> >>> The latest and greatest DRM code is in the drm-tip branch at >>> >>> git://anongit.freedesktop.org/drm/drm-tip >>> >>> If you build this version you should find >>> >>> /sys/kernel/debug/dri/0/vram-mm >>> >>> on the device. You have to build with debugfs enabled and >>> maybe have to mount debugfs at /sys/kernel/debug. >>> >>> >>>> >>>> >>>>> >>>>> before and after switching to graphics mode. The file lists the >>>>> allocated regions of the VRAM. >>>>> >>>>>> >>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>> >>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>> >>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>> more warnings. >>>>> >>>>> >>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>> >>>> >>>> >>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>> >>>> >>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>> >>>> >>>> lspci -s 3d:00.0 -vvv -k >>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>> Subsystem: Oracle/SUN Device 4852 >>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>> Latency: 0, Cache Line Size: 64 bytes >>>> Interrupt: pin A routed to IRQ 16 >>>> NUMA node: 0 >>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>> Capabilities: [dc] Power Management version 2 >>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>> Address: 00000000 Data: 0000 >>>> Kernel driver in use: mgag200 >>>> Kernel modules: mgag200 >>> >>> Looks all normal. >>> >>> Best regards >>> Thomas >>> > > ============== Snip =========== > > > Hi Thomas > , > I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: > > > between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 > > > I started to bisect this range on by date, by day , based on the changes done in : > > drivers/gpu/drm/ > > fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works > > Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. Great, thanks for bisecting. Could you attach your kernel config file? I'd like to compare with my config and try to reproduce the issue. Best regards Thomas > > > > JD. > > > > > > > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
[parent not found: <81D853E0-34F0-4894-B692-7E560AC2D9A1@oracle.com>]
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics [not found] ` <81D853E0-34F0-4894-B692-7E560AC2D9A1@oracle.com> @ 2019-11-08 15:06 ` Thomas Zimmermann 2019-11-08 18:07 ` John Donnelly 0 siblings, 1 reply; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-08 15:06 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, allen [-- Attachment #1.1.1: Type: text/plain, Size: 11628 bytes --] Hi Am 08.11.19 um 13:55 schrieb John Donnelly: > > >> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Hi John >> >> Am 07.11.19 um 23:14 schrieb John Donnelly: >>> >>> >>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >>>> >>>> >>>> >>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> >>>>> Hi John >>>>> >>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>> Hi Thomas ; Thank you for reaching out. >>>>>> >>>>>> See inline: >>>>>> >>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>> >>>>>>> Hi John, >>>>>>> >>>>>>> apparently the vgaarb was not the problem. >>>>>>> >>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>>>> >>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>> console that emulates text mode? >>>>>>> >>>>>> >>>>>> >>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>>>> >>>>> Yes. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>>>> of work went into memory management recently. I could imagine that the >>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>> correct framebuffer. >>>>>> >>>>>> There is no display at all ; so there is no resolution to mention. >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>> the output of >>>>>>> >>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>> >>>>>> I don’t see that file ; Is there something else I need to do ? >>>>> >>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>> See below for how to get it. >>>> >>>> I built your “tip” ; Still no graphics displayed . >>>> >>>> >>>> mount -t debugfs none /sys/kernel >>>> >>>> cat /proc/cmdline >>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>> >>>> >>>> cat /sys/kernel/dri/0/vram-mm >>>> >>>> In VGA mode : >>>> >>>> >>>> cat /sys/kernel/dri/0/vram-mm >>>> 0x0000000000000000-0x0000000000000300: 768: used >>>> 0x0000000000000300-0x0000000000000600: 768: used >>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>> >>>> >>>> In GRAPHICS mode ( if it matters ) >>>> >>>> >>>> cat /sys/kernel/dri/0/vram-mm >>>> 0x0000000000000000-0x0000000000000300: 768: used >>>> 0x0000000000000300-0x0000000000000600: 768: used >>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>> total: 2032, used 1538 free 494 >>>> >> >> This is interesting. In the graphics mode, you see two buffers of 768 >> pages each. That's the main framebuffers as used by X (it's double >> buffered). Then there's a free area and finally two pages for cursor >> images (also double buffered). That looks as expected. >> >> The thing is that in text mode, the areas are allocated. But the driver >> shouldn't be active, so the file shouldn't exist or only show a single >> free area. >> > > If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . > > >> >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>>>> >>>>> Good! Looking through that log file, the card is found at line 79 and >>>>> the generic X modesetting driver initializes below. That works as expected. >>>>> >>>>> I notices that several operations are not permitted (lines 78 and 87). I >>>>> guess you're starting X from a regular user account? IIRC special >>>>> permission is required to acquire control of the display. What happens >>>>> if you start X as root user? >>>> >>>> >>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >>>> >>>> The default runlevel is 3 on boot . >>>> >>>> On failing session running your 5.4.0.rc6. >>>> >>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>> >>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>> >>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>> >>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>> >>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>> >>>> >>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >>>> >>>> >>>> >>>> >>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>>>> >>>>>> # cat /proc/cmdline >>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>> >>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>>>> >>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>> >>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>> >>>>> If you build this version you should find >>>>> >>>>> /sys/kernel/debug/dri/0/vram-mm >>>>> >>>>> on the device. You have to build with debugfs enabled and >>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> before and after switching to graphics mode. The file lists the >>>>>>> allocated regions of the VRAM. >>>>>>> >>>>>>>> >>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>>>> >>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>>>> >>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>>>> more warnings. >>>>>>> >>>>>>> >>>>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>>>> >>>>>> >>>>>> >>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>>>> >>>>>> >>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>>>> >>>>>> >>>>>> lspci -s 3d:00.0 -vvv -k >>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>> Interrupt: pin A routed to IRQ 16 >>>>>> NUMA node: 0 >>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>> Capabilities: [dc] Power Management version 2 >>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>> Address: 00000000 Data: 0000 >>>>>> Kernel driver in use: mgag200 >>>>>> Kernel modules: mgag200 >>>>> >>>>> Looks all normal. >>>>> >>>>> Best regards >>>>> Thomas >>>>> >>> >>> ============== Snip =========== >>> >>> >>> Hi Thomas >>> , >>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: >>> >>> >>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>> >>> >>> I started to bisect this range on by date, by day , based on the changes done in : >>> >>> drivers/gpu/drm/ >>> >>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>> >>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. >> >> Great, thanks for bisecting. >> >> Could you attach your kernel config file? I'd like to compare with my >> config and try to reproduce the issue. >> >> Best regards >> Thomas > > Hi. > > Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : > > config.5.2.21 - work with that flavor > config.5.3. fails with 5.3 and later. > > Do you have access to mgag200 style adapter ? I do. I think I've been able to reproduce the issue. Buffers seem to remain in video ram after they have been pinned there. I'll investigate next week. I hope your bisecting session can point to the cause. Best regards Thomas > > > > > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-08 15:06 ` Thomas Zimmermann @ 2019-11-08 18:07 ` John Donnelly 2019-11-08 19:10 ` Daniel Vetter 2019-11-11 15:57 ` Thomas Zimmermann 0 siblings, 2 replies; 20+ messages in thread From: John Donnelly @ 2019-11-08 18:07 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen > On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi > > Am 08.11.19 um 13:55 schrieb John Donnelly: >> >> >>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi John >>> >>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>> >>>> >>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >>>>> >>>>> >>>>> >>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>> >>>>>> Hi John >>>>>> >>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>> >>>>>>> See inline: >>>>>>> >>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>> >>>>>>>> Hi John, >>>>>>>> >>>>>>>> apparently the vgaarb was not the problem. >>>>>>>> >>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>>>>> >>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>> console that emulates text mode? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>>>>> >>>>>> Yes. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>>>>> of work went into memory management recently. I could imagine that the >>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>> correct framebuffer. >>>>>>> >>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>> the output of >>>>>>>> >>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>> >>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>> >>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>> See below for how to get it. >>>>> >>>>> I built your “tip” ; Still no graphics displayed . >>>>> >>>>> >>>>> mount -t debugfs none /sys/kernel >>>>> >>>>> cat /proc/cmdline >>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>> >>>>> >>>>> cat /sys/kernel/dri/0/vram-mm >>>>> >>>>> In VGA mode : >>>>> >>>>> >>>>> cat /sys/kernel/dri/0/vram-mm >>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>> >>>>> >>>>> In GRAPHICS mode ( if it matters ) >>>>> >>>>> >>>>> cat /sys/kernel/dri/0/vram-mm >>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>> total: 2032, used 1538 free 494 >>>>> >>> >>> This is interesting. In the graphics mode, you see two buffers of 768 >>> pages each. That's the main framebuffers as used by X (it's double >>> buffered). Then there's a free area and finally two pages for cursor >>> images (also double buffered). That looks as expected. >>> >>> The thing is that in text mode, the areas are allocated. But the driver >>> shouldn't be active, so the file shouldn't exist or only show a single >>> free area. >>> >> >> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . >> >> >>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>>>>> >>>>>> Good! Looking through that log file, the card is found at line 79 and >>>>>> the generic X modesetting driver initializes below. That works as expected. >>>>>> >>>>>> I notices that several operations are not permitted (lines 78 and 87). I >>>>>> guess you're starting X from a regular user account? IIRC special >>>>>> permission is required to acquire control of the display. What happens >>>>>> if you start X as root user? >>>>> >>>>> >>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >>>>> >>>>> The default runlevel is 3 on boot . >>>>> >>>>> On failing session running your 5.4.0.rc6. >>>>> >>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>> >>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>>> >>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>>> >>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>> >>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>>> >>>>> >>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >>>>> >>>>> >>>>> >>>>> >>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>>>>> >>>>>>> # cat /proc/cmdline >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>> >>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>>>>> >>>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>>> >>>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>>> >>>>>> If you build this version you should find >>>>>> >>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>> >>>>>> on the device. You have to build with debugfs enabled and >>>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> before and after switching to graphics mode. The file lists the >>>>>>>> allocated regions of the VRAM. >>>>>>>> >>>>>>>>> >>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>>>>> >>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>>>>> >>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>>>>> more warnings. >>>>>>>> >>>>>>>> >>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>>>>> >>>>>>> >>>>>>> >>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>>>>> >>>>>>> >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>>>>> >>>>>>> >>>>>>> lspci -s 3d:00.0 -vvv -k >>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>>> Interrupt: pin A routed to IRQ 16 >>>>>>> NUMA node: 0 >>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>>> Capabilities: [dc] Power Management version 2 >>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>>> Address: 00000000 Data: 0000 >>>>>>> Kernel driver in use: mgag200 >>>>>>> Kernel modules: mgag200 >>>>>> >>>>>> Looks all normal. >>>>>> >>>>>> Best regards >>>>>> Thomas >>>>>> >>>> >>>> ============== Snip =========== >>>> >>>> >>>> Hi Thomas >>>> , >>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: >>>> >>>> >>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>>> >>>> >>>> I started to bisect this range on by date, by day , based on the changes done in : >>>> >>>> drivers/gpu/drm/ >>>> >>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>>> >>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. >>> >>> Great, thanks for bisecting. >>> >>> Could you attach your kernel config file? I'd like to compare with my >>> config and try to reproduce the issue. >>> >>> Best regards >>> Thomas >> >> Hi. >> >> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : >> >> config.5.2.21 - work with that flavor >> config.5.3. fails with 5.3 and later. >> >> Do you have access to mgag200 style adapter ? > > I do. > > I think I've been able to reproduce the issue. Buffers seem to remain in > video ram after they have been pinned there. I'll investigate next week. > I hope your bisecting session can point to the cause. > > Best regards > Thomas Hi Thomas, Wonderful! I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm Specifically this merge included these two changes : 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. If I build a kernel from : fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma That is posted day prior to be8454afc50f - the GNOME desktop works. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-08 18:07 ` John Donnelly @ 2019-11-08 19:10 ` Daniel Vetter 2019-11-11 15:57 ` Thomas Zimmermann 1 sibling, 0 replies; 20+ messages in thread From: Daniel Vetter @ 2019-11-08 19:10 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, Thomas Zimmermann, allen On Fri, Nov 8, 2019 at 7:07 PM John Donnelly <john.p.donnelly@oracle.com> wrote: > > > > > On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi > > > > Am 08.11.19 um 13:55 schrieb John Donnelly: > >> > >> > >>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>> > >>> Hi John > >>> > >>> Am 07.11.19 um 23:14 schrieb John Donnelly: > >>>> > >>>> > >>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: > >>>>> > >>>>> > >>>>> > >>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>>> > >>>>>> Hi John > >>>>>> > >>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: > >>>>>>> Hi Thomas ; Thank you for reaching out. > >>>>>>> > >>>>>>> See inline: > >>>>>>> > >>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>>>>> > >>>>>>>> Hi John, > >>>>>>>> > >>>>>>>> apparently the vgaarb was not the problem. > >>>>>>>> > >>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” > >>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. > >>>>>>>> > >>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical > >>>>>>>> console that emulates text mode? > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. > >>>>>> > >>>>>> Yes. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot > >>>>>>>> of work went into memory management recently. I could imagine that the > >>>>>>>> driver sets the correct resolution, but then fails to display the > >>>>>>>> correct framebuffer. > >>>>>>> > >>>>>>> There is no display at all ; so there is no resolution to mention. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> If possible, could you try to update to the latest drm-tip and attach > >>>>>>>> the output of > >>>>>>>> > >>>>>>>> /sys/kernel/debug/dri/0/vram-mm > >>>>>>> > >>>>>>> I don’t see that file ; Is there something else I need to do ? > >>>>>> > >>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. > >>>>>> See below for how to get it. > >>>>> > >>>>> I built your “tip” ; Still no graphics displayed . > >>>>> > >>>>> > >>>>> mount -t debugfs none /sys/kernel > >>>>> > >>>>> cat /proc/cmdline > >>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > >>>>> > >>>>> > >>>>> cat /sys/kernel/dri/0/vram-mm > >>>>> > >>>>> In VGA mode : > >>>>> > >>>>> > >>>>> cat /sys/kernel/dri/0/vram-mm > >>>>> 0x0000000000000000-0x0000000000000300: 768: used > >>>>> 0x0000000000000300-0x0000000000000600: 768: used > >>>>> 0x0000000000000600-0x00000000000007ee: 494: free > >>>>> 0x00000000000007ee-0x00000000000007ef: 1: used > >>>>> 0x00000000000007ef-0x00000000000007f0: 1: used > >>>>> > >>>>> > >>>>> In GRAPHICS mode ( if it matters ) > >>>>> > >>>>> > >>>>> cat /sys/kernel/dri/0/vram-mm > >>>>> 0x0000000000000000-0x0000000000000300: 768: used > >>>>> 0x0000000000000300-0x0000000000000600: 768: used > >>>>> 0x0000000000000600-0x00000000000007ee: 494: free > >>>>> 0x00000000000007ee-0x00000000000007ef: 1: used > >>>>> 0x00000000000007ef-0x00000000000007f0: 1: used > >>>>> total: 2032, used 1538 free 494 > >>>>> > >>> > >>> This is interesting. In the graphics mode, you see two buffers of 768 > >>> pages each. That's the main framebuffers as used by X (it's double > >>> buffered). Then there's a free area and finally two pages for cursor > >>> images (also double buffered). That looks as expected. > >>> > >>> The thing is that in text mode, the areas are allocated. But the driver > >>> shouldn't be active, so the file shouldn't exist or only show a single > >>> free area. > >>> > >> > >> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . > >> > >> > >>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; > >>>>>> > >>>>>> Good! Looking through that log file, the card is found at line 79 and > >>>>>> the generic X modesetting driver initializes below. That works as expected. > >>>>>> > >>>>>> I notices that several operations are not permitted (lines 78 and 87). I > >>>>>> guess you're starting X from a regular user account? IIRC special > >>>>>> permission is required to acquire control of the display. What happens > >>>>>> if you start X as root user? > >>>>> > >>>>> > >>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . > >>>>> > >>>>> The default runlevel is 3 on boot . > >>>>> > >>>>> On failing session running your 5.4.0.rc6. > >>>>> > >>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > >>>>> > >>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied > >>>>> > >>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log > >>>>> > >>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > >>>>> > >>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied > >>>>> > >>>>> > >>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . > >>>>>>> > >>>>>>> # cat /proc/cmdline > >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > >>>>>>> > >>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. > >>>>>> > >>>>>> The latest and greatest DRM code is in the drm-tip branch at > >>>>>> > >>>>>> git://anongit.freedesktop.org/drm/drm-tip > >>>>>> > >>>>>> If you build this version you should find > >>>>>> > >>>>>> /sys/kernel/debug/dri/0/vram-mm > >>>>>> > >>>>>> on the device. You have to build with debugfs enabled and > >>>>>> maybe have to mount debugfs at /sys/kernel/debug. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> before and after switching to graphics mode. The file lists the > >>>>>>>> allocated regions of the VRAM. > >>>>>>>> > >>>>>>>>> > >>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. > >>>>>>>>> > >>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: > >>>>>>>> > >>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable > >>>>>>>> more warnings. > >>>>>>>> > >>>>>>>> > >>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: > >>>>>>> > >>>>>>> > >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff > >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff > >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff > >>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console > >>>>>>> > >>>>>>> > >>>>>>> lspci -s 3d:00.0 -vvv -k > >>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) > >>>>>>> Subsystem: Oracle/SUN Device 4852 > >>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- > >>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > >>>>>>> Latency: 0, Cache Line Size: 64 bytes > >>>>>>> Interrupt: pin A routed to IRQ 16 > >>>>>>> NUMA node: 0 > >>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] > >>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] > >>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] > >>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] > >>>>>>> Capabilities: [dc] Power Management version 2 > >>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > >>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > >>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 > >>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us > >>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- > >>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- > >>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > >>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes > >>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > >>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns > >>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > >>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > >>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > >>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > >>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- > >>>>>>> Address: 00000000 Data: 0000 > >>>>>>> Kernel driver in use: mgag200 > >>>>>>> Kernel modules: mgag200 > >>>>>> > >>>>>> Looks all normal. > >>>>>> > >>>>>> Best regards > >>>>>> Thomas > >>>>>> > >>>> > >>>> ============== Snip =========== > >>>> > >>>> > >>>> Hi Thomas > >>>> , > >>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: > >>>> > >>>> > >>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 > >>>> > >>>> > >>>> I started to bisect this range on by date, by day , based on the changes done in : > >>>> > >>>> drivers/gpu/drm/ > >>>> > >>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works > >>>> > >>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. > >>> > >>> Great, thanks for bisecting. > >>> > >>> Could you attach your kernel config file? I'd like to compare with my > >>> config and try to reproduce the issue. > >>> > >>> Best regards > >>> Thomas > >> > >> Hi. > >> > >> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : > >> > >> config.5.2.21 - work with that flavor > >> config.5.3. fails with 5.3 and later. > >> > >> Do you have access to mgag200 style adapter ? > > > > I do. > > > > I think I've been able to reproduce the issue. Buffers seem to remain in > > video ram after they have been pinned there. I'll investigate next week. > > I hope your bisecting session can point to the cause. > > > > Best regards > > Thomas > > Hi Thomas, > > > Wonderful! > > I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : > > > be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm Are you bisecting by hand or is git bisect somehow giving you all these merge commits by chance? Ime always use git bisect, it's a lot better at accurately splitting the history down the middle. Also, I never bother with filtering for only "relevant" commits, since drm is so big nowadays that all you safe is 2-3 commits at most. And worst case the regression is outside of drm, and then you wasted booting into a _lot_ of kernels for not much gain. -Daniel > > Specifically this merge included these two changes : > > 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling > f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update > > > I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. > > If I build a kernel from : > > fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma > > That is posted day prior to be8454afc50f - the GNOME desktop works. > > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-08 18:07 ` John Donnelly 2019-11-08 19:10 ` Daniel Vetter @ 2019-11-11 15:57 ` Thomas Zimmermann 2019-11-11 17:40 ` John Donnelly 2019-11-12 19:13 ` John Donnelly 1 sibling, 2 replies; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-11 15:57 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, allen [-- Attachment #1.1.1: Type: text/plain, Size: 13647 bytes --] Hi John Am 08.11.19 um 19:07 schrieb John Donnelly: > > >> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Hi >> >> Am 08.11.19 um 13:55 schrieb John Donnelly: >>> >>> >>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>> >>>> Hi John >>>> >>>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>>> >>>>> >>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>> >>>>>>> Hi John >>>>>>> >>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>>> >>>>>>>> See inline: >>>>>>>> >>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>>> >>>>>>>>> Hi John, >>>>>>>>> >>>>>>>>> apparently the vgaarb was not the problem. >>>>>>>>> >>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>>>>>> >>>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>>> console that emulates text mode? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>>>>>> >>>>>>> Yes. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>>>>>> of work went into memory management recently. I could imagine that the >>>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>>> correct framebuffer. >>>>>>>> >>>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>>> the output of >>>>>>>>> >>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>> >>>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>>> >>>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>>> See below for how to get it. >>>>>> >>>>>> I built your “tip” ; Still no graphics displayed . >>>>>> >>>>>> >>>>>> mount -t debugfs none /sys/kernel >>>>>> >>>>>> cat /proc/cmdline >>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>> >>>>>> >>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>> >>>>>> In VGA mode : >>>>>> >>>>>> >>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>> >>>>>> >>>>>> In GRAPHICS mode ( if it matters ) >>>>>> >>>>>> >>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>> total: 2032, used 1538 free 494 >>>>>> >>>> >>>> This is interesting. In the graphics mode, you see two buffers of 768 >>>> pages each. That's the main framebuffers as used by X (it's double >>>> buffered). Then there's a free area and finally two pages for cursor >>>> images (also double buffered). That looks as expected. >>>> >>>> The thing is that in text mode, the areas are allocated. But the driver >>>> shouldn't be active, so the file shouldn't exist or only show a single >>>> free area. >>>> >>> >>> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . >>> >>> >>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>>>>>> >>>>>>> Good! Looking through that log file, the card is found at line 79 and >>>>>>> the generic X modesetting driver initializes below. That works as expected. >>>>>>> >>>>>>> I notices that several operations are not permitted (lines 78 and 87). I >>>>>>> guess you're starting X from a regular user account? IIRC special >>>>>>> permission is required to acquire control of the display. What happens >>>>>>> if you start X as root user? >>>>>> >>>>>> >>>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >>>>>> >>>>>> The default runlevel is 3 on boot . >>>>>> >>>>>> On failing session running your 5.4.0.rc6. >>>>>> >>>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>> >>>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>>>> >>>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>>>> >>>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>> >>>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>>>> >>>>>> >>>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>>>>>> >>>>>>>> # cat /proc/cmdline >>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>>> >>>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>>>>>> >>>>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>>>> >>>>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>>>> >>>>>>> If you build this version you should find >>>>>>> >>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>> >>>>>>> on the device. You have to build with debugfs enabled and >>>>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> before and after switching to graphics mode. The file lists the >>>>>>>>> allocated regions of the VRAM. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>>>>>> >>>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>>>>>> >>>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>>>>>> more warnings. >>>>>>>>> >>>>>>>>> >>>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>>>>>> >>>>>>>> >>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>>>>>> >>>>>>>> >>>>>>>> lspci -s 3d:00.0 -vvv -k >>>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>>>> Interrupt: pin A routed to IRQ 16 >>>>>>>> NUMA node: 0 >>>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>>>> Capabilities: [dc] Power Management version 2 >>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>>>> Address: 00000000 Data: 0000 >>>>>>>> Kernel driver in use: mgag200 >>>>>>>> Kernel modules: mgag200 >>>>>>> >>>>>>> Looks all normal. >>>>>>> >>>>>>> Best regards >>>>>>> Thomas >>>>>>> >>>>> >>>>> ============== Snip =========== >>>>> >>>>> >>>>> Hi Thomas >>>>> , >>>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: >>>>> >>>>> >>>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>>>> >>>>> >>>>> I started to bisect this range on by date, by day , based on the changes done in : >>>>> >>>>> drivers/gpu/drm/ >>>>> >>>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>>>> >>>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. >>>> >>>> Great, thanks for bisecting. >>>> >>>> Could you attach your kernel config file? I'd like to compare with my >>>> config and try to reproduce the issue. >>>> >>>> Best regards >>>> Thomas >>> >>> Hi. >>> >>> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : >>> >>> config.5.2.21 - work with that flavor >>> config.5.3. fails with 5.3 and later. >>> >>> Do you have access to mgag200 style adapter ? >> >> I do. >> >> I think I've been able to reproduce the issue. Buffers seem to remain in >> video ram after they have been pinned there. I'll investigate next week. >> I hope your bisecting session can point to the cause. >> >> Best regards >> Thomas > > Hi Thomas, > > > Wonderful! > > I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : > > > be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm > > Specifically this merge included these two changes : > > 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling > f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update > > > I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. > > If I build a kernel from : > > fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma > > That is posted day prior to be8454afc50f - the GNOME desktop works. I thought I could reproduce the problem, but I'm not so sure now. Please bisect the range between the two merges as described by Daniel to find the broken commit. Doing git bisect start git bisect bad be8454afc50f git bisect good fec88ab0af97 should start the session. Best regards Thomas > > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-11 15:57 ` Thomas Zimmermann @ 2019-11-11 17:40 ` John Donnelly 2019-11-12 10:02 ` Thomas Zimmermann 2019-11-12 19:13 ` John Donnelly 1 sibling, 1 reply; 20+ messages in thread From: John Donnelly @ 2019-11-11 17:40 UTC (permalink / raw) To: dri-devel On 11/11/19 9:57 AM, Thomas Zimmermann wrote: > Hi John > > Am 08.11.19 um 19:07 schrieb John Donnelly: >> >> >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi >>> >>> Am 08.11.19 um 13:55 schrieb John Donnelly: >>>> >>>> >>>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> >>>>> Hi John >>>>> >>>>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>>>> >>>>>> >>>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>> >>>>>>>> Hi John >>>>>>>> >>>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>>>> >>>>>>>>> See inline: >>>>>>>>> >>>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>>>> >>>>>>>>>> Hi John, >>>>>>>>>> >>>>>>>>>> apparently the vgaarb was not the problem. >>>>>>>>>> >>>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>>>>>>> >>>>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>>>> console that emulates text mode? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>>>>>>> of work went into memory management recently. I could imagine that the >>>>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>>>> correct framebuffer. >>>>>>>>> >>>>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>>>> the output of >>>>>>>>>> >>>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>>> >>>>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>>>> >>>>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>>>> See below for how to get it. >>>>>>> >>>>>>> I built your “tip” ; Still no graphics displayed . >>>>>>> >>>>>>> >>>>>>> mount -t debugfs none /sys/kernel >>>>>>> >>>>>>> cat /proc/cmdline >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> >>>>>>> In VGA mode : >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>> >>>>>>> >>>>>>> In GRAPHICS mode ( if it matters ) >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>> total: 2032, used 1538 free 494 >>>>>>> >>>>> >>>>> This is interesting. In the graphics mode, you see two buffers of 768 >>>>> pages each. That's the main framebuffers as used by X (it's double >>>>> buffered). Then there's a free area and finally two pages for cursor >>>>> images (also double buffered). That looks as expected. >>>>> >>>>> The thing is that in text mode, the areas are allocated. But the driver >>>>> shouldn't be active, so the file shouldn't exist or only show a single >>>>> free area. >>>>> >>>> >>>> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>>>>>>> >>>>>>>> Good! Looking through that log file, the card is found at line 79 and >>>>>>>> the generic X modesetting driver initializes below. That works as expected. >>>>>>>> >>>>>>>> I notices that several operations are not permitted (lines 78 and 87). I >>>>>>>> guess you're starting X from a regular user account? IIRC special >>>>>>>> permission is required to acquire control of the display. What happens >>>>>>>> if you start X as root user? >>>>>>> >>>>>>> >>>>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >>>>>>> >>>>>>> The default runlevel is 3 on boot . >>>>>>> >>>>>>> On failing session running your 5.4.0.rc6. >>>>>>> >>>>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>>> >>>>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>>>>> >>>>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>>>>> >>>>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>>> >>>>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>>>>> >>>>>>> >>>>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>>>>>>> >>>>>>>>> # cat /proc/cmdline >>>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>>>> >>>>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>>>>>>> >>>>>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>>>>> >>>>>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>>>>> >>>>>>>> If you build this version you should find >>>>>>>> >>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>> >>>>>>>> on the device. You have to build with debugfs enabled and >>>>>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> before and after switching to graphics mode. The file lists the >>>>>>>>>> allocated regions of the VRAM. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>>>>>>> >>>>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>>>>>>> >>>>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>>>>>>> more warnings. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>>>>>>> >>>>>>>>> >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>>>>>>> >>>>>>>>> >>>>>>>>> lspci -s 3d:00.0 -vvv -k >>>>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>>>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>>>>> Interrupt: pin A routed to IRQ 16 >>>>>>>>> NUMA node: 0 >>>>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>>>>> Capabilities: [dc] Power Management version 2 >>>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>>>>> Address: 00000000 Data: 0000 >>>>>>>>> Kernel driver in use: mgag200 >>>>>>>>> Kernel modules: mgag200 >>>>>>>> >>>>>>>> Looks all normal. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Thomas >>>>>>>> >>>>>> >>>>>> ============== Snip =========== >>>>>> >>>>>> >>>>>> Hi Thomas >>>>>> , >>>>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: >>>>>> >>>>>> >>>>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>>>>> >>>>>> >>>>>> I started to bisect this range on by date, by day , based on the changes done in : >>>>>> >>>>>> drivers/gpu/drm/ >>>>>> >>>>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>>>>> >>>>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. >>>>> >>>>> Great, thanks for bisecting. >>>>> >>>>> Could you attach your kernel config file? I'd like to compare with my >>>>> config and try to reproduce the issue. >>>>> >>>>> Best regards >>>>> Thomas >>>> >>>> Hi. >>>> >>>> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : >>>> >>>> config.5.2.21 - work with that flavor >>>> config.5.3. fails with 5.3 and later. >>>> >>>> Do you have access to mgag200 style adapter ? >>> >>> I do. >>> >>> I think I've been able to reproduce the issue. Buffers seem to remain in >>> video ram after they have been pinned there. I'll investigate next week. >>> I hope your bisecting session can point to the cause. >>> >>> Best regards >>> Thomas >> >> Hi Thomas, >> >> >> Wonderful! >> >> I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : >> >> >> be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm >> >> Specifically this merge included these two changes : >> >> 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling >> f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update >> >> >> I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. >> >> If I build a kernel from : >> >> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma >> >> That is posted day prior to be8454afc50f - the GNOME desktop works. > > I thought I could reproduce the problem, but I'm not so sure now. > > Please bisect the range between the two merges as described by Daniel to > find the broken commit. Doing > > git bisect start > git bisect bad be8454afc50f > git bisect good fec88ab0af97 > > should start the session. > Hi, I am OoO today . I will start this exercise tomorrow. -- Thank You, John _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-11 17:40 ` John Donnelly @ 2019-11-12 10:02 ` Thomas Zimmermann 0 siblings, 0 replies; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-12 10:02 UTC (permalink / raw) To: John Donnelly, dri-devel [-- Attachment #1.1.1: Type: text/plain, Size: 16006 bytes --] Hi just a few more comments. Am 11.11.19 um 18:40 schrieb John Donnelly: > On 11/11/19 9:57 AM, Thomas Zimmermann wrote: >> Hi John >> >> Am 08.11.19 um 19:07 schrieb John Donnelly: >>> >>> >>>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> >>>> wrote: >>>> >>>> Hi >>>> >>>> Am 08.11.19 um 13:55 schrieb John Donnelly: >>>>> >>>>> >>>>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann >>>>>> <tzimmermann@suse.de> wrote: >>>>>> >>>>>> Hi John >>>>>> >>>>>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly >>>>>>>> <john.p.donnelly@oracle.com> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann >>>>>>>>> <tzimmermann@suse.de> wrote: >>>>>>>>> >>>>>>>>> Hi John >>>>>>>>> >>>>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>>>>> >>>>>>>>>> See inline: >>>>>>>>>> >>>>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann >>>>>>>>>>> <tzimmermann@suse.de> wrote: >>>>>>>>>>> >>>>>>>>>>> Hi John, >>>>>>>>>>> >>>>>>>>>>> apparently the vgaarb was not the problem. >>>>>>>>>>> >>>>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I am investigating an issue where we lose video activity >>>>>>>>>>>> when the display is switched from from “text mode” to >>>>>>>>>>>> “graphic mode” >>>>>>>>>>>> on a number of servers using this driver. Specifically >>>>>>>>>>>> starting the GNOME desktop. >>>>>>>>>>> >>>>>>>>>>> When you say "text mode", do you mean VGA text mode or the >>>>>>>>>>> graphical >>>>>>>>>>> console that emulates text mode? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS >>>>>>>>>> . Ie : run-level 3; So I guess your term for it is VGA. >>>>>>>>> >>>>>>>>> Yes. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> When you enable graphics mode, does it set the correct >>>>>>>>>>> resolution? A lot >>>>>>>>>>> of work went into memory management recently. I could imagine >>>>>>>>>>> that the >>>>>>>>>>> driver sets the correct resolution, but then fails to display >>>>>>>>>>> the >>>>>>>>>>> correct framebuffer. >>>>>>>>>> >>>>>>>>>> There is no display at all ; so there is no resolution to >>>>>>>>>> mention. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> If possible, could you try to update to the latest drm-tip >>>>>>>>>>> and attach >>>>>>>>>>> the output of >>>>>>>>>>> >>>>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>>>> >>>>>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>>>>> >>>>>>>>> That file is fairly new and maybe it's not in the mainline >>>>>>>>> kernel yet. >>>>>>>>> See below for how to get it. >>>>>>>> >>>>>>>> I built your “tip” ; Still no graphics displayed . >>>>>>>> >>>>>>>> >>>>>>>> mount -t debugfs none /sys/kernel >>>>>>>> >>>>>>>> cat /proc/cmdline >>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ >>>>>>>> root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto >>>>>>>> resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root >>>>>>>> rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>>> >>>>>>>> >>>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>>> >>>>>>>> In VGA mode : >>>>>>>> >>>>>>>> >>>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>>> >>>>>>>> >>>>>>>> In GRAPHICS mode ( if it matters ) >>>>>>>> >>>>>>>> >>>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>>> total: 2032, used 1538 free 494 Reconsidering this output, it actually makes sense. X11 only allocates a single framebuffer and uses an additional shadow buffer for its rendering. So the memory map is OK. I'm having some problems with running Gnome 3.34 (3.32 is fine), which makes it hard to distinguish Gnome errors from driver errors. I guess I'm back to step 1. :( Best regards Thomas >>>>>>>> >>>>>> >>>>>> This is interesting. In the graphics mode, you see two buffers of 768 >>>>>> pages each. That's the main framebuffers as used by X (it's double >>>>>> buffered). Then there's a free area and finally two pages for cursor >>>>>> images (also double buffered). That looks as expected. >>>>>> >>>>>> The thing is that in text mode, the areas are allocated. But the >>>>>> driver >>>>>> shouldn't be active, so the file shouldn't exist or only show a >>>>>> single >>>>>> free area. >>>>>> >>>>> >>>>> If you want me to double check this I will . I have GNOME >>>>> installed , but the machine boots to runlevel 3, then I start the >>>>> desktop using init 5 I am pretty sure I took that output when the >>>>> machine was in graphic’s mode at runlevel 5 . >>>>> >>>>> >>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; >>>>>>>>>> instead ; >>>>>>>>> >>>>>>>>> Good! Looking through that log file, the card is found at line >>>>>>>>> 79 and >>>>>>>>> the generic X modesetting driver initializes below. That works >>>>>>>>> as expected. >>>>>>>>> >>>>>>>>> I notices that several operations are not permitted (lines 78 >>>>>>>>> and 87). I >>>>>>>>> guess you're starting X from a regular user account? IIRC special >>>>>>>>> permission is required to acquire control of the display. What >>>>>>>>> happens >>>>>>>>> if you start X as root user? >>>>>>>> >>>>>>>> >>>>>>>> I am starting GNOME as root by doing “init 5” from either >>>>>>>> the console session or from ssh . >>>>>>>> >>>>>>>> The default runlevel is 3 on boot . >>>>>>>> >>>>>>>> On failing session running your 5.4.0.rc6. >>>>>>>> >>>>>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O >>>>>>>> (Operation not permitted) >>>>>>>> >>>>>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>>>>>> >>>>>>>> Booting 4.18 kernel yields the same error results in: >>>>>>>> /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>>>>>> >>>>>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O >>>>>>>> (Operation not permitted) >>>>>>>> >>>>>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>>>>>> >>>>>>>> >>>>>>>> What is strange the X logs ( bad and Ok ) files essentially >>>>>>>> appear as if GNOME started ! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( >>>>>>>>>> my last test was 5.3.8 and it failed also ) . >>>>>>>>>> >>>>>>>>>> # cat /proc/cmdline >>>>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ >>>>>>>>>> root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto >>>>>>>>>> resume=/dev/mapper/ol_ca--dev55-swap >>>>>>>>>> rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap >>>>>>>>>> console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>>>>> >>>>>>>>>> When you say “tip”. - Are you referring to a specific kernel >>>>>>>>>> ? I can build a 5.4.0.rc6 ; The problem appears to have >>>>>>>>>> been introduced around 5.3 time frame. >>>>>>>>> >>>>>>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>>>>>> >>>>>>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>>>>>> >>>>>>>>> If you build this version you should find >>>>>>>>> >>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>>> >>>>>>>>> on the device. You have to build with debugfs enabled and >>>>>>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> before and after switching to graphics mode. The file lists the >>>>>>>>>>> allocated regions of the VRAM. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> This adapter is Server Engines Integrated Remote Video >>>>>>>>>>>> Acceleration Subsystem (RVAS) and is used as remote console >>>>>>>>>>>> in iLO/DRAC environments. >>>>>>>>>>>> >>>>>>>>>>>> I don’t see any specific errors in the gdm logs or message >>>>>>>>>>>> file other than this: >>>>>>>>>>> >>>>>>>>>>> You can boot with drm.debug=0xff on the kernel command line >>>>>>>>>>> to enable >>>>>>>>>>> more warnings. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Could you please attach the output of lspci -v for the VGA >>>>>>>>>>> adapter? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Here is the output from the current machine; The previous >>>>>>>>>> addresses were from another model using the same SE device: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>>>>>>>>> remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> >>>>>>>>>> 0xc5ffffff >>>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>>>>>>>>> remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> >>>>>>>>>> 0xc6813fff >>>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: >>>>>>>>>> remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> >>>>>>>>>> 0xc67fffff >>>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: >>>>>>>>>> deactivate vga console >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> lspci -s 3d:00.0 -vvv -k >>>>>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems >>>>>>>>>> Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if >>>>>>>>>> 00 [VGA controller]) >>>>>>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- >>>>>>>>>> VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >>>>>>>>>> >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>>>>>> Interrupt: pin A routed to IRQ 16 >>>>>>>>>> NUMA node: 0 >>>>>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) >>>>>>>>>> [size=16M] >>>>>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) >>>>>>>>>> [size=16K] >>>>>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) >>>>>>>>>> [size=8M] >>>>>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>>>>>> Capabilities: [dc] Power Management version 2 >>>>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA >>>>>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency >>>>>>>>>> L0s <64ns, L1 <1us >>>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ >>>>>>>>>> Fatal+ Unsupported- >>>>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ >>>>>>>>>> AuxPwr- TransPend- >>>>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, >>>>>>>>>> Exit Latency L0s <64ns >>>>>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- >>>>>>>>>> SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>>>>>> Address: 00000000 Data: 0000 >>>>>>>>>> Kernel driver in use: mgag200 >>>>>>>>>> Kernel modules: mgag200 >>>>>>>>> >>>>>>>>> Looks all normal. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Thomas >>>>>>>>> >>>>>>> >>>>>>> ============== Snip =========== >>>>>>> >>>>>>> >>>>>>> Hi Thomas >>>>>>> , >>>>>>> I hopefully narrowed down the breakage between these up-stream >>>>>>> commits, which is v5.2 and 5.3.0-rc1: >>>>>>> >>>>>>> >>>>>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : >>>>>>> 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>>>>>> >>>>>>> >>>>>>> I started to bisect this range on by date, by day , based on the >>>>>>> changes done in : >>>>>>> >>>>>>> drivers/gpu/drm/ >>>>>>> >>>>>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of >>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>>>>>> >>>>>>> Hopefully something in drivers/gpu/drm/ between the date range of >>>>>>> 2019-07-14 to 2019-07-21 will surface tomorrow. >>>>>> >>>>>> Great, thanks for bisecting. >>>>>> >>>>>> Could you attach your kernel config file? I'd like to compare with my >>>>>> config and try to reproduce the issue. >>>>>> >>>>>> Best regards >>>>>> Thomas >>>>> >>>>> Hi. >>>>> >>>>> Here are config files generated after a “ make oldconfig “ >>>>> that started with an original .config file from a master file we >>>>> use for 5.4.0.-rc4. : >>>>> >>>>> config.5.2.21 - work with that flavor >>>>> config.5.3. fails with 5.3 and later. >>>>> >>>>> Do you have access to mgag200 style adapter ? >>>> >>>> I do. >>>> >>>> I think I've been able to reproduce the issue. Buffers seem to >>>> remain in >>>> video ram after they have been pinned there. I'll investigate next >>>> week. >>>> I hope your bisecting session can point to the cause. >>>> >>>> Best regards >>>> Thomas >>> >>> Hi Thomas, >>> >>> >>> Wonderful! >>> >>> I think I have narrowed down the merge to this build which is : >>> vmlinuz-5.2.0-rc5+ : >>> >>> >>> be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of >>> git://anongit.freedesktop.org/drm/drm >>> >>> Specifically this merge included these two changes : >>> >>> 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling >>> f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during >>> dirty update >>> >>> >>> I tried reverting them and the resultant driver doesn’t build >>> afterwards due to drm calls. >>> >>> If I build a kernel from : >>> >>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of >>> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma >>> >>> That is posted day prior to be8454afc50f - the GNOME desktop works. >> >> I thought I could reproduce the problem, but I'm not so sure now. >> >> Please bisect the range between the two merges as described by Daniel to >> find the broken commit. Doing >> >> git bisect start >> git bisect bad be8454afc50f >> git bisect good fec88ab0af97 >> >> should start the session. >> > Hi, > > I am OoO today . I will start this exercise tomorrow. > > > > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-11 15:57 ` Thomas Zimmermann 2019-11-11 17:40 ` John Donnelly @ 2019-11-12 19:13 ` John Donnelly 2019-11-12 20:14 ` Daniel Vetter 2019-11-13 8:17 ` Thomas Zimmermann 1 sibling, 2 replies; 20+ messages in thread From: John Donnelly @ 2019-11-12 19:13 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen > On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi John > > Am 08.11.19 um 19:07 schrieb John Donnelly: >> >> >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi >>> >>> Am 08.11.19 um 13:55 schrieb John Donnelly: >>>> >>>> >>>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>> >>>>> Hi John >>>>> >>>>> Am 07.11.19 um 23:14 schrieb John Donnelly: >>>>>> >>>>>> >>>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>> >>>>>>>> Hi John >>>>>>>> >>>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: >>>>>>>>> Hi Thomas ; Thank you for reaching out. >>>>>>>>> >>>>>>>>> See inline: >>>>>>>>> >>>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>>>>>>>>> >>>>>>>>>> Hi John, >>>>>>>>>> >>>>>>>>>> apparently the vgaarb was not the problem. >>>>>>>>>> >>>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” >>>>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. >>>>>>>>>> >>>>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical >>>>>>>>>> console that emulates text mode? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. >>>>>>>> >>>>>>>> Yes. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot >>>>>>>>>> of work went into memory management recently. I could imagine that the >>>>>>>>>> driver sets the correct resolution, but then fails to display the >>>>>>>>>> correct framebuffer. >>>>>>>>> >>>>>>>>> There is no display at all ; so there is no resolution to mention. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> If possible, could you try to update to the latest drm-tip and attach >>>>>>>>>> the output of >>>>>>>>>> >>>>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>>> >>>>>>>>> I don’t see that file ; Is there something else I need to do ? >>>>>>>> >>>>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. >>>>>>>> See below for how to get it. >>>>>>> >>>>>>> I built your “tip” ; Still no graphics displayed . >>>>>>> >>>>>>> >>>>>>> mount -t debugfs none /sys/kernel >>>>>>> >>>>>>> cat /proc/cmdline >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> >>>>>>> In VGA mode : >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>> >>>>>>> >>>>>>> In GRAPHICS mode ( if it matters ) >>>>>>> >>>>>>> >>>>>>> cat /sys/kernel/dri/0/vram-mm >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used >>>>>>> total: 2032, used 1538 free 494 >>>>>>> >>>>> >>>>> This is interesting. In the graphics mode, you see two buffers of 768 >>>>> pages each. That's the main framebuffers as used by X (it's double >>>>> buffered). Then there's a free area and finally two pages for cursor >>>>> images (also double buffered). That looks as expected. >>>>> >>>>> The thing is that in text mode, the areas are allocated. But the driver >>>>> shouldn't be active, so the file shouldn't exist or only show a single >>>>> free area. >>>>> >>>> >>>> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . >>>> >>>> >>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; >>>>>>>> >>>>>>>> Good! Looking through that log file, the card is found at line 79 and >>>>>>>> the generic X modesetting driver initializes below. That works as expected. >>>>>>>> >>>>>>>> I notices that several operations are not permitted (lines 78 and 87). I >>>>>>>> guess you're starting X from a regular user account? IIRC special >>>>>>>> permission is required to acquire control of the display. What happens >>>>>>>> if you start X as root user? >>>>>>> >>>>>>> >>>>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . >>>>>>> >>>>>>> The default runlevel is 3 on boot . >>>>>>> >>>>>>> On failing session running your 5.4.0.rc6. >>>>>>> >>>>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>>> >>>>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied >>>>>>> >>>>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log >>>>>>> >>>>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) >>>>>>> >>>>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied >>>>>>> >>>>>>> >>>>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . >>>>>>>>> >>>>>>>>> # cat /proc/cmdline >>>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff >>>>>>>>> >>>>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. >>>>>>>> >>>>>>>> The latest and greatest DRM code is in the drm-tip branch at >>>>>>>> >>>>>>>> git://anongit.freedesktop.org/drm/drm-tip >>>>>>>> >>>>>>>> If you build this version you should find >>>>>>>> >>>>>>>> /sys/kernel/debug/dri/0/vram-mm >>>>>>>> >>>>>>>> on the device. You have to build with debugfs enabled and >>>>>>>> maybe have to mount debugfs at /sys/kernel/debug. >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> before and after switching to graphics mode. The file lists the >>>>>>>>>> allocated regions of the VRAM. >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. >>>>>>>>>>> >>>>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: >>>>>>>>>> >>>>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable >>>>>>>>>> more warnings. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: >>>>>>>>> >>>>>>>>> >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console >>>>>>>>> >>>>>>>>> >>>>>>>>> lspci -s 3d:00.0 -vvv -k >>>>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) >>>>>>>>> Subsystem: Oracle/SUN Device 4852 >>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- >>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- >>>>>>>>> Latency: 0, Cache Line Size: 64 bytes >>>>>>>>> Interrupt: pin A routed to IRQ 16 >>>>>>>>> NUMA node: 0 >>>>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] >>>>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] >>>>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] >>>>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] >>>>>>>>> Capabilities: [dc] Power Management version 2 >>>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) >>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- >>>>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 >>>>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us >>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- >>>>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- >>>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- >>>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes >>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- >>>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns >>>>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- >>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ >>>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- >>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- >>>>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- >>>>>>>>> Address: 00000000 Data: 0000 >>>>>>>>> Kernel driver in use: mgag200 >>>>>>>>> Kernel modules: mgag200 >>>>>>>> >>>>>>>> Looks all normal. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Thomas >>>>>>>> >>>>>> >>>>>> ============== Snip =========== >>>>>> >>>>>> >>>>>> Hi Thomas >>>>>> , >>>>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: >>>>>> >>>>>> >>>>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 >>>>>> >>>>>> >>>>>> I started to bisect this range on by date, by day , based on the changes done in : >>>>>> >>>>>> drivers/gpu/drm/ >>>>>> >>>>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works >>>>>> >>>>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. >>>>> >>>>> Great, thanks for bisecting. >>>>> >>>>> Could you attach your kernel config file? I'd like to compare with my >>>>> config and try to reproduce the issue. >>>>> >>>>> Best regards >>>>> Thomas >>>> >>>> Hi. >>>> >>>> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : >>>> >>>> config.5.2.21 - work with that flavor >>>> config.5.3. fails with 5.3 and later. >>>> >>>> Do you have access to mgag200 style adapter ? >>> >>> I do. >>> >>> I think I've been able to reproduce the issue. Buffers seem to remain in >>> video ram after they have been pinned there. I'll investigate next week. >>> I hope your bisecting session can point to the cause. >>> >>> Best regards >>> Thomas >> >> Hi Thomas, >> >> >> Wonderful! >> >> I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : >> >> >> be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm >> >> Specifically this merge included these two changes : >> >> 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling >> f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update >> >> >> I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. >> >> If I build a kernel from : >> >> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma >> >> That is posted day prior to be8454afc50f - the GNOME desktop works. > > I thought I could reproduce the problem, but I'm not so sure now. > > Please bisect the range between the two merges as described by Daniel to > find the broken commit. Doing > > git bisect start > git bisect bad be8454afc50f > git bisect good fec88ab0af97 > > should start the session. In short . I started with : git bisect start git bisect bad be8454afc50f git bisect good fec88ab0af97 And at the the end of bisects showed this was the offending commit : c0a74c732568 commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) Author: Jani Nikula <jani.nikula@intel.com> Date: Fri May 24 20:35:22 2019 +0300 drm/i915: Update DRIVER_DATE to 20190524 Signed-off-by: Jani Nikula <jani.nikula@intel.com> That does not have any real relevance I am not sure if I did the bisects correctly . After each test I did : #1 git bisect bad 827440a90146 #2 git bisect bad f5b07b04e5f0 #3 git bisect bad c0a74c732568 #4 git bisect good 818f5cb3e8fb #5 git bisect good 6cfe7ec02e85 #6 git bisect good f71e01a78bee #7 git bisect good 09a93ef3d60f #8 git bisect good f1e6b336bafa #9 git bisect good eaf20e6933dc #10 git bisect good 63e8dcdb4f8e #11 git bisect good 397049a03022 I’ve restarted the bisect without appending the <commit-id> after a the “bad|good “ , and so far git is showing the same selections. _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-12 19:13 ` John Donnelly @ 2019-11-12 20:14 ` Daniel Vetter 2019-11-13 8:17 ` Thomas Zimmermann 1 sibling, 0 replies; 20+ messages in thread From: Daniel Vetter @ 2019-11-12 20:14 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, Thomas Zimmermann, allen On Tue, Nov 12, 2019 at 8:13 PM John Donnelly <john.p.donnelly@oracle.com> wrote: > > > > > On Nov 11, 2019, at 9:57 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi John > > > > Am 08.11.19 um 19:07 schrieb John Donnelly: > >> > >> > >>> On Nov 8, 2019, at 9:06 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>> > >>> Hi > >>> > >>> Am 08.11.19 um 13:55 schrieb John Donnelly: > >>>> > >>>> > >>>>> On Nov 8, 2019, at 1:46 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>> > >>>>> Hi John > >>>>> > >>>>> Am 07.11.19 um 23:14 schrieb John Donnelly: > >>>>>> > >>>>>> > >>>>>>> On Nov 7, 2019, at 10:13 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> On Nov 7, 2019, at 7:42 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>>>>> > >>>>>>>> Hi John > >>>>>>>> > >>>>>>>> Am 07.11.19 um 14:12 schrieb John Donnelly: > >>>>>>>>> Hi Thomas ; Thank you for reaching out. > >>>>>>>>> > >>>>>>>>> See inline: > >>>>>>>>> > >>>>>>>>>> On Nov 7, 2019, at 1:54 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > >>>>>>>>>> > >>>>>>>>>> Hi John, > >>>>>>>>>> > >>>>>>>>>> apparently the vgaarb was not the problem. > >>>>>>>>>> > >>>>>>>>>> Am 07.11.19 um 03:29 schrieb John Donnelly: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> I am investigating an issue where we lose video activity when the display is switched from from “text mode” to “graphic mode” > >>>>>>>>>>> on a number of servers using this driver. Specifically starting the GNOME desktop. > >>>>>>>>>> > >>>>>>>>>> When you say "text mode", do you mean VGA text mode or the graphical > >>>>>>>>>> console that emulates text mode? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> I call “text mode” the 24x80 ascii mode ; - NOT GRAPHICS . Ie : run-level 3; So I guess your term for it is VGA. > >>>>>>>> > >>>>>>>> Yes. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> When you enable graphics mode, does it set the correct resolution? A lot > >>>>>>>>>> of work went into memory management recently. I could imagine that the > >>>>>>>>>> driver sets the correct resolution, but then fails to display the > >>>>>>>>>> correct framebuffer. > >>>>>>>>> > >>>>>>>>> There is no display at all ; so there is no resolution to mention. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> If possible, could you try to update to the latest drm-tip and attach > >>>>>>>>>> the output of > >>>>>>>>>> > >>>>>>>>>> /sys/kernel/debug/dri/0/vram-mm > >>>>>>>>> > >>>>>>>>> I don’t see that file ; Is there something else I need to do ? > >>>>>>>> > >>>>>>>> That file is fairly new and maybe it's not in the mainline kernel yet. > >>>>>>>> See below for how to get it. > >>>>>>> > >>>>>>> I built your “tip” ; Still no graphics displayed . > >>>>>>> > >>>>>>> > >>>>>>> mount -t debugfs none /sys/kernel > >>>>>>> > >>>>>>> cat /proc/cmdline > >>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.4.0-rc6.drm.+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > >>>>>>> > >>>>>>> > >>>>>>> cat /sys/kernel/dri/0/vram-mm > >>>>>>> > >>>>>>> In VGA mode : > >>>>>>> > >>>>>>> > >>>>>>> cat /sys/kernel/dri/0/vram-mm > >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used > >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used > >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free > >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used > >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used > >>>>>>> > >>>>>>> > >>>>>>> In GRAPHICS mode ( if it matters ) > >>>>>>> > >>>>>>> > >>>>>>> cat /sys/kernel/dri/0/vram-mm > >>>>>>> 0x0000000000000000-0x0000000000000300: 768: used > >>>>>>> 0x0000000000000300-0x0000000000000600: 768: used > >>>>>>> 0x0000000000000600-0x00000000000007ee: 494: free > >>>>>>> 0x00000000000007ee-0x00000000000007ef: 1: used > >>>>>>> 0x00000000000007ef-0x00000000000007f0: 1: used > >>>>>>> total: 2032, used 1538 free 494 > >>>>>>> > >>>>> > >>>>> This is interesting. In the graphics mode, you see two buffers of 768 > >>>>> pages each. That's the main framebuffers as used by X (it's double > >>>>> buffered). Then there's a free area and finally two pages for cursor > >>>>> images (also double buffered). That looks as expected. > >>>>> > >>>>> The thing is that in text mode, the areas are allocated. But the driver > >>>>> shouldn't be active, so the file shouldn't exist or only show a single > >>>>> free area. > >>>>> > >>>> > >>>> If you want me to double check this I will . I have GNOME installed , but the machine boots to runlevel 3, then I start the desktop using init 5 I am pretty sure I took that output when the machine was in graphic’s mode at runlevel 5 . > >>>> > >>>> > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> I’ve attached : var/lib/gdm/.local/share/xorg/Xorg.0.log. ; instead ; > >>>>>>>> > >>>>>>>> Good! Looking through that log file, the card is found at line 79 and > >>>>>>>> the generic X modesetting driver initializes below. That works as expected. > >>>>>>>> > >>>>>>>> I notices that several operations are not permitted (lines 78 and 87). I > >>>>>>>> guess you're starting X from a regular user account? IIRC special > >>>>>>>> permission is required to acquire control of the display. What happens > >>>>>>>> if you start X as root user? > >>>>>>> > >>>>>>> > >>>>>>> I am starting GNOME as root by doing “init 5” from either the console session or from ssh . > >>>>>>> > >>>>>>> The default runlevel is 3 on boot . > >>>>>>> > >>>>>>> On failing session running your 5.4.0.rc6. > >>>>>>> > >>>>>>> 78 [ 237.712] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > >>>>>>> > >>>>>>> 87 [ 237.712] (EE) open /dev/fb0: Permission denied > >>>>>>> > >>>>>>> Booting 4.18 kernel yields the same error results in: /var/lib/gdm/.local/share/xorg/Xorg.0.log > >>>>>>> > >>>>>>> 78 [ 101.334] xf86EnableIOPorts: failed to set IOPL for I/O (Operation not permitted) > >>>>>>> > >>>>>>> 87 [ 101.334] (EE) open /dev/fb0: Permission denied > >>>>>>> > >>>>>>> > >>>>>>> What is strange the X logs ( bad and Ok ) files essentially appear as if GNOME started ! > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> <Xorg.0.log.bad><Xorg.0.log.Ok> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Here is my cmdline - I just tested 5.3.0 and it fails too ( my last test was 5.3.8 and it failed also ) . > >>>>>>>>> > >>>>>>>>> # cat /proc/cmdline > >>>>>>>>> BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.3.0+ root=/dev/mapper/ol_ca--dev55-root ro crashkernel=auto resume=/dev/mapper/ol_ca--dev55-swap rd.lvm.lv=ol_ca-dev55/root rd.lvm.lv=ol_ca-dev55/swap console=ttyS0,9600,8,n,1 drm.debug=0xff > >>>>>>>>> > >>>>>>>>> When you say “tip”. - Are you referring to a specific kernel ? I can build a 5.4.0.rc6 ; The problem appears to have been introduced around 5.3 time frame. > >>>>>>>> > >>>>>>>> The latest and greatest DRM code is in the drm-tip branch at > >>>>>>>> > >>>>>>>> git://anongit.freedesktop.org/drm/drm-tip > >>>>>>>> > >>>>>>>> If you build this version you should find > >>>>>>>> > >>>>>>>> /sys/kernel/debug/dri/0/vram-mm > >>>>>>>> > >>>>>>>> on the device. You have to build with debugfs enabled and > >>>>>>>> maybe have to mount debugfs at /sys/kernel/debug. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> before and after switching to graphics mode. The file lists the > >>>>>>>>>> allocated regions of the VRAM. > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This adapter is Server Engines Integrated Remote Video Acceleration Subsystem (RVAS) and is used as remote console in iLO/DRAC environments. > >>>>>>>>>>> > >>>>>>>>>>> I don’t see any specific errors in the gdm logs or message file other than this: > >>>>>>>>>> > >>>>>>>>>> You can boot with drm.debug=0xff on the kernel command line to enable > >>>>>>>>>> more warnings. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Could you please attach the output of lspci -v for the VGA adapter? > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Here is the output from the current machine; The previous addresses were from another model using the same SE device: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 0: 0xc5000000 -> 0xc5ffffff > >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 1: 0xc6810000 -> 0xc6813fff > >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: remove_conflicting_pci_framebuffers: bar 2: 0xc6000000 -> 0xc67fffff > >>>>>>>>> Nov 7 04:42:50 ca-dev55 kernel: mgag200 0000:3d:00.0: vgaarb: deactivate vga console > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> lspci -s 3d:00.0 -vvv -k > >>>>>>>>> 3d:00.0 VGA compatible controller: Matrox Electronics Systems Ltd. MGA G200e [Pilot] ServerEngines (SEP1) (rev 05) (prog-if 00 [VGA controller]) > >>>>>>>>> Subsystem: Oracle/SUN Device 4852 > >>>>>>>>> Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx- > >>>>>>>>> Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- > >>>>>>>>> Latency: 0, Cache Line Size: 64 bytes > >>>>>>>>> Interrupt: pin A routed to IRQ 16 > >>>>>>>>> NUMA node: 0 > >>>>>>>>> Region 0: Memory at c5000000 (32-bit, non-prefetchable) [size=16M] > >>>>>>>>> Region 1: Memory at c6810000 (32-bit, non-prefetchable) [size=16K] > >>>>>>>>> Region 2: Memory at c6000000 (32-bit, non-prefetchable) [size=8M] > >>>>>>>>> Expansion ROM at 000c0000 [disabled] [size=128K] > >>>>>>>>> Capabilities: [dc] Power Management version 2 > >>>>>>>>> Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) > >>>>>>>>> Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- > >>>>>>>>> Capabilities: [e4] Express (v1) Legacy Endpoint, MSI 00 > >>>>>>>>> DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <64ns, L1 <1us > >>>>>>>>> ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset- > >>>>>>>>> DevCtl: Report errors: Correctable+ Non-Fatal+ Fatal+ Unsupported- > >>>>>>>>> RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- > >>>>>>>>> MaxPayload 128 bytes, MaxReadReq 128 bytes > >>>>>>>>> DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- > >>>>>>>>> LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s, Exit Latency L0s <64ns > >>>>>>>>> ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp- > >>>>>>>>> LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ > >>>>>>>>> ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- > >>>>>>>>> LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- > >>>>>>>>> Capabilities: [54] MSI: Enable- Count=1/1 Maskable- 64bit- > >>>>>>>>> Address: 00000000 Data: 0000 > >>>>>>>>> Kernel driver in use: mgag200 > >>>>>>>>> Kernel modules: mgag200 > >>>>>>>> > >>>>>>>> Looks all normal. > >>>>>>>> > >>>>>>>> Best regards > >>>>>>>> Thomas > >>>>>>>> > >>>>>> > >>>>>> ============== Snip =========== > >>>>>> > >>>>>> > >>>>>> Hi Thomas > >>>>>> , > >>>>>> I hopefully narrowed down the breakage between these up-stream commits, which is v5.2 and 5.3.0-rc1: > >>>>>> > >>>>>> > >>>>>> between : 0ecfebd2b524 2019-07-07 | Linux 5.2 to : 5f9e832c1370 2019-07-21 | Linus 5.3-rc1 > >>>>>> > >>>>>> > >>>>>> I started to bisect this range on by date, by day , based on the changes done in : > >>>>>> > >>>>>> drivers/gpu/drm/ > >>>>>> > >>>>>> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma ; works > >>>>>> > >>>>>> Hopefully something in drivers/gpu/drm/ between the date range of 2019-07-14 to 2019-07-21 will surface tomorrow. > >>>>> > >>>>> Great, thanks for bisecting. > >>>>> > >>>>> Could you attach your kernel config file? I'd like to compare with my > >>>>> config and try to reproduce the issue. > >>>>> > >>>>> Best regards > >>>>> Thomas > >>>> > >>>> Hi. > >>>> > >>>> Here are config files generated after a “ make oldconfig “ that started with an original .config file from a master file we use for 5.4.0.-rc4. : > >>>> > >>>> config.5.2.21 - work with that flavor > >>>> config.5.3. fails with 5.3 and later. > >>>> > >>>> Do you have access to mgag200 style adapter ? > >>> > >>> I do. > >>> > >>> I think I've been able to reproduce the issue. Buffers seem to remain in > >>> video ram after they have been pinned there. I'll investigate next week. > >>> I hope your bisecting session can point to the cause. > >>> > >>> Best regards > >>> Thomas > >> > >> Hi Thomas, > >> > >> > >> Wonderful! > >> > >> I think I have narrowed down the merge to this build which is : vmlinuz-5.2.0-rc5+ : > >> > >> > >> be8454afc50f 2019-07-15 | Merge tag 'drm-next-2019-07-16' of git://anongit.freedesktop.org/drm/drm > >> > >> Specifically this merge included these two changes : > >> > >> 94dc57b10399 2019-06-13 | drm/mgag200: Rewrite cursor handling > >> f4ce5af71bc2 2019-06-13 | drm/mgag200: Pin framebuffer BO during dirty update > >> > >> > >> I tried reverting them and the resultant driver doesn’t build afterwards due to drm calls. > >> > >> If I build a kernel from : > >> > >> fec88ab0af97 2019-07-14 | Merge tag 'for-linus-hmm' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma > >> > >> That is posted day prior to be8454afc50f - the GNOME desktop works. > > > > I thought I could reproduce the problem, but I'm not so sure now. > > > > Please bisect the range between the two merges as described by Daniel to > > find the broken commit. Doing > > > > git bisect start > > git bisect bad be8454afc50f > > git bisect good fec88ab0af97 > > > > should start the session. > > > In short . I started with : > > git bisect start > > git bisect bad be8454afc50f > > git bisect good fec88ab0af97 > > And at the the end of bisects showed this was the offending commit : > > c0a74c732568 > > commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) > Author: Jani Nikula <jani.nikula@intel.com> > Date: Fri May 24 20:35:22 2019 +0300 > > drm/i915: Update DRIVER_DATE to 20190524 > > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > > That does not have any real relevance > > > I am not sure if I did the bisects correctly . After each test I did : > > > #1 git bisect bad 827440a90146 > > #2 git bisect bad f5b07b04e5f0 > > #3 git bisect bad c0a74c732568 > > #4 git bisect good 818f5cb3e8fb > > #5 git bisect good 6cfe7ec02e85 > > #6 git bisect good f71e01a78bee > > #7 git bisect good 09a93ef3d60f > > #8 git bisect good f1e6b336bafa > > #9 git bisect good eaf20e6933dc > > #10 git bisect good 63e8dcdb4f8e > > #11 git bisect good 397049a03022 > > I’ve restarted the bisect without appending the <commit-id> after a the “bad|good “ , and so far git is showing the same selections. Well you're saying that c0a74c732568 is bad and that 397049a03022702defa65694c23 (its immediate ancestor) is good, so clearly c0a74 is the bad commit per your test results. If this is correct (please retest to make sure) then git bisect is pointing at the right commit. If not, then you did a mixup somewhere in your testing. It could also be that there's a timing change, but given that the bisected commit has no real code change that should be impossible. btw for testing it's good to enable CONFIG_LOCALVERSION_AUTO, then you can double-check the sha1 of the commit you're testing before running git bisect good/bad. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-12 19:13 ` John Donnelly 2019-11-12 20:14 ` Daniel Vetter @ 2019-11-13 8:17 ` Thomas Zimmermann 2019-11-13 17:42 ` John Donnelly 1 sibling, 1 reply; 20+ messages in thread From: Thomas Zimmermann @ 2019-11-13 8:17 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, allen [-- Attachment #1.1.1: Type: text/plain, Size: 2322 bytes --] Hi John Am 12.11.19 um 20:13 schrieb John Donnelly: > > In short . I started with : > > git bisect start > > git bisect bad be8454afc50f > > git bisect good fec88ab0af97 > > And at the the end of bisects showed this was the offending commit : > > c0a74c732568 > > commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) > Author: Jani Nikula <jani.nikula@intel.com> > Date: Fri May 24 20:35:22 2019 +0300 > > drm/i915: Update DRIVER_DATE to 20190524 > > Signed-off-by: Jani Nikula <jani.nikula@intel.com> > > That does not have any real relevance No, that doesn't look right. The other bad commits you list below also don't seem to be related. You could also bisect between your original working commit (v4.18?) and the one you want to upgrade to (v5.3?). It's only a few more builds but might be might give better results. BTW, are you also converting Gnome from X11 to Wayland. I found that Gnome's Wayland code is so slow on mgag200 that it's unusable. They recently added a shadow FB [1] to improve performance, but it won't be available before Gnome 3.36. Best regards Thomas [1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/877/diffs > > > I am not sure if I did the bisects correctly . After each test I did : > > > #1 git bisect bad 827440a90146 > > #2 git bisect bad f5b07b04e5f0 > > #3 git bisect bad c0a74c732568 > > #4 git bisect good 818f5cb3e8fb > > #5 git bisect good 6cfe7ec02e85 > > #6 git bisect good f71e01a78bee > > #7 git bisect good 09a93ef3d60f > > #8 git bisect good f1e6b336bafa > > #9 git bisect good eaf20e6933dc > > #10 git bisect good 63e8dcdb4f8e > > #11 git bisect good 397049a03022 > > I’ve restarted the bisect without appending the <commit-id> after a the “bad|good “ , and so far git is showing the same selections. > > > > > > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 159 bytes --] _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-13 8:17 ` Thomas Zimmermann @ 2019-11-13 17:42 ` John Donnelly 2019-11-13 19:44 ` John Donnelly 2019-11-13 20:06 ` Daniel Vetter 0 siblings, 2 replies; 20+ messages in thread From: John Donnelly @ 2019-11-13 17:42 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen Hi Thomas: See below > On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > Hi John > > Am 12.11.19 um 20:13 schrieb John Donnelly: >> >> In short . I started with : >> >> git bisect start >> >> git bisect bad be8454afc50f >> >> git bisect good fec88ab0af97 >> >> And at the the end of bisects showed this was the offending commit : >> >> c0a74c732568 >> >> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >> Author: Jani Nikula <jani.nikula@intel.com> >> Date: Fri May 24 20:35:22 2019 +0300 >> >> drm/i915: Update DRIVER_DATE to 20190524 >> >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >> >> That does not have any real relevance > > No, that doesn't look right. The other bad commits you list below also > don't seem to be related. Thank you for your patience ; I started over and the bisect took to me to this change that certainly reflects the behavior I am seeing : commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Tue May 21 13:08:29 2019 +0200 drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin The push-to-system function forces a buffer out of video RAM. This decision should rather be made by the memory manager. By replacing the function with calls to the kunmap and unpin functions, the buffer's memory becomes available, but the buffer remains in VRAM until it's evicted by a pin operation. This patch replaces the remaining instances of drm_gem_vram_push_to_system() in ast and mgag200, and removes the function from DRM. My 1st impression is we need a method that restores the previous behavior that pushes the content to the device . > > You could also bisect between your original working commit (v4.18?) and > the one you want to upgrade to (v5.3?). It's only a few more builds but > might be might give better results. > > BTW, are you also converting Gnome from X11 to Wayland. I found that > Gnome's Wayland code is so slow on mgag200 that it's unusable. They > recently added a shadow FB [1] to improve performance, but it won't be > available before Gnome 3.36. I found this issue using gnome-desktop3-3.28.2-1.el8.x86_64 If there is a more specific. RPM I can look at for guidance I will . > > Best regards > Thomas > > [1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/877/diffs > >> >> >> I am not sure if I did the bisects correctly . After each test I did : >> >> >> #1 git bisect bad 827440a90146 >> >> #2 git bisect bad f5b07b04e5f0 >> >> #3 git bisect bad c0a74c732568 >> >> #4 git bisect good 818f5cb3e8fb >> >> #5 git bisect good 6cfe7ec02e85 >> >> #6 git bisect good f71e01a78bee >> >> #7 git bisect good 09a93ef3d60f >> >> #8 git bisect good f1e6b336bafa >> >> #9 git bisect good eaf20e6933dc >> >> #10 git bisect good 63e8dcdb4f8e >> >> #11 git bisect good 397049a03022 >> >> I’ve restarted the bisect without appending the <commit-id> after a the “bad|good “ , and so far git is showing the same selections. ======== snip ======== _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-13 17:42 ` John Donnelly @ 2019-11-13 19:44 ` John Donnelly 2019-11-13 20:06 ` Daniel Vetter 1 sibling, 0 replies; 20+ messages in thread From: John Donnelly @ 2019-11-13 19:44 UTC (permalink / raw) To: Thomas Zimmermann; +Cc: dri-devel, allen > On Nov 13, 2019, at 11:42 AM, John Donnelly <john.p.donnelly@oracle.com> wrote: > > Hi Thomas: See below > >> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >> >> Hi John >> >> Am 12.11.19 um 20:13 schrieb John Donnelly: >>> >>> In short . I started with : >>> >>> git bisect start >>> >>> git bisect bad be8454afc50f >>> >>> git bisect good fec88ab0af97 >>> >>> And at the the end of bisects showed this was the offending commit : >>> >>> c0a74c732568 >>> >>> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >>> Author: Jani Nikula <jani.nikula@intel.com> >>> Date: Fri May 24 20:35:22 2019 +0300 >>> >>> drm/i915: Update DRIVER_DATE to 20190524 >>> >>> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >>> >>> That does not have any real relevance >> >> No, that doesn't look right. The other bad commits you list below also >> don't seem to be related. > > > > Thank you for your patience ; I started over and the bisect took to me to this change that certainly reflects the behavior I am seeing : > > commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) > Author: Thomas Zimmermann <tzimmermann@suse.de> > Date: Tue May 21 13:08:29 2019 +0200 > > drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin > > The push-to-system function forces a buffer out of video RAM. This decision > should rather be made by the memory manager. By replacing the function with > calls to the kunmap and unpin functions, the buffer's memory becomes available, > but the buffer remains in VRAM until it's evicted by a pin operation. > > This patch replaces the remaining instances of drm_gem_vram_push_to_system() > in ast and mgag200, and removes the function from DRM. > > > My 1st impression is we need a method that restores the previous behavior that pushes the content to the device . It appears many of the code changes that were involved in 81da87f63a1 ( above ) have been superseded by : commit 5d17718997367c435dbe5341a8e270d9b19478d3 Author: Thomas Zimmermann <tzimmermann@suse.de> Date: Thu Jun 27 10:09:09 2019 +0200 drm/mgag200: Replace struct mga_framebuffer with GEM framebuffer helpers Are there any other methods (tools ) you could recommend outside of starting Gnome that I could use to get a display activity shown on the console ? ===. snipped === _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-13 17:42 ` John Donnelly 2019-11-13 19:44 ` John Donnelly @ 2019-11-13 20:06 ` Daniel Vetter 2019-11-13 21:34 ` John Donnelly 1 sibling, 1 reply; 20+ messages in thread From: Daniel Vetter @ 2019-11-13 20:06 UTC (permalink / raw) To: John Donnelly; +Cc: dri-devel, Thomas Zimmermann, allen On Wed, Nov 13, 2019 at 6:42 PM John Donnelly <john.p.donnelly@oracle.com> wrote: > > Hi Thomas: See below > > > On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: > > > > Hi John > > > > Am 12.11.19 um 20:13 schrieb John Donnelly: > >> > >> In short . I started with : > >> > >> git bisect start > >> > >> git bisect bad be8454afc50f > >> > >> git bisect good fec88ab0af97 > >> > >> And at the the end of bisects showed this was the offending commit : > >> > >> c0a74c732568 > >> > >> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) > >> Author: Jani Nikula <jani.nikula@intel.com> > >> Date: Fri May 24 20:35:22 2019 +0300 > >> > >> drm/i915: Update DRIVER_DATE to 20190524 > >> > >> Signed-off-by: Jani Nikula <jani.nikula@intel.com> > >> > >> That does not have any real relevance > > > > No, that doesn't look right. The other bad commits you list below also > > don't seem to be related. > > > > Thank you for your patience ; I started over and the bisect took to me to this change that certainly reflects the behavior I am seeing : > > commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) > Author: Thomas Zimmermann <tzimmermann@suse.de> > Date: Tue May 21 13:08:29 2019 +0200 > > drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin > > The push-to-system function forces a buffer out of video RAM. This decision > should rather be made by the memory manager. By replacing the function with > calls to the kunmap and unpin functions, the buffer's memory becomes available, > but the buffer remains in VRAM until it's evicted by a pin operation. > > This patch replaces the remaining instances of drm_gem_vram_push_to_system() > in ast and mgag200, and removes the function from DRM. Yeah that looks a lot more plausible as the culprit. > My 1st impression is we need a method that restores the previous behavior that pushes the content to the device . Can you pls grab the debugsfs for the above broken kernel (without any of the later reworks on top), both for console mode and after you started gnome. Plus I guess booting with drm.debug=0xfe and full dmesg (please note the timestamp when you started gnome, that helps with sifting through it all, it's going to be a lot). You might need to grab the full dmesg from logs on disk, please make sure it includes everything from boot-up. Thanks, Daniel > > > > > > > > You could also bisect between your original working commit (v4.18?) and > > the one you want to upgrade to (v5.3?). It's only a few more builds but > > might be might give better results. > > > > BTW, are you also converting Gnome from X11 to Wayland. I found that > > Gnome's Wayland code is so slow on mgag200 that it's unusable. They > > recently added a shadow FB [1] to improve performance, but it won't be > > available before Gnome 3.36. > > > I found this issue using > > gnome-desktop3-3.28.2-1.el8.x86_64 > > If there is a more specific. RPM I can look at for guidance I will . > > > > > > Best regards > > Thomas > > > > [1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/877/diffs > > > >> > >> > >> I am not sure if I did the bisects correctly . After each test I did : > >> > >> > >> #1 git bisect bad 827440a90146 > >> > >> #2 git bisect bad f5b07b04e5f0 > >> > >> #3 git bisect bad c0a74c732568 > >> > >> #4 git bisect good 818f5cb3e8fb > >> > >> #5 git bisect good 6cfe7ec02e85 > >> > >> #6 git bisect good f71e01a78bee > >> > >> #7 git bisect good 09a93ef3d60f > >> > >> #8 git bisect good f1e6b336bafa > >> > >> #9 git bisect good eaf20e6933dc > >> > >> #10 git bisect good 63e8dcdb4f8e > >> > >> #11 git bisect good 397049a03022 > >> > >> I’ve restarted the bisect without appending the <commit-id> after a the “bad|good “ , and so far git is showing the same selections. > > > ======== snip ======== > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics 2019-11-13 20:06 ` Daniel Vetter @ 2019-11-13 21:34 ` John Donnelly 0 siblings, 0 replies; 20+ messages in thread From: John Donnelly @ 2019-11-13 21:34 UTC (permalink / raw) To: Daniel Vetter; +Cc: dri-devel, Thomas Zimmermann, allen > On Nov 13, 2019, at 2:06 PM, Daniel Vetter <daniel@ffwll.ch> wrote: > > On Wed, Nov 13, 2019 at 6:42 PM John Donnelly > <john.p.donnelly@oracle.com> wrote: >> >> Hi Thomas: See below >> >>> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann@suse.de> wrote: >>> >>> Hi John >>> >>> Am 12.11.19 um 20:13 schrieb John Donnelly: >>>> >>>> In short . I started with : >>>> >>>> git bisect start >>>> >>>> git bisect bad be8454afc50f >>>> >>>> git bisect good fec88ab0af97 >>>> >>>> And at the the end of bisects showed this was the offending commit : >>>> >>>> c0a74c732568 >>>> >>>> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad) >>>> Author: Jani Nikula <jani.nikula@intel.com> >>>> Date: Fri May 24 20:35:22 2019 +0300 >>>> >>>> drm/i915: Update DRIVER_DATE to 20190524 >>>> >>>> Signed-off-by: Jani Nikula <jani.nikula@intel.com> >>>> >>>> That does not have any real relevance >>> >>> No, that doesn't look right. The other bad commits you list below also >>> don't seem to be related. >> >> >> >> Thank you for your patience ; I started over and the bisect took to me to this change that certainly reflects the behavior I am seeing : >> >> commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad) >> Author: Thomas Zimmermann <tzimmermann@suse.de> >> Date: Tue May 21 13:08:29 2019 +0200 >> >> drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin >> >> The push-to-system function forces a buffer out of video RAM. This decision >> should rather be made by the memory manager. By replacing the function with >> calls to the kunmap and unpin functions, the buffer's memory becomes available, >> but the buffer remains in VRAM until it's evicted by a pin operation. >> >> This patch replaces the remaining instances of drm_gem_vram_push_to_system() >> in ast and mgag200, and removes the function from DRM. > > Yeah that looks a lot more plausible as the culprit. > >> My 1st impression is we need a method that restores the previous behavior that pushes the content to the device . > > Can you pls grab the debugsfs for the above broken kernel (without any > of the later reworks on top), both for console mode and after you > started gnome. Plus I guess booting with drm.debug=0xfe and full dmesg > (please note the timestamp when you started gnome, that helps with > sifting through it all, it's going to be a lot). You might need to > grab the full dmesg from logs on disk, please make sure it includes > everything from boot-up. > > Thanks, Daniel Hi I started a Bugzilla https://bugs.freedesktop.org/show_bug.cgi?id=112265 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2019-11-13 21:36 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-07 2:29 Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics John Donnelly
2019-11-07 7:54 ` Thomas Zimmermann
2019-11-07 13:12 ` John Donnelly
2019-11-07 13:42 ` Thomas Zimmermann
2019-11-07 16:13 ` John Donnelly
2019-11-07 22:14 ` John Donnelly
2019-11-08 7:46 ` Thomas Zimmermann
[not found] ` <81D853E0-34F0-4894-B692-7E560AC2D9A1@oracle.com>
2019-11-08 15:06 ` Thomas Zimmermann
2019-11-08 18:07 ` John Donnelly
2019-11-08 19:10 ` Daniel Vetter
2019-11-11 15:57 ` Thomas Zimmermann
2019-11-11 17:40 ` John Donnelly
2019-11-12 10:02 ` Thomas Zimmermann
2019-11-12 19:13 ` John Donnelly
2019-11-12 20:14 ` Daniel Vetter
2019-11-13 8:17 ` Thomas Zimmermann
2019-11-13 17:42 ` John Donnelly
2019-11-13 19:44 ` John Donnelly
2019-11-13 20:06 ` Daniel Vetter
2019-11-13 21:34 ` John Donnelly
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.