CPSW_DEBUG_DMA define.
This handles a condition where checking for DMA_RXEOQ in the received packet
results in the console being spammed with "rxeoq" messages, which soon results
in a kernel panic. The corresponding Debugger() call for this check was
commented out.
The TI documentation ("AM335x and AMIC110 Sitara™ Processors Technical
Reference Manual") documents the EOQ bit thus:
(14.3.2.4.1.2.4) This bit is set by the EMAC when the EMAC identifies
that a descriptor is the last for a given packet received (also sets
the EOP flag), and there are no more descriptors in the receive list
(next descriptor pointer is NULL). The software application can use
this bit to detect when the EMAC receiver for the corresponding channel
has halted. This is useful when the application appends additional free
buffer descriptors to an active receive queue. Note that this flag is
valid on EOP descriptors only.
Moving this check (and the offending printf() ) into a debug #ifdef results in
the BeagleBone Green surviving the nightly checks; it would always drop into
the debugger before this change.
Derived from Intel and AMD manuals.
Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3
(3A, 3B, 3C, & 3D: System Programming Guide, Order Number:
325384-077US, April 2022.
https://cdrdv2.intel.com/v1/dl/getContent/671447
AMD64 Technology: AMD64 Architecture Programmers' Manual, Volume 2:
System Programming, Publication No. 24953, Revision 3.40, January 2023.
https://www.amd.com/system/files/TechDocs/24593.pdf
No functional change intended.
XXX Should apply the same treatment to i386_trap.S.
Since /tmp and /var/tmp are always part of .MAKE.META.IGNORE_PATHS
the varname-dot-make-meta-ignore_* tests will not work
if TMPDIR is either (or subdir) of those.
This time, make sure to restore the FPU state when switching to a
kthread in the middle of kthread_fpu_enter/exit.
This adds a single predicted-taken branch for the case of kthreads
that are not in kthread_fpu_enter/exit, so it incurs a penalty only
for threads that actually use it. Since it avoids FPU state
switching in kthreads that do use the FPU, namely cgd worker threads,
this should be a net performance win on systems using it and have
negligible impact otherwise.
XXX pullup-10
In fpu_kern_enter, make sure all the MXCSR exception status bits are
set when we start using the FPU, so that instructions which exhibit
MCDT are unaffected by it.
While here, zero all the other FPU registers in fpu_kern_enter.
In principle we could skip this step on future CPUs that fix the MCDT
bug, but there's probably not much benefit -- workloads that do a lot
of crypto in the kernel are probably better off using
kthread_fpu_enter or WQ_FPU to skip the fpu_kern_enter/leave cycles
in the first place.
For details, see:
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/mxcsr-configuration-dependent-timing.html
Fixes crash on boot in new KASSERT(kpreempt_disabled()) in
cpu_load_pmap.
We could do KASSERT(kpreempt_disabled() || cold), but I don't know if
bioscall is ever reachable after warm boot; this way is safer.
XXX Would be nice if bioscall were a C function, not asm -- I don't
see any reason why we need it to be asm?
Use .Ql instead of .Sq Li, add some missing ones. Use .Pq instead of
explicit () for longer phrases - these are easier to read in the
postscript output b/c of extra spacing.
Add netrc processing to fetch-mode (URL on command line) to enable options and autologin
via netrc.
Fix SSL cleanup in some error paths.
Certificate validation is now enabled by default. Set FTPSSLNOVERIFY=1 in environment
or configure a corresponding init macro via netrc to not validate certs (required if
you haven't installed a required CA certificate for OpenSSL).
Discussed with lukem@ on icb.
I had accidentally added these tests to the file for the special
variable '.MAKEFLAGS' instead of the file for the environment variable
'MAKEFLAGS'. While here, add a basic test that shows how 'MAKEFLAGS' is
built from '.MAKEFLAGS' and '.MAKEOVERRIDES'.
Sprinkle KASSERT (or KDASSERT in hot paths) for kpreempt_disabled()
when we use curcpu() and it's not immediately obvious that the caller
has preemption disabled but closer scrutiny suggests the caller has.
Note unsafe curcpu()s for syscall event counting. Not sure this is
worth changing.
Possible bugs fixed:
- cpu_irq and cpu_fiq could be preempted while trying to run softints
on this CPU.
- data_abort_handler might incorrectly think it was invoked in
interrupt context when it was only preempted and migrated to
another CPU.
- pmap_fault_fixup might report the wrong CPU logs.
(However, we don't currently run with kpreemption on aarch64, so
these are not yet real bugs fixed except if you patch it to build
with __HAVE_PREEMPTION.)
rillig