signals delivered to a process writing to the audio device the
system: if you try
cat /dev/zero > /dev/dsp (or cat /dev/zero > /dev/pcaudio)
and press Ctrl-C : for a second or two the system appears to freeze
(e.g. the cursor will disappear if you move the mouse, xclock
blocks, etc.). I think that interrupts etc. still run so the problem
is not too terrible, but still annoying
[ The problems appears to also be in isa/pcaudio.c, though that is ignored ]
Submitted by: Luigi Rizzo <luigi@labinfo.iet.unipi.it>
which rely on u_int being defined in sys/types.h, but isn't
if _POSIX_SOURCE is defined.
This fixes the gnu/lib/libstdc++ breakage. I've successfully completed
a make world after this and a kernel (without many devices).
Highlights:
* Simple model for underlying hardware.
* Hardware basis for timekeeping can be changed on the fly.
* Only one hardware clock responsible for TOD keeping.
* Provides a real nanotime() function.
* Time granularity: .232E-18 seconds.
* Frequency granularity: .238E-12 s/s
* Frequency adjustment is continuous in time.
* Less overhead for frequency adjustment.
* Improves xntpd performance.
Reviewed by: bde, bde, bde
Uncommented css0. It compiles OK.
Moved trix0 so that it compiles OK when uncommented. Uncommented
it. Drivers with the same interrupt handler must be together in
config files so that config(8)'s simple avoidance of redundant
declarations of interrupt handlers works (config emits a declaration
unless it would duplicate the previous one).
Commented out NO_LKM. Negative options should not be configured
in LINT. There should be no negative options for subsystems.
LKMs should never have been standard or the default.
so_error is set, clear it before returning it. The behavior
introduced in 4.3-Reno (to not clear so_error) causes potentially
transient errors (e.g. ECONNREFUSED if the other end hasn't opened
its socket yet) to be permanent on connected datagram sockets that
are only used for writing.
(soreceive() clears so_error before returning it, as does
getsockopt(...,SO_ERROR,...).)
Submitted by: Van Jacobson <van@ee.lbl.gov>, via a comment in the vat sources.
FAT32 partitions. Unfortunately, we looked around here at
Walnut Creek CDROM for any newer FAT32-supporting versions
of Win95 and we were unsuccessful; only the older stuff here.
So this is untested beyond simply making sure it compiles and
someone with access to an actual FAT32 fs will have
to let us know how well it actually works.
Submitted by: Dmitrij Tejblum <dima@tejblum.dnttm.rssi.ru>
Obtained from: NetBSD
