Bug 241089 - BEAGLEBONE-20191004-r353072 panics
Summary: BEAGLEBONE-20191004-r353072 panics
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: arm (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-arm mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-05 19:55 UTC by Poul-Henning Kamp
Modified: 2019-10-08 20:17 UTC (History)
3 users (show)

See Also:


Attachments
verbose console log (28.71 KB, text/plain)
2019-10-05 19:55 UTC, Poul-Henning Kamp
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Poul-Henning Kamp freebsd_committer 2019-10-05 19:55:37 UTC
Created attachment 208124 [details]
verbose console log

Opened at @manu's request.


        cpsw0: bpf attached^M
        cpsw0: Ethernet address: 40:06:a0:21:b1:a7^M
        simplebus13: <target-module@180000> disabled compat ti,sysc (no driver attached)^M
        simplebus13: <target-module@200000> disabled compat ti,sysc (no driver attached)^M
        simplebus13: <target-module@300000> disabled compat ti,sysc (no driver attached)^M
        simplebus15: <target-module@0> disabled compat ti,sysc (no driver attached)^M
        simplebus15: <target-module@3000> disabled compat ti,sysc (no driver attached)^M
        simplebus0: <edma@49000000> mem 0x49000000-0x4900ffff irq 1,2,3 compat ti,edma3-tpcc (no driver attached)^M
        simplebus0: <tptc@49800000> mem 0x49800000-0x498fffff irq 4 compat ti,edma3-tptc (no driver attached)^M
        simplebus0: <tptc@49900000> mem 0x49900000-0x499fffff irq 5 compat ti,edma3-tptc (no driver attached)^M
        simplebus0: <tptc@49a00000> mem 0x49a00000-0x49afffff irq 6 compat ti,edma3-tptc (no driver attached)^M
        sdhci_ti2: <TI MMCHS (SDHCI 2.0)> mem 0-0xfff irq 54 on ti_sysc42^M
        Fatal kernel mode data abort: 'External Abort' on read^M
        trapframe: 0xc0e14c60^M
        FSR=00001008, FAR=ff910114, spsr=60000093^M
        r0 =c08d92c0, r1 =ff910000, r2 =00000114, r3 =00000000^M
        r4 =c24d8200, r5 =c24d8218, r6 =fffffc19, r7 =00000000^M
        r8 =c24d8200, r9 =0000d07c, r10=c2450a80, r11=c0e14d30^M
        r12=0000006e, ssp=c0e14cf0, slr=c068a8b8, pc =c068aa50^M
        ^M
        panic: Fatal abort^M
        cpuid = 0^M
        time = 1^M
        KDB: stack backtrace:^M
        db_trace_self() at db_trace_self^M
                 pc = 0xc05cfc98  lr = 0xc007a1e8 (db_trace_self_wrapper+0x30)^M
                 sp = 0xc0e14a40  fp = 0xc0e14b58^M
        db_trace_self_wrapper() at db_trace_self_wrapper+0x30^M
                 pc = 0xc007a1e8  lr = 0xc02afae4 (vpanic+0x168)^M
                 sp = 0xc0e14b60  fp = 0xc0e14b78^M
                 r4 = 0x00000100  r5 = 0xc0b23720^M
                 r6 = 0xc0727a61  r7 = 0x00000000^M
        vpanic() at vpanic+0x168^M
                 pc = 0xc02afae4  lr = 0xc02af8ac (doadump)^M
                 sp = 0xc0e14b80  fp = 0xc0e14b84^M



See attachment for full console log
Comment 1 Ian Lepore freebsd_committer 2019-10-05 22:54:09 UTC
On TI chips, an external data abort on an address in the mmio range is almost certainly an attempt to read from a device register when that device's clocks aren't running.  Probably fresh fallout from a recent DTS import.
Comment 2 commit-hook freebsd_committer 2019-10-07 08:11:56 UTC
A commit references this bug:

Author: manu
Date: Mon Oct  7 08:11:49 UTC 2019
New revision: 353172
URL: https://svnweb.freebsd.org/changeset/base/353172

Log:
  arm: dts: ti: Fix mmc3 instance by setting it to disabled

  DTS Import of Linux 5.3 added a patch that rework the L3 mmc instance
  in the AM335x SoC but removed the status = 'disabled' on the node.
  This cause the kernel to probe the device even if the board doesn't
  have this mmc used and since we don't correctly activate the clock
  for this module we panic with an external data abort.
  Beaglebone(s) don't have this device anyway so simply disabling it.
  Patch for the DTS was sent upstream.
  https://patchwork.kernel.org/patch/11176921/

  PR:		241089
  Reported by:	phk

Changes:
  head/sys/gnu/dts/arm/am33xx.dtsi
Comment 3 Emmanuel Vadot freebsd_committer 2019-10-08 17:29:07 UTC
Re-opening this bug as Linux will likely won't apply my patch. TI have differents view on DTS than others.
Also the real bug is that we probably don't handle the clock for mmc3 correctly.
I won't work on this problem.
ian@ suggested an dtb overlay auto-loading features if we have a <basedtb>-freebsd.dtbo where we would put things like that when they aren't accepted upstream, I'll likely more work on this.
Comment 4 Warner Losh freebsd_committer 2019-10-08 20:17:11 UTC
I like the overload autoload thing, which could be useful in papering over differences of opinion on the proper role of DTB between the different vendors, Linux kernel folks and the ePAR successors who aren't always all on the same page...