Page MenuHomeFreeBSD

linuxkpi: Set the UMA_ZFLAG_CACHE flag in linux_kmem_cache_create()
Needs ReviewPublic

Authored by nc on Jul 7 2021, 2:05 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 23 2023, 1:17 AM
Unknown Object (File)
Jan 5 2023, 9:51 AM

Details

Summary

This is needed to prevent kernel panics on the drm-kmod 5.7 branch.

Test Plan

Tested on Intel TigerLake (HP Spectre x360 13t-aw200).

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 40360
Build 37249: arc lint + arc unit

Event Timeline

nc requested review of this revision.Jul 7 2021, 2:05 AM

This is wrong. Please use:

uma_zone_t
uma_zcache_create(const char *name, int size, uma_ctor ctor, uma_dtor dtor,
    uma_init zinit, uma_fini zfini, uma_import zimport, uma_release zrelease,
    void *arg, int flags)
{
        struct uma_zctor_args args;

        memset(&args, 0, sizeof(args));
        args.name = name;
        args.size = size;
        args.ctor = ctor;
        args.dtor = dtor;
        args.uminit = zinit;
        args.fini = zfini;
        args.import = zimport;
        args.release = zrelease;
        args.arg = arg;
        args.align = 0;
        args.flags = flags | UMA_ZFLAG_CACHE;

        return (zone_alloc_item(zones, &args, UMA_ANYDOMAIN, M_WAITOK));

I'm sure that we don't want to use UMA cache zones here. They are for specialized allocators which implement their own back-end; they just provide per-CPU caching. For instance, a kernel subsystem might have some large, fixed-size collection of objects which may be allocated and freed. Then a UMA cache zone can be used to provide a scalable allocator for that collection. I suspect that this change just hides a problem.

Here's the thing. It may still be an "issue", but:

  • My 5.7-wip branch was shelved for a 5.6-wip branch, the latter which was committed to GitHub by @wulf, but no work has been done since then
  • I sold my TigerLake laptop and went back to my older, supported WhiskeyLake laptop. Even if I got a working (buggy) 5.7-wip branch, NVMe was slow to initialize and HD Audio doesn't work on TigerLake.

I am thinking about buying an AMD Ryzen-based HP Envy x360 since it seems the 4700U's Radeon GPU is "supported". Or should I just get a refurb ThinkPad?

In D31085#708018, @nc wrote:

Here's the thing. It may still be an "issue", but:

  • My 5.7-wip branch was shelved for a 5.6-wip branch, the latter which was committed to GitHub by @wulf, but no work has been done since then

5.6-wip crashes on KabyLake right after start of desktop environment with "panic: vm_page_insert_after: page already inserted" message, so there is nothing to work on before it get fixed.
May be it is a result of missing iterations on scatter-gather list in remap_io_sg()?

P.S. This revision does not fix panic for me.

In D31085#708455, @wulf wrote:

5.6-wip crashes on KabyLake right after start of desktop environment with "panic: vm_page_insert_after: page already inserted" message, so there is nothing to work on before it get fixed.
May be it is a result of missing iterations on scatter-gather list in remap_io_sg()?

That could be very well possible, however see my next point.

P.S. This revision does not fix panic for me.

It's not surprising, since this was mainly for my 5.7-wip. Although on my 5.7-wip, sometimes it crashed after a few minutes/hours of use.

I sold my TigerLake laptop and went back to my WhiskeyLake laptop for now. The reason isn't just drm-kmod, but also a lack of audio drivers and a buggy/slow SSD initialization. I do plan to continue work on drm-kmod on WhiskeyLake, hopefully at least and plan to get an AMD-based laptop to replace the TGL one.

There are my commits on my 5.7-wip that could be brought over to 5.6-wip: https://github.com/neelchauhan/drm-kmod/commits/5.7-wip

Some of the commits may not have been brought over.

However, looking at the stack traces could be useful in your case, that's how I debugged.

It seems remap_io_sg() is identical on my 5.7-wip versus the actual 5.6-wip.