* 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
* 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.