[bug] Slackware 15.0 : nomodeset causes elogind to crash

BernieK · 06-03-2022, 04:55 PM

After installing Slackware Linux 15.0 I added the following record to /etc/lilo.conf with the hope of getting the console to fully utilize my monitor's resolution rather than squishing text into only the upper left corner of the monitor:

Code:

append = " nomodeset "

Including nomodeset as a kernel boot-argument fixed the monitor real-estate utilization problem, but broke elogind - which crashes 2-3 seconds after presenting a login prompt on the console, thereby preventing further interaction with the machine until rebooting without the nomodeset argument.

The same console's resolution was fully-utilized thru Slackware 14.2 on the same machine without kernel/boot arguments regardless of the selected console font.

Debugging suggestions are welcome.

- BernieK

Missing the days when Slackware felt like a Unix cousin. Days without HAL (dbus, udev, freedesktop), PAM, PolicyKit, sudo, systemd (or extracts thereof), Wayland (or any "Display Manager"), cgroups or containers. Days when the pieces were not tightly coupled.

zeebra · 06-11-2022, 03:43 AM

Quote:

Originally Posted by BernieK

After installing Slackware Linux 15.0 I added the following record to /etc/lilo.conf with the hope of getting the console to fully utilize my monitor's resolution rather than squishing text into only the upper left corner of the monitor:

Code:

append = " nomodeset "

So, what is your graphics card?

You can't run nomodeset with Intel graphics for example.

BernieK · 06-11-2022, 02:14 PM

Quote:

Originally Posted by zeebra

So, what is your graphics card?
You can't run nomodeset with Intel graphics for example.

Thank you for the notice regarding Intel graphics and the kernel/boot "nomodeset" argument.

Information regarding the video hardware on my Slackware 15.0 box follows:

Chipset: AMD M880G (codename RS880)
Integrated Graphics: ATI Mobility Radeon HD 4200 series (Radeon HD 4250)

From Xorg log:

Code:

[    37.053] (--) RADEON(0): Chipset: "ATI Mobility Radeon HD 4200" (ChipID = 0x9712)
        .        .        .
        .        .        .
[    39.587] (II) RADEON(0): glamor X acceleration enabled on AMD RS880 (DRM 2.50.0 / 5.15.38, LLVM 13.0.0)

From dmesg (without the "nomodeset" kernel/boot argument):

Code:

[   10.131847] [drm] radeon kernel modesetting enabled.
[   10.132201] radeon 0000:01:05.0: vgaarb: deactivate vga console
[   10.132840] Console: switching to colour dummy device 80x25
[   10.133539] [drm] initializing kernel modesetting (RS880 0x1002:0x9712 0x103C:0x3642 0x00).
[   10.133638] resource sanity check: requesting [mem 0x000c0000-0x000dffff], which spans more than PCI Bus 0000:00 [mem 0x000c0000-0x000c3fff window]
[   10.133665] caller pci_map_rom+0x79/0x1d0 mapping multiple BARs
[   10.135021] hid: raw HID events driver (C) Jiri Kosina
[   10.135774] ATOM BIOS: HP_Rachman20
[   10.135828] radeon 0000:01:05.0: VRAM: 320M 0x00000000C0000000 - 0x00000000D3FFFFFF (320M used)
[   10.135850] radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[   10.135879] [drm] Detected VRAM RAM=320M, BAR=256M
[   10.135889] [drm] RAM width 32bits DDR
[   10.135968] [drm] radeon: 320M of VRAM memory ready
[   10.135979] [drm] radeon: 512M of GTT memory ready
        .        .        .
        .        .        .
[   10.232386] [drm] radeon: power management initialized
[   10.233547] [drm] GART: num cpu pages 131072, num gpu pages 131072
[   10.251322] [drm] PCIE GART of 512M enabled (table at 0x00000000C0146000).
[   10.251431] radeon 0000:01:05.0: WB enabled
[   10.251446] radeon 0000:01:05.0: fence driver on ring 0 use gpu addr 0x00000000a0000c00
[   10.254801] radeon 0000:01:05.0: fence driver on ring 5 use gpu addr 0x00000000c0056038
[   10.255078] radeon 0000:01:05.0: radeon: MSI limited to 32-bit
[   10.255113] [drm] radeon: irq initialized.
        .        .        .
        .        .        .
[   11.130523] [drm] ib test on ring 5 succeeded
[   11.131372] [drm] radeon atom DIG backlight initialized
        .        .        .
        .        .        .
[   11.977469] fbcon: radeondrmfb (fb0) is primary device
[   12.021614] Console: switching to colour frame buffer device 160x50
[   12.032548] radeon 0000:01:05.0: [drm] fb0: radeondrmfb frame buffer device
[   12.046976] [drm] Initialized radeon 2.50.0 20080528 for 0000:01:05.0 on minor 0

zeebra · 06-13-2022, 02:12 AM

Quote:

Originally Posted by BernieK

Information regarding the video hardware on my Slackware 15.0 box follows:

Chipset: AMD M880G (codename RS880)
Integrated Graphics: ATI Mobility Radeon HD 4200 series (Radeon HD 4250)

I don't really know much about ATI/AMD and Nvidia these days. But if I'm not mistaken it depends on the driver, that you're suppose to or have to run modesetting with the free AMD driver. Maybe the proprietary one as well...
In any case, it seems your driver does use modeset when it is enabled which indicates it should be used. So perhaps you're tacking this problem the wrong way?

Maybe it should be something like "when using modeset" on my graphics card, resolution does so and so, how can I get resolution to behave so and so instead..

BernieK · 07-22-2022, 06:17 PM

Thank you for suggesting I address the display real-estate utilization problem differently (and thus necessarily without using the "nomodeset" kernel boot-argument given the noted elogind bug). A solution is posted. (ref. https://www.linuxquestions.org/quest...ge-4175714770/ )

Regarding the problem expressed as this thread's title; When elogind crashes as a result of the "nomodeset" kernel boot-argument being used it leaves the system inaccessible via a local shell.

elcore · 09-07-2022, 06:38 AM

Well if you don't use kde or xfce4 desktop, you can basically just discard elogind.
Note that official procps-ng-3.3.17 package may break without elogind library, so I'd just go ahead and rebuild procps-ng:

Code:

--disable-elogind \

I mean if the compile flag is there, it's probably there for a reason.
Otherwise, I've not found anything else in Slackware v15 which hard-depends on elogind.

And TBH, it's really not elogind library job to decide whether or not you're gonna use nomodeset, not sure how kernel parameter's even relevant for that library.
So if it breaks with nomodeset (I have not bothered to test), then it's elogind problem or (even more likely) a systemd-logind problem.