designated initializers.
I have not built every extant kernel so I have probably broken at
least one build; however I've also found and fixed some wrong
cdevsw/bdevsw entries so even if so I think we come out ahead.
The 2nd byte of ISO-2022-JP must be 0x21-0x7e. Especially,
the character code less than 0x2121 causes SEGV, because a
font address points outside of the CGROM.
Reported by tsutsui@. Should be pulled up to netbsd-6.
Tested both fdNa (1232KB, 1024bytes/sector, 8sectors/track) and
fdNc (1200KB, 512bytes/sector, 15sectors/track) format on X68030
using fdformat(1).
Finally we can prepare NetBSD/x68k install floppies without Human68k
(except actual initial bootstrap).
error paths, as sys/dev/isa/fd.c does. Fixes unexpected DMAC errors
(and possible VM panic due to un-unloaded dmamap) on the first floppy
access after read/write errors.
rather than DMAC_CCR_HLT (halt operation).
DMAC_CCR_HLT doesn't abort DMA xfers but only suspends DMA ops
(i.e. clearing HLT bit will resume DMA xfers), so previously
DMAC error always occurs on the next DMA xfer ops after
dmac_abort_xfer() is called.
Also suppress DMAC error messages in dmac_error() if it's caused
by software abort command because it can happen during normal
audio play/record DMA ops in vs(4) driver.
as sys/dev/sun/event_var.h does.
Fixes immediate KASSERT(mutex_owned(proc_lock)) panic during running Xserver
on DIAGNOSTIC kernel.
Should be pulled up to netbsd-6.
to avoid confusion.
Previous one (fdc->sc_addr + fddata) wasn't a right address for
the FDC's data register but one for the command register by accident,
but FDC ignores A0 address input (connected to A1 of x68k address bus)
during DMA xfer (i.e. when DACK is asserted) so it happened to work
as expected on the real X680x0 hardware, but caused trouble on emulators.
The inconsistency was found by Y.Sugahara during debugging XM6i emulator
(and it will be fixed in the next release).
FDC behavior during DMA is confirmed by uPD72068 hardware application note.
XXX: There is no proper MI API to specify DMA address for DMA controller
(like MC68450) to access devices mapped to memory space by bus_space(9).
on machines with extended high memories:
- dev/fd.c:
- add missing bus_dmamap_sync(9) POSTREAD/POSTWRITE ops
- x68k/machdep.c:
- update avail_end variable (which is used to check DMA'able memory range
in intio.c) properly per probed extended memory regions
The problem was found during debugging XM6i's FDC emulation by
Y.Sugahara, isaki@, and me.
Should be pulled up to netbsd-6.
Based on isaki@'s patch and debugged by both isaki@ and tsutsui@.
PSX16550 specific hardware infomation is taken from Human68k's PSXIO driver:
http://retropc.net/x68000/software/hardware/psx16550/
XXX1: TL16C550C seems to have some timing critical issue around THRE interrupt
XXX2: auto hardware flow control of TL16C550 is not implemented in MI com(4)
1) Move core entropy-pool code and source/sink/sample management code
to sys/kern from sys/dev.
2) Remove use of NRND as test for presence of entropy-pool code throughout
source tree.
3) Remove use of RND_ENABLED in device drivers as microoptimization to
avoid expensive operations on disabled entropy sources; make the
rnd_add calls do this directly so all callers benefit.
4) Fix bug in recent rnd_add_data()/rnd_add_uint32() changes that might
have lead to slight entropy overestimation for some sources.
5) Add new source types for environmental sensors, power sensors, VM
system events, and skew between clocks, with a sample implementation
for each.
ok releng to go in before the branch due to the difficulty of later
pullup (widespread #ifdef removal and moved files). Tested with release
builds on amd64 and evbarm and live testing on amd64.
power switch handler of pow(4) deleted before.
Benefits than pow(4):
- separate a front switch (= powsw0) and an EXPWON line (= powsw1)
completely. Only powsw0 is enabled in GENERIC by default.
- prevent chattering in some hardware individuals.
thank you for a report and a test: Yasushi Oshima and Y.Sugahara.
the original ad-audiomp branch notes:
Add MP locking to the audio drivers.
Making the audio drivers MP safe is necessary before efforts
can be made to make the VM system MP safe.
The are two locks per device instance, an ISR lock and
a character device lock. The ISR lock replaces calls to
splaudio()/splx(), and will be held across calls to device
methods which were called at splaudio() before (e.g.
trigger_output). The character device lock is held across
calls to nearly all of the methods, excluding some only
used for initialization, e.g. get_locks.
Welcome to 5.99.57.
<20111022023242.BA26F14A158@mail.netbsd.org>. This change includes
the following:
An initial cleanup and minor reorganization of the entropy pool
code in sys/dev/rnd.c and sys/dev/rndpool.c. Several bugs are
fixed. Some effort is made to accumulate entropy more quickly at
boot time.
A generic interface, "rndsink", is added, for stream generators to
request that they be re-keyed with good quality entropy from the pool
as soon as it is available.
The arc4random()/arc4randbytes() implementation in libkern is
adjusted to use the rndsink interface for rekeying, which helps
address the problem of low-quality keys at boot time.
An implementation of the FIPS 140-2 statistical tests for random
number generator quality is provided (libkern/rngtest.c). This
is based on Greg Rose's implementation from Qualcomm.
A new random stream generator, nist_ctr_drbg, is provided. It is
based on an implementation of the NIST SP800-90 CTR_DRBG by
Henric Jungheim. This generator users AES in a modified counter
mode to generate a backtracking-resistant random stream.
An abstraction layer, "cprng", is provided for in-kernel consumers
of randomness. The arc4random/arc4randbytes API is deprecated for
in-kernel use. It is replaced by "cprng_strong". The current
cprng_fast implementation wraps the existing arc4random
implementation. The current cprng_strong implementation wraps the
new CTR_DRBG implementation. Both interfaces are rekeyed from
the entropy pool automatically at intervals justifiable from best
current cryptographic practice.
In some quick tests, cprng_fast() is about the same speed as
the old arc4randbytes(), and cprng_strong() is about 20% faster
than rnd_extract_data(). Performance is expected to improve.
The AES code in src/crypto/rijndael is no longer an optional
kernel component, as it is required by cprng_strong, which is
not an optional kernel component.
The entropy pool output is subjected to the rngtest tests at
startup time; if it fails, the system will reboot. There is
approximately a 3/10000 chance of a false positive from these
tests. Entropy pool _input_ from hardware random numbers is
subjected to the rngtest tests at attach time, as well as the
FIPS continuous-output test, to detect bad or stuck hardware
RNGs; if any are detected, they are detached, but the system
continues to run.
A problem with rndctl(8) is fixed -- datastructures with
pointers in arrays are no longer passed to userspace (this
was not a security problem, but rather a major issue for
compat32). A new kernel will require a new rndctl.
The sysctl kern.arandom() and kern.urandom() nodes are hooked
up to the new generators, but the /dev/*random pseudodevices
are not, yet.
Manual pages for the new kernel interfaces are forthcoming.
Probably the combination of pow(4) ioctl and rtcalarm(8) does
not work for a long time, and nobody uses them.
I'll rewrite a part about power switch handler as a new device.
could cause mutex error panic, so defer it via softint(9).
This should fix panic on heavy key strokes during running Xserver.
Should be pulled up to netbsd-5.
XXX: amiga and atari might have the similar problem?
Problem was reported by isaki@.
On X680x0 (and most other machines other than ISA FDC),
the ready line from FDD is connected to FDC and fdc driver can
be notified of the ready state after fd_set_motor() by interrupts.
In this case no need to use callout(9) to wait the FDD motor stabilized,
and the callout(9) method used in ISA fdc(4) driver rather caused
infinite unhandled interrupts since callout(9) was no longer invoked
during interrupt storm after vmlocking2 merge, I guess.
Should be pulled up to netbsd-5.
copyright. Confirmed by Mike Hibler, mike at cs.utah.edu - thanks!
Also, merge UCB and Utah copyright texts back into one, as they
originally were.
Extra verification by snj@.
M680[12346] are now available from opt_m68k_arch.h. FPSP meantioned
in the PR has already been fixed, and i could not find any more.
i built these kernels to ensure i did not break their builds:
amiga: GENERIC DRACO
atari: HADES FALCON MILAN-PCIIDE
mac68k: GENERIC
sun2: GENERIC
sun3: GENERIC GENERIC3X
cesfic: attempted GENERIC, does not build due to lack of machine/bus.h
hp300: GENERIC
luna68k: GENERIC
mvme68k: GENERIC
news68k: GENERIC
next68k: GENERIC
x68k: GENERIC
M680[12346] are now available from opt_m68k_arch.h. FPSP meantioned
in the PR has already been fixed, and i could not find any more.
i built these kernels to ensure i did not break their builds:
amiga: GENERIC DRACO
atari: HADES FALCON MILAN-PCIIDE
mac68k: GENERIC
sun2: GENERIC
sun3: GENERIC GENERIC3X
cesfic: attempted GENERIC, does not build due to lack of machine/bus.h
hp300: GENERIC
luna68k: GENERIC
mvme68k: GENERIC
news68k: GENERIC
next68k: GENERIC
x68k: GENERIC
especially on RTL8019AS which is also used for non-ISA local bus of
embedded controllers and some m68k machines like atari and x68k.
* move RTL8019 probe and attach code from each bus attachment
to MI ne2000_detect() and ne2000_attach()
* change a method for backend and attachment to specify 8 bit mode
to use a new sc->sc_quirk member, instead of sc->sc_dmawidth
* handle more NE2000 8 bit mode specific settings, including
bus_space(9) access width and available size of buffer memory
* add a function to detect NE2000 8 bit mode
(disabled by default, but enalbed by options NE2000_DETECT_8BIT
to avoid possible regression on various ISA clones)
* fix ipkdb attachment accordingly (untested)
Tested on two NE2000 ISA variants (RTL8019AS and another clone named UL0001)
in both 8 bit and 16 bit mode on i386. "Looks good" from nonaka@.
See my post on tech-kern for details:
http://mail-index.NetBSD.org/tech-kern/2010/02/26/msg007423.html
#if NBPFILTER is no longer required in the client. This change
doesn't yet add support for loading bpf as a module, since drivers
can register before bpf is attached. However, callers of bpf can
now be modularized.
Dynamically loadable bpf could probably be done fairly easily with
coordination from the stub driver and the real driver by registering
attachments in the stub before the real driver is loaded and doing
a handoff. ... and I'm not going to ponder the depths of unload
here.
Tested with i386/MONOLITHIC, modified MONOLITHIC without bpf and rump.
