summaryrefslogtreecommitdiffstats
path: root/sys/x86
Commit message (Collapse)AuthorAgeFilesLines
* Fix build when NEW_PCIB is not defined.jhb2011-07-162-1/+7
| | | | | Submitted by: gcooper (partially) Pointy hat to: jhb
* Respect the BIOS/firmware's notion of acceptable address ranges for PCIjhb2011-07-153-5/+315
| | | | | | | | | | | | | | | | | | | | resource allocation on x86 platforms: - Add a new helper API that Host-PCI bridge drivers can use to restrict resource allocation requests to a set of address ranges for different resource types. - For the ACPI Host-PCI bridge driver, use Producer address range resources in _CRS to enumerate valid address ranges for a given Host-PCI bridge. This can be disabled by including "hostres" in the debug.acpi.disabled tunable. - For the MPTable Host-PCI bridge driver, use entries in the extended MPTable to determine the valid address ranges for a given Host-PCI bridge. This required adding code to parse extended table entries. Similar to the new PCI-PCI bridge driver, these changes are only enabled if the NEW_PCIB kernel option is enabled (which is enabled by default on amd64 and i386). Approved by: re (kib)
* If TSC stops ticking in C3, disable deep sleep when the user forcefullyjkim2011-07-141-0/+1
| | | | | | select TSC as timecounter hardware. Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de)
* Move {amd64,i386}/pci/pci_bus.c and {amd64,i386}/include/pci_cfgreg.h tojhb2011-06-222-0/+779
| | | | | the x86 tree. The $PIR code is still only enabled on i386 and not amd64. While here, make the qpi(4) driver on conditional on 'device pci'.
* Set negative quality to TSC timecounter when C3 state is enabled for Inteljkim2011-06-221-0/+13
| | | | | | | | | | | | | | | processors unless the invariant TSC bit of CPUID is set. Intel processors may stop incrementing TSC when DPSLP# pin is asserted, according to Intel processor manuals, i. e., TSC timecounter is useless if the processor can enter deep sleep state (C3/C4). This problem was accidentally uncovered by r222869, which increased timecounter quality of P-state invariant TSC, e.g., for Core2 Duo T5870 (Family 6, Model f) and Atom N270 (Family 6, Model 1c). Reported by: Fabian Keil (freebsd-listen at fabiankeil dot de) Ian FREISLICH (ianf at clue dot co dot za) Tested by: Fabian Keil (freebsd-listen at fabiankeil dot de) - Core2 Duo T5870 (C3 state available/enabled) jkim - Xeon X5150 (C3 state unavailable)
* Teach the compiler how to shift TSC value efficiently. As noted in r220631,jkim2011-06-171-2/+5
| | | | | | some times compiler inserts redundant instructions to preserve unused upper 32 bits even when it is casted to a 32-bit value. Unfortunately, it seems the problem becomes more serious when it is shifted, especially on amd64.
* Tidy up r222866.jkim2011-06-081-6/+6
| | | | | | | | - Re-add accidentally removed atomic op. for sysctl(9) handler. - Remove a period(`.') at the end of a debugging message. - Consistently spell "low" for "TSC-low" timecounter throughout. Pointed out by: bde
* Increase quality of TSC (or TSC-low) timecounter to 1000 if it is P-statejkim2011-06-081-2/+27
| | | | | | | | invariant. For SMP case (TSC-low), it also has to pass SMP synchronization test and the CPU vendor/model has to be white-listed explicitly. Currently, all Intel CPUs and single-socket AMD Family 15h processors are listed here. Discussed with: hackers
* Introduce low-resolution TSC timecounter "TSC-low". It replaces the normaljkim2011-06-081-6/+38
| | | | | | | | | | | TSC timecounter if TSC frequency is higher than ~4.29 MHz (or 2^32-1 Hz) or multiple CPUs are present. The "TSC-low" frequency is always lower than a preset maximum value and derived from TSC frequency (by being halved until it becomes lower than the maximum). Note the maximum value for SMP case is significantly lower than UP case because we want to reduce (rare but known) "temporal anomalies" caused by non-serialized RDTSC instruction. Normally, it is still higher than "ACPI-fast" timecounter frequency (which was default timecounter hardware for long time until r222222) to be useful.
* Remove a redundant assignment since r221703.jkim2011-06-081-3/+0
|
* MFCattilio2011-05-092-11/+75
|
* MFCattilio2011-05-062-47/+13
|
* Commit the support for removing cpumask_t and replacing it directly withattilio2011-05-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cpuset_t objects. That is going to offer the underlying support for a simple bump of MAXCPU and then support for number of cpus > 32 (as it is today). Right now, cpumask_t is an int, 32 bits on all our supported architecture. cpumask_t on the other side is implemented as an array of longs, and easilly extendible by definition. The architectures touched by this commit are the following: - amd64 - i386 - pc98 - arm - ia64 - XEN while the others are still missing. Userland is believed to be fully converted with the changes contained here. Some technical notes: - This commit may be considered an ABI nop for all the architectures different from amd64 and ia64 (and sparc64 in the future) - per-cpu members, which are now converted to cpuset_t, needs to be accessed avoiding migration, because the size of cpuset_t should be considered unknown - size of cpuset_t objects is different from kernel and userland (this is primirally done in order to leave some more space in userland to cope with KBI extensions). If you need to access kernel cpuset_t from the userland please refer to example in this patch on how to do that correctly (kgdb may be a good source, for example). - Support for other architectures is going to be added soon - Only MAXCPU for amd64 is bumped now The patch has been tested by sbruno and Nicholas Esborn on opteron 4 x 12 pack CPUs. More testing on big SMP is expected to came soon. pluknet tested the patch with his 8-ways on both amd64 and i386. Tested by: pluknet, sbruno, gianni, Nicholas Esborn Reviewed by: jeff, jhb, sbruno
* MFCattilio2011-05-032-0/+2
|
* Fix build with clang. Please note there is an LLVM/Clang PR:jkim2011-05-021-1/+1
| | | | | | http://llvm.org/bugs/show_bug.cgi?id=9379 Reported by: rpaulo, dim
* Add implementations of BUS_ADJUST_RESOURCE() to the PCI bus driver,jhb2011-05-022-21/+38
| | | | | generic PCI-PCI bridge driver, x86 nexus driver, and x86 Host to PCI bridge drivers.
* Change rman_manage_region() to actually honor the rm_start and rm_endjhb2011-04-291-1/+1
| | | | | | | | | | constraints on the rman and reject attempts to manage a region that is out of range. - Fix various places that set rm_end incorrectly (to ~0 or ~0u instead of ~0ul). - To preserve existing behavior, change rman_init() to set rm_start and rm_end to allow managing the full range (0 to ~0ul) if they are not set by the caller when rman_init() is called.
* Detect VMware guest and set the TSC frequency as reported by the hypervisor.jkim2011-04-291-17/+101
| | | | | | | VMware products virtualize TSC and it run at fixed frequency in so-called "apparent time". Although virtualized i8254 also runs in apparent time, TSC calibration always gives slightly off frequency because of the complicated timer emulation and lost-tick correction mechanism.
* Turn off periodic recalibration of CPU ticker frequency if it is invariant.jkim2011-04-281-1/+1
|
* Add the watchdogs patting during the (shutdown time) disk syncing andattilio2011-04-281-0/+8
| | | | | | | | | | | | | | | | disk dumping. With the option SW_WATCHDOG on, these operations are doomed to let watchdog fire, fi they take too long. I implemented the stubs this way because I really want wdog_kern_* KPI to not be dependant by SW_WATCHDOG being on (and really, the option only enables watchdog activation in hardclock) and also avoid to call them when not necessary (avoiding not-volountary watchdog activations). Sponsored by: Sandvine Incorporated Discussed with: emaste, des MFC after: 2 weeks
* Use ACPI-supplied CPU frequencies instead of estimated ones as we are aboutjkim2011-04-271-3/+3
| | | | | | to use other values from the same table anyway. MFC after: 3 days
* Use newly added rdtsc32() for DELAY(9) as well.jkim2011-04-141-1/+1
|
* Work around an emulator problem where virtual CPU advertises TSC is P-statejkim2011-04-141-2/+12
| | | | | | | | | | invariant and APERF/MPERF MSRs exist but these MSRs never tick. When we calculate effective frequency from cpu_est_clockrate(), it caused panic of division-by-zero. Now we test whether these MSRs actually increase to avoid such foot-shooting. Reported by: dim Tested by: dim
* Use newly added rdtsc32() for the timecounter_get_t method.jkim2011-04-141-2/+3
|
* Add some tunable descriptions about x86 timers.jkim2011-04-142-2/+3
| | | | Requested by: arundel
* Do not use TSC for DELAY(9) if it not P-state invariant to avoid possiblejkim2011-04-121-1/+1
| | | | | foot-shooting. DELAY() becomes unreliable when TSC frequency varies wildly, especially cpufreq(4) and powerd(8) are used at the same time.
* Probe capability to find effective frequency. When the TSC is P-statejkim2011-04-121-0/+9
| | | | invariant, APERF/MPERF ratio can be used to find effective frequency.
* Add a new tunable 'machdep.disable_tsc_calibration' to allow skipping TSCjkim2011-04-121-16/+93
| | | | | frequency calibration. For Intel processors, if brand string from CPUID contains its nominal frequency, this frequency is used instead.
* Merge two similar functions to reduce duplication.jkim2011-04-111-30/+29
|
* Refactor DELAYDEBUG as it is only useful for correcting i8254 frequency.jkim2011-04-081-13/+14
|
* Use atomic load & store for TSC frequency. It may be overkill for amd64 butjkim2011-04-073-11/+15
| | | | | | | | | safer for i386 because it can be easily over 4 GHz now. More worse, it can be easily changed by user with 'machdep.tsc_freq' tunable (directly) or cpufreq(4) (indirectly). Note it is intentionally not used in performance critical paths to avoid performance regression (but we should, in theory). Alternatively, we may add "virtual TSC" with lower frequency if maximum frequency overflows 32 bits (and ignore possible incoherency as we do now).
* Revert r219676.jkim2011-03-161-3/+5
| | | | Requested by: jhb, bde
* Do not let machdep.tsc_freq modify tsc_freq itself. It is bad for i386 asjkim2011-03-151-5/+3
| | | | | | it does not operate atomically. Actually, it serves no purpose. Noticed by: bde
* Deprecate tsc_present as the last of its real consumers finally disappeared.jkim2011-03-151-7/+2
|
* When TSC is unavailable, broken or disabled and the current timecounter hasjkim2011-03-141-10/+43
| | | | better quality than i8254 timer, use it for DELAY(9).
* Add a tunable "machdep.disable_tsc" to turn off TSC. Specifically, it turnsjkim2011-03-111-7/+11
| | | | | off boot-time CPU frequency calibration, DELAY(9) with TSC, and using TSC as a CPU ticker. Note tsc_present does not change by this tunable.
* Turn off pointless P-state invariant TSC detection based on CPU modeljkim2011-03-101-6/+9
| | | | on a virtual machine.
* Deprecate rarely used tsc_is_broken. Instead, we zero out tsc_freq becausejkim2011-03-102-3/+2
| | | | it is almost always used with tsc_freq any way.
* Set C1 "I/O then Halt" capability bit for Intel EIST. Some broken BIOSesjkim2011-02-251-2/+5
| | | | | | | refuse to load external SSDTs if this bit is unset for _PDC. It seems Linux and OpenSolaris did the same long ago. MFC after: 1 week
* Fix typos - remove duplicate "is".brucec2011-02-231-1/+1
| | | | | | PR: docs/154934 Submitted by: Eitan Adler <lists at eitanadler.com> MFC after: 3 days
* Use a dedicated taskqueue with a thread that runs at a software-interruptjhb2011-02-031-3/+7
| | | | priority for the periodic polling of the machine check registers.
* Introduce signed and unsigned version of CTLTYPE_QUAD, renamingmdf2011-01-191-2/+2
| | | | existing uses. Rename sysctl_handle_quad() to sysctl_handle_64().
* If an interrupt on an I/O APIC is moved to a different CPU after it hasjhb2011-01-131-2/+0
| | | | | | | | | | | started to execute, it seems that the corresponding ISR bit in the "old" local APIC can be cleared. This causes the local APIC interrupt routine to fail to find an interrupt to service. Rather than panic'ing in this case, simply return from the interrupt without sending an EOI to the local APIC. If there are any other pending interrupts in other ISR registers, the local APIC will assert a new interrupt. Tested by: steve
* Revert to using bus_size_t for the bounce_zone's alignment member.mdf2011-01-131-3/+10
| | | | Reuqested by: jhb
* Fix a brain fart. Since this file is shared between i386 and amd64, amdf2011-01-121-3/+3
| | | | | | bus_size_t may be 32 or 64 bits. Change the bounce_zone alignment field to explicitly be 32 bits, as I can't really imagine a DMA device that needs anything close to 2GB alignment of data.
* sysctl(9) cleanup checkpoint: amd64 GENERIC builds cleanly.mdf2011-01-121-2/+2
| | | | Commit the kernel changes.
* Remove unneeded includes of <sys/linker_set.h>. Other headers that usejhb2011-01-111-1/+0
| | | | | | it internally contain nested includes. Reviewed by: bde
* Copy powerpc/include/_inttypes.h to x86 and replace i386/amd64/pc98tijl2011-01-081-0/+221
| | | | | | headers with stubs. Approved by: kib (mentor)
* Drop the icu_lock spinlock while pausing briefly after masking thejhb2010-12-231-0/+2
| | | | | | | | | | | | | | | interrupt in the I/O APIC before moving it to a different CPU. If the interrupt had been triggered by the I/O APIC after locking icu_lock but before we masked the pin in the I/O APIC, then this could cause the interrupt to be pending on the "old" CPU and it would finally trigger after we had moved the interrupt to the new CPU. This could cause us to panic as there was no interrupt source associated with the old IDT vector on the old CPU. Dropping the lock after the interrupt is masked but before it is moved allows the interrupt to fire and be handled in this case before it is moved. Tested by: Daniel Braniss danny of cs huji ac il MFC after: 1 week
* Merge amd64 and i386 bus.h and move the resulting header to x86. Replacetijl2010-12-202-12/+1102
| | | | | | | | | the original amd64 and i386 headers with stubs. Rename (AMD64|I386)_BUS_SPACE_* to X86_BUS_SPACE_* everywhere. Reviewed by: imp (previous version), jhb Approved by: kib (mentor)
OpenPOWER on IntegriCloud