- 08 5月, 2009 3 次提交
-
-
由 Hidetoshi Seto 提交于
Lockdep reports the warning below when Li tries to offline one cpu: [ 110.835487] ================================= [ 110.835616] [ INFO: inconsistent lock state ] [ 110.835688] 2.6.30-rc4-00336-g8c9ed899 #52 [ 110.835757] --------------------------------- [ 110.835828] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage. [ 110.835908] swapper/0 [HC1[1]:SC0[0]:HE0:SE1] takes: [ 110.835982] (cmci_discover_lock){?.+...}, at: [<ffffffff80236dc0>] cmci_clear+0x30/0x9b cmci_clear() can be called via smp_call_function_single(). It is better to disable interrupt while holding cmci_discover_lock, to turn it into an irq-safe lock - we can deadlock otherwise. [ Impact: fix possible deadlock in the MCE code ] Reported-by: NShaohua Li <shaohua.li@intel.com> Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Andi Kleen <andi@firstfloor.org> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <4A03ED38.8000700@jp.fujitsu.com> Signed-off-by: NIngo Molnar <mingo@elte.hu> Reported-by: Shaohua Li<shaohua.li@intel.com>
-
由 Huang Ying 提交于
Tim Starling reported that crashdump will panic with kernel compiled with CONFIG_KEXEC_JUMP due to null pointer deference in machine_kexec_32.c: machine_kexec(), when deferencing kexec_image. Refering to: http://bugzilla.kernel.org/show_bug.cgi?id=13265 This patch fixes the BUG via replacing global variable reference: kexec_image in machine_kexec() with local variable reference: image, which is more appropriate, and will not be null. Same BUG is in machine_kexec_64.c too, so fixed too in the same way. [ Impact: fix crash on kexec ] Reported-by: NTim Starling <tstarling@wikimedia.org> Signed-off-by: NHuang Ying <ying.huang@intel.com> LKML-Reference: <1241751101.6259.85.camel@yhuang-dev.sh.intel.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
由 Jan Beulich 提交于
If the first non-reserved (sub-)range doesn't fit the size requested, an endless loop will be entered. If a range returned from find_e820_area_size() turns out insufficient in size, the range must be skipped before calling the function again. [ Impact: fixes boot hang on some platforms ] Signed-off-by: NJan Beulich <jbeulich@novell.com> Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
-
- 05 5月, 2009 1 次提交
-
-
由 Andreas Herrmann 提交于
Commit 7ad728f9 (cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t) changed the output of /proc/cpuinfo for siblings: Example on an AMD Phenom: physical id : 0 siblings : 1 core id : 3 cpu cores : 4 Before that commit it was: physical id : 0 siblings : 4 core id : 3 cpu cores : 4 Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings. This is due to the following hunk of above commit: | --- a/arch/x86/kernel/cpu/proc.c | +++ b/arch/x86/kernel/cpu/proc.c | @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf | if (c->x86_max_cores * smp_num_siblings > 1) { | seq_printf(m, "physical id\t: %d\n", c->phys_proc_id); | seq_printf(m, "siblings\t: %d\n", | - cpus_weight(per_cpu(cpu_core_map, cpu))); | + cpumask_weight(cpu_sibling_mask(cpu))); | seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id); | seq_printf(m, "cpu cores\t: %d\n", c->booted_cores); | seq_printf(m, "apicid\t\t: %d\n", c->apicid); This was a mistake, because the impact line shows that this side-effect was not anticipated: Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y So revert the respective hunk to restore the old behavior. [ Impact: fix sibling-info regression in /proc/cpuinfo ] Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Cc: Rusty Russell <rusty@rustcorp.com.au> LKML-Reference: <20090504182859.GA29045@alberich.amd.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 04 5月, 2009 1 次提交
-
-
由 Joerg Roedel 提交于
The feature bits should be set via bitmasks, not via feature IDs. [ Impact: fix feature enabling in newer IOMMU versions ] Signed-off-by: NJoerg Roedel <joerg.roedel@amd.com> LKML-Reference: <20090504102028.GA30307@amd.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 02 5月, 2009 1 次提交
-
-
由 Thomas Gleixner 提交于
commit db949bba (x86-32: use non-lazy io bitmap context switching) broke ioperm for 32bit because it removed the lazy initialization of io_bitmap_base and did not set it to the real bitmap offset. [ Impact: fix non-working sys_ioperm() on 32-bit kernels ] Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
-
- 24 4月, 2009 1 次提交
-
-
由 Len Brown 提交于
The HPET in the ICH4M is not documented in the data sheet because it was not officially validated. While it is fine for hackers to continue to use "hpet=force" to enable the hardware that they have, it is not prudent to solicit additional "hpet=force" users on this hardware. [ Impact: remove hpet=force syslog message on old-ICH systems ] Signed-off-by: NLen Brown <len.brown@intel.com> Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> LKML-Reference: <alpine.LFD.2.00.0904231918510.15843@localhost.localdomain> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 23 4月, 2009 2 次提交
-
-
由 Andi Kleen 提交于
The earlier patch to change the poller to a separate function subtly broke the boot logging logic. This could lead to machine checks getting logged at boot even when disabled or defaulting to off on some systems. Fix that. [ Impact: bug fix - avoid spurious MCE in log ] Signed-off-by: NAndi Kleen <ak@linux.intel.com> Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Andi Kleen 提交于
The polling timer while running per CPU still uses a global next_interval variable, which lead to some CPUs either polling too fast or too slow. This was not a serious problem because all errors get picked up eventually, but it's still better to avoid it. Turn next_interval into a per cpu variable. v2: Fix check_interval == 0 case (Hidetoshi Seto) [ Impact: minor bug fix ] Signed-off-by: NAndi Kleen <ak@linux.intel.com> Reviewed-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 22 4月, 2009 3 次提交
-
-
由 Coly Li 提交于
uv_read_rtc() is referenced by read member of struct clocksource clocksource_uv. In include/linux/clocksource.h, read of struct clocksource is declared as: cycle_t (*read)(struct clocksource *cs) This got introduced recently in: 8e19608e: clocksource: pass clocksource to read() callback But arch/x86/kernel/uv_time.c was not properly converted by that pach. This patch adds a dummy parameter (struct clocksource type) to uv_read_rtc() to fix the incompatible reference in clocksource_uv, and add a NULL parameter in all places where uv_read_rtc() gets called. [ Impact: cleanup, address compiler warning ] Signed-off-by: NColy Li <coly.li@suse.de> Cc: Dimitri Sivanich <sivanich@sgi.com> Cc: Magnus Damm <damm@igel.co.jp> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Hugh Dickins <hugh@veritas.com> LKML-Reference: <49EF3614.1050806@suse.de> Signed-off-by: NIngo Molnar <mingo@elte.hu> Cc: Dimitri Sivanich <sivanich@sgi.com>
-
由 Andreas Herrmann 提交于
(See http://bugzilla.kernel.org/show_bug.cgi?id=12961) It partially reverts commit c23e253e (x86: hpet: stop HPET_COUNTER when programming periodic mode) HPET on AMD 81xx chipset needs a second write (with HPET_TN_SETVAL cleared) to T0_CMP register to set the period in periodic mode. With this patch HPET_COUNTER is still stopped but not reset when HPET is programmed in periodic mode. This should help to avoid races when HPET is programmed in periodic mode and fixes a boot time hang that I've observed on a machine when using 1000HZ. [ Impact: fix boot time hang on machines with AMD 81xx chipset ] Reported-by: NJeff Mahoney <jeffm@suse.com> Signed-off-by: NAndreas Herrmann <andreas.herrmann3@amd.com> Tested-by: NJeff Mahoney <jeffm@suse.com> LKML-Reference: <20090421180037.GA2763@alberich.amd.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Magnus Damm 提交于
Pass clocksource pointer to the read() callback for clocksources. This allows us to share the callback between multiple instances. [hugh@veritas.com: fix powerpc build of clocksource pass clocksource mods] [akpm@linux-foundation.org: cleanup] Signed-off-by: NMagnus Damm <damm@igel.co.jp> Acked-by: NJohn Stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: NHugh Dickins <hugh@veritas.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 21 4月, 2009 4 次提交
-
-
由 Rusty Russell 提交于
In theory (though not shown in practice) alloc_cpumask_var() doesn't zero memory, so CPUs might print an "NMI backtrace for cpu %d" once on boot. (Bug introduced in fcef8576). [ Impact: avoid theoretical syslog noise in rare configs ] Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> Cc: Steven Rostedt <rostedt@goodmis.org> LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Rusty Russell 提交于
fcef8576 converted backtrace_mask to a cpumask_var_t, and assumed check_nmi_watchdog was called before nmi_watchdog_tick was ever called. Steven's oops shows I was wrong. This is something of a bandaid: I'm not sure we *should* be calling nmi_watchdog_tick before check_nmi_watchdog. Note that gcc eliminates this test for the CONFIG_CPUMASK_OFFSTACK=n case. [ Impact: fix boot crash in rare configs ] Reported-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NRusty Russell <rusty@rustcorp.com.au> LKML-Reference: <alpine.DEB.2.00.0904202113520.10097@gandalf.stny.rr.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Suresh Siddha 提交于
In 64bit signal delivery path, clear_used_math() was happening before saving the current active FPU state on to the user stack for signal handling. Between clear_used_math() and the state store on to the user stack, potentially we can get a page fault for the user address and can block. Infact, while testing we were hitting the might_fault() in __clear_user() which can do a schedule(). At a later point in time, we will schedule back into this process and resume the save state (using "xsave/fxsave" instruction) which can lead to DNA fault. And as used_math was cleared before, we will reinit the FP state in the DNA fault and continue. This reinit will result in loosing the FPU state of the process. Move clear_used_math() to a point after the FPU state has been stored onto the user stack. This issue is present from a long time (even before the xsave changes and the x86 merge). But it can easily be exposed in 2.6.28.x and 2.6.29.x series because of the __clear_user() in this path, which has an explicit __cond_resched() leading to a context switch with CONFIG_PREEMPT_VOLUNTARY. [ Impact: fix FPU state corruption ] Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> Cc: <stable@kernel.org> [2.6.28.x, 2.6.29.x] Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Jack Steiner 提交于
Fix endcase where the memory at physical address 0 does not really exist AND one of the sockets on blade 0 has no active cpus. The memory that _appears_ to be at physical address 0 is actually memory that located at a different address but has been remapped by the chipset so that it appears to be at physical address 0. When determining the UV pnode, the algorithm for determining the pnode incorrectly used the relocated physical address instead of the actual (global) address. [ Impact: boot failure on partitioned systems ] Signed-off-by: NJack Steiner <steiner@sgi.com> LKML-Reference: <20090420132530.GA23156@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 20 4月, 2009 4 次提交
-
-
由 Thomas Renninger 提交于
Take already available policy->cpuinfo.max_freq and get rid of acpi-cpufreq specific max_freq variable. This implies that P0 is always the highest frequency which should always be true as ACPI spec says: As a result, the zeroth entry describes the highest performance state Signed-off-by: NThomas Renninger <trenn@suse.de> Acked-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Thomas Renninger 提交于
Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Thomas Renninger 提交于
Signed-off-by: NThomas Renninger <trenn@suse.de> Signed-off-by: NLen Brown <len.brown@intel.com>
-
由 Pallipadi, Venkatesh 提交于
Fix for a regression that was introduced by earlier commit 18b2646f on Mon Apr 6 11:26:08 2009 Regression resulted in the below error happened on systems with software coordination where per_cpu acpi data will not be initiated for secondary CPUs in a P-state domain. On Tue, 2009-04-14 at 23:01 -0700, Zhang, Yanmin wrote: My machine hanged with kernel 2.6.30-rc2 when script read > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor. > > opps happens in get_measured_perf: > > cur.aperf.whole = readin.aperf.whole - > per_cpu(drv_data, cpu)->saved_aperf; > > Because per_cpu(drv_data, cpu)=NULL. > > So function get_measured_perf should check if (per_cpu(drv_data, > cpu)==NULL) > and return 0 if it's NULL. --------------sys log------------------ BUG: unable to handle kernel NULL pointer dereference at 0000000000000020 IP: [<ffffffff8021af75>] get_measured_perf+0x4a/0xf9 PGD a7dd88067 PUD a7ccf5067 PMD 0 Oops: 0000 [#1] SMP last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor CPU 0 Modules linked in: video output Pid: 2091, comm: kondemand/0 Not tainted 2.6.30-rc2 #1 MP Server RIP: 0010:[<ffffffff8021af75>] [<ffffffff8021af75>] get_measured_perf+0x4a/0xf9 RSP: 0018:ffff880a7d56de20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 00000046241a42b6 RCX: ffff88004d219000 RDX: 000000000000b660 RSI: 0000000000000020 RDI: 0000000000000001 RBP: ffff880a7f052000 R08: 00000046241a42b6 R09: ffffffff807639f0 R10: 00000000ffffffea R11: ffffffff802207f4 R12: ffff880a7f052000 R13: ffff88004d20e460 R14: 0000000000ddd5a6 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff88004d200000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 0000000000000020 CR3: 0000000a7f1bf000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process kondemand/0 (pid: 2091, threadinfo ffff880a7d56c000, task ffff880a7d4d18c0) Stack: ffff880a7f052078 ffffffff803efd54 00000046241a42b6 000000462ffa9e95 0000000000000001 0000000000000001 00000000ffffffea ffffffff8064f41a 0000000000000012 0000000000000012 ffff880a7f052000 ffffffff80650547 Call Trace: [<ffffffff803efd54>] ? kobject_get+0x12/0x17 [<ffffffff8064f41a>] ? __cpufreq_driver_getavg+0x42/0x57 [<ffffffff80650547>] ? do_dbs_timer+0x147/0x272 [<ffffffff80650400>] ? do_dbs_timer+0x0/0x272 [<ffffffff802474ca>] ? worker_thread+0x15b/0x1f5 [<ffffffff8024a02c>] ? autoremove_wake_function+0x0/0x2e [<ffffffff8024736f>] ? worker_thread+0x0/0x1f5 [<ffffffff80249f0d>] ? kthread+0x54/0x83 [<ffffffff8020c87a>] ? child_rip+0xa/0x20 [<ffffffff80249eb9>] ? kthread+0x0/0x83 [<ffffffff8020c870>] ? child_rip+0x0/0x20 Code: 99 a6 03 00 31 c9 85 c0 0f 85 c3 00 00 00 89 df 4c 8b 44 24 10 48 c7 c2 60 b6 00 00 48 8b 0c fd e0 30 a5 80 4c 89 c3 48 8b 04 0a <48> 2b 58 20 48 8b 44 24 18 48 89 1c 24 48 8b 34 0a 48 2b 46 28 RIP [<ffffffff8021af75>] get_measured_perf+0x4a/0xf9 RSP <ffff880a7d56de20> CR2: 0000000000000020 ---[ end trace 2b8fac9a49e19ad4 ]--- Tested-by: N"Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: NLen Brown <len.brown@intel.com>
-
- 18 4月, 2009 2 次提交
-
-
由 Steven Rostedt 提交于
I hit the check_flags error of lockdep: WARNING: at kernel/lockdep.c:2893 check_flags+0x1a7/0x1d0() [...] hardirqs last enabled at (12567): [<ffffffff8026206a>] local_bh_enable+0xaa/0x110 hardirqs last disabled at (12569): [<ffffffff80610c76>] int3+0x16/0x40 softirqs last enabled at (12566): [<ffffffff80514d2b>] lock_sock_nested+0xfb/0x110 softirqs last disabled at (12568): [<ffffffff8058454e>] tcp_prequeue_process+0x2e/0xa0 The check_flags warning of lockdep tells me that lockdep thought interrupts were disabled, but they were really enabled. The numbers in the above parenthesis show the order of events: 12566: softirqs last enabled: lock_sock_nested 12567: hardirqs last enabled: local_bh_enable 12568: softirqs last disabled: tcp_prequeue_process 12566: hardirqs last disabled: int3 int3 is a breakpoint! Examining this further, I have CONFIG_NET_TCPPROBE enabled which adds break points into the kernel. The paranoid_exit of the return of int3 does not account for enabling interrupts on return to kernel. This code is a bit tricky since it is also used by the nmi handler (when lockdep is off), and we must be careful about the swapgs. We can not call kernel code after the swapgs has been performed. [ Impact: fix lockdep check_flags warning + self-turn-off ] Acked-by: NPeter Zijlsta <a.p.zijlstra@chello.nl> Signed-off-by: NSteven Rostedt <rostedt@goodmis.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Jack Steiner 提交于
Fix an endcase in the UV initialization code for the "UV large system mode" of apicids. If node zero contains no cpus, cpus on another node will be the boot cpu. The percpu data that contains the extra apicid bits was not being initialized early enough. [ Impact: fix potential boot crash on cpu-less UV nodes ] Signed-off-by: NJack Steiner <steiner@sgi.com> LKML-Reference: <20090417142447.GA23759@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 17 4月, 2009 2 次提交
-
-
由 Dmitry Adamushko 提交于
Jeff Garzik reported this WARN_ON() noise: > Kernel: 2.6.30-rc1-00306-g8371f87c > Hardware: ICH10 x86-64 > > This is a regression from 2.6.29. Microcode spews the following WARNING > multiple times during boot: > > ------------[ cut here ]------------ > WARNING: at fs/sysfs/group.c:138 sysfs_remove_group+0xeb/0xf0() > Hardware name: sysfs group ffffffffa0209700 not found for > kobject 'cpu0' Keep sysfs files around for cpus even when we failed to locate microcode for them at the moment of module loading. The appropriate microcode firmware can become available later on. Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Cliff Wickman 提交于
This patch correctly sets BAU memory mapped registers to point to the sending activation descriptor table and target payload table. The "Broadcast Assist Unit" is used for TLB shootdown in UV. The memory mapped registers that point to sending and receiving memory structures contain node numbers. In one case the __pa() function did not provide the node id of memory on blade zero in configurations where that id is nonzero. In another case, it was assumed that memory was allocated on the local node. That assumption is not true in a configuration in which the node has no memory. Tested on the UV hardware simulator. [ Impact: fix possible runtime crash due to incorrect TLB logic ] Signed-off-by: NCliff Wickman <cpw@sgi.com> LKML-Reference: <E1LuR5Z-0007An-B8@eag09.americas.sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 15 4月, 2009 3 次提交
-
-
由 Linus Torvalds 提交于
It turns out that 'smp_call_function_many()' doesn't work at all like 'smp_call_function_single()', and my change to Andrew's patch to use it rather than a loop over all CPU's acpi-cpufreq doesn't work. My bad. 'smp_call_function_many()' has two "features" (aka "documented bugs"): (a) it needs to be called with preemption disabled, because it uses smp_processor_id() without guarding the CPU lookup with 'get_cpu()' and 'put_cpu()' like the 'single' variant does. (b) even if the current CPU is part of the CPU mask, it won't do the call on that CPU. Still, we're better off trying to use 'smp_call_function_many()' than looping over CPU's, since it at least in theory allows us to use a broadcast IPI and do it all in parallel. So let's just work around the silly semantic bugs in that function. Reported-and-tested-by: NAli Gholami Rudi <ali@rudi.ir> Cc: Ingo Molnar <mingo@elte.hu> Cc: Andrew Morton <akpm@linux-foundation.org>, Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Dave Jones <davej@redhat.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Hugh Dickins 提交于
Revert part of af5c820a ("x86: cpumask: use work_on_cpu in arch/x86/kernel/microcode_core.c") That change is causing only one Intel CPU's microcode to be updated e.g. microcode: CPU3 updated from revision 0x9 to 0x17, date = 2005-04-22 where before it announced that also for CPU0 and CPU1 and CPU2. We cannot use work_on_cpu() in the CONFIG_MICROCODE_OLD_INTERFACE code, because Intel's request_microcode_user() involves a copy_from_user() from /sbin/microcode_ctl, which therefore needs to be on that CPU at the time. Signed-off-by: NHugh Dickins <hugh@veritas.com> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Cliff Wickman 提交于
This patch enables each partition's BAU distribution bit map to be partition-relative. The distribution bitmap had been constructed assuming 0 as the base node number. That construct would not have allowed a total system of greater than 256 nodes. It also corrects an error that occurred when the first blade's nasid was not zero. That nasid was stored as the base node. The base node number gets added by hardware to the node numbers implied in the distribution bitmap, resulting in invalid target nasids. Tested on the UV hardware simulator. Signed-off-by: NCliff Wickman <cpw@sgi.com> LKML-Reference: <E1Ltl0C-0004Ob-37@eag09.americas.sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 14 4月, 2009 4 次提交
-
-
由 Pallipadi, Venkatesh 提交于
As discussed in the thread here: http://marc.info/?l=linux-kernel&m=123964468521142&w=2 Eric W. Biederman observed: > It looks like some additional bugs have slipped in since last I looked. > > set_irq_affinity does this: > ifdef CONFIG_GENERIC_PENDING_IRQ > if (desc->status & IRQ_MOVE_PCNTXT || desc->status & IRQ_DISABLED) { > cpumask_copy(desc->affinity, cpumask); > desc->chip->set_affinity(irq, cpumask); > } else { > desc->status |= IRQ_MOVE_PENDING; > cpumask_copy(desc->pending_mask, cpumask); > } > #else > > That IRQ_DISABLED case is a software state and as such it has nothing to > do with how safe it is to move an irq in process context. [...] > > The only reason we migrate MSIs in interrupt context today is that there > wasn't infrastructure for support migration both in interrupt context > and outside of it. Yes. The idea here was to force the MSI migration to happen in process context. One of the patches in the series did disable_irq(dev->irq); irq_set_affinity(dev->irq, cpumask_of(dev->cpu)); enable_irq(dev->irq); with the above patch adding irq/manage code check for interrupt disabled and moving the interrupt in process context. IIRC, there was no IRQ_MOVE_PCNTXT when we were developing this HPET code and we ended up having this ugly hack. IRQ_MOVE_PCNTXT was there when we eventually submitted the patch upstream. But, looks like I did a blind rebasing instead of using IRQ_MOVE_PCNTXT in hpet MSI code. Below patch fixes this. i.e., revert commit 932775a4 and add PCNTXT to HPET MSI setup. Also removes copying of desc->affinity in generic code as set_affinity routines are doing it internally. Reported-by: N"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com> Acked-by: N"Eric W. Biederman" <ebiederm@xmission.com> Cc: "Li Shaohua" <shaohua.li@intel.com> Cc: Gary Hade <garyhade@us.ibm.com> Cc: "lcm@us.ibm.com" <lcm@us.ibm.com> Cc: suresh.b.siddha@intel.com LKML-Reference: <20090413222058.GB8211@linux-os.sc.intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Linus Torvalds 提交于
We ended up incorrectly using '&cur' instead of '&readin' in the work_on_cpu() -> smp_call_function_single() transformation in commit 01599fca ("cpufreq: use smp_call_function_[single|many]() in acpi-cpufreq.c"). Andrew explains: "OK, the acpi tree went and had conflicting changes merged into it after I'd written the patch and it appears that I incorrectly reverted part of 18b2646f while fixing the resulting rejects. Switching it to `readin' looks correct." Acked-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
由 Jaswinder Singh Rajput 提交于
Impact: reduce kernel size a bit, address sparse warning Addresses the problem pointed out by this sparse warning: arch/x86/kernel/pci-swiotlb.c:53:20: warning: symbol 'swiotlb_dma_ops' was not declared. Should it be static? For x86: swiotlb_dma_ops can be static, because it's not used outside of pci-swiotlb.c Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com> Acked-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> LKML-Reference: <1239558861.3938.2.camel@localhost.localdomain> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Andrew Morton 提交于
Atttempting to rid us of the problematic work_on_cpu(). Just use smp_call_fuction_single() here. This repairs a 10% sysbench(oltp)+mysql regression which Mike reported, due to commit 6b44003e Author: Andrew Morton <akpm@linux-foundation.org> Date: Thu Apr 9 09:50:37 2009 -0600 work_on_cpu(): rewrite it to create a kernel thread on demand It seems that the kernel calls these acpi-cpufreq functions at a quite high frequency. Valdis Kletnieks also reports that this causes 70-90 forks per second on his hardware. Cc: Valdis.Kletnieks@vt.edu Cc: Rusty Russell <rusty@rustcorp.com.au> Cc: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Cc: Len Brown <len.brown@intel.com> Cc: Zhao Yakui <yakui.zhao@intel.com> Acked-by: NDave Jones <davej@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Tested-by: NMike Galbraith <efault@gmx.de> Cc: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Acked-by: NIngo Molnar <mingo@elte.hu> [ Made it use smp_call_function_many() instead of looping over cpu's with smp_call_function_single() - Linus ] Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 12 4月, 2009 2 次提交
-
-
由 Suresh Siddha 提交于
Impact: save/restore Intel-AVX state properly between tasks Intel Advanced Vector Extensions (AVX) introduce 256-bit vector processing capability. More about AVX at http://software.intel.com/sites/avx Add OS support for YMM state management using xsave/xrstor infrastructure to support AVX. Signed-off-by: NSuresh Siddha <suresh.b.siddha@intel.com> LKML-Reference: <1239402084.27006.8057.camel@localhost.localdomain> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Rakib Mullick 提交于
Impact: fix section mismatch In arch/x86/kernel/mpparse.c, smp_reserve_bootmem() has been called and also refers to a function which is in .init section. Thus causes the first warning. And check_irq_src() also requires an __init, because it refers to an .init section. Signed-off-by: NRakib Mullick <rakib.mullick@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <b9df5fa10904102004g51265d9axc8d07278bfdb6ba0@mail.gmail.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 10 4月, 2009 1 次提交
-
-
由 Weidong Han 提交于
To simplify level irq migration in the presence of interrupt-remapping, Suresh used a virtual vector (io-apic pin number) to eliminate io-apic RTE modification. Level triggered interrupt will appear as an edge to the local apic cpu but still as level to the IO-APIC. So in addition to do the local apic EOI, it still needs to do IO-APIC directed EOI to clear the remote IRR bit in the IO-APIC RTE. Pls refer to Suresh's patch for more details (commit 0280f7c4). Now interrupt remapping is decoupled from x2apic, it also needs to do the directed EOI for apic. Otherwise, apic interrupts won't work correctly. Signed-off-by: NWeidong Han <weidong.han@intel.com> Cc: iommu@lists.linux-foundation.org Cc: Weidong Han <weidong.han@intel.com> Cc: suresh.b.siddha@intel.com Cc: dwmw2@infradead.org Cc: allen.m.kay@intel.com LKML-Reference: <1239355037-22856-1-git-send-email-weidong.han@intel.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 09 4月, 2009 3 次提交
-
-
由 Jaswinder Singh Rajput 提交于
It seems by mistake these files got execute permissions so removing it. Signed-off-by: NJaswinder Singh Rajput <jaswinderrajput@gmail.com> LKML-Reference: <1239211186.9037.2.camel@ht.satnam> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Frederic Weisbecker 提交于
Impact: fix build warnings and possibe compat misbehavior on IA64 Building a kernel on ia64 might trigger these ugly build warnings: CC arch/ia64/ia32/sys_ia32.o In file included from arch/ia64/ia32/sys_ia32.c:55: arch/ia64/ia32/ia32priv.h:290:1: warning: "elf_check_arch" redefined In file included from include/linux/elf.h:7, from include/linux/module.h:14, from include/linux/ftrace.h:8, from include/linux/syscalls.h:68, from arch/ia64/ia32/sys_ia32.c:18: arch/ia64/include/asm/elf.h:19:1: warning: this is the location of the previous definition [...] sys_ia32.c includes linux/syscalls.h which in turn includes linux/ftrace.h to import the syscalls tracing prototypes. But including ftrace.h can pull too much things for a low level file, especially on ia64 where the ia32 private headers conflict with higher level headers. Now we isolate the syscall tracing headers in their own lightweight file. Reported-by: NTony Luck <tony.luck@intel.com> Tested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NFrederic Weisbecker <fweisbec@gmail.com> Acked-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Jason Baron <jbaron@redhat.com> Cc: "Frank Ch. Eigler" <fche@redhat.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Cc: Lai Jiangshan <laijs@cn.fujitsu.com> Cc: Jiaying Zhang <jiayingz@google.com> Cc: Michael Rubin <mrubin@google.com> Cc: Martin Bligh <mbligh@google.com> Cc: Michael Davidson <md@google.com> LKML-Reference: <20090408184058.GB6017@nowhere> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Hidetoshi Seto 提交于
Now /proc/interrupts of tip tree has new counters: PLT: Platform interrupts Format change of output, as like that by commit: commit 7a81d9a7 x86: smarten /proc/interrupts output should be applied to these new counters too. Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Cc: Jan Beulich <jbeulich@novell.com> LKML-Reference: <49C98DEA.8060208@jp.fujitsu.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
- 08 4月, 2009 3 次提交
-
-
由 Alan Cox 提交于
Closes http://bugzilla.kernel.org/show_bug.cgi?12901Signed-off-by: NAlan Cox <alan@lxorguk.ukuu.org.uk> LKML-Reference: <20090326204524.4454.8776.stgit@localhost.localdomain> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Yinghai Lu 提交于
Impact: restore old behavior for flat and phys_flat Signed-off-by: Yinhai Lu <yinghai@kernel.org. LKML-Reference: <49DCBBF1.8080903@kernel.org> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-
由 Russ Anderson 提交于
/sys/firmware/sgi_uv should only be created on uv systems. Signed-off-by: NRuss Anderson <rja@sgi.com> LKML-Reference: <20090403222423.GA28546@sgi.com> Signed-off-by: NIngo Molnar <mingo@elte.hu>
-