- 13 Dec, 2006 40 commits
-
-
David Brownell authored
Fix a glitch in the procfs dumping of whether the alarm IRQ is enabled: use the traditional name (from drivers/char/rtc.c and many other places) of "alarm_IRQ", not "alrm_wakeup" (which didn't even match the efirtc code, which originated that reporting API). Also, update a few of the RTC drivers to stop providing that duplicate status, and/or to expose it properly when reporting the alarm state. We really don't want every RTC driver doing their own thing here... Signed-off-by:
David Brownell <dbrownell@users.sourceforge.net> Acked-by:
Alessandro Zummo <a.zummo@towertech.it> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
David Brownell authored
This removes some syslog spam as RTC drivers register; debug messages shouldn't come out at "info" level. Signed-off-by:
-
Jan Beulich authored
- conditionalizes procfs code upon CONFIG_PROC_FS (to reduce code size when that option is not enabled) - make initialization no longer fail when the procfs entry can't be allocated (namely would initialization always have failed when CONFIG_PROC_FS was not set) - move the formerly file-scope static variable rtc_int_handler_ptr into the only function using it, and makes it automatic. Signed-off-by:
Jan Beulich <jbeulich@novell.com> Signed-off-by:
-
Jan Beulich authored
Ensure RTC driver doesn't use its timer when it doesn't get to set it up (as it cannot currently prevent other of its functions to be called from outside when not built as a module - probably this should also be addressed). Signed-off-by:
-
Al Viro authored
Annotated, all places switched to keeping status net-endian. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Acked-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Al Viro authored
Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Al Viro authored
Now that it's built on m68k too... Signed-off-by:
-
Al Viro authored
Remove useless includes of linux/io.h, don't even try to build iomap_copy on uml (it doesn't have readb() et.al., so...) Signed-off-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Al Viro authored
Signed-off-by:
-
Ralf Baechle authored
I don't see why there is a memory barrier in copy_from_read_buf() at all. Even if it was useful spin_unlock_irqrestore implies a barrier. Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Robert P. J. Day authored
All kcalloc() calls of the form "kcalloc(1,...)" are converted to the equivalent kzalloc() calls, and a few kcalloc() calls with the incorrect ordering of the first two arguments are fixed. Signed-off-by:
Robert P. J. Day <rpjday@mindspring.com> Cc: Jeff Garzik <jeff@garzik.org> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: Adam Belay <ambx1@neo.rr.com> Cc: James Bottomley <James.Bottomley@steeleye.com> Cc: Greg KH <greg@kroah.com> Cc: Mark Fasheh <mark.fasheh@oracle.com> Cc: Trond Myklebust <trond.myklebust@fys.uio.no> Cc: Neil Brown <neilb@suse.de> Signed-off-by:
-
Jeremy Fitzhardinge authored
activate_mm() is not the right thing to be using in use_mm(). It should be switch_mm(). On normal x86, they're synonymous, but for the Xen patches I'm adding a hook which assumes that activate_mm is only used the first time a new mm is used after creation (I have another hook for dealing with dup_mm). I think this use of activate_mm() is the only place where it could be used a second time on an mm. >From a quick look at the other architectures I think this is OK (most simply implement one in terms of the other), but some are doing some subtly different stuff between the two. Acked-by:
David Miller <davem@davemloft.net> Signed-off-by:
-
Ingo Molnar authored
Jarek Poplawski noticed that lockdep global state could be accessed in a racy way if one CPU did a lockdep assert (shutting lockdep down), while the other CPU would try to do something that changes its global state. This patch fixes those races and cleans up lockdep's internal locking by adding a graph_lock()/graph_unlock()/debug_locks_off_graph_unlock helpers. (Also note that as we all know the Linux kernel is, by definition, bug-free and perfect, so this code never triggers, so these fixes are highly theoretical. I wrote this patch for aesthetic reasons alone.) [akpm@osdl.org: build fix] [jarkao2@o2.pl: build fix's refix] Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Jarek Poplawski <jarkao2@o2.pl> Signed-off-by:
-
Ingo Molnar authored
When we print an assert due to scheduling-in-atomic bugs, and if lockdep is enabled, then the IRQ tracing information of lockdep can be printed to pinpoint the code location that disabled interrupts. This saved me quite a bit of debugging time in cases where the backtrace did not identify the irq-disabling site well enough. Signed-off-by:
-
Ingo Molnar authored
CONFIG_DEBUG_LOCKDEP is unacceptably slow because it does not utilize the chain-hash. Turn the chain-hash back on in this case too. Signed-off-by:
-
Ingo Molnar authored
Cleanup: the VERY_VERBOSE define was unnecessarily dependent on #ifdef VERBOSE - while the VERBOSE switch is 0 or 1 (always defined). Signed-off-by:
-
Ingo Molnar authored
Clear all the chains during lockdep_reset(). This fixes some locking-selftest false positives i saw on -rt. (never saw those on mainline though, but it could happen.) Signed-off-by:
-
Ingo Molnar authored
Make verbose lockdep messages (off by default) more informative by printing out the hash chain key. (this patch was what helped me catch the earlier lockdep hash-collision bug) Signed-off-by:
-
Ingo Molnar authored
Fix typo in the class_filter() function. (filtering is not used by default so this only affects lockdep-internal debugging cases) Signed-off-by:
-
Ingo Molnar authored
Most distributions enable sysrq support but set it to 0 by default. Add a sysrq_always_enabled boot option to always-enable sysrq keys. Useful for debugging - without having to modify the disribution's config files (which might not be possible if the kernel is on a live CD, etc.). Also, while at it, clean up the sysrq interfaces. [bunk@stusta.de: make sysrq_always_enabled_setup() static] Signed-off-by:
Adrian Bunk <bunk@stusta.de> Signed-off-by:
-
Chen, Kenneth W authored
Implement block device specific .direct_IO method instead of going through generic direct_io_worker for block device. direct_io_worker() is fairly complex because it needs to handle O_DIRECT on file system, where it needs to perform block allocation, hole detection, extents file on write, and tons of other corner cases. The end result is that it takes tons of CPU time to submit an I/O. For block device, the block allocation is much simpler and a tight triple loop can be written to iterate each iovec and each page within the iovec in order to construct/prepare bio structure and then subsequently submit it to the block layer. This significantly speeds up O_D on block device. [akpm@osdl.org: small speedup] Signed-off-by:
Ken Chen <kenneth.w.chen@intel.com> Cc: Christoph Hellwig <hch@lst.de> Cc: Zach Brown <zach.brown@oracle.com> Signed-off-by:
-
Mark Fasheh authored
Update ocfs2_should_update_atime() to understand the MNT_RELATIME flag and to test against mtime / ctime accordingly. [akpm@osdl.org: cleanups] Signed-off-by:
Mark Fasheh <mark.fasheh@oracle.com> Cc: Valerie Henson <val_henson@linux.intel.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Valerie Henson authored
Add "relatime" (relative atime) support. Relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified. A corresponding patch against mount(8) is available at http://userweb.kernel.org/~akpm/mount-relative-atime.txtSigned-off-by:
Valerie Henson <val_henson@linux.intel.com> Cc: Mark Fasheh <mark.fasheh@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Karel Zak <kzak@redhat.com> Signed-off-by:
-
Andrew Morton authored
Simplify touch_atime() layout. Cc: Valerie Henson <val_henson@linux.intel.com> Cc: Mark Fasheh <mark.fasheh@oracle.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Chris Zankel authored
The kernel termios (ktermios) changes were somehow missed for Xtensa. This patch adds the ktermios structure and also includes some minor file name fix that was missed in the syscall patch. Signed-off-by:
Chris Zankel <chris@zankel.net> Acked-by:
Alan Cox <alan@lxorguk.ukuu.org.uk> Signed-off-by:
-
Rafael J. Wysocki authored
Currently, to tell a task that it should go to the refrigerator, we set the PF_FREEZE flag for it and send a fake signal to it. Unfortunately there are two SMP-related problems with this approach. First, a task running on another CPU may be updating its flags while the freezer attempts to set PF_FREEZE for it and this may leave the task's flags in an inconsistent state. Second, there is a potential race between freeze_process() and refrigerator() in which freeze_process() running on one CPU is reading a task's PF_FREEZE flag while refrigerator() running on another CPU has just set PF_FROZEN for the same task and attempts to reset PF_FREEZE for it. If the refrigerator wins the race, freeze_process() will state that PF_FREEZE hasn't been set for the task and will set it unnecessarily, so the task will go to the refrigerator once again after it's been thawed. To solve first of these problems we need to stop using PF_FREEZE to tell tasks that they should go to the refrigerator. Instead, we can introduce a special TIF_*** flag and use it for this purpose, since it is allowed to change the other tasks' TIF_*** flags and there are special calls for it. To avoid the freeze_process()-refrigerator() race we can make freeze_process() to always check the task's PF_FROZEN flag after it's read its "freeze" flag. We should also make sure that refrigerator() will always reset the task's "freeze" flag after it's set PF_FROZEN for it. Signed-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Acked-by:
Pavel Machek <pavel@ucw.cz> Cc: Russell King <rmk@arm.linux.org.uk> Cc: David Howells <dhowells@redhat.com> Cc: Andi Kleen <ak@muc.de> Cc: "Luck, Tony" <tony.luck@intel.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Paul Mundt <lethal@linux-sh.org> Signed-off-by:
-
Rafael J. Wysocki authored
Currently, if a task is stopped (ie. it's in the TASK_STOPPED state), it is considered by the freezer as unfreezeable. However, there may be a race between the freezer and the delivery of the continuation signal to the task resulting in the task running after we have finished freezing the other tasks. This, in turn, may lead to undesirable effects up to and including data corruption. To prevent this from happening we first need to make the freezer consider stopped tasks as freezeable. For this purpose we need to make freezeable() stop returning 0 for these tasks and we need to force them to enter the refrigerator. However, if there's no continuation signal in the meantime, the stopped tasks should remain stopped after all processes have been thawed, so we need to send an additional SIGSTOP to each of them before waking it up. Also, a stopped task that has just been woken up should first check if there's a freezing request for it and go to the refrigerator if that's the case. Signed-off-by:
-
Eric Dumazet authored
When some objects are allocated by one CPU but freed by another CPU we can consume lot of cycles doing divides in obj_to_index(). (Typical load on a dual processor machine where network interrupts are handled by one particular CPU (allocating skbufs), and the other CPU is running the application (consuming and freeing skbufs)) Here on one production server (dual-core AMD Opteron 285), I noticed this divide took 1.20 % of CPU_CLK_UNHALTED events in kernel. But Opteron are quite modern cpus and the divide is much more expensive on oldest architectures : On a 200 MHz sparcv9 machine, the division takes 64 cycles instead of 1 cycle for a multiply. Doing some math, we can use a reciprocal multiplication instead of a divide. If we want to compute V = (A / B) (A and B being u32 quantities) we can instead use : V = ((u64)A * RECIPROCAL(B)) >> 32 ; where RECIPROCAL(B) is precalculated to ((1LL << 32) + (B - 1)) / B Note : I wrote pure C code for clarity. gcc output for i386 is not optimal but acceptable : mull 0x14(%ebx) mov %edx,%eax // part of the >> 32 xor %edx,%edx // useless mov %eax,(%esp) // could be avoided mov %edx,0x4(%esp) // useless mov (%esp),%ebx [akpm@osdl.org: small cleanups] Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Cc: Christoph Lameter <clameter@sgi.com> Cc: David Miller <davem@davemloft.net> Signed-off-by:
-
Paul Jackson authored
Elaborate the API for calling cpuset_zone_allowed(), so that users have to explicitly choose between the two variants: cpuset_zone_allowed_hardwall() cpuset_zone_allowed_softwall() Until now, whether or not you got the hardwall flavor depended solely on whether or not you or'd in the __GFP_HARDWALL gfp flag to the gfp_mask argument. If you didn't specify __GFP_HARDWALL, you implicitly got the softwall version. Unfortunately, this meant that users would end up with the softwall version without thinking about it. Since only the softwall version might sleep, this led to bugs with possible sleeping in interrupt context on more than one occassion. The hardwall version requires that the current tasks mems_allowed allows the node of the specified zone (or that you're in interrupt or that __GFP_THISNODE is set or that you're on a one cpuset system.) The softwall version, depending on the gfp_mask, might allow a node if it was allowed in the nearest enclusing cpuset marked mem_exclusive (which requires taking the cpuset lock 'callback_mutex' to evaluate.) This patch removes the cpuset_zone_allowed() call, and forces the caller to explicitly choose between the hardwall and the softwall case. If the caller wants the gfp_mask to determine this choice, they should (1) be sure they can sleep or that __GFP_HARDWALL is set, and (2) invoke the cpuset_zone_allowed_softwall() routine. This adds another 100 or 200 bytes to the kernel text space, due to the few lines of nearly duplicate code at the top of both cpuset_zone_allowed_* routines. It should save a few instructions executed for the calls that turned into calls of cpuset_zone_allowed_hardwall, thanks to not having to set (before the call) then check (within the call) the __GFP_HARDWALL flag. For the most critical call, from get_page_from_freelist(), the same instructions are executed as before -- the old cpuset_zone_allowed() routine it used to call is the same code as the cpuset_zone_allowed_softwall() routine that it calls now. Not a perfect win, but seems worth it, to reduce this chance of hitting a sleeping with irq off complaint again. Signed-off-by:
Paul Jackson <pj@sgi.com> Signed-off-by:
-
Christoph Lameter authored
More cleanups for slab.h 1. Remove tabs from weird locations as suggested by Pekka 2. Drop the check for NUMA and SLAB_DEBUG from the fallback section as suggested by Pekka. 3. Uses static inline for the fallback defs as also suggested by Pekka. 4. Make kmem_ptr_valid take a const * argument. 5. Separate the NUMA fallback definitions from the kmalloc_track fallback definitions. Signed-off-by:
Christoph Lameter <clameter@sgi.com> Cc: Pekka Enberg <penberg@cs.helsinki.fi> Signed-off-by:
-
Christoph Lameter authored
This is a response to an earlier discussion on linux-mm about splitting slab.h components per allocator. Patch is against 2.6.19-git11. See http://marc.theaimsgroup.com/?l=linux-mm&m=116469577431008&w=2 This patch cleans up the slab header definitions. We define the common functions of slob and slab in slab.h and put the extra definitions needed for slab's kmalloc implementations in <linux/slab_def.h>. In order to get a greater set of common functions we add several empty functions to slob.c and also rename slob's kmalloc to __kmalloc. Slob does not need any special definitions since we introduce a fallback case. If there is no need for a slab implementation to provide its own kmalloc mess^H^H^Hacros then we simply fall back to __kmalloc functions. That is sufficient for SLOB. Sort the function in slab.h according to their functionality. First the functions operating on struct kmem_cache * then the kmalloc related functions followed by special debug and fallback definitions. Also redo a lot of comments. Signed-off-by: Christoph Lameter <clameter@sgi.com>? Signed-off-by:
-
Mike Miller authored
Remove calls to pci_disable_device except in fail_all_cmds. The pci_disable_device function does something nasty to Smart Array controllers that pci_enable_device does not undo. So if the driver is unloaded it cannot be reloaded. Also, customers can disable any pci device via the ROM Based Setup Utility (RBSU). If the customer has disabled the controller we should not try to blindly enable the card from the driver. Please consider this for inclusion. Signed-off-by:
Mike Miller <mike.miller@hp.com> Acked-by:
Alan Cox <alan@redhat.com> Signed-off-by:
-
Mike Miller authored
Map out more memory for our config table. It's required to reach offset 0x214 to disable DMA on the P600. I'm not sure how I lost this hunk. Please consider this for inclusion. Signed-off-by:
-
Jiri Slaby authored
When CONFIG_PCI is not defined (i.e. PCI bus is disabled), the sx driver fails to link, since some pci functions are not available. Fix this behaviour to be able to compile this driver on machines with no PCI bus (but with ISA bus support). Signed-off-by:
Jiri Slaby <jirislaby@gmail.com> Signed-off-by:
-
Jiri Slaby authored
When CONFIG_PCI is not defined (i.e. PCI bus is disabled), the mxser_new driver fails to link, since some pci functions are not available. Fix this behaviour to be able to compile this driver on machines with no PCI bus (but with ISA bus support). Signed-off-by:
-
Randy Dunlap authored
With CONFIG_PCI=n: drivers/char/isicom.c: In function 'isicom_probe': drivers/char/isicom.c:1793: warning: implicit declaration of function 'pci_request_region' drivers/char/isicom.c:1827: warning: implicit declaration of function 'pci_release_region' Let's CONFIG_ISI depend on CONFIG_PCI. Signed-off-by:
Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by:
-
Evgeniy Polyakov authored
Based on patch from Alexander Rigbo <alexander.rigbo@acgnystrom.se> Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
Avi Kivity authored
It seems macbooks set bit 2 but not bit 0, which is an "enabled but vmxon will fault" setting. Signed-off-by:
Avi Kivity <avi@qumranet.com> Tested-by: Alex Larsson (sometimes testing helps) Signed-off-by:
-
Michael Riepe authored
Signed-off-by:
-
