Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

panic: Unknown userland exception 0 esr_el1 2000000 #9

Open
emaste opened this issue Feb 11, 2015 · 2 comments
Open

panic: Unknown userland exception 0 esr_el1 2000000 #9

emaste opened this issue Feb 11, 2015 · 2 comments

Comments

@emaste
Copy link
Member

emaste commented Feb 11, 2015

x0: 0
x1: 405f27a8
x2: 74
x3: 40c000c0
x4: 1
x5: 1
x6: 1
x7: 1
x8: 1
x9: 0
x10: 40c100c0
x11: 2ff0000000000000
x12: 7e
x13: b0
x14: 408001b0
x15: ffffffff
x16: 405d4f18
x17: 405ae464
x18: 5000
x19: 0
x20: 41fa92
x21: 0
x22: 41f78f
x23: 41f991
x24: 100000001
x25: 0
x26: 8ffffe130
x27: 1
x28: 7fffffe130
x29: 41f890
x30: 7fffffe730
sp: 7fffffe130
lr: 7fffffe130
elr: 7fffffe130
spsr: 60000000
panic: Unknown userland exception 0 esr_el1 2000000

KDB: stack backtrace:
db_trace_self() at db_trace_self_wrapper+0x30
pc = 0xffffff80003c0cb4 lr = 0xffffff8000014b10
sp = 0xffffff8056f9a7b0 fp = 0xffffff8056f9a8e0

db_trace_self_wrapper() at vpanic+0xc8
pc = 0xffffff8000014b10 lr = 0xffffff8000153f30
sp = 0xffffff8056f9a8f0 fp = 0xffffff8056f9a960

vpanic() at panic+0x4c
pc = 0xffffff8000153f30 lr = 0xffffff8000154040
sp = 0xffffff8056f9a970 fp = 0xffffff8056f9a9f0

panic() at do_el0_sync+0x6f0
pc = 0xffffff8000154040 lr = 0xffffff80003cdc04
sp = 0xffffff8056f9aa00 fp = 0xffffff8056f9aaa0

do_el0_sync() at handle_el0_sync+0x58
pc = 0xffffff80003cdc04 lr = 0xffffff80003c21b4
sp = 0xffffff8056f9aab0 fp = 0x0041f890

handle_el0_sync() at 0xfffc
pc = 0xffffff80003c21b4 lr = 0x0000fffc
sp = 0x0041f8a0 fp = 0x00000000

KDB: enter: panic
[ thread pid 344 tid 100039 ]
Stopped at kdb_enter+0x6c:
db>
@emaste
Copy link
Member Author

emaste commented Feb 11, 2015

this happened on bootup just after "Starting syslogd."

@zxombie
Copy link

zxombie commented Feb 11, 2015

sp: 7fffffe130
lr: 7fffffe130
elr: 7fffffe130

This looks to be wrong.

handle_el0_sync() at 0xfffc
pc = 0xffffff80003c21b4 lr = 0x0000fffc
sp = 0x0041f8a0 fp = 0x00000000

But now it's different.

emaste pushed a commit that referenced this issue Feb 22, 2019
@cemeyer
fuse: Fix a regression introduced in r337165
0be3f78 
On systems with non-default DFLTPHYS and/or MAXBSIZE, FUSE would attempt to
use a buf cache block size in excess of permitted size.  This did not affect
most configurations, since DFLTPHYS and MAXBSIZE both default to 64kB.
The issue was discovered and reported using a custom kernel with a DFLTPHYS
of 512kB.

