There is a number of devices that are compliant, of which the 3Com 5605 is
has been verified to work.
The driver is not perfect yet, but should be able to get you somewhere.
The driver was originally written by Lennart Augustsson, but Mike Smith
and Mike Meyer <mwm@mired.org> did the porting.
3.3volt PCI/cardbus chipsets similar to the 98715 (and they have
512-bit hash tables). Also update the man page to mention the 98727/98732
and the SOHOware SFA110A Rev B4 card with the 98715AEC-C chip.
entropy estimation, but causes an immediate reseed after the input
(read in sizeof(u_int64_t) chunks) is "harvested".
This will be used in the reboot "reseeder", coming in another
commit. This can be used very effectively at any time you think
your randomness is compromised; something like
# (ps -gauxwww; netstat -an; dmesg; vmstat -c10 1) > /dev/random
will give the attacker something to think about.
non-disconnecting command. Interestingly enough, of the other flavors
of the 7.65 f/w (the dual-id and multi-id flavor)- the dual-id doesn't
hang (they're also supposed to be the same except for supporting dual
or multi-id capture!), but other things are questionable as well.
which differ slightly from the Macronix MX98715AEC chip on the sample
adapter that I have in that the multicast hash table is only 128 bits
wide instead of 512. New adapters are popping up with this chip, and
due to improper handling of the smaller hash table, broadcast packets
were not being received correctly.
ether_ifdetach().
The former consolidates the operations of if_attach(), ng_ether_attach(),
and bpfattach(). The latter consolidates the corresponding detach operations.
Reviewed by: julian, freebsd-net
associated patch to XFree86 allows the X server to work with this chipset
on FreeBSD. Additional work will include porting the Linux 3D driver.
Submitted by: Ruslan Ermilov <ru@FreeBSD.org>
the gating of system calls that cause modifications to the underlying
filesystem. The gating can be enabled by any filesystem that needs
to consistently suspend operations by adding the vop_stdgetwritemount
to their set of vnops. Once gating is enabled, the function
vfs_write_suspend stops all new write operations to a filesystem,
allows any filesystem modifying system calls already in progress
to complete, then sync's the filesystem to disk and returns. The
function vfs_write_resume allows the suspended write operations to
begin again. Gating is not added by default for all filesystems as
for SMP systems it adds two extra locks to such critical kernel
paths as the write system call. Thus, gating should only be added
as needed.
Details on the use and current status of snapshots in FFS can be
found in /sys/ufs/ffs/README.snapshot so for brevity and timelyness
is not included here. Unless and until you create a snapshot file,
these changes should have no effect on your system (famous last words).
with splhigh(). However, the entropy-harvesting routine needs pretty
serious irq-protection, as it is called out of irq handlers etc.
Clues given by: bde
structure; remind myself in the cooments. Also regroup all the Yarrow
variables at the top of the variable list; they are "special".
(no functional change).
(I had been busy for my own research activity until the last weekend)
Supported devices:
SB Midi Port (sbc + midi)
SB OPL3 (sbc + midi)
16550 UART (midi, needs a trick in your hint)
CS461x Midi Port (csa + midi)
OSS-compatible sequencer (seq)
Supported playing software:
playmidi (We definitely need more)
Notes:
/dev/midistat now reports installed midi drivers. /dev/sndstat reports
only pcm drivers. We need the new name(pcmstat?).
EMU8000(SB AWE) does not sound yet but does get probed so that the OPL3
synth on an AWE card works.
TODO:
MSS/PCI bridge drivers
Midi-tty interface to support general serial devices
Modules
stack. It's bad for your machine's health.
Make the two huge structs in reseed() static to prevent crashes. This
is the bug that people have been running into and panic()ing on for the
past few days.
Reviewed by: phk
are working. Add a small blurb about XE_DEBUG as it might be useful
to some people troubelshooting problems in the future.
Submitted by: "Kevin Oberman" <oberman@es.net>
sure that it really is by issuing a ISPCTL_ABORT_CMD just on the
off chance the f/w will start it up again and, ha ha, start using
the DMA resources we gave it but are now taking away.
after the acquisition of any advisory locks. This fix corrects a case
in which a process tries to open a file with a non-blocking exclusive
lock. Even if it fails to get the lock it would still truncate the
file even though its open failed. With this change, the truncation
is done only after the lock is successfully acquired.
Obtained from: BSD/OS
