summaryrefslogtreecommitdiffstats
path: root/sys/i386/include
Commit message (Collapse)AuthorAgeFilesLines
* Initialize the mxcsr properly, so the initial value in a process isn'tdas2005-03-171-0/+1
| | | | just the value that was left over from some other application.
* Remove fpsetsticky(). This was added for SysV compatibility, but duedas2005-03-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | to mistakes from day 1, it has always had semantics inconsistent with SVR4 and its successors. In particular, given argument M: - On Solaris and FreeBSD/{alpha,sparc64}, it clobbers the old flags and *sets* the new flag word to M. (NetBSD, too?) - On FreeBSD/{amd64,i386}, it *clears* the flags that are specified in M and leaves the remaining flags unchanged (modulo a small bug on amd64.) - On FreeBSD/ia64, it is not implemented. There is no way to fix fpsetsticky() to DTRT for both old FreeBSD apps and apps ported from other operating systems, so the best approach seems to be to kill the function and fix any apps that break. I couldn't find any ports that use it, and any such ports would already be broken on FreeBSD/ia64 and Linux anyway. By the way, the routine has always been undocumented in FreeBSD, except for an MLINK to a manpage that doesn't describe it. This manpage has stated since 5.3-RELEASE that the functions it describes are deprecated, so that must mean that functions that it is *supposed* to describe but doesn't are even *more* deprecated. ;-) Note that fpresetsticky() has been retained on FreeBSD/i386. As far as I can tell, no other operating systems or ports of FreeBSD implement it, so there's nothing for it to be inconsistent with. PR: 75862 Suggested by: bde
* Refactor the bus_dma header files so that the interface is described inscottl2005-03-141-235/+2
| | | | | | | | | | sys/bus_dma.h instead of being copied in every single arch. This slightly reorders a flag that was specific to AXP and thus changes the ABI there. The interface still relies on bus_space definitions found in <machine/bus.h> so it cannot be included on its own yet, but that will be fixed at a later date. Add an MD <machine/bus_dma.h> for ever arch for consistency and to allow for future MD augmentation of the API. sparc64 makes heavy use of this right now due to its different bus_dma implemenation.
* Remove an OBE set of comments, fix a minor whitespace nit while here.peter2005-03-111-8/+1
|
* - Remove the BURN_BRIDGES marked support for hooking into the ISA timer 0jhb2005-03-091-4/+0
| | | | | | | | interrupt. - Remove the timer_func variable as it now has a static value of hardclock() and is only used in one place. Axe borrowed from: phk
* netchild's mega-patch to isolate compiler dependencies into a centraljoerg2005-03-0215-82/+116
| | | | | | | | | | | | | | | | place. This moves the dependency on GCC's and other compiler's features into the central sys/cdefs.h file, while the individual source files can then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42. By now, GCC and ICC (the Intel compiler) have been actively tested on IA32 platforms by netchild. Extension to other compilers is supposed to be possible, of course. Submitted by: netchild Reviewed by: various developers on arch@, some time ago
* Use a common multi-inclusion protection, and add such aru2005-02-191-4/+4
| | | | protection to alpha/include/exec.h.
* Together with the changes to compile kernels with the Intel C/C++ compilermarius2005-02-191-1/+1
| | | | | | | | | | preliminary support for using the GCC-compatibility of ICC was committed but couldn't be tested at that time due to problems with ICC itself. Since ICC 8.1 it's possible to use its GCC-compatibility under FreeBSD and it turned out that a typedef for __gnuc_va_list is required in that case. Revert the part of rev. 1.8 which #ifdef'ed out __gnuc_va_list for ICC. MFC after: 1 week
* Implement support for CPU private mappings within sf_buf_alloc().alc2005-02-131-1/+4
|
* Use the local APIC timer to drive the various kernel clocks on SMP machinesjhb2005-02-082-6/+4
| | | | | | | | | | | | | | | | | | | | | | | rather than forwarding interrupts from the clock devices around using IPIs: - Add an IDT vector that pushes a clock frame and calls lapic_handle_timer(). - Add functions to program the local APIC timer including setting the divisor, and setting up the timer to either down a periodic countdown or one-shot countdown. - Add a lapic_setup_clock() function that the BSP calls from cpu_init_clocks() to setup the local APIC timer if it is going to be used. The setup uses a one-shot countdown to calibrate the timer. We then program the timer on each CPU to fire at a frequency of hz * 3. stathz is defined as freq / 23 (hz * 3 / 23), and profhz is defined as freq / 2 (hz * 3 / 2). This gives the clocks relatively prime divisors while keeping a low LCM for the frequency of the clock interrupts. Thanks to Peter Jeremy for suggesting this approach. - Remove the hardclock and statclock forwarding code including the two associated IPIs. The bitmap IPI handler has now effectively degenerated to just IPI_AST. - When the local APIC timer is used we don't turn the RTC on at all, but we still enable interrupts on the ISA timer 0 (i8254) for timecounting purposes.
* o Move copyin()/copyout() out of i386_{get,set}_ldt() andsobomax2005-01-261-0/+8
| | | | | | | | | i386_{get,set}_ioperm() and make those APIs visible in the kernel namespace; o use i386_{get,set}_ldt() and i386_{get,set}_ioperm() instead of sysarch() in the linuxlator, which allows to kill another two stackgaps. MFC after: 2 weeks
* Tweak the ELCR support slightly. Explicitly probe the ELCR during bootjhb2005-01-181-0/+1
| | | | | | | | instead of burying that in the atpic(4) code as atpic(4) is not the only user of elcr(4). Change the elcr(4) code to export a global elcr_found variable that other code can check to see if a valid ELCR was found. MFC after: 1 month
* Introduce bus_dmamap_load_mbuf_sg(). Instead of taking a callback arg, thisscottl2005-01-071-0/+5
| | | | | | | cuts to the chase and fills in a provided s/g list. This is meant to optimize out the cost of the callback since the callback doesn't serve much purpose for mbufs since mbuf loads will never be deferred. This is just for amd64 and i386 at the moment, other arches will be coming shortly.
* /* -> /*- for copyright notices, minor format tweaks as necessaryimp2005-01-0638-50/+56
|
* Remove left over include file from stallion driver.imp2005-01-061-122/+0
|
* Expand indirect reference to BSD license with the current one.imp2005-01-061-2/+22
|
* This doesn't seem to have been used since 386BSD daysimp2005-01-061-4/+0
|
* These appear to be unused in our tree, so remove them.imp2005-01-051-45/+0
|
* Add some constants for the local APIC timer.jhb2004-12-231-0/+5
|
* Add a simple 'intrcnt_add' function that other MD code can use to add ajhb2004-12-231-0/+1
| | | | | single named counter to the interrupt counts without having to fake up an entire interrupt source.
* - Add a function to set the Task Priority Register (TPR) of the local APIC.jhb2004-12-231-10/+14
| | | | | | | | | | | | | | | Currently this is only used to initiailize the TPR to 0 during initial setup. - Reallocate vectors for the local APIC timer, error, and thermal LVT entries. The timer entry is allocated from the top of the I/O interrupt range reducing the number of vectors available for hardware interrupts to 191. Linux happens to use the same exact vector for its timer interrupt as well. If the timer vector shared the same priority queue as the IPI handlers, then the frequency that the timer vector will eventually be firing at can interact badly with the IPIs resulting in the queue filling and the dreaded IPI stuck panics, hence it being located at the top of the previous priority queue instead. - Fixup various minor nits in comments.
* Avoid more than two pending IPI interrupt vectors per local APICups2004-12-072-14/+44
| | | | | | | | | | | as this may cause deadlocks. This should fix kern/72123. Discussed with: jhb Tested by: Nik Azim Azam, Andy Farkas, Flack Man, Aykut KARA Izzet BESKARDES, Jens Binnewies, Karl Keusgen Approved by: sam (mentor)
* Change gdb_cpu_setreg() to not take the value to which to set themarcel2004-12-011-1/+1
| | | | | | | | | | | | | | | | | | | | | specified register, but a pointer to the in-memory representation of that value. The reason for this is twofold: 1. Not all registers can be represented by a register_t. In particular FP registers fall in that category. Passing the new register value by reference instead of by value makes this point moot. 2. When we receive a G or P packet, both are for writing a register, the packet will have the register value in target-byte order and in the memory representation (modulo the fact that bytes are sent as 2 printable hexadecimal numbers of course). We only need to decode the packet to have a pointer to the register value. This change fixes the bug of extracting the register value of the P packet as a hexadecimal number instead of as a bit array. The quick (and dirty) fix to bswap the register value in gdb_cpu_setreg() as it has been added on i386 and amd64 can therefore be removed and has in fact been that. Tested on: alpha, amd64, i386, ia64, sparc64
* Remove UAREA_PAGES.das2004-11-201-1/+0
| | | | Reviewed by: arch@
* Initiate deorbit burn sequence for 80386 support in FreeBSD: Removejhb2004-11-163-14/+4
| | | | 80386 (I386_CPU) support from the kernel.
* Spell _KERNEL correctly so that UP kernels are actually optimized again.jhb2004-11-121-1/+1
| | | | Submitted by: pjd
* - Use the SMP style ops for atomic_load/store() in userland so thatjhb2004-11-121-2/+1
| | | | | | | libraries and binaries will work on both UP and SMP machines. - Remove unnecessary gcc memory barrier from the UP atomic_store() op. Submitted by: bde
* - Place the gcc memory barrier hint in the right place in the 80386 versionjhb2004-11-111-8/+9
| | | | | | | | | | of atomic_store_rel(). - Use the 80386 versions of atomic_load_acq() and atomic_store_rel() that do not use serializing instructions on all UP kernels since a UP machine does need to synchronize with other CPUs. This trims lots of cycles from spin locks on UP kernels among other things. Benchmarked by: rwatson
* Begin an invasion of i386-land by amd64.peter2004-11-061-0/+11
| | | | | | Expose some of the amd64-specific sysarch functions to allow alternative implementations of the %fs/%gs code for TLS, threads, etc. USER_LDT does not exist on the amd64 kernel, so we have to implement things other ways.
* Move the code for halting the CPU (acpi_cpu_c1) into machdep files.njl2004-10-111-1/+2
| | | | | | This removes the last MD portion of acpi_cpu.c. MFC after: 2 weeks
* Make pte_load_store() an atomic operation in all cases, not just i386 PAE.alc2004-10-081-4/+16
| | | | | | | | | Restructure pmap_enter() to prevent the loss of a page modified (PG_M) bit in a race between processors. (This restructuring assumes the newly atomic pte_load_store() for correct operation.) Reviewed by: tegge@ PR: i386/61852
* Prevent the unexpected deallocation of a page table page while performingalc2004-09-291-1/+1
| | | | | | | | | | | | | pmap_copy(). This entails additional locking in pmap_copy() and the addition of a "flags" parameter to the page table page allocator for specifying whether it may sleep when memory is unavailable. (Already, pmap_copy() checks the availability of memory, aborting if it is scarce. In theory, another CPU could, however, allocate memory between pmap_copy()'s check and the call to the page table page allocator, causing the current thread to release its locks and sleep. This change makes this scenario impossible.) Reviewed by: tegge@
* Fix breakpoint handling for i386.julian2004-09-151-2/+10
| | | | | | | | | | | | | | not sure yet about 5.x... MFC if needed. Also fixes small problems with examining some registers and some specific gdb transfer problems. As the patch says: This is not a pretty patch and only meant as a temporary fix until a better solution is committed. PR: i386/71715 Submitted by: Stephan Uphoff <ups@tree.com> MFC after: 1 week
* Double the number of kernel page tables for amd64 and for i386/PAE. The oldscottl2004-09-111-2/+3
| | | | | | | | value was only enough for 8GB of RAM, the new value can do 16GB. This still isn't optimal since it doesn't scale. Fixing this for amd64 looks to be fairly easy, but for i386 will be quite difficult. Reviewed by: peter
* Turn PREEMPTION into a kernel option. Make sure that it's defined ifscottl2004-09-021-5/+0
| | | | | | FULL_PREEMPTION is defined. Add a runtime warning to ULE if PREEMPTION is enabled (code inspired by the PREEMPTION warning in kern_switch.c). This is a possible MT5 candidate.
* Give up trying to make preemption dependent on SCHED_4BSDjulian2004-09-011-4/+1
| | | | the list of breakages was getting too long
* Don't ask for this for modules. no modules need to know about preemption at ↵julian2004-09-011-1/+1
| | | | the moment
* Protect the PREEMPTION logic with #ifdef _KERNEL to fix the build.scottl2004-09-011-0/+2
|
* Only turn preemption for 4bsd.julian2004-09-011-0/+3
| | | | it's still poison for ULE.
* Give the 4bsd scheduler the ability to wake up idle processorsjulian2004-09-011-2/+0
| | | | | | when there is new work to be done. MFC after: 5 days
* Move the kernel-specific logic to adjust frompc from MI to MD. Formarcel2004-08-271-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | these two reasons: 1. On ia64 a function pointer does not hold the address of the first instruction of a functions implementation. It holds the address of a function descriptor. Hence the user(), btrap(), eintr() and bintr() prototypes are wrong for getting the actual code address. 2. The logic forces interrupt, trap and exception entry points to be layed-out contiguously. This can not be achieved on ia64 and is generally just bad programming. The MCOUNT_FROMPC_USER macro is used to set the frompc argument to some kernel address which represents any frompc that falls outside the kernel text range. The macro can expand to ~0U to bail out in that case. The MCOUNT_FROMPC_INTR macro is used to set the frompc argument to some kernel address to represent a call to a trap or interrupt handler. This to avoid that the trap or interrupt handler appear to be called from everywhere in the call graph. The macro can expand to ~0U to prevent adjusting frompc. Note that the argument is selfpc, not frompc. This commit defines the macros on all architectures equivalently to the original code in sys/libkern/mcount.c. People can take it from here... Compile-tested on: alpha, amd64, i386, ia64 and sparc64 Boot-tested on: i386
* Fix a bug in in_cksum_hdr w/o -O.obrien2004-08-251-16/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | The C code assumes that the carry bit is always kept from the previous operation. However, the pointer indexing requires another add operation. Thus, the carry bit from the first operation is tromped over by the "addl" operation that ends up following it, so the "adcl" that follows that has no effect because the carry bit is cleared before it. The result is checksum failure on received packets. The larger issue is that there isn't any other way of preventing the compiler inserting arbitrary instructions between different __asm statements (and that the commit message in revision 1.13 of in_cksum.h is wrong on this point). From http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Extended-Asm.html ---8<---8<---8<--- You can't expect a sequence of volatile asm instructions to remain perfectly consecutive. If you want consecutive output, use a single asm. Also, GCC will perform some optimizations across a volatile asm instruction; GCC does not "forget everything" when it encounters a volatile asm instruction the way some other compilers do. ---8<---8<---8<--- Also, this change also makes the ASM code much easier to read. PR: 69257 Submitted by: Mike Bristow <mike@urgle.com>, Qing Li <qing.li@bluecoat.com>
* Increase the scaling of VM_KMEM_SIZE_MAX.obrien2004-08-161-1/+1
| | | | Submitted by: alc
* Add an "options MP_WATCHDOG" to i386. This option allows one of therwatson2004-08-151-0/+34
| | | | | | | | | | | | | | | | | | | | | | | logical CPUs on a system to be used as a dedicated watchdog to cause a drop to the debugger and/or generate an NMI to the boot processor if the kernel ceases to respond. A sysctl enables the watchdog running out of the processor's idle thread; a callout is launched to reset a timer in the watchdog. If the callout fails to reset the timer for ten seconds, the watchdog will fire. The sysctl allows you to select which CPU will run the watchdog. A sample "debug.leak_schedlock" is included, which causes a sysctl to spin holding sched_lock in order to trigger the watchdog. On my Xeons, the watchdog is able to detect this failure mode and break into the debugger, which cannot otherwise be done without an NMI button. This option does not currently work with sched_ule due to ule's push notion of scheduling, similar to machdep.hlt_logical_cpus failing to work with that scheduler. On face value, this might seem somewhat inefficient, but there are a lot of dual-processor Xeons with HTT around, so using one as a watchdog for testing is not as inefficient as one might fear.
* Instead of calling ia32_pause() conditionally on __i386__ or __amd64__mux2004-08-031-2/+3
| | | | | | | | | being defined, define and use a new MD macro, cpu_spinwait(). It only expands to something on i386 and amd64, so the compiled code should be identical. Name of the macro found by: jhb Reviewed by: jhb
* Add definitions for TLS relocations.dfr2004-08-021-2/+22
|
* Optimize intr_execute_handlers() by combining the pic_disable_source() andscottl2004-08-021-1/+7
| | | | | | | | | | | | | | pic_eoi_source() into one call. This halves the number of spinlock operations and indirect function calls in the normal case of handling a normal (ithread) interrupt. Optimize the atpic and ioapic drivers to use inlines where appropriate in supporting the intr_execute_handlers() change. This knocks 900ns, or roughly 1350 cycles, off of the time spent servicing an interrupt in the common case on my 1.5GHz P4 uniprocessor system. SMP systems likely won't see as much of a gain due to the ioapic being more efficient than the atpic. I'll investigate porting this to amd64 soon. Reviewed by: jhb
* Turn off PREEMPTION by default while it gets debugged. It's been causingscottl2004-08-011-0/+3
| | | | | 4 weeks of problems including deadlocks and instant panics. Note that the real bugs are likely in the scheduler.
* Break out the MI part of the /dev/[k]mem and /dev/io drivers intomarkm2004-08-012-0/+73
| | | | | | | | their own directory and module, leaving the MD parts in the MD area (the MD parts _are_ part of the modules). /dev/mem and /dev/io are now loadable modules, thus taking us one step further towards a kernel created entirely out of modules. Of course, there is nothing preventing the kernel from having these statically compiled.
* Pass a thread argument into cpu_critical_{enter,exit}() rather thanrwatson2004-07-271-6/+6
| | | | | | | | | dereference curthread. It is called only from critical_{enter,exit}(), which already dereferences curthread. This doesn't seem to affect SMP performance in my benchmarks, but improves MySQL transaction throughput by about 1% on UP on my Xeon. Head nodding: jhb, bmilekic
OpenPOWER on IntegriCloud