I have a system that is very unstable after resuming from suspend-to-RAM
but only if HPET is used as the event timer. The theory is that SMM
code / firmware could be enabling HPET for its own uses and unexpected
interrupts cause a trouble for it. Originally I wanted to solve the
problem in hpet_suspend() method, but that was insufficient as the event
timer could get reprogrammed again.
So, it's better, for my case and in general, to stop the event timer(s)
before entering the hardware suspend.
MFC after: 4 weeks
Differential Revision: https://reviews.freebsd.org/D15413
When we issue shootdown IPIs, we first assign zero to pm_gens to
indicate the need to flush on the next context switch in case our IPI
misses the context, next we read pm_active. On context switch we set
our bit in pm_active, then we read pm_gen. It is crucial that both
threads see the memory in the program order, otherwise invalidation
thread might read pm_active bit as zero and the context switching
thread might read pm_gen as zero.
IA32 allows CPU for both reads to see zero. We must use the barriers
between write and read. The pm_active bit set is already locked, so
only the invalidation functions need it.
I never saw it in real life, or at least I do not have a good
reproduction case. I found this during code inspection when hunting
for the Xen TLB issue reported by cperciva.
Reviewed by: alc, markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D15506
dyn_lookup_ipv[46]_state_locked(). These checks are remnants of not
ready to be committed code, and they are there by accident.
Due to the race these checks can lead to creating of duplicate states
when concurrent threads in the same time will try to add state for two
packets of the same flow, but in reverse directions and matched by
different parent rules.
Reported by: lev
MFC after: 3 days
They're only useful when multiple threads may share an epoch record,
and that can't happen with non-preemptible sections.
Reviewed by: mmacy
Differential Revision: https://reviews.freebsd.org/D15507
Per vnet(9), CURVNET_SET and CURVNET_RESTORE cannot be used as a single
statement for a conditional and CURVNET_RESTORE must be in the same
block as CURVNET_SET (or a subblock).
Reviewed by: andrew
Sponsored by: The FreeBSD Foundation
boot1.efi have some trouble to read MBR partitions, it needs them to be
aligned a certain way while loader.efi can cope with them either way.
We want to switch to loader.efi as the main efi loader everywhere, it seems
that arm64 using MBR partition will be the guinea pig.
Tested On: RPI3, Pine64
Reviewed by: imp
Approved by: gjb
Remove 'top.local.hs'. This was not noticed since
/srv/obj/fbsd/srv/src/freebsd/svn/head/amd64.amd64/usr.bin/top/top.local.h
existed locally on my machine despite "make clean". Only fully removing
the objdir allowed me to observe the error directly.
Pointyhat to: me
This leaves at WARNS=6:
35 warnings in top.c
88 warnings in machine.c
all of which are either "incompatible-pointer-types-discards-qualifiers"
or "cast-qual"
- Replace caddr_t with "void *". This reduces
the number of warnings at WARNS=6
- use "static" where possible
- sprinkle const where possible
This leaves at WARNS=6:
35 warnings in top.c
88 warnings in machine.c
7 warnings in commands.c
all of which are either "incompatible-pointer-types-discards-qualifiers"
or "cast-qual"
- Replace caddr_t with "void *". This reduces
the number of warnings at WARNS=6
- use "static" where possible
- sprinkle const where possible
This leaves at WARNS=6:
35 warnings in top.c
72 warnings in machine.c
5 warnings in commands.c
all of which are either "incompatible-pointer-types-discards-qualifiers"
or "cast-qual"
r329190; sparc64 kernels are always 64-bit but with that revision
in place, the loader was treating them as 32-bit ones.
- In order to reduce the likelihood of this kind of breakage in the
future, #ifdef out md_load() on sparc64 and make md_load_dual() -
which is currently local to metadata.c anyway - static.
- Make md_getboothowto() - also local to metadata.c - static.
- Get rid of the unused DTB pointer on sparc64.
This changes previous behavior of calculating it at startup based on
the current max username length.
This is done because:
- it is in theory possible for the max length to change at run-time
(e.g., a new user is added after top starts running)
- on machines with many users this delays startup significantly
PR: 20799
PR: 89762
Reported by: ob@e-Gitt.NET
Reported by: wkwu@Kavalan.csie.NCTU.edu.tw
Reported on: 2000-08-23 and 2005-11-30
