Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jul 29 05:01
    grahamperrin commented #120
  • Jul 11 02:15
    mstoeckl commented #156
  • Jun 16 08:12
    jbeich commented #156
  • May 20 16:01

    evadot on master

    amdgpu: Move arcturus to the GF… (compare)

  • May 20 15:23
    evadot closed #18
  • May 20 15:23
    evadot commented #18
  • May 20 15:22

    evadot on cirrus

    (compare)

  • May 20 15:09

    evadot on master

    cirrus-ci: Test installing the … amdgpu: Only build dimgrey_cave… (compare)

  • May 20 15:01

    evadot on cirrus

    cirrus-ci: Test installing the … (compare)

  • May 20 14:52

    evadot on cirrus

    cirrus-ci: Test installing the … (compare)

  • May 20 14:26

    evadot on master

    amdgpu: Makefile: Sort green_sa… (compare)

  • May 20 14:18

    evadot on master

    amdgpu: Update firmware to matc… (compare)

  • May 20 14:08

    evadot on master

    amdgpu: Update firmware to matc… (compare)

  • May 17 06:50
    ivan-volnov commented #24
  • May 17 06:42
    evadot closed #24
  • May 17 06:42
    evadot commented #24
  • May 17 06:13
    ivan-volnov opened #24
  • May 11 17:27
    ivan-volnov commented #21
  • May 11 14:03
    evadot closed #21
  • May 11 14:03
    evadot commented #21
fbsdgitter
@fbsdgitter
[irc] <jfree> device=0x73df
[irc] <jfree> drm reports: "amdgpu kernel modesetting enabled", but X11 fails to modeset
fbsdgitter
@fbsdgitter
[irc] <jrm> tcberner: Thanks for keeping me in the loop. It was a holiday here too.
fbsdgitter
@fbsdgitter
[irc] <jfree> manu: Are you joining me and jrm at 19:00 CEST for GSoC meeting?
fbsdgitter
@fbsdgitter
[irc] <manu> jfree: will try but I'm not sure that I'll be able to attend this time
fbsdgitter
@fbsdgitter
[irc] <jfree> manu: Sounds good. Thanks
fbsdgitter
@fbsdgitter
[irc] <VVD> what versions of xorg supported by x11/nvidia-driver-340?
[irc] <VVD> look like last xorg update break compatibility with nvidia 340 (8xxx/9xxx/1xx/2xx/3xx)
[irc] <VVD> nothing in UPDATING
[irc] <VVD> Can work with: Option "IgnoreABI" "true"
fbsdgitter
@fbsdgitter
[irc] <VVD> What about pkg-message or/and UPDATING?
Alex
@shkhln
Well, "last xorg update" was 2 years ago: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244421.
I wouldn't expect any entries in UPDATING because there is nothing to update to.
fbsdgitter
@fbsdgitter
[irc] <manu> last xorg update was today
Alex
@shkhln
Noted, but that's not the first update that is incompatible with nvidia-driver-340.
fbsdgitter
@fbsdgitter
[irc] <VVD> shkhln, Current 1.20 is compatable with 340
Alex
@shkhln
I see.
304 is kind of too close 340.
Anyway, the advise is the same.
(First reply in that issue thread.)
If you really want to, you try patching 1.21 to use 1.20-compaitble ABI yourself.
  • can
