summaryrefslogtreecommitdiffstats
path: root/sys/ia64
Commit message (Collapse)AuthorAgeFilesLines
* - Allow duplicate "machine" directives with the same arguments.ru2005-11-274-10/+1
| | | | - Move existing "machine" directives to DEFAULTS.
* 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.
* Create DEFAULTS files for alpha, ia64, powerpc, and sparc64 and movejhb2005-11-212-2/+13
| | | | | | 'device mem' over from GENERIC to DEFAULTS to be consistent with i386 and amd64. Additionally, on ia64 enable ACPI by default since ia64 requires acpi.
* Eliminate pmap_init2(). It's no longer used.alc2005-11-201-5/+0
|
* In get_pv_entry() use PMAP_LOCK() instead of PMAP_TRYLOCK() when deadlockalc2005-11-131-1/+4
| | | | cannot possibly occur.
* Reimplement the reclamation of PV entries. Specifically, performalc2005-11-091-14/+65
| | | | | | | | | | | | | | | | | | 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
* 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)
* Remove the remaining spl*() calls. Add some assertions. Eliminate somealc2005-11-031-13/+2
| | | | excessive white space.
* Normalize a significant number of kernel malloc type names:rwatson2005-10-311-1/+1
| | | | | | | | | | | | | | | | | | | - 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.
* Remove a stray return statement in the interrupt dispatch functionmarcel2005-10-301-1/+0
| | | | | | that caused a premature exit after calling a fast interrupt handler and bypassing a much needed critical_exit() and the scheduling of the interrupt thread for non-fast handlers. In short: unbreak :-)
* Reorganize the interrupt handling code a bit to make a few things cleanerjhb2005-10-251-25/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* 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
* Make ttyconsolemode() call ttsetwater() so that drivers don't have to.phk2005-10-161-1/+0
|
* 1. Change prototype of trapsignal and sendsig to use ksiginfo_t *, mostdavidxu2005-10-144-26/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | changes in MD code are trivial, before this change, trapsignal and sendsig use discrete parameters, now they uses member fields of ksiginfo_t structure. For sendsig, this change allows us to pass POSIX realtime signal value to user code. 2. Remove cpu_thread_siginfo, it is no longer needed because we now always generate ksiginfo_t data and feed it to libpthread. 3. Add p_sigqueue to proc structure to hold shared signals which were blocked by all threads in the proc. 4. Add td_sigqueue to thread structure to hold all signals delivered to thread. 5. i386 and amd64 now return POSIX standard si_code, other arches will be fixed. 6. In this sigqueue implementation, pending signal set is kept as before, an extra siginfo list holds additional siginfo_t data for signals. kernel code uses psignal() still behavior as before, it won't be failed even under memory pressure, only exception is when deleting a signal, we should call sigqueue_delete to remove signal from sigqueue but not SIGDELSET. Current there is no kernel code will deliver a signal with additional data, so kernel should be as stable as before, a ksiginfo can carry more information, for example, allow signal to be delivered but throw away siginfo data if memory is not enough. SIGKILL and SIGSTOP have fast path in sigqueue_add, because they can not be caught or masked. The sigqueue() syscall allows user code to queue a signal to target process, if resource is unavailable, EAGAIN will be returned as specification said. Just before thread exits, signal queue memory will be freed by sigqueue_flush. Current, all signals are allowed to be queued, not only realtime signals. Earlier patch reviewed by: jhb, deischen Tested on: i386, amd64
* Eliminate need for __RMAN_RESOURCE_VISIBLEphk2005-10-061-6/+4
| | | | Reviewed by: marcel@
* Back out alpha/alpha/trap.c:1.124, osf1_ioctl.c:1.14, osf1_misc.c:1.57,rwatson2005-09-281-4/+0
| | | | | | | | | | | | | | | | | | | | osf1_signal.c:1.41, amd64/amd64/trap.c:1.291, linux_socket.c:1.60, svr4_fcntl.c:1.36, svr4_ioctl.c:1.23, svr4_ipc.c:1.18, svr4_misc.c:1.81, svr4_signal.c:1.34, svr4_stat.c:1.21, svr4_stream.c:1.55, svr4_termios.c:1.13, svr4_ttold.c:1.15, svr4_util.h:1.10, ext2_alloc.c:1.43, i386/i386/trap.c:1.279, vm86.c:1.58, unaligned.c:1.12, imgact_elf.c:1.164, ffs_alloc.c:1.133: Now that Giant is acquired in uprintf() and tprintf(), the caller no longer leads to acquire Giant unless it also holds another mutex that would generate a lock order reversal when calling into these functions. Specifically not backed out is the acquisition of Giant in nfs_socket.c and rpcclnt.c, where local mutexes are held and would otherwise violate the lock order with Giant. This aligns this code more with the eventual locking of ttys. Suggested by: bde
* Implement 32 bit getcontext/setcontext/swapcontext on amd64. I've addedpeter2005-09-271-0/+21
| | | | | stubs for ia64 to keep it compiling. These are used by 32 bit apps such as gdb.
* Add a new atomic_fetchadd() primitive that atomically adds a value to ajhb2005-09-271-0/+19
| | | | | | | | | variable and returns the previous value of the variable. Tested on: i386, alpha, sparc64, arm (cognet) Reviewed by: arch@ Submitted by: cognet (arm) MFC after: 1 week
* Add GIANT_REQUIRED and WITNESS sleep warnings to uprintf() and tprintf(),rwatson2005-09-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | as they both interact with the tty code (!MPSAFE) and may sleep if the tty buffer is full (per comment). Modify all consumers of uprintf() and tprintf() to hold Giant around calls into these functions. In most cases, this means adding an acquisition of Giant immediately around the function. In some cases (nfs_timer()), it means acquiring Giant higher up in the callout. With these changes, UFS no longer panics on SMP when either blocks are exhausted or inodes are exhausted under load due to races in the tty code when running without Giant. NB: Some reduction in calls to uprintf() in the svr4 code is probably desirable. NB: In the case of nfs_timer(), calling uprintf() while holding a mutex, or even in a callout at all, is a bad idea, and will generate warnings and potential upset. This needs to be fixed, but was a problem before this change. NB: uprintf()/tprintf() sleeping is generally a bad ideas, as is having non-MPSAFE tty code. MFC after: 1 week
* Introduce a kernel config for the Mandatory Access Control framework.csjp2005-09-181-0/+28
| | | | | | | | This kernel config briefly describes some of the major MAC policies available on FreeBSD. The hope is that this will raise the awareness about MAC and get more people interested. Discussed with: scottl
* Eliminate unused definitions.alc2005-09-112-8/+1
|
* Canonize the include of acpi.h.obrien2005-09-114-4/+4
|
* Merge db_interface.c and db_trace.c into db_machdep.c.marcel2005-09-102-337/+290
|
* Move the prototypes of db_md_set_watchpoint(), db_md_clr_watchpoint()marcel2005-09-101-4/+0
| | | | and db_md_list_watchpoints() to ddb/ddb.h.
* Move the ia32_sigcode structure from ia32_sigtramp.c to ia32_signal.c.marcel2005-09-102-44/+19
| | | | It's a bit excessive to have it in a file of its own.
* Remove redundant $FreeBSD$marcel2005-09-101-2/+0
|
* Change the High FP lock from a sleep lock to a spin lock. We canmarcel2005-09-094-16/+16
| | | | | | take the lock from interrupt context, which causes an implicit lock order reversal. We've been using the lock carefully enough that making it a spin lock should not be harmful.
* Milestone: enable SMP by default.marcel2005-09-051-1/+1
|
* o In pmap_remove_pte: always invalidate the page. Previously the pagemarcel2005-09-051-13/+11
| | | | | | | | | | | | was not invalidated if the PTE was not actually being removed. In an UP kernel this didn't cause problems, because the new mapping would preempt the old one. In an SMP kernel this could lead to the use of stale translations when processes move between CPUs at the "right" moment. This fixes the last of the obvious SMP problems and it should be safe to enable SMP by default now. o In pmap_remove_pte: minor code refactoring to avoid duplication. o Test all PTE pointers against NULL. Don't use implicit boolean tests.
* o s/vhpt_size/pmap_vhpt_log2size/gmarcel2005-09-033-48/+88
| | | | | | | | | | | | | | o s/vhpt_base/pmap_vhpt_base/g o s/vhpt_bucket/pmap_vhpt_bucket/g o Declare the above in <machine/pmap.h> o Move the vm.stats.vhpt.* sysctls to machdep.vhpt.* o Create a tunable machdep.vhpt.log2size, with corresponding sysctl. The tunable allows the user to specify the VHPT size from the loader. o Don't keep track of the number of PTEs in the VHPT. Calculate the population when necessary by iterating the buckets and summing up the length of the buckets. o Don't perform the tpa instruction with a bucket lock held. The instruction can (theoretically) fault and locking is not needed.
* Fix collision chain termination checks. The result of IA64_PHYS_TO_RR7marcel2005-09-031-16/+18
| | | | | | | | | | is never 0, so one cannot test for a NULL pointer after a physical address is translated into a virtual pointer with said macro. Instead, keep the physical address around and test it against 0. Note that this obviously implies that a PTE can never be allocated at physical address 0. This isn't exactly guaranteed, but hasn't been a problem so far. We test the physical address against 0 for as long as the ia64 port exists...
* Pass a value of type vm_prot_t to pmap_enter_quick() so that it determinealc2005-09-031-3/+4
| | | | whether the mapping should permit execute access.
* Move MINSIGSTKSZ from <machine/signal.h> to <machine/_limits.h> and renamestefanf2005-08-202-5/+3
| | | | | | | | | | it to __MINSIGSTKSZ. Define MINSIGSTKSZ in <sys/signal.h>. This is done in order to use MINSIGSTKSZ for the macro PTHREAD_STACK_MIN in <pthread.h> (soon <limits.h>) without having to include the whole <sys/signal.h> header. Discussed with: bde
* Remove the execute permission for stacks.marcel2005-08-141-1/+1
|
* o s/pmap_lpte_/pmap_/gmarcel2005-08-131-80/+52
| | | | o Remove pmap_is_referenced(). It was already compiled-out.
* Fix the problem with the IPI for the lazy context switching of themarcel2005-08-132-2/+5
| | | | | | | | | | | high FP registers. It was not that the IPI got lost due to the perceived unreliability of the IPI delivery, but rather that the IPI was not assigned a vector (ugh). Sending a 0 vector to a CPU results in a stray external interrupt. Add a KASSERT to ipi_send() to catch this. The initialization of the IPIs could be better, but it's not at all sure what the future of the code is. Avoid wasting a lot of time on something that is going to be rewritten anyway.
* Improve SMP support:marcel2005-08-069-320/+318
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | o Allocate a VHPT per CPU. The VHPT is a hash table that the CPU uses to look up translations it can't find in the TLB. As such, the VHPT serves as a level 1 cache (the TLB being a level 0 cache) and best results are obtained when it's not shared between CPUs. The collision chain (i.e. the hash bucket) is shared between CPUs, as all buckets together constitute our collection of PTEs. To achieve this, the collision chain does not point to the first PTE in the list anymore, but to a hash bucket head structure. The head structure contains the pointer to the first PTE in the list, as well as a mutex to lock the bucket. Thus, each bucket is locked independently of each other. With at least 1024 buckets in the VHPT, this provides for sufficiently finei-grained locking to make the ssolution scalable to large SMP machines. o Add synchronisation to the lazy FP context switching. We do this with a seperate per-thread lock. On SMP machines the lazy high FP context switching without synchronisation caused inconsistent state, which resulted in a panic. Since the use of the high FP registers is not common, it's possible that races exist. The ia64 package build has proven to be a good stress test, so this will get plenty of exercise in the near future. o Don't use the local ID of the processor we want to send the IPI to as the argument to ipi_send(). use the struct pcpu pointer instead. The reason for this is that IPI delivery is unreliable. It has been observed that sending an IPI to a CPU causes it to receive a stray external interrupt. As such, we need a way to make the delivery reliable. The intended solution is to queue requests in the target CPU's per-CPU structure and use a single IPI to inform the CPU that there's a new entry in the queue. If that IPI gets lost, the CPU can check it's queue at any convenient time (such as for each clock interrupt). This also allows us to send requests to a CPU without interrupting it, if such would be beneficial. With these changes SMP is almost working. There are still some random process crashes and the machine can hang due to having the IPI lost that deals with the high FP context switch. The overhead of introducing the hash bucket head structure results in a performance degradation of about 1% for UP (extra pointer indirection). This is surprisingly small and is offset by gaining reasonably/good scalable SMP support.
* Reduce the default MAXCPU from 16 to 4. This is in preparation ofmarcel2005-08-061-1/+1
| | | | | | | | allocating a VHPT per CPU. Since we don't yet know how many CPUs are actually in the system at the time we need to allocate the VHPTs, we allocate for MAXCPU processors. This can result in a lot of wasted space for 2-way machines. So, for now, limit MAXCPU to something smaller until we have something more dynamic.
* For ia64_ptc_{e,g,ga,l}(), use instruction serialization. Wemarcel2005-08-061-4/+4
| | | | | typically don't know what the TLB described and need to assume that it affects the fetching of instructions.
* - Add support for saving stack traces and displaying them via printf(9)jeff2005-08-031-0/+13
| | | | | | | and KTR. Contributed by: Antoine Brodin <antoine.brodin@laposte.net> Concept code from: Neal Fachan <neal@isilon.com>
* Convert the atomic_ptr() operations over to operating on uintptr_tjhb2005-07-151-58/+19
| | | | | | | | | | variables rather than void * variables. This makes it easier and simpler to get asm constraints and volatile keywords correct. MFC after: 3 days Tested on: i386, alpha, sparc64 Compiled on: ia64, powerpc, amd64 Kernel toolchain busted on: arm
* Add recently invented COMPAT_FREEBSD5 option.kensmith2005-07-141-0/+1
| | | | MFC after: 3 days
* Validate if the value written into {FS,GS}.base is a canonicaldavidxu2005-07-101-1/+2
| | | | | | | | | address, writting non-canonical address can cause kernel a panic, by restricting base values to 0..VM_MAXUSER_ADDRESS, ensuring only canonical values get written to the registers. Reviewed by: peter, Josepha Koshy < joseph.koshy at gmail dot com > Approved by: re (scottl)
* Enhance ia64_flush_dirty() to handle the case in which td != curthread.marcel2005-07-052-23/+52
| | | | | | | | This case is triggered with ptrace(2) and the PT_SETREGS function. Change the return type of the function to int so that errors can be passed on to the caller. Approved by: re (scottl)
* Implement functions calls from within DDB on ia64. On ia64 a functionmarcel2005-07-022-0/+24
| | | | | | | | | | | | | | | | | | | | | | | pointer doesn't point to the first instruction of that function, but rather to a descriptor. The descriptor has the address of the first instruction, as well as the value of the global pointer. The symbol table doesn't know anything about descriptors, so if you lookup the name of a function you get the address of the first instruction. The cast from the address, which is the result of the symbol lookup, to a function pointer as is done in db_fncall is therefore invalid. Abstract this detail behind the DB_CALL macro. By default DB_CALL is defined as db_fncall_generic, which yields the old behaviour. On ia64 the macro is defined as db_fncall_ia64, in which a descriptor is constructed to yield a valid function pointer. While here, introduce DB_MAXARGS. DB_MAXARGS replaces the existing (local) MAXARGS. The DB_MAXARGS macro can be defined by platforms to create a convenient maximum. By default this will be the legacy 10. On ia64 we define this macro to be 8, for 8 is the maximum number of arguments that can be passed in registers. This avoids having to implement spilling of arguments on the memory stack. Approved by: re (dwhite)
* Fix a buglet that was present in the ia64 code and that got inheritedmarcel2005-07-021-0/+1
| | | | | | | | | | | | | | | | | | by amd64 and i386: For buffered writes we collect data and write it out a ${DEV_BSIZE}-sized block at a time. The fragsz variable is used to keep track of how much data we have collected in the buffer so far and it's reset to zero immediately after writing a block to the dump device. When the last, possibly partially filled buffer is flushed, we didn't reset fragsz to 0 and as such would stop reflecting reality. Since we currently only need to do buffered writes once, this isn't a problem. However, when kernel dumps are made by hand (say by callling doadump from within DDB), the improperly cleared state from the first call to dumpsys causes the next call to dumpsys to create an invalid code file. This change resets fragsz after flushing the partially filled buffer so that it fixes the two problems at once. Approved by: re (scottl)
* Jumbo-commit to enhance 32 bit application support on 64 bit kernels.peter2005-06-301-0/+82
| | | | | | | | | | | | | | | | | | | | | | | | This is good enough to be able to run a RELENG_4 gdb binary against a RELENG_4 application, along with various other tools (eg: 4.x gcore). We use this at work. ia32_reg.[ch]: handle the 32 bit register file format, used by ptrace, procfs and core dumps. procfs_*regs.c: vary the format of proc/XXX/*regs depending on the client and target application. procfs_map.c: Don't print a 64 bit value to 32 bit consumers, or their sscanf fails. They expect an unsigned long. imgact_elf.c: produce a valid 32 bit coredump for 32 bit apps. sys_process.c: handle 32 bit consumers debugging 32 bit targets. Note that 64 bit consumers can still debug 32 bit targets. IA64 has got stubs for ia32_reg.c. Known limitations: a 5.x/6.x gdb uses get/setcontext(), which isn't implemented in the 32/64 wrapper yet. We also make a tiny patch to gdb pacify it over conflicting formats of ld-elf.so.1. Approved by: re
* Handle B-unit break instructions. The break.b is unique in that themarcel2005-06-271-1/+50
| | | | | | | | | | | | | | | | | | | | | | | | immediate is not saved by the architecture. Any of the break.{mifx} instructions have their immediate saved in cr.iim on interruption. Consequently, when we handle the break interrupt, we end up with a break value of 0 when it was a break.b. The immediate is important because it distinguishes between different uses of the break and which are defined by the runtime specification. The bottomline is that when the GNU debugger replaces a B-unit instruction with a break instruction in the inferior, we would not send the process a SIGTRAP when we encounter it, because the value is not one we recognize as a debugger breakpoint. This change adds logic to decode the bundle in which the break instruction lives whenever the break value is 0. The assumption being that it's a break.b and we fetch the immediate directly out of the instruction. If the break instruction was not a break.b, but any of break.{mifx} with an immediate of 0, we would be doing unnecessary work. But since a break 0 is invalid, this is not a problem and it will still result in a SIGILL being sent to the process. Approved by: re (scottl)
* Replace the existing copyright notice with my own. Over the years I'vemarcel2005-06-271-23/+19
| | | | | | | changed this file so much that it's equivalent to a rewrite, and I'm not talking about any of the cosmetic changes of course. Approved by: re (scottl)
* Cosmetic: s/u_int64_t/uint64_t/gmarcel2005-06-271-7/+7
| | | | Approved by: re (scottl)
OpenPOWER on IntegriCloud