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

Get lint building on arm64 - need stdarg va_start, va_arg #4

Open
emaste opened this issue Jan 16, 2015 · 3 comments
Open

Get lint building on arm64 - need stdarg va_start, va_arg #4

emaste opened this issue Jan 16, 2015 · 3 comments

Comments

@emaste
Copy link
Member

emaste commented Jan 16, 2015

As noted in 4d65d36c637a793258686f442778d8dffd738b04
@zxombie
Copy link

zxombie commented Jan 19, 2015

Lint should build, it just won't run with anything that includes <machine/stdarg.h> or <stdarg.h>. the latter is a symlink to the former. It looks like it runs as part of the build process so will stop the build.

To fix it we need to add macros for va_start, etc.

@emaste
Copy link
Member Author

emaste commented Jan 19, 2015

It looks like it runs as part of the build process so will stop the build.

I did not look in detail, just noticed that lint caused buildworld to fail. It seems odd to me that it's run during the build, but then I guess there are a number of oddities in our build.

@emaste
Copy link
Member Author

emaste commented Mar 24, 2015

Failure is:

In file included from /tank/emaste/src/freebsd-arm64/usr.bin/xlint/llib/llib-lstdc:47:
/tank/emaste/obj/arm64.aarch64/tank/emaste/src/freebsd-arm64/tmp/usr/include/stdarg.h:63:2: error: no support for your compiler
#error no support for your compiler
 ^

@emaste emaste changed the title Get lint building on arm64 Get lint building on arm64 - need stdarg va_start, va_arg Mar 24, 2015
emaste pushed a commit that referenced this issue Sep 14, 2018
@kevans91
lualoader: Refactor config line expressions
df8ad87 
A couple of issues addressed:

1.) Modules with - in the name were not recognized as modules
2.) The module regex was repeated for each place a module name may appear
3.) The 'strip leading space' bits were repeated for each expression
4.) The trailing 'comment validation' stuff was repeated every expression

#4 still has some more work to be done. exec lines, for instance, don't
capture a 'value' -- there's only one capture pattern. This throws off the
'c' value that we match, so the trailing bits aren't *actually* being
validated. This isn't a new issue, though, so a future comit will address
this.
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 Jul 2, 2019
@DimitryAndric
Partially revert r271349, which disabled the msun cexp test #4 on i386.
d364650 
Ensure the expected result is stored first in a volatile variable with
the desired type.  This makes all the tests succeed.

Slightly changed from the original pull request, but functionally the
same.

Obtained from:	freebsd#401
Submitted by:	Moritz Buhl <[email protected]>
PR:		191676
MFC after:	3 days
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