Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 03 22:07
    dumbbell edited #25
  • Oct 03 22:07
    dumbbell opened #25
  • 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
fbsdgitter
@fbsdgitter
[irc] <manu_> that's the simplest imho
[irc] <manu_> but I won't have time this afternoon or tonight
Niclas Zeising
@zeising
So basically the port will install different versions depending on FreeBSD version. We have decided against that in the past because it causes confusion. But if you think it will work, try it.
I don't have time either. I have asked Bjoern to revert the fix for now, to give us a chance to fix this.
I need to get back to focus on work, I'll check back later
fbsdgitter
@fbsdgitter
[irc] <manu_> @zeising: @wulf7: I've confirmed that drm_v5.4.92_5 works on 13.0-RELEASE
[irc] <manu_> @zeising: @wulf7: and I beleive it should also on 13-STABLE
Niclas Zeising
@zeising
Ok.
That is good
fbsdgitter
@fbsdgitter
[irc] <manu_> but won't have time to test this today
[irc] <manu_> I'll update the port though
[irc] <manu_> it doesn't hurt 13.0 people and will maybe help 13-stable users
[irc] <fbsdslack> <zeising> yeah.
[irc] <fbsdslack> <zeising> It wont make the situation worse
Vladimir Kondratyev
@wulf7
@zeising: @manu: I confirm that drm_v5.4.92_4 built on 13.0-RELEASE does not work on 13-STABLE. I don't know which commit broke KBI. May be one of @bz commits, may be it had happened before.
fbsdgitter
@fbsdgitter
[irc] <manu_> that's always the case for drm kmods
[irc] <fbsdslack> <zeising> it is unfortunate though, and we need to keep track of it for 13.1
Vladimir Kondratyev
@wulf7
That forces some people to wait for three months to upgrade
fbsdgitter
@fbsdgitter
[irc] <fbsdslack> <zeising> If you have time, feel free to try to figure out which commit broke it.
Niclas Zeising
@zeising
I need to cut down the number of places I have this chat ;)
Warner Losh
@bsdimp
We've had this problem with all the branches and drm. Our KBI isn't stable enough, and it's quite often not the linuxkpi changes that are to blame.
I have a PoC kernel .h file extraction port that can be used to build for a 13.1 kernel on a 13.0 system.
Though I remain convinced that we should be downloading source and requiring compilers and kernel headers be around to solve this completely. And that's kinda a hard problem that we've dabbled with in the past and discovered it isn't always so simple as to 'just include sources' because new kernel headers can break them. :(
so testing that things are good for that would be an interesting testing matrix. :(
Vladimir Kondratyev
@wulf7
I bisected LKPI commits to find culprit. 04456f7118 appeared to be guilty. It adds some fields to struct pci_devwhich are required by newer versions of drm-kmod.
That means that we have 2 options: Revert all breaking commits and stick to drm-kmod 5.4 on 13.x forever or break 13.x->13.x+1 binary upgrade over and over again.
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> Who allocates the struct pci_dev? I can't find it in my quick search. If it's the linuxkpi code, then we can just add those fields at the end and life will be good.
[irc] <bsdimp_> It looks like it gets passed into the create routine.
[irc] <bsdimp_> I'm not seeing who calls the probe routine, I'm guessing that's burried inside of linuxkpi macros that resis grepping.
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> Oh, it's allocated in the drivers and the size is embedded in them.
[irc] <bsdimp_> oh, wait: that's the pci_driver, not the pci_dev.
[irc] <bsdimp_> ah, found it
[irc] <bsdimp_> pdev = malloc(sizeof(*pdev), M_DEVBUF, M_WAITOK|M_ZERO);
[irc] <bsdimp_> OK. That means we move the fields to the end. It breaks binary compat within the stable branch from the 11th to when the commit is made. That's fine, imho.
[irc] <bsdimp_> since linuxkpi allocates it, the drivers that use ti don't care.
[irc] <bsdimp_> old drivers won't access the new fields
[irc] <bsdimp_> New drivers won't run on old kernels
[irc] <bsdimp_> all new kernels will grok it.
[irc] <bsdimp_> we won't be able to do the 5.5 drivers for 13.0.
[irc] <bsdimp_> but we will for newer.
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> which brings up interesting 'how do we package things' issues for them.
[irc] <bsdimp_> but at the very least we should do a followup direct commit that moves the fields so that 13.0-built packages will work in newer stable
[irc] <bsdimp_> that problem, at least, will be behind us, assuming it's the only KBI issue
[irc] <bsdimp_> And I think there's value in being able to run 5.4.9x drm on latest stable/13
[irc] <bsdimp_> 5.4.9x drm built on 13.0
[irc] <bsdimp_> how we finesse the rest, I'll leave for another day. I gotta get to bed. I'm zonked.
Vladimir Kondratyev
@wulf7
I am able to run 5.4.9x drm built on 13.0 on latest stable/13
Commits to revert are 04456f711853, 40a215e38a4d, 1eaaada457d6, 3a606aadf2e7 and 10235ad0567f
04456f711853 and 10235ad0567f are drm-kmod related
40a215e38a4d, 1eaaada457d6 and 3a606aadf2e7 are by @bz. They looks like a part ofcoming wifi LKPI
Vladimir Kondratyev
@wulf7
If someone is willing to revert them let me know. I can cherry-pick drm-kmod 5.5 support for missing commits from early 5.5 versions.
But IMO it is a way to nowhere