- always enable options MIPS3_ENABLE_CLOCK_INTR and just clear the compare
register in cpu_intr() to make CLKF_BASE() works
properly
- prepare only possible number of cpu_inttab
- use macro for interrupt priority number passed to arc_set_intr()
to avoid confusion
- merge arc_hardware_intr() into cpu_intr()
- check independent timer interrupt first in cpu_intr()
- tweak MIPS_SR_INT_IE before calling hardclock timer handlers so that
spllowersoftclock(9) will be invoked properly in hardclock(9)
- reenable interrupt for timer in cpu_intr() rather than each timer handlers
okay'ed by soda.
Note the real fix is to make CLKF_BASE() check all independent
interrupt sources including jazz and isa devices.
the splay tree has been added for these types. Fix kern/33797 by
Geoff C. Wing.
While here also fix writes the same way (probably broken for 2 years),
and properly implement KERNFS_XREAD.
The IPsec code could probably be moved out now, and use kernfs_alloctype().
the precision of getnanotime() is not suitable for file timestamps.
esp. when it's nfs-exported.
- introduce vfs_timestamp().
(the name is from freebsd. currently merely a wrapper of nanotime())
- for ufs-like filesystems, use it rather than getnanotime().
XXX check other filesystems.
2) Modify pnpbus attachment code to record the chipid of the device if it
has one.
3) Change the clock probes to use the chipid, rather than relying on
potentially untrustworthy subtype and interface.
4) Add decoding of memory ranges to the RESIDUAL_DUMP code.
5) Add a we@pnpbus device to allow netbooting and root device detection
from an IBM we ethernet. (it will only work if your firmware detects it)
6) Because I moved the pnpbus probe to occur prior to pci and isa, it
screwed up the root device detection and firmware path building code.
Completely rewrite the fw-path detection code to deal with this.
PIIX support to release its mapping on the edge/level control registers.
Now that these are guaranteed to be unmapped, capture and restore the
registers in piixpcib(4)'s powerhook. The same will need to be done on a
per-chipset basis.
Concerns were raised about calling pci_intr_fixup on resume WRT hotplug
devices, so this has been removed.
Ok cube@.
backend for timecounters.
Due to known bugs in some chipsets, always read until we get 3 successive
samples which are monotonic, as FreeBSD does in its "safe" variant.
This can be refined later, either by chipset quirks or by a test (as
FreeBSD does).
and INSTALL_SMALL. Since floppy images have to fit on one floppy, we
have to really cut down on the drivers on that image, but people
netbooting don't have that problem, so they deserve a more featured
kernel to install with. (namely one with raid support and more ethernet
drivers)
Otherwise, if there are two resources definitions of the same type in _CRS,
the same one from _PRS will be used twice, which of course leads to errors.
Note: _PRS is Possible Resources Set
_CRS is Current Resources Set
XXX acpi_allocate_resources is still very weak, e.g. it completely ignores
StartDependentFn entries which are kind of a switch. But at least it's
slightly better that way.
Tested by jmcneill@.
ntp on my 7248, however, my 7043-140 is still a bit flaky. I suspect the
only way to fix the 7043 is going to be writing a timecounter driver for
the 8254 present on these machines. Either way, this makes some of the
machines better, and the other machines are still about the same as they
were before, so it's a net gain for the port.
partitions. We do this by checking the NetBSD label to see if the
boot partition is of type RAID. If so, we offset reads from the
disk so that the kernel image can be read.
Note that with this code, sun4 machines (with PROM monitor) will only
boot from RAID if the RAID partition is the first one on the disk.
Tested on a SPARCstation 20, a SPARCstation 2 and a 4/330.
> The driver for the family of Promise SATA controllers,
> /usr/src/sys/dev/pci/pdcsata.c is not very robust when it comes to handling
> transient drive errors, or interrupt hickups when the card is under load.
> Worse, my experience seems to indicate, and the Linux driver confirms,
> that these cards tend to fall over rather frequently during high load
> operations or if drives unexpectedly reset or go to sleep. Symptoms
> include interupt timeouts during heavy load, the inability to reset drives
> if they go to sleep, and a failure of the card to generate interrupts at
> all if the interrupt load gets too high.
