Hi Larry, could you attach a sosreport from a system that had such an error? There's not much to go on right now, so we'll need this as a first step for our investgation

Created attachment 1904315 [details]
failing system SOS report

Hello Niels,

A sos report has been attached to this case.  Let me know if you need any additional information.

I have found a second system type that has this same core dump issue with the monitor-edid tools. The only difference in behavior is that the system does not crash, but the monitor-edid utility still core dumps in the same manner.   The second system type is a brand new ASUS "KMPP-D32 Series" board that uses an integrated video controller.

Looking at the two systems that experience this problem, they have the same OS configuration (although the kernel is now at 5.14.0-183.el9.x86_64) but the common thread now appears to be the integrated video controller.   Here is the "lshw" output of the display properties for both of the systems that experience the problem:

ASUS motherboard  "KMPP-D32 Series"

 *-display
      description: VGA compatible controller
      product: ASPEED Graphics Family
      vendor: ASPEED Technology, Inc.
      physical id: 0
      bus info: pci@0000:62:00.0
      logical name: /dev/fb0
      version: 52
      width: 32 bits
      clock: 33MHz
      capabilities: pm msi vga_controller bus_master cap_list rom fb
      configuration: depth=32 driver=ast latency=0 resolution=1024,768
      resources: irq:158 memory:c8000000-cbffffff memory:cc000000-cc03ffff ioport:8000(size=128) memory:c0000-dffff



Supermicro X10 

*-display
     description: VGA compatible controller
     product: ASPEED Graphics Family
     vendor: ASPEED Technology, Inc.
     physical id: 0
     bus info: pci@0000:07:00.0
     logical name: /dev/fb0
     version: 30
     width: 32 bits
     clock: 33MHz
     capabilities: pm msi vga_controller cap_list rom fb
     configuration: depth=32 driver=ast latency=0 resolution=1024,768
     resources: irq:18 memory:fa000000-faffffff memory:fb000000-fb01ffff ioport:d000(size=128) memory:c0000-dffff

One other detail to add - both of the the systems that the problem occurs on normally run without any physical monitor attached.  I noticed that if I boot the system with a physical monitor attached, "monitor-edid" still core dumps, but it does generate seemingly accurate monitor status before it crashes.   This only occurs if a monitor is attached at system boot time, attaching a monitor while the system is running results in a core dump with no output.

Hi, 

I tried to reproduce the issue on a server with Aspeed graphics (AST2600).
I only have remote access, and it looks there are nothing connected to VGA.

running monitor-edid returns nothing and it doesn't crash.
I tested with 5.14.0-226.el9.x86_64, I will try next week with an older kernel to see if I can reproduce something.

Normally monitor-edid, only read the edid data in /sys/class/drm/card0/card0-VGA-1/edid

so can you try if only doing this will crash your machine ?
cat /sys/class/drm/card0/card0-VGA-1/edid > /tmp/edid.bin

Hello,

I updated my systems to kernel 5.14.0-226.el9.x86_64, and the behavior of the problem has indeed changed a bit, but is consistent across both the two hardware types I have seen the problem on.


The problem behavior now on kernel 5.14.0.-226.el9.x86_64:

- cat /sys/class/drm/card0/card0-VGA-1/edid
  No errors or crashes, returns normally

- /usr/sbin/monitor-edid
  On both the older (AST2400, Supermicro X10 board) and newer (AST2600, Asus KMPP-D32 board) this command now returns normally - with no output.  No core dump or system freeze.

- /usr/sbin/monitor-get-edid-using-vbe
  On the older system (AST2400, Supermicro X10 board):  core dump followed shortly by system freeze.
  
  On the newer system (AST2600, Asus KMPP-D32 board):  core dump, but no system freeze.


I have attached "strace" output from the monitor-get-edid-using-vbe command for both systems.

Thanks,

Larry

Created attachment 1936303 [details]
strace output from system using ast2400 video

Created attachment 1936304 [details]
strace output from system with AST2600 video

ok, thanks for your reactivity.

I just read about vbe and EDID.

It looks like vbe is only available when booting in BIOS mode, it cannot work with UEFI.
https://wiki.osdev.org/Getting_VBE_Mode_Info

The strace shows that it tries to directly access /dev/mem, and looking for VBE address.
But if you booted in UEFI mode, this memory is used for something else, and that's probably why it crashes.

If you can confirm the machine are booting in UEFI mode, that can explain the crash.

Both systems that have the problem are definitely booted in BIOS mode, which is the default mode for both servers.

I've made a few try, but the server I use boot in UEFI mode, and I can't change it back to BIOS.

#monitor-get-edid-using-vbe -v
VBE: Error (0x4f00): 0x4f00

I get this error, but it doesn't crash the machine.

Anyway, monitor-get-edid-using-vbe doesn't use the aspeed kernel driver. It accesses directly the hardware by using /dev/mem, and calling some BIOS interrupt.
So in this case the error is either a bug in monitor-get-edid-using-vbe, or a buggy BIOS implementation. In both cases I won't be able to help much.

Other have reported hard freeze in UEFI mode, in the monitor-get-edid bug tracker:
https://bugs.mageia.org/show_bug.cgi?id=28124

If you agree, we can close this bug, as monitor-edid is now working, and monitor-get-edid-using-vbe is not using the aspeed kernel driver.

I would prefer to keep this bug open, as it affects multiple vendors and hardware platforms.  If there is any additional information I can gather that would assist you in troubleshooting the issue, please let me know.

A third system type that the problem occurs on is: Supermicro X11SPW-CTF, which uses an ASPEED AST-2500 integrated video controller.

This system operates in BIOS boot mode, and is using the latest BIOS version from the OEM, version 3.8a, 10/22/2022.

Executing /usr/sbin/monitor-get-edid-using-vbe produces a core dump, but no system freeze.

Maybe one thing you can try, is to blacklist the ast kernel driver.

The kernel will fallback to vesafb, so you will still have graphics.
The drawback is that you won't be able to change the resolution.

Normally vesafb won't change the cards settings, thus the BIOS calls used by monitor-get-edid-using-vbe might still work.

I did try blacklisting the ast driver on one system, but that resulted in no video driver at all from loading:

lshw shows no video hardware or driver
/sys/class/drm/card0  - path not present


But yes, with no video driver loaded, the "monitor-get-edid-using-vbe" does not coredump :)

You still have a video driver, it's not a "DRM" driver but a "FB" (older kernel interface for graphic cards).

you should have a /dev/fb0 in this case.

So I think the BIOS is not buggy after all.

The root cause is that the ast driver configures the card for its own usage, so the configuration and memory mapping from the BIOS is no longer valid.

VBE interface is normally intended for bootloader, or system fallback drivers (like vesafb). It should not be used by userspace program like this.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.