- 26 Jun, 2006 40 commits
-
-
bibo,mao authored
In x86_64 architecture, if device driver with msi function gets 0xee vector by assign_irq_vector() function, system will crash if this interrupt happens. It is because 0xee interrupt entry is empty. This patch modifies this. This patch is based on 2.6.17-rc6. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
- Rename the GART_IOMMU option to IOMMU to make clear it's not just for AMD - Rewrite the help text to better emphatise this fact - Make it an embedded option because too many people get it wrong. To my astonishment I discovered the aacraid driver tests this symbol directly. This looks quite broken to me - it's an internal implementation detail of the PCI DMA API. Can the maintainer please clarify what this test was intended to do? Cc: linux-scsi@vger.kernel.org Cc: alan@redhat.com Cc: markh@osdl.org Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Previously it would only work in the first 32bit system call, not during early process setup. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
Fix a potential deadlock scenario introduced by io_apic.c's new vector_lock on i386 and x86_64. Found by the locking correctness validator. The patch was boot-tested on x86. For details of the deadlock scenario, see the validator output: ====================================================== [ BUG: hard-safe -> hard-unsafe lock order detected! ] ------------------------------------------------------ idle/1 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire: (msi_lock){....}, at: [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35 and this task is already holding: (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107 which would create a new lock dependency: (&irq_desc[i].lock){++..} -> (msi_lock){....} but this new dependency connects a hard-irq-safe lock: (&irq_desc[i].lock){++..} ... which became hard-irq-safe at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad to a hard-irq-unsafe lock: (vector_lock){--..} ... which became hard-irq-unsafe at: ... [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb which could potentially lead to deadlocks! other info that might help us debug this: 3 locks held by idle/1: #0: (port_mutex){--..}, at: [<c067070d>] uart_add_one_port+0x61/0x289 #1: (&state->mutex){--..}, at: [<c067071f>] uart_add_one_port+0x73/0x289 #2: (&irq_desc[i].lock){++..}, at: [<c015b924>] probe_irq_on+0x36/0x107 the hard-irq-safe lock's dependencies: -> (&irq_desc[i].lock){++..} ops: 9861 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c015b415>] setup_irq+0x9b/0x14d [<c1aaa4c4>] time_init_hook+0xf/0x11 [<c1a9f320>] time_init+0x44/0x46 [<c1a9955f>] start_kernel+0x191/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c015aff5>] __do_IRQ+0x3d/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c1ea31e0>] irq_desc_lock_type+0x0/0x20 -> (i8259A_lock){++..} ops: 5149 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0108090>] init_8259A+0x11/0x8f [<c1aa0d22>] init_ISA_irqs+0x12/0x4d [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa [<c1aa0cb9>] init_IRQ+0xe/0x65 [<c1a99546>] start_kernel+0x178/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c142f174>] i8259A_lock+0x14/0x40 ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107eb2>] enable_8259A_irq+0x10/0x47 [<c0107f12>] startup_8259A_irq+0x8/0xc [<c015b45e>] setup_irq+0xe4/0x14d [<c1aaa4c4>] time_init_hook+0xf/0x11 [<c1a9f320>] time_init+0x44/0x46 [<c1a9955f>] start_kernel+0x191/0x38f [<c0100210>] 0xc0100210 -> (ioapic_lock){+...} ops: 122 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c1aa71db>] io_apic_get_version+0x16/0x55 [<c1aa5c73>] mp_register_ioapic+0xc6/0x127 [<c1aa382e>] acpi_parse_ioapic+0x2d/0x39 [<c1abe031>] acpi_table_parse_madt_family+0xb4/0x100 [<c1abe093>] acpi_table_parse_madt+0x16/0x18 [<c1aa3c8a>] acpi_boot_init+0x132/0x251 [<c1aa08ea>] setup_arch+0xd36/0xe37 [<c1a99434>] start_kernel+0x66/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c011bce1>] mask_IO_APIC_irq+0x11/0x31 [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41 [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c1432514>] ioapic_lock+0x14/0x3c -> (i8259A_lock){++..} ops: 5149 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0108090>] init_8259A+0x11/0x8f [<c1aa0d22>] init_ISA_irqs+0x12/0x4d [<c1aaa4f0>] pre_intr_init_hook+0x8/0xa [<c1aa0cb9>] init_IRQ+0xe/0x65 [<c1a99546>] start_kernel+0x178/0x38f [<c0100210>] 0xc0100210 in-hardirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad in-softirq-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107fb0>] mask_and_ack_8259A+0x1b/0xcc [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad } ... key at: [<c142f174>] i8259A_lock+0x14/0x40 ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c0107e6b>] disable_8259A_irq+0x10/0x47 [<c011bdbd>] startup_edge_ioapic_vector+0x31/0x58 [<c015b45e>] setup_irq+0xe4/0x14d [<c015b5a1>] request_irq+0xda/0xf9 [<c1ac983a>] rtc_init+0x6a/0x1a7 [<c0100457>] init+0x14a/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb ... acquired at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c011bce1>] mask_IO_APIC_irq+0x11/0x31 [<c011c5cc>] ack_edge_ioapic_vector+0x31/0x41 [<c015b007>] __do_IRQ+0x4f/0x113 [<c01062d3>] do_IRQ+0x8c/0xad the hard-irq-unsafe lock's dependencies: -> (vector_lock){--..} ops: 31 { initial-use at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb softirq-on-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb hardirq-on-W at: [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10485e9>] _spin_lock+0x21/0x2f [<c011b5e8>] assign_irq_vector+0x34/0xc8 [<c1aa82fa>] setup_IO_APIC+0x45a/0xcff [<c1aa56e3>] smp_prepare_cpus+0x5ea/0x8aa [<c010033f>] init+0x32/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb } ... key at: [<c1432574>] vector_lock+0x14/0x3c stack backtrace: [<c0104f36>] show_trace+0xd/0xf [<c010543e>] dump_stack+0x17/0x19 [<c0144e34>] check_usage+0x1f6/0x203 [<c0146395>] __lockdep_acquire+0x8c2/0xaa5 [<c01468c4>] lockdep_acquire+0x68/0x84 [<c10487f4>] _spin_lock_irqsave+0x2a/0x3a [<c04ff8d2>] startup_msi_irq_wo_maskbit+0x10/0x35 [<c015b932>] probe_irq_on+0x44/0x107 [<c0673d58>] serial8250_config_port+0x84b/0x986 [<c06707b1>] uart_add_one_port+0x105/0x289 [<c1ace54b>] serial8250_init+0xc3/0x10a [<c0100457>] init+0x14a/0x2cb [<c0102005>] kernel_thread_helper+0x5/0xb Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Jan Beulich <jbeulich@novell.com> Cc: Andi Kleen <ak@suse.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jon Mason authored
include/asm-x86_64/gart-mapping.h is only ever used in arch/x86_64/kernel/setup.c and none of its contents are referenced. Looks to be leftover cruft not removed in the dma_ops patch. Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Use inline code bitmaps <= BITS_PER_LONG in bitmap_weight. This gives _much_ better code. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
It was originally added for 2.4 oprofile, but 2.6 oprofile doesn't need that anymore. Shouldn't be any use in tree anymore and it doesn't make much sense to export the ia32 syscalls when the main syscalls are not exported. I think Adrian Bunk asked for removing it several times. Also included hunk from Adrian to remove the .globl ia32_sys_call_table Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Early development of x86-64 Linux was in CVS, but that hasn't been the case for a long time now. Remove the obsolete $Id$s. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Don Zickus authored
Misc header cleanup for nmi watchdog. Signed-off-by: Don Zickus <dzickus@redhat.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
fix unlikely profiling in vsyscalls ... Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jan Beulich authored
Since END()/ENDPROC() are now available, add respective annotations to x86_64's entry.S. This should help debugging activities. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Sometimes e.g. with crashme the compat layer warnings can be noisy. Add a way to turn them off by gating all output through compat_printk that checks a global sysctl. The default is not changed. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Fix initcall at 0xffffffff806c5b89: pci_iommu_init+0x0/0x53c(): returned with error code -1 Return -ENODEV instead when the IOMMU is not used. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jan Beulich authored
Simplify (remove duplication of) code in ioapic_register_intr(). Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jan Beulich authored
Since assign_irq_vector() can be called at runtime, its access of static variables should be protected by a lock. Signed-off-by: Jan Beulich <jbeulich@novell.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
- Factor out the duplicated access/cache code into a single file * Shared between i386/x86-64. - Share flush code between AGP and IOMMU * Fix a bug: AGP didn't wait for end of flush before - Drop 8 northbridges limit and allocate dynamically - Add lock to serialize AGP and IOMMU GART flushes - Add PCI ID for next AMD northbridge - Random related cleanups The old K8 NUMA discovery code is unchanged. New systems should all use SRAT for this. Cc: "Navin Boppuri" <navin.boppuri@newisys.com> Cc: Dave Jones <davej@redhat.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jon Mason authored
A trivial change to have gart_unmap_sg call gart_unmap_single directly, instead of bouncing through the dma_unmap_single wrapper in dma-mapping.h. This change required moving the gart_unmap_single above gart_unmap_sg, and under gart_map_single (which seems a more logical place that its current location IMHO). Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Previously we would just silently provide 64 bit services for this to 32bit processes. I also added all the other cases explicitely to the ptrace compat wrapper to make sure this doesn't happen again. And removed one bogus check in the wrapper. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Mike Waychison authored
Allow search for a contiguous block of iommu space to cross the next_bit marker if we have already committed ourselves to flushing the gart. There shouldn't be any reason why we'd restrict the search. Signed-off-by: Mike Waychison <mikew@google.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Ingo Molnar authored
enable large bzImages on x86_64. (fix is from x86's build.c) Using this patch i have successfully built and booted an allyesconfig 13MB+ bzImage on x86_64 too: $ size64 vmlinux text data bss dec hex filename 23444831 8202642 3439360 35086833 21761f1 vmlinux -rw-rw-r-- 1 mingo mingo 13121740 Apr 19 09:32 arch/x86_64/boot/bzImage Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
It's only needed for three system calls, no need to maintain a full list forever. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Jon Mason authored
Replace hard coded DMA masks with #defines from include/linux/dma-mapping.h Signed-off-by: Jon Mason <jdmason@us.ibm.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Gerd Hoffmann authored
Changes are largely identical to the i386 version: * alternative #define are moved to the new alternative.h file. * one new elf section with pointers to the lock prefixes which can be nop'ed out for non-smp. * two new elf sections simliar to the "classic" alternatives to replace SMP code with simpler UP code. * fixup headers to use alternative.h instead of defining their own LOCK / LOCK_PREFIX macros. The patch reuses the i386 version of the alternatives code to avoid code duplication. The code in alternatives.c was shuffled around a bit to reduce the number of #ifdefs needed. It also got some tweaks needed for x86_64 (vsyscall page handling) and new features (noreplacement option which was x86_64 only up to now). Debug printk's are changed from compile-time to runtime. Loosely based on a early version from Bastian Blank <waldi@debian.org> Signed-off-by: Gerd Hoffmann <kraxel@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Intel systems report the cache level data from CPUID 4 in sysfs. Add a CPUID 4 emulation for AMD CPUs to report the same information for them. This allows programs to read this information in a uniform way. The AMD way to report this is less flexible so some assumptions are hardcoded (e.g. no L3) Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Previously the apicid<->coreid split was computed based on the max number of cores. Now use a new CPUID AMD defined for that. On most systems right now it should be 0 and the old method will be used. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Inspired from i386 changes Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
ravikiran thirumalai authored
vSMPowered systems use apic_cluster too. Forcing apic_physflat works on these systems too, but only if we change phys_pkg_id to use hard_smp_prcoessor_id() instead of cpuid_ebx. I am guessing other multichassi cluster systems would need this too. Signed-off-by: ravikiran thirumalai <kiran@scalex86.org> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Andi Kleen authored
Enable some hwmon drivers as modules and tulip and stack unwinding Kernel image should be somewhat bigger now because of the unwind information being included, but you'll get exact backtraces for that. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Malcolm Parsons authored
binfmt_flat.c calls set_personality with PER_LINUX as the personality. On the arm architecture this results in the program running in 26bit usermode. PER_LINUX_32BIT should be used instead. This doesn't affect other architectures that use binfmt_flat. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Change enable_irq() macro to be a statement, not expression. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Fix PLL setting for the Coldfire 5249 CPU. This brings it into line with the new style frequency configuration of m68knommu parts. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Fix flush code for the ColdFire 5206/5206e/5272 cases. Add support for the new ColdFire 532x CPU family Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Philippe De Muyter authored
Here is a patch to the system call handling for 5307/5272/etc to: - fix the strace support (one tested the wrong bit) - make all system calls a little bit faster by inlining set_esp0 and supporting ENOSYS out of the critical path. - remove extraneous spaces Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
This patch solve a bug triggered by execvp (this function use calloc to store the argument list and gcc 3.4.x align the stack to word, not to dword). This situation aren't related to signal handling and all 2.6.x have the bug. On ColdFire targets we must force the stack to be aligned. Original patch from Andrea Tarani <andrea.tarani@gilbarco.com>, Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Remove list of fixed clock frequency options used for configuring master clock, and make field an int. Much more flexible this way, no need to add more options for every new used freqency. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Remove list of fixed clock frequency options used for configuring master clock, and make field an int. Much more flexible this way, no need to add more options for every new used freqency. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Add support for the AVNET 5282 board. Patch submitted by Daniel Alomar <dalomar@serrasold.com>. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Greg Ungerer authored
Add configure support for the new Freescale 532x family of CPUs. Patch submitted by Matt Waddel <Matt.Waddel@freescale.com>. Signed-off-by: Greg Ungerer <gerg@uclinux.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-
Linus Torvalds authored
This reverts commits 3e3318de [PATCH] swsusp: x86_64 mark special saveable/unsaveable pages b6370d96 [PATCH] swsusp: i386 mark special saveable/unsaveable pages ce4ab001 [PATCH] swsusp: add architecture special saveable pages support because not only do they apparently cause page faults on x86, the infrastructure doesn't compile on powerpc. Signed-off-by: Linus Torvalds <torvalds@osdl.org>
-