summaryrefslogtreecommitdiffstats
path: root/sys/amd64
Commit message (Collapse)AuthorAgeFilesLines
* Merge DRM CVS as of 2005-12-02, adding i915 DRM support thanks to Alexey Popov,anholt2005-12-031-0/+1
| | | | and a new r300 PCI ID.
* Update DRM to CVS snapshot as of 2005-11-28. Notable changes:anholt2005-11-281-0/+1
| | | | | | | | | | | | | - S3 Savage driver ported. - Added support for ATI_fragment_shader registers for r200. - Improved r300 support, needed for latest r300 DRI driver. - (possibly) r300 PCIE support, needs X.Org server from CVS. - Added support for PCI Matrox cards. - Software fallbacks fixed for Rage 128, which used to render badly or hang. - Some issues reported by WITNESS are fixed. - i915 module Makefile added, as the driver may now be working, but is untested. - Added scripts for copying and preprocessing DRM CVS for inclusion in the kernel. Thanks to Daniel Stone for getting me started on that.
* If we get a stray interrupt, return after logging it. In the extremelyjhb2005-11-281-0/+1
| | | | | | | | | | rare case of a stray interrupt to an unregistered source (such as a stray interrupt from the 8259As when using APIC), this could result in a page fault when it tried to walk the list of interrupt handlers to execute INTR_FAST handlers. This bug was introduced with the intr_event changes, so it's not present in 5.x or 6.x. Submitted by: Mark Tinguely tinguely at casselton dot net
* - Allow duplicate "machine" directives with the same arguments.ru2005-11-273-9/+1
| | | | - Move existing "machine" directives to DEFAULTS.
* Fix typo.le2005-11-241-1/+1
|
* Add missing "struct" in i386/i386/machdep.c,v 1.497 by deischen@.ru2005-11-241-1/+1
|
* Don't enable PUC_FASTINTR by default in the source. Instead, enable itjhb2005-11-211-0/+2
| | | | | | | | | | | via the DEFAULTS kernel configs. This allows folks to turn it that option off in the kernel configs if desired without having to hack the source. This is especially useful since PUC_FASTINTR hangs the kernel boot on my ultra60 which has two uart(4) devices hung off of a puc(4) device. I did not enable PUC_FASTINTR by default on powerpc since powerpc does not currently allow sharing of INTR_FAST with non-INTR_FAST like the other archs.
* Expand the hack to mask the atpics if 'device atpic' is not in the kerneljhb2005-11-211-8/+28
| | | | | | | | | | | | | | during boot up. Now we do a full reset of the 8259As and setup a simple interrupt handler (we actually borrow the apic one that just does an immediate iret) to handle any spurious interrupts triggered by either chip. This should fix some folks that were getting a Trap 30 during bootup of certain SMP AMD systems. This might get pushed into the 6.0 branch as an errata. For now a suitable workaround is to add 'device atpic' to your kernel config. Tested by: scottl Helpful info from: dillon MFC after: 1 week
* Eliminate pmap_init2(). It's no longer used.alc2005-11-201-5/+0
|
* - Always print the trap number so that we have something to start with forjhb2005-11-181-4/+9
| | | | | | | | mystery traps. If we don't have a message for a given trap, just use UNKNOWN for the message. - Add trap messages for T_XMMFLT and T_RESERVED. MFC after: 1 week
* Fix spelling mistake.obrien2005-11-171-1/+1
| | | | Submitted by: kris
* Revert a part of the previous commits to these files that made the NMIjhb2005-11-161-5/+4
| | | | | | | | | IPI_STOP handling code use atomic_readandclear() to execute the restart function on the first CPU to resume and restore the behavior of always executing the restart function on the BSP since this is in fact what the non-NMI IPI_STOP handler does. I did add back in a statement to clear the restart function pointer after it is executed to match the behavior of the non-NMI IPI_STOP handler.
* Revert previous commit to these files. There isn't a race necessitatingjhb2005-11-161-3/+2
| | | | | an xchg instruction as we only try to execute the startup function if the CPU ID is 0 (i.e. the BSP). I missed this earlier.
* Fix a typo in the check for an invalid APIC. If we are told about anjhb2005-11-161-1/+1
| | | | | | | | | I/O APIC that doesn't exist, then a read of the version register is going to return -1 which is 0xffffffff not 0xffffff. Tested on: i386 Tested by: Nikos Ntarmos ntarmos at ceid dot upatras dot gr MFC after: 1 week
* In get_pv_entry() use PMAP_LOCK() instead of PMAP_TRYLOCK() when deadlockalc2005-11-131-1/+4
| | | | cannot possibly occur.
* Add /dev/speaker support to amd64.ru2005-11-111-0/+3
| | | | | | | | The following repo-copies were made (by Mark Murray): sys/i386/isa/spkr.c -> sys/dev/speaker/spkr.c sys/i386/include/speaker.h -> sys/dev/speaker/speaker.h share/man/man4/man4.i386/spkr.4 -> share/man/man4/spkr.4
* Reimplement the reclamation of PV entries. Specifically, performalc2005-11-091-33/+42
| | | | | | | | | | | | | | | | | | reclamation synchronously from get_pv_entry() instead of asynchronously as part of the page daemon. Additionally, limit the reclamation to inactive pages unless allocation from the PV entry zone or reclamation from the inactive queue fails. Previously, reclamation destroyed mappings to both inactive and active pages. get_pv_entry() still, however, wakes up the page daemon when reclamation occurs. The reason being that the page daemon may move some pages from the active queue to the inactive queue, making some new pages available to future reclamations. Print the "reclaiming PV entries" message at most once per minute, but don't stop printing it after the fifth time. This way, we do not give the impression that the problem has gone away. Reviewed by: tegge
* Add uart(4). When both sio(4) and uart(4) can handle a serial port,marcel2005-11-051-1/+2
| | | | | | | | sio(4) will claim it. This change therefore only affects how ports are handled when they are not claimed by sio(4), and in principle will improve hardware support. MFC after: 2 months
* Define M_IOAPIC the same as i386peter2005-11-041-1/+1
|
* Catch up with the recent <sys/signal.h> change and make this compile.ru2005-11-041-1/+1
|
* Begin and end the initialization of pvzone in pmap_init().alc2005-11-041-19/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, pvzone's initialization was split between pmap_init() and pmap_init2(). This split initialization was the underlying cause of some UMA panics during initialization. Specifically, if the UMA boot pages was exhausted before the pvzone was fully initialized, then UMA, through no fault of its own, would use an inappropriate back-end allocator leading to a panic. (Previously, as a workaround, we have increased the UMA boot pages.) Fortunately, there is no longer any reason that pvzone's initialization cannot be completed in pmap_init(). Eliminate a check for whether pv_entry_high_water has been initialized or not from get_pv_entry(). Since pvzone's initialization is completed in pmap_init(), this check is no longer needed. Use cnt.v_page_count, the actual count of available physical pages, instead of vm_page_array_size to compute the maximum number of pv entries. Introduce the vm.pmap.pv_entries tunable on alpha and ia64. Eliminate some unnecessary white space. Discussed with: tegge (item #1) Tested by: marcel (ia64)
* Calling setrlimit from 32bit apps could potentially increase certainps2005-11-021-3/+2
| | | | | | | limits beyond what should be capiable in a 32bit process, so we must fixup the limits. Reviewed by: jhb
* Change the x86 code to allocate IDT vectors on-demand when an interruptjhb2005-11-024-95/+216
| | | | | | | | | | | | | | | | source is first enabled similar to how intr_event's now allocate ithreads on-demand. Previously, we would map IDT vectors 1:1 to IRQs. Since we only have 191 available IDT vectors for I/O interrupts, this limited us to only supporting IRQs 0-190 corresponding to the first 190 I/O APIC intpins. On many machines, however, each PCI-X bus has its own APIC even though it only has 1 or 2 devices, thus, we were reserving between 24 and 32 IRQs just for 1 or 2 devices and thus 24 or 32 IDT vectors. With this change, a machine with 100 IRQs but only 5 in use will only use up 5 IDT vectors. Also, this change provides an API (apic_alloc_vector() and apic_free_vector()) that will allow a future MSI interrupt source driver to request IDT vectors for use by MSI interrupts on x86 machines. Tested on: amd64, i386
* Throw the switch and turn on STOP_NMI on in GENERIC for amd64 and i386.jhb2005-11-011-0/+1
| | | | | Requested by: kris Ok'd by: scottl
* Catch up with ACPI-CA 20051021 importjkim2005-11-011-1/+1
|
* Instead of a panic()ing in pmap_insert_entry() if get_pv_entry()alc2005-10-311-5/+59
| | | | | | | | | | fails, reclaim a pv entry by destroying a mapping to an inactive page. Change the format strings in many of the assertions that were recently converted from PMAP_DIAGNOSTIC printf()s so that they are compatible with PAE. Avoid unnecessary differences between the amd64 and i386 format strings.
* Hook nve(4) up in i386 and amd64 NOTES.jhb2005-10-311-0/+2
| | | | MFC after: 1 week
* Normalize a significant number of kernel malloc type names:rwatson2005-10-313-3/+3
| | | | | | | | | | | | | | | | | | | - Prefer '_' to ' ', as it results in more easily parsed results in memory monitoring tools such as vmstat. - Remove punctuation that is incompatible with using memory type names as file names, such as '/' characters. - Disambiguate some collisions by adding subsystem prefixes to some memory types. - Generally prefer lower case to upper case. - If the same type is defined in multiple architecture directories, attempt to use the same name in additional cases. Not all instances were caught in this change, so more work is required to finish this conversion. Similar changes are required for UMA zone names.
* Replace diagnostic printf()s by assertions. Use consistent style foralc2005-10-301-36/+8
| | | | similar assertions.
* MFi386: bring over DEFAULTS (repocopy) and adapt. While there isn't apeter2005-10-272-9/+3
| | | | 4.x->6.x amd64 upgrade path, the config files are kept in approximate sync.
* Remove atpic as we've changed to using the lapic timer vs. using irq0obrien2005-10-271-3/+0
|
* Create a default kernel config for i386 and move 'device isa' andjhb2005-10-271-0/+17
| | | | | | | | | 'device npx' (both of which aren't really optional right now) and 'device io' and 'device mem' (to preserve POLA for 4.x users upgrading to 6.0) from GENERIC into DEFAULTS. Requested by: scottl Reviewed by: scottl
* MFi386: Various apic fixes and tweakspeter2005-10-262-6/+20
| | | | | | | * Don't recursively panic if we've already paniced and the local apic is now stuck. * Add hw.apic.* tunables/sysctls for extint controls * Change "lapic%d timer" to "cpu%d timer" intname to match i386
* Change PHYSMAP_SIZE to allow for more memory segments. The old value waspeter2005-10-261-1/+1
| | | | too low for certain Dell amd64 machines.
* Reorganize the interrupt handling code a bit to make a few things cleanerjhb2005-10-253-55/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | and increase flexibility to allow various different approaches to be tried in the future. - Split struct ithd up into two pieces. struct intr_event holds the list of interrupt handlers associated with interrupt sources. struct intr_thread contains the data relative to an interrupt thread. Currently we still provide a 1:1 relationship of events to threads with the exception that events only have an associated thread if there is at least one threaded interrupt handler attached to the event. This means that on x86 we no longer have 4 bazillion interrupt threads with no handlers. It also means that interrupt events with only INTR_FAST handlers no longer have an associated thread either. - Renamed struct intrhand to struct intr_handler to follow the struct intr_foo naming convention. This did require renaming the powerpc MD struct intr_handler to struct ppc_intr_handler. - INTR_FAST no longer implies INTR_EXCL on all architectures except for powerpc. This means that multiple INTR_FAST handlers can attach to the same interrupt and that INTR_FAST and non-INTR_FAST handlers can attach to the same interrupt. Sharing INTR_FAST handlers may not always be desirable, but having sio(4) and uhci(4) fight over an IRQ isn't fun either. Drivers can always still use INTR_EXCL to ask for an interrupt exclusively. The way this sharing works is that when an interrupt comes in, all the INTR_FAST handlers are executed first, and if any threaded handlers exist, the interrupt thread is scheduled afterwards. This type of layout also makes it possible to investigate using interrupt filters ala OS X where the filter determines whether or not its companion threaded handler should run. - Aside from the INTR_FAST changes above, the impact on MD interrupt code is mostly just 's/ithread/intr_event/'. - A new MI ddb command 'show intrs' walks the list of interrupt events dumping their state. It also has a '/v' verbose switch which dumps info about all of the handlers attached to each event. - We currently don't destroy an interrupt thread when the last threaded handler is removed because it would suck for things like ppbus(8)'s braindead behavior. The code is present, though, it is just under #if 0 for now. - Move the code to actually execute the threaded handlers for an interrrupt event into a separate function so that ithread_loop() becomes more readable. Previously this code was all in the middle of ithread_loop() and indented halfway across the screen. - Made struct intr_thread private to kern_intr.c and replaced td_ithd with a thread private flag TDP_ITHREAD. - In statclock, check curthread against idlethread directly rather than curthread's proc against idlethread's proc. (Not really related to intr changes) Tested on: alpha, amd64, i386, sparc64 Tested on: arm, ia64 (older version of patch by cognet and marcel)
* Modify the pci_cfgdisable() routine to bring it more in line withwpaul2005-10-251-2/+6
| | | | | | | | | | | | | other OSes (Solaris, Linux, VxWorks). It's not necessary to write a 0 to the config address register when using config mechanism 1 to turn off config access. In fact, it can be downright troublesome, since it seems to confuse the PCI-PCI bridge in the AMD8111 chipset and cause it to sporadically botch reads from some devices. This is the cause of the missing USP ports problem I was experiencing with my Sun Opteron system. Also correct the case for mechanism 2: it's only necessary to write a 0 to the ENABLE port.
* Rename the KDB_STOP_NMI kernel option to STOP_NMI and make it apply to alljhb2005-10-244-19/+53
| | | | | | | | | | | | | | | | | | | | | | IPI_STOP IPIs. - Change the i386 and amd64 MD IPI code to send an NMI if STOP_NMI is enabled if an attempt is made to send an IPI_STOP IPI. If the kernel option is enabled, there is also a sysctl to change the behavior at runtime (debug.stop_cpus_with_nmi which defaults to enabled). This includes removing stop_cpus_nmi() and making ipi_nmi_selected() a private function for i386 and amd64. - Fix ipi_all(), ipi_all_but_self(), and ipi_self() on i386 and amd64 to properly handle bitmapped IPIs as well as IPI_STOP IPIs when STOP_NMI is enabled. - Fix ipi_nmi_handler() to execute the restart function on the first CPU that is restarted making use of atomic_readandclear() rather than assuming that the BSP is always included in the set of restarted CPUs. Also, the NMI handler didn't clear the function pointer meaning that subsequent stop and restarts could execute the function again. - Define a new macro HAVE_STOPPEDPCBS on i386 and amd64 to control the use of stoppedpcbs[] and always enable it for i386 and amd64 instead of being dependent on KDB_STOP_NMI. It works fine in both the NMI and non-NMI cases.
* When restarting the BSP during cpu_reset() use a membar to ensure thatjhb2005-10-241-1/+3
| | | | | the updated cpustop_restartfunc is seen when the BSP resumes execution. This matches the membar already present in restart_cpus().
* Use xchg in Xcpustop to close a race and make cpustop_restartfunc trulyjhb2005-10-241-2/+3
| | | | | one-shot in the SMP case (before using the simple mov / cmp / mov sequence could allow multiple CPUs to execute the restart function on resume).
* - Various small whitespace and style nits.jhb2005-10-241-15/+10
| | | | | - Use PCPU_GET(cpumask) in preference to 1 << PCPU_GET(cpuid) in a few places.
* include opt_compat.h to unbreak the buildps2005-10-241-0/+2
|
* Specifically panic() in the case where pmap_insert_entry() fails toade2005-10-211-0/+2
| | | | | | | | | | | | get a new pv under high system load where the available pv entries have been exhausted before the pagedaemon has a chance to wake up to reclaim some. Prior to this, the NULL pointer dereference ended up causing secondary panics with rather less than useful resulting tracebacks. Reviewed by: alc, jhb MFC after: 1 week
* Redo physical/logical CPU count.jkim2005-10-171-3/+4
| | | | Suggested by: jhb
* Micro optimization for context switch. Eliminate code for saving gs.basedavidxu2005-10-172-15/+2
| | | | | | | | | | and fs.base. We always update pcb.pcb_gsbase and pcb.pcb_fsbase when user wants to set them, in context switch routine, we only need to write them into registers, we never have to read them out from registers when thread is switched away. Since rdmsr is a serialization instruction, micro benchmark shows it is worthy to do. Reviewed by: peter, jhb
* Another bit of sx(4) removal.jhb2005-10-171-3/+0
|
* Split displaying number of physical and logical cores.jkim2005-10-171-2/+3
|
* For AMD processors, nullify CPUID.HTT. FreeBSD has no need for theobrien2005-10-161-0/+9
| | | | | information it conveys, and it is only confusing people. This fixes incorrect output in the previous commit.
* Correct few MSR addresses.jkim2005-10-151-8/+8
| | | | | PR: amd64/85852 Submitted by: Nate Eldredge <nge at cs dot hmc dot edu>
* - Print number of physical/logical cores and more CPUID info.jkim2005-10-144-9/+91
| | | | | | | | | - Add newer CPUID definitions for future use. Many thanks to Mike Tancsa <mike at sentex dot net> for providing test cases for Intel Pentium D and AMD Athlon 64 X2. Approved by: anholt (mentor)
* The signal code is now an int rather than a long, so update debug printfs.jhb2005-10-141-2/+2
|
OpenPOWER on IntegriCloud