exist on other architectures yet.
- While I'm here, fix the formatting of the options line. The keyword
"options" should be followed by a space and then a tab, not 2 tabs.
by default, yet.
- Replace "graphics cards" with "framebuffers" in the description
of creator(4) in order to make it uniform with the description of
machfb(4) and the latter occur both on-board and as add-on cards.
which doesn't assume a hardware cursor on __sparc64__ rather than on
DEV_CREATOR. If we want to include more than one framebuffer driver in
e.g. the GENERIC kernel all drivers have to work the same way. Now that
DEV_CREATOR is no longer used remove it from options.sparc64.
eeprom_ebus_attach() and eeprom_sbus_attach() into eeprom_attach()
respectively. Since the introduction of the ofw_bus interface some
time ago and now that ebus(4) also uses SYS_RES_MEMORY for the
memory resources since ebus.c rev. 1.22 there is no longer a
need to have separate front-ends for ebus(4), fhc(4) and sbus(4).
- Fail gracefully instead of panicing when the model can't be
determined.
- Don't leak resources when mk48txx_attach() fails.
- Use FBSDID.
front-end and the LSI64854 and NCR53C9x code in case one of these
functions fails. Add detach functions to these parts and make esp(4)
detachable.
- Revert rev. 1.7 of esp_sbus.c, since rev. 1.34 of sbus.c the clockfreq
IVAR defaults to the per-child values.
- Merge ncr53c9x.c rev. 1.111 from NetBSD (partial):
On reset, clear state flags and the msgout queue.
In NetBSD code to notify the upper layer (i.e. CAM in FreeBSD) on reset
was also added with this revision. This is believed to be not necessary
in FreeBSD and was not merged.
This makes ncr53c9x.c to be in sync with NetBSD up to rev. 1.114.
- Conditionalize the LSI64854 support on sbus(4) only instead of sbus(4)
and esp(4) as it's also required for the 'dma', 'espdma' and 'ledma'
busses/devices as well as the 'SUNW,bpp' device (printer port) which
all hang off of sbus(4).
- Add a driver for the 'dma', 'espdma' and 'ledma' (pseudo-)busses/
devices. These busses and devices actually represent the LSI64854 DMA
engines for the ESP SCSI and LANCE Ethernet controllers found on the
SBus of Ultra 1 and SBus add-on cards. With 'espdma' and 'ledma' the
'esp' and 'le' devices hang off of the respective DMA bus instead of
directly from the SBus. The 'dma' devices are either also used in this
manner or on some add-on cards also as a companion device to an 'esp'
device which also hangs off directly from the SBus. With the latter
variant it's a bit tricky to glue the DMA engine to the core logic of
the respective 'esp' device. With rev. 1.35 of sbus.c we are however
guaranteed that such a 'dma' device is probed before the respective
'esp' device which simplifies things a lot. [1]
- In the esp(4) SBus front-end read the part-unique ID code of Fast-SCSI
capable chips the right way. This fixes erroneously detecting some
chips as FAS366 when in fact they are not. Add explicit checks for the
FAS100A, FAS216 and FAS236 variants instead treating all of these as
ESP200. That way we can correctly set the respective Fast-SCSI config
bits instead of driving them out of specs. This includes adding the
FAS100A and FAS236 variants to the NCR53C9x core code. We probably
still subsume some chip variants as ESP200 while in fact they are
another variant which however shouldn't really matter as this will
only happen when these chips are driven at 25MHz or less which implies
not being able to run Fast-SCSI. [3]
- Add a workaround to the NCR53C9x interrupt handler which ignores the
stray interrupt generated by FAS100A when doing path inquiry during
boot and which otherwiese would trigger a panic.
- Add support for the 'esp' devices hanging off of a 'dma' or 'espdma'
busses or which are companions of 'dma' devices to esp(4). In case of
the variants that hang off of a DMA device this is a bit hackish as
esp(4) then directly uses the softc of the respective parent to talk
to the DMA engine. It might make sense to add an interface for this
in order to implement this in a cleaner way however it's not yet clear
how the requirements for the LANCE Ethernet controllers are and the
hack works for now. [2]
This effectively adds support for the onboard SCSI controller in
Ultra 1 as well as most of the ESP-based SBus add-on cards to esp(4).
With this the code for supporting the Performance Technologies SBS430
SBus SCSI add-on cards is also largely in place the remaining bits
were however omitted as it's unclear from the NetBSD how to couple
the DMA engine and the core logic together for these cards.
Obtained from: OpenBSD [1]
Obtained from: NetBSD [2]
Clue from: BSD/OS [3]
Reviewed by: scottl (earlier version)
Tested with: FSBE/S add-on card (FAS236), SSHA add-on card (ESP100A),
Ultra 1 (onboard FAS100A), Ultra 2 (onboard FAS366)
- Move MD files into <arch>/<arch>.
- Move bus dependent files into <arch>/<bus>.
Rename some files to more suitable names.
Repo-copied by: peter
Discussed with: imp
access to POSIX Semaphores:
mac_init_posix_sem() Initialize label for POSIX semaphore
mac_create_posix_sem() Create POSIX semaphore
mac_destroy_posix_sem() Destroy POSIX semaphore
mac_check_posix_sem_destroy() Check whether semaphore may be destroyed
mac_check_posix_sem_getvalue() Check whether semaphore may be queried
mac_check_possix_sem_open() Check whether semaphore may be opened
mac_check_posix_sem_post() Check whether semaphore may be posted to
mac_check_posix_sem_unlink() Check whether semaphore may be unlinked
mac_check_posix_sem_wait() Check whether may wait on semaphore
Update Biba, MLS, Stub, and Test policies to implement these entry points.
For information flow policies, most semaphore operations are effectively
read/write.
Submitted by: Dandekar Hrishikesh <rishi_dandekar at sbcglobal dot net>
Sponsored by: DARPA, McAfee, SPARTA
Obtained from: TrustedBSD Project
a regular IPI vector, but this vector is blocked when interrupts are disabled.
With "options KDB_STOP_NMI" and debug.kdb.stop_cpus_with_nmi set, KDB will
send an NMI to each CPU instead. The code also has a context-stuffing
feature which helps ddb extract the state of processes running on the
stopped CPUs.
KDB_STOP_NMI is only useful with SMP and complains if SMP is not defined.
This feature only applies to i386 and amd64 at the moment, but could be
used on other architectures with the appropriate MD bits.
Submitted by: ups
here on in, if_ndis.ko will be pre-built as a module, and can be built
into a static kernel (though it's not part of GENERIC). Drivers are
created using the new ndisgen(8) script, which uses ndiscvt(8) under
the covers, along with a few other tools. The result is a driver module
that can be kldloaded into the kernel.
A driver with foo.inf and foo.sys files will be converted into
foo_sys.ko (and foo_sys.o, for those who want/need to make static
kernels). This module contains all of the necessary info from the
.INF file and the driver binary image, converted into an ELF module.
You can kldload this module (or add it to /boot/loader.conf) to have
it loaded automatically. Any required firmware files can be bundled
into the module as well (or converted/loaded separately).
Also, add a workaround for a problem in NdisMSleep(). During system
bootstrap (cold == 1), msleep() always returns 0 without actually
sleeping. The Intel 2200BG driver uses NdisMSleep() to wait for
the NIC's firmware to come to life, and fails to load if NdisMSleep()
doesn't actually delay. As a workaround, if msleep() (and hence
ndis_thsuspend()) returns 0, use a hard DELAY() to sleep instead).
This is not really the right thing to do, but we can't really do much
else. At the very least, this makes the Intel driver happy.
There are probably other drivers that fail in this way during bootstrap.
Unfortunately, the only workaround for those is to avoid pre-loading
them and kldload them once the system is running instead.
o Remove the clock interface. Not only does it conflict with the MI
version when device genclock is added to the kernel, it was also
not possible to have more than 1 clock device. This of course would
have been a problem if we actually had more than 1 clock device.
In short: we don't need a clock interface and if we do eventually,
we should be using the MI one.
o Rewrite inittodr() and resettodr() to take into account that:
1) We use the EFI interface directly.
2) time_t is 64-bit and we do need to make sure we can determine
leap years from year 2100 and on. Add a nice explanation of
where leap years come from and why.
3) This rewrite happened in 2005 so any date prior to 1/1/2005
(either M/D/Y or D/M/Y) is bogus. Reprogram the EFI clock with
1/1/2005 in that case.
4) The EFI clock has a high probability of being correct, so
only (further) correct the EFI clock when the file system time
is larger. That should never happen in a time-synchronised world.
Complain when EFI lost 2 days or more.
Replace the copyright notice now that I (pretty much) rewrote all of
this file.
- Split core DRM routines back into their own module, rather than using the
nasty templated system like before.
- Development-class R300 support in radeon driver (requires userland pieces, of
course).
- Mach64 driver (haven't tested in a while -- my mach64s no longer fit in the
testbox). Covers Rage Pros, Rage Mobility P/M, Rage XL, and some others.
- i915 driver files, which just need to get drm_drv.c fixed to allow attachment
to the drmsub device. Covers i830 through i915 integrated graphics.
- savage driver files, which should require minimal changes to work. Covers the
Savage3D, Savage IX/MX, Savage 4, ProSavage.
- Support for color and texture tiling and HyperZ features of Radeon.
Thanks to: scottl (much p4 handholding)
Jung-uk Kim (helpful prodding)
PR: [1] kern/76879, [2] kern/72548
Submitted by: [1] Alex, lesha at intercaf dot ru
[2] Shaun Jurrens, shaun at shamz dot net
when using an APIC. This simplifies the APIC code somewhat and also allows
us to be pedantically more compliant with ACPI which mandates no use of
mixed mode.
Also, move the -I stuff to the centralized kern.pre.mk. However, it
might be better to add these flags to files.conf. This is a short
term fix to fix the broken builds on my machine (I don't have a valid
/sys link).
3ware's 9xxx series controllers. This corresponds to
the 9.2 release (for FreeBSD 5.2.1) on the 3ware website.
Highlights of this release are:
1. The driver has been re-architected to use a "Common Layer"
(all tw_cl* files), which is a consolidation of all OS-independent
parts of the driver. The FreeBSD OS specific portions of the
driver go into an "OS Layer" (all tw_osl* files).
This re-architecture is to achieve better maintainability, consistency
of behavior across OS's, and better portability to new OS's (drivers
for new OS's can be written by just adding an OS Layer that's specific
to the OS, by complying to a "Common Layer Programming Interface" API.
2. The driver takes advantage of multiple processors.
3. The driver has a new firmware image bundled, the new features of which
include Online Capacity Expansion and multi-lun support, among others.
More details about 3ware's 9.2 release can be found here:
http://www.3ware.com/download/Escalade9000Series/9.2/9.2_Release_Notes_Web.pdf
Since the Common Layer is used across OS's, the FreeBSD specific include
path for header files (/sys/dev/twa) is not part of the #include pre-processor
directive in any of the source files. For being able to integrate twa into
the kernel despite this, Makefile.<arch> has been changed to add the include
path to CFLAGS.
Reviewed by: scottl
