arch/microblaze/configs/nommu_defconfig | 50 +++++++++------ arch/microblaze/kernel/intc.c | 4 - arch/powerpc/configs/ps3_defconfig | 105 ++++++++++++++++++-------------- arch/powerpc/kernel/ftrace.c | 22 +++--- arch/powerpc/kernel/vmlinux.lds.S | 1 arch/powerpc/mm/pgtable.c | 3 arch/x86/Kconfig | 13 +++ arch/x86/include/asm/paravirt.h | 2 arch/x86/include/asm/percpu.h | 10 +-- arch/x86/include/asm/ptrace.h | 7 +- arch/x86/include/asm/spinlock.h | 4 - arch/x86/kernel/Makefile | 3 arch/x86/kernel/apic/es7000_32.c | 8 +- arch/x86/kernel/cpu/mtrr/generic.c | 6 + arch/x86/kernel/ftrace.c | 2 arch/x86/kernel/paravirt.c | 2 arch/x86/oprofile/backtrace.c | 2 arch/x86/xen/Makefile | 5 - arch/x86/xen/mmu.c | 1 arch/x86/xen/xen-ops.h | 19 ++++- drivers/char/random.c | 2 drivers/mtd/devices/mtd_dataflash.c | 2 drivers/regulator/da903x.c | 2 drivers/usb/serial/ftdi_sio.c | 9 -- fs/nfs/dir.c | 3 include/asm-generic/local.h | 2 kernel/lockdep_internals.h | 4 - kernel/sched_clock.c | 3 kernel/trace/trace.c | 2 29 files changed, 181 insertions(+), 117 deletions(-)
New commits: commit 26a9a418237c0b06528941bca693c49c8d97edbe Author: Linus Torvalds <[email protected]> Date: Tue May 19 11:25:35 2009 -0700 Avoid ICE in get_random_int() with gcc-3.4.5 Martin Knoblauch reports that trying to build 2.6.30-rc6-git3 with RHEL4.3 userspace (gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)) causes an internal compiler error (ICE): drivers/char/random.c: In function `get_random_int': drivers/char/random.c:1672: error: unrecognizable insn: (insn 202 148 150 0 /scratch/build/linux-2.6.30-rc6-git3/arch/x86/include/asm/tsc.h:23 (set (reg:SI 0 ax [91]) (subreg:SI (plus:DI (plus:DI (reg:DI 0 ax [88]) (subreg:DI (reg:SI 6 bp) 0)) (const_int -4 [0xfffffffffffffffc])) 0)) -1 (nil) (nil)) drivers/char/random.c:1672: internal compiler error: in extract_insn, at recog.c:2083 and after some debugging it turns out that it's due to the code trying to figure out the rough value of the current stack pointer by taking an address of an uninitialized variable and casting that to an integer. This is clearly a compiler bug, but it's not worth fighting - while the current stack kernel pointer might be somewhat hard to predict in user space, it's also not generally going to change for a lot of the call chains for a particular process. So just drop it, and mumble some incoherent curses at the compiler. Tested-by: Martin Knoblauch <[email protected]> Cc: Matt Mackall <[email protected]> Cc: Ingo Molnar <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 7ee2cb7f32b299c2b06a31fde155457203e4b7dd Author: Frank Filz <[email protected]> Date: Mon May 18 17:41:40 2009 -0400 nfs: Fix NFS v4 client handling of MAY_EXEC in nfs_permission. The problem is that permission checking is skipped if atomic open is possible, but when exec opens a file, it just opens it O_READONLY which means EXEC permission will not be checked at that time. This problem is observed by the following sequence (executed as root): mount -t nfs4 server:/ /mnt4 echo "ls" >/mnt4/foo chmod 744 /mnt4/foo su guest -c "mnt4/foo" Signed-off-by: Frank Filz <[email protected]> Signed-off-by: Trond Myklebust <[email protected]> Cc: [email protected] Tested-by: Eugene Teo <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 80193195f87ebca6d7417516d6edeb3969631c15 Author: David Woodhouse <[email protected]> Date: Mon May 18 13:07:35 2009 +0100 Fix oops on close of hot-unplugged FTDI serial converter Commit c45d6320 ("fix reference counting of ftdi_private") stopped ftdi_sio_port_remove() from directly freeing the port-private data, with the intention if the port was still open, it would be freed when ftdi_close() is eventually called and releases the last refcount on the structure. That's all very well, but ftdi_sio_port_remove() still contains a call to usb_set_serial_port_data(port, NULL) -- so by the time we get to ftdi_close() for the port which was unplugged, it _still_ oopses on dereferencing that NULL pointer, as it did before (and does in 2.6.29). The fix is just not to clear the private data in ftdi_sio_port_remove(). Then the refcount is properly reduced to zero when the final kref_put() happens in ftdi_close(). Remove a bogus comment too, while we're at it. And stop doing things inside "if (priv)" -- it must _always_ be there. Based loosely on an earlier patch by Daniel Mack, and suggestions by Alan Stern. Signed-off-by: David Woodhouse <[email protected]> Tested-by: Daniel Mack <[email protected]> Cc: [email protected] Signed-off-by: Linus Torvalds <[email protected]> commit dbf8c11f821b6ff83302c34f2403b4f7231f50ae Author: Peter Korsgaard <[email protected]> Date: Mon May 18 11:13:54 2009 +0100 mtd_dataflash: unbreak erase support Commit 5b7f3a50 (fix dataflash 64-bit divisions) unfortunately introduced a typo. Erase addr and len were swapped in the pageaddr calculation, causing the wrong sectors to get erased. Signed-off-by: Peter Korsgaard <[email protected]> Acked-by: Artem Bityutskiy <[email protected]> Signed-off-by: David Woodhouse <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit bac9caf016bf147af7d3afbe7580a7f773cb1566 Author: Roel Kluin <[email protected]> Date: Sun May 17 18:18:58 2009 -0700 asm-generic: fix local_add_unless macro `local_add_unless(x, y, z)' will be expanded to `(&(x)->y, (y), (x))', but `&(x)->y' should be `&(x)->a' Signed-off-by: Roel Kluin <[email protected]> Cc: Mathieu Desnoyers <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> commit 7b7210d7a9d260becef4dba98b9075e2c9b41f93 Author: Michal Simek <[email protected]> Date: Thu May 14 13:35:52 2009 +0200 microblaze: Fix kind-of-intr checking against number of interrupts + Fix typographic fault. Signed-off-by: Michal Simek <[email protected]> commit 3026589c1bc17b0c389b95afec127e92e2a745e2 Author: Michal Simek <[email protected]> Date: Mon May 11 09:24:47 2009 +0200 microblaze: Update Microblaze defconfig Signed-off-by: Michal Simek <[email protected]> commit 5b4662f098b47f68d7fcea9b065d1513547fef12 Author: Mike Frysinger <[email protected]> Date: Fri May 15 14:50:33 2009 -0400 regulator: da903x: add missing __devexit_p() The remove function uses __devexit, so the .remove assignment needs __devexit_p() to fix a build error with hotplug disabled. Signed-off-by: Mike Frysinger <[email protected]> CC: Liam Girdwood <[email protected]> CC: Mike Rapoport <[email protected]> CC: Eric Miao <[email protected]> Acked-by: Eric Miao <[email protected]> Signed-off-by: Liam Girdwood <[email protected]> commit 0e337b42d620ca7c45fe64e64dd71957c56216c9 Author: Benjamin Herrenschmidt <[email protected]> Date: Sun May 17 18:29:03 2009 +0000 powerpc: Explicit alignment for .data.cacheline_aligned I don't think anything guarantees that the objects in data.page_aligned are a multiple of PAGE_SIZE, thus the section may end on any boundary. So the following section, .data.cacheline_aligned needs an explicit alignment. Signed-off-by: Benjamin Herrenschmidt <[email protected]> commit dc892288f42661a140124ecbf9d44850a95de222 Author: Geoff Levand <[email protected]> Date: Fri May 15 08:01:59 2009 +0000 powerpc/ps3: Update ps3_defconfig Refresh and set these options: CONFIG_SYSFS_DEPRECATED_V2: y -> n CONFIG_INPUT_JOYSTICK: y -> n CONFIG_HID_SONY: n -> m CONFIG_RTC_DRV_PS3: - -> m Signed-off-by: Geoff Levand <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> commit c3cf8667ed7db58c1960958cbb0a9098d513cc60 Author: Steven Rostedt <[email protected]> Date: Fri May 15 04:33:54 2009 +0000 powerpc/ftrace: Fix constraint to be early clobber After upgrading my distcc boxes from gcc 4.2.2 to 4.4.0, the function graph tracer broke. This was discovered on my x86 boxes. The issue is that gcc used the same register for an output as it did for an input in an asm statement. I first thought this was a bug in gcc and reported it. I was notified that gcc was correct and that the output had to be flagged as an "early clobber". I noticed that powerpc had the same issue and this patch fixes it. Signed-off-by: Steven Rostedt <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> commit 021376a3b655364c92c10be544a3319946a792e8 Author: Michael Ellerman <[email protected]> Date: Wed May 13 20:30:24 2009 +0000 powerpc/ftrace: Use pr_devel() in ftrace.c pr_debug() can now result in code being generated even when #DEBUG is not defined. That's not really desirable in the ftrace code which we want to be snappy. With CONFIG_DYNAMIC_DEBUG=y: size before: text data bss dec hex filename 3334 672 4 4010 faa arch/powerpc/kernel/ftrace.o size after: text data bss dec hex filename 2616 360 4 2980 ba4 arch/powerpc/kernel/ftrace.o Signed-off-by: Michael Ellerman <[email protected]> Acked-by: Steven Rostedt <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> commit af3e4aca47d2e05a545a5e10ba5c7193e0b665e0 Author: Mel Gorman <[email protected]> Date: Thu Apr 30 10:59:19 2009 +0000 powerpc: Do not assert pte_locked for hugepage PTE entries With CONFIG_DEBUG_VM, an assertion is made when changing the protection flags of a PTE that the PTE is locked. Huge pages use a different pagetable format and the assertion is bogus and will always trigger with a bug looking something like Unable to handle kernel paging request for data at address 0xf1a00235800006f8 Faulting instruction address: 0xc000000000034a80 Oops: Kernel access of bad area, sig: 11 [#1] SMP NR_CPUS=32 NUMA Maple Modules linked in: dm_snapshot dm_mirror dm_region_hash dm_log dm_mod loop evdev ext3 jbd mbcache sg sd_mod ide_pci_generic pata_amd ata_generic ipr libata tg3 libphy scsi_mod windfarm_pid windfarm_smu_sat windfarm_max6690_sensor windfarm_lm75_sensor windfarm_cpufreq_clamp windfarm_core i2c_powermac NIP: c000000000034a80 LR: c000000000034b18 CTR: 0000000000000003 REGS: c000000003037600 TRAP: 0300 Not tainted (2.6.30-rc3-autokern1) MSR: 9000000000009032 <EE,ME,IR,DR> CR: 28002484 XER: 200fffff DAR: f1a00235800006f8, DSISR: 0000000040010000 TASK = c0000002e54cc740[2960] 'map_high_trunca' THREAD: c000000003034000 CPU: 2 GPR00: 4000000000000000 c000000003037880 c000000000895d30 c0000002e5a2e500 GPR04: 00000000a0000000 c0000002edc40880 0000005700000393 0000000000000001 GPR08: f000000011ac0000 01a00235800006e8 00000000000000f5 f1a00235800006e8 GPR12: 0000000028000484 c0000000008dd780 0000000000001000 0000000000000000 GPR16: fffffffffffff000 0000000000000000 00000000a0000000 c000000003037a20 GPR20: c0000002e5f4ece8 0000000000001000 c0000002edc40880 0000000000000000 GPR24: c0000002e5f4ece8 0000000000000000 00000000a0000000 c0000002e5f4ece8 GPR28: 0000005700000393 c0000002e5a2e500 00000000a0000000 c000000003037880 NIP [c000000000034a80] .assert_pte_locked+0xa4/0xd0 LR [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4 Call Trace: [c000000003037880] [c000000003037990] 0xc000000003037990 (unreliable) [c000000003037910] [c000000000034b18] .ptep_set_access_flags+0x6c/0xb4 [c0000000030379b0] [c00000000014bef8] .hugetlb_cow+0x124/0x674 [c000000003037b00] [c00000000014c930] .hugetlb_fault+0x4e8/0x6f8 [c000000003037c00] [c00000000013443c] .handle_mm_fault+0xac/0x828 [c000000003037cf0] [c0000000000340a8] .do_page_fault+0x39c/0x584 [c000000003037e30] [c0000000000057b0] handle_page_fault+0x20/0x5c Instruction dump: 7d29582a 7d200074 7800d182 0b000000 3c004000 3960ffff 780007c6 796b00c4 7d290214 7929a302 1d290068 7d6b4a14 <800b0010> 7c000074 7800d182 0b000000 This patch fixes the problem by not asseting the PTE is locked for VMAs backed by huge pages. Signed-off-by: Mel Gorman <[email protected]> Signed-off-by: Benjamin Herrenschmidt <[email protected]> commit b4ecc126991b30fe5f9a59dfacda046aeac124b2 Author: Jeremy Fitzhardinge <[email protected]> Date: Wed May 13 17:16:55 2009 -0700 x86: Fix performance regression caused by paravirt_ops on native kernels Xiaohui Xin and some other folks at Intel have been looking into what's behind the performance hit of paravirt_ops when running native. It appears that the hit is entirely due to the paravirtualized spinlocks introduced by: | commit 8efcbab674de2bee45a2e4cdf97de16b8e609ac8 | Date: Mon Jul 7 12:07:51 2008 -0700 | | paravirt: introduce a "lock-byte" spinlock implementation The extra call/return in the spinlock path is somehow causing an increase in the cycles/instruction of somewhere around 2-7% (seems to vary quite a lot from test to test). The working theory is that the CPU's pipeline is getting upset about the call->call->locked-op->return->return, and seems to be failing to speculate (though I haven't seen anything definitive about the precise reasons). This doesn't entirely make sense, because the performance hit is also visible on unlock and other operations which don't involve locked instructions. But spinlock operations clearly swamp all the other pvops operations, even though I can't imagine that they're nearly as common (there's only a .05% increase in instructions executed). If I disable just the pv-spinlock calls, my tests show that pvops is identical to non-pvops performance on native (my measurements show that it is actually about .1% faster, but Xiaohui shows a .05% slowdown). Summary of results, averaging 10 runs of the "mmperf" test, using a no-pvops build as baseline: nopv Pv-nospin Pv-spin CPU cycles 100.00% 99.89% 102.18% instructions 100.00% 100.10% 100.15% CPI 100.00% 99.79% 102.03% cache ref 100.00% 100.84% 100.28% cache miss 100.00% 90.47% 88.56% cache miss rate 100.00% 89.72% 88.31% branches 100.00% 99.93% 100.04% branch miss 100.00% 103.66% 107.72% branch miss rt 100.00% 103.73% 107.67% wallclock 100.00% 99.90% 102.20% The clear effect here is that the 2% increase in CPI is directly reflected in the final wallclock time. (The other interesting effect is that the more ops are out of line calls via pvops, the lower the cache access and miss rates. Not too surprising, but it suggests that the non-pvops kernel is over-inlined. On the flipside, the branch misses go up correspondingly...) So, what's the fix? Paravirt patching turns all the pvops calls into direct calls, so _spin_lock etc do end up having direct calls. For example, the compiler generated code for paravirtualized _spin_lock is: <_spin_lock+0>: mov %gs:0xb4c8,%rax <_spin_lock+9>: incl 0xffffffffffffe044(%rax) <_spin_lock+15>: callq *0xffffffff805a5b30 <_spin_lock+22>: retq The indirect call will get patched to: <_spin_lock+0>: mov %gs:0xb4c8,%rax <_spin_lock+9>: incl 0xffffffffffffe044(%rax) <_spin_lock+15>: callq <__ticket_spin_lock> <_spin_lock+20>: nop; nop /* or whatever 2-byte nop */ <_spin_lock+22>: retq One possibility is to inline _spin_lock, etc, when building an optimised kernel (ie, when there's no spinlock/preempt instrumentation/debugging enabled). That will remove the outer call/return pair, returning the instruction stream to a single call/return, which will presumably execute the same as the non-pvops case. The downsides arel 1) it will replicate the preempt_disable/enable code at eack lock/unlock callsite; this code is fairly small, but not nothing; and 2) the spinlock definitions are already a very heavily tangled mass of #ifdefs and other preprocessor magic, and making any changes will be non-trivial. The other obvious answer is to disable pv-spinlocks. Making them a separate config option is fairly easy, and it would be trivial to enable them only when Xen is enabled (as the only non-default user). But it doesn't really address the common case of a distro build which is going to have Xen support enabled, and leaves the open question of whether the native performance cost of pv-spinlocks is worth the performance improvement on a loaded Xen system (10% saving of overall system CPU when guests block rather than spin). Still it is a reasonable short-term workaround. [ Impact: fix pvops performance regression when running native ] Analysed-by: "Xin Xiaohui" <[email protected]> Analysed-by: "Li Xin" <[email protected]> Analysed-by: "Nakajima Jun" <[email protected]> Signed-off-by: Jeremy Fitzhardinge <[email protected]> Acked-by: H. Peter Anvin <[email protected]> Cc: Nick Piggin <[email protected]> Cc: Xen-devel <[email protected]> LKML-Reference: <[email protected]> [ fixed the help text ] Signed-off-by: Ingo Molnar <[email protected]> commit 88fc86c283d9c3854e67e4155808027bc2519eb6 Author: GeunSik Lim <[email protected]> Date: Thu May 14 17:23:38 2009 +0900 tracing: Append prompt in /debug/tracing/README file append prompt in /debug/tracing/README file. This is trivial issue. Fix typo Mini Howto file(README) for ftrace. [ Impact: cleanup ] Signed-off-by: GeunSik Lim <[email protected]> Acked-by: Steven Rostedt <[email protected]> Cc: williams <[email protected]> LKML-Reference: <1242289418.31161.45.ca...@centos51> Signed-off-by: Ingo Molnar <[email protected]> commit aa512a27e9e8ed32f31b15eec67ab1ceca33839b Author: Steven Rostedt <[email protected]> Date: Wed May 13 13:52:19 2009 -0400 x86/function-graph: fix constraint for recording old return value After upgrading from gcc 4.2.2 to 4.4.0, the function graph tracer broke. Investigating, I found that in the asm that replaces the return value, gcc was using the same register for the old value as it was for the new value. mov (addr), old mov new, (addr) But if old and new are the same register, we clobber new with old! I first thought this was a bug in gcc 4.4.0 and reported it: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40132 Andrew Pinski responded (quickly), saying that it was correct gcc behavior and the code needed to denote old as an "early clobber". Instead of "=r"(old), we need "=&r"(old). [Impact: keep function graph tracer from breaking with gcc 4.4.0 ] Signed-off-by: Steven Rostedt <[email protected]> commit 44408ad7368906c84000e87a99c14a16dbb867fd Author: Randy Dunlap <[email protected]> Date: Tue May 12 13:31:40 2009 -0700 xen: use header for EXPORT_SYMBOL_GPL mmu.c needs to #include module.h to prevent these warnings: arch/x86/xen/mmu.c:239: warning: data definition has no type or storage class arch/x86/xen/mmu.c:239: warning: type defaults to 'int' in declaration of 'EXPORT_SYMBOL_GPL' arch/x86/xen/mmu.c:239: warning: parameter names (without types) in function declaration [ Impact: cleanup ] Signed-off-by: Randy Dunlap <[email protected]> Acked-by: Jeremy Fitzhardinge <[email protected]> Signed-off-by: Andrew Morton <[email protected]> LKML-Reference: <new-submission> Signed-off-by: Ingo Molnar <[email protected]> commit d80c19df5fcceb8c741e96f09f275c2da719efef Author: Ingo Molnar <[email protected]> Date: Tue May 12 16:29:13 2009 +0200 lockdep: increase MAX_LOCKDEP_ENTRIES and MAX_LOCKDEP_CHAINS Now that lockdep coverage has increased it has become easier to run out of entries: [ 21.401387] BUG: MAX_LOCKDEP_ENTRIES too low! [ 21.402007] turning off the locking correctness validator. [ 21.402007] Pid: 1555, comm: S99local Not tainted 2.6.30-rc5-tip #2 [ 21.402007] Call Trace: [ 21.402007] [<ffffffff81069789>] add_lock_to_list+0x53/0xba [ 21.402007] [<ffffffff810eb615>] ? lookup_mnt+0x19/0x53 [ 21.402007] [<ffffffff8106be14>] check_prev_add+0x14b/0x1c7 [ 21.402007] [<ffffffff8106c304>] validate_chain+0x474/0x52a [ 21.402007] [<ffffffff8106c6fc>] __lock_acquire+0x342/0x3c7 [ 21.402007] [<ffffffff8106c842>] lock_acquire+0xc1/0xe5 [ 21.402007] [<ffffffff810eb615>] ? lookup_mnt+0x19/0x53 [ 21.402007] [<ffffffff8153aedc>] _spin_lock+0x31/0x66 Double the size - as we've done in the past. [ Impact: allow lockdep to cover more locks ] Acked-by: Peter Zijlstra <[email protected]> LKML-Reference: <new-submission> Signed-off-by: Ingo Molnar <[email protected]> commit 7b6c6c77732ca1d2498eda7eabb64f9648896e96 Author: Masami Hiramatsu <[email protected]> Date: Mon May 11 17:03:00 2009 -0400 x86, 32-bit: fix kernel_trap_sp() Use ®s->sp instead of regs for getting the top of stack in kernel mode. (on x86-64, regs->sp always points the top of stack) [ Impact: Oprofile decodes only stack for backtracing on i386 ] Signed-off-by: Masami Hiramatsu <[email protected]> [ v2: rename the API to kernel_stack_pointer(), move variable inside ] Acked-by: Linus Torvalds <[email protected]> Cc: [email protected] Cc: Harvey Harrison <[email protected]> Cc: Jan Blunck <[email protected]> Cc: Christoph Hellwig <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> commit 3c598766a2bae1b208470e7cc934ac462561e3cb Author: Jan Beulich <[email protected]> Date: Mon May 11 16:49:28 2009 +0100 x86: fix percpu_{to,from}_op() - the byte operand constraints were wrong for 32-bit - the to-op's input operands weren't properly parenthesized [ Impact: fix possible miscompilation or build failure ] Signed-off-by: Jan Beulich <[email protected]> Signed-off-by: H. Peter Anvin <[email protected]> commit 917a0153621572e88aeb2d5df025ad2e81027287 Author: Yinghai Lu <[email protected]> Date: Wed May 6 21:36:16 2009 -0700 x86: mtrr: Fix high_width computation when phys-addr is >= 44bit found one system where cpu address line is 44bits, mtrr printout is not right: [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0 00000000 mask FF0 00000000 write-back [ 0.000000] 1 base 10 00000000 mask FFF 80000000 write-back [ 0.000000] 2 base 0 80000000 mask FFF 80000000 uncachable [ 0.000000] 3 base 0 7F800000 mask FFF FF800000 uncachable Li Zefan and Frederic pointed out the high_width could be -4 some how. It turns out when phys_addr is 44bit, size_or_mask will be ffffffff,00000000 so ffs(size_or_mask) will be 0. Try to check low 32 bit, to get correct high_width. Signed-off-by: Yinghai Lu <[email protected]> Also-analyzed-by: Frederic Weisbecker <[email protected]> Also-analyzed-by: Li Zefan <[email protected]> Cc: Jeremy Fitzhardinge <[email protected]> Cc: Zhaolei <[email protected]> Cc: Steven Rostedt <[email protected]> Cc: Vegard Nossum <[email protected]> Cc: Andrew Morton <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> commit b74d446f1f337e3fe906169a3266cb65ffa4179e Author: Sam Ravnborg <[email protected]> Date: Sat May 9 15:35:10 2009 +0600 x86: Fix false positive section mismatch warnings in the apic code [ Impact: reduce kernel image size a bit, annotate away warnings ] Signed-off-by: Sam Ravnborg <[email protected]> [ modified and tested it ] Signed-off-by: Rakib Mullick <[email protected]> Cc: Marcin Slusarz <[email protected]> LKML-Reference: <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> commit 92d23f703c608fcb2c8edd74a3fd0f4031e18606 Author: Ron <[email protected]> Date: Fri May 8 22:54:49 2009 +0930 sched: Fix fallback sched_clock()'s offset when using jiffies Account for the initial offset to the jiffy count. [ Impact: fix printk timestamps on architectures using fallback sched_clock() ] Signed-off-by: Ron Lee <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=26a9a418237c0b06528941bca693c49c8d97edbe http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=7ee2cb7f32b299c2b06a31fde155457203e4b7dd http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=80193195f87ebca6d7417516d6edeb3969631c15 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=dbf8c11f821b6ff83302c34f2403b4f7231f50ae http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=bac9caf016bf147af7d3afbe7580a7f773cb1566 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=7b7210d7a9d260becef4dba98b9075e2c9b41f93 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=3026589c1bc17b0c389b95afec127e92e2a745e2 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=5b4662f098b47f68d7fcea9b065d1513547fef12 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=0e337b42d620ca7c45fe64e64dd71957c56216c9 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=dc892288f42661a140124ecbf9d44850a95de222 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=c3cf8667ed7db58c1960958cbb0a9098d513cc60 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=021376a3b655364c92c10be544a3319946a792e8 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=af3e4aca47d2e05a545a5e10ba5c7193e0b665e0 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=b4ecc126991b30fe5f9a59dfacda046aeac124b2 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=88fc86c283d9c3854e67e4155808027bc2519eb6 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=aa512a27e9e8ed32f31b15eec67ab1ceca33839b http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=44408ad7368906c84000e87a99c14a16dbb867fd http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=d80c19df5fcceb8c741e96f09f275c2da719efef http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=7b6c6c77732ca1d2498eda7eabb64f9648896e96 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=3c598766a2bae1b208470e7cc934ac462561e3cb http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=917a0153621572e88aeb2d5df025ad2e81027287 http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=b74d446f1f337e3fe906169a3266cb65ffa4179e http://suva.vyatta.com/git/?p=linux-vyatta.git;a=commitdiff;h=92d23f703c608fcb2c8edd74a3fd0f4031e18606 _______________________________________________ svn mailing list [email protected] http://mailman.vyatta.com/mailman/listinfo/svn
