#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
else than rototill it for the past n+1 years. The comments at the
top note a number of clauses after which it can be removed. I'm
sure that in the past 10+ years those have either been met or become
irrelevant, so remove this.
identified as product code 0x1533, which is what is actually in the
CS20. PCI_PRODUCT_ALI_M1543 was corrected recently and sio.c would fail
to match the bridge.
- Replace most remaining uses of l_addr with uvm_lwp_getuarea() or lwp_getpcb().
- Amend assembly in ports where it accesses PCB via struct user.
- Rename L_ADDR to L_PCB in few places. Reduce sys/user.h inclusions.
This allows use of subr_disk_mbr on all archs. Default to it for
the rump disk component. No functional change for regular kernels.
(The other option would've been to include dkbad in disklabels
everywhere, but arguably this approach has less possible side-effects,
especially given that wedges and related magic will take over the
world any second now).
can cause a deadlock or pool cache corruption. Take the shootdown job
queue mutex before calling pool_cache_get(), which will block the IPI
interrupts and seems to fix the remaining tlb shootdown deadlocks and
pool cache corruption I've been seeing. Should address both
PR port-amiga/38335 and PR port-amiga/42174.
got raid drives configured on the iop(4) adapter and the mlx(4) adapter.
Change the kernel text to 0xfffffc0000430000 (which is where Tru64 has its
kernel).
extent storage for each tsp(4), which caused a LOCKDEBUG kernel to fail
because the extent storage contained a mutex which panics when the second
mutex_init() is attempted. Put the extent storage into the tsp_config
structure so each tsp(4) gets it own. Fixes PR port-alpha/38358.
actually start shutting down cpus. This caused problems because the
wait_mask computed at the beginning of cpu_reboot() wouldn't be correct
when actually waiting for the other cpus to shutdown, and cpu_halt()
might be called instead of prom_halt() at the end, leading to a hung
machine.
- Addresses the issue described in PR/38828.
- Some simplification in threading and sleepq subsystems.
- Eliminates pmap_collect() and, as a side note, allows pmap optimisations.
- Eliminates XS_CTL_DATA_ONSTACK in scsipi code.
- Avoids few scans on LWP list and thus potentially long holds of proc_lock.
- Cuts ~1.5k lines of code. Reduces amd64 kernel size by ~4k.
- Removes __SWAP_BROKEN cases.
Tested on x86, mips, acorn32 (thanks <mpumford>) and partly tested on
acorn26 (thanks to <bjh21>).
Discussed on <tech-kern>, reviewed by <ad>.
queue mutex doesn't work very well. I get various deadlocks and corrupted
queue entries. Change to IPL_SCHED [IPL_CLOCK] to block IPI interrupts
while the cpu is mucking with the shootdown queue.
send pmap tlb shootdowns to them cause the shootdown job queue to fill up,
but since the cpus aren't running yet, no IPIs get sent. When the job
queue is full, the bit mask of cpus to send the IPI to is not set and no
shootdown IPI ever gets sent after the cpu is marked running. Always
set the cpumask even when the queue is full. Now I get shootdown ipis
on all the secondary cpus.
cpus are told to begin running. Since the seconedary cpus weren't being
added to the cpu_info list until then, that initialization wasn't being
done and resulted in crashes on the secondary cpus. Add the secondary
cpus to the cpu_info_list after they've been started (but waiting to be
told to start running). This fixes the problem specifically stated in
PR port-alpha/41106. MP alphas will now at least boot and begin running,
but will eventually crash in various ways later.
