| created | 2022-07-31T00:49:53Z |
|---|---|
| begin | 2022-07-24T00:00:00Z |
| end | 2022-07-25T00:00:00Z |
| path | src/sys |
| commits | 5 |
| date | 2022-07-24T00:28:09Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/arch/macppc/dev/macintr.c | log | diff | annotate |
| src/sys/arch/macppc/dev/openpic.c | log | diff | annotate | |
| src/sys/arch/macppc/macppc/clock.c | log | diff | annotate | |
| src/sys/arch/powerpc/include/cpu.h | log | diff | annotate | |
| src/sys/arch/powerpc/powerpc/intr.c | log | diff | annotate | |
| message |
macppc, powerpc: retrigger deferred DEC interrupts from splx(9) On PowerPC, by design, you cannot mask decrementer (DEC) interrupts without also masking other interrupts that we want to leave unmasked at or above IPL_CLOCK. So, currently, the DEC is left unmasked, even when we're working at IPL_CLOCK or IPL_HIGH. If a DEC interrupt arrives while we're at those priority levels, the current solution is to postpone any clock interrupt work until the next hardclock(9) or statclock tick. This is a problem for a machine-independent clock interrupt subsystem because the MD code, e.g. decr_intr(), ideally shouldn't need to know anything about when the next event is scheduled to occur. The most obvious solution to this problem that I can think of is to instead postpone clock interrupt work until the next time our priority level drops below IPL_CLOCK. This is something we can do from the MD code without any knowledge of when the next clock interrupt event is scheduled to occur. So: - Add a new boolean, ci_dec_deferred, to the PowerPC cpu_info struct. - If we reach decr_intr() when the CPU's priority level is too high, set ci_dec_deferred, clear the DEC exception, and return. - If we reach decr_intr() and the CPU's priority level is low enough, clear ci_dec_deferred and do any needed clock interrupt work. - In splx(9) (there are three different versions we need to update), check ci_dec_deferred. If it's set and our priority level is dropping below IPL_CLOCK, raise a DEC exception. Tested by me on PowerMac7,3 (openpic). Tested by miod@ on PowerMac1,1 (macintr) (`make build` completes). Tested by gkoehler@ on an unknown PowerMac (probably openpic). With lots of help from kettenis@. ok gkoehler@ miod@ |
|||
| date | 2022-07-24T11:00:22Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_aobj.c | log | diff | annotate |
| src/sys/uvm/uvm_aobj.h | log | diff | annotate | |
| src/sys/uvm/uvm_page.c | log | diff | annotate | |
| src/sys/uvm/uvm_pager.c | log | diff | annotate | |
| message |
Revert simplification of the aiodone daemon it breaks swap on arm64. Found the hard way by mlarkin@ and deraadt@. |
|||
| date | 2022-07-24T17:22:12Z | |||
|---|---|---|---|---|
| author | kn | |||
| files | src/sys/dev/cardbus/if_athn_cardbus.c | log | diff | annotate |
| src/sys/dev/pci/if_athn_pci.c | log | diff | annotate | |
| src/sys/dev/pci/pcidevs | log | diff | annotate | |
| message |
Update Atheros AR928X pcidev string The AR9280 half Mini Card (HB92) supports 5GHz as confirmed by athn(4)'s "The AR9220, AR9223 and AR9280 (codenamed Merlin) ..." paragraph. pcidevs however wrongly identifies this device as athn0 at pci2 dev 0 function 0 "Atheros AR9281" rev 0x01: apic 2 int 17 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de athn(4) says AR9281 is 2GHz only, so the first line (pcidevs string) does not match the real information on the second line (from real hardware). Looking around, the PCI Vendor ID: 168c, Product ID: 002a are described as * https://pcilookup.com/?ven=168c&dev=002a&action=submit "AR928X Wireless Network Adapter (PCI-Express)" * https://pci-ids.ucw.cz/read/PC/168c/002a calls this "AR928X Wireless Network Adapter (PCI-Express)" * https://github.com/torvalds/linux/blob/fc02cb2b37fe2cbf1d3334b9f0f0eab9431766c4/Documentation/devicetree/bindings/net/wireless/qca%2Cath9k.yaml#L27 says - pci168c,002a # AR9280 and AR9283 * https://pcisig.com/membership/member-companies?combine=168c (empty, no result) * NetBSD pcidevs is like ours product ATHEROS AR9281 0x002a AR9281 Im summary, "AR928X" seems more appropiate and matches both AR9280 and AR9281 chipsets, so use that to avoid contradicting dmesg lines: athn0 at pci2 dev 0 function 0 "Atheros AR928X" rev 0x01: apic 2 int 17 athn0: AR9280 rev 2 (2T2R), ROM rev 22, address 04:f0:21:30:37:de stsp confirms how "Atheros naming is very convoluted." Feedback sthen OK stsp |
|||
| date | 2022-07-24T17:23:23Z | |||
|---|---|---|---|---|
| author | kn | |||
| files | src/sys/dev/pci/pcidevs.h | log | diff | annotate |
| src/sys/dev/pci/pcidevs_data.h | log | diff | annotate | |
| message | regen | |||
| date | 2022-07-24T22:38:25Z | |||
|---|---|---|---|---|
| author | bluhm | |||
| files | src/sys/netinet/ip_input.c | log | diff | annotate |
| src/sys/netinet6/ip6_input.c | log | diff | annotate | |
| message |
Fix assertion for write netlock in rip6_input(). ip6_input() has shared net lock. ip_deliver() needs exclusive net lock. Instead of calling ip_deliver() directly, use ip6_ours() to queue the packet. Move the write lock assertion into ip_deliver() to catch such bugs earlier. The assertion was only triggered with IPv6 multicast forwarding or router alert hop by hop option. Found by regress test. OK kn@ mvs@ |
|||