summaryrefslogtreecommitdiffstats
path: root/sys/amd64
Commit message (Collapse)AuthorAgeFilesLines
* Remove COMPAT_43 from GENERIC (and other kernel configs). For amd64 there'snetchild2006-06-151-1/+0
| | | | | | | | | | | | | | | | | | | | | | an explicit comment that it's needed for the linuxolator. This is not the case anymore. For all other architectures there was only a "KEEP THIS". I'm (and other people too) running a COMPAT_43-less kernel since it's not necessary anymore for the linuxolator. Roman is running such a kernel for a for longer time. No problems so far. And I doubt other (newer than ia32 or alpha) architectures really depend on it. This may result in a small performance increase for some workloads. If the removal of COMPAT_43 results in a not working program, please recompile it and all dependencies and try again before reporting a problem. The only place where COMPAT_43 is needed (as in: does not compile without it) is in the (outdated/not usable since too old) svr4 code. Note: this does not remove the COMPAT_43TTY option. Nagging by: rdivacky
* Remove mpte optimization from pmap_enter_quick().ups2006-06-151-5/+3
| | | | | | | | | There is a race with the current locking scheme and removing it should have no measurable performance impact. This fixes page faults leading to panics in pmap_enter_quick_locked() on amd64/i386. Reviewed by: alc,jhb,peter,ps
* regen after MFP4 (soc2006/rdivacky_linuxolator) of syscalls.masternetchild2006-06-133-163/+206
| | | | | | P4-Changes: similar to 98673 and 98675 but regenerated locally Sponsored by: Google SoC 2006 Submitted by: rdivacky
* MFP4 (soc2006/rdivacky_linuxolator)netchild2006-06-131-180/+225
| | | | | | | | | | | | | Update of syscall.master: o Adding of several new dummy syscalls (268-310) o Synchronization of amd64 syscall.master with i386 one o Auditing added to amd64 syscall.master o Change auditing type for lstat syscall (bugfix). [1] P4-Changes: 98672, 98674 Noticed by: rwatson [1] Sponsored by: Google SoC 2006 Submitted by: rdivacky
* Add scheduler CORE, the work I have done half a year ago, recent,davidxu2006-06-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I picked it up again. The scheduler is forked from ULE, but the algorithm to detect an interactive process is almost completely different with ULE, it comes from Linux paper "Understanding the Linux 2.6.8.1 CPU Scheduler", although I still use same word "score" as a priority boost in ULE scheduler. Briefly, the scheduler has following characteristic: 1. Timesharing process's nice value is seriously respected, timeslice and interaction detecting algorithm are based on nice value. 2. per-cpu scheduling queue and load balancing. 3. O(1) scheduling. 4. Some cpu affinity code in wakeup path. 5. Support POSIX SCHED_FIFO and SCHED_RR. Unlike scheduler 4BSD and ULE which using fuzzy RQ_PPQ, the scheduler uses 256 priority queues. Unlike ULE which using pull and push, the scheduelr uses pull method, the main reason is to let relative idle cpu do the work, but current the whole scheduler is protected by the big sched_lock, so the benefit is not visible, it really can be worse than nothing because all other cpu are locked out when we are doing balancing work, which the 4BSD scheduelr does not have this problem. The scheduler does not support hyperthreading very well, in fact, the scheduler does not make the difference between physical CPU and logical CPU, this should be improved in feature. The scheduler has priority inversion problem on MP machine, it is not good for realtime scheduling, it can cause realtime process starving. As a result, it seems the MySQL super-smack runs better on my Pentium-D machine when using libthr, despite on UP or SMP kernel.
* Enable a few more things in x86 NOTES to get broader LINT coverage:jhb2006-06-121-0/+12
| | | | | - Turn on iwi(4), ipw(4), and ndis(4) on amd64 and i386. - Turn on ral(4) and ural(4) on i386, pc98, and amd64.
* Don't invalidate the TLB in pmap_qenter() unless the old mapping was valid.alc2006-06-121-10/+15
| | | | | | Most often, it isn't. Reviewed by: tegge@
* Add the ability to subset the devices that UART pulls in. This allowsimp2006-06-121-0/+3
| | | | | | | | the arm to compile without all the extras that don't appear, at least not in the flavors of ARM I deal with. This helps us save about 100k. If I've botched the available devices on a platform, please let me know and I'll correct ASAP.
* Introduce the function pmap_enter_object(). It maps a sequence of residentalc2006-06-051-5/+47
| | | | | | | pages from the same object. Use it in vm_map_pmap_enter() to reduce the locking overhead of premapping objects. Reviewed by: tegge@
* After much discussion with mjacob and scottl, change bus_dmamem_alloc sosilby2006-06-011-21/+3
| | | | | | | | | | | | that it just warns the user with a printf when it misaligns a piece of memory that was requested through a busdma tag. Some drivers (such as mpt, and probably others) were asking for alignments that could not be satisfied, but as far as driver operation was concerned, that did not matter. In the theory that other drivers will fall into this same category, we agreed that panicing or making the allocation fail will cause more hardship than is necessary. The printf should be sufficient motivation to get the driver glitch fixed.
* Turn the panic on not being able to meet alignment constraintsmjacob2006-05-311-4/+22
| | | | | | | in bus_dmamem_alloc into the more reasonable EINVAL return. Also, reclaim memory allocated but then not used if we had an error return.
* MFi386 rev 1.78:silby2006-05-281-2/+14
| | | | | | | Add a quick hack to ensure that bus_dmamem_alloc properly aligns small allocations with large alignment requirements. Add a panic to detect cases where we've still failed to properly align.
* Move clock_lock prototype into <machine/clock.h>, where it is moresobomax2006-05-192-9/+1
| | | | | | appropriate. Discussed with: jhb
* Add le(4). I could actually only test it on alpha, i386 and sparc64 butmarius2006-05-171-1/+2
| | | | | given that this includes the more problematic platforms I see no reason why it shouldn't also work on amd64 and ia64.
* Since DELAY() was moved, most <machine/clock.h> #includes have beenphk2006-05-161-1/+0
| | | | unnecessary.
* Kill more references to lnc(4).ru2006-05-161-3/+1
| | | | Submitted by: grep(1)
* Remove some remnants of lnc(4).marius2006-05-141-4/+0
|
* Clean out sysctl machdep.* related defines.phk2006-05-112-12/+3
| | | | The cmos clock related stuff should really be in MI code.
* regen (linux rt_sigpending)netchild2006-05-103-5/+6
|
* Implement rt_sigpending in the linuxolator.netchild2006-05-102-2/+2
| | | | | PR: 92671 Submitted by: Markus Niemist"o <markus.niemisto@gmx.net>
* Add in linsysfs. A linux 2.6 like sys filesystem to pacify the Linuxambrisko2006-05-092-0/+5
| | | | | | | LSI MegaRAID SAS utility. Sponsored by: IronPort Systems Man page help from: brueffer
* Forgot the amd/linux32 part since sys/*/linux didn't match :-(ambrisko2006-05-061-0/+6
| | | | Pointed out by: Alexander (thanks)
* add ath and wlan crypto supportsam2006-05-031-0/+6
| | | | MFC after: 1 month
* Allow bus_dmamap_load() to pass ENOMEM back to the caller. This puts it intoscottl2006-05-031-4/+10
| | | | | | | conformance with the mbuf and uio load routines. ENOMEM can only happen with BUS_DMA_NOWAIT is passed in, thus the deferals are disabled. I don't like doing this, but fixing this fixes assumptions in other important drivers, which is a net benefit for now.
* Add various constants for the PAT MSR and the PAT PTE and PDE flags.jhb2006-05-014-0/+63
| | | | | | | Initialize the PAT MSR during boot to map PAT type 2 to Write-Combining (WC) instead of Uncached (UC-). MFC after: 1 month
* Add a new 'pmap_invalidate_cache()' to flush the CPU caches via thejhb2006-05-016-2/+64
| | | | | | | wbinvd() instruction. This includes a new IPI so that all CPU caches on all CPUs are flushed for the SMP case. MFC after: 1 month
* Eliminate unnecessary, recursive acquisitions and releases of the pagealc2006-04-291-5/+2
| | | | | | queues lock by free_pv_entry() and pmap_remove_pages(). Reduce the scope of the page queues lock in pmap_remove_pages().
* Rewrite of puc(4). Significant changes are:marcel2006-04-281-2/+0
| | | | | | | | | | | | | | | | | | | | o Properly use rman(9) to manage resources. This eliminates the need to puc-specific hacks to rman. It also allows devinfo(8) to be used to find out the specific assignment of resources to serial/parallel ports. o Compress the PCI device "database" by optimizing for the common case and to use a procedural interface to handle the exceptions. The procedural interface also generalizes the need to setup the hardware (program chipsets, program clock frequencies). o Eliminate the need for PUC_FASTINTR. Serdev devices are fast by default and non-serdev devices are handled by the bus. o Use the serdev I/F to collect interrupt status and to handle interrupts across ports in priority order. o Sync the PCI device configuration to include devices found in NetBSD and not yet merged to FreeBSD. o Add support for Quatech 2, 4 and 8 port UARTs. o Add support for a couple dozen Timedia serial cards as found in Linux.
* Enable the rr232x driver for amd64.scottl2006-04-282-0/+6
|
* In general, bits in the page directory entry (PDE) and the page tablealc2006-04-271-4/+8
| | | | | | | | | | | | | entry (PTE) have the same meaning. The exception to this rule is the eighth bit (0x080). It is the PS bit in a PDE and the PAT bit in a PTE. This change avoids the possibility that pmap_enter() confuses a PAT bit with a PS bit, avoiding a panic(). Eliminate a diagnostic printf() from the i386 pmap_enter() that serves no current purpose, i.e., I've seen no bug reports in the last two years that are helped by this printf(). Reviewed by: jhb
* Move vm.pmap.pv_entry_count out from the PV_STATS ifdefs. It is alwayspeter2006-04-261-2/+3
| | | | available and is a real counter, not a statistic.
* Check if reported HTT cores are physical cores. This commit does notjkim2006-04-251-0/+8
| | | | | affect AMD CPUs at all because HTT bit is disabled earlier. Intel multicore CPUs and ULE scheduler may be affected.
* Add another Intel CPU feature flag, xTPR (Send Task Priority Messages).jkim2006-04-241-1/+1
|
* Check if deterministic cache parameters leaf is valid before use.jkim2006-04-241-1/+2
|
* Adjust dangerous-shared-cache-detection logic from "all shared datacperciva2006-04-241-2/+2
| | | | | | | | | | | | | | | caches are dangerous" to "a shared L1 data cache is dangerous". This is a compromise between paranoia and performance: Unlike the L1 cache, nobody has publicly demonstrated a cryptographic side channel which exploits the L2 cache -- this is harder due to the larger size, lower bandwidth, and greater associativity -- and prohibiting shared L2 caches turns Intel Core Duo processors into Intel Core Solo processors. As before, the 'machdep.hyperthreading_allowed' sysctl will allow even the L1 data cache to be shared. Discussed with: jhb, scottl Security: See FreeBSD-SA-05:09.htt for background material.
* Move AHC_REG_PRETTY_PRINT and AHD_REG_PRETTY_PRINT belowdelphij2006-04-241-4/+4
| | | | their corresponding devices.
* Oops. Minidumps were developed on 6.x, in without the small pv entry code.peter2006-04-211-0/+3
| | | | | Add some strategic dump_add_page()/dump_drop_page() lines to include pv chunks in the minidumps - these operate in the direct map region like UMA.
* Introduce minidumps. Full physical memory crash dumps are still availablepeter2006-04-216-3/+491
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | via the debug.minidump sysctl and tunable. Traditional dumps store all physical memory. This was once a good thing when machines had a maximum of 64M of ram and 1GB of kvm. These days, machines often have many gigabytes of ram and a smaller amount of kvm. libkvm+kgdb don't have a way to access physical ram that is not mapped into kvm at the time of the crash dump, so the extra ram being dumped is mostly wasted. Minidumps invert the process. Instead of dumping physical memory in in order to guarantee that all of kvm's backing is dumped, minidumps instead dump only memory that is actively mapped into kvm. amd64 has a direct map region that things like UMA use. Obviously we cannot dump all of the direct map region because that is effectively an old style all-physical-memory dump. Instead, introduce a bitmap and two helper routines (dump_add_page(pa) and dump_drop_page(pa)) that allow certain critical direct map pages to be included in the dump. uma_machdep.c's allocator is the intended consumer. Dumps are a custom format. At the very beginning of the file is a header, then a copy of the message buffer, then the bitmap of pages present in the dump, then the final level of the kvm page table trees (2MB mappings are expanded into a 4K page mappings), then the sparse physical pages according to the bitmap. libkvm can now conveniently access the kvm page table entries. Booting my test 8GB machine, forcing it into ddb and forcing a dump leads to a 48MB minidump. While this is a best case, I expect minidumps to be in the 100MB-500MB range. Obviously, never larger than physical memory of course. minidumps are on by default. It would want be necessary to turn them off if it was necessary to debug corrupt kernel page table management as that would mess up minidumps as well. Both minidumps and regular dumps are supported on the same machine.
* Set the rid for a resoruce allocated with rman_reserve_resource.imp2006-04-201-1/+1
|
* Correct a local information leakage bug affecting AMD FPUs.cperciva2006-04-191-0/+36
| | | | Security: FreeBSD-SA-06:14.fpu
* If we're doing a try-alloc of a pv entry and give up early, do not forgetpeter2006-04-181-0/+1
| | | | | | | to reduce the pv_entry_count counter. This was found by Tor Egge. In the same email, Tor also pointed out the pv_stats problem in the previous commit, but I'd forgotten about it until I went looking for this email about this allocation problem.
* pv_entry_count is more than a statistic. It is used for resource limiting.peter2006-04-181-3/+3
| | | | Do not compile out its counter updates if pv entry stats are turned off.
* Include opt_pmap.h for PMAP_SHPGPERPROC.alc2006-04-131-0/+1
| | | | PR: 94509
* Retire pmap_track_modified(). We no longer need it because we do notalc2006-04-121-42/+10
| | | | | | | | create managed mappings within the clean submap. To prevent regressions, add assertions blocking the creation of managed mappings within the clean submap. Reviewed by: tegge
* Hook bce up to the buildps2006-04-101-0/+1
|
* Cache the value of the lower half of each I/O APIC redirection table entryjhb2006-04-051-6/+4
| | | | | | | | | | so that we only have to do an ioapic_write() instead of an ioapic_read() followed by an ioapic_write() every time we mask and unmask level triggered interrupts. This cuts the execution time for these operations roughly in half. Profiled by: Paolo Pisati <p.pisati@oltrelinux.com> MFC after: 1 week
* Convert pv_entry_frees and pv_entry_allocs stats counters from int to long,peter2006-04-041-3/+4
| | | | they wrap way too quickly.
* Sync with i386: Map exceptions to signals in gdb_cpu_signal() somarcel2006-04-042-6/+25
| | | | | | that kgdb(1) gets a SIGTRAP when it needs to. Pointed out by: grehan@
* The PC is register 16, not 18.marcel2006-04-041-1/+1
| | | | Pointed out by: grehan@
* Eliminate HAVE_STOPPEDPCBS. On ia64 the PCPU holds a pointer to themarcel2006-04-031-0/+2
| | | | | | | | PCB in which the context of stopped CPUs is stored. To access this PCB from KDB, we introduce a new define, called KDB_STOPPEDPCB. The definition, when present, lives in <machine/kdb.h> and abstracts where MD code saves the context. Define KDB_STOPPEDPCB on i386, amd64, alpha and sparc64 in accordance to previous code.
OpenPOWER on IntegriCloud