summaryrefslogtreecommitdiffstats
path: root/sys/x86
Commit message (Collapse)AuthorAgeFilesLines
* Trim stray blank line.jhb2012-04-111-1/+0
|
* Recognize the RDRAND instruction feature.jhb2012-04-091-0/+1
| | | | | Submitted by: Michael Fuckner michael fuckner net MFC after: 3 days
* Fix interrupt load balancing regression, introduced in revisiongibbs2012-04-061-3/+0
| | | | | | | | | | | | | | | | 222813, that left all un-pinned interrupts assigned to CPU 0. sys/x86/x86/intr_machdep.c: In intr_shuffle_irqs(), remove CPU_SETOF() call that initialized the "intr_cpus" cpuset to only contain CPU0. This initialization is too late and nullifies the results of calls the intr_add_cpu() that occur much earlier in the boot process. Since "intr_cpus" is statically initialized to the empty set, and all processors, including the BSP, already add themselves to "intr_cpus" no special initialization for the BSP is necessary. MFC after: 3 days
* Further tweak the changes made in r233709. The kernel doesn't permitjhb2012-04-021-14/+25
| | | | | | | | | | | | | sleeping from a swi handler (even though in this case it would be ok), so switch the refill and scanning SWI handlers to being tasks on a fast taskqueue. Also, only schedule the refill task for a CMCI as an MC# can fire at any time, so it should do the minimal amount of work needed and avoid opportunities to deadlock before it panics (such as scheduling a task it won't ever need in practice). To handle the case of an MC# only finding recoverable errors (which should never happen), always try to refill the event free list when the periodic scan executes. MFC after: 2 weeks
* Make machine check exception logging more readable. On newer Intel systems,jhb2012-04-022-9/+8
| | | | | | | | | | | | an uncorrected ECC error tends to fire on all CPUs in a package simultaneously and the current printf hacks are not sufficient to make the messages legible. Instead, use the existing mca_lock spinlock to serialize calls to mca_log() and change the machine check code to panic directly when an unrecoverable error is encoutered rather than falling back to a trap_fatal() call in trap() (which adds nearly a screen-full of logging messages that aren't useful for machine checks). MFC after: 2 weeks
* Attempt to make machine check handling a bit more robust:jhb2012-03-301-28/+72
| | | | | | | | | | | | | | | | | - Don't malloc() new MCA records for machine checks logged due to a CMCI or MC# exception. Instead, use a pre-allocated pool of records. When a CMCI or MC# exception fires, schedule a swi to refill the pool. The pool is sized to hold at least one record per available machine bank, and one record per CPU. This should handle the case of all CPUs triggering a single bank at once as well as the case a single CPU triggering all of its banks. The periodic scans still use malloc() since they are run from a safe context. - Since we have to create an swi to handle refills, make the periodic scan a second swi for the same thread instead of having a separate taskqueue thread for the scans. Suggested by: mdf (avoiding malloc()) MFC after: 2 weeks
* Move the legacy(4) driver to x86.jhb2012-03-304-2/+437
|
* Fix an issue introduced in sys/x86/include/endian.h with r232721. Indim2012-03-291-2/+2
| | | | | | | | | | | | | | | | | | | that revision, the bswapXX_const() macros were renamed to bswapXX_gen(). Also, bswap64_gen() was implemented as two calls to bswap32(), and similarly, bswap32_gen() as two calls to bswap16(). This mainly helps our base gcc to produce more efficient assembly. However, the arguments are not properly masked, which results in the wrong value being calculated in some instances. For example, bswap32(0x12345678) returns 0x7c563412, and bswap64(0x123456789abcdef0) returns 0xfcdefc9a7c563412. Fix this by appropriately masking the arguments to bswap16() in bswap32_gen(), and to bswap32() in bswap64_gen(). This should also silence warnings from clang. Submitted by: jh
* Revert sys/x86/include/endian.h to what it was before r233419, as thatdim2012-03-291-3/+3
| | | | | | | | | | revision has two problems: - It can produce worse code with both clang and gcc. - It doesn't fix the actual issue introduced in r232721, which will be fixed in the next commit. Submitted by: bde, tijl and jh Pointy hat to: dim
* Use a more proper fix for enabling HT MSI mapping windows on Host-PCIjhb2012-03-292-14/+20
| | | | | | | | | | | | | | | | | | | | bridges. Rather than blindly enabling the windows on all of them, only enable the window when an MSI interrupt is enabled for a device behind the bridge, similar to what already happens for HT PCI-PCI bridges. To implement this, each x86 Host-PCI bridge driver has to be able to locate it's actual backing device on bus 0. For ACPI, use the _ADR method to find the slot and function of the device. For the non-ACPI case, the legacy(4) driver already scans bus 0 looking for Host-PCI bridge devices. Now it saves the slot and function of each bridge that it finds as ivars that the Host-PCI bridge driver can then use in its pcib_map_msi() method. This fixes machines where non-MSI interrupts were broken by the previous round of HT MSI changes. Tested by: bapt MFC after: 1 week
* Restore proper use of bounce buffers for ISA DMA. When locking wasjhb2012-03-291-2/+3
| | | | | | | | | | added, the call to pmap_kextract() was moved up, and as a result the code never updated the physical address to use for DMA if a bounce buffer was used. Restore the earlier location of pmap_kextract() so it takes bounce buffers into account. Tested by: kargl MFC after: 1 week
* Allocate the ioapics[] array dynamically since it is only needed for thejhb2012-03-281-5/+11
| | | | | | | | duration of madt_setup_io(). This avoids having the array take up permanent space in the BSS. Inspired by: bde MFC after: 2 weeks
* Move the DTrace return IDT vector back up from 0x20 to 0x92. The 0x20jhb2012-03-281-1/+1
| | | | | | | | vector is currently dedicated to servicing IRQ 0 from the 8259A's, so it shouldn't be overloaded for DTrace. Tested by: rstone MFC after: 1 week
* Fix the following clang warning in sys/dev/dcons/dcons.c, caused by thedim2012-03-241-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | recent changes in sys/x86/include/endian.h: sys/dev/dcons/dcons.c:190:15: error: implicit conversion from '__uint32_t' (aka 'unsigned int') to '__uint16_t' (aka 'unsigned short') changes value from 1684238190 to 28526 [-Werror,-Wconstant-conversion] buf->magic = ntohl(DCONS_MAGIC); ^~~~~~~~~~~~~~~~~~ sys/sys/param.h:306:18: note: expanded from: #define ntohl(x) __ntohl(x) ^ ./x86/endian.h:128:20: note: expanded from: #define __ntohl(x) __bswap32(x) ^ ./x86/endian.h:78:20: note: expanded from: __bswap32_gen((__uint32_t)(x)) : __bswap32_var(x)) ^ ./x86/endian.h:68:26: note: expanded from: (((__uint32_t)__bswap16(x) << 16) | __bswap16((x) >> 16)) ^ ./x86/endian.h:75:53: note: expanded from: __bswap16_gen((__uint16_t)(x)) : __bswap16_var(x))) ~~~~~~~~~~~~~ ^ This is because the __bswapXX_gen() macros (for x86) call the regular __bswapXX() macros. Since the __bswapXX_gen() variants are only called when their arguments are constant, there is no need to do that constancy check recursively. Also, it causes the above error with clang. Fix it by calling __bswap16_gen() from __bswap32_gen(), and similarly, __bswap32_gen() from __bswap64_gen(). While here, add extra parentheses around the __bswap16_gen() macro expansion, to prevent unexpected side effects.
* Mark the 'lapics' and 'ioapics' arrays here static since they arejhb2012-03-221-2/+2
| | | | | | | | private to this file. The 'lapics' array was actually shadowing a completely different 'lapics' array that is private to local_apic.c. Reported by: bde MFC after: 2 weeks
* Copy amd64 sysarch.h to x86 and merge with i386 sysarch.h. Replacetijl2012-03-191-0/+138
| | | | amd64/i386/pc98 sysarch.h with stubs.
* Copy i386 specialreg.h to x86 and merge with amd64 specialreg.h. Replacetijl2012-03-191-0/+678
| | | | amd64/i386/pc98 specialreg.h with stubs.
* Copy i386 psl.h to x86 and replace amd64/i386/pc98 psl.h with stubs.tijl2012-03-191-0/+84
|
* Move userland bits (and some common kernel bits) from amd64 and i386tijl2012-03-191-0/+286
| | | | | | | segments.h to a new x86 segments.h. Add __packed attribute to some structs (just to be sure). Also make it clear that i386 GDT and LDT entries are used in ia64 code.
* Eliminate ia32_reg.h by moving its contents to x86 and ia64 reg.h.tijl2012-03-181-5/+8
| | | | Reviewed by: kib
* Copy i386 reg.h to x86 and merge with amd64 reg.h. Replace i386/amd64/pc98tijl2012-03-181-0/+253
| | | | | | | | | | | | | | | | | reg.h with stubs. The tREGISTER macros are only made visible on i386. These macros are deprecated and should not be available on amd64. The i386 and amd64 versions of struct reg have been renamed to struct __reg32 and struct __reg64. During compilation either __reg32 or __reg64 is defined as reg depending on the machine architecture. On amd64 the i386 struct is also available as struct reg32 which is used in COMPAT_FREEBSD32 code. Most of compat/ia32/ia32_reg.h is now IA64 only. Reviewed by: kib (previous version)
* Move userland bits of i386 npx.h and amd64 fpu.h to x86 fpu.h.tijl2012-03-161-0/+216
| | | | | | | | | | | | | | Remove FPU types from compat/ia32/ia32_reg.h that are no longer needed. Create machine/npx.h on amd64 to allow compiling i386 code that uses this header. The original npx.h and fpu.h define struct envxmm differently. Both definitions have been included in the new x86 header as struct __envxmm32 and struct __envxmm64. During compilation either __envxmm32 or __envxmm64 is defined as envxmm depending on machine architecture. On amd64 the i386 struct is also available as struct envxmm32. Reviewed by: kib
* Revert the PCIe 4GB boundary issue workaround now that the proper fix isjhb2012-03-161-8/+0
| | | | | | in HEAD. Ok'd by: scottl
* - Fix to build a native i386 kernel without the SMP and atpic.nyan2012-03-163-46/+50
| | | | | | | | | - Merge r232744 changes to pc98. (Allow a kernel to be built with 'nodevice atpic'.) - Move ICU related defines from x86/isa/atpic.c to x86/isa/icu.h and use them in x86/x86/intr_machdep.c. Reviewed by: jhb
* Move i386's intr_machdep.c to the x86 tree and share it with amd64.jhb2012-03-091-0/+567
|
* Add casts to __uint16_t to the __bswap16() macros on all arches whichdim2012-03-091-2/+2
| | | | | | | | | | | didn't already have them. This is because the ternary expression will return int, due to the Usual Arithmetic Conversions. Such casts are not needed for the 32 and 64 bit variants. While here, add additional parentheses around the x86 variant, to protect against unintended consequences. MFC after: 2 weeks
* Cast the expression in __bswap16(x) to __uint16_t because it is promotedtijl2012-03-091-2/+2
| | | | | | to int. Reviewed by: dim
* Clean up x86 endian.h:tijl2012-03-091-44/+37
| | | | | | | | | | | | | - Remove extern "C". There are no functions with external linkage here. [1] - Rename bswapNN_const(x) to bswapNN_gen(x) to indicate that these macros are generic implementations that can take non-constant arguments. [1] - Split up __GNUCLIKE_ASM && __GNUCLIKE_BUILTIN_CONSTANT_P and deal with each separately. - Replace _LP64 with __amd64__ because asm instructions are machine dependent, not ABI dependent. Submitted by: bde [1] Reviewed by: bde
* Copy amd64 ptrace.h to x86 and merge with i386 ptrace.h. Replacetijl2012-03-041-0/+48
| | | | | | | | | | amd64/i386/pc98 ptrace.h with stubs. For amd64 PT_GETXSTATE and PT_SETXSTATE have been redefined to match the i386 values. The old values are still supported but should no longer be used. Reviewed by: kib
* Do not use INT64_C and UINT64_C to define 64 bit integer limits. Theytijl2012-03-041-6/+10
| | | | | | aren't defined for C++ code unless __STDC_CONSTANT_MACROS is defined. Reported by: jhb
* Copy amd64 trap.h to x86 and replace amd64/i386/pc98 trap.h with stubs.tijl2012-03-041-0/+95
|
* Copy amd64 float.h to x86 and merge with i386 float.h. Replacetijl2012-03-041-0/+98
| | | | amd64/i386/pc98 float.h with stubs.
* - Change contigmalloc() to use the vm_paddr_t type instead of an unsignedjhb2012-03-011-2/+2
| | | | | | | | | | | | | | | long for specifying a boundary constraint. - Change bus_dma tags to use bus_addr_t instead of bus_size_t for boundary constraints. These allow boundary constraints to be fully expressed for cases where sizeof(bus_addr_t) != sizeof(bus_size_t). Specifically, it allows a driver to properly specify a 4GB boundary in a PAE kernel. Note that this cannot be safely MFC'd without a lot of compat shims due to KBI changes, so I do not intend to merge it. Reviewed by: scottl
* Copy amd64 stdarg.h to x86 and replace amd64/i386/pc98 stdarg.h with stubs.tijl2012-02-281-0/+75
|
* Copy amd64 setjmp.h to x86 and replace amd64/i386/pc98 setjmp.h with stubs.tijl2012-02-281-0/+50
|
* Workaround for PCIe 4GB boundary issueemaste2012-02-281-0/+8
| | | | | | | | | | | | | | Enforce a boundary of no more than 4GB - transfers crossing a 4GB boundary can lead to data corruption due to PCIe limitations. This change is a less-intrusive workaround that can be quickly merged back to older branches; a cleaner implementation will arrive in HEAD later but may require KPI changes. This change is based on a suggestion by jhb@. Reviewed by: scottl, jhb Sponsored by: Sandvine Incorporated MFC after: 3 days
* Copy amd64 endian.h to x86 and merge with i386 endian.h. Replacetijl2012-02-281-0/+138
| | | | | | | | | | amd64/i386/pc98 endian.h with stubs. In __bswap64_const(x) the conflict between 0xffUL and 0xffULL has been resolved by reimplementing the macro in terms of __bswap32(x). As a side effect __bswap64_var(x) is now implemented using two bswap instructions on i386 and should be much faster. __bswap32_const(x) has been reimplemented in terms of __bswap16(x) for consistency.
* Copy amd64 _stdint.h to x86 and merge with i386 _stdint.h. Replacetijl2012-02-281-0/+191
| | | | amd64/i386/pc98 _stdint.h with stubs.
* Copy amd64 _limits.h to x86 and merge with i386 _limits.h. Replacetijl2012-02-281-0/+101
| | | | amd64/i386/pc98 _limits.h with stubs.
* Copy amd64 _types.h to x86 and merge with i386 _types.h. Replace existingtijl2012-02-281-0/+160
| | | | amd64/i386/pc98 _types.h with stubs.
* - Panic up front if a kernel does not include 'device atpic' and anjhb2012-02-271-1/+10
| | | | | | | | APIC is not found. - Don't panic if lapic_enable_cmc() is called and the APIC is not enabled. This can happen due to booting a kernel with APIC disabled on a CPU that supports CMCI. - Wrap a long line.
* Fix apparent logic reversal in setting the 'auto_mode' flag.kan2012-02-261-2/+2
| | | | MFC after: 2 weeks
* Fix a few bugs in the SRAT parsing code:jhb2012-01-031-5/+12
| | | | | | | | | | | | | - Actually increment ndomain when building our list of known domains so that we can properly renumber them to be 0-based and dense. - If the number of domains exceeds the configured maximum (VM_NDOMAIN), bail out of processing the SRAT and disable NUMA rather than hitting an obscure panic later. - Don't bother parsing the SRAT at all if VM_NDOMAIN is set to 1 to disable NUMA (the default). Reported by: phk (2) MFC after: 1 week
* Get rid of kludgy per-descriptor state handling in acpi_apm.ed2011-12-051-63/+25
| | | | | | Where i386/bios/apm.c requires no per-descriptor state, the ACPI version of these device do. Instead of using hackish clone lists that leave stale device nodes lying around, use the cdevpriv API.
* - There's no need to overwrite the default device method with the defaultmarius2011-11-223-6/+3
| | | | | | | | | | one. Interestingly, these are actually the default for quite some time (bus_generic_driver_added(9) since r52045 and bus_generic_print_child(9) since r52045) but even recently added device drivers do this unnecessarily. Discussed with: jhb, marcel - While at it, use DEVMETHOD_END. Discussed with: jhb - Also while at it, use __FBSDID.
* Mark all SYSCTL_NODEs static that have no corresponding SYSCTL_DECLs.ed2011-11-074-11/+12
| | | | | | The SYSCTL_NODE macro defines a list that stores all child-elements of that node. If there's no SYSCTL_DECL macro anywhere else, there's no reason why it shouldn't be static.
* Mark MALLOC_DEFINEs static that have no corresponding MALLOC_DECLAREs.ed2011-11-072-2/+2
| | | | This means that their use is restricted to a single C file.
* Ignore SRAT memory entries if the memory range does not overlap with anjhb2011-10-051-0/+26
| | | | | | | | | existing phys_avail[] table. If a hw.physmem setting causes a memory domain to not be present in phys_avail[], the SRAT table will now be ignored rather than triggering a panic when a CPU in the missing domain tries to allocate a page. MFC after: 1 week
* Fix a deficiency in the selinfo interface:attilio2011-08-251-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a selinfo object is recorded (via selrecord()) and then it is quickly destroyed, with the waiters missing the opportunity to awake, at the next iteration they will find the selinfo object destroyed, causing a PF#. That happens because the selinfo interface has no way to drain the waiters before to destroy the registered selinfo object. Also this race is quite rare to get in practice, because it would require a selrecord(), a poll request by another thread and a quick destruction of the selrecord()'ed selinfo object. Fix this by adding the seldrain() routine which should be called before to destroy the selinfo objects (in order to avoid such case), and fix the present cases where it might have already been called. Sometimes, the context is safe enough to prevent this type of race, like it happens in device drivers which installs selinfo objects on poll callbacks. There, the destruction of the selinfo object happens at driver detach time, when all the filedescriptors should be already closed, thus there cannot be a race. For this case, mfi(4) device driver can be set as an example, as it implements a full correct logic for preventing this from happening. Sponsored by: Sandvine Incorporated Reported by: rstone Tested by: pluknet Reviewed by: jhb, kib Approved by: re (bz) MFC after: 3 weeks
* Disable TSC usage inside SMP VM environments. On my VMware ESXi 4.1silby2011-08-221-3/+8
| | | | | | | | | | | | | | environment with a core i5-2500K, operation in this mode causes timeouts from the mpt driver. Switching to the ACPI-fast timer resolves this issue. Switching the VM back to single CPU mode also works, which is why I have not disabled the TSC in that mode. I did not test with KVM or other VM environments, but I am being cautious and assuming that the TSC is not reliable in SMP mode there as well. Reviewed by: kib Approved by: re (kib) MFC after: Not applicable, the timecounter code is new for 9.x
OpenPOWER on IntegriCloud