#
267654 |
|
19-Jun-2014 |
gjb |
Copy stable/9 to releng/9.3 as part of the 9.3-RELEASE cycle.
Approved by: re (implicit) Sponsored by: The FreeBSD Foundation |
#
262192 |
|
18-Feb-2014 |
jhb |
MFC 261517,261520: Convert the license on files where I am the sole copyright holder to 2 clause BSD licenses.
|
#
247877 |
|
06-Mar-2013 |
avg |
MFC r246247: x86 suspend/resume: suspend pics and pseudo-pics in reverse order
|
#
235260 |
|
11-May-2012 |
attilio |
MFC r233961,234074,234105,234564,234723,234989,235231-235232: - Fix a bug in x86 and sparc64 where the intr cpu mask does only enables the BSP. - Remove the SMP constraints for intr_add_cpu
|
#
234144 |
|
11-Apr-2012 |
jhb |
MFC 232744,232747,233031: - Allow a native i386 kernel to be built with 'nodevice atpic'. Just as on amd64, if 'device isa' is present quiesce the 8259A's during boot and resume from suspend. - Move i386's intr_machdep.c to the x86 tree and share it with amd64. - 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.
Note, I normally would have merged 232747 separately, but 233031 assumed 232747 was already merged and 232744 needs to be merged with 233031.
|
#
232747 |
|
09-Mar-2012 |
jhb |
Move i386's intr_machdep.c to the x86 tree and share it with amd64.
|
#
232744 |
|
09-Mar-2012 |
jhb |
Allow a native i386 kernel to be built with 'nodevice atpic'. Just as on amd64, if 'device isa' is present quiesce the 8259A's during boot and resume from suspend.
While here, be more selective on amd64 about which kernel configurations need elcr.c.
MFC after: 2 weeks
|
#
224187 |
|
18-Jul-2011 |
attilio |
- Remove the eintrcnt/eintrnames usage and introduce the concept of sintrcnt/sintrnames which are symbols containing the size of the 2 tables. - For amd64/i386 remove the storage of intr* stuff from assembly files. This area can be widely improved by applying the same to other architectures and likely finding an unified approach among them and move the whole code to be MI. More work in this area is expected to happen fairly soon.
No MFC is previewed for this patch.
Tested by: pluknet Reviewed by: jhb Approved by: re (kib)
|
#
222813 |
|
07-Jun-2011 |
attilio |
etire the cpumask_t type and replace it with cpuset_t usage.
This is intended to fix the bug where cpu mask objects are capped to 32. MAXCPU, then, can now arbitrarely bumped to whatever value. Anyway, as long as several structures in the kernel are statically allocated and sized as MAXCPU, it is suggested to keep it as low as possible for the time being.
Technical notes on this commit itself: - More functions to handle with cpuset_t objects are introduced. The most notable are cpusetobj_ffs() (which calculates a ffs(3) for a cpuset_t object), cpusetobj_strprint() (which prepares a string representing a cpuset_t object) and cpusetobj_strscan() (which creates a valid cpuset_t starting from a string representation). - pc_cpumask and pc_other_cpus are target to be removed soon. With the moving from cpumask_t to cpuset_t they are now inefficient and not really useful. Anyway, for the time being, please note that access to pcpu datas is protected by sched_pin() in order to avoid migrating the CPU while reading more than one (possible) word - Please note that size of cpuset_t objects may differ between kernel and userland. While this is not directly related to the patch itself, it is good to understand that concept and possibly use the patch as a reference on how to deal with cpuset_t objects in userland, when accessing kernland members. - KTR_CPUMASK is changed and now is represented through a string, to be set as the example reported in NOTES.
Please additively note that no MAXCPU is bumped in this patch, but private testing has been done until to MAXCPU=128 on a real 8x8x2(htt) machine (amd64).
Please note that the FreeBSD version is not yet bumped because of the upcoming pcpu changes. However, note that this patch is not targeted for MFC.
People to thank for the time spent on this patch: - sbruno, pluknet and Nicholas Esborn (nick AT desert DOT net) tested several revision of the patches and really helped in improving stability of this work. - marius fixed several bugs in the sparc64 implementation and reviewed patches related to ktr. - jeff and jhb discussed the basic approach followed. - kib and marcel made targeted review on some specific part of the patch. - marius, art, nwhitehorn and andreast reviewed MD specific part of the patch. - marius, andreast, gonzo, nwhitehorn and jceel tested MD specific implementations of the patch. - Other people have made contributions on other patches that have been already committed and have been listed separately.
Companies that should be mentioned for having participated at several degrees: - Yahoo! for having offered the machines used for testing on big count of CPUs. - The FreeBSD Foundation for having sponsored my devsummit attendance, which has been instrumental. - Sandvine for having offered offices and infrastructure during development.
(I really hope I didn't forget anyone, if it happened I apologize in advance).
|
#
214448 |
|
28-Oct-2010 |
jhb |
Use 'PCPU_GET(apic_id)' to determine the BSP's APIC ID on a UP machine when routing interrupts instead of cpu_apic_ids[0] since cpu_apic_ids[] is only populated for multiple-CPU machines. This also matches what the code does when SMP is not enabled.
PR: bin/151616 Tested by: "Damian S. Kolodziejczyk" damkol | gmail Submitted by: avg MFC after: 1 week
|
#
209649 |
|
02-Jul-2010 |
mav |
Revert r209638. After commit, there appeared to be more people who liked previous name of stray interrupt counters, then responded to the list.
|
#
209638 |
|
01-Jul-2010 |
mav |
Make stray irq counters have format alike to other counters. Unified format makes string processing (for example by `systat -vm`) easier.
|
#
209155 |
|
14-Jun-2010 |
mav |
Fix bug introduced in SVN rev 194985. When calling pic_assign_cpu() for pre-bound IRQs during boot, submit there LAPIC ID, same as in other places, not CPU ID.
|
#
198170 |
|
16-Oct-2009 |
kib |
Move intr_describe() out of #ifdef SMP; the function is always required.
Reviewed by: jhb
|
#
198134 |
|
15-Oct-2009 |
jhb |
Add a facility for associating optional descriptions with active interrupt handlers. This is primarily intended as a way to allow devices that use multiple interrupts (e.g. MSI) to meaningfully distinguish the various interrupt handlers. - Add a new BUS_DESCRIBE_INTR() method to the bus interface to associate a description with an active interrupt handler setup by BUS_SETUP_INTR. It has a default method (bus_generic_describe_intr()) which simply passes the request up to the parent device. - Add a bus_describe_intr() wrapper around BUS_DESCRIBE_INTR() that supports printf(9) style formatting using var args. - Reserve MAXCOMLEN bytes in the intr_handler structure to hold the name of an interrupt handler and copy the name passed to intr_event_add_handler() into that buffer instead of just saving the pointer to the name. - Add a new intr_event_describe_handler() which appends a description string to an interrupt handler's name. - Implement support for interrupt descriptions on amd64 and i386 by having the nexus(4) driver supply a custom bus_describe_intr method that invokes a new intr_describe() MD routine which in turn looks up the associated interrupt event and invokes intr_event_describe_handler().
Requested by: many Reviewed by: scottl MFC after: 2 weeks
|
#
195249 |
|
01-Jul-2009 |
jhb |
Improve the handling of cpuset with interrupts. - For x86, change the interrupt source method to assign an interrupt source to a specific CPU to return an error value instead of void, thus allowing it to fail. - If moving an interrupt to a CPU fails due to a lack of IDT vectors in the destination CPU, fail the request with ENOSPC rather than panicing. - For MSI interrupts on x86 (but not MSI-X), only allow cpuset to be used on the first interrupt in a group. Moving the first interrupt in a group moves the entire group. - Use the icu_lock to protect intr_next_cpu() on x86 instead of the intr_table_lock to fix a LOR introduced in the last set of MSI changes. - Add a new privilege PRIV_SCHED_CPUSET_INTR for using cpuset with interrupts. Previously, binding an interrupt to a CPU only performed a privilege check if the interrupt had an interrupt thread. Interrupts without a thread could be bound by non-root users as a result. - If an interrupt event's assign_cpu method fails, then restore the original cpuset mask for the associated interrupt thread.
Approved by: re (kib)
|
#
195002 |
|
25-Jun-2009 |
jhb |
Fix kernels compiled without SMP support. Make intr_next_cpu() available for UP kernels but as a stub that always returns the single CPU's local APIC ID.
Reported by: kib
|
#
194985 |
|
25-Jun-2009 |
jhb |
- Restore the behavior of pre-allocating IDT vectors for MSI interrupts. This is mostly important for the multiple MSI message case where the IDT vectors for the entire group need to be allocated together. This also restores the assumptions made by the PCI bus code that it could invoke PCIB_MAP_MSI() once MSI vectors were allocated. - To avoid whiplash with CPU assignments, change the way that CPUs are assigned to interrupt sources on activation. Instead of assigning the CPU via pic_assign_cpu() before calling enable_intr(), allow the different interrupt source drivers to ask the MD interrupt code which CPU to use when they allocate an IDT vector. I/O APIC interrupt pins do this in their pic_enable_intr() routines giving the same behavior as before. MSI sources do it when the IDT vectors are allocated during msi_alloc() and msix_alloc(). - Change the intr_table_lock from an sx lock to a mutex.
Tested by: rnoland
|
#
185306 |
|
25-Nov-2008 |
ganbold |
Remove unused variable.
Found with: Coverity Prevent(tm) CID: 3685
Approved by: scottl
|
#
183133 |
|
18-Sep-2008 |
kmacy |
Don't do round robin assignment of interrupts on xen
MFC after: 1 month
|
#
178092 |
|
11-Apr-2008 |
jeff |
- Add the interrupt vector number to intr_event_create so MI code can 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
|
#
177940 |
|
05-Apr-2008 |
jhb |
Add a MI intr_event_handle() routine for the non-INTR_FILTER case. This 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
|
#
177325 |
|
17-Mar-2008 |
jhb |
Simplify the interrupt code a bit: - 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}
|
#
177253 |
|
16-Mar-2008 |
rwatson |
In keeping with style(9)'s recommendations on macros, use a ';' 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
|
#
177181 |
|
14-Mar-2008 |
jhb |
Add preliminary support for binding interrupts to CPUs: - 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}
|
#
177160 |
|
14-Mar-2008 |
jhb |
Fix a silly bogon which prevented all the CPUs that are tagged as interrupt 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
|
#
173799 |
|
21-Nov-2007 |
scottl |
Extend critical section coverage in the low-level interrupt handlers to include the ithread scheduling step. Without this, a preemption might occur in between the interrupt getting masked and the ithread getting scheduled. Since the interrupt handler runs in the context of curthread, the scheudler might see it as having a such a low priority on a busy system that it doesn't get to run for a _long_ time, leaving the interrupt stranded in a disabled state. The only way that the preemption can happen is by a fast/filter handler triggering a schduling event earlier in the handler, so this problem can only happen for cases where an interrupt is being shared by both a fast/filter handler and an ithread handler. Unfortunately, it seems to be common for this sharing to happen with network and USB devices, for example. This fixes many of the mysterious TCP session timeouts and NIC watchdogs that were being reported. Many thanks to Sam Lefler for getting to the bottom of this problem.
Reviewed by: jhb, jeff, silby
|
#
170291 |
|
04-Jun-2007 |
attilio |
Rework the PCPU_* (MD) interface: - Rename PCPU_LAZY_INC into PCPU_INC - Add the PCPU_ADD interface which just does an add on the pcpu member given a specific value.
Note that for most architectures PCPU_INC and PCPU_ADD are not safe. This is a point that needs some discussions/work in the next days.
Reviewed by: alc, bde Approved by: jeff (mentor)
|
#
170162 |
|
31-May-2007 |
piso |
In some particular cases (like in pccard and pccbb), the real device handler is wrapped in a couple of functions - a filter wrapper and an ithread wrapper. In this case (and just in this case), the filter wrapper could ask the system to schedule the ithread and mask the interrupt source if the wrapped handler is composed of just an ithread handler: modify the "old" interrupt code to make it support this situation, while the "new" interrupt code is already ok.
Discussed with: jhb
|
#
169391 |
|
08-May-2007 |
jhb |
Minor fixes and tweaks to the x86 interrupt code: - Split the intr_table_lock into an sx lock used for most things, and a spin lock to protect intrcnt_index. Originally I had this as a spin lock so interrupt code could use it to lookup sources. However, we don't actually do that because it would add a lot of overhead to interrupts, and if we ever do support removing interrupt sources, we can use other means to safely do so w/o locking in the interrupt handling code. - Replace is_enabled (boolean) with is_handlers (a count of handlers) to determine if a source is enabled or not. This allows us to notice when a source is no longer in use. When that happens, we now invoke a new PIC method (pic_disable_intr()) to inform the PIC driver that the source is no longer in use. The I/O APIC driver frees the APIC IDT vector when this happens. The MSI driver no longer needs to have a hack to clear is_enabled during msi_alloc() and msix_alloc() as a result of this change as well. - Add an apic_disable_vector() to reset an IDT vector back to Xrsvd to complement apic_enable_vector() and use it in the I/O APIC and MSI code when freeing an IDT vector. - Add a new nexus hook: nexus_add_irq() to ask the nexus driver to add an IRQ to its irq_rman. The MSI code uses this when it creates new interrupt sources to let the nexus know about newly valid IRQs. Previously the msi_alloc() and msix_alloc() passed some extra stuff back to the nexus methods which then added the IRQs. This approach is a bit cleaner. - Change the MSI sx lock to a mutex. If we need to create new sources, drop the lock, create the required number of sources, then get the lock and try the allocation again.
|
#
169320 |
|
06-May-2007 |
piso |
Bring in the reminaing bits to make interrupt filtering work:
o push much of the i386 and amd64 MD interrupt handling code (intr_machdep.c::intr_execute_handlers()) into MI code (kern_intr.c::ithread_loop()) o move filter handling to kern_intr.c::intr_filter_loop() o factor out the code necessary to mask and ack an interrupt event (intr_machdep.c::intr_eoi_src() and intr_machdep.c::intr_disab_eoi_src()), and make them part of 'struct intr_event', passing them as arguments to kern_intr.c::intr_event_create(). o spawn a private ithread per handler (struct intr_handler::ih_thread) with filter and ithread functions.
Approved by: re (implicit?)
|
#
167273 |
|
06-Mar-2007 |
jhb |
Change the x86 interrupt code to use FreeBSD CPU IDs (i.e. PCPU_GET(cpuid)) rather than local APIC IDs to keep track of CPUs which can handle interrupts.
|
#
166922 |
|
23-Feb-2007 |
jhb |
Use ih_filter instead of ih_handler in a couple of places. This fixes most INTR_FAST handlers on i386.
Reviewed by: piso
|
#
166901 |
|
23-Feb-2007 |
piso |
o break newbus api: add a new argument of type driver_filter_t to bus_setup_intr()
o add an int return code to all fast handlers
o retire INTR_FAST/IH_FAST
For more info: http://docs.freebsd.org/cgi/getmsg.cgi?fetch=465712+0+current/freebsd-current
Reviewed by: many Approved by: re@
|
#
165125 |
|
12-Dec-2006 |
jhb |
Add a function to return the MD interrupt source cookie associated with an interrupt event. Use this in the x86 code to fixup the intrcnt names when an interrupt handler is removed.
|
#
164358 |
|
17-Nov-2006 |
jhb |
Trim some noise from bootverbose: - Drop the printf in intr_machdep.c when we assign an interrupt souce to a CPU. Each source already has a more detailed printf. - Don't output a line for each ioapic pin showing its initial state, this has outlived its usefulness. - When an APIC enumerator sets the bus, polarity, or trigger mode of an ioapic pin, just return success without printing anything if the new value matches the current one.
MFC after: 2 weeks
|
#
163219 |
|
10-Oct-2006 |
jhb |
Change the x86 interrupt code to suspend/resume interrupt controllers (PICs) rather than interrupt sources. This allows interrupt controllers with no interrupt pics (such as the 8259As when APIC is in use) to participate in suspend/resume. - Always register the 8259A PICs even if we don't use any of their pins. - Explicitly reset the 8259As on resume on amd64 if 'device atpic' isn't included. - Add a "dummy" PIC for the local APIC on the BSP to reset the local APIC on resume. This gets suspend/resume working with APIC on UP systems. SMP still needs more work to bring the APs back to life.
The MFC after is tentative.
Tested by: anholt (i386) Submitted by: Andrea Bittau <a.bittau at cs.ucl.ac.uk> (3) MFC after: 1 week
|
#
160312 |
|
12-Jul-2006 |
jhb |
Simplify the pager support in DDB. Allowing different db commands to install custom pager functions didn't actually happen in practice (they all just used the simple pager and passed in a local quit pointer). So, just hardcode the simple pager as the only pager and make it set a global db_pager_quit flag that db commands can check when the user hits 'q' (or a suitable variant) at the pager prompt. Also, now that it's easy to do so, enable paging by default for all ddb commands. Any command that wishes to honor the quit flag can do so by checking db_pager_quit. Note that the pager can also be effectively disabled by setting $lines to 0.
Other fixes: - 'show idt' on i386 and pc98 now actually checks the quit flag and terminates early. - 'show intr' now actually checks the quit flag and terminates early.
|
#
156124 |
|
28-Feb-2006 |
jhb |
Rework how we wire up interrupt sources to CPUs: - Throw out all of the logical APIC ID stuff. The Intel docs are somewhat ambiguous, but it seems that the "flat" cluster model we are currently using is only supported on Pentium and P6 family CPUs. The other "hierarchy" cluster model that is supported on all Intel CPUs with local APICs is severely underdocumented. For example, it's not clear if the OS needs to glean the topology of the APIC hierarchy from somewhere (neither ACPI nor MP Table include it) and setup the logical clusters based on the physical hierarchy or not. Not only that, but on certain Intel chipsets, even though there were 4 CPUs in a logical cluster, all the interrupts were only sent to one CPU anyway. - We now bind interrupts to individual CPUs using physical addressing via the local APIC IDs. This code has also moved out of the ioapic PIC driver and into the common interrupt source code so that it can be shared with MSI interrupt sources since MSI is addressed to APICs the same way that I/O APIC pins are. - Interrupt source classes grow a new method pic_assign_cpu() to bind an interrupt source to a specific local APIC ID. - The SMP code now tells the interrupt code which CPUs are avaiable to handle interrupts in a simpler and more intuitive manner. For one thing, it means we could now choose to not route interrupts to HT cores if we wanted to (this code is currently in place in fact, but under an #if 0 for now). - For now we simply do static round-robin of IRQs to CPUs when the first interrupt handler just as before, with the change that IRQs are now bound to individual CPUs rather than groups of up to 4 CPUs. - Because the IRQ to CPU mapping has now been moved up a layer, it would be easier to manage this mapping from higher levels. For example, we could allow drivers to specify a CPU affinity map for their interrupts, or we could allow a userland tool to bind IRQs to specific CPUs.
The MFC is tentative, but I want to see if this fixes problems some folks had with UP APIC kernels on 6.0 on SMP machines (an SMP kernel would work fine, but a UP APIC kernel (such as GENERIC in RELENG_6) would lose interrupts).
MFC after: 1 week
|
#
153146 |
|
05-Dec-2005 |
jhb |
Change the i386 code to pass the interrupt vector as a separate argument rather than embedding it in the intrframe as if_vec. This reduces diffs with amd64 somewhat. - Remove cf_vec from clockframe (it wasn't used anyway) and stop pushing dummy vector arguments for ipi_bitmap_handler() and lapic_handle_timer() since clockframe == trapframe now. - Fix ddb to handle stack traces across interrupt entry points that just have a trapframe on their stack and not a trapframe + vector. - Change intr_execute_handlers() to take a trapframe rather than an intrframe pointer. - Change lapic_handle_intr() and atpic_handle_intr() to take a vector and trapframe rather than an intrframe. - GC struct intrframe now that nothing uses it anymore. - GC CLOCK_TO_TRAPFRAME() and INTR_TO_TRAPFRAME().
Reviewed by: bde Requested by: peter
|
#
152906 |
|
28-Nov-2005 |
jhb |
If we get a stray interrupt, return after logging it. In the extremely 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
|
#
151658 |
|
25-Oct-2005 |
jhb |
Reorganize the interrupt handling code a bit to make a few things cleaner 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)
|
#
144971 |
|
12-Apr-2005 |
jhb |
Use PCPU_LAZY_INC() for cnt.v_{intr,trap,syscalls} rather than atomic operations in some places and simple non-per CPU math in others.
|
#
139242 |
|
23-Dec-2004 |
jhb |
Add a simple 'intrcnt_add' function that other MD code can use to add a single named counter to the interrupt counts without having to fake up an entire interrupt source.
|
#
138498 |
|
06-Dec-2004 |
ups |
Allow fast interrupts to cause preemption.
Reviewed by: jhb, scottl Approved by: sam (mentor)
|
#
137165 |
|
03-Nov-2004 |
scottl |
Don't use atomic ops to increment interrupt stats. This was only done on amd64 and i386 anyways. The stats are only kept for informational purposes.
|
#
137117 |
|
01-Nov-2004 |
jhb |
- Change the ddb paging "support" to use a variable (db_lines_per_page) to control the number of lines per page rather than a constant. The variable can be examined and changed in ddb as '$lines'. Setting the variable to 0 will effectively turn off paging. - Change db_putchar() to force out pending whitespace before outputting newlines and carriage returns so that one can rub out content on the current line via '\r \r' type strings. - Change the simple pager to rub out the --More-- prompt explicitly when the routine exits. - Add some aliases to the simple pager to make it more compatible with more(1): 'e' and 'j' do a single line. 'd' does half a page, and 'f' does a full page.
MFC after: 1 month Inspired by: kris
|
#
133017 |
|
02-Aug-2004 |
scottl |
Optimize intr_execute_handlers() by combining the pic_disable_source() and pic_eoi_source() into one call. This halves the number of spinlock operations and indirect function calls in the normal case of handling a normal (ithread) interrupt. Optimize the atpic and ioapic drivers to use inlines where appropriate in supporting the intr_execute_handlers() change.
This knocks 900ns, or roughly 1350 cycles, off of the time spent servicing an interrupt in the common case on my 1.5GHz P4 uniprocessor system. SMP systems likely won't see as much of a gain due to the ioapic being more efficient than the atpic. I'll investigate porting this to amd64 soon.
Reviewed by: jhb
|
#
132408 |
|
19-Jul-2004 |
jhb |
As a temporary hack, turn off deferred preemptions that are the result of a fast interrupt handler doing an swi_sched(). This fixed the lockups I saw on my laptop when using xmms in KDE and on rwatson's MySQL benchmarks on SMP. This will eventually be removed and/or modified when I figure out what the root cause is and fix that.
|
#
131481 |
|
02-Jul-2004 |
jhb |
Implement preemption of kernel threads natively in the scheduler rather than as one-off hacks in various other parts of the kernel: - Add a function maybe_preempt() that is called from sched_add() to determine if a thread about to be added to a run queue should be preempted to directly. If it is not safe to preempt or if the new thread does not have a high enough priority, then the function returns false and sched_add() adds the thread to the run queue. If the thread should be preempted to but the current thread is in a nested critical section, then the flag TDF_OWEPREEMPT is set and the thread is added to the run queue. Otherwise, mi_switch() is called immediately and the thread is never added to the run queue since it is switch to directly. When exiting an outermost critical section, if TDF_OWEPREEMPT is set, then clear it and call mi_switch() to perform the deferred preemption. - Remove explicit preemption from ithread_schedule() as calling setrunqueue() now does all the correct work. This also removes the do_switch argument from ithread_schedule(). - Do not use the manual preemption code in mtx_unlock if the architecture supports native preemption. - Don't call mi_switch() in a loop during shutdown to give ithreads a chance to run if the architecture supports native preemption since the ithreads will just preempt DELAY(). - Don't call mi_switch() from the page zeroing idle thread for architectures that support native preemption as it is unnecessary. - Native preemption is enabled on the same archs that supported ithread preemption, namely alpha, i386, and amd64.
This change should largely be a NOP for the default case as committed except that we will do fewer context switches in a few cases and will avoid the run queues completely when preempting.
Approved by: scottl (with his re@ hat)
|
#
129816 |
|
28-May-2004 |
jhb |
Reenable ithread preemption for interrupts that occur while executing in the kernel. I accidentally broke this with the new interrupt code that came in prior to 5.2.
Submitted by: bde
|
#
128931 |
|
04-May-2004 |
jhb |
- Add a new pic method pic_config_intr() to set the trigger mode and polarity for a specified IRQ. The intr_config_intr() function wraps this pic method hiding the IRQ to interrupt source lookup. - Add a config_intr() method to the atpic(4) driver that reconfigures the interrupt using the ELCR if possible and returns an error otherwise. - Add a config_intr() method to the apic(4) driver that just logs any requests that would change the existing programming under bootverbose. Currently, the only changes the apic(4) driver receives are due to bugs in the acpi(4) driver and its handling of link devices, hence the reason for such requests currently being ignored. - Have the nexus(4) driver on i386 implement the bus_config_intr() function by calling intr_config_intr().
|
#
122841 |
|
17-Nov-2003 |
peter |
Widen the enable/disable helper function's argument in line with the ithread_create() changes etc. This should be mostly a NOP.
|
#
122700 |
|
14-Nov-2003 |
jhb |
If an interrupt source doesn't have an ithread, treat it as a stray interrupt. This can only happen if an unregistered interrupt source triggers an interrupt.
|
#
122572 |
|
12-Nov-2003 |
jhb |
- Move manipulation of td_intr_nesting_level out of assembly interrupt vector stubs and into the C functions they call. - Move disabling and EOIing of interrupt sources out of PIC driver entry points and into intr_execute_handlers(). Intr_execute_handlers() only disables a source for an interrupt if it is a stray interrupt or has threaded handlers. Sources with fast handlers no longer disable (mask) the source while executing the handlers. - Move the setting of clkintr_pending into intr_execute_handlers() and set the variable for any interrupt source with a vector of 0. (Should only be true for IRQ 0.) This fixes clkintr_pending in the NO_MIXED_MODE case. - Implement lapic_eoi() and use it to implement ioapic_eoi_source(). - Rename atpic_sched_ithd() to atpic_handle_intr() since it is used to handle all atpic interrupts and not just threaded ones.
Inspired by: peter's changes to amd64 in p4 (1) Requested by: bde (2)
|
#
121982 |
|
03-Nov-2003 |
jhb |
New device interrupt code. This defines an interrupt source abstraction that provides methods via a PIC driver to do things like mask a source, unmask a source, enable it when the first interrupt handler is added, etc. The interrupt code provides a table of interrupt sources indexed by IRQ numbers, or vectors. These vectors are what new-bus uses for its IRQ resources and for bus_setup_intr()/bus_teardown_intr(). The interrupt code then maps that vector a given interrupt source object. When an interrupt comes in, the low-level interrupt code looks up the interrupt source for the source that triggered the interrupt and hands it off to this code to execute the appropriate handlers.
By having an interrupt source abstraction, this allows us to have different types of interrupt source providers within the shared IRQ address space. For example, IRQ 0 may map to pin 0 of the master 8259A PIC, IRQs 1 through 60 may map to pins on various I/O APICs, and IRQs 120 through 128 may map to MSI interrupts for various PCI devices.
|