Re: [PATCH] [mm] trivial fixes to long lines and typo in comment
On Sat, 29 Nov 2014, Mel Gorman wrote: Well, the subject line says it all. Why bother? It adds almost nothing (one meaningful change) and git blame would no longer points to the commit that actually modified that introduced or last updated those comments. Agreed. I am usually taking typo fixes through trivial.git, as they might potentially help someone who is grepping around the sources and hoping to actually find something :) But just reformatting long lines in comments is just not worth it at all. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: qemu-kvm hangs at start up under 3.8.0-rc3-00074-gb719f43 (works with CONFIG_LOCKDEP)
On Tue, 15 Jan 2013, Andrew Clayton wrote:
bashS 88013b2b0d00 0 3203 3133 0x
880114dabe58 0082 800113558065
880114dabfd8 880114dabfd8 4000 88013b0c5b00
88013b2b0d00 880114dabd88 8109067d ea0004536670
ea0004536640 Call Trace:
[8109067d] ? default_wake_function+0xd/0x10
[8108a315] ? atomic_notifier_call_chain+0x15/0x20
[8133d84f] ? tty_get_pgrp+0x3f/0x50
[810819ac] ? pid_vnr+0x2c/0x30
[8133fe54] ? tty_ioctl+0x7b4/0xbd0
[8106bf62] ? wait_consider_task+0x102/0xaf0
[815c00e4] schedule+0x24/0x70
[8106cb24] do_wait+0x1d4/0x200
[8106d9cb] sys_wait4+0x9b/0xf0
[8106b9f0] ? task_stopped_code+0x50/0x50
[815c1ad2] system_call_fastpath+0x16/0x1b
qemu-kvmD 88011ab8c8b8 0 3345 3203 0x
880112129cd8 0082 880112129c50
880112129fd8 880112129fd8 4000 88013b04ce00
880139da1a00 000280da 880112129d38
810d3300 Call Trace:
[810d3300] ? __alloc_pages_nodemask+0xf0/0x7c0
[811273c6] ? touch_atime+0x66/0x170
[810cdabf] ? generic_file_aio_read+0x5bf/0x730
[815c00e4] schedule+0x24/0x70
[815c0cdd] rwsem_down_failed_common+0xbd/0x150
[815c0da3] rwsem_down_write_failed+0x13/0x15
[812d1be3] call_rwsem_down_write_failed+0x13/0x20
[815bf4dd] ? down_write+0x2d/0x34
[810f0724] vma_adjust+0xe4/0x610
[810f0fa4] vma_merge+0x1b4/0x270
[810f1fa6] do_brk+0x196/0x330
[810f2217] sys_brk+0xd7/0x130
[815c1ad2] system_call_fastpath+0x16/0x1b
This looks like qemu-kvm getting stuck trying to get the anon_vma
lock.
That leads to the obvious question: what is holding the lock, and/or
failed to release it?
Do you have any other (qemu-kvm?) processes on your system that have
any code in the VM (or strace/ptrace/...) in the backtrace, that might
be holding this lock?
I don't think so. The above was done having just logged into
gnome-shell and opened up a couple of gnome-terminals.
Do you have anything in your dmesg showing threads that had a BUG_ON
(and exited) while holding the lock?
I never noticed anything like that.
The interesting thing is that if I use basically the same kernel but
with CONFIG_LOCKDEP enabled, it works fine.
Thorough and careful review and analysis revealed that the rootcause very
likely is that I am a complete nitwit.
Could you please try the patch below and report backt? Thanks.
From: Jiri Kosina jkos...@suse.cz
Subject: [PATCH] lockdep, rwsem: fix down_write_nest_lock() if
!CONFIG_DEBUG_LOCK_ALLOC
Commit 1b963c81b1 (lockdep, rwsem: provide down_write_nest_lock())
contains a bug in a codepath when CONFIG_DEBUG_LOCK_ALLOC is disabled,
which causes down_read() to be called instead of down_write() by mistake
on such configurations. Fix that.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
include/linux/rwsem.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/linux/rwsem.h b/include/linux/rwsem.h
index 413cc11..8da67d6 100644
--- a/include/linux/rwsem.h
+++ b/include/linux/rwsem.h
@@ -135,7 +135,7 @@ do {
\
#else
# define down_read_nested(sem, subclass) down_read(sem)
-# define down_write_nest_lock(sem, nest_lock) down_read(sem)
+# define down_write_nest_lock(sem, nest_lock) down_write(sem)
# define down_write_nested(sem, subclass) down_write(sem)
#endif
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH]arch:x86:kvm:i8254.h Fix typo in kvm_pit
On Wed, 30 Mar 2011, Avi Kivity wrote:
The below patch changes base_addresss to base_address.
Note: I have grepped for base_addresss and nothing shows up,
grepping for base_address gets me lots of output, telling me that
this is a typo, but could be wrong.
Signed-off-by: Justin P. Mattockjustinmatt...@gmail.com
---
arch/x86/kvm/i8254.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kvm/i8254.h b/arch/x86/kvm/i8254.h
index 46d08ca..c2fa48b 100644
--- a/arch/x86/kvm/i8254.h
+++ b/arch/x86/kvm/i8254.h
@@ -33,7 +33,7 @@ struct kvm_kpit_state {
};
struct kvm_pit {
- unsigned long base_addresss;
+ unsigned long base_address;
struct kvm_io_device dev;
struct kvm_io_device speaker_dev;
struct kvm *kvm;
Why not remove the variable completely?
didnt even think to completely remove the variable(figured it was used
somewhere).I will look at that and resend with removal of the variable for
you..
Well if it was used, you ought to have changed all of the users, no?
I am afraid Justin is not trying to compile-test his patches (I got this
suspicion after last patchset trying to remove all the includes of
version.h).
--
Jiri Kosina
SUSE Labs, Novell Inc.
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM internal error. Suberror: 1 with ancient 2.4 kernel as guest
Hi, when migrating ancient machine to become KVM guest, I am facing a problem that KVM gives me the error below when being passed oldish vmlinuz image: === # qemu-kvm -kernel vmlinuz-2.4.33 KVM internal error. Suberror: 1 rax rbx 003e rcx rdx c1485180 rsi c00b8000 rdi c1485180 rsp c0305f70 rbp 0fa0 r8 r9 r10 r11 r12 r13 r14 r15 rip c027a841 rflags 0006 cs 0010 (/ p 1 dpl 0 db 1 s 1 type b l 0 g 1 avl 0) ds 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) es 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) ss 0018 (/bfff p 1 dpl 0 db 1 s 1 type 7 l 0 g 1 avl 0) fs 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) gs 0018 (/ p 1 dpl 0 db 1 s 1 type 3 l 0 g 1 avl 0) tr 0060 (c0301d80/00eb p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0068 (c0289020/0027 p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt c0288860/7f idt c0288000/7ff cr0 80050033 cr2 0 cr3 287000 cr4 90 cr8 0 efer 0 emulation failure, check dmesg for details === There is no message emitted in dmesg. The instructions around eip look reasonably valid from a quick look (this is monitor output from the time it crashes): === (qemu) x/5i $eip 0xc027a841: movq (%esi),%mm0 0xc027a844: movq 0x8(%esi),%mm1 0xc027a848: movq 0x10(%esi),%mm2 0xc027a84c: movq 0x18(%esi),%mm3 0xc027a850: movq %mm0,(%edx) === Is there any issue with emulating MMX? This is with 0.12.3 KVM module on 2.6.32. The kernel image which triggers this can be downloaded from http://www.jikos.cz/jikos/junk/vmlinuz-2.4.33 Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] KVM: x86: explain 'no-kvmclock' kernel parameter
no-kvmclock kernel parameter is missing its explanation in Documentation/kernel-parameters.txt. Add it. Signed-off-by: Jiri Kosina jkos...@suse.cz --- Documentation/kernel-parameters.txt |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 2c85c06..0f9e299 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1693,6 +1693,8 @@ and is between 256 and 4096 characters. It is defined in the file nojitter[IA64] Disables jitter checking for ITC timers. + no-kvmclock [X86,KVM] Disable paravirtualized KVM clock driver + nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH][RFC] x86: remove SMP check/taint for AMD K7 (was Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3)
On Wed, 31 Mar 2010, Andi Kleen wrote:
booting 32bit guest on 32bit host on AMD system gives me the following
warning when KVM is instructed to boot as SMP:
I guess these warnings could be just disabled. With nearly everyone
using multi-core these days they are kind of obsolete anyways.
Why is it there for K7 only anyway? Was that the only product line which
had instances which were explicitly marked as unsuitable for SMP by AMD?
From: Jiri Kosina jkos...@suse.cz
Subject: x86: remove SMP check/taint for AMD K7
Remove code checking of AMD K7 CPU models and warning/tainting kernel if
it doesn't suit given criteria.
The code has been there originally in order to detect systems which were
doing SMP with CPUs that were not oficially cerified by AMD as SMP-safe.
It's not clear whether the checks are either proper or complete. Quoting
Andi Kleen: I guess these warnings could be just disabled. With nearly
everyone using multi-core these days they are kind of obsolete anyways.
Signed-off-by: Jiri Kosina jkos...@suse.cz
---
arch/x86/kernel/cpu/amd.c | 51 -
1 files changed, 0 insertions(+), 51 deletions(-)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index e485825..6510fe5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -144,55 +144,6 @@ static void __cpuinit init_amd_k6(struct cpuinfo_x86 *c)
}
}
-static void __cpuinit amd_k7_smp_check(struct cpuinfo_x86 *c)
-{
-#ifdef CONFIG_SMP
- /* calling is from identify_secondary_cpu() ? */
- if (c-cpu_index == boot_cpu_id)
- return;
-
- /*
-* Certain Athlons might work (for various values of 'work') in SMP
-* but they are not certified as MP capable.
-*/
- /* Athlon 660/661 is valid. */
- if ((c-x86_model == 6) ((c-x86_mask == 0) ||
- (c-x86_mask == 1)))
- goto valid_k7;
-
- /* Duron 670 is valid */
- if ((c-x86_model == 7) (c-x86_mask == 0))
- goto valid_k7;
-
- /*
-* Athlon 662, Duron 671, and Athlon model 7 have capability
-* bit. It's worth noting that the A5 stepping (662) of some
-* Athlon XP's have the MP bit set.
-* See http://www.heise.de/newsticker/data/jow-18.10.01-000 for
-* more.
-*/
- if (((c-x86_model == 6) (c-x86_mask = 2)) ||
- ((c-x86_model == 7) (c-x86_mask = 1)) ||
-(c-x86_model 7))
- if (cpu_has_mp)
- goto valid_k7;
-
- /* If we get here, not a certified SMP capable AMD system. */
-
- /*
-* Don't taint if we are running SMP kernel on a single non-MP
-* approved Athlon
-*/
- WARN_ONCE(1, WARNING: This combination of AMD
-processors is not suitable for SMP.\n);
- if (!test_taint(TAINT_UNSAFE_SMP))
- add_taint(TAINT_UNSAFE_SMP);
-
-valid_k7:
- ;
-#endif
-}
-
static void __cpuinit init_amd_k7(struct cpuinfo_x86 *c)
{
u32 l, h;
@@ -228,8 +179,6 @@ static void __cpuinit init_amd_k7(struct cpuinfo_x86 *c)
}
set_cpu_cap(c, X86_FEATURE_K7);
-
- amd_k7_smp_check(c);
}
#endif
--
To unsubscribe from this list: send the line unsubscribe kvm in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
On Wed, 31 Mar 2010, Andre Przywara wrote: But the far better solution is to instruct QEMU/KVM to inject a better CPU model (as it was suggested by some people two weeks ago). I am about to test various guests with respect to their behavior regarding different family/model/stepping settings (one issue is already fixed). If this goes well, I will send out the patch to inject the host's CPUID F/M/S into the guest by default (which has other advantages, but denies migration mostly). BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. I just quickly checked ... [0.048001] Pid: 0, comm: swapper Not tainted (2.6.32.9-0.5-pae #1) Bochs [0.048001] EIP: 0060:[c0528a80] EFLAGS: 00010246 CPU: 0 [0.048001] EIP is at init_amd+0x249/0x279 [0.048001] EAX: EBX: ECX: 00a21000 EDX: [0.048001] ESI: c077de80 EDI: c077de98 EBP: c07e1a14 ESP: c0749f8c [0.048001] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 [0.048001] Process swapper (pid: 0, ti=c0748000 task=c074fca0 task.ti=c0748000) [0.048001] Stack: [0.048001] 00e8 c07b9720 c077de80 c077debc c077de98 c0527d74 [0.048001] 0 de816448 de816440 de840580 80d0 c07b9720 00099d00 [0.048001] 0 c074c000 00bfc003 c078822d c07882c8 c028e762 c07b9720 c0781a05 0062 [0.048001] Call Trace: [0.048001] [c0527d74] identify_cpu+0xc2/0x223 [0.048001] [c078822d] identify_boot_cpu+0xa/0x22 [0.048001] [c07882c8] check_bugs+0x8/0xd2 [0.048001] [c0781a05] start_kernel+0x32e/0x3a9 [0.048001] Code: 00 00 39 44 24 08 0f 96 c0 0f b6 d0 0f b7 86 b6 00 00 00 8b 0c 9d 80 e4 77 c0 8d 04 42 31 d2 66 89 44 0d 00 0f b7 86 b8 00 00 00 f7 74 24 08 66 89 96 b8 00 00 00 e9 77 fe ff ff 66 c7 05 00 1d [0.048001] EIP: [c0528a80] init_amd+0x249/0x279 SS:ESP 0068:c0749f8c [0.116025] ---[ end trace 4eaa2a86a8e2da22 ]--- [0.117661] Kernel panic - not syncing: Attempted to kill the idle task! [0.120008] Pid: 0, comm: swapper Tainted: G D 2.6.32.9-0.5-pae #1 [0.122115] Call Trace: [0.124032] [c02069a1] try_stack_unwind+0x1b1/0x1f0 [0.125821] [c020596f] dump_trace+0x3f/0xe0 [0.132019] [c02065ab] show_trace_log_lvl+0x4b/0x60 [0.136012] [c02065d8] show_trace+0x18/0x20 [0.137572] [c052dc19] dump_stack+0x6d/0x74 [0.139120] [c052dc62] panic+0x42/0x145 [0.140018] [c0242936] do_exit+0x236/0x310 [0.141550] [c0531063] oops_end+0xc3/0xd0 [0.144012] [c020455c] do_divide_error+0x7c/0x90 [0.145643] [c05304ee] error_code+0x66/0x6c [0.147235] [c0528a80] init_amd+0x249/0x279 [0.148011] [c0527d74] identify_cpu+0xc2/0x223 [0.149649] [c078822d] identify_boot_cpu+0xa/0x22 [0.152010] [c07882c8] check_bugs+0x8/0xd2 [0.153573] [c0781a05] start_kernel+0x32e/0x3a9 But I admit that this isn't the most up-to-date version, so perhaps it's already fixed ... -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
On Wed, 31 Mar 2010, Andre Przywara wrote: BTW.: I encourage people to test their KVM guests with -cpu host (on newer QEMUs) and send me any crash logs. I just quickly checked ... snip [0.147235] [c0528a80] init_amd+0x249/0x279 [0.148011] [c0527d74] identify_cpu+0xc2/0x223 [0.149649] [c078822d] identify_boot_cpu+0xa/0x22 [0.152010] [c07882c8] check_bugs+0x8/0xd2 [0.153573] [c0781a05] start_kernel+0x32e/0x3a9 But I admit that this isn't the most up-to-date version, so perhaps it's already fixed ... No, that is something new. I dug out the kernel (SLES 11.1?) and booted with my script, it crashed on FMS 16/9/0, so I guess this machine was a Magny-Cours, right? Yup, it's cpu family 10h. Anyway, many thanks for the report, I will investigate this. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
KVM warning about uncertified CPU for SMP for AMD model 2, stepping 3
Hi, booting 32bit guest on 32bit host on AMD system gives me the following warning when KVM is instructed to boot as SMP: CPU0: AMD QEMU Virtual CPU version 0.9.1 stepping 03 Booting Node 0, Processors #1 Initializing CPU#1 Leaving ESR disabled. Mapping cpu 1 to node 0 [ cut here ] WARNING: at linux-2.6.32/arch/x86/kernel/cpu/amd.c:187 init_amd_k7+0x178/0x187() Hardware name: WARNING: This combination of AMD processors is not suitable for SMP. Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.32.9-0.5-pae #1 Call Trace: [c02069a1] try_stack_unwind+0x1b1/0x1f0 [c020596f] dump_trace+0x3f/0xe0 [c02065ab] show_trace_log_lvl+0x4b/0x60 [c02065d8] show_trace+0x18/0x20 [c052dc19] dump_stack+0x6d/0x74 [c023ebbf] warn_slowpath_common+0x6f/0xd0 [c023ec6b] warn_slowpath_fmt+0x2b/0x30 [c052875c] init_amd_k7+0x178/0x187 [c052896f] init_amd+0x138/0x279 [c0527d74] identify_cpu+0xc2/0x223 [c0527ee1] identify_secondary_cpu+0xc/0x1a [c052b3bc] smp_callin+0xd4/0x1a1 [c052b493] start_secondary+0xa/0xe7 The virtual CPU identifies itself as cpu family 6, model 2, stepping 3 in /proc/cpuinfo. Model 2 is indeed not handled by amd_k7_smp_check() and thus this warning is spit out. Is that correct? Model 2 refers to Pluto/Orion (K75) if I remember correctly, right? That one is not oficially certified for SMP by AMD? If it is not, maybe KVM should better emulate different CPU for SMP-enabled configurations, right? On the other hand, if it is certified (I have no idea), amd_k7_smp_check() should handle this model properly. Thanks, -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334
On Wed, 4 Jun 2008, Thomas Gleixner wrote: OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the resume path. The original bug-report is on http://lkml.org/lkml/2008/4/7/130 sysdev_resume() is supposed to run with interrupts disabled, at least it was that way when the timekeeping_resume code was written. True. However in Zdenek's case, interrupts/preemption gets enabled somewhere during the resume, which correctly triggers the warning. Thanks, -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334
[ re-introduced LKML to CC, and also added KVM CCs] On Tue, 3 Jun 2008, Zdenek Kabelac wrote: 2008/6/3 Jiri Kosina [EMAIL PROTECTED]: On Tue, 3 Jun 2008, Zdenek Kabelac wrote: Another backtrace from suspend code path: (T61, 2GB, C2D, no SD card) kernel from git 20080603, commit 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 agpgart-intel :00:00.0: LATE suspend platform bay.0: LATE suspend platform dock.0: LATE suspend Extended CMOS year: 2000 hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] Back to C! BUG: using smp_processor_id() in preemptible [] code: pm-suspend/17334 caller is do_machine_check+0xa9/0x500 Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 Call Trace: [8118347c] debug_smp_processor_id+0xcc/0xd0 [810184d9] do_machine_check+0xa9/0x500 [81010e7b] ? init_8259A+0x1b/0x120 [810189d6] mce_init+0x56/0xf0 [81018a7b] mce_resume+0xb/0x10 [81204fd0] __sysdev_resume+0x20/0x60 [81205068] sysdev_resume+0x58/0x90 [8120aac9] device_power_up+0x9/0x10 [8106f4f7] suspend_devices_and_enter+0x147/0x1a0 [8106f6c6] enter_state+0x146/0x1d0 [8106f80a] state_store+0xba/0x100 [81177ae7] kobj_attr_store+0x17/0x20 [81110fea] sysfs_write_file+0xca/0x140 [810ba00b] vfs_write+0xcb/0x190 [810ba1c0] sys_write+0x50/0x90 [8100c4fb] system_call_after_swapgs+0x7b/0x80 This looks very much like the oops you reported here: http://lkml.org/lkml/2008/4/7/130 Is this also a virtual machine run under KVM, as it has been in the aforementioned thread? Ahh yes - you are right , I've completely forget about that old post - I've thought that my post are usually getting fixed sooner :) So yes - this is actually the same bug which is still not fixed within the latest kernel - the machine is running qemu guest (which seems to me now somehow also slower) OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the resume path. The original bug-report is on http://lkml.org/lkml/2008/4/7/130 -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe kvm in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
