CIS MAC only on error.
(NetBSD these days tries to read the MAC address from the PCMCIA
CIS. Prism cards made by Senao set the MAC in every PCMCIA CIS to
00:02:6f:00:02:15. In a network of Senao cards, this causes MAC
duplication.)
(from an offset to the end of the packet), the pseudo-header checksum must be
calculated by software. So, provide it in the TCP/UDP header when
M_CSUM_NO_PSEUDOHDR is set in the interface's if_csum_flags_tx.
The start offset, the end of the IP header, is also provided in the high 16
bits of pkthdr.csum_data. Such that the driver need not examine the packet
at all.
XXX At the request of Jonathan Stone, note that sharing of if_csum_flags_tx &
pkthdr.csum_flags for checksum quirks should be re-evaluated.
the handler and disable them again right after the handler returns.
we don't want another hardware interrupt coming in while we're mucking
with the list pointers. also, clear the intrhand's ih_pending pointer
before calling the handler rather than after, so that if another interrupt
comes in while the handler is running, we can put the intrhand back on
the list so it will be called again.
in send_softint(), disable interrupts via %pstate instead of %pil, so that
hardware interrupts at higher levels are blocked while we manipulate the
intrpending list. also, if the intrhand already has ih_pending set,
don't bother poking the SET_SOFTINT register again, since being on the list
implies that there is already a softint pending in the hardware.
these appear to fix PR 21750 (the "sleep forever" problem).
while I'm here, remove more vestiges of the !INTRLIST softint stuff
(code and comments). and in sparc64_ipi_flush_all(), interrupts are
already disabled so we don't need to fiddle with %pstate.
which was missed due to a sticky tag in my local tree.
pointed by Izumi Tsutsui.
> remove uvm_map_protect from cpu_startup of several ports.
> - they shouldn't be needed with the current fault handler.
> - they causes assertion failure with the recent vm_map implementation.
>
> discussed on tech-kern@. reviewed by Chuck Silvers.
> PR/29179 from Julio M. Merino Vidal.
determine if we are willing to wait for memory to come from the
diskqueuedata (dqd) and bufpool pools. Cleanup the mess related to
code calling rf_CreateDiskQueueData() with different expectations
(and/or blatent disregard) of what might happen if there were
insufficient pool resources.
christos