aboutsummaryrefslogtreecommitdiff
path: root/arch/i386
AgeCommit message (Collapse)Author
2006-04-18[PATCH] i386: Move CONFIG_DOUBLEFAULT into arch/i386 where it belongs.Andi Kleen
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-18[PATCH] i386/x86-64: Fix ACPI disabled LAPIC handling mismergeAndi Kleen
The patch I submitted earlier to fix disabled LAPIC handling in ACPI was mismerged for some reason I still don't quite understand. Parts of it was applied to the wrong function. This patch fixes it up. Cc: len.brown@intel.com Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-14Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6Linus Torvalds
* master.kernel.org:/pub/scm/linux/kernel/git/gregkh/pci-2.6: (169 commits) commit 78a596b4490e17b9990d87b9d468ef5bb70daa10 Author: Adrian Bunk <bunk@stusta.de> Date: Fri Mar 31 01:38:12 2006 -0800 [PATCH] remove kernel/power/pm.c:pm_unregister() Since the last user is removed in -mm, we can now remove this long deprecated function. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: Pavel Machek <pavel@ucw.cz> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> commit 21440d313358043b0ce5e43b00ff3c9b35a8616c Author: David Brownell <david-b@pacbell.net> Date: Sat Apr 1 10:21:52 2006 -0800 [PATCH] dma doc updates ...
2006-04-14[PATCH] arch/i386/pci/irq.c - new VIA chipsets (fwd)Grzegorz Janoszka
I use 2.6.15.6 Linux kernel and found some problems. I have about 100 Linux boxes (all with the same (binary the same) kernel). Last time I have upgraded all those boxes from 2.4.32 to 2.6.15.6 (first 2.6.15.1, next .2, .4 and .6) and I have found some problems on VIA based PC's. Probably the reason of this is that some VIA chipsets are unrecognized by IRQ router. In line 586 there is: /* FIXME: add new ones for 8233/5 */ There were only a few of chipsets ID's there, some of my VIA chipsets were not present and kernel used default IRQ router. I have added three entries, so that the code looks like: case PCI_DEVICE_ID_VIA_82C596: case PCI_DEVICE_ID_VIA_82C686: case PCI_DEVICE_ID_VIA_8231: case PCI_DEVICE_ID_VIA_8233A: case PCI_DEVICE_ID_VIA_8235: case PCI_DEVICE_ID_VIA_8237: case PCI_DEVICE_ID_VIA_8237_SATA: /* FIXME: add new ones for 8233/5 */ r->name = "VIA"; r->get = pirq_via_get; r->set = pirq_via_set; return 1; } The kernel goes fine but I haven't testes it for weeks, I'm just a moment after reboot :) One thing is different (better?): Using previus kernel I had: PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 0 now I have: PCI: Via IRQ fixup for 0000:00:0f.1, from 255 to 11 Maybe it is good idea to add there some more VIA chipsets? The ones I have added seem to be OK. From: Grzegorz Janoszka <Grzegorz@Janoszka.pl> Acked-by: Martin Mares <mj@ucw.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-14[PATCH] DMI: move dmi_scan.c from arch/i386 to drivers/firmware/Bjorn Helgaas
dmi_scan.c is arch-independent and is used by i386, x86_64, and ia64. Currently all three arches compile it from arch/i386, which means that ia64 and x86_64 depend on things in arch/i386 that they wouldn't otherwise care about. This is simply "mv arch/i386/kernel/dmi_scan.c drivers/firmware/" (removing trailing whitespace) and the associated Makefile changes. All three architectures already set CONFIG_DMI in their top-level Kconfig files. Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andrey Panin <pazke@orbita1.ru> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-04-11[PATCH] splice: add support for sys_tee()Jens Axboe
Basically an in-kernel implementation of tee, which uses splice and the pipe buffers as an intelligent way to pass data around by reference. Where the user space tee consumes the input and produces a stdout and file output, this syscall merely duplicates the data inside a pipe to another pipe. No data is copied, the output just grabs a reference to the input pipe data. Signed-off-by: Jens Axboe <axboe@suse.de>
2006-04-11[PATCH] i386/x86-64: Remove checks for value == NULL in PCI config space accessAndi Kleen
Nobody should pass NULL here. Could in theory make it a BUG, but the NULL pointer oops will do as well. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] i386: Remove bogus special case code from AMD core parsingAndi Kleen
It's not actually needed and would break non power of two number of cores. Follows similar earlier x86-64 patch. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] x86-64/i386: Don't process APICs/IO-APICs in ACPI when APIC is disabled.Andi Kleen
When nolapic was passed or the local APIC was disabled for another reason ACPI would still parse the IO-APICs until these were explicitely disabled with noapic. Usually this resulted in a non booting configuration unless "nolapic noapic" was used. I also disabled the local APIC parsing in this case, although that's only cosmetic (suppresses a few printks) This hopefully makes nolapic work in all cases. Cc: Len Brown <len.brown@intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] vesafb: Fix incorrect logo colors in x86_64Antonino A. Daplas
Bugzilla Bug 6299: A pixel size of 8 bits produces wrong logo colors in x86_64. The driver has 2 methods for setting the color map, using the protected mode interface provided by the video BIOS and directly writing to the VGA registers. The former is not supported in x86_64 and the latter is enabled only in i386. Fix by enabling the latter method in x86_64 only if supported by the BIOS. If both methods are unsupported, change the visual of vesafb to STATIC_PSEUDOCOLOR. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] No arch-specific strpbrk implementationsKyle McMartin
While cleaning up parisc_ksyms.c earlier, I noticed that strpbrk wasn't being exported from lib/string.c. Investigating further, I noticed a changeset that removed its export and added it to _ksyms.c on a few more architectures. The justification was that "other arches do it." I think this is wrong, since no architecture currently defines __HAVE_ARCH_STRPBRK, there's no reason for any of them to be exporting it themselves. Therefore, consolidate the export to lib/string.c. Signed-off-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] Configurable NODES_SHIFTYasunori Goto
Current implementations define NODES_SHIFT in include/asm-xxx/numnodes.h for each arch. Its definition is sometimes configurable. Indeed, ia64 defines 5 NODES_SHIFT values in the current git tree. But it looks a bit messy. SGI-SN2(ia64) system requires 1024 nodes, and the number of nodes already has been changeable by config. Suitable node's number may be changed in the future even if it is other architecture. So, I wrote configurable node's number. This patch set defines just default value for each arch which needs multi nodes except ia64. But, it is easy to change to configurable if necessary. On ia64 the number of nodes can be already configured in generic ia64 and SN2 config. But, NODES_SHIFT is defined for DIG64 and HP'S machine too. So, I changed it so that all platforms can be configured via CONFIG_NODES_SHIFT. It would be simpler. See also: http://marc.theaimsgroup.com/?l=linux-kernel&m=114358010523896&w=2 Signed-off-by: Yasunori Goto <y-goto@jp.fujitsu.com> Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Richard Henderson <rth@twiddle.net> Cc: Kyle McMartin <kyle@mcmartin.ca> Cc: Russell King <rmk@arm.linux.org.uk> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Jack Steiner <steiner@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] Enable TSC for AMD Geode GX/LXJordan Crouse
Geode GX/LX should enable X86_TSC. Pointed out by Adrian Bunk. Signed-off-by: Jordan Crouse <jordan.crouse@amd.com> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] i386: move SMP option above subarch selectionAdrian Bunk
Since several subarchs depend on SMP, the SMP option should be above the subarch selection. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] mpparse: prevent table index out-of-boundsRandy Dunlap
John Z. Bohach <jzb@aexorsyst.com> found this bug: If the board has more than 32 PCI busses on it, the mptable bus array will overwrite its bounds for the PCI busses, and stomp on anything that's after it. Prevent possible table overflow and unknown data corruption. Code is in an __init section so it will be discarded after init. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] menu: relocate DOUBLEFAULT optionRandy Dunlap
Move the DOUBLEFAULT option from the top-level menu to the EMBEDDED menu. Only applicable to X86_32. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] i386: print EIP/ESP lastRandy Dunlap
Print summary registers (EIP and SS:ESP only) as last death info. This makes this important data visible in case it had scrolled off the top of the display. Similar to what x86_64 does. Suggested by Andi Kleen. Signed-off-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] swsusp: don't require bigsmpAshok Raj
Switching to automatic bigsmp causes a misleading error message, that more then 8 cpus are detected, and user needs to select either X86_GENERICARCH or X86_BIGSMP to handle. Reason is we switched to bigsmp to avoid IP race when new cpu is comming up. [bigsmp is nothing but using physical flat mode that can work for 1 .. 255 cpus] [default is X86_PC, that uses logical flat mode up to 8 CPUs max] Current x86_64 code uses bigsmp as default when hotplug is enabled. It would be preferable to make bigsmp as default, and work the dependencies of other related code like SMP_SUSPEND, and some related to memory hotplug code for i386. Current logical flat mode doesnt use shortcuts that cause the race by using the send_IPI_mask() instead of shortcuts when HOTPLUG_CPU is enabled. In the meantime this patch is the path of lease resistance. We will switch to bigsmp default sometime soon, when we get to work it again. Signed-off-by: Ashok Raj <ashok.raj@intel.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: "Rafael J. Wysocki" <rjw@sisk.pl> Cc: Nigel Cunningham <nigel@suspend2.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-11[PATCH] arch/i386/mach-voyager/voyager_cat.c: named initializersAdrian Bunk
This patch switches arch/i386/mach-voyager/voyager_cat.c to using named initializers for struct resource. Besides a fixing compile error in Greg's tree, it makes the code more readable. Signed-off-by: Adrian Bunk <bunk@stusta.de> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09Move request_standard_resources() back to before PCI probingLinus Torvalds
This effectively undoes the PCI resource allocation changes done in commit b408cbc704352eccee301e1103b23203ba1c3a0e, but leaves the cleanups of that commit in place. We're going back to marking the resources reported by e820 busy _before_ doing PCI probing, so that any PCI resource that clashes with the BIOS- reported memory map will be reloacted to a non-clashing area. The reason? Larry Finger reports that his laptop has the cardbus controller set up by the BIOS so that it conflicts with the e820 memory map, and needs to be relocated. See http://bugzilla.kernel.org/show_bug.cgi?id=6337 for more details. We'll have to work out how to handle the fbcon problem that caused that commit in the first place in some other way. Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru> Cc: Greg Kroah-Hartman <gregkh@suse.de> Cc: Antonino A. Daplas <adaplas@pol.net> Cc: <bjk@luxsci.net> Tested-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386: Remove printk about reboot fixups at rebootAndi Kleen
Printk doesn't have any value Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86-64: Return defined error value for bad PCI config space ↵Andi Kleen
accesses Mostly to get better handling when a extended config space access has to fallback to Type1. Cc: gregkh@suse.de Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86_64: Check if MCFG works for the first 16 bussesAndi Kleen
Previously only the first bus would be checked against Type 1. Why 16? Checking all would need too much memory and we can assume that systems with more than 16 busses have better than average quality BIOS. This is an additional defense against bad MCFG tables. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86_64: Proper null pointer check in powernow_k8_getJacob Shin
This prevents crashes on dual core system when enough ticks are lost. Replaces earlier patch by me. Cc: Dave Jones <davej@redhat.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86_64: Revert earlier powernow-k8 changeAndi Kleen
Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386: Consolidate modern APIC handlingAndi Kleen
AMD systems have a modern APIC that supports 8 bit IDs, but don't have a XAPIC version number. Add a new "modern_apic" subfunction that handles this correctly and use it (nearly) everywhere where XAPIC is tested for. I removed one wart: the code specified that external APICs would use an 8bit APIC ID. But I checked a real 82093 data sheet and it says clearly that they only use 4bit. So I removed this special case since it would a bit awkward to implement now. I removed the valid APIC tests in mptable parsing completely. On any modern system they only check against the full field width (8bit) anyways and are no-ops. This also fixes them doing the wrong thing on >8 core Opterons. This makes i386 boot again on 16 core Opterons. Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86-64/i386: Don't process APICs/IO-APICs in ACPI when APIC is disabled.Andi Kleen
When nolapic was passed or the local APIC was disabled for another reason ACPI would still parse the IO-APICs until these were explicitely disabled with noapic. Usually this resulted in a non booting configuration unless "nolapic noapic" was used. I also disabled the local APIC parsing in this case, although that's only cosmetic (suppresses a few printks) This hopefully makes nolapic work in all cases. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86_64: Don't sanity check Type 1 PCI bus access on newer systemsAndi Kleen
Horus systems don't have anything on bus 0 which makes the Type 1 sanity checks fail. Use the DMI BIOS year to check for newer systems and always assume Type 1 works on them. I used 2001 as an pretty arbitary cutoff year. Cc: gregkh@suse.de Cc: Navin Boppuri <navin.boppuri@newisys.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] i386/x86-64: Check that MCFG points to an e820 reserved areaArjan van de Ven
This patch introduces a user for the e820_all_mapped function: There have been several machines that don't have a working MMCONFIG, often because of a buggy MCFG table in the ACPI bios. This patch adds a simple sanity check that detects a whole bunch of these cases, and when it detects it, linux now boots rather than crash-and-burns. The accuracy of this detection can in principle be improved if there was a "is this entire range in e820 with THIS attribute", but no such function exist and the complexity needed for this is not really worth it; this simple check already catches most cases anyway. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86_64: Introduce e820_all_mappedArjan van de Ven
Introduce a e820_all_mapped() function which checks if the entire range <start,end> is mapped with type. This is done by moving the local start variable to the end of each known-good region; if at the end of the function the start address is still before end, there must be a part that's not of the correct type; otherwise it's a good region. Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-09[PATCH] x86_64: Support memory hotadd without sparsememAndi Kleen
Memory hotadd doesn't need SPARSEMEM, but can be handled by just preallocating mem_maps. This only needs some untangling of ifdefs to enable the necessary code even without SPARSEMEM. Originally from Keith Mannthey, hacked by AK. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-04-02Merge git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivialLinus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/bunk/trivial: (48 commits) Documentation: fix minor kernel-doc warnings BUG_ON() Conversion in drivers/net/ BUG_ON() Conversion in drivers/s390/net/lcs.c BUG_ON() Conversion in mm/slab.c BUG_ON() Conversion in mm/highmem.c BUG_ON() Conversion in kernel/signal.c BUG_ON() Conversion in kernel/signal.c BUG_ON() Conversion in kernel/ptrace.c BUG_ON() Conversion in ipc/shm.c BUG_ON() Conversion in fs/freevxfs/ BUG_ON() Conversion in fs/udf/ BUG_ON() Conversion in fs/sysv/ BUG_ON() Conversion in fs/inode.c BUG_ON() Conversion in fs/fcntl.c BUG_ON() Conversion in fs/dquot.c BUG_ON() Conversion in md/raid10.c BUG_ON() Conversion in md/raid6main.c BUG_ON() Conversion in md/raid5.c Fix minor documentation typo BFP->BPF in Documentation/networking/tuntap.txt ...
2006-04-02Manual merge with Linus.Dmitry Torokhov
Conflicts: arch/powerpc/kernel/setup-common.c drivers/input/keyboard/hil_kbd.c drivers/input/mouse/hil_ptr.c
2006-04-01kexec: grammar fix for crash_save_this_cpu()Horms
kexec: grammar fix for crash_save_this_cpu() Signed-Off-By: Horms <horms@verge.net.au> Signed-off-by: Adrian Bunk <bunk@stusta.de>
2006-03-31[PATCH] unexport get_wchanAdrian Bunk
The only user of get_wchan is the proc fs - and proc can't be built modular. Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] sys_sync_file_range()Andrew Morton
Remove the recently-added LINUX_FADV_ASYNC_WRITE and LINUX_FADV_WRITE_WAIT fadvise() additions, do it in a new sys_sync_file_range() syscall instead. Reasons: - It's more flexible. Things which would require two or three syscalls with fadvise() can be done in a single syscall. - Using fadvise() in this manner is something not covered by POSIX. The patch wires up the syscall for x86. The sycall is implemented in the new fs/sync.c. The intention is that we can move sys_fsync(), sys_fdatasync() and perhaps sys_sync() into there later. Documentation for the syscall is in fs/sync.c. A test app (sync_file_range.c) is in http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz. The available-to-GPL-modules do_sync_file_range() is for knfsd: "A COMMIT can say NFS_DATA_SYNC or NFS_FILE_SYNC. I can skip the ->fsync call for NFS_DATA_SYNC which is hopefully the more common." Note: the `async' writeout mode SYNC_FILE_RANGE_WRITE will turn synchronous if the queue is congested. This is trivial to fix: add a new flag bit, set wbc->nonblocking. But I'm not sure that we want to expose implementation details down to that level. Note: it's notable that we can sync an fd which wasn't opened for writing. Same with fsync() and fdatasync()). Note: the code takes some care to handle attempts to sync file contents outside the 16TB offset on 32-bit machines. It makes such attempts appear to succeed, for best 32-bit/64-bit compatibility. Perhaps it should make such requests fail... Cc: Nick Piggin <nickpiggin@yahoo.com.au> Cc: Michael Kerrisk <mtk-manpages@gmx.net> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Neil Brown <neilb@cse.unsw.edu.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] Don't pass boot parameters to argv_init[]OGAWA Hirofumi
The boot cmdline is parsed in parse_early_param() and parse_args(,unknown_bootoption). And __setup() is used in obsolete_checksetup(). start_kernel() -> parse_args() -> unknown_bootoption() -> obsolete_checksetup() If __setup()'s callback (->setup_func()) returns 1 in obsolete_checksetup(), obsolete_checksetup() thinks a parameter was handled. If ->setup_func() returns 0, obsolete_checksetup() tries other ->setup_func(). If all ->setup_func() that matched a parameter returns 0, a parameter is seted to argv_init[]. Then, when runing /sbin/init or init=app, argv_init[] is passed to the app. If the app doesn't ignore those arguments, it will warning and exit. This patch fixes a wrong usage of it, however fixes obvious one only. Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] Mark unwind info for signal trampolines in vDSOsJakub Jelinek
Mark unwind info for signal trampolines using the new S augmentation flag introduced in: http://gcc.gnu.org/PR26208. GCC 4.2 (or patched earlier GCC) will be able to special case unwinding through frames right above signal trampolines. As the augmentations start with z flag and S is at the very end of the augmentation string, older GCCs will just skip the S flag as unknown (that's why an augmentation flag was chosen over say a new CFA opcode). Signed-off-by: Jakub Jelinek <jakub@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-31[PATCH] i386 kdump timer vector lockup fixVivek Goyal
Porting the patch I posted for x86_64 to i386. http://marc.theaimsgroup.com/?l=linux-kernel&m=114178139610707&w=2 o While using kdump, after a system crash when second kernel boots, timer vector gets (0x31) locked and CPU does not see timer interrupts travelling from IOAPIC to APIC. Currently it does not lead to boot failure in second kernel as timer interrupts continues to come as ExtInt through LAPIC directly, but fixing it is good in case some boards do not support the other mode. o After a system crash, it is not safe to service interrupts any more, hence interrupts are disabled. This leads to pending interrupts at LAPIC. LAPIC sends these interrupts to the CPU during early boot of second kernel. Other pending interrupts are discarded saying unexpected trap but timer interrupt is serviced and CPU does not issue an LAPIC EOI because it think this interrupt came from i8259 and sends ack to 8259. This leads to vector 0x31 locking as LAPIC does not clear respective ISR and keeps on waiting for EOI. o This patch issues extra EOI for the pending interrupts who have ISR set. o Though today only timer seems to be the special case because in early boot it thinks interrupts are coming from i8259 and uses mask_and_ack_8259A() as ack handler and does not issue LAPIC EOI. But probably doing it in generic manner for all vectors makes sense. Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-30[PATCH] Introduce sys_splice() system callJens Axboe
This adds support for the sys_splice system call. Using a pipe as a transport, it can connect to files or sockets (latter as output only). From the splice.c comments: "splice": joining two ropes together by interweaving their strands. This is the "extended pipe" functionality, where a pipe is used as an arbitrary in-memory buffer. Think of a pipe as a small kernel buffer that you can use to transfer data from one end to the other. The traditional unix read/write is extended with a "splice()" operation that transfers data buffers to or from a pipe buffer. Named by Larry McVoy, original implementation from Linus, extended by Jens to support splicing to files and fixing the initial implementation bugs. Signed-off-by: Jens Axboe <axboe@suse.de> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-28Merge master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreqLinus Torvalds
* master.kernel.org:/pub/scm/linux/kernel/git/davej/cpufreq: [CPUFREQ] cpufreq_conservative: keep ignore_nice_load and freq_step values when reselected [CPUFREQ] powernow: remove private for_each_cpu_mask() [CPUFREQ] hotplug cpu fix for powernow-k8 [PATCH] cpufreq_ondemand: add range check [PATCH] cpufreq_ondemand: keep ignore_nice_load value when it is reselected [PATCH] cpufreq_ondemand: Warn if it cannot run due to too long transition latency [PATCH] cpufreq_conservative: alternative initialise approach [PATCH] cpufreq_conservative: make for_each_cpu() safe [PATCH] cpufreq_conservative: alter default responsiveness [PATCH] cpufreq_conservative: aligning of codebase with ondemand
2006-03-28[PATCH] fix signed vs unsigned in nmi watchdogJesper Juhl
Fix "signed vs unsigned" in nmi_watchdog_tick. Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-28[PATCH] arch/i386/kernel/microcode.c: remove the obsolete microcode_ioctlAdrian Bunk
Nowadays, even Debian stable ships a microcode_ctl utility recent enough to no longer use this ioctl. Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Tigran Aivazian <tigran_aivazian@symantec.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-28[PATCH] for_each_possible_cpu: i386KAMEZAWA Hiroyuki
This patch replaces for_each_cpu with for_each_possible_cpu. under arch/i386. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27[CPUFREQ] powernow: remove private for_each_cpu_mask()Andrew Morton
It is unneeded and wrong. Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Dave Jones <davej@redhat.com>
2006-03-27[CPUFREQ] hotplug cpu fix for powernow-k8shin, jacob
Andi's previous fix to initialise powernow_data on all siblings will not work properly with CPU Hotplug. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Signed-off-by: Dave Jones <davej@redhat.com>
2006-03-27[PATCH] fbdev: Make BIOS EDID reading configurableAntonino A. Daplas
DDC reading via the Video BIOS may take several tens of seconds with some combination of display cards and monitors. Make this option configurable. It defaults to `y' to minimise disruption. Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27[PATCH] Notifier chain update: API changesAlan Stern
The kernel's implementation of notifier chains is unsafe. There is no protection against entries being added to or removed from a chain while the chain is in use. The issues were discussed in this thread: http://marc.theaimsgroup.com/?l=linux-kernel&m=113018709002036&w=2 We noticed that notifier chains in the kernel fall into two basic usage classes: "Blocking" chains are always called from a process context and the callout routines are allowed to sleep; "Atomic" chains can be called from an atomic context and the callout routines are not allowed to sleep. We decided to codify this distinction and make it part of the API. Therefore this set of patches introduces three new, parallel APIs: one for blocking notifiers, one for atomic notifiers, and one for "raw" notifiers (which is really just the old API under a new name). New kinds of data structures are used for the heads of the chains, and new routines are defined for registration, unregistration, and calling a chain. The three APIs are explained in include/linux/notifier.h and their implementation is in kernel/sys.c. With atomic and blocking chains, the implementation guarantees that the chain links will not be corrupted and that chain callers will not get messed up by entries being added or removed. For raw chains the implementation provides no guarantees at all; users of this API must provide their own protections. (The idea was that situations may come up where the assumptions of the atomic and blocking APIs are not appropriate, so it should be possible for users to handle these things in their own way.) There are some limitations, which should not be too hard to live with. For atomic/blocking chains, registration and unregistration must always be done in a process context since the chain is protected by a mutex/rwsem. Also, a callout routine for a non-raw chain must not try to register or unregister entries on its own chain. (This did happen in a couple of places and the code had to be changed to avoid it.) Since atomic chains may be called from within an NMI handler, they cannot use spinlocks for synchronization. Instead we use RCU. The overhead falls almost entirely in the unregister routine, which is okay since unregistration is much less frequent that calling a chain. Here is the list of chains that we adjusted and their classifications. None of them use the raw API, so for the moment it is only a placeholder. ATOMIC CHAINS ------------- arch/i386/kernel/traps.c: i386die_chain arch/ia64/kernel/traps.c: ia64die_chain arch/powerpc/kernel/traps.c: powerpc_die_chain arch/sparc64/kernel/traps.c: sparc64die_chain arch/x86_64/kernel/traps.c: die_chain drivers/char/ipmi/ipmi_si_intf.c: xaction_notifier_list kernel/panic.c: panic_notifier_list kernel/profile.c: task_free_notifier net/bluetooth/hci_core.c: hci_notifier net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_chain net/ipv4/netfilter/ip_conntrack_core.c: ip_conntrack_expect_chain net/ipv6/addrconf.c: inet6addr_chain net/netfilter/nf_conntrack_core.c: nf_conntrack_chain net/netfilter/nf_conntrack_core.c: nf_conntrack_expect_chain net/netlink/af_netlink.c: netlink_chain BLOCKING CHAINS --------------- arch/powerpc/platforms/pseries/reconfig.c: pSeries_reconfig_chain arch/s390/kernel/process.c: idle_chain arch/x86_64/kernel/process.c idle_notifier drivers/base/memory.c: memory_chain drivers/cpufreq/cpufreq.c cpufreq_policy_notifier_list drivers/cpufreq/cpufreq.c cpufreq_transition_notifier_list drivers/macintosh/adb.c: adb_client_list drivers/macintosh/via-pmu.c sleep_notifier_list drivers/macintosh/via-pmu68k.c sleep_notifier_list drivers/macintosh/windfarm_core.c wf_client_list drivers/usb/core/notify.c usb_notifier_list drivers/video/fbmem.c fb_notifier_list kernel/cpu.c cpu_chain kernel/module.c module_notify_list kernel/profile.c munmap_notifier kernel/profile.c task_exit_notifier kernel/sys.c reboot_notifier_list net/core/dev.c netdev_chain net/decnet/dn_dev.c: dnaddr_chain net/ipv4/devinet.c: inetaddr_chain It's possible that some of these classifications are wrong. If they are, please let us know or submit a patch to fix them. Note that any chain that gets called very frequently should be atomic, because the rwsem read-locking used for blocking chains is very likely to incur cache misses on SMP systems. (However, if the chain's callout routines may sleep then the chain cannot be atomic.) The patch set was written by Alan Stern and Chandra Seetharaman, incorporating material written by Keith Owens and suggestions from Paul McKenney and Andrew Morton. [jes@sgi.com: restructure the notifier chain initialization macros] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Chandra Seetharaman <sekharan@us.ibm.com> Signed-off-by: Jes Sorensen <jes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27[PATCH] lightweight robust futexes: i386Ingo Molnar
i386: add the futex_atomic_cmpxchg_inuser() assembly implementation, and wire up the new syscalls. Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Arjan van de Ven <arjan@infradead.org> Acked-by: Ulrich Drepper <drepper@redhat.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2006-03-27[PATCH] unify PFN_* macrosDave Hansen
Just about every architecture defines some macros to do operations on pfns. They're all virtually identical. This patch consolidates all of them. One minor glitch is that at least i386 uses them in a very skeletal header file. To keep away from #include dependency hell, I stuck the new definitions in a new, isolated header. Of all of the implementations, sh64 is the only one that varied by a bit. It used some masks to ensure that any sign-extension got ripped away before the arithmetic is done. This has been posted to that sh64 maintainers and the development list. Compiles on x86, x86_64, ia64 and ppc64. Signed-off-by: Dave Hansen <haveblue@us.ibm.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>