Bug 243117 - panic: keg dma coherent 32 initialization after use. (MIPS MALTA64)
Summary: panic: keg dma coherent 32 initialization after use. (MIPS MALTA64)
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: Jeff Roberson
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-01-05 16:55 UTC by Alex Richardson
Modified: 2020-01-05 22:59 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Richardson freebsd_committer freebsd_triage 2020-01-05 16:55:41 UTC 
With today's HEAD I get the following panic when booting a MALTA64 kernel on QEMU:

Breakpoint 1, panic (fmt=0xffffffff80766a14 "keg %s initialization after use.")
    at /exports/users/alr48/sources/freebsd/sys/kern/kern_shutdown.c:835
835		vpanic(fmt, ap);
(gdb) bt
#0  panic (fmt=0xffffffff80766a14 "keg %s initialization after use.")
    at /exports/users/alr48/sources/freebsd/sys/kern/kern_shutdown.c:835
#1  0xffffffff8068a1f4 in uma_zone_set_allocf (zone=<optimized out>,
    allocf=0xffffffff8070a180 <busdma_bufalloc_alloc_uncacheable>)
    at /exports/users/alr48/sources/freebsd/sys/vm/uma_core.c:4265
#2  0xffffffff80709f68 in busdma_bufalloc_create (name=<optimized out>,
    minimum_alignment=<optimized out>,
    alloc_func=0xffffffff8070a180 <busdma_bufalloc_alloc_uncacheable>,
    free_func=0xffffffff8070a1e0 <busdma_bufalloc_free_uncacheable>,
    zcreate_flags=<optimized out>)
    at /exports/users/alr48/sources/freebsd/sys/kern/subr_busdma_bufalloc.c:110
#3  0xffffffff806e0678 in busdma_init (dummy=<optimized out>)
    at /exports/users/alr48/sources/freebsd/sys/mips/mips/busdma_machdep.c:246
#4  0xffffffff803a3f40 in mi_startup ()
    at /exports/users/alr48/sources/freebsd/sys/kern/init_main.c:314
#5  0xffffffff80100388 in _locore ()
    at /exports/users/alr48/sources/freebsd/sys/mips/mips/locore.S:201
Comment 1 Alex Richardson freebsd_committer freebsd_triage 2020-01-05 16:56:38 UTC 
Probably caused by https://reviews.freebsd.org/rS356348 ?
Comment 2 Mark Johnston freebsd_committer freebsd_triage 2020-01-05 18:43:12 UTC 
I think the issue is that the assertion checks the value of uz_allocs while it still points to EARLY_COUNTER, and so we get bogus values.
Comment 3 commit-hook freebsd_committer freebsd_triage 2020-01-05 22:55:19 UTC 
A commit references this bug:

Author: jeff
Date: Sun Jan  5 22:54:26 UTC 2020
New revision: 356389
URL: https://svnweb.freebsd.org/changeset/base/356389

Log:
  The fix in r356353 was insufficient.  Not every architecture returns 0 for
  EARLY_COUNTER.  Only amd64 seems to.

  Suggested by:	markj
  Reported by:	lwhsu
  Reviewed by:	markj
  PR:		243117

Changes:
  head/sys/vm/uma_core.c
Comment 4 Mark Johnston freebsd_committer freebsd_triage 2020-01-05 22:59:04 UTC 
Before r356348 we were reading EARLY_COUNTER, giving a bogus allocation counter.  It happens to work on amd64 because counter_u64_fetch() uses CPU_FOREACH, which is a no-op before SI_SUB_CPU.