An error occurred fetching the project authors.
- 18 Jun, 2004 1 commit
-
-
Pavel Machek authored
This cleans up io_apic.c a bit -- I do not really like 4 copies of same code. Ingo said: yeah, agreed - i checked & test it, it's ok. I made a small modification (see the patch below) to uninline the __modify_IO_APIC_irq() function - shaving 0.5K off the kernel's size. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
- 25 May, 2004 1 commit
-
-
Ingo Molnar authored
This patch, from Venkatesh Pallipadi, changes x86 IO-APICs to use fixed interrupt delivery instead of lowest priority to support larger number of CPUs. Only bigsmp is affected by this cleanup. From: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
-
- 10 May, 2004 1 commit
-
-
Andrew Morton authored
From: Nick Piggin <piggin@cyberone.com.au> This is a (somewhat) trivial patch which converts cpu_sibling_map from an array of CPUs to an array of cpumasks. Needed for >2 siblings per package, but it actually can simplify code as it allows the cpu_sibling_map to be set up even when there is 1 sibling per package. Intel want this, I use it in the next patch to build scheduling domains for the P4 HT. From: Thomas Schlichter <thomas.schlichter@web.de> Build fix From: "Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> Fix to handle more than 2 siblings per package.
-
- 30 Apr, 2004 1 commit
-
-
Len Brown authored
Handle BIOS that reference disabled PCI Interrupt Link Devices http://bugme.osdl.org/show_bug.cgi?id=1581 Clean up VIA _CRS = 0 BIOS workaround Handle BIOS returning _CRS outside _PRS http://bugme.osdl.org/show_bug.cgi?id=2567 delete now unused _SRS retry code disable redundant console messages
-
- 22 Apr, 2004 1 commit
-
-
- 12 Apr, 2004 1 commit
-
-
Andrew Morton authored
From: "Nguyen, Tom L" <tom.l.nguyen@intel.com> Adds MSI support for ia64. - Modified existing code in drivers/pci/msi.c and drivers/pci/msi.h to include MSI support on IA64 platform. - Based on the comments received from Zwane Mwaikambo and David Mosberger, this patch consolidates the vector allocators as assign_irq_vector(AUTO_ASSIGN) has the same semantics as ia64_alloc_vector() by converting the existing uses of ia64_alloc_vector() to assign_irq_vector(AUTO_ASSIGN). - Based on the comments received from Zwane Mwaikambo, this patch consolidates the semantics of vector allocator assign_irq_vector() in drivers/pci/msi.c into the relevant architecture's vector allocator assign_irq_vector() in arch/i386/kernel/io_apic.c. - Regarding vector allocation, this patch modifies the existing function assign_irq_vector() to maximize the number of allocated vectors to 188 before going -ENOSPC. - Based on your comments, this patch creates <asm-i386/msi.h>, <asm-ia64/msi.h> and <asm-x86_64/msi.h>, includes <asm/msi.h> from within drivers/pci/msi.h and then places all the code which is currently under ifdef in msi.h into the relevant architecture's <asm/msi.h> file. - Based on your comments, this patch places pci_vector_resources() in existing drivers/pci/msi.c in the relevant architecture implementations such as into arch/.../pci/irq.c.
-
- 31 Mar, 2004 1 commit
-
-
- 10 Mar, 2004 1 commit
-
-
Linus Torvalds authored
This patch was trying to work around buggy SMM bios but causes problems by not deasserting NMI irq line (reported by Thomas Schlicht) for some integrated local apic. This patch was written originally as an optimization (with the side effect to fix those bugged bios) but was never applied to 2.4 tree. The rational was: fix your bios instead. Cset exclude: akpm@osdl.org|ChangeSet|20040219045328|16041
-
- 08 Mar, 2004 1 commit
-
-
Andrew Morton authored
From: Valdis.Kletnieks@vt.edu The send_IPI_self() in smp.c was fixed but the one in io_apic.c was not.
-
- 19 Feb, 2004 1 commit
-
-
Andrew Morton authored
From: "Martin J. Bligh" <mbligh@aracnet.com> Make irqbalance into a config option - some people (jgarzik, arjan, etc) wanted to be able to disable it and do things from userspace instead. This patch allows each camp to do their own thing, which seems fair ;-)
-
- 18 Feb, 2004 1 commit
-
-
Andrew Morton authored
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl> Fix up the 8259 ack handling for buggy SMM firmware. See http://www.ussg.iu.edu/hypermail/linux/kernel/0203.2/0956.html Apparently the embedded 8259A-compatible core is not fully functional. This patch lets the I/O APIC-driven NMI watchdog to function correctly. Credit to Ross Dickson for discovering this.
-
- 29 Dec, 2003 1 commit
-
-
Andrew Morton authored
From: long <tlnguyen@snoqualmie.dp.intel.com> Add support for Message Signalled Interrupt delivery on ia32. With a fix from Zwane Mwaikambo <zwane@arm.linux.org.uk>
-
- 07 Nov, 2003 1 commit
-
-
- 21 Oct, 2003 1 commit
-
-
James Cleverdon authored
The "irq_vector[]" array is indexed by the sum of all RTEs in all I/O APICs, and is not necessarily limited by the x86 CPU irq vector inputs. In fact, the irq vector index would overflow on big machines with lots of IO APIC's, causing the boot to fail. So grow the array for the big SMP boxes, keeping the default the same as before (and shrink the vector entry size down to a 8-bit value, since that's the size of the actual CPU vector entry).
-
- 26 Sep, 2003 1 commit
-
-
Randy Dunlap authored
From: maximilian attems <janitor@sternwelten.at> this patches catches obvious mistyping of new line: /n versus \n adds a printk loglevel to one of the erroneous lines
-
- 21 Sep, 2003 2 commits
-
-
Andrew Morton authored
From: James Cleverdon <jamesclv@us.ibm.com> 32-way IBM x445s will have I/O xAPICs with IDs greater than 0xF (0x8 to 0xE isn't enough). This breaks the code in setup_ioapic_ids_from_mpc. However, the entire unique ID check is unnecessary. Only I/O APICs using the serial APIC bus need the unique numbers. Those sending messages through the system bus simply don't use them.
-
Andrew Morton authored
From: James Cleverdon <jamesclv@us.ibm.com> Some very large systems overflow the array and corrupt memory. A BUG_ON will at least flag the problem until dynamic irq_vector allocation is added.
-
- 18 Aug, 2003 1 commit
-
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> Contributions from: Jan Dittmer <jdittmer@sfhq.hn.org> Arnd Bergmann <arnd@arndb.de> "Bryan O'Sullivan" <bos@serpentine.com> "David S. Miller" <davem@redhat.com> Badari Pulavarty <pbadari@us.ibm.com> "Martin J. Bligh" <mbligh@aracnet.com> Zwane Mwaikambo <zwane@linuxpower.ca> It has ben tested on x86, sparc64, x86_64, ia64 (I think), ppc and ppc64. cpumask_t enables systems with NR_CPUS > BITS_PER_LONG to utilize all their cpus by creating an abstract data type dedicated to representing cpu bitmasks, similar to fd sets from userspace, and sweeping the appropriate code to update callers to the access API. The fd set-like structure is according to Linus' own suggestion; the macro calling convention to ambiguate representations with minimal code impact is my own invention. Specifically, a new set of inline functions for manipulating arbitrary-width bitmaps is introduced with a relatively simple implementation, in tandem with a new data type representing bitmaps of width NR_CPUS, cpumask_t, whose accessor functions are defined in terms of the bitmap manipulation inlines. This bitmap ADT found an additional use in i386 arch code handling sparse physical APIC ID's, which was convenient to use in this case as the accounting structure was required to be wider to accommodate the physids consumed by larger numbers of cpus. For the sake of simplicity and low code impact, these cpu bitmasks are passed primarily by value; however, an additional set of accessors along with an auxiliary data type with const call-by-reference semantics is provided to address performance concerns raised in connection with very large systems, such as SGI's larger models, where copying and call-by-value overhead would be prohibitive. Few (if any) users of the call-by-reference API are immediately introduced. Also, in order to avoid calling convention overhead on architectures where structures are required to be passed by value, NR_CPUS <= BITS_PER_LONG is special-cased so that cpumask_t falls back to an unsigned long and the accessors perform the usual bit twiddling on unsigned longs as opposed to arrays thereof. Audits were done with the structure overhead in-place, restoring this special-casing only afterward so as to ensure a more complete API conversion while undergoing the majority of its end-user exposure in -mm. More -mm's were shipped after its restoration to be sure that was tested, too. The immediate users of this functionality are Sun sparc64 systems, SGI mips64 and ia64 systems, and IBM ia32, ppc64, and s390 systems. Of these, only the ppc64 machines needing the functionality have yet to be released; all others have had systems requiring it for full functionality for at least 6 months, and in some cases, since the initial Linux port to the affected architecture.
-
- 29 Jul, 2003 1 commit
-
-
Andy Grover authored
active-low, level trigger. Make other changes as required for this. (Andrew de Quincey)
-
- 14 Jul, 2003 1 commit
-
-
Alexander Atanasov authored
send_IPI_self is needed to resend irqs with IRQ_PENDING status when enabled. Checked with Ingo, and it's in 2.4-ac for some time. This should fix ide lost interrupts on UP with IO-APIC Ide trigers it this way: - disable_irq - do stuff that triggers IRQ. - irq is IRQ_PENDING - enable_irq - IRQ is lost, needs to be resend. I'll send the patch to fixup IDE disable_irq logic to Bart.
-
- 02 Jul, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> This renames the bad "timer" variable to "cur_timer" and moves externs to .h files.
-
- 27 Jun, 2003 1 commit
-
-
Randy Dunlap authored
This patch is to 2.5.73-bk4 and is purely cosmetic. Please apply. It removes the blank line after "testing the IO APIC....":
-
- 25 Jun, 2003 1 commit
-
-
Randy Dunlap authored
[ Registers of the world, unite! ] This makes the IO-APIC data structures use unions, so that we can cleanly access them both as flat "raw" values, and as the bitmap sub-entries.
-
- 24 Jun, 2003 1 commit
-
-
Randy Dunlap authored
Recently there has been a rash of Unexpected IO APIC reports on the linux-smp mailing list. Most of the most recent ones are due to some newer Intel chipsets (865, 875). The IO APIC Version register doesn't indicate the differences in these IO APICs. I have an patch that addresses these chipsets. It has been tested by a few people with good results and has been blessed by Maciej Rozycki. Other than conditionally decoding IO APIC registers 2 and 3, we could alternately ignore them since Linux doesn't use the values for anything other than printing them. This patch ignores IO APIC register 2 if it's the same value as IO APIC register 1. It also reads IO APIC register 3 if the IO APIC version is >= 0x20, but some chipsets don't support this register, so it is also ignored if its value if the same as IO APIC register 1 or 2. Another possible(?) alternative is to read the PID/VID of the device to determine which registers it supports. However, PCI devices have not been scanned at this point in init, so it would require scanning PCI config space directly and I don't yet see the point of doing that. Oh, and the UNEXPECTED_IO_APIC() function doesn't print anything in 2.5.current and I didn't change that.
-
- 14 Jun, 2003 1 commit
-
-
Andrew Morton authored
From: "Protasevich, Natalie" <Natalie.Protasevich@unisys.com> The patch set adds support for the Unisys ES7000 series architecture. It covers different ES7000 platform variations with their corresponding APIC architectures, such as Fosters-Gallatins based (XAPIC) ES7000s as well as older Cascades based (logical cluster) ES7000 machines. The patch was discussed among platform developers on LK and later resided in the Alan's tree for 4-5 weeks for testing. Alan indicated that there are "Zero complaints of any kind, zero problems from the changed code". He recommended submit the patch. The code was tested by IBM as well as others and did not have any impact on existing subarchs and on standard systems. Here is the "generic" patch #1. It deals with the IRQ overrides (most of changes in mpparse.c and PCI range adjustment in io_apic.c), insufficient width of IO-APIC ID, and a corner case for defining quantities of things like APICs, IRQ sources, etc. (the attempt to make easier defining these items in subarchs resulted in separation of MP definition portion in include/asm-i386/mpparse.h from its enumeration portion). It has also Venkatesh Palladi's fix that he suggested earlier for the correct APIC version; I had to have it for this platform since the correct APIC version will be needed later for dynamic platform discovery when es7000 will be incorporated into genapic.
-
- 10 Jun, 2003 1 commit
-
-
Andrew Morton authored
From: "Martin J. Bligh" <mbligh@aracnet.com> Patch from Martin Bligh, based on observations by Andrew Theurer and Bill Irwin. TARGET_CPUS is used as a cpu mask by some things, and an apic mask for others. For SMP, that doesn't matter (they're the same), but for Summit it does. This patch changes TARGET_CPUS to consistently be a cpu mask everywhere. Should be a no-op for normal platforms. Invalid arguments to cpu_mask_to_apicid for clustered apic mode architectures will now return the broadcast apicid, in order to ensure someone still gets the interrupt (was the default init value, and is safest).
-
- 02 Jun, 2003 1 commit
-
-
Andrew Morton authored
From: Andi Kleen <ak@suse.de> John Stultz noticed that kirqd didn't start because of another logic error, which broke irq balancing. This was still a fallout from the generic subarchitecture changes. Actually it still refuses to balance anything on my test box, but perhaps I'm just not able to generate enough interrupts. Anyways, with this patch the thread is running again at least.
-
- 29 May, 2003 1 commit
-
-
Andrew Morton authored
From: Andi Kleen <ak@suse.de> The logic is: the global variable is set to the magic value IRQBALANCE_CHECK_ARCH. It can be overwritten by a __setup function. If the magic value is still set when the irq balancer is started it asks the subarchitecture using the NO_BALANCE_IRQ macro. This is defined to a genapic field in the generic architecture, otherwise constant. Then the global variable is set and when it is true no balancing happens. Previously I had this wrong in that it always disabled it. This part should be correct, but it still doesn't seem to work. (I left the printk in there until the problem is debugged, could be removed of course)
-
- 15 May, 2003 1 commit
-
-
Andrew Morton authored
From: john stultz <johnstul@us.ibm.com> I've been having problems with ACPI on a box here in our lab. Some of our more recent hardware requires that SMIs are routed through the IOAPIC, thus when we clear_IO_APIC() at boot time, we clear the BIOS initialized SMI pin. This basically clobbers the SMI so we can then never make the transition into ACPI mode. This patch simply reads the apic entry in clear_IO_APIC to make sure the delivery_mode isn't dest_SMI. If it is, we leave the apic entry alone and return. With this patch, the box boots and SMIs function properly.
-
- 12 May, 2003 1 commit
-
-
Andrew Morton authored
From: Keith Mannthey <kmannth@us.ibm.com> The following is a patch to fix inconsistent use of the function set_ioapic_affinity. In the current kernel it is unclear as to weather the value being passed to the function is a cpu mask or valid apic id. In irq_affinity_write_proc the kernel passes on a cpu mask but the kirqd thread passes on logical apic ids. In flat apic mode this is not an issue because a cpu mask represents the apic value. However in clustered apic mode the cpu mask is very different from the logical apic id. This is an attempt to do the right thing for clustered apics. I clarify that the value being passed to set_ioapic_affinity is a cpu mask not a apicid. Set_ioapic_affinity will do the conversion to logical apic ids. Since many cpu masks don't map to valid apicids in clustered apic mode TARGET_CPUS is used as a default value when such a situation occurs. I think this is a good step in making irq_affinity clustered apic safe.
-
- 07 May, 2003 1 commit
-
-
Andrew Morton authored
From: Andi Kleen <ak@muc.de> This patch adds an generic x86 subarchitecture. It is intended to provide an dynamic interface for APIC drivers. There are already three subarchitectures (bigsmp, summit, default) that only differ in how they drive the local APIC. A fourth - Unisys ES7000 - is scheduled to be merged soon. The subarchitecture concept separated this nicely, but it has the big drawback that they are compile time options. A Linux vendor cannot ship own binary kernel rpms for all of these machines. Runtime probing is needed instead. This patch adds a new "generic" subarchitecture that just acts as a dynamic switching layer for APIC drivers. It only tries to virtualize the APICs, no attempt is made to cover further incompatiblities. This means machines like the Visual Workstation, pc9800 or Voyager are not covered; but these are unlikely to be supported by binary distributions anyways. The generic arch reuses the existing interface in mach_ipi / mach_mpparse.h / mach_apic.h and just pulls it using some macros into an "struct genapic" object. The main APIC code does not recognize it, it is all hidden in the mach-generic include files. Auto detection of APIC types is supported in the usual way used by existing ports like Summit - checking ACPI or mptables for specific signatures - or it can be specified by the user using a new "apic=" boot option. I also moved the DMI scan to before the generic subarchitecture probe, so DMI could be used in future too to probe specific machines. Some minor hacks were needed to avoid circular declaration of a few symbols, but overall it's fairly clean. The patch has been tested on a Summit machine, an generic 4 virtual CPUs Xeon and on an ES7000.
-
- 25 Apr, 2003 1 commit
-
-
Valdis Kletnieks authored
-
- 20 Apr, 2003 1 commit
-
-
Linus Torvalds authored
allocate FIRST_SYSTEM_VECTOR as an external interrupt. It's unlikely, but could happen if we have a _ton_ of interrupt sources. Found by Chuck Ebbert.
-
- 14 Apr, 2003 1 commit
-
-
Linus Torvalds authored
-
- 08 Apr, 2003 1 commit
-
-
Alan Cox authored
Allows for the non standard cascade
-
- 07 Apr, 2003 2 commits
-
-
Linus Torvalds authored
implies that it should vary between 0-7, not any further (the higher bits are done by updating current_vector by 8). This also means that we don't have any overflow condition.
-
Zwane Mwaikambo authored
This patch disables irqbalance and doesn't spawn a kernel thread for systems which run SMP kernels and only have one online cpu.
-
- 20 Mar, 2003 1 commit
-
-
Andrew Morton authored
From: William Lee Irwin III <wli@holomorphy.com> The NMI watchdog has two different "modes": NMI_IO_APIC, which delivers NMI's through the IO-APIC, and NMI_LOCAL_APIC, which uses the local APIC vector table (LVT) to deliver the periodic NMI's. Only NMI_IO_APIC requires being able to set up the PIT so it can deliver NMI's through the IO-APIC, and so NMI_LOCAL_APIC has no dependency on the timer being set up through the IO-APIC and is unjustifiably disabled by check_timer() when the PIT cannot deliver interrupts through the IO-APIC. This is important because one of the most important uses of NMI_LOCAL_APIC is to get the NMI watchdog going when NMI_IO_APIC doesn't work. So what this patch does to repair the situation is instead of checking to see if the NMI watchdog is enabled at all, it instead checks whether the NMI watchdog is being used in NMI_IO_APIC mode when a failure to set up the NMI timer interrupt through the IO-APIC occurs.
-
- 18 Mar, 2003 2 commits
-
-
Andrew Morton authored
Patch from "Martin J. Bligh" <mbligh@aracnet.com> This removes the DO_ACTION stuff. The downside is that we add some boring and repetive code. The upside is that it's simple, and mere mortals can read it without screwing their brains into a small piece of silly putty and bouncing it off the wall. I think that's more important than pure source code size.
-
Andrew Morton authored
Patch from Zwane Mwaikambo <zwane@linuxpower.ca> This patch fixes what seems to have been a longstanding bug. Ever since we moved cpu bringup later into the boot process, we end up programming the ioapics before we have any of our possible cpus in the cpu_online_map. Therefore leading to the following current situation; For walmart-smp, bigsmp and summit we set the logical destination for cpu to TARGET_CPUS which can depend on the cpu_online_map, so what you would normally see with noirqbalance would be all interrupts handled on cpu0 since at that stage no other cpu apart from the BSP is online. You can check for this by looking at the ioredtbls at boottime for a two way system; .... IRQ redirection table: NR Log Phy Mask Trig IRR Pol Stat Dest Deli Vect: 00 000 00 1 0 0 0 0 0 0 00 01 001 01 0 0 0 0 0 1 1 39 02 001 01 0 0 0 0 0 1 1 31 03 001 01 0 0 0 0 0 1 1 41 04 001 01 0 0 0 0 0 1 1 49 05 001 01 0 0 0 0 0 1 1 51 06 001 01 0 0 0 0 0 1 1 59 Notice that 'Log' is set to 1 instead of 3. This patch will simply reprogram all the ioredtbls to handle the other online cpus. Patch tested on my 2way P2-400 and a 16way NUMAQ both with noirqbalance. It will not affect the irqbalance case because we are simply setting TARGET_CPUS which is done anyway. before: CPU0 CPU1 0: 1495632 0 IO-APIC-edge timer 1: 4270 0 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 8: 1 0 IO-APIC-edge rtc 12: 83592 0 IO-APIC-edge i8042 14: 93791 0 IO-APIC-edge ide0 15: 103167 0 IO-APIC-edge ide1 17: 1396088 0 IO-APIC-level EMU10K1, eth0 18: 56125 0 IO-APIC-level aic7xxx, aic7xxx 19: 2258 0 IO-APIC-level uhci-hcd, eth1, serial NMI: 0 0 LOC: 1495566 1497133 after: CPU0 CPU1 0: 1046157 1015670 IO-APIC-edge timer 1: 4923 4173 IO-APIC-edge i8042 2: 0 0 XT-PIC cascade 8: 1 0 IO-APIC-edge rtc 12: 48596 48968 IO-APIC-edge i8042 14: 4238 3416 IO-APIC-edge ide0 15: 25362 31525 IO-APIC-edge ide1 17: 3757 4014 IO-APIC-level EMU10K1, eth0 18: 335 366 IO-APIC-level aic7xxx, aic7xxx 19: 1052 908 IO-APIC-level uhci-hcd, eth1 NMI: 0 0 LOC: 2061856 2061893
-