- 07 Sep, 2005 40 commits
-
-
Corey Minyard authored
This patch allows Dell servers with IPMI controllers that predate IPMI 1.5 to use the standard poweroff or powercycle commands. These systems firmware don't set the chassis capability bit in the Get Device ID, but they do implement the standard poweroff and powercycle commands. Tested on RHEL3 kernel 2.4.21-20.ELsmp on a PowerEdge 2600. The standard ipmi_poweroff driver cannot drive these systems. With this patch, they power off or powercycle as expected. Signed-off-by:
Matt Domsch <Matt_Domsch@dell.com> Signed-off-by:
Corey Minyard <minyard@acm.org> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Corey Minyard authored
The "null message handler" in the IPMI driver is used in startup and panic situations to handle messages. It was only designed to work with messages from the local management controller, but in some cases it was used to get messages from remote managmenet controllers, and the system would then panic. This patch makes the "null message handler" in the IPMI driver more general so it works with any kind of message. Signed-off-by:
-
Corey Minyard authored
This adds MODULE_VERSION, MODULE_DESCRIPTION, and MODULE_AUTHOR tags to the IPMI driver modules. Also changes the MODULE_VERSION to remove the prepended 'v' on each value, consistent with the module versioning policy. This patch also removes all the version information from everything except the ipmi_msghandler module. Signed-off-by:
-
Corey Minyard authored
The ipmi driver does not have a way to handle firmware-generated events which have the OEM[012] Data Available flags set. In such a case, the SMS_ATN bit may never get cleared by firmware, leaving the driver looping infinitely but never able to make any progress. This patch first simplifies storage and use of the data returned from an IPMI Get Device ID command. It then creates a new per-OEM handler hook, which should know how to handle events with the OEM[012] Data Available flags set. It then uses this to implement a workaround for IPMI 1.5-capable Dell PowerEdge servers which are susceptable to setting the OEM[012] Data Available flags when the driver can't handle it. Signed-off-by:
-
Corey Minyard authored
The IPMI driver include file needs to include compiler.h so it has definitions for __user and such. Signed-off-by:
-
Corey Minyard authored
There are some interactions between IPMI NMI timeouts and the other operations of the IPMI driver. This make sure those interactions are handled properly. Signed-off-by:
-
Corey Minyard authored
Fix some problems with the high-res timer support. Signed-off-by:
-
Corey Minyard authored
IPMI allows multiple IPMB channels on a single interface, and each channel might have a different IPMB address. However, the driver has only one IPMB address that it uses for everything. This patch adds new IOCTLS and a new internal interface for setting per-channel IPMB addresses and LUNs. New systems are coming out with support for multiple IPMB channels, and they are broken without this patch. Signed-off-by:
-
Andrey Panin authored
This patch replaces homebrew DMI scanning code in IPMI System Interface driver with dmi_find_device() call. Signed-off-by:
Andrey Panin <pazke@donpac.ru> Cc: Corey Minyard <minyard@acm.org> Signed-off-by:
-
Pekka Enberg authored
This patch introduces a memory-leak tracking version of kzalloc for ALSA. Signed-off-by:
Pekka Enberg <penberg@cs.helsinki.fi> Cc: Jaroslav Kysela <perex@suse.cz> Signed-off-by:
Jiri Slaby <xslaby@fi.muni.cz> Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka Enberg authored
This patch converts kcalloc(1, ...) calls to use the new kzalloc() function. Signed-off-by:
-
Pekka J Enberg authored
This patch introduces a kzalloc wrapper and converts kernel/ to use it. It saves a little program text. Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Robert Love authored
Background: 1) dmi_check_system() returns the count of the number of matches. Zero thus means no matches. 2) A match callback can return nonzero to stop the match checking. Bug: The count is incremented after we check for the nonzero return value, so it does not reflect the actual count. We could say this is intended, for some dumb reason, except that it means that a match on the first check returns zero--no matches--if the callback returns nonzero. Attached patch implements the count before calling the callback and thus before potentially short-circuiting. Signed-off-by:
Robert Love <rml@novell.com> Cc: Andrey Panin <pazke@donpac.ru> Signed-off-by:
-
Andrey Panin authored
This patch adds onboard devices and IPMI BMC discovery into DMI scan code. Drivers can use dmi_find_device() function to search for devices by type and name. Signed-off-by:
-
Andrey Panin authored
This patch changes dmi_string() function to allocate string copy by itself, to avoid code duplication in the next patch. Signed-off-by:
-
Andrey Panin authored
DMI debugging code is unused for ages. This patch removes it. Signed-off-by:
-
Andrey Panin authored
After elimination of central DMI blacklist dmi_scan_machine() function became a wrapper for dmi_iterate(). This patch moves some code around to kill unneeded function. Signed-off-by:
-
Miklos Szeredi authored
cifs_create() did totally the wrong thing with nd->intent.open.flags: it interpreted nd->intent.open.flags as the original open flags, not the one transformed for open_namei(). Also it used the intent data even if it was not filled in (if called from sys_mknod()). Signed-off-by:
Miklos Szeredi <miklos@szeredi.hu> Cc: <viro@parcelfarce.linux.theplanet.co.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Steven French <sfrench@us.ibm.com> Signed-off-by:
-
Miklos Szeredi authored
64 bit architectures all implement their own compatibility sys_open(), when in fact the difference is simply not forcing the O_LARGEFILE flag. So use the a common function instead. Signed-off-by:
-
Miklos Szeredi authored
Extract common code used by ptrace_attach() and may_ptrace_attach() into a separate function. Signed-off-by:
-
Miklos Szeredi authored
This patch fixes wrongly placed elements in the pid_directory_inos enum. Also add comment so this mistake is not repeated. Signed-off-by:
-
Miklos Szeredi authored
This patch cleans up proc_cwd_link() and proc_root_link() by factoring out common code into get_fs_struct(). Signed-off-by:
-
Miklos Szeredi authored
Extract common code into inline functions to make reading easier. Signed-off-by:
-
Miklos Szeredi authored
Remove unused ia_attr_flags from struct iattr, and related defines. Signed-off-by:
-
Jiri Slaby authored
This patch removes 1 whole entry, which is no longer maintained and 1 e-mail, which is not right. [comtrol was posted by Rolf Eike Beer] Signed-off-by:
Rolf Eike Beer <eike-kernel@sf-tec.de> Signed-off-by:
-
Olaf Hering authored
https://bugzilla.novell.com/show_bug.cgi?id=103746 Old 2.6.13 hotplug enviroment for 'plug in firewire disk' event: ==> debug.01139.ieee1394.add.8211 <== set -- ieee1394 UDEV_LOG='7' ACTION='add' DEVPATH='/class/ieee1394/00010410100036e0-0' SUBSYSTEM='ieee1394' SEQNUM='1139' PHYSDEVPATH='/devices/pci0001:10/0001:10:0d.0/0001:11:0a.0/fw-host0/00010410100036e0/00010410100036e0-0' PHYSDEVBUS='ieee1394' VENDOR_ID='000000' MODEL_ID='001010' GUID='00010410100036e0' SPECIFIER_ID='00609e' VERSION='010483' UDEVD_EVENT='1' Module spb2 is not loaded. grep sbp2 /lib/modules/2.6.13-20050901172817-default/modules.alias alias ieee1394:ven*mo*sp0000609Ever00010483* sbp2 printf 'ieee1394:ven%08Xmo%08Xsp%08Xver%08X\n' '0x000000' '0x001010' '0x00609e' '0x010483' ieee1394:ven00000000mo00001010sp0000609Ever00010483 modprobe -v ieee1394:ven00000000mo00001010sp0000609Ever00010483 insmod /lib/modules/2.6.13-20050901172817-default/kernel/drivers/ieee1394/sbp2.ko Providing a MODALIAS= enviroment variable with the content above will fix it. Signed-off-by:
Olaf Hering <olh@suse.de> Cc: Ben Collins <bcollins@debian.org> Signed-off-by:
-
Coywolf Qi Hunt authored
Signed-off-by:
Coywolf Qi Hunt <qiyong@fc-cn.com> Signed-off-by:
-
Eric Dumazet authored
dentry cache uses sophisticated RCU technology (and prefetching if available) but touches 2 cache lines per dentry during hlist lookup. This patch moves d_hash in the same cache line than d_parent and d_name fields so that : 1) One cache line is needed instead of two. 2) the hlist_for_each_rcu() prefetching has a chance to bring all the needed data in advance, not only the part that includes d_hash.next. I also changed one old comment that was wrong for 64bits. A further optimisation would be to separate dentry in two parts, one that is mostly read, and one writen (d_count/d_lock) to avoid false sharing on SMP/NUMA but this would need different field placement depending on 32bits or 64bits platform. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Signed-off-by:
-
John Hawkes authored
Revert the hack introduced last week. Signed-off-by:
John Hawkes <hawkes@sgi.com> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
John Hawkes authored
For a NUMA system with multiple CPUs per node, declaring a cpu-exclusive cpuset that includes only some, but not all, of the CPUs in a node will mangle the sched domain structures. Signed-off-by:
-
John Hawkes authored
Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Paul Jackson authored
Now the real motivation for this cpuset mem_exclusive patch series seems trivial. This patch keeps a task in or under one mem_exclusive cpuset from provoking an oom kill of a task under a non-overlapping mem_exclusive cpuset. Since only interrupt and GFP_ATOMIC allocations are allowed to escape mem_exclusive containment, there is little to gain from oom killing a task under a non-overlapping mem_exclusive cpuset, as almost all kernel and user memory allocation must come from disjoint memory nodes. This patch enables configuring a system so that a runaway job under one mem_exclusive cpuset cannot cause the killing of a job in another such cpuset that might be using very high compute and memory resources for a prolonged time. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Paul Jackson authored
This patch makes use of the previously underutilized cpuset flag 'mem_exclusive' to provide what amounts to another layer of memory placement resolution. With this patch, there are now the following four layers of memory placement available: 1) The whole system (interrupt and GFP_ATOMIC allocations can use this), 2) The nearest enclosing mem_exclusive cpuset (GFP_KERNEL allocations can use), 3) The current tasks cpuset (GFP_USER allocations constrained to here), and 4) Specific node placement, using mbind and set_mempolicy. These nest - each layer is a subset (same or within) of the previous. Layer (2) above is new, with this patch. The call used to check whether a zone (its node, actually) is in a cpuset (in its mems_allowed, actually) is extended to take a gfp_mask argument, and its logic is extended, in the case that __GFP_HARDWALL is not set in the flag bits, to look up the cpuset hierarchy for the nearest enclosing mem_exclusive cpuset, to determine if placement is allowed. The definition of GFP_USER, which used to be identical to GFP_KERNEL, is changed to also set the __GFP_HARDWALL bit, in the previous cpuset_gfp_hardwall_flag patch. GFP_ATOMIC and GFP_KERNEL allocations will stay within the current tasks cpuset, so long as any node therein is not too tight on memory, but will escape to the larger layer, if need be. The intended use is to allow something like a batch manager to handle several jobs, each job in its own cpuset, but using common kernel memory for caches and such. Swapper and oom_kill activity is also constrained to Layer (2). A task in or below one mem_exclusive cpuset should not cause swapping on nodes in another non-overlapping mem_exclusive cpuset, nor provoke oom_killing of a task in another such cpuset. Heavy use of kernel memory for i/o caching and such by one job should not impact the memory available to jobs in other non-overlapping mem_exclusive cpusets. This patch enables providing hardwall, inescapable cpusets for memory allocations of each job, while sharing kernel memory allocations between several jobs, in an enclosing mem_exclusive cpuset. Like Dinakar's patch earlier to enable administering sched domains using the cpu_exclusive flag, this patch also provides a useful meaning to a cpuset flag that had previously done nothing much useful other than restrict what cpuset configurations were allowed. Signed-off-by:
-
Paul Jackson authored
Add another GFP flag: __GFP_HARDWALL. A subsequent "cpuset_zone_allowed" patch will use this flag to mark GFP_USER allocations, and distinguish them from GFP_KERNEL allocations. Allocations (such as GFP_USER) marked GFP_HARDWALL are constrainted to the current tasks cpuset. Other allocations (such as GFP_KERNEL) can steal from the possibly larger nearest mem_exclusive cpuset ancestor, if memory is tight on every node in the current cpuset. This patch collides with Mel Gorman's patch to reduce fragmentation in the standard buddy allocator, which adds two GFP flags. This was discussed on linux-mm in July. Most likely, one of his flags for user reclaimable memory can be the same as my __GFP_HARDWALL flag, under some generic name meaning its user address space memory. Signed-off-by:
-
Paul Jackson authored
This patch series extends the use of the cpuset attribute 'mem_exclusive' to support cpuset configurations that: 1) allow GFP_KERNEL allocations to come from a potentially larger set of memory nodes than GFP_USER allocations, and 2) can constrain the oom killer to tasks running in cpusets in a specified subtree of the cpuset hierarchy. Here's an example usage scenario. For a few hours or more, a large NUMA system at a University is to be divided in two halves, with a bunch of student jobs running in half the system under some form of batch manager, and with a big research project running in the other half. Each of the student jobs is placed in a small cpuset, but should share the classic Unix time share facilities, such as buffered pages of files in /bin and /usr/lib. The big research project wants no interference whatsoever from the student jobs, and has highly tuned, unusual memory and i/o patterns that intend to make full use of all the main memory on the nodes available to it. In this example, we have two big sibling cpusets, one of which is further divided into a more dynamic set of child cpusets. We want kernel memory allocations constrained by the two big cpusets, and user allocations constrained by the smaller child cpusets where present. And we require that the oom killer not operate across the two halves of this system, or else the first time a student job runs amuck, the big research project will likely be first inline to get shot. Tweaking /proc/<pid>/oom_adj is not ideal -- if the big research project really does run amuck allocating memory, it should be shot, not some other task outside the research projects mem_exclusive cpuset. I propose to extend the use of the 'mem_exclusive' flag of cpusets to manage such scenarios. Let memory allocations for user space (GFP_USER) be constrained by a tasks current cpuset, but memory allocations for kernel space (GFP_KERNEL) by constrained by the nearest mem_exclusive ancestor of the current cpuset, even though kernel space allocations will still _prefer_ to remain within the current tasks cpuset, if memory is easily available. Let the oom killer be constrained to consider only tasks that are in overlapping mem_exclusive cpusets (it won't help much to kill a task that normally cannot allocate memory on any of the same nodes as the ones on which the current task can allocate.) The current constraints imposed on setting mem_exclusive are unchanged. A cpuset may only be mem_exclusive if its parent is also mem_exclusive, and a mem_exclusive cpuset may not overlap any of its siblings memory nodes. This patch was presented on linux-mm in early July 2005, though did not generate much feedback at that time. It has been built for a variety of arch's using cross tools, and built, booted and tested for function on SN2 (ia64). There are 4 patches in this set: 1) Some minor cleanup, and some improvements to the code layout of one routine to make subsequent patches cleaner. 2) Add another GFP flag - __GFP_HARDWALL. It marks memory requests for USER space, which are tightly confined by the current tasks cpuset. 3) Now memory requests (such as KERNEL) that not marked HARDWALL can if short on memory, look in the potentially larger pool of memory defined by the nearest mem_exclusive ancestor cpuset of the current tasks cpuset. 4) Finally, modify the oom killer to skip any task whose mem_exclusive cpuset doesn't overlap ours. Patch (1), the one time I looked on an SN2 (ia64) build, actually saved 32 bytes of kernel text space. Patch (2) has no affect on the size of kernel text space (it just adds a preprocessor flag). Patches (3) and (4) added about 600 bytes each of kernel text space, mostly in kernel/cpuset.c, which matters only if CONFIG_CPUSET is enabled. This patch: This patch applies a few comment and code cleanups to mm/oom_kill.c prior to applying a few small patches to improve cpuset management of memory placement. The comment changed in oom_kill.c was seriously misleading. The code layout change in select_bad_process() makes room for adding another condition on which a process can be spared the oom killer (see the subsequent cpuset_nodes_overlap patch for this addition). Also a couple typos and spellos that bugged me, while I was here. This patch should have no material affect. Signed-off-by:
-
