three PRs regarding them: 17836, 17837, 17838. Did a few kernel
compiles with them just to make sure they are okay. Approved by
christos@, thanks to Dave for sending the PRs and verifying to me
that they work.
Fix the bug where the thread worker constantly looped. It was a race as
to whether or not the thread fired up or a polled/probed command happened
first, or maybe it's due to other scsipi changes, but we never set the
value that caused the fc thread worker to actually go to sleep until an
initial loop up.
This was rather ugly as it consumed nearly all CPU time available from thence
on. Bad.
This fixes a bug whereby a fast cpu with a decent cache can easily
outstrip the GT's ability to put packets on the wire, resulting in a
permanent backlog of mbufs in the Tx pending queues under heavy Tx load.
The bug was masked if the packet buffer was mapped non-cached, which
slowed down the cpu to where it couldn't keep up with the GT at 100mbit.
* Mark the actual Handspring Visor as type "VISOR" and all others
"PALM4" (notably, the Sony Clie 41 changes from Visor-type to
Palm4-type).
* For Palm4-type devices, use the GET_PALM_CONNECTION_INFORMATION
query instead of the GET_CONNECTION_INFORMATION query, and interpret
the returned data structure appropriately. This permits attaching a
ucom device to newer devices such as the Tungsten T that do not
support the Visor-style query (data structure definition gleaned
from the Linux 2.4.21 visor.c).
* Crank down UVISORBUFSIZE from 1024 to 64 to avoid a problem where
the Palm device and the USB host controller deadlock. The USB host
controller is expecting an early-end-of-transmission packet with 0
data, and the Palm doesn't send one because it's already
communicated the amount of data it's going to send in a header
(which ucom/uvisor are oblivious to). This is the problem that has
been known on the pilot-link lists as the "[Free]BSD USB problem",
but not understood.
XXX It would be better for the Palm protocol to be handled entirely
in userland via ugen, since the serial protocol abstraction isn't
really adequate for the amount of structure that's here, and the
64-byte limit is just a workaround. The pilot-link tools aren't up
to the task yet, though.
in the default disklabel and the boot message, instead of using the
value reported by the drive (which is 16383 if the drive is larger than 8G).
Should fix PR 9864
Replace with a new from-scratch port of recent OpenBSD hifn7751 source,
with changes to the crypto-framework calls to fit Sam Leffler's rework.
(Some of the attach-time changes from the previous driver were carried over).
Many thanks to Quentin Garnier (cube@cubidou.net) for testing an pre-release
of the driver and finding a couple of missing initializations.
Note that RNG support is temporarily disabled, until a potential issue
with RNG quality is investigated and resolved.
jonathan