- 30 Jan, 2008 40 commits
-
-
Rafael J. Wysocki authored
Document the fact that __save_processor_state() has to save all CPU registers referred to by the kernel in case a different kernel is used to load and restore a hibernation image containing it. Sigend-off-by:
Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Sam Ravnborg authored
Michael Opdenacker reported: For backward compatibility with earlier (< 2.6.24) kernels, arch/i386/boot/bzImage or arch/x86_64/boot/bzImage symbolic links to arch/x86/boot/bzImage are created when you build an x86 kernel. The arch/i386 or arch/x86_64 directories are then created for this only purpose. Issue: these generated directories and symbolic links are *not cleaned up* when you run "make mrproper" (and thus "make distclean"). This disturbs the production of patches, because the source tree is left with generated files and directories. Sam has an alternative fix: The directory is killed during make clean as opposed to make mrproper. Reported-by:
Michael Opdenacker <michael-lists@free-electrons.com> Signed-off-by:
-
Venki Pallipadi authored
Current idle time in kstat is based on jiffies and is coarse grained. tick_sched.idle_sleeptime is making some attempt to keep track of idle time in a fine grained manner. But, it is not handling the time spent in interrupts fully. Make tick_sched.idle_sleeptime accurate with respect to time spent on handling interrupts and also add tick_sched.idle_lastupdate, which keeps track of last time when idle_sleeptime was updated. This statistics will be crucial for cpufreq-ondemand governor, which can shed some conservative gaurd band that is uses today while setting the frequency. The ondemand changes that uses the exact idle time is coming soon. Signed-off-by:
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
john stultz authored
I recently noticed on one of my boxes that when synched with an NTP server, the drift value reported for the system was ~283ppm. While in some cases, clock hardware can be that bad, it struck me as unusual as the system was using the acpi_pm clocksource, which is one of the more trustworthy and accurate clocksources on x86 hardware. I brought up another system and let it sync to the same NTP server, and I noticed a similar 280some ppm drift. In looking at the code, I found that the acpi_pm's constant frequency was being computed correctly at boot-up, however once the system was up, even without the ntp daemon running, the clocksource's frequency was being modified by the clocksource_adjust() function. Digging deeper, I realized that in the code that keeps track of how much the clocksource is skewing from the ntp desired time, we were using different lengths to establish how long an time interval was. The clocksource was being setup with the following interval: NTP_INTERVAL_LENGTH = NSEC_PER_SEC/NTP_INTERVAL_FREQ While the ntp code was using the tick_length_base value: tick_length_base ~= (tick_usec * NSEC_PER_USEC * USER_HZ) /NTP_INTERVAL_FREQ The subtle difference is: (tick_usec * NSEC_PER_USEC * USER_HZ) != NSEC_PER_SEC This difference in calculation was causing the clocksource correction code to apply a correction factor to the clocksource so the two intervals were the same, however this results in the actual frequency of the clocksource to be made incorrect. I believe this difference would affect all clocksources, although to differing degrees depending on the clocksource resolution. The issue was introduced when my HZ free ntp patch landed in 2.6.21-rc1, so my apologies for the mistake, and for not noticing it until now. The following patch, corrects the clocksource's initialization code so it uses the same interval length as the code in ntp.c. After applying this patch, the drift value for the same system went from ~283ppm to only 2.635ppm. I believe this patch to be good, however it does affect all arches and I've only tested on x86, so some caution is advised. I do think it would be a likely candidate for a stable 2.6.24.x release. Any thoughts or feedback would be appreciated. Signed-off-by:
John Stultz <johnstul@us.ibm.com> Signed-off-by:
-
Balaji Rao authored
Looks like IRQ 31 is assigned to timer 3, even without the patch! I wonder who wrote the number 31. But the manual says that it is zero by default. I think we should check whether the timer has been allocated an IRQ before proceeding to assign one to it. Here is a patch that does this. Signed-off-by:
Balaji Rao <balajirrao@gmail.com> Tested-by:
Yinghai Lu <yhlu.kernel@gmail.com> Signed-off-by:
-
Balaji Rao authored
The userspace API for the HPET (see Documentation/hpet.txt) did not work. The HPET_IE_ON ioctl was failing as there was no IRQ assigned to the timer device. This patch fixes it by allocating IRQs to timer blocks in the HPET. arch/x86/kernel/hpet.c | 13 +++++-------- drivers/char/hpet.c | 45 ++++++++++++++++++++++++++++++++++++++------- include/linux/hpet.h | 2 +- 3 files changed, 44 insertions(+), 16 deletions(-) Signed-off-by:
-
Ingo Molnar authored
detect zero event-device multiplicators - they then cause division-by-zero crashes if a clockevent has been initialized incorrectly. Signed-off-by:
-
Thomas Gleixner authored
The following scenario might leave PIT as a disfunctional clock source: PIT is registered as clocksource PM_TIMER is registered as clocksource and enables highres/dyntick mode PIT is switched to oneshot mode -> now the readout of PIT is bogus, but the user might select PIT via the sysfs override, which would break the box as the time readout is unusable. Unregister the PIT clocksource when the PIT clock event device is switched into shutdown / oneshot mode. Signed-off-by: -
Thomas Gleixner authored
On x86 the PIT might become an unusable clocksource. Add an unregister function to provide a possibilty to remove the PIT from the list of available clock sources. Signed-off-by:
-
Thomas Gleixner authored
PIT clocksource is registered unconditionally even when HPET is enabled or when PIT is replaced by the local APIC timer. In both cases PIT can not be used as it is stopped and the readout would be stale. Prevent registering PIT in those cases. patch depends on: x86: offer is_hpet_enabled() on !CONFIG_HPET_TIMER too Signed-off-by:
-
Ingo Molnar authored
offer is_hpet_enabled() on !CONFIG_HPET_TIMER too. Signed-off-by:
-
Andi Kleen authored
This way it checks if the clocks are synchronized between CPUs too. This might be able to detect slowly drifting TSCs which only go wrong over longer time. Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Parag Warudkar authored
clocksource_watchdog can use a deferrable timer - reduces wakeups from idle per second. Signed-off-by:
Parag Warudkar <parag.warudkar@gmail.com> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Geert Uytterhoeven authored
- getnstimeofday() was just a wrapper around __get_realtime_clock_ts() - Replace calls to __get_realtime_clock_ts() by calls to getnstimeofday() - Fix bogus reference to get_realtime_clock_ts(), which never existed Signed-off-by:
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Atsushi Nemoto authored
Signed-off-by:
Atsushi Nemoto <anemo@mba.ocn.ne.jp> Cc: john stultz <johnstul@us.ibm.com> Signed-off-by:
-
Thomas Gleixner authored
clean up tick-broadcast.c Signed-off-by:
-
Pavel Machek authored
I was confused by FSEC = 10^15 NSEC statement, plus small whitespace fixes. When there's copyright, there should be GPL. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Pavel Machek authored
Small cleanups to tick-related code. Wrong preempt count is followed by BUG(), so it is hardly KERN_WARNING. Signed-off-by:
-
Pavel Machek authored
Clean up hungarian notation from timer code. Signed-off-by:
-
Greg KH authored
the logic in this function is just crazy. It's recursive, but we can circumvent the creation for the kobject and whole creation of the threshold_block if some conditions are met. That's why we see the allocate_threshold_blocks so many times in the callstack, yet only a few kobjects created. Then we blow up in kobject_uevent_env() on the first debug printk. Which means that we are just passing in garbage. Man, this is one time that comments in code would have been very nice to have, and why forward goto's into major code blocks are just evil... Signed-off-by:
-
git://git.linux-nfs.org/pub/linux/nfs-2.6Linus Torvalds authored
* git://git.linux-nfs.org/pub/linux/nfs-2.6: (118 commits) NFSv4: Iterate through all nfs_clients when the server recalls a delegation NFSv4: Deal more correctly with duplicate delegations NFS: Fix a potential race between umount and nfs_access_cache_shrinker() NFS: Add an asynchronous delegreturn operation for use in nfs_clear_inode nfs: convert NFS_*(inode) helpers to static inline nfs: obliterate NFS_FLAGS macro NFS: Address memory leaks in the NFS client mount option parser nfs4: allow nfsv4 acls on non-regular-files NFS: Optimise away the sigmask code in aio/dio reads and writes SUNRPC: Don't bother changing the sigmask for asynchronous RPC calls SUNRPC: rpcb_getport_sync() passes incorrect address size to rpc_create() SUNRPC: Clean up block comment preceding rpcb_getport_sync() SUNRPC: Use appropriate argument types in rpcb client SUNRPC: rpcb_getport_sync() should use built-in hostname generator SUNRPC: Clean up functions that free address_strings array NFS: NFS version number is unsigned NLM: Fix a bogus 'return' in nlmclnt_rpc_release NLM: Introduce an arguments structure for nlmclnt_init() NLM/NFS: Use cached nlm_host when calling nlmclnt_proc() NFS: Invoke nlmclnt_init during NFS mount processing ...
-
Jens Axboe authored
If the two requests belong to the same io context, we will attempt to lock the same lock twice. But swapping contexts is pointless in that case, so just check for rioc == nioc before doing the double lock and copy. Tested-by:
Olof Johansson <olof@lixom.net> Signed-off-by:
Jens Axboe <jens.axboe@oracle.com>
-
Trond Myklebust authored
The same delegation may have been handed out to more than one nfs_client. Ensure that if a recall occurs, we return all instances. Signed-off-by:Trond Myklebust <Trond.Myklebust@netapp.com>
-
Trond Myklebust authored
If a (broken?) server hands out two different delegations for the same file, then we should return one of them. Signed-off-by: -
Trond Myklebust authored
Thanks to Yawei Niu for spotting the race. Signed-off-by: -
Trond Myklebust authored
Otherwise, there is a potential deadlock if the last dput() from an NFSv4 close() or other asynchronous operation leads to nfs_clear_inode calling the synchronous delegreturn. Signed-off-by: -
Benny Halevy authored
Signed-off-by:
Benny Halevy <bhalevy@panasas.com> Signed-off-by:
-
Benny Halevy authored
use NFS_I(inode)->flags instead Signed-off-by:
-
Chuck Lever authored
David Howells noticed that repeating the same mount option twice during an NFS mount request can result in orphaned memory in certain cases. Only the client_address and mount_server.hostname strings are initialized in the mount parsing loop, so those appear to be the only two pointers that might be written over by repeating a mount option. The strings in the nfs_server section of the nfs_parsed_mount_data structure are set only once after the options are parsed, thus these are not susceptible to being overwritten. Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
J. Bruce Fields authored
The rfc doesn't give any reason it shouldn't be possible to set an attribute on a non-regular file. And if the server supports it, then it shouldn't be up to us to prevent it. Thanks to Erez for the report and Trond for further analysis. Signed-off-by:
J. Bruce Fields <bfields@citi.umich.edu> Tested-by:
Erez Zadok <ezk@cs.sunysb.edu> Signed-off-by:
-
Trond Myklebust authored
There are no interruptible waits for asynchronous RPC tasks, so we don't need to wrap calls to rpc_run_task() with an rpc_clnt_sigmask/rpc_clnt_unsigmask pair. Instead we can wrap the wait_for_completion_interruptible() in nfs_direct_wait(). This means that we completely optimise away sigmask setting for the case of non-blocking aio/dio. Signed-off-by: -
Trond Myklebust authored
The caller will never sleep in rpc_execute, so don't bother setting the sigmask. Signed-off-by: -
Chuck Lever authored
The variable "sin" is a pointer, so sizeof(sin) is the size of a pointer, not the size of thing that sin points to. Signed-off-by:
-
Chuck Lever authored
Signed-off-by:
-
Chuck Lever authored
Clean up: Follow recommendations of Chapter 5 of Documentation/CodingStyle and use "u32" instead of "__u32" for types in definitions that are not shared with user space. Signed-off-by:
-
Chuck Lever authored
rpc_create() can already fill in the hostname with a string representation of the server's IP address, so remove redundant logic in in rpcb_getport_sync() that does that. Signed-off-by:
-
Chuck Lever authored
Clean up: document the rule (kfree) and the exceptions (RPC_DISPLAY_PROTO and RPC_DISPLAY_NETID) when freeing the objects in a transport's address_strings array. Signed-off-by:
-
Chuck Lever authored
RPC protocol version numbers are unsigned. Signed-off-by:
-
Trond Myklebust authored
Signed-off-by: -
Chuck Lever authored
Clean up: pass 5 arguments to nlmclnt_init() in a structure similar to the new nfs_client_initdata structure. Signed-off-by:
-
