- 13 Oct, 2006 40 commits
-
-
KAMEZAWA Hiroyuki authored
Assume that a cpu is *physically* offlined at boot time... Because smpboot.c::smp_boot_cpu_map() canoot find cpu's sapicid, numa.c::build_cpu_to_node_map() cannot build cpu<->node map for offlined cpu. For such cpus, cpu_to_node map should be fixed at cpu-hot-add. This mapping should be done before cpu onlining. This patch also handles cpu hotremove case. Signed-off-by:
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
KAMEZAWA Hiroyuki authored
Problem description: We have additional_cpus= option for allocating possible_cpus. But nid for possible cpus are not fixed at boot time. cpus which is offlined at boot or cpus which is not on SRAT is not tied to its node. This will cause panic at cpu onlining. Usually, pxm_to_nid() mapping is fixed at boot time by SRAT. But, unfortunately, some system (my system!) do not include full SRAT table for possible cpus. (Then, I use additiona_cpus= option.) For such possible cpus, pxm<->nid should be fixed at hot-add. We now have acpi_map_pxm_to_node() which is also used at boot. It's suitable here. Signed-off-by:
-
Michael Hanselmann authored
Seems like not all drivers use the framebuffer_alloc() function and won't have an initialized mutex. But those don't have a backlight, anyway. Signed-off-by:
Michael Hanselmann <linux-kernel@hansmi.ch> Cc: Olaf Hering <olaf@aepfle.de> Cc: "Antonino A. Daplas" <adaplas@pol.net> Cc: Daniel R Thompson <daniel.thompson@st.com> Cc: Jon Smirl <jonsmirl@gmail.com> Signed-off-by:
-
David Rientjes authored
Stops panic associated with attempting to free a non slab-allocated per_cpu_pageset. Signed-off-by:
David Rientjes <rientjes@cs.washington.edu> Acked-by:
Christoph Lameter <clameter@sgi.com> Signed-off-by:
-
Peter Zijlstra authored
BUG: warning at kernel/lockdep.c:1816/trace_hardirqs_on() (Not tainted) [<c04051ee>] show_trace_log_lvl+0x58/0x171 [<c0405802>] show_trace+0xd/0x10 [<c040591b>] dump_stack+0x19/0x1b [<c043abee>] trace_hardirqs_on+0xa2/0x11e [<c06143c3>] _spin_unlock_irq+0x22/0x26 [<c0541540>] rtc_get_rtc_time+0x32/0x176 [<c0419ba4>] hpet_rtc_interrupt+0x92/0x14d [<c0450f94>] handle_IRQ_event+0x20/0x4d [<c0451055>] __do_IRQ+0x94/0xef [<c040678d>] do_IRQ+0x9e/0xbd [<c0404a49>] common_interrupt+0x25/0x2c DWARF2 unwinder stuck at common_interrupt+0x25/0x2c Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Acked-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
keith mannthey authored
With CONFIG_PHYSICAL_START set to a non default values the i386 boot_ioremap code calculated its pte index wrong and users of boot_ioremap have their areas incorrectly mapped (for me SRAT table not mapped during early boot). This patch removes the addr < BOOT_PTE_PTRS constraint. Signed-off-by: Keith Mannthey<kmannth@us.ibm.com> Cc: Vivek Goyal <vgoyal@in.ibm.com> Cc: Dave Hansen <haveblue@us.ibm.com> Cc: Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Benjamin Herrenschmidt authored
Looks like a workaround for old bogus OF bitrot... This fixes it and hence fixes boot on some performa machines. Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Hidetoshi Seto authored
Following function can drops d_count twice against one reference by lookup_one_len. <SOURCE> /** * sysfs_update_file - update the modified timestamp on an object attribute. * @kobj: object we're acting for. * @attr: attribute descriptor. */ int sysfs_update_file(struct kobject * kobj, const struct attribute * attr) { struct dentry * dir = kobj->dentry; struct dentry * victim; int res = -ENOENT; mutex_lock(&dir->d_inode->i_mutex); victim = lookup_one_len(attr->name, dir, strlen(attr->name)); if (!IS_ERR(victim)) { /* make sure dentry is really there */ if (victim->d_inode && (victim->d_parent->d_inode == dir->d_inode)) { victim->d_inode->i_mtime = CURRENT_TIME; fsnotify_modify(victim); /** * Drop reference from initial sysfs_get_dentry(). */ dput(victim); res = 0; } else d_drop(victim); /** * Drop the reference acquired from sysfs_get_dentry() above. */ dput(victim); } mutex_unlock(&dir->d_inode->i_mutex); return res; } </SOURCE> PCI-hotplug (drivers/pci/hotplug/pci_hotplug_core.c) is only user of this function. I confirmed that dentry of /sys/bus/pci/slots/XXX/* have negative d_count value. This patch removes unnecessary dput(). Signed-off-by:Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by:
-
Arnd Bergmann authored
Ulrich Weigand found a bug with the current version of the asm-powerpc/ptrace.h that prevents building at least the SPU target version of gdb, since some ptrace opcodes are not defined. The problem seems to have originated in the merging of 32 and 64 bit versions of that file, the problem is that some opcodes are only valid on 64 bit kernels, but are also used by 32 bit programs, so they can't depends on the __powerpc64__ symbol. Signed-off-by:
Arnd Bergmann <arnd.bergmann@de.ibm.com> Signed-off-by:
David Woodhouse <dwmw2@infradead.org> Signed-off-by:
-
David Woodhouse authored
It's not used by anything user-visible, and it make g++ unhappy. Signed-off-by:
-
David Woodhouse authored
This fixes most of the issues with exported headers on CRIS, although we do still need to deal with the asm/arch symlink. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
David Woodhouse authored
For architectures which don't have the include/asm-$(ARCH)/Kbuild file, like ARM26, UM, etc. Signed-off-by:
-
David Woodhouse authored
No need for UML to export headers for userspace to build against. Signed-off-by:
-
David Woodhouse authored
We ought to be able to use ARM headers; no need for special ARM26 version. Signed-off-by:
-
David Woodhouse authored
Just clean up asm/page.h Signed-off-by:
-
David Woodhouse authored
Just clean up asm/page.h Signed-off-by:
-
David Woodhouse authored
Mostly removing files which have no business being used in userspace. Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
David Woodhouse authored
> asm-m32r/page.h requires asm-generic/memory_model.h, which does not exist > asm-m32r/ptrace.h requires asm/m32r.h, which does not exist > asm-m32r/signal.h requires linux/linkage.h, which does not exist > asm-m32r/unistd.h requires asm/syscall.h, which does not exist > asm-m32r/user.h requires asm/processor.h, which does not exist Signed-off-by:
Hirokazu Takata <takata@linux-m32r.org> Signed-off-by:
-
Paul Mundt authored
Cleanup for user headers, as noted: asm-sh64/page.h requires asm-generic/memory_model.h, which does not exist in exported headers asm-sh64/shmparam.h requires asm/cache.h, which does not exist in exported headers asm-sh64/signal.h requires asm/processor.h, which does not exist in exported headers asm-sh64/user.h requires asm/processor.h, which does not exist in exported headers Signed-off-by:
Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Paul Mundt authored
Cleanup for user headers, as noted: asm-sh/page.h requires asm-generic/memory_model.h, which does not exist in exported headers asm-sh/ptrace.h requires asm/ubc.h, which does not exist in exported headers Signed-off-by:
-
David Woodhouse authored
Sanitise the ARM headers exported to userspace. Signed-off-by:
-
David Woodhouse authored
Signed-off-by:
-
Stephen Hemminger authored
This makes the id table match the current netdev upstream tree. From: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: -
Stephen Hemminger authored
The sky2 driver will hang if transmit flow control is enabled and it receives a pause frame. The pause frame gets partially processed by hardware but never makes it through to the correct logic. This patch made it into 2.6.17 stable, but never got accepted for 2.6.18, so it will have to go into 2.6.18.1 See also: http://bugzilla.kernel.org/show_bug.cgi?id=6839Signed-off-by:
Stephen Hemminger <shemminger@osdl.org> Signed-off-by:
-
Jeff Garzik authored
inside #if 0'd code, but it bugged me. Really, we should probably just delete the driver. Signed-off-by:
Jeff Garzik <jeff@garzik.org> Signed-off-by:
-
Jeff Garzik authored
The last minute fix submitted by the author fixed a bug, but broke the driver build. Noticed by Al Viro, since I can't build on said platform. Signed-off-by:
-
Christoph Lameter authored
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0ff38490c836dc379ff7ec45b10a15a662f4e5f6 Currently one can enable slab reclaim by setting an explicit option in /proc/sys/vm/zone_reclaim_mode. Slab reclaim is then used as a final option if the freeing of unmapped file backed pages is not enough to free enough pages to allow a local allocation. However, that means that the slab can grow excessively and that most memory of a node may be used by slabs. We have had a case where a machine with 46GB of memory was using 40-42GB for slab. Zone reclaim was effective in dealing with pagecache pages. However, slab reclaim was only done during global reclaim (which is a bit rare on NUMA systems). This patch implements slab reclaim during zone reclaim. Zone reclaim occurs if there is a danger of an off node allocation. At that point we 1. Shrink the per node page cache if the number of pagecache pages is more than min_unmapped_ratio percent of pages in a zone. 2. Shrink the slab cache if the number of the nodes reclaimable slab pages (patch depends on earlier one that implements that counter) are more than min_slab_ratio (a new /proc/sys/vm tunable). The shrinking of the slab cache is a bit problematic since it is not node specific. So we simply calculate what point in the slab we want to reach (current per node slab use minus the number of pages that neeed to be allocated) and then repeately run the global reclaim until that is unsuccessful or we have reached the limit. I hope we will have zone based slab reclaim at some point which will make that easier. The default for the min_slab_ratio is 5% Also remove the slab option from /proc/sys/vm/zone_reclaim_mode. [akpm@osdl.org: cleanups] Signed-off-by:
Linus Torvalds <torvalds@osdl.org> Signed-off-by:
-
Christoph Lameter authored
The scheduler will stop load balancing if the most busy processor contains processes pinned via processor affinity. The scheduler currently only does one search for busiest cpu. If it cannot pull any tasks away from the busiest cpu because they were pinned then the scheduler goes into a corner and sulks leaving the idle processors idle. F.e. If you have processor 0 busy running four tasks pinned via taskset, there are none on processor 1 and one just started two processes on processor 2 then the scheduler will not move one of the two processes away from processor 2. This patch fixes that issue by forcing the scheduler to come out of its corner and retrying the load balancing by considering other processors for load balancing. This patch was originally developed by John Hawkes and discussed at http://marc.theaimsgroup.com/?l=linux-kernel&m=113901368523205&w=2. I have removed extraneous material and gone back to equipping struct rq with the cpu the queue is associated with since this makes the patch much easier and it is likely that others in the future will have the same difficulty of figuring out which processor owns which runqueue. The overhead added through these patches is a single word on the stack if the kernel is configured to support 32 cpus or less (32 bit). For 32 bit environments the maximum number of cpus that can be configued is 255 which would result in the use of 32 bytes additional on the stack. On IA64 up to 1k cpus can be configured which will result in the use of 128 additional bytes on the stack. The maximum additional cache footprint is one cacheline. Typically memory use will be much less than a cacheline and the additional cpumask will be placed on the stack in a cacheline that already contains other local variable. Signed-off-by:
-
Jan Kara authored
Original commit code assumes, that when a buffer on BJ_SyncData list is locked, it is being written to disk. But this is not true and hence it can lead to a potential data loss on crash. Also the code didn't count with the fact that journal_dirty_data() can steal buffers from committing transaction and hence could write buffers that no longer belong to the committing transaction. Finally it could possibly happen that we tried writing out one buffer several times. The patch below tries to solve these problems by a complete rewrite of the data commit code. We go through buffers on t_sync_datalist, lock buffers needing write out and store them in an array. Buffers are also immediately refiled to BJ_Locked list or unfiled (if the write out is completed). When the array is full or we have to block on buffer lock, we submit all accumulated buffers for IO. [suitable for 2.6.18.x around the 2.6.19-rc2 timeframe] Signed-off-by:
Jan Kara <jack@suse.cz> Cc: Badari Pulavarty <pbadari@us.ibm.com> Signed-off-by:
-
Takashi Iwai authored
ALSA: Fix initiailization of user-space controls Fix an assertion when accessing a user-defined control due to lack of initialization (appears only when CONFIG_SND_DEBUg is enabled). ALSA sound/core/control.c:660: BUG? (info->access == 0) Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Tony Lindgren authored
Allows compiling g_ether in and fixes a typo with MUSB_HDRC Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: David Brownell <david-b@pacbell.net> Signed-off-by:
-
Jack Morgenstein authored
The SM LID used to send traps to is incorrectly set to port LID. This is a regression from 2.6.17 -- after a PortInfo MAD is received, no traps are sent to the SM LID. The traps go to the loopback interface instead, and are dropped there. The SM LID should be taken from the sm_lid of the PortInfo response. The bug was introduced by commit 12bbb2b7: IB/mthca: Add client reregister event generation Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Signed-off-by:
Michael S. Tsirkin <mst@mellanox.co.il> Signed-off-by:
Roland Dreier <rolandd@cisco.com> Signed-off-by:
-
Martin Schwidefsky authored
[S390] user readable uninitialised kernel memory. A user space program can read uninitialised kernel memory by appending to a file from a bad address and then reading the result back. The cause is the copy_from_user function that does not clear the remaining bytes of the kernel buffer after it got a fault on the user space address. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Daniel Drake authored
The vendor driver chooses this value based on an ifndef ASIC, and ASIC is never defined. Signed-off-by:
Daniel Drake <dsd@gentoo.org> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
Mike Isely authored
Currently it is not understood how to properly control the horizontal capture resolution on 24xxx devices. The pvrusb2 driver is doing everything it should (pass resolution paramter(s) to cx2341x and cx25840 modules) but for some reason the result is corrupted video if any resolution other than 720 is used. This patch causes the driver to only permit a horizontal resolution of 720 to be used on 24xxx devices. Even if the app requests something else, the driver will force the resolution back to 720. This patch still allows full control of the resolution for 29xxx devices. Signed-off-by:
Mike Isely <isely@pobox.com> Signed-off-by:
Michael Krufky <mkrufky@linuxtv.org> Signed-off-by:
-
Mike Isely authored
The pvrusb2 driver needs to call video_devdata() in order to correctly transform a file pointer into a video_device pointer. Unfortunately the prototype for this function has been marked V4L1-only and there's no official substitute that I can find for V4L2. Adding to the mystery is that the implementation for this function exists whether or not V4L1 compatibility has been selected. The upshot of all this is that we get a compilation warning here about a missing prototype but the code links OK. This fix solves the warning by copying the prototype into the source file that is using it. Yes this is a hack, but it's a safe one for 2.6.18 (any alternative would be much more intrusive). A better solution should be forthcoming for the next kernel. Signed-off-by:
-
Mike Isely authored
The CONFIG_VIDEO_PVRUSB2_24XXX is not nearly as "experimental" as the description suggests. So refine the description to better match reality. Signed-off-by:
-
Mike Isely authored
There is a mutex ordering problem between the pvrusb2 driver and the v4l core. Two different pathways take mutexes in opposing orders and this (under rare circumstances) can cause a deadlock. The two mutexes in question are videodev_lock in the v4l core and device_lock inside the pvrusb2 driver. The device_lock instance in the driver protects a private global array of context pointers which had been implemented in advance of v4l core changes which eliminate the video_set_drvdata() and video_get_drvdata() functions. This patch restores the use of video_get_drvdata() and video_set_drvdata(), eliminating the need for the array and the mutex. (This is actually a patch to restore the previous implementation.) We can do this for 2.6.18 since those functions are in fact still present. A better (and larger) solution will be done for later kernels. Signed-off-by:
-
Yeasah Pell authored
The cx24109 datasheet says: "NOTE: if A=0, then N=N+1" The current code is the result of a misinterpretation of the datasheet to mean exactly the opposite of the requirement -- The actual value of N is 1 greater than the value written when A is 0, so 1 needs to be *subtracted* from it to compensate. Signed-off-by:
Yeasah Pell <yeasah@schwide.net> Signed-off-by:
Steven Toth <stoth@hauppauge.com> Signed-off-by:
-
