Skip to content

amdgpu glamor: fix module loading when linked with '-z now' - #62

Draft
cepelinas9000 wants to merge 1 commit into
X11Libre:masterfrom
cepelinas9000:pr/znowfix
Draft

amdgpu glamor: fix module loading when linked with '-z now'#62
cepelinas9000 wants to merge 1 commit into
X11Libre:masterfrom
cepelinas9000:pr/znowfix

Conversation

@cepelinas9000

@cepelinas9000 cepelinas9000 commented Jun 25, 2026

Copy link
Copy Markdown

draft for now, until figure out problem:

[2026-06-25 14:06:59] (II) modeset(0): Async flip capable
[2026-06-25 14:06:59] (EE) modeset(G0): drmSetMaster failed: Device or resource busy
[2026-06-25 14:06:59] 
Fatal server error:
[2026-06-25 14:06:59] AddScreen/ScreenInit failed for gpu driver 0 -1

because on failure - it load modesetting drivers and user have working session.

Tautvydas @cepelinas9000
amdgpu glamor: fix module loading when linked with '-z now'
03792b7 
This patch explicitly loads the glamoregl, shadowfb submodules and manually dereferences the required library calls.
This is necessary because recent compilers and distribution maintainers (e.g., Gentoo, which includes a GCC patch for
this behavior, example at https://github.com/gentoo/gcc-patches/blob/master/16.1.0/gentoo/23_all_DEF_GENTOO_ZNOW-z-now.patch) -
force all shared library symbols to be bound at load time, effectively ignoring the DT_LAZY flag.

Signed-off-by: Tautvis <gtautvis@gmail.com>
@stefan11111

stefan11111 commented Jun 25, 2026 •
edited
Loading

Copy link
Copy Markdown

draft for now, until figure out problem:

[2026-06-25 14:06:59] (II) modeset(0): Async flip capable
[2026-06-25 14:06:59] (EE) modeset(G0): drmSetMaster failed: Device or resource busy
[2026-06-25 14:06:59] 
Fatal server error:
[2026-06-25 14:06:59] AddScreen/ScreenInit failed for gpu driver 0 -1

because on failure - it load modesetting drivers and user have working session.

Pretty sure that is a problem of no xorg.conf

With no xorg.conf, the X server tries multiple drivers, they find the same devices, and conflict in initialization.
Since the X server has no fallback mechanism if ScreenInit fails, the entire X server goes down.

@metux @ONykyf ping

@cepelinas9000

cepelinas9000 commented Jun 25, 2026

Copy link
Copy Markdown
Author

draft for now, until figure out problem:

[2026-06-25 14:06:59] (II) modeset(0): Async flip capable
[2026-06-25 14:06:59] (EE) modeset(G0): drmSetMaster failed: Device or resource busy
[2026-06-25 14:06:59] 
Fatal server error:
[2026-06-25 14:06:59] AddScreen/ScreenInit failed for gpu driver 0 -1

because on failure - it load modesetting drivers and user have working session.

Pretty sure that is a problem of no xorg.conf

With no xorg.conf, the X server tries multiple drivers, they find the same devices, and conflict in initialization. Since the X server has no fallback mechanism if ScreenInit fails, the entire X server goes down.

@metux @ONykyf ping

The problem is: amdgpu driver do not claim device during probe, then when modesetting drivers probes it sees as free device and claims it. Then both drivers loads

stefan11111
stefan11111 reviewed Jun 25, 2026
View reviewed changes
Comment thread src/amdgpu_kms.c
}

static bool
load_shadowfd(ScrnInfoPtr pScrn){

@stefan11111 stefan11111 Jun 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/fd/fb/ ?

@stefan11111

stefan11111 commented Jun 25, 2026

Copy link
Copy Markdown

The problem is: amdgpu driver do not claim device during probe, then when modesetting drivers probes it sees as free device and claims it. Then both drivers loads

Does the amdgpu driver only probe devices with the fallback probe?

When using the pci probe or the platform probe, the X server should claim slots by itself.

@cepelinas9000

cepelinas9000 commented Jun 25, 2026

Copy link
Copy Markdown
Author

The problem is: amdgpu driver do not claim device during probe, then when modesetting drivers probes it sees as free device and claims it. Then both drivers loads

Does the amdgpu driver only probe devices with the fallback probe?

When using the pci probe or the platform probe, the X server should claim slots by itself.

Debugged little while ago, the fallback probe is NULL( DriverRec->Probe). It was pci probe or the platform probe didn't claim slot.

@cepelinas9000 cepelinas9000 mentioned this pull request Jul 2, 2026
Merged
@metux metux mentioned this pull request Jul 7, 2026
Open
@josephcrowell

josephcrowell commented Jul 10, 2026

Copy link
Copy Markdown
Collaborator

Will this be solved xserver side? What causes NULL( DriverRec->Probe) and probe not to claim slot?

@stefan11111

stefan11111 commented Jul 10, 2026

Copy link
Copy Markdown

Will this be solved xserver side? What causes NULL( DriverRec->Probe) and probe not to claim slot?

I doubt this will solve that issue. The point of this patch is to get the module to work when built without lazy-loading.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@stefan11111 stefan11111 stefan11111 left review comments
@josephcrowell josephcrowell Awaiting requested review from josephcrowell

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@cepelinas9000 @stefan11111 @josephcrowell