Bug 28124

Thank you for this detailed report, Martin.

Neither SRPM has a regular maintainer, so have to assign this globally.

Assignee: bugsquad => pkg-bugs
Source RPM: monitor-edid-3.3-1.mga8 => monitor-edid-3.3-1.mga8, libx86-1.1-37.mga8.src.rpm

is this on real hw or virtualbox ?

interestingly I cant get it to crash here on wayland

I do get the:
monitor-get-edid-using-vbe triggered

  mmap /dev/zero: Operation not permitted

but it does not hit the   "VBE: could not initialize LRMI" path...

but then again monitor-edid actually gets edid output as it should...

do you get any edid output at all ? or does this only trigger on hw that does not output edid data ?

(In reply to Thomas Backlund from comment #2)
> is this on real hw or virtualbox ?

Both

> interestingly I cant get it to crash here on wayland

Try

  monitor-get-edid-using-vbe -v

for the "VBE: could not initialize LRMI" then

  monitor-get-edid-using-vbe -v --try-in-console

to lose your gnome-session. If you want to try for the system freeze, do

  mount -o remount,exec /dev

first. For me it could take anywhere from a few seconds to a minute for the system to freeze (so I didn't immediately realise what was causing it).

> do you get any edid output at all ? or does this only trigger on hw that
> does not output edid data ?

Using monitor-edid it triggers if either

  - it doesn't find the edid info in /sys/class/drm/card*
  - you run it as root and don't specify the --first option

(In reply to Martin Whitaker from comment #3)
> (In reply to Thomas Backlund from comment #2)
> > is this on real hw or virtualbox ?
> 
> Both
> 
> > interestingly I cant get it to crash here on wayland
> 
> Try
> 
>   monitor-get-edid-using-vbe -v
> 
> for the "VBE: could not initialize LRMI" then
> 
>   monitor-get-edid-using-vbe -v --try-in-console
> 
> to lose your gnome-session. If you want to try for the system freeze, do

I dont lose it.
I get switched to gdm login, but can switch  back to my open session with Ctrl-Alt-F2

> 
>   mount -o remount,exec /dev
>

Not here. it still works on real hw.


I only get:
#   monitor-get-edid-using-vbe -v --try-in-console
VBE: Error (0x4f00): 0x4f00
VBE: Error (0x4f00): 0x4f00


but nothing hangs/freezes/...
 
> first. For me it could take anywhere from a few seconds to a minute for the
> system to freeze (so I didn't immediately realise what was causing it).
> 
> > do you get any edid output at all ? or does this only trigger on hw that
> > does not output edid data ?
> 
> Using monitor-edid it triggers if either
> 
>   - it doesn't find the edid info in /sys/class/drm/card*
>   - you run it as root and don't specify the --first option

Not here on real hw

I will try in vbox next...

Further testing shows that Ctrl-Alt-F2 will switch me back to a still-working session on one machine. On two others it takes me back to a blank screen which echoes key presses and has a movable mouse pointer (so a remnant of the original session with most of the processes dead). Ctrl-C will exit that, after which I'm able to start a new session from the GDM login screen.

The freeze only occurs on one machine. Oddly, that one does return sensible VBE information first. On a second machine the VBE requests time out, but have no observable side effects. On a third machine the VBE requests return sensible information and have no observable side effects.

So the freeze is probably due to a buggy BIOS.

Asus u31s is affected model.

dual graphics : intel 810 or later / nvidia390 drivers required

CC: (none) => westel

failure was triggered from MCC "set up the graphical server" 

never from terminal

To confuse things further...
Running on real hardware:
 $ inxi -SGxx
System:
  Host: localhost Kernel: 5.10.8-desktop-1.mga8 x86_64 bits: 64 
  compiler: gcc v: 10.2.1 Desktop: GNOME 3.38.3 tk: GTK 3.24.24 
  wm: gnome-shell dm: GDM, LightDM, LXDM Distro: Mageia 8 mga8 
Graphics:
  Device-1: AMD Wrestler [Radeon HD 7310] vendor: Acer Incorporated ALI 
  driver: radeon v: kernel bus ID: 00:01.0 chip ID: 1002:9809 
  Display: wayland server: Mageia X.org 1.20.10 compositor: gnome-shell 
  driver: ati,radeon,v4l resolution: 1366x768~60Hz s-dpi: 96 
  OpenGL: 
  renderer: AMD PALM (DRM 2.50.0 / 5.10.8-desktop-1.mga8 LLVM 11.0.1) 
  v: 3.3 Mesa 20.3.3 compat-v: 3.1 direct render: Yes 

I had previously run Gnome (GNOME menu entry, implies Wayland) via LightDM, and nothing failed except the old:
 $ sudo monitor-get-edid-using-vbe
 mmap /dev/zero: Operation not permitted
Ran drakx11 both via MCC and command line, all OK 'Test' included. Then I discovered that it was running X11...

Changed to GDM, re-booted, chose GNOME session; confirmed this time it *is* Wayland:
 $ echo $XDG_SESSION_TYPE
 wayland
 $ echo $WAYLAND_DISPLAY
 wayland-0
drakx11 1/2 worked, either from MCC or command line. It runs OK, but the 'Test'
showed a black screen. Fortunately that returned to the GUI after its timeout, no breakages.

CC: (none) => lewyssmith

@Lewis, when using GDM, what is the output from

  cat /sys/class/tty/tty0/active

and

  sudo monitor-get-edid-using-vbe -v --try-in-console

You just caught me before retiring! Your wish etc...
From Xfce-4 terminal under Gnome:

$ cat /sys/class/tty/tty0/active
tty2

$ sudo monitor-get-edid-using-vbe -v --try-in-console
[sudo] password for lewis: 
mmap /dev/zero: Operation not permitted
VBE: could not initialize LRMI
mmap /dev/zero: Operation not permitted
VBE: could not initialize LRMI

The screen went momentarily black (like the drakx11 test), then reverted to the GUI, then went all black. I did Ctrl/Alt/F1 and that gave me the GDM login screen. Giving the password, to my delight that restored the full session. More like a screenlock situation.

Yes, on some machines the GNOME session goes into an inactive state when monitor-get-edid-using-vbe switches to the console and is recoverable, on others machines it is not. Sometimes, if the switch to and from the console happens quickly enough, the GNOME session doesn't notice it, and you don't hit the bug.

Further tests on my machine with the keyboard/freeze problem show that it only occurs when booted in UEFI mode, not in legacy mode. The code that gets the EDID info via a BIOS call allocates a block of low memory for the returned data. My guess is that when booted in UEFI mode, it happens to hit a region of memory being used by the UEFI BIOS.

My suggestions for fixing the various issues exposed in this bug report are:

1. Don't use the --try-in-console option when calling monitor-edid from drakx tools. That fixes the issue with GDM+GNOME. Other DMs run the DE in vt1, so it is ignored anyway (plus monitor-get-edid-using-vbe hasn't been working for some years due to /dev being mounted without exec permissions).

2. Modify monitor-edid to not use monitor-get-edid-using-vbe when booted in UEFI mode (test for existence of /sys/firmware/efi).

3. Modify monitor-edid to look in /sys/class/drm/card* for EDID info before trying anything else.

4. Modify libx86 to not include exec permissions when mapping memory. I doubt either monitor-get-edid-using-vbe or vbetool really need exec permissions.

My box is EFI. Would not have dreamed it matters.

CC: lewyssmith => (none)

Closeing as fixed.

CC: (none) => davidwhodgins
Resolution: (none) => FIXED
Status: NEW => RESOLVED