PR:		230260 (comment #9)
Reported by:	ken@
MFC after:	π/𝑒 weeks
emaste pushed a commit that referenced this issue Jul 2, 2019
@bu7cher
Rework r348303 to reduce the time of holding global BPF lock.
4b4eed4 
It appeared that using NET_EPOCH_WAIT() while holding global BPF lock
can lead to another panic:

spin lock 0xfffff800183c9840 (turnstile lock) held by 0xfffff80018e2c5a0 (tid 100325) too long
panic: spin lock held too long
...
#0  sched_switch (td=0xfffff80018e2c5a0, newtd=0xfffff8000389e000, flags=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2133
#1  0xffffffff80bf9912 in mi_switch (flags=256, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:439
#2  0xffffffff80c21db7 in sched_bind (td=<optimized out>, cpu=<optimized out>) at /usr/src/sys/kern/sched_ule.c:2704
#3  0xffffffff80c34c33 in epoch_block_handler_preempt (global=<optimized out>, cr=0xfffffe00005a1a00, arg=<optimized out>)
    at /usr/src/sys/kern/subr_epoch.c:394
#4  0xffffffff803c741b in epoch_block (global=<optimized out>, cr=<optimized out>, cb=<optimized out>, ct=<optimized out>)
    at /usr/src/sys/contrib/ck/src/ck_epoch.c:416
#5  ck_epoch_synchronize_wait (global=0xfffff8000380cd80, cb=<optimized out>, ct=<optimized out>) at /usr/src/sys/contrib/ck/src/ck_epoch.c:465
#6  0xffffffff80c3475e in epoch_wait_preempt (epoch=0xfffff8000380cd80) at /usr/src/sys/kern/subr_epoch.c:513
#7  0xffffffff80ce970b in bpf_detachd_locked (d=0xfffff801d309cc00, detached_ifp=<optimized out>) at /usr/src/sys/net/bpf.c:856
#8  0xffffffff80ced166 in bpf_detachd (d=<optimized out>) at /usr/src/sys/net/bpf.c:836
#9  bpf_dtor (data=0xfffff801d309cc00) at /usr/src/sys/net/bpf.c:914

To fix this add the check to the catchpacket() that BPF descriptor was
not detached just before we acquired BPFD_LOCK().

Reported by:	slavash
Tested by:	slavash
MFC after:	1 week
emaste pushed a commit that referenced this issue Jan 6, 2020
@ppaeps
fuspi: Fix 'sleepable after non-sleepable' lock
4729f0c 
With WITNESS enabled we see the following warning:

    lock order reversal: (sleepable after non-sleepable)
     1st 0xffffffd0847c7210 fu540spi0 (fu540spi0) @
     /usr/home/kp/axiado/hornet-freebsd/src/sys/riscv/sifive/fu540_spi.c:297
      2nd 0xffffffc00372bb30 Clock topology lock (Clock topology lock) @
      /usr/home/kp/axiado/hornet-freebsd/src/sys/dev/extres/clk/clk.c:1137
      stack backtrace:
      #0 0xffffffc0002a579e at witness_checkorder+0xb72
      #1 0xffffffc0002a5556 at witness_checkorder+0x92a
      #2 0xffffffc000254c7a at _sx_slock_int+0x66
      #3 0xffffffc00025537a at _sx_slock+0x8
      #4 0xffffffc000123022 at clk_get_freq+0x38
      #5 0xffffffc0005463e4 at __clzdi2+0x2bb8
      #6 0xffffffc00014af58 at randomdev_getkey+0x76e
      #7 0xffffffc0001278b0 at simplebus_add_device+0x7ee
      #8 0xffffffc00027c9a8 at device_attach+0x2e6
      #9 0xffffffc00027c634 at device_probe_and_attach+0x7a
      #10 0xffffffc00027d76a at bus_generic_attach+0x10
      #11 0xffffffc00014aab0 at randomdev_getkey+0x2c6
      #12 0xffffffc00027c9a8 at device_attach+0x2e6
      #13 0xffffffc00027c634 at device_probe_and_attach+0x7a
      #14 0xffffffc00027d76a at bus_generic_attach+0x10
      #15 0xffffffc000278bd2 at config_intrhook_oneshot+0x52
      #16 0xffffffc000278b3e at config_intrhook_establish+0x146
      #17 0xffffffc000278cf2 at config_intrhook_disestablish+0xfe

The clock topology lock can sleep, which means we cannot attempt to
acquire it while holding the non-sleepable mutex.

Fix that by retrieving the clock speed once, during attach and not every
time during SPI transaction setup.

Submitted by:   kp
Sponsored by:   Axiado
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@zxombie @emaste