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
Warner Losh
@bsdimp
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
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> that's a really long list...
[irc] <bsdimp_> 04456f711853 can be tweaked to move things to the end.
[irc] <bsdimp_> 40a215e38a4d likewise
[irc] <bsdimp_> they are both pci_dev
[irc] <bsdimp_> 1eaaada457d6 adds to the middle of irq_ent. I've not chased it down, but it looks linuxkpi internal
[irc] <bsdimp_> so maybe it could too.
[irc] <bsdimp_> 3a606aadf2e7 is another that can move items to the end.
[irc] <bsdimp_> 10235ad0567f looks harder.
[irc] <bsdimp_> I could come up with a patch for the first 4 I think would work, but don't know about the last one.
[irc] <bsdimp_> wulf7 would you be interested in testing that patch? Or do you think it's too crazy a train to try to ride?
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> I'm unsure how the last one breaks it at all after looking at it.
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> I'm unsure how 1eaaada457d6 and 10235ad0567f break kbi though
[irc] <bsdimp_> https://bsdimp@github.com/bsdimp/freebsd branch drm-kbi-hacks has what I think will restore KBI, but again, I don't understand why the last two break things.
[irc] <bsdimp_> I run -current on my laptop and it would be some significant pain
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> Oh I understand 1eaaada457d6 since it's a bunch of static inlines, the sizes and offsets of irq_ent are encoded into the binaries.
[irc] <bsdimp_> 10235ad0567f calls different things now, so I kinda understand it as well, but not what to do.
Vladimir Kondratyev
@wulf7
10235ad0567f is included in this list as it makes some LKPI symbols private. It is easy to make them public again.
Vladimir Kondratyev
@wulf7

wulf7 would you be interested in testing that patch? Or do you think it's too crazy a train to try to ride?

I will be mostly AFK until sunday. With no access to 13-STABLE. Can smoke-test any patches after than as I am not 13-STABLE user too. I just made external USB 2.0 HDD and installed subj onto it to test. This HDD is ridiculousy slow but is useable

Vladimir Kondratyev
@wulf7

https://bsdimp@github.com/bsdimp/freebsd branch drm-kbi-hacks has what I think will restore KBI, but again, I don't understand why the last two break

drm-kbi-hacks along with restoring of linux_kmem_cache_free_rcu visibility (10235ad0567) allowed me to run Xorg+DE session succesfully.

on 13-STABLE with drm-kmod built on 13.0-RELEASE
fbsdgitter
@fbsdgitter
[irc] <bsdimp_> OK. Lemme add that to the branch and I'll work to get it committed to stable/13
[irc] <bsdimp_> I'll bump FreeBSD_versrion too