Alex
@shkhln
Basically, find all xf86 symbols that the driver uses (say xf86SetWeight and so on). Look at Xorg's ABI changes. Make a wrapper (xfNvSetWeight, etc) for each changed function, patch the driver to use that symbol.
That could be very little work or it could be a lot of work.
Alex
@shkhln
(The are actually quite a few symbols without xf86 prefix, they need attention as well.)
unrelentingtech
@unrelentingtech:mozilla.org
[m]
jfree: "kernel modesetting enabled" is just the driver loading. hmmm yea looks like 5.10 only has Sienna_Cichlid (6800/XT/6900XT), but not Navy_Flounder
fbsdgitter
@fbsdgitter
[irc] <markj> jfree: one thing I note is that igt_install_exit_handler() installs a SIGSEGV handler. If I change it to not do that, the test passes. And I see that fatal_sig_handler() gets installed... which causes the process to exit with status 128+signo.
[irc] <markj> and it so happens that Linux and FreeBSD differ in how they handle exit statuses >= 128
[irc] <jfree> markj: That's the source of issue then. I'll figure out a way to circumvent the differing behavior
[irc] <jfree> I really appreciate you looking into that though. It would have taken me much longer to figure that out myself
[irc] <markj> jfree: no problem. I'm not sure at a glance how we can make freebsd behave the same as linux. freebsd has a stricter separation between exit statuses and fatal signal numbers (see that exit1() in the kernel has distinct parameters for each). It might be that the signal handler needs to reset the signal action and then raise the signal again to get the right behaviour.
fbsdgitter
@fbsdgitter
[irc] <markj> btw I noticed this line in truss -f output shortly before the raise(), which is how I got to that point: 4296: sigaction(SIGSEGV,{ 0x8235cfdd0 SA_RESTART|SA_SIGINFO ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0)
fbsdgitter
@fbsdgitter
[irc] <jfree> markj: Would it be more beneficial to adjust FreeBSD's hollistic implementation of signal handling? I was going to add an ifdef FreeBSD at igt_core:2592 to alter the behavior for igt-gpu-tools alone
[irc] <jfree> Potentially just use another raise(SIGSEGV) to segfault the program again w/o any major adjustments to the code
[irc] <jfree> I will figure out a more robust solution later today. If you have any suggestions, I definitely wouldn't mind hearing them
[irc] <markj> jfree: I think it's better to modify igt-tools. Yeah, I think re-raising the signal (after removing the signal handler) would be ok. I'd first write a little test program to verify that that actually behaves as expected.
fbsdgitter
@fbsdgitter
[irc] <markj> to be clear, by removing the signal handler I just mean calling sigaction(signo, &(struct sigaction){.sa_handler = SIG_DFL}, NULL)
fbsdgitter
@fbsdgitter
[irc] <VVD> shkhln, If I knew how it's done, I would try…
[irc] <VVD> this file: lib/xorg/modules/drivers/nvidia_drv.so ?
fbsdgitter
@fbsdgitter
[irc] <VVD> readelf -a /usr/local/lib/xorg/modules/drivers/nvidia_drv.so | grep xf86 ?
fbsdgitter
@fbsdgitter
[irc] <VVD> why xorg upstream break comatibility every 2 years? :-\
fbsdgitter
@fbsdgitter
[irc] <jfree> markj: I ended up modifying the internal_assert_wsignald function to account for FreeBSD's exit status when greater than 128. Disabling the sighandler had some major side effects in other igt tests. See here: jakesfreeland/igt-gpu-tools@d00ed38
fbsdgitter
@fbsdgitter
[irc] <markj> jfree: that seems reasonable enough for a test suite
fbsdgitter
@fbsdgitter
[irc] <jfree> markj: It seemed like the most effective solution without extensively modifying igt's code for FreeBSD. Would mimicking Linux's 128+n signal return behavior be of interest for a src addition at some point?
fbsdgitter
@fbsdgitter
[irc] <markj> jfree: I don't really think so. Though, we might want to emulate Linux's behaviour more carefully in sys/compat/linux. igt_segfault wouldn't work properly when run under the Linuxulator either, at least by my reading of linux_exit().
[irc] <markj> that said, this behaviour seems rather obscure and I'm not sure that many "real" programs depend on it
fbsdgitter
@fbsdgitter
[irc] <jfree> markj: Noted. I'll keep the Linuxulator behavior in mind for potential future work. Thanks for the guidance.
fbsdgitter
@fbsdgitter
[irc] <tcberner> bapt: hardendbd sees some more linker errors in xorg-server: http://ci-08.md.hardenedbsd.org/data/hardenedbsd-current_amd64-local/2022-08-02_21h46m08s/logs/errors/xorg-server-21.1.4,1.log additionally to 265691