- 17 Jan, 2006 40 commits
-
-
Richard Mortimer authored
Ensure a consistent value is read from the STICK register by ensuring that both high and low are read without high changing due to a roll over of the low register. Various Debian/SPARC users (myself include) have noticed problems with Hummingbird based systems. The symptoms are that the system time is seen to jump forward 3 days, 6 hours, 11 minutes give or take a few seconds. In many cases the system then hangs some time afterwards. I've spotted a race condition in the code to read the STICK register. I could not work out why 3d, 6h, 11m is important but guess that it is due to the 2^32 jump of STICK (forwards on one read and then the next read will seem to be backwards) during a timer interrupt. I'm guessing that a change of -2^32 will get converted to a large unsigned increment after the arithmetic manipulation between STICK, nanoseconds, jiffies etc. I did a test where I modified __hbird_read_stick to artificially inject rollover faults forcefully every few seconds. With this I saw the clock jump over 6 times in 12 hours compared to once every month or so. Signed-off-by:
Richard Mortimer <richm@oldelvet.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Linus Torvalds authored
-
-
Alan Cox authored
Signed-off-by:
Alan Cox <alan@redhat.com> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by:
-
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by: -
Alan Cox authored
Signed-off-by:
-
Xose Vazquez Perez authored
Replace old information with newer from kernel.org Signed-off-by: -
Dmitry Torokhov authored
Signed-off-by:
Dmitry Torokhov <dtor@mail.ru> Signed-off-by:
-
Ingo Molnar authored
fix the following sparse warning: kernel/hrtimer.c:665:34: warning: incorrect type in argument 2 (different address spaces) kernel/hrtimer.c:665:34: expected void const *from kernel/hrtimer.c:665:34: got struct timespec [noderef] *<noident><asn:1> kernel/hrtimer.c:664:2: warning: dereference of noderef expression Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
-
Linus Torvalds authored
-
Ravikiran G Thirumalai authored
Patch fixes a build problem with CONFIG_X86_VSMP. The vSMP bits probably gathered some fuzz on its way to mainline, and safe_halt() which was outside the #endif (CONFIG_X86_VSMP) somehow got inside the !CONFIG_X86_VSMP condition, hence being undefined and breaking CONFIG_X86_VSMP builds. Patch takes safe_halt() and halt() macros out of the #endif Signed-off-by:
Ravikiran Thirumalai <kiran@scalex86.org> Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Matt Tolentino authored
Add __meminit to the __init lineup to ensure functions default to __init when memory hotplug is not enabled. Replace __devinit with __meminit on functions that were changed when the memory hotplug code was introduced. Signed-off-by:
Matt Tolentino <matthew.e.tolentino@intel.com> Signed-off-by:
-
Matt Tolentino authored
Add x86-64 specific memory hot-add functions, Kconfig options, and runtime kernel page table update functions to make hot-add usable on x86-64 machines. Also, fixup the nefarious conditional locking and exports pointed out by Andi. Tested on Intel and IBM x86-64 memory hot-add capable systems. Signed-off-by:
-
Andi Kleen authored
Another try at this. For 32bit follow the 32bit implementation from Ingo - mappings are growing down from the end of stack now and vary randomly by 1GB. Randomized mappings for 64bit just vary the normal mmap break by 1TB. I didn't bother implementing full flex mmap for 64bit because it shouldn't be needed there. Cc: mingo@elte.hu Signed-off-by:
-
