summaryrefslogtreecommitdiffstats
path: root/sys/amd64
Commit message (Collapse)AuthorAgeFilesLines
* enable IEEE80211_DEBUG and IEEE80211_AMPDU_AGE by defaultsam2008-05-031-0/+2
|
* Intel 4965 wireless driver (derived from openbsd driver of the same name)sam2008-04-291-0/+2
|
* Always use PG_PS_FRAME to extract the physical address of a 2/4MB pagealc2008-04-251-9/+10
| | | | from a PDE.
* - Add an integer argument to idle to indicate how likely we are to wakejeff2008-04-252-40/+172
| | | | | | | | | | | | | | | from idle over the next tick. - Add a new MD routine, cpu_wake_idle() to wakeup idle threads who are suspended in cpu specific states. This function can fail and cause the scheduler to fall back to another mechanism (ipi). - Implement support for mwait in cpu_idle() on i386/amd64 machines that support it. mwait is a higher performance way to synchronize cpus as compared to hlt & ipis. - Allow selecting the idle routine by name via sysctl machdep.idle. This replaces machdep.cpu_idle_hlt. Only idle routines supported by the current machine are permitted. Sponsored by: Nokia
* Implement linux_truncate64() syscall.rdivacky2008-04-231-1/+0
| | | | | Tested by: Aline de Freitas <aline@riseup.net> Approved by: kib (mentor)
* Now that all platforms use genclock, shuffle things around slightlyphk2008-04-223-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for better structure. Much of this is related to <sys/clock.h>, which should really have been called <sys/calendar.h>, but unless and until we need the name, the repocopy can wait. In general the kernel does not know about minutes, hours, days, timezones, daylight savings time, leap-years and such. All that is theoretically a matter for userland only. Parts of kernel code does however care: badly designed filesystems store timestamps in local time and RTC chips almost universally track time in a YY-MM-DD HH:MM:SS format, and sometimes in local timezone instead of UTC. For this we have <sys/clock.h> <sys/time.h> on the other hand, deals with time_t, timeval, timespec and so on. These know only seconds and fractions thereof. Move inittodr() and resettodr() prototypes to <sys/time.h>. Retain the names as it is one of the few surviving PDP/VAX references. Move startrtclock() to <machine/clock.h> on relevant platforms, it is a MD call between machdep.c/clock.c. Remove references to it elsewhere. Remove a lot of unnecessary <sys/clock.h> includes. Move the machdep.disable_rtc_set sysctl to subr_rtc.c where it belongs. XXX: should be kern.disable_rtc_set really, it's not MD.
* Multi-bss (aka vap) support for 802.11 devices.sam2008-04-201-2/+0
| | | | | | | | | | | Note this includes changes to all drivers and moves some device firmware loading to use firmware(9) and a separate module (e.g. ral). Also there no longer are separate wlan_scan* modules; this functionality is now bundled into the wlan module. Supported by: Hobnob and Marvell Reviewed by: many Obtained from: Atheros (some bits)
* move awi to the Attic; it will not make the jump to the new world ordersam2008-04-201-1/+0
| | | | Reviewed by: imp
* Put in a real isa_irq_pending() stub in order to remove two lines of dmesgpeter2008-04-191-2/+14
| | | | | | | noise from sio per unit. sio likes to probe if interrupts are configured correctly by looking at the pending bits of the atpic in order to put a non-fatal warning on the console. I think I'd rather read the pending bits from the apics, but I'm not sure its worth the hassle.
* - Add inlines for the monitor and mwait instructions.jeff2008-04-181-0/+13
| | | | Sponsored by: Nokia
* Regenerate.jkim2008-04-163-4/+46
|
* Add stubs for syscalls introduced in Linux 2.6.17 kernel.jkim2008-04-162-0/+12
| | | | | | Some GNU libc version started using them before 2.6.17 was officially out. MFC after: 3 days
* This file is unused on amd64.imp2008-04-151-32/+0
|
* Convert amd64 and i386 to share the atrtc device driver.phk2008-04-142-237/+19
|
* Connect k8temp(4) to the build.rpaulo2008-04-121-0/+2
|
* - Add the interrupt vector number to intr_event_create so MI code canjeff2008-04-111-1/+1
| | | | | | | | | | | | lookup hard interrupt events by number. Ignore the irq# for soft intrs. - Add support to cpuset for binding hardware interrupts. This has the side effect of binding any ithread associated with the hard interrupt. As per restrictions imposed by MD code we can only bind interrupts to a single cpu presently. Interrupts can be 'unbound' by binding them to all cpus. Reviewed by: jhb Sponsored by: Nokia
* Correct pmap_copy()'s method for extracting the physical address of aalc2008-04-101-6/+6
| | | | | | | | | | | 2/4MB page from a PDE. Specifically, change it to use PG_PS_FRAME, not PG_FRAME, to extract the physical address of a 2/4MB page from a PDE. Change the last argument passed to pmap_pv_insert_pde() from a vm_page_t representing the first 4KB page of a 2/4MB page to the vm_paddr_t of the 2/4MB page. This avoids an otherwise unnecessary conversion from a vm_paddr_t to a vm_page_t in pmap_copy().
* Regeneratekib2008-04-083-41/+73
|
* Implement the linux syscallskib2008-04-084-28/+26
| | | | | | | | | openat, mkdirat, mknodat, fchownat, futimesat, fstatat, unlinkat, renameat, linkat, symlinkat, readlinkat, fchmodat, faccessat. Submitted by: rdivacky Sponsored by: Google Summer of Code 2007 Tested by: pho
* Update pmap_page_wired_mappings() so that it counts 2/4MB page mappings.alc2008-04-071-4/+18
|
* Add a MI intr_event_handle() routine for the non-INTR_FILTER case. Thisjhb2008-04-051-111/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | allows all the INTR_FILTER #ifdef's to be removed from the MD interrupt code. - Rename the intr_event 'eoi', 'disable', and 'enable' hooks to 'post_filter', 'pre_ithread', and 'post_ithread' to be less x86-centric. Also, add a comment describe what the MI code expects them to do. - On amd64, i386, and powerpc this is effectively a NOP. - On arm, don't bother masking the interrupt unless the ithread is scheduled in the non-INTR_FILTER case to match what INTR_FILTER did. Also, don't bother unmasking the interrupt in the post_filter case if we never masked it. The INTR_FILTER case had been doing this by having arm_unmask_irq for the post_filter (formerly 'eoi') hook. - On ia64, stray interrupts are now masked for the non-INTR_FILTER case. They were already masked in the INTR_FILTER case. - On sparc64, use the a NULL pre_ithread hook and use intr_enable_eoi() for both the 'post_filter' and 'post_ithread' hooks to match what the non-INTR_FILTER code did. - On sun4v, retire the ithread wrapper hack by using an appropriate 'post_ithread' hook instead (it's what 'post_ithread'/'enable' was designed to do even in 5.x). Glanced at by: piso Reviewed by: marius Requested by: marius [1], [5] Tested on: amd64, i386, arm, sparc64
* Eliminate an unnecessary test and its misleading comment from pmap_enter().alc2008-04-041-6/+0
|
* Optimize pmap_pml4e() and pmap_pdpe() based upon two observations: Thealc2008-04-021-3/+1
| | | | | | given pmap is never NULL, and therefore pmap_pml4e() can never return NULL. The pervasive use of these inline functions throughout the pmap makes these simple changes worthwhile.
* Add support to mincore for detecting whether a page is part of aps2008-03-281-1/+2
| | | | | | "super" page or not. Reviewed by: alc, ups
* Add kernel module support for nfslockd and krpc. Use the module systemdfr2008-03-271-0/+1
| | | | | | | to detect (or load) kernel NLM support in rpc.lockd. Remove the '-k' option to rpc.lockd and make kernel NLM the default. A user can still force the use of the old user NLM by building a kernel without NFSLOCKD and/or removing the nfslockd.ko module.
* When building a kernel module, define MAXCPU the same as SMP sojb2008-03-271-1/+1
| | | | that modules work with and without SMP.
* Back in the good old days, PC's had random pieces of rock forphk2008-03-262-125/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | frequency generation and what frequency the generated was anyones guess. In general the 32.768kHz RTC clock x-tal was the best, because that was a regular wrist-watch Xtal, whereas the X-tal generating the ISA bus frequency was much lower quality, often costing as much as several cents a piece, so it made good sense to check the ISA bus frequency against the RTC clock. The other relevant property of those machines, is that they typically had no more than 16MB RAM. These days, CPU chips croak if their clocks are not tightly within specs and all necessary frequencies are derived from the master crystal by means if PLL's. Considering that it takes on average 1.5 second to calibrate the frequency of the i8254 counter, that more likely than not, we will not actually use the result of the calibration, and as the final clincher, we seldom use the i8254 for anything besides BEL in syscons anyway, it has become time to drop the calibration code. If you need to tell the system what frequency your i8254 runs, you can do so from the loader using hw.i8254.freq or using the sysctl kern.timecounter.tc.i8254.frequency.
* Eliminate unnecessary #includesphk2008-03-261-9/+0
|
* The "free-lance" timer in the i8254 is only used for the speakerphk2008-03-263-50/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | these days, so de-generalize the acquire_timer/release_timer api to just deal with speakers. The new (optional) MD functions are: timer_spkr_acquire() timer_spkr_release() and timer_spkr_setfreq() the last of which configures the timer to generate a tone of a given frequency, in Hz instead of 1/1193182th of seconds. Drop entirely timer2 on pc98, it is not used anywhere at all. Move sysbeep() to kern/tty_cons.c and use the timer_spkr*() if they exist, and do nothing otherwise. Remove prototypes and empty acquire-/release-timer() and sysbeep() functions from the non-beeping archs. This eliminate the need for the speaker driver to know about i8254frequency at all. In theory this makes the speaker driver MI, contingent on the timer_spkr_*() functions existing but the driver does not know this yet and still attaches to the ISA bus. Syscons is more tricky, in one function, sc_tone(), it knows the hz and things are just fine. In the other function, sc_bell() it seems to get the period from the KDMKTONE ioctl in terms if 1/1193182th second, so we hardcode the 1193182 and leave it at that. It's probably not important. Change a few other sysbeep() uses which obviously knew that the argument was in terms of i8254 frequency, and leave alone those that look like people thought sysbeep() took frequency in hertz. This eliminates the knowledge of i8254_freq from all but the actual clock.c code and the prof_machdep.c on amd64 and i386, where I think it would be smart to ask for help from the timecounters anyway [TBD].
* Rename timer0_max_count to i8254_max_count.phk2008-03-263-50/+51
| | | | | Rename timer0_real_max_count to i8254_real_max_count and make it static. Rename timer_freq to i8254_freq and make it a loader tunable.
* The RTC related pscnt and psdiv variables have no business being public.phk2008-03-262-4/+2
|
* Belatedly add BPF_JITTER in NOTES for supported architectures.jkim2008-03-241-0/+4
|
* First pass at (possibly futile) microoptimizing of cpu_switch. Resultspeter2008-03-231-75/+116
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | are mixed. Some pure context switch microbenchmarks show up to 29% improvement. Pipe based context switch microbenchmarks show up to 7% improvement. Real world tests are far less impressive as they are dominated more by actual work than switch overheads, but depending on the machine in question, workload, kernel options, phase of moon, etc, a few percent gain might be seen. Summary of changes: - don't reload MSR_[FG]SBASE registers when context switching between non-threaded userland apps. These typically cost 120 clock cycles each on an AMD cpu (less on Barcelona/Phenom). Intel cores are probably no faster on this. - The above change only helps unthreaded userland apps that tend to use the same value for gsbase. Threaded apps will get no benefit from this. - reorder things like accessing the pcb to be in memory order, to give prefetching a better chance of working. Operations are now in increasing memory address order, rather than reverse or random. - Push some lesser used code out of the main code paths. Hopefully allowing better code density in cache lines. This is probably futile. - (part 2 of previous item) Reorder code so that branches have a more realistic static branch prediction hint. Both Intel and AMD cpus default to predicting branches to lower memory addresses as being taken, and to higher memory addresses as not being taken. This is overridden by the limited dynamic branch prediction subsystem. A trip through userland might overflow this. - Futule attempt at spreading the use of the results of previous operations in new operations. Hopefully this will allow the cpus to execute in parallel better. - stop wasting 16 bytes at the top of kernel stack, below the PCB. - Never load the userland fs/gsbase registers for kthreads, but preserve curpcb->pcb_[fg]sbase as caches for the cpu. (Thanks Jeff!) Microbenchmarking this code seems to be really sensitive to things like scheduling luck, timing, cache behavior, tlb behavior, kernel options, other random code changes, etc. While it doesn't help heavy userland workloads much, it does help high context switch loads a little, and should help those that involve switching via kthreads a bit more. A special thanks to Kris for the testing and reality checks, and Jeff for tormenting me into doing this. :) This is still work-in-progress.
* Correct an error in pmap_mincore() when applied to a 2MB page mapping:alc2008-03-231-3/+3
| | | | | Use PG_PS_FRAME, not PG_FRAME, to obtain the physical address of the 2MB physical page from the PDE.
* Export TDP_KTHREAD to asm files.peter2008-03-231-0/+1
|
* Move pcb_flags to make trivially better use of cache lines.peter2008-03-231-1/+1
|
* Protect the setting of the fsbase/gsbase MSR registers and thepeter2008-03-231-0/+2
| | | | pcb_[fg]sbase values with a critical section, like the rest of the kernel.
* To date, we have assumed that the TLB will only set the PG_M bit in aalc2008-03-231-38/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PTE if that PTE has the PG_RW bit set. However, this assumption does not hold on recent processors from Intel. For example, consider a PTE that has the PG_RW bit set but the PG_M bit clear. Suppose this PTE is cached in the TLB and later the PG_RW bit is cleared in the PTE, but the corresponding TLB entry is not (yet) invalidated. Historically, upon a write access using this (stale) TLB entry, the TLB would observe that the PG_RW bit had been cleared and initiate a page fault, aborting the setting of the PG_M bit in the PTE. Now, however, P4- and Core2-family processors will set the PG_M bit before observing that the PG_RW bit is clear and initiating a page fault. In other words, the write does not occur but the PG_M bit is still set. The real impact of this difference is not that great. Specifically, we should no longer assert that any PTE with the PG_M bit set must also have the PG_RW bit set, and we should ignore the state of the PG_M bit unless the PG_RW bit is set. However, these changes enable me to remove a work-around from pmap_promote_pde(), the superpage promotion procedure. (Note: The AMD processors that we have tested, including the latest, the Phenom, still exhibit the historical behavior.) Acknowledgments: After I observed the problem, Stephan (ups) was instrumental in characterizing the exact behavior of Intel's recent TLBs. Tested by: Peter Holm
* Prevent the overflow in the calculation of the next page directory.kib2008-03-231-0/+18
| | | | | | | | | | | | | The overflow causes the wraparound with consequent corruption of the (almost) whole address space mapping. As Alan noted, pmap_copy() does not require the wrap-around checks because it cannot be applied to the kernel's pmap. The checks there are included for consistency. Reported and tested by: kris (i386/pmap.c:pmap_remove() part) Reviewed by: alc MFC after: 1 week
* Explicitly use spinlock_enter/exit rather than locking the icu_lock spinjhb2008-03-201-15/+14
| | | | | | lock in the 8259A drivers as these drivers are only used on UP systems. This slightly reduces the penalty of an SMP kernel (such as GENERIC) on a UP x86 machine.
* Implement a BUS_BIND_INTR() method in the bus interface to bind an IRQjhb2008-03-201-0/+14
| | | | | | | | | | | | | resource to a CPU. The default method is to pass the request up to the parent similar to BUS_CONFIG_INTR() so that all busses don't have to explicitly implement bus_bind_intr. A bus_bind_intr(9) wrapper routine similar to bus_setup/teardown_intr() is added for device drivers to use. Unbinding an interrupt is done by binding it to NOCPU. The IRQ resource must be allocated, but it can happen in any order with respect to bus_setup_intr(). Currently it is only supported on amd64 and i386 via nexus(4) methods that simply call the intr_bind() routine. Tested by: gallatin
* Simplify the interrupt code a bit:jhb2008-03-171-32/+15
| | | | | | | | | | | | - Always include the ie_disable and ie_eoi methods in 'struct intr_event' and collapse down to one intr_event_create() routine. The disable and eoi hooks simply aren't used currently in the !INTR_FILTER case. - Expand 'disab' to 'disable' in a few places. - Use function casts for arm and i386:intr_eoi_src() instead of wrapper routines since to trim one extra indirection. Compiled on: {arm,amd64,i386,ia64,ppc,sparc64} x {FILTER, !FILTER} Tested on: {amd64,i386} x {FILTER, !FILTER}
* Implement atomic_fetchadd_long() for all architectures and document it.pjd2008-03-161-0/+20
| | | | Reviewed by: attilio, jhb, jeff, kris (as a part of the uidinfo_waitfree.patch)
* Regen.rdivacky2008-03-163-4/+12
|
* Implement sched_setaffinity and get_setaffinity usingrdivacky2008-03-161-1/+2
| | | | | | | real cpu affinity setting primitives. Reviewed by: jeff Approved by: kib (mentor)
* In keeping with style(9)'s recommendations on macros, use a ';'rwatson2008-03-166-10/+12
| | | | | | | | | after each SYSINIT() macro invocation. This makes a number of lightweight C parsers much happier with the FreeBSD kernel source, including cflow's prcc and lxr. MFC after: 1 month Discussed with: imp, rink
* Add preliminary support for binding interrupts to CPUs:jhb2008-03-142-9/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add a new intr_event method ie_assign_cpu() that is invoked when the MI code wishes to bind an interrupt source to an individual CPU. The MD code may reject the binding with an error. If an assign_cpu function is not provided, then the kernel assumes the platform does not support binding interrupts to CPUs and fails all requests to do so. - Bind ithreads to CPUs on their next execution loop once an interrupt event is bound to a CPU. Only shared ithreads are bound. We currently leave private ithreads for drivers using filters + ithreads in the INTR_FILTER case unbound. - A new intr_event_bind() routine is used to bind an interrupt event to a CPU. - Implement binding on amd64 and i386 by way of the existing pic_assign_cpu PIC method. - For x86, provide a 'intr_bind(IRQ, cpu)' wrapper routine that looks up an interrupt source and binds its interrupt event to the specified CPU. MI code can currently (ab)use this by doing: intr_bind(rman_get_start(irq_res), cpu); however, I plan to add a truly MI interface (probably a bus_bind_intr(9)) where the implementation in the x86 nexus(4) driver would end up calling intr_bind() internally. Requested by: kmacy, gallatin, jeff Tested on: {amd64, i386} x {regular, INTR_FILTER}
* Fix a silly bogon which prevented all the CPUs that are tagged as interruptjhb2008-03-141-4/+4
| | | | | | | | | | | | | | | receivers from being given interrupts if any CPUs in the system were not tagged as interrupt receivers that I introduced when switching the x86 interrupt code to track CPUs via FreeBSD CPU IDs rather than local APIC IDs. In practice this only affects systems with Hyperthreading (though disabling HTT in the BIOS would workaround the issue) as that is the only case currently where one can have CPUs that aren't tagged as interrupt receivers. On a Dell SC1425 test box with 2 x Xeon w/ HTT (so 4 logical CPUs of which 2 were interrupt receivers) the result was that all device interrupts were sent to CPU 0. MFC after: 1 week Pointy hat to: jhb
* Rework how the nexus(4) device works on x86 to better handle the idea ofjhb2008-03-134-38/+113
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | different "platforms" on x86 machines. The existing code already handles having two platforms: ACPI and legacy. However, the existing approach was rather hardcoded and difficult to extend. These changes take the approach that each x86 hardware platform should provide its own nexus(4) driver (it can inherit most of its behavior from the default legacy nexus(4) driver) which is responsible for probing for the platform and performing appropriate platform-specific setup during attach (such as adding a platform-specific bus device). This does mean changing the x86 platform busses to no longer use an identify routine for probing, but to move that logic into their matching nexus(4) driver instead. - Make the default nexus(4) driver in nexus.c on i386 and amd64 handle the legacy platform. It's probe routine now returns BUS_PROBE_GENERIC so it can be overriden. - Expose a nexus_init_resources() routine which initializes the various resource managers so that subclassed nexus(4) drivers can invoke it from their attach routine. - The legacy nexus(4) driver explicitly adds a legacy0 device in its attach routine. - The ACPI driver no longer contains an new-bus identify method. Instead it exposes a public function (acpi_identify()) which is a probe routine that the MD nexus(4) drivers can use to probe for ACPI. All of the probe logic in acpi_probe() is now moved into acpi_identify() and acpi_probe() is just a stub. - On i386 and amd64, an ACPI-specific nexus(4) driver checks for ACPI via acpi_identify() and claims the nexus0 device if the probe succeeds. It then explicitly adds an acpi0 device in its attach routine. - The legacy(4) driver no longer knows anything about the acpi0 device. - On ia64 if acpi_identify() fails you basically end up with no devices. This matches the previous behavior where the old acpi_identify() would fail to add an acpi0 device again leaving you with no devices. Discussed with: imp Silence on: arch@
* Since version 4.3, gcc changed its behaviour concerning the i386/amd64kib2008-03-133-5/+5
| | | | | | | | | | | | | | | | | | ABI and the direction flag, that is it now assumes that the direction flag is cleared at the entry of a function and it doesn't clear once more if needed. This new behaviour conforms to the i386/amd64 ABI. Modify the signal handler frame setup code to clear the DF {e,r}flags bit on the amd64/i386 for the signal handlers. jhb@ noted that it might break old apps if they assumed DF == 1 would be preserved in the signal handlers, but that such apps should be rare and that older versions of gcc would not generate such apps. Submitted by: Aurelien Jarno <aurelien aurel32 net> PR: 121422 Reviewed by: jhb MFC after: 2 weeks
OpenPOWER on IntegriCloud