Re: [kbuild-all] [PATCH 5/6] KVM: PPC: Book3S HV: Send IPI to host core to wake VCPU
Hi Suresh,
Sorry for the noise!
Do you have a git tree that the robot can monitor and test?
In this case of one patchset depending on another, there is no chance
for the robot to do valid testing based on emailed patches.
Thanks,
Fengguang
On Fri, Oct 30, 2015 at 10:16:06AM -0500, Suresh E. Warrier wrote:
> This patch set depends upon a previous patch set that I had submitted to
> linux-ppc. The URL for that is:
>
> https://lists.ozlabs.org/pipermail/linuxppc-dev/2015-October/135794.html
>
> -suresh
>
> On 10/29/2015 11:52 PM, kbuild test robot wrote:
> > Hi Suresh,
> >
> > [auto build test ERROR on kvm/linux-next -- if it's inappropriate base,
> > please suggest rules for selecting the more suitable base]
> >
> > url:
> > https://github.com/0day-ci/linux/commits/Suresh-Warrier/KVM-PPC-Book3S-HV-Optimize-wakeup-VCPU-from-H_IPI/20151030-081329
> > config: powerpc-defconfig (attached as .config)
> > reproduce:
> > wget
> > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
> > -O ~/bin/make.cross
> > chmod +x ~/bin/make.cross
> > # save the attached .config to linux build tree
> > make.cross ARCH=powerpc
> >
> > All errors (new ones prefixed by >>):
> >
> >arch/powerpc/kvm/book3s_hv_rm_xics.c: In function 'icp_rm_set_vcpu_irq':
> >>> arch/powerpc/kvm/book3s_hv_rm_xics.c:142:4: error: implicit declaration
> >>> of function 'smp_muxed_ipi_rm_message_pass'
> >>> [-Werror=implicit-function-declaration]
> >smp_muxed_ipi_rm_message_pass(hcpu,
> >^
> >arch/powerpc/kvm/book3s_hv_rm_xics.c:143:7: error:
> > 'PPC_MSG_RM_HOST_ACTION' undeclared (first use in this function)
> > PPC_MSG_RM_HOST_ACTION);
> > ^
> >arch/powerpc/kvm/book3s_hv_rm_xics.c:143:7: note: each undeclared
> > identifier is reported only once for each function it appears in
> >cc1: all warnings being treated as errors
> >
> > vim +/smp_muxed_ipi_rm_message_pass +142
> > arch/powerpc/kvm/book3s_hv_rm_xics.c
> >
> >136 hcore = -1;
> >137 if (kvmppc_host_rm_ops_hv)
> >138 hcore =
> > find_available_hostcore(XICS_RM_KICK_VCPU);
> >139 if (hcore != -1) {
> >140 hcpu = hcore << threads_shift;
> >141
> > kvmppc_host_rm_ops_hv->rm_core[hcore].rm_data = vcpu;
> > > 142 smp_muxed_ipi_rm_message_pass(hcpu,
> >143
> > PPC_MSG_RM_HOST_ACTION);
> >144 } else {
> >145 this_icp->rm_action |=
> > XICS_RM_KICK_VCPU;
> >
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology
> > Center
> > https://lists.01.org/pipermail/kbuild-all Intel
> > Corporation
> >
>
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
--
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: [kbuild-all] [kvm:queue 27/38] arch/x86/kvm/hyperv.c:186:41: sparse: incorrect type in argument 2 (different modifiers)
[CC sparse people]
On Fri, Sep 18, 2015 at 04:41:56PM +0200, Paolo Bonzini wrote:
>
>
> On 18/09/2015 16:40, Roman Kagan wrote:
> > typedef unsigned long __nocast cputime_t;
> >
> > extern void task_cputime_adjusted(cputime_t *);
> > extern void current_task_runtime_100ns(void);
> >
> > void current_task_runtime_100ns(void)
> > {
> > cputime_t utime;
> >
> > task_cputime_adjusted();
> > }
> > %%% gcc -c x.c -Wall -Werror -O2; echo $?
> > 0
> > %%% sparse x.c
> > x.c:16:32: warning: incorrect type in argument 1 (different modifiers)
> > x.c:16:32:expected unsigned long [nocast] [usertype] *
> > x.c:16:32:got unsigned long *
> > x.c:16:32: warning: implicit cast to nocast type
> >
> > Looks like a sparse bug to me.
>
> Indeed...
>
> Paolo
> ___
> kbuild-all mailing list
> kbuild-...@lists.01.org
> https://lists.01.org/mailman/listinfo/kbuild-all
--
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
[x86, kvm] WARNING: at arch/x86/kernel/pvclock.c:182 pvclock_init_vsyscall()
Greetings, 0day kernel testing robot got the below dmesg and the first bad commit is commit 3dc4f7cfb7441e5e0fed3a02fc81cdaabd28300a Author: Marcelo Tosatti mtosa...@redhat.com AuthorDate: Tue Nov 27 23:28:56 2012 -0200 Commit: Marcelo Tosatti mtosa...@redhat.com CommitDate: Tue Nov 27 23:29:10 2012 -0200 x86: kvm guest: pvclock vsyscall support Hook into generic pvclock vsyscall code, with the aim to allow userspace to have visibility into pvclock data. Signed-off-by: Marcelo Tosatti mtosa...@redhat.com +--++++ | | 71056ae22d | 3dc4f7cfb7 | d778df51c0 | +--++++ | boot_successes | 141| 0 | 0 | | boot_failures| 0 | 47 | 11 | | WARNING:at_arch/x86/kernel/pvclock.c:pvclock_init_vsyscall() | 0 | 47 | 11 | | backtrace:pvclock_init_vsyscall | 0 | 47 | 11 | | backtrace:warn_slowpath_null | 0 | 47 | 11 | | backtrace:kvm_setup_vsyscall_timeinfo| 0 | 47 | 11 | | backtrace:kvm_guest_init | 0 | 47 | 11 | | Kernel_panic-not_syncing:Attempted_to_kill_init_exitcode=| 0 | 0 | 7 | | BUG:kernel_boot_hang | 0 | 0 | 4 | +--++++ [0.00] mapped IOAPIC to ff5f9000 (fec0) [0.00] nr_irqs_gsi: 40 [0.00] [ cut here ] [0.00] WARNING: at arch/x86/kernel/pvclock.c:182 pvclock_init_vsyscall+0x41/0x8e() [0.00] Hardware name: Standard PC (i440FX + PIIX, 1996) [0.00] Modules linked in: [0.00] Pid: 0, comm: swapper Not tainted 3.7.0-rc3-00112-g3dc4f7c #1 [0.00] Call Trace: [0.00] [8104f750] warn_slowpath_common+0x70/0xa0 [0.00] [8104f83a] warn_slowpath_null+0x1a/0x20 [0.00] [8219a6af] pvclock_init_vsyscall+0x41/0x8e [0.00] [8219a623] kvm_setup_vsyscall_timeinfo+0x48/0x78 [0.00] [8219a397] kvm_guest_init+0x98/0xe1 [0.00] [82190eb8] setup_arch+0xa9b/0xb10 [0.00] [818eeae8] ? printk+0x4f/0x57 [0.00] [8218e856] start_kernel+0x93/0x388 [0.00] [8218e120] ? early_idt_handlers+0x120/0x120 [0.00] [8218e2b4] x86_64_start_reservations+0xb0/0xb3 [0.00] [8218e3b9] x86_64_start_kernel+0x102/0x10f [0.00] ---[ end trace c9f7d63dd24af7e7 ]--- [0.00] KVM setup async PF for cpu 0 git bisect start v3.8 v3.7 -- git bisect bad 8d91a42e54eebc43f4d8f6064751ccba73528275 # 21:30 0- 5 Merge tag 'omap-late-cleanups' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc git bisect bad 770b6cb4d21fb3e3df2a7a51e186a3c14db1ec30 # 21:35 0- 1 ARM: OMAP: Fix drivers to depend on omap for internal devices git bisect good 9977d9b379cb77e0f67bd6f4563618106e58e11d # 21:40 30+ 0 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/signal git bisect bad e777d192ffb9f2929d547a2f8a5f65b7db7a9552 # 21:44 4- 26 Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi git bisect good 8b0cab14951fbf8126795ab301835a8f8126a988 # 22:00 30+ 0 Merge tag 'regulator-3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator git bisect good c7708fac5a878d6e0f2de0aa19f9749cff4f707f # 22:11 30+ 0 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux git bisect bad e05a1c6397a73d09389e033b6b2c25c954d2177c # 22:17 0- 1 Merge tag 'ktest-v3.8' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest git bisect good 896ea17d3da5f44b2625c9cda9874d7dfe447393 # 22:36 30+ 0 Merge tag 'stable/for-linus-3.8-rc0-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen git bisect bad 66cdd0ceaf65a18996f561b770eedde1d123b019 # 22:41 3- 3 Merge tag 'kvm-3.8-1' of git://git.kernel.org/pub/scm/virt/kvm/kvm git bisect good 8455d79e2163997e479931b8d5b7e60a92cd2b86 # 23:04 30+ 0 KVM: PPC: Book3S HV: Run virtual core whenever any vcpus in it can run git bisect bad 78c634402a1825f1f5bef13077f0985f3b8a3212 # 23:11 3- 23 kvm: deliver msi interrupts from irq handler git bisect good
Re: [x86, kvm] WARNING: at arch/x86/kernel/pvclock.c:182 pvclock_init_vsyscall()
On Tue, Sep 30, 2014 at 02:05:09PM +0200, Paolo Bonzini wrote: Il 30/09/2014 09:59, Fengguang Wu ha scritto: +--++++ | | 71056ae22d | 3dc4f7cfb7 | d778df51c0 | +--++++ | boot_successes | 141 | 0 | 0 | | boot_failures| 0 | 47 | 11 | | WARNING:at_arch/x86/kernel/pvclock.c:pvclock_init_vsyscall() | 0 | 47 | 11 | | backtrace:pvclock_init_vsyscall | 0 | 47 | 11 | | backtrace:warn_slowpath_null | 0 | 47 | 11 | | backtrace:kvm_setup_vsyscall_timeinfo| 0 | 47 | 11 | | backtrace:kvm_guest_init | 0 | 47 | 11 | | Kernel_panic-not_syncing:Attempted_to_kill_init_exitcode=| 0 | 0 | 7 | | BUG:kernel_boot_hang | 0 | 0 | 4 | +--++++ Can I get the randconfig that was used? Sure, attached. Sorry forgot attaching it! Thanks, Fengguang # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.7.0 Kernel Configuration # CONFIG_64BIT=y CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set CONFIG_KERNEL_LZO=y CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_FHANDLE=y CONFIG_AUDIT=y # CONFIG_AUDITSYSCALL is not set # CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_DOMAIN_DEBUG=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y # CONFIG_HIGH_RES_TIMERS is not set # # CPU/Task time and stats accounting # # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_IRQ_TIME_ACCOUNTING=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set CONFIG_TASKSTATS=y # CONFIG_TASK_DELAY_ACCT is not set CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y CONFIG_CGROUP_DEBUG=y CONFIG_CGROUP_FREEZER=y # CONFIG_CGROUP_DEVICE is not set CONFIG_CPUSETS=y # CONFIG_PROC_PID_CPUSET is not set # CONFIG_CGROUP_CPUACCT is not set CONFIG_RESOURCE_COUNTERS=y CONFIG_MEMCG=y # CONFIG_MEMCG_SWAP is not set # CONFIG_CGROUP_PERF is not set # CONFIG_CGROUP_SCHED is not set # CONFIG_BLK_CGROUP is not set
Re: [kbuild] [vfio:vfio-vga 4/5] drivers/vfio/pci/vfio_pci_rdwr.c:191 vfio_pci_legacy_mem_rw() warn: consider using resource_size() here
Hi Dan and Alex, On Mon, Jan 21, 2013 at 09:17:51PM +0300, Dan Carpenter wrote: Hi Fengguang, I already forwarded these on Thursday. You should have got a mail about it because I CC'd the kbuild list. Yes it is! Sorry for the duplicated report! Fengguang -- 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: [kbuild] [vfio:vfio-vga 3/5] drivers/vfio/pci/vfio_pci_rdwr.c:169 vfio_pci_bar_rw() warn: always true condition '(done = 0) = (0-u32max = 0)'
On Wed, Jan 16, 2013 at 08:47:57PM -0700, Alex Williamson wrote: On Thu, 2013-01-17 at 09:21 +0800, Fengguang Wu wrote: Hi Alex, FYI, there are new smatch warnings show up in tree: git://github.com/awilliam/linux-vfio.git vfio-vga Thanks for the bug report. I never would have expected but reports from an unadvertised branch but it's a really cool service. Thanks for providing it! My pleasure! :) Thanks, Fengguang -- 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
[kbuild] [vfio:vfio-vga 4/5] drivers/vfio/pci/vfio_pci_rdwr.c:191 vfio_pci_legacy_mem_rw() warn: consider using resource_size() here
Hi Alex,
FYI, there are new smatch warnings show up in
tree: git://github.com/awilliam/linux-vfio.git vfio-vga
head: 2c2e21fa66c40ed7b8e434c86a9f2ab0c879f21d
commit: c5b7a5a85fa477e70497c513f2acda50eea73bf7 [4/5] vfio-pci: Add support
for legacy MMIO I/O port towards VGA support
New smatch warnings:
drivers/vfio/pci/vfio_pci_rdwr.c:191 vfio_pci_legacy_mem_rw() warn: consider
using resource_size() here
drivers/vfio/pci/vfio_pci_rdwr.c:206 vfio_pci_legacy_mem_rw() warn: always true
condition '(done = 0) = (0-u32max = 0)'
drivers/vfio/pci/vfio_pci_rdwr.c:254 vfio_pci_legacy_io_rw() warn: always true
condition '(done = 0) = (0-u32max = 0)'
Old smatch warnings:
drivers/vfio/pci/vfio_pci_rdwr.c:170 vfio_pci_bar_rw() warn: always true
condition '(done = 0) = (0-u32max = 0)'
vim +191 drivers/vfio/pci/vfio_pci_rdwr.c
c5b7a5a8 Alex Williamson 2013-01-16 185if (vdev-has_vga pos =
0xa pos 0xc) {
c5b7a5a8 Alex Williamson 2013-01-16 186void __iomem *mem;
c5b7a5a8 Alex Williamson 2013-01-16 187size_t done;
c5b7a5a8 Alex Williamson 2013-01-16 188
c5b7a5a8 Alex Williamson 2013-01-16 189count = min(count,
(size_t)(0xc - pos));
c5b7a5a8 Alex Williamson 2013-01-16 190
c5b7a5a8 Alex Williamson 2013-01-16 @191mem =
ioremap_nocache(0xa, 0xc - 0xa);
c5b7a5a8 Alex Williamson 2013-01-16 192if (!mem)
c5b7a5a8 Alex Williamson 2013-01-16 193return -ENOMEM;
c5b7a5a8 Alex Williamson 2013-01-16 194
c5b7a5a8 Alex Williamson 2013-01-16 195ret =
vga_get_interruptible(vdev-pdev, VGA_RSRC_LEGACY_MEM);
c5b7a5a8 Alex Williamson 2013-01-16 196if (ret) {
c5b7a5a8 Alex Williamson 2013-01-16 197iounmap(mem);
c5b7a5a8 Alex Williamson 2013-01-16 198return ret;
c5b7a5a8 Alex Williamson 2013-01-16 199}
c5b7a5a8 Alex Williamson 2013-01-16 200
c5b7a5a8 Alex Williamson 2013-01-16 201done = do_io_rw(mem,
buf, pos - 0xa, count, 0, 0, iswrite);
c5b7a5a8 Alex Williamson 2013-01-16 202
c5b7a5a8 Alex Williamson 2013-01-16 203vga_put(vdev-pdev,
VGA_RSRC_LEGACY_MEM);
c5b7a5a8 Alex Williamson 2013-01-16 204iounmap(mem);
c5b7a5a8 Alex Williamson 2013-01-16 205
c5b7a5a8 Alex Williamson 2013-01-16 @206if (done = 0)
c5b7a5a8 Alex Williamson 2013-01-16 207*ppos += done;
c5b7a5a8 Alex Williamson 2013-01-16 208
c5b7a5a8 Alex Williamson 2013-01-16 209return done;
c5b7a5a8 Alex Williamson 2013-01-16 210}
c5b7a5a8 Alex Williamson 2013-01-16 211
c5b7a5a8 Alex Williamson 2013-01-16 212return -EINVAL;
c5b7a5a8 Alex Williamson 2013-01-16 213 }
c5b7a5a8 Alex Williamson 2013-01-16 214
c5b7a5a8 Alex Williamson 2013-01-16 215 ssize_t vfio_pci_legacy_io_rw(struct
vfio_pci_device *vdev, char __user *buf,
c5b7a5a8 Alex Williamson 2013-01-16 216 size_t
count, loff_t *ppos, bool iswrite)
c5b7a5a8 Alex Williamson 2013-01-16 217 {
c5b7a5a8 Alex Williamson 2013-01-16 218int ret;
c5b7a5a8 Alex Williamson 2013-01-16 219loff_t pos = *ppos
VFIO_PCI_OFFSET_MASK;
c5b7a5a8 Alex Williamson 2013-01-16 220
c5b7a5a8 Alex Williamson 2013-01-16 221if (vdev-has_vga
c5b7a5a8 Alex Williamson 2013-01-16 222((pos = 0x3b0 pos
0x3bc) || (pos = 0x3c0 pos 0x3e0))) {
c5b7a5a8 Alex Williamson 2013-01-16 223void __iomem *io = NULL;
c5b7a5a8 Alex Williamson 2013-01-16 224loff_t off;
c5b7a5a8 Alex Williamson 2013-01-16 225size_t done;
c5b7a5a8 Alex Williamson 2013-01-16 226
c5b7a5a8 Alex Williamson 2013-01-16 227switch (pos) {
c5b7a5a8 Alex Williamson 2013-01-16 228case 0x3b0 ... 0x3bb:
c5b7a5a8 Alex Williamson 2013-01-16 229count =
min(count, (size_t)(0x3bc - pos));
c5b7a5a8 Alex Williamson 2013-01-16 230io =
ioport_map(0x3b0, 0x3bc - 0x3b0);
c5b7a5a8 Alex Williamson 2013-01-16 231off = pos -
0x3b0;
c5b7a5a8 Alex Williamson 2013-01-16 232break;
c5b7a5a8 Alex Williamson 2013-01-16 233case 0x3c0 ... 0x3df:
c5b7a5a8 Alex Williamson 2013-01-16 234count =
min(count, (size_t)(0x3e0 - pos));
c5b7a5a8 Alex Williamson 2013-01-16 235io =
ioport_map(0x3c0, 0x3e0 - 0x3c0);
c5b7a5a8 Alex Williamson 2013-01-16 236off = pos -
0x3c0;
c5b7a5a8 Alex Williamson 2013-01-16 237break;
c5b7a5a8 Alex Williamson 2013-01-16 238}
c5b7a5a8 Alex Williamson 2013-01-16 239
c5b7a5a8 Alex Williamson 2013-01-16 240if (!io)
c5b7a5a8 Alex Williamson 2013-01-16 241return
[kbuild] [vfio:vfio-vga 3/5] drivers/vfio/pci/vfio_pci_rdwr.c:169 vfio_pci_bar_rw() warn: always true condition '(done = 0) = (0-u32max = 0)'
Hi Alex,
FYI, there are new smatch warnings show up in
tree: git://github.com/awilliam/linux-vfio.git vfio-vga
head: 2c2e21fa66c40ed7b8e434c86a9f2ab0c879f21d
commit: f4d38f216ef420595d12f74b256b3961eb4c3c14 [3/5] vfio-pci: Cleanup BAR
access
New smatch warnings:
drivers/vfio/pci/vfio_pci_rdwr.c:169 vfio_pci_bar_rw() warn: always true
condition '(done = 0) = (0-u32max = 0)'
vim +169 drivers/vfio/pci/vfio_pci_rdwr.c
f4d38f21 Alex Williamson 2013-01-16 153if (!io) {
f4d38f21 Alex Williamson 2013-01-16 154
pci_release_selected_regions(pdev, 1 bar);
f4d38f21 Alex Williamson 2013-01-16 155return -ENOMEM;
89e1f7d4 Alex Williamson 2012-07-31 156}
89e1f7d4 Alex Williamson 2012-07-31 157
f4d38f21 Alex Williamson 2013-01-16 158vdev-barmap[bar] = io;
f4d38f21 Alex Williamson 2013-01-16 159} else
89e1f7d4 Alex Williamson 2012-07-31 160io = vdev-barmap[bar];
89e1f7d4 Alex Williamson 2012-07-31 161
f4d38f21 Alex Williamson 2013-01-16 162if (bar == vdev-msix_bar) {
f4d38f21 Alex Williamson 2013-01-16 163x_start =
vdev-msix_offset;
f4d38f21 Alex Williamson 2013-01-16 164x_end =
vdev-msix_offset + vdev-msix_size;
89e1f7d4 Alex Williamson 2012-07-31 165}
89e1f7d4 Alex Williamson 2012-07-31 166
f4d38f21 Alex Williamson 2013-01-16 167done = do_io_rw(io, buf, pos,
count, x_start, x_end, iswrite);
89e1f7d4 Alex Williamson 2012-07-31 168
f4d38f21 Alex Williamson 2013-01-16 @169if (done = 0)
f4d38f21 Alex Williamson 2013-01-16 170*ppos += done;
89e1f7d4 Alex Williamson 2012-07-31 171
89e1f7d4 Alex Williamson 2012-07-31 172if (bar == PCI_ROM_RESOURCE)
89e1f7d4 Alex Williamson 2012-07-31 173pci_unmap_rom(pdev, io);
89e1f7d4 Alex Williamson 2012-07-31 174
f4d38f21 Alex Williamson 2013-01-16 175return done;
89e1f7d4 Alex Williamson 2012-07-31 176 }
---
0-DAY kernel build testing backend Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
___
kbuild mailing list
kbu...@lists.01.org
https://lists.01.org/mailman/listinfo/kbuild
--
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:queue 23/25] arch/s390/kvm/kvm-s390.c:358:6: error: conflicting types for 'kvm_arch_vcpu_postcreate'
On Tue, Nov 27, 2012 at 11:51:19PM -0200, Marcelo Tosatti wrote: On Tue, Nov 27, 2012 at 10:56:50AM +0800, Fengguang Wu wrote: Hi Marcelo, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue head: fc1ddea318fa2c1ac3d496d8653ca4bc9b66e679 commit: 438d76a60e7be59a558f8712a47565fa8258d17d [23/25] KVM: x86: add kvm_arch_vcpu_postcreate callback, move TSC initialization config: make ARCH=s390 allmodconfig Fengguang Wu, Thanks. Repository has been updated, it would be good if you can rerun the tests. Marcelo, the build log shows that the new kvm/queue head d98d07ca7e0347d712d54a865af323c4aee04bc2 builds fine. :) Thanks, Fengguang -- 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:queue 23/25] arch/s390/kvm/kvm-s390.c:358:6: error: conflicting types for 'kvm_arch_vcpu_postcreate'
Hi Marcelo,
FYI, kernel build failed on
tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head: fc1ddea318fa2c1ac3d496d8653ca4bc9b66e679
commit: 438d76a60e7be59a558f8712a47565fa8258d17d [23/25] KVM: x86: add
kvm_arch_vcpu_postcreate callback, move TSC initialization
config: make ARCH=s390 allmodconfig
All error/warnings:
arch/s390/kvm/kvm-s390.c:358:6: error: conflicting types for
'kvm_arch_vcpu_postcreate'
In file included from arch/s390/kvm/kvm-s390.c:22:0:
include/linux/kvm_host.h:599:5: note: previous declaration of
'kvm_arch_vcpu_postcreate' was here
arch/s390/kvm/kvm-s390.c: In function 'kvm_arch_vcpu_postcreate':
arch/s390/kvm/kvm-s390.c:360:2: warning: 'return' with a value, in function
returning void [enabled by default]
vim +358 +/kvm_arch_vcpu_postcreate arch/s390/kvm/kvm-s390.c
b0c632db Heiko Carstens2008-03-25 352
vcpu-arch.guest_fpregs.fpc = 0;
b0c632db Heiko Carstens2008-03-25 353 asm volatile(lfpc %0
: : Q (vcpu-arch.guest_fpregs.fpc));
b0c632db Heiko Carstens2008-03-25 354
vcpu-arch.sie_block-gbea = 1;
61bde82c Christian Borntraeger 2012-06-11 355
atomic_set_mask(CPUSTAT_STOPPED, vcpu-arch.sie_block-cpuflags);
b0c632db Heiko Carstens2008-03-25 356 }
b0c632db Heiko Carstens2008-03-25 357
438d76a6 Marcelo Tosatti 2012-11-19 @358 void
kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu)
438d76a6 Marcelo Tosatti 2012-11-19 359 {
438d76a6 Marcelo Tosatti 2012-11-19 @360 return 0;
438d76a6 Marcelo Tosatti 2012-11-19 361 }
438d76a6 Marcelo Tosatti 2012-11-19 362
b0c632db Heiko Carstens2008-03-25 363 int kvm_arch_vcpu_setup(struct
kvm_vcpu *vcpu)
---
0-DAY kernel build testing backend Open Source Technology Center
Fengguang Wu, Yuanhan Liu Intel Corporation
--
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: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)
On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: On 09/14/2012 01:57 PM, Xiao Guangrong wrote: On 09/12/2012 04:15 PM, Avi Kivity wrote: On 09/12/2012 07:40 AM, Fengguang Wu wrote: Hi, 3 of my test boxes running v3.5 kernel become unaccessible and I find two of them kept emitting this dmesg: vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit reason is 0x31 The other one has froze and the above lines are the last dmesg. Any ideas? First, that printk should be rate-limited. Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to if ((vectoring_info VECTORING_INFO_VALID_MASK) (exit_reason != EXIT_REASON_EXCEPTION_NMI exit_reason != EXIT_REASON_EPT_VIOLATION exit_reason != EXIT_REASON_TASK_SWITCH)) printk(KERN_WARNING %s: unexpected, valid vectoring info (0x%x) and exit reason is 0x%x\n, __func__, vectoring_info, exit_reason); since it's easily caused by the guest. Yes, i will do these. Third, it's really unexpected. It seems the guest was attempting to deliver a page fault exception (0x0e) but encountered an mmio page during delivery (in the IDT, TSS, stack, or page tables). Is this reproducible? If so it's easy to patch kvm to halt in that case and allow examining the guest via qemu. Have no idea yet why the box was frozen under this case, will try to write a test case, hope it can help me to find the reason out. Still did not know why linux kernel triggered it. I have posted a patchset to report an internal error for this case, hoping Fengguang can reproduce it after the patchset and Qemu's dump can help us to find the reason out. I will keep working on it. Thanks! Shall I run some patched kernel, or just 3.6.0? Another problem I sometimes run into is, dmesg no longer works in the test boxes that run lots of KVMs. It aborts with an error message: dmesg: klogctl failed: Bad address Thanks, Fengguang -- 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: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)
On Wed, Oct 17, 2012 at 03:04:49PM +0800, Xiao Guangrong wrote: On 10/17/2012 02:43 PM, Fengguang Wu wrote: On Wed, Oct 17, 2012 at 02:26:22PM +0800, Xiao Guangrong wrote: On 09/14/2012 01:57 PM, Xiao Guangrong wrote: On 09/12/2012 04:15 PM, Avi Kivity wrote: On 09/12/2012 07:40 AM, Fengguang Wu wrote: Hi, 3 of my test boxes running v3.5 kernel become unaccessible and I find two of them kept emitting this dmesg: vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit reason is 0x31 The other one has froze and the above lines are the last dmesg. Any ideas? First, that printk should be rate-limited. Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to if ((vectoring_info VECTORING_INFO_VALID_MASK) (exit_reason != EXIT_REASON_EXCEPTION_NMI exit_reason != EXIT_REASON_EPT_VIOLATION exit_reason != EXIT_REASON_TASK_SWITCH)) printk(KERN_WARNING %s: unexpected, valid vectoring info (0x%x) and exit reason is 0x%x\n, __func__, vectoring_info, exit_reason); since it's easily caused by the guest. Yes, i will do these. Third, it's really unexpected. It seems the guest was attempting to deliver a page fault exception (0x0e) but encountered an mmio page during delivery (in the IDT, TSS, stack, or page tables). Is this reproducible? If so it's easy to patch kvm to halt in that case and allow examining the guest via qemu. Have no idea yet why the box was frozen under this case, will try to write a test case, hope it can help me to find the reason out. Still did not know why linux kernel triggered it. I have posted a patchset to report an internal error for this case, hoping Fengguang can reproduce it after the patchset and Qemu's dump can help us to find the reason out. I will keep working on it. Thanks! Shall I run some patched kernel, or just 3.6.0? The patchset is under review. Can be found at: https://lkml.org/lkml/2012/10/17/31 Thanks, I'll try it. Thanks, Fengguang -- 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: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)
On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote: On 09/28/2012 05:35 AM, Paul E. McKenney wrote: On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote: On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote: On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote: On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote: On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote: [ . . . ] But could you also please send your .config file and a description of .config attached. the workload you are running? It's basically the below commands. The exact initrd is not relevant in this case because it's a boot time warning before user space is started. The stalls roughly happen 1 time on every 10 boots. Yow!!! You have severe cross-CPU time-synchronization problems. See for example the first dmesg, with the relevant part extracted right here. One CPU believes that it is about 37 seconds past boot, and the other CPU beleives that it is about 137 seconds past boot. Given that large of a time difference, an RCU CPU stall warning is expected behavior. Good spot! Yeah I noticed that huge timestamp gap, however didn't take it seriously enough.. Get your two CPUs in agreement about what time it is, and I bet that the CPU stall warnings will go away. Possibly KVM related? Because the warnings show up in many test boxes running KVM and so is not likely some hardware specific issue. I vaguely recall seeing something recently. But let's ask the KVM and timekeeping guys. From the logs it looks like hpet (why not kvmclock?) is used for the Hi Avi! Thanks for looking into this. It seems you have the full logs attached in my previous email? FYI, I've enabled CONFIG_KVM_CLOCK/CONFIG_KVM_GUEST for all bootable kernels and here is the related boot message: [0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00 [0.00] kvm-clock: cpu 0, msr 0:1b7ec81, boot clock clock, it should not generate such drifts since it is a global clock. Can you verify current_clocksource on a boot that actually failed (in case the clocksource is switched during runtime)? I see a line [2.011710] Switching to clocksource kvm-clock w/o any indication of errors. Thanks, Fengguang -- 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: INFO: rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=10002 jiffies)
On Sun, Sep 30, 2012 at 01:32:46PM +0200, Avi Kivity wrote:
On 09/30/2012 01:23 PM, Fengguang Wu wrote:
On Sun, Sep 30, 2012 at 01:10:55PM +0200, Avi Kivity wrote:
On 09/28/2012 05:35 AM, Paul E. McKenney wrote:
On Thu, Sep 27, 2012 at 12:40:44PM +0800, Fengguang Wu wrote:
On Wed, Sep 26, 2012 at 09:28:50PM -0700, Paul E. McKenney wrote:
On Thu, Sep 27, 2012 at 10:54:00AM +0800, Fengguang Wu wrote:
On Wed, Sep 26, 2012 at 09:45:43AM -0700, Paul E. McKenney wrote:
On Wed, Sep 26, 2012 at 04:15:01PM +0800, Fengguang Wu wrote:
[ . . . ]
But could you also please send your .config file and a
description of
.config attached.
the workload you are running?
It's basically the below commands. The exact initrd is not relevant
in
this case because it's a boot time warning before user space is
started. The stalls roughly happen 1 time on every 10 boots.
Yow!!!
You have severe cross-CPU time-synchronization problems. See for
example the first dmesg, with the relevant part extracted right here.
One CPU believes that it is about 37 seconds past boot, and the other
CPU beleives that it is about 137 seconds past boot. Given that large
of a time difference, an RCU CPU stall warning is expected behavior.
Good spot! Yeah I noticed that huge timestamp gap, however didn't take
it seriously enough..
Get your two CPUs in agreement about what time it is, and I bet that
the CPU stall warnings will go away.
Possibly KVM related? Because the warnings show up in many test boxes
running KVM and so is not likely some hardware specific issue.
I vaguely recall seeing something recently. But let's ask the KVM and
timekeeping guys.
From the logs it looks like hpet (why not kvmclock?) is used for the
clock, it should not generate such drifts since it is a global clock.
Can you verify current_clocksource on a boot that actually failed (in
case the clocksource is switched during runtime)?
I've checked out the dmesg that's cited by Paul, attached. Yes it
contains lines
[4.970051] Switching to clocksource hpet
and then
[7.250353] Switching to clocksource tsc
And there is no kvm-clock lines. Oh well for this particular kernel:
Ah, tsc will certainly break on kvm if the hardware doesn't provide a
constant tsc source. I'm surprised the guest kernel didn't detect it
and switch back to hpet though.
Thanks, it's good to know the root cause. All the dmesgs show the same hpet+tsc
switching pattern (and never switch back):
$ grep Switching dmesg-kvm_bisect2-inn-*21
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.111415] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-37-51-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.550098] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.927716] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-41931-2012-09-27-10-41-48-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.030117] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
3.587408] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-35-17-3.6.0-rc7-bisect2-00078-g593d100-21:[
5.812400] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.294842] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-43-56-3.6.0-rc7-bisect2-00078-g593d100-21:[
6.491696] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.745749] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42322-2012-09-27-10-47-03-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.193121] Switching to clocksource tsc
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
4.970051] Switching to clocksource hpet
dmesg-kvm_bisect2-inn-42527-2012-09-27-10-38-38-3.6.0-rc7-bisect2-00078-g593d100-21:[
7.250353] Switching to clocksource tsc
And these are the stall times:
$ grep -hC1 stalls dmesg-kvm_bisect2-inn-*21
[ 36.122624] bus: 'platform': really_probe: probing driver i8042 with device
i8042
[ 36.106893] INFO: rcu_preempt self-detected stall on CPU[ 210.200388] INFO:
rcu_preempt detected stalls on CPUs/tasks: { 1} (detected by 0, t=17413 jiffies)
[ 210.200417] Pid: 0, comm: swapper/0 Not tainted
3.6.0-rc7-bisect2-00078-g593d100 #21
--
[ 35.403888] bus: 'platform': really_probe: probing driver i8042 with device
i8042
[ 212.130131] INFO: rcu_preempt detected stalls on CPUs/tasks:[ 212.131029]
rcu-torture: rtc: c1a5e988 ver: 228 tfle: 0 rta: 228 rtaf: 162 rtf: 206 rtmbe:
0 rtbke: 0 rtbre: 0 rtbf: 0 rtb: 0 nt: 988 onoff: 0/0:0/0 -1,0:-1,0 0:0
(HZ=100
[kvm:queue 41/42] arch/s390/kvm/interrupt.c:428:12: warning: ignoring return value of 'vcpu_load', declared with attribute warn_unused_result
Hi Michael,
FYI, there are new compile warnings show up in
tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git queue
head: 879238fecc051d95037ae76332916209a7770709
commit: 9fc77441e5e1bf80b794cc546d2243ee9f4afb75 [41/42] KVM: make processes
waiting on vcpu mutex killable
config: s390-defconfig
All error/warnings:
arch/s390/kvm/interrupt.c: In function 'kvm_s390_handle_wait':
arch/s390/kvm/interrupt.c:428:12: warning: ignoring return value of
'vcpu_load', declared with attribute warn_unused_result [-Wunused-result]
vim +428 arch/s390/kvm/interrupt.c
418 add_wait_queue(vcpu-arch.local_int.wq, wait);
419 while (list_empty(vcpu-arch.local_int.list)
420 list_empty(vcpu-arch.local_int.float_int-list)
421 (!vcpu-arch.local_int.timer_due)
422 !signal_pending(current)) {
423 set_current_state(TASK_INTERRUPTIBLE);
424 spin_unlock_bh(vcpu-arch.local_int.lock);
425 spin_unlock(vcpu-arch.local_int.float_int-lock);
426 vcpu_put(vcpu);
427 schedule();
428 vcpu_load(vcpu);
429 spin_lock(vcpu-arch.local_int.float_int-lock);
430 spin_lock_bh(vcpu-arch.local_int.lock);
431 }
432 __unset_cpu_idle(vcpu);
433 __set_current_state(TASK_RUNNING);
434 remove_wait_queue(vcpu-arch.local_int.wq, wait);
435 spin_unlock_bh(vcpu-arch.local_int.lock);
436 spin_unlock(vcpu-arch.local_int.float_int-lock);
437 hrtimer_try_to_cancel(vcpu-arch.ckc_timer);
438 return 0;
---
0-DAY kernel build testing backend Open Source Technology Centre
Fengguang Wu, Yuanhan Liu Intel Corporation
--
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:next 1/1] arch/x86/kvm/emulate.c:232 writeback_registers() error: buffer overflow 'ctxt-_regs' 9 = 15
On Wed, Sep 12, 2012 at 01:58:22PM +0800, Amos Kong wrote:
On 11/09/12 22:31, Fengguang Wu wrote:
Hi Avi,
In the kvm/next branch, sparse warns about
arch/x86/kvm/emulate.c:232 writeback_registers() error: buffer overflow
'ctxt-_regs' 9 = 15
This is because the array definition is ctxt._regs[NR_VCPU_REGS] where
NR_VCPU_REGS=9 for i386 and 17 for x86_64.
It could be fixed by changing the hard coded 16 to (NR_VCPU_REGS-1).
Hi Fengguang,
You replaced 16 to NR_VCPU_REGS in your patch, not (NR_VCPU_REGS-1).
I guess it's a mistake in your commitlog, right?
16 == (NR_VCPU_REGS-1). So I mean, if replacing 16 with (NR_VCPU_REGS-1),
there will be no behavior change for the x86_64 case. However I
*suspect* the right value is (NR_VCPU_REGS), as I said in the below
sentence.
And I wonder whether you actually want NR_VCPU_REGS here?
For your convenience, here is the relevant code for NR_VCPU_REGS:
enum kvm_reg {
VCPU_REGS_RAX = 0,
VCPU_REGS_RCX = 1,
VCPU_REGS_RDX = 2,
VCPU_REGS_RBX = 3,
VCPU_REGS_RSP = 4,
VCPU_REGS_RBP = 5,
VCPU_REGS_RSI = 6,
VCPU_REGS_RDI = 7,
#ifdef CONFIG_X86_64
VCPU_REGS_R8 = 8,
VCPU_REGS_R9 = 9,
VCPU_REGS_R10 = 10,
VCPU_REGS_R11 = 11,
VCPU_REGS_R12 = 12,
VCPU_REGS_R13 = 13,
VCPU_REGS_R14 = 14,
VCPU_REGS_R15 = 15,
#endif
VCPU_REGS_RIP,
== NR_VCPU_REGS
};
Thanks,
Fengguang
--- linux-next.orig/arch/x86/kvm/emulate.c 2012-09-11 20:14:00.537475301
+0800
+++ linux-next/arch/x86/kvm/emulate.c2012-09-11 22:21:57.569227558
+0800
@@ -228,7 +228,7 @@ static void writeback_registers(struct x
{
unsigned reg;
-for_each_set_bit(reg, (ulong *)ctxt-regs_dirty, 16)
+for_each_set_bit(reg, (ulong *)ctxt-regs_dirty, NR_VCPU_REGS)
ctxt-ops-write_gpr(ctxt, reg, ctxt-_regs[reg]);
}
--
Amos.
--
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: [3.5.0 BUG] vmx_handle_exit: unexpected, valid vectoring info (0x80000b0e)
On Wed, Sep 12, 2012 at 11:15:40AM +0300, Avi Kivity wrote: On 09/12/2012 07:40 AM, Fengguang Wu wrote: Hi, 3 of my test boxes running v3.5 kernel become unaccessible and I find two of them kept emitting this dmesg: vmx_handle_exit: unexpected, valid vectoring info (0x8b0e) and exit reason is 0x31 The other one has froze and the above lines are the last dmesg. Any ideas? First, that printk should be rate-limited. Second, we should add EXIT_REASON_EPT_MISCONFIG (0x31) to if ((vectoring_info VECTORING_INFO_VALID_MASK) (exit_reason != EXIT_REASON_EXCEPTION_NMI exit_reason != EXIT_REASON_EPT_VIOLATION exit_reason != EXIT_REASON_TASK_SWITCH)) printk(KERN_WARNING %s: unexpected, valid vectoring info (0x%x) and exit reason is 0x%x\n, __func__, vectoring_info, exit_reason); since it's easily caused by the guest. Third, it's really unexpected. It seems the guest was attempting to deliver a page fault exception (0x0e) but encountered an mmio page during delivery (in the IDT, TSS, stack, or page tables). Is this reproducible? If so it's easy to patch kvm to halt in that case and allow examining the guest via qemu. It's the first time I see such errors. For now I've upgraded the host kernel to 3.6-rc5. Let's check whether it will happen again. Maybe we should do so regardless (return a KVM_EXIT_INTERNAL_ERROR). I can test your changes either way. Thanks, Fengguang -- 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:next 1/1] arch/x86/kvm/emulate.c:232 writeback_registers() error: buffer overflow 'ctxt-_regs' 9 = 15
Hi Avi,
In the kvm/next branch, sparse warns about
arch/x86/kvm/emulate.c:232 writeback_registers() error: buffer overflow
'ctxt-_regs' 9 = 15
This is because the array definition is ctxt._regs[NR_VCPU_REGS] where
NR_VCPU_REGS=9 for i386 and 17 for x86_64.
It could be fixed by changing the hard coded 16 to (NR_VCPU_REGS-1).
And I wonder whether you actually want NR_VCPU_REGS here?
Thanks,
Fengguang
---
--- linux-next.orig/arch/x86/kvm/emulate.c 2012-09-11 20:14:00.537475301
+0800
+++ linux-next/arch/x86/kvm/emulate.c 2012-09-11 22:21:57.569227558 +0800
@@ -228,7 +228,7 @@ static void writeback_registers(struct x
{
unsigned reg;
- for_each_set_bit(reg, (ulong *)ctxt-regs_dirty, 16)
+ for_each_set_bit(reg, (ulong *)ctxt-regs_dirty, NR_VCPU_REGS)
ctxt-ops-write_gpr(ctxt, reg, ctxt-_regs[reg]);
}
--
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 1/2] PCI: Use local parameter pci_device_id for pci_get_subsys/class()
On Fri, Sep 07, 2012 at 06:32:48PM -0700, Yinghai Lu wrote:
with this one in pci/next pci config in /sys are not created.
10:~ # lspci -tv
pcilib: Cannot open /sys/bus/pci/devices/:00:03.0/config
lspci: Unable to read the standard configuration space header of
device :00:03.0
pcilib: Cannot open /sys/bus/pci/devices/:00:02.0/config
lspci: Unable to read the standard configuration space header of
device :00:02.0
pcilib: Cannot open /sys/bus/pci/devices/:00:01.3/config
lspci: Unable to read the standard configuration space header of
device :00:01.3
pcilib: Cannot open /sys/bus/pci/devices/:00:01.1/config
lspci: Unable to read the standard configuration space header of
device :00:01.1
pcilib: Cannot open /sys/bus/pci/devices/:00:01.0/config
lspci: Unable to read the standard configuration space header of
device :00:01.0
pcilib: Cannot open /sys/bus/pci/devices/:00:00.0/config
lspci: Unable to read the standard configuration space header of
device :00:00.0
-[:00]-
bisected to this commit
ccee7d23102f5e5765ec24779c5b77472af8f79e is the first bad commit
commit ccee7d23102f5e5765ec24779c5b77472af8f79e
Author: Feng Tang feng.t...@intel.com
Date: Thu Aug 23 15:45:03 2012 +0800
PCI: Use pci_device_id on stack for pci_get_subsys/class() to avoid
kmalloc
This fixes a kernel warning https://lkml.org/lkml/2012/7/31/682
pci_get_subsys() may get called in late system reboot stage, using
a sleepable kmalloc() sounds fragile and will cause a kernel warning
with my recent commmit 55c844a x86/reboot: Fix a warning message
triggered by stop_other_cpus() which disable local interrupt in
late system shutdown/reboot phase. Using a local parameter instead
will fix it and make it eligible for calling forom atomic context.
Do the same change for the pci_get_class() as suggested by Bjorn Helgaas
[bhelgaas: changelog]
Bisected-by: Fengguang Wu fengguang...@intel.com
Signed-off-by: Feng Tang feng.t...@intel.com
Signed-off-by: Bjorn Helgaas bhelg...@google.com
Reviewed-by: Fengguang Wu fengguang...@intel.com
:04 04 dee62a035816b73abc68e40de8f21c7349efc4cb
70b2a6258bffa1ab963bd650d8f5d02da774fbce M drivers
so the stack get overrun ?
Bjorn, I think it is this one that cause lspci broken that I mentioned
during meeting at San Diego.
This makes lspci work again on my side. The caveat is, kzalloc() will
zero out all data while the new local variable leaves some data
uninitialized.
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 78a08b1..9148b6e 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -245,7 +245,12 @@ struct pci_dev *pci_get_subsys(unsigned int vendor,
unsigned int device,
unsigned int ss_vendor, unsigned int ss_device,
struct pci_dev *from)
{
- struct pci_device_id id;
+ struct pci_device_id id = {
+ .vendor = vendor,
+ .device = device,
+ .subvendor = ss_vendor,
+ .subdevice = ss_device,
+ };
/*
* pci_find_subsys() can be called on the ide_setup() path,
@@ -256,11 +261,6 @@ struct pci_dev *pci_get_subsys(unsigned int vendor,
unsigned int device,
if (unlikely(no_pci_devices()))
return NULL;
- id.vendor = vendor;
- id.device = device;
- id.subvendor = ss_vendor;
- id.subdevice = ss_device;
-
return pci_get_dev_by_id(id, from);
}
@@ -300,11 +300,14 @@ pci_get_device(unsigned int vendor, unsigned int device,
struct pci_dev *from)
*/
struct pci_dev *pci_get_class(unsigned int class, struct pci_dev *from)
{
- struct pci_device_id id;
-
- id.vendor = id.device = id.subvendor = id.subdevice = PCI_ANY_ID;
- id.class_mask = PCI_ANY_ID;
- id.class = class;
+ struct pci_device_id id = {
+ .vendor = PCI_ANY_ID,
+ .device = PCI_ANY_ID,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .class_mask = PCI_ANY_ID,
+ .class = class,
+ };
return pci_get_dev_by_id(id, from);
}
--
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:next 1/1] (.text+0x2ac8): undefined reference to `.gfn_to_hva_memslot'
On Mon, Aug 27, 2012 at 10:33:12AM +0800, Xiao Guangrong wrote: On 08/24/2012 11:11 PM, Fengguang Wu wrote: Hi Xiao, FYI, kernel build failed on tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git next head: 4d8b81abc47b83a1939e59df2fdb0e98dfe0eedd commit: 4d8b81abc47b83a1939e59df2fdb0e98dfe0eedd [1/1] KVM: introduce readonly memslot config: powerpc-allmodconfig (attached as .config) All related error/warning messages: arch/powerpc/kvm/built-in.o: In function `.kvmppc_h_enter': (.text+0x2ac8): undefined reference to `.gfn_to_hva_memslot' Fengguang, it is a known issue which can be fixed by this patch: https://patchwork.kernel.org/patch/1370121/ OK, you are quick hand :) Thanks for your test and report. ;) You are welcome. Thanks, Fengguang -- 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: pci_get_subsys: GFP_KERNEL allocations with IRQs disabled
On Wed, Aug 22, 2012 at 03:49:08PM +0800, Tang, Feng wrote:
Hi Fengguang,
On Wed, 22 Aug 2012 10:50:08 +0800
Fengguang Wu fengguang...@intel.com wrote:
Feng,
I think it's pci_get_subsys() triggered this assert:
/*
* Oi! Can't be having __GFP_FS allocations with IRQs disabled.
*/
if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)))
return;
It's bisected down to this commit:
commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448
Author: Feng Tang feng.t...@intel.com
AuthorDate: Wed May 30 23:15:41 2012 +0800
Commit: Ingo Molnar mi...@kernel.org
CommitDate: Wed Jun 6 12:03:23 2012 +0200
x86/reboot: Fix a warning message triggered by stop_other_cpus()
Thanks,
Fengguang
Thanks for the bisection.
Revert my commit should be a solution, but can we simply make the
pci_device_id
a local on stack one instead of using sleepable kmalloc for it, as this
sounds fragile when pci_get_subsys get called in a late system reboot stage?
Good idea! I like this simple solution. It will sure fix the warning.
Reviewed-by: Fengguang Wu fengguang...@intel.com
Thanks,
Fengguang
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index 993d4a0..e5ccede 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -246,7 +246,7 @@ struct pci_dev *pci_get_subsys(unsigned int vendor,
unsigned int device,
struct pci_dev *from)
{
struct pci_dev *pdev;
- struct pci_device_id *id;
+ struct pci_device_id id;
/*
* pci_find_subsys() can be called on the ide_setup() path,
@@ -257,17 +257,12 @@ struct pci_dev *pci_get_subsys(unsigned int vendor,
unsigned int device,
if (unlikely(no_pci_devices()))
return NULL;
- id = kzalloc(sizeof(*id), GFP_KERNEL);
- if (!id)
- return NULL;
- id-vendor = vendor;
- id-device = device;
- id-subvendor = ss_vendor;
- id-subdevice = ss_device;
-
- pdev = pci_get_dev_by_id(id, from);
- kfree(id);
+ id.vendor = vendor;
+ id.device = device;
+ id.subvendor = ss_vendor;
+ id.subdevice = ss_device;
+ pdev = pci_get_dev_by_id(id, from);
return pdev;
}
[ 91.282131] machine restart
[ 91.283895] [ cut here ]
[ 91.284731] WARNING: at /c/wfg/linux/kernel/lockdep.c:2739
lockdep_trace_alloc+0x1fb/0x210()
[ 91.286132] Modules linked in:
[ 91.286703] Pid: 697, comm: reboot Not tainted
3.5.0-00024-g01ff5db-dirty #4
[ 91.287859] Call Trace:
[ 91.288289] [81050148] warn_slowpath_common+0xb8/0x100
[ 91.289338] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210
[ 91.290264] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210
[ 91.291161] [810501ce] warn_slowpath_null+0x3e/0x50
[ 91.292042] [8110acdb] lockdep_trace_alloc+0x1fb/0x210
[ 91.292934] [81228e25] kmem_cache_alloc_trace+0x55/0x600
[ 91.292934] [813025ca] ? kobject_put+0x9a/0x160
[ 91.292934] [814e95e0] ? klist_iter_exit+0x30/0x50
[ 91.292934] [81405881] ? bus_find_device+0xf1/0x120
[ 91.292934] [81361a3c] ? pci_get_subsys+0x11c/0x1b0
[ 91.292934] [81361a3c] pci_get_subsys+0x11c/0x1b0
[ 91.292934] [81361afe] pci_get_device+0x2e/0x40
[ 91.292934] [81033e25] mach_reboot_fixups+0xa5/0xd0
[ 91.292934] [81027611] native_machine_emergency_restart+0x1f1/0x590
[ 91.292934] [814f2e00] ? printk+0x4b/0x5b
[ 91.292934] [810269ef] native_machine_restart+0x6f/0x80
[ 91.292934] [810271cc] machine_restart+0x1c/0x30
[ 91.292934] [810886e0] kernel_restart+0x70/0xc0
[ 91.292934] [81088a85] sys_reboot+0x325/0x380
[ 91.292934] [811f796c] ? handle_pte_fault+0xdc/0x1740
[ 91.292934] [811f93e7] ? handle_mm_fault+0x417/0x4a0
[ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30
[ 91.292934] [810b33e7] ? up_read+0x37/0x70
[ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30
[ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0
[ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0
[ 91.292934] [810b0270] ? update_rmtp+0xe0/0xe0
[ 91.292934] [8150376e] ? restore_all+0xf/0xf
[ 91.292934] [8103d880] ? vmalloc_sync_all+0x320/0x320
[ 91.292934] [81109fca] ? trace_hardirqs_on_caller+0x28a/0x380
[ 91.292934] [81311594] ? trace_hardirqs_on_thunk+0xc/0x10
[ 91.292934] [81503735] syscall_call+0x7/0xb
Thanks,
Fengguang
--
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: pci_get_subsys: GFP_KERNEL allocations with IRQs disabled
Feng, I think it's pci_get_subsys() triggered this assert: /* * Oi! Can't be having __GFP_FS allocations with IRQs disabled. */ if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))) return; It's bisected down to this commit: commit 55c844a4dd16a4d1fdc0cf2a283ec631a02ec448 Author: Feng Tang feng.t...@intel.com AuthorDate: Wed May 30 23:15:41 2012 +0800 Commit: Ingo Molnar mi...@kernel.org CommitDate: Wed Jun 6 12:03:23 2012 +0200 x86/reboot: Fix a warning message triggered by stop_other_cpus() Thanks, Fengguang [ 91.282131] machine restart [ 91.283895] [ cut here ] [ 91.284731] WARNING: at /c/wfg/linux/kernel/lockdep.c:2739 lockdep_trace_alloc+0x1fb/0x210() [ 91.286132] Modules linked in: [ 91.286703] Pid: 697, comm: reboot Not tainted 3.5.0-00024-g01ff5db-dirty #4 [ 91.287859] Call Trace: [ 91.288289] [81050148] warn_slowpath_common+0xb8/0x100 [ 91.289338] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.290264] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.291161] [810501ce] warn_slowpath_null+0x3e/0x50 [ 91.292042] [8110acdb] lockdep_trace_alloc+0x1fb/0x210 [ 91.292934] [81228e25] kmem_cache_alloc_trace+0x55/0x600 [ 91.292934] [813025ca] ? kobject_put+0x9a/0x160 [ 91.292934] [814e95e0] ? klist_iter_exit+0x30/0x50 [ 91.292934] [81405881] ? bus_find_device+0xf1/0x120 [ 91.292934] [81361a3c] ? pci_get_subsys+0x11c/0x1b0 [ 91.292934] [81361a3c] pci_get_subsys+0x11c/0x1b0 [ 91.292934] [81361afe] pci_get_device+0x2e/0x40 [ 91.292934] [81033e25] mach_reboot_fixups+0xa5/0xd0 [ 91.292934] [81027611] native_machine_emergency_restart+0x1f1/0x590 [ 91.292934] [814f2e00] ? printk+0x4b/0x5b [ 91.292934] [810269ef] native_machine_restart+0x6f/0x80 [ 91.292934] [810271cc] machine_restart+0x1c/0x30 [ 91.292934] [810886e0] kernel_restart+0x70/0xc0 [ 91.292934] [81088a85] sys_reboot+0x325/0x380 [ 91.292934] [811f796c] ? handle_pte_fault+0xdc/0x1740 [ 91.292934] [811f93e7] ? handle_mm_fault+0x417/0x4a0 [ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [810b33e7] ? up_read+0x37/0x70 [ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [810b0270] ? update_rmtp+0xe0/0xe0 [ 91.292934] [8150376e] ? restore_all+0xf/0xf [ 91.292934] [8103d880] ? vmalloc_sync_all+0x320/0x320 [ 91.292934] [81109fca] ? trace_hardirqs_on_caller+0x28a/0x380 [ 91.292934] [81311594] ? trace_hardirqs_on_thunk+0xc/0x10 [ 91.292934] [81503735] syscall_call+0x7/0xb Thanks, Fengguang -- 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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Aug 07, 2012 at 09:29:33AM -0400, Steven Rostedt wrote: On Wed, 2012-08-01 at 07:57 +0800, Fengguang Wu wrote: What was the next lines? I bet you it was PASSED. Which means it did not fail. This is the second bug you found that has to do with RCU being called in 'idle'. The one that Paul posted a patch for. Yeah, PASSED! I have this patch queued for 3.7. Can I add your 'Tested-by' for it. Yes, please. Thanks! Thanks, Fengguang [2.898070] [8117ea5e] time_hardirqs_on+0x1de/0x220 [2.898070] [81013313] ? default_idle+0x593/0xc30 [2.898070] [81109d6d] trace_hardirqs_on_caller+0x2d/0x380 [2.898070] [8110a0e7] trace_hardirqs_on+0x27/0x40 [2.898070] [81013313] default_idle+0x593/0xc30 [2.898070] [8101692d] cpu_idle+0x2dd/0x390 [2.898070] [817fbe97] start_secondary+0x44b/0x460 [3.150115] PASSED [3.390079] Testing tracer function_graph: PASSED I'll test Paul's patch on top of yours right away. Thanks, Fengguang -- 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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
[CC kvm developers] On Mon, Jul 30, 2012 at 11:45:05AM -0400, Steven Rostedt wrote: On Tue, 2012-07-24 at 17:07 +0800, Fengguang Wu wrote: On Tue, Jul 24, 2012 at 05:03:30PM +0800, Fengguang Wu wrote: And this warning shows up in one of the dozens of boots, for the same kconfig. [2.320434] Testing tracer wakeup: PASSED [2.840288] Testing tracer wakeup_rt: .. no entries found ..FAILED! [3.280861] [ cut here ] [3.281967] WARNING: at /c/kernel-tests/src/linux/kernel/trace/trace.c:834 register_tracer+0x1b0/0x270() [3.284162] Hardware name: Bochs [3.284933] Modules linked in: [3.285695] Pid: 1, comm: swapper/0 Not tainted 3.5.0+ #1371 [3.287032] Call Trace: [3.287626] [41035c32] warn_slowpath_common+0x72/0xa0 [3.288938] [410e7dd0] ? register_tracer+0x1b0/0x270 [3.290280] [410e7dd0] ? register_tracer+0x1b0/0x270 [3.291516] [41035c82] warn_slowpath_null+0x22/0x30 [3.292723] [410e7dd0] register_tracer+0x1b0/0x270 [3.293921] [41434c7a] ? init_irqsoff_tracer+0x11/0x11 [3.295269] [41434c95] init_wakeup_tracer+0x1b/0x1d [3.296464] [41001112] do_one_initcall+0x112/0x160 [3.297639] [4141fadd] kernel_init+0xf7/0x18e [3.298724] [4141f455] ? do_early_param+0x7a/0x7a [3.299879] [4141f9e6] ? start_kernel+0x375/0x375 [3.301093] [412b15c2] kernel_thread_helper+0x6/0x10 [3.302352] ---[ end trace 57f7151f6a5def05 ]--- The comment above this test shows: * Yes this is slightly racy. It is possible that for some * strange reason that the RT thread we created, did not * call schedule for 100ms after doing the completion, * and we do a wakeup on a task that already is awake. * But that is extremely unlikely, and the worst thing that * happens in such a case, is that we disable tracing. * Honestly, if this race does happen something is horrible * wrong with the system. I guess the question now is, why didn't the RT test wake up? Oh wait! You did this on a virt machine. This test isn't designed for virt machines because the thread could have woken on another vcpu, but due to scheduling of the host system, it didn't get to run for 100ms, thus the test will fail because it never recorded the wakeup of the RT task. In other-words, the test is bogus on virt boxes :-/ It's good to quickly get to the root cause :) Can we possibly detect whether we are in a virtual machine and hence skip this particular test case? Thanks, Fengguang -- 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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
On 07/31/2012 03:43 PM, Steven Rostedt wrote:
That would be better. A hypervisor might be real-time capable (with
some effort kvm can do this), so we don't want to turn off real time
features just based on that.
It would only turn off if you enable selftests and the timing falied. If
the kvm had real time features, this most likely would fail anyway. But
that said, here's a patch that should solve this:
No luck.. it still fails:
[2.360068] Testing tracer irqsoff: [2.854529]
[2.854828] ===
[2.855560] [ INFO: suspicious RCU usage. ]
[2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
[2.857182] ---
[2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock() used
illegally while idle!
[2.859450]
[2.859450] other info that might help us debug this:
[2.859450]
[2.860874]
[2.860874] RCU used illegally from idle CPU!
[2.860874] rcu_scheduler_active = 1, debug_locks = 0
[2.862754] RCU used illegally from extended quiescent state!
[2.863741] 2 locks held by swapper/0/0:
[2.864377] #0: [2.864423] (max_trace_lock){..}, at: [814f6bfe]
check_critical_timing+0xd7/0x286
[2.864423] #1: (rcu_read_lock){.+.+..}, at: [8116f930]
__update_max_tr+0x0/0x430
[2.864423] stack backtrace:
[2.864423] Pid: 0, comm: swapper/0 Not tainted 3.5.0-00024-g01ff5db-dirty #3
[2.864423] Call Trace:
[2.864423] [81103a06] lockdep_rcu_suspicious+0x1c6/0x210
[2.864423] [8116fc9a] __update_max_tr+0x36a/0x430
[2.864423] [8116f930] ? tracing_record_cmdline+0x200/0x200
[2.864423] [8117186e] update_max_tr_single+0x14e/0x2c0
[2.864423] [81170baa] ? __trace_stack+0x2a/0x40
[2.864423] [814f6d22] check_critical_timing+0x1fb/0x286
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [8110a0e7] ? trace_hardirqs_on+0x27/0x40
[2.864423] [8117ea5e] time_hardirqs_on+0x1de/0x220
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [81109d6d] trace_hardirqs_on_caller+0x2d/0x380
[2.864423] [8110a0e7] trace_hardirqs_on+0x27/0x40
[2.864423] [81013313] default_idle+0x593/0xc30
[2.864423] [8101692d] cpu_idle+0x2dd/0x390
[2.864423] [814eb841] rest_init+0x2f5/0x314
[2.864423] [814eb54c] ? __read_lock_failed+0x14/0x14
[2.864423] [817a43b4] start_kernel+0x866/0x87a
Thanks,
Fengguang
--
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: Testing tracer wakeup_rt: .. no entries found ..FAILED!
On Tue, Jul 31, 2012 at 07:51:39PM -0400, Steven Rostedt wrote:
On Wed, 2012-08-01 at 07:43 +0800, Fengguang Wu wrote:
On Tue, Jul 31, 2012 at 09:13:39AM -0400, Steven Rostedt wrote:
On Tue, 2012-07-31 at 15:50 +0300, Avi Kivity wrote:
On 07/31/2012 03:43 PM, Steven Rostedt wrote:
That would be better. A hypervisor might be real-time capable (with
some effort kvm can do this), so we don't want to turn off real time
features just based on that.
It would only turn off if you enable selftests and the timing falied. If
the kvm had real time features, this most likely would fail anyway. But
that said, here's a patch that should solve this:
No luck.. it still fails:
I bet you it didn't ;-)
[2.360068] Testing tracer irqsoff: [2.854529]
[2.854828] ===
[2.855560] [ INFO: suspicious RCU usage. ]
[2.856266] 3.5.0-00024-g01ff5db-dirty #3 Not tainted
[2.857182] ---
[2.857933] /c/wfg/linux/include/linux/rcupdate.h:730 rcu_read_lock()
used illegally while idle!
[2.859450]
[2.859450] other info that might help us debug this:
[2.859450]
[2.860874]
[2.860874] RCU used illegally from idle CPU!
[2.860874] rcu_scheduler_active = 1, debug_locks = 0
[2.862754] RCU used illegally from extended quiescent state!
[2.863741] 2 locks held by swapper/0/0:
[2.864377] #0: [2.864423] (max_trace_lock){..}, at:
[814f6bfe] check_critical_timing+0xd7/0x286
[2.864423] #1: (rcu_read_lock){.+.+..}, at: [8116f930]
__update_max_tr+0x0/0x430
[2.864423] stack backtrace:
[2.864423] Pid: 0, comm: swapper/0 Not tainted
3.5.0-00024-g01ff5db-dirty #3
[2.864423] Call Trace:
[2.864423] [81103a06] lockdep_rcu_suspicious+0x1c6/0x210
[2.864423] [8116fc9a] __update_max_tr+0x36a/0x430
[2.864423] [8116f930] ? tracing_record_cmdline+0x200/0x200
[2.864423] [8117186e] update_max_tr_single+0x14e/0x2c0
[2.864423] [81170baa] ? __trace_stack+0x2a/0x40
[2.864423] [814f6d22] check_critical_timing+0x1fb/0x286
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [8110a0e7] ? trace_hardirqs_on+0x27/0x40
[2.864423] [8117ea5e] time_hardirqs_on+0x1de/0x220
[2.864423] [81013313] ? default_idle+0x593/0xc30
[2.864423] [81109d6d] trace_hardirqs_on_caller+0x2d/0x380
[2.864423] [8110a0e7] trace_hardirqs_on+0x27/0x40
[2.864423] [81013313] default_idle+0x593/0xc30
[2.864423] [8101692d] cpu_idle+0x2dd/0x390
[2.864423] [814eb841] rest_init+0x2f5/0x314
[2.864423] [814eb54c] ? __read_lock_failed+0x14/0x14
[2.864423] [817a43b4] start_kernel+0x866/0x87a
What was the next lines? I bet you it was PASSED. Which means it did
not fail. This is the second bug you found that has to do with RCU being
called in 'idle'. The one that Paul posted a patch for.
Yeah, PASSED!
[2.898070] [8117ea5e] time_hardirqs_on+0x1de/0x220
[2.898070] [81013313] ? default_idle+0x593/0xc30
[2.898070] [81109d6d] trace_hardirqs_on_caller+0x2d/0x380
[2.898070] [8110a0e7] trace_hardirqs_on+0x27/0x40
[2.898070] [81013313] default_idle+0x593/0xc30
[2.898070] [8101692d] cpu_idle+0x2dd/0x390
[2.898070] [817fbe97] start_secondary+0x44b/0x460
[3.150115] PASSED
[3.390079] Testing tracer function_graph: PASSED
I'll test Paul's patch on top of yours right away.
Thanks,
Fengguang
--
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
pci_get_subsys: GFP_KERNEL allocations with IRQs disabled
On Tue, Jul 31, 2012 at 05:18:11PM -0700, Paul E. McKenney wrote: On Tue, Jul 31, 2012 at 08:09:38PM -0400, Steven Rostedt wrote: On Tue, 2012-07-31 at 16:57 -0700, Paul E. McKenney wrote: What was the next lines? I bet you it was PASSED. Which means it did not fail. This is the second bug you found that has to do with RCU being called in 'idle'. The one that Paul posted a patch for. Though it needs another patch to actually use it in the right place... Right. Something like this: Looks good to me! With all 3 patches applied, the warning on __update_max_tr finally goes away. Thanks! However, this unrelated warning still reliably remains (the same config). I think it's pci_get_subsys() triggered this assert: /* * Oi! Can't be having __GFP_FS allocations with IRQs disabled. */ if (DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))) return; [ 91.282131] machine restart [ 91.283895] [ cut here ] [ 91.284731] WARNING: at /c/wfg/linux/kernel/lockdep.c:2739 lockdep_trace_alloc+0x1fb/0x210() [ 91.286132] Modules linked in: [ 91.286703] Pid: 697, comm: reboot Not tainted 3.5.0-00024-g01ff5db-dirty #4 [ 91.287859] Call Trace: [ 91.288289] [81050148] warn_slowpath_common+0xb8/0x100 [ 91.289338] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.290264] [8110acdb] ? lockdep_trace_alloc+0x1fb/0x210 [ 91.291161] [810501ce] warn_slowpath_null+0x3e/0x50 [ 91.292042] [8110acdb] lockdep_trace_alloc+0x1fb/0x210 [ 91.292934] [81228e25] kmem_cache_alloc_trace+0x55/0x600 [ 91.292934] [813025ca] ? kobject_put+0x9a/0x160 [ 91.292934] [814e95e0] ? klist_iter_exit+0x30/0x50 [ 91.292934] [81405881] ? bus_find_device+0xf1/0x120 [ 91.292934] [81361a3c] ? pci_get_subsys+0x11c/0x1b0 [ 91.292934] [81361a3c] pci_get_subsys+0x11c/0x1b0 [ 91.292934] [81361afe] pci_get_device+0x2e/0x40 [ 91.292934] [81033e25] mach_reboot_fixups+0xa5/0xd0 [ 91.292934] [81027611] native_machine_emergency_restart+0x1f1/0x590 [ 91.292934] [814f2e00] ? printk+0x4b/0x5b [ 91.292934] [810269ef] native_machine_restart+0x6f/0x80 [ 91.292934] [810271cc] machine_restart+0x1c/0x30 [ 91.292934] [810886e0] kernel_restart+0x70/0xc0 [ 91.292934] [81088a85] sys_reboot+0x325/0x380 [ 91.292934] [811f796c] ? handle_pte_fault+0xdc/0x1740 [ 91.292934] [811f93e7] ? handle_mm_fault+0x417/0x4a0 [ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [810b33e7] ? up_read+0x37/0x70 [ 91.292934] [8103e07b] ? do_page_fault+0x7fb/0xb30 [ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [8123c063] ? do_sys_open+0x3a3/0x3f0 [ 91.292934] [810b0270] ? update_rmtp+0xe0/0xe0 [ 91.292934] [8150376e] ? restore_all+0xf/0xf [ 91.292934] [8103d880] ? vmalloc_sync_all+0x320/0x320 [ 91.292934] [81109fca] ? trace_hardirqs_on_caller+0x28a/0x380 [ 91.292934] [81311594] ? trace_hardirqs_on_thunk+0xc/0x10 [ 91.292934] [81503735] syscall_call+0x7/0xb Thanks, Fengguang -- 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:auto-next 24/39] (.init.rodata+0x830): undefined reference to `x86_hyper_kvm'
Hi Raghavendra, Kernel build failed on tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git auto-next head: 12938728e8145ecd49dce97c52f10b713bcdfc94 commit: f2a743473194a1ad44a85f8b63aeef9d63e5bf47 [24/39] KVM: Add config to support ple or cpu relax optimzation config: x86_64-alldefconfig (attached as .config) All related error/warning messages: arch/x86/built-in.o: In function `interrupt': (.init.rodata+0x830): undefined reference to `x86_hyper_kvm' --- 0-DAY kernel build testing backend Open Source Technology Centre Fengguang Wu w...@linux.intel.com Intel Corporation # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 3.5.0-rc1 Kernel Configuration # CONFIG_64BIT=y # CONFIG_X86_32 is not set CONFIG_X86_64=y CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf64-x86-64 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/x86_64_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y CONFIG_NEED_DMA_MAP_STATE=y CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_BUG=y CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y CONFIG_ZONE_DMA32=y CONFIG_AUDIT_ARCH=y CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11 CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # # CONFIG_EXPERIMENTAL is not set CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_KERNEL_GZIP=y # CONFIG_KERNEL_BZIP2 is not set # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_FHANDLE is not set CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # CONFIG_CGROUPS is not set # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_PID_NS=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y CONFIG_ANON_INODES=y # CONFIG_EXPERT is not set # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PCI_QUIRKS=y CONFIG_SLUB_DEBUG=y CONFIG_COMPAT_BRK=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y CONFIG_HAVE_USER_RETURN_NOTIFIER=y CONFIG_HAVE_PERF_EVENTS_NMI=y CONFIG_HAVE_ARCH_JUMP_LABEL=y CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y CONFIG_HAVE_CMPXCHG_LOCAL=y CONFIG_HAVE_CMPXCHG_DOUBLE=y CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
Re: [kvm:auto-next 24/39] (.init.rodata+0x830): undefined reference to `x86_hyper_kvm'
Hi Avi, On Thu, Jul 26, 2012 at 04:58:35PM +0300, Avi Kivity wrote: On 07/26/2012 04:26 PM, Fengguang Wu wrote: Hi Raghavendra, Kernel build failed on tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git auto-next head: 12938728e8145ecd49dce97c52f10b713bcdfc94 commit: f2a743473194a1ad44a85f8b63aeef9d63e5bf47 [24/39] KVM: Add config to support ple or cpu relax optimzation config: x86_64-alldefconfig (attached as .config) All related error/warning messages: arch/x86/built-in.o: In function `interrupt': (.init.rodata+0x830): undefined reference to `x86_hyper_kvm' Fixed by d63d3e6217c4. OK, sorry for the noise! Perhaps your tree is not rebaseable? With that knowledge I can arrange to not report transient errors in the tree, and avoid sending unnecessary noises to you. Thanks, Fengguang -- 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:auto-next 24/39] (.init.rodata+0x830): undefined reference to `x86_hyper_kvm'
On Thu, Jul 26, 2012 at 05:13:45PM +0300, Avi Kivity wrote: On 07/26/2012 05:03 PM, Fengguang Wu wrote: Hi Avi, On Thu, Jul 26, 2012 at 04:58:35PM +0300, Avi Kivity wrote: On 07/26/2012 04:26 PM, Fengguang Wu wrote: Hi Raghavendra, Kernel build failed on tree: git://git.kernel.org/pub/scm/virt/kvm/kvm.git auto-next head: 12938728e8145ecd49dce97c52f10b713bcdfc94 commit: f2a743473194a1ad44a85f8b63aeef9d63e5bf47 [24/39] KVM: Add config to support ple or cpu relax optimzation config: x86_64-alldefconfig (attached as .config) All related error/warning messages: arch/x86/built-in.o: In function `interrupt': (.init.rodata+0x830): undefined reference to `x86_hyper_kvm' Fixed by d63d3e6217c4. OK, sorry for the noise! Perhaps your tree is not rebaseable? With that knowledge I can arrange to not report transient errors in the tree, and avoid sending unnecessary noises to you. 'next' is not rebased, 'auto-next' is. Please do keep testing, if we get too much noise we'll find a way to reduce it. Got it! I actually do per-branch control policies :-) I've set it up to report every build error in kvm/auto-next and to only report errors that still remain at kvm/next/HEAD. Thanks, Fengguang -- 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 segfaults and bad page state in 3.4.0
Hi Guangrong, On Tue, Jul 03, 2012 at 02:41:02PM +0800, Xiao Guangrong wrote: Hi Fengguang, I can reproduce this bug in my test case, and have posted a patch to fix it which can found at: http://marc.info/?l=linux-mmm=134129723504527w=2 Could you please try it? Thank you very much! I'm glad to try it out in my compile servers. Note that I've not encountered the bug since then (seems not very reproducible). So the feedback would be kind of the patch works well rather than confirming that it fixed the bug for me. Sorry for that. Thanks, Fengguang On 06/04/2012 07:46 PM, Fengguang Wu wrote: Hi, I'm running lots of kvm instances for doing kernel boot tests. Unfortunately the test system itself is not stable enough, I got scary errors in both kvm and the host kernel. Like this. [294025.795382] kvm used greatest stack depth: 2896 bytes left [310388.622083] kvm[1864]: segfault at c ip 7f498e9f6a81 sp 7f4994b9fca0 error 4 in kvm[7f498e96+33b000] [310692.050589] kvm[4332]: segfault at 10 ip 7fca662620b9 sp 7fca70472af0 error 6 in kvm[7fca661cc000+33b000] [312608.950120] kvm[18931]: segfault at 8 ip 7f95962a10a5 sp 7f959d777170 error 4 in kvm[7f959620b000+33b000] [312622.941640] kvm[19123]: segfault at 10 ip 7f406f5580b9 sp 7f4077d8b350 error 6 in kvm[7f406f4c2000+33b000] [313917.860951] kvm[28789]: segfault at c ip 7f718f4dfa81 sp 7f7198459520 error 4 in kvm[7f718f449000+33b000] [313919.177192] kvm used greatest stack depth: 2864 bytes left [314061.390945] kvm used greatest stack depth: 2208 bytes left [327479.676068] BUG: Bad page state in process kvm pfn:59ac9 -- 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 segfaults and bad page state in 3.4.0
Hi, I'm running lots of kvm instances for doing kernel boot tests. Unfortunately the test system itself is not stable enough, I got scary errors in both kvm and the host kernel. Like this. [294025.795382] kvm used greatest stack depth: 2896 bytes left [310388.622083] kvm[1864]: segfault at c ip 7f498e9f6a81 sp 7f4994b9fca0 error 4 in kvm[7f498e96+33b000] [310692.050589] kvm[4332]: segfault at 10 ip 7fca662620b9 sp 7fca70472af0 error 6 in kvm[7fca661cc000+33b000] [312608.950120] kvm[18931]: segfault at 8 ip 7f95962a10a5 sp 7f959d777170 error 4 in kvm[7f959620b000+33b000] [312622.941640] kvm[19123]: segfault at 10 ip 7f406f5580b9 sp 7f4077d8b350 error 6 in kvm[7f406f4c2000+33b000] [313917.860951] kvm[28789]: segfault at c ip 7f718f4dfa81 sp 7f7198459520 error 4 in kvm[7f718f449000+33b000] [313919.177192] kvm used greatest stack depth: 2864 bytes left [314061.390945] kvm used greatest stack depth: 2208 bytes left [327479.676068] BUG: Bad page state in process kvm pfn:59ac9 [327479.676455] page:ea000166b240 count:0 mapcount:0 mapping: (null) index:0x7fd346bc6 [327479.677083] page flags: 0x114(referenced|dirty) [327479.677575] Modules linked in: [327479.677897] Pid: 11423, comm: kvm Not tainted 3.4.0 #131 [327479.678272] Call Trace: [327479.678538] [81107343] bad_page+0xe6/0xfb [327479.678897] [811079c6] get_page_from_freelist+0x534/0x6f6 [327479.679314] [81107d92] __alloc_pages_nodemask+0x20a/0x75e [327479.679729] [8108e121] ? finish_task_switch+0x4c/0xf6 [327479.680136] [81143477] ? lookup_page_cgroup_used+0xe/0x24 [327479.680548] [811079b5] ? get_page_from_freelist+0x523/0x6f6 [327479.680970] [811367c8] alloc_pages_current+0xd2/0xf3 [327479.681369] [811012e4] __page_cache_alloc+0xa1/0xae [327479.681761] [8110b144] __do_page_cache_readahead+0x107/0x20b [327479.682188] [8110b0cc] ? __do_page_cache_readahead+0x8f/0x20b [327479.682615] [811293b0] ? anon_vma_prepare+0xb4/0x137 [327479.683010] [8110b521] ra_submit+0x21/0x25 [327479.683375] [81102f7a] filemap_fault+0x18a/0x383 [327479.683757] [8111d6b3] __do_fault+0xc8/0x451 [327479.684128] [81120103] handle_pte_fault+0x2de/0x844 [327479.684522] [8114446e] ? mem_cgroup_count_vm_event+0x1a/0x96 [327479.684944] [811218ac] handle_mm_fault+0x1a6/0x1bb [327479.685339] [819b8c12] do_page_fault+0x405/0x42a [327479.685722] [8112619e] ? do_mmap_pgoff+0x299/0x2f3 [327479.686115] [813fe03d] ? trace_hardirqs_off_thunk+0x3a/0x3c [327479.686534] [819b5b45] page_fault+0x25/0x30 [327479.686898] Disabling lock debugging due to kernel taint The same host kernel, in another test box: [770644.256817] kvm_get_msr_common: 2123 callbacks suppressed [770644.257475] kvm: 31889: cpu0 unhandled rdmsr: 0x2 [770644.258103] kvm: 31889: cpu0 unhandled rdmsr: 0x3 [770644.258707] kvm: 31889: cpu0 unhandled rdmsr: 0x4 [770644.259322] kvm: 31889: cpu0 unhandled rdmsr: 0x5 [770644.259914] kvm: 31889: cpu0 unhandled rdmsr: 0x6 [770644.260499] kvm: 31889: cpu0 unhandled rdmsr: 0x7 [770644.261108] kvm: 31889: cpu0 unhandled rdmsr: 0x8 [770644.261700] kvm: 31889: cpu0 unhandled rdmsr: 0x9 [770644.262302] kvm: 31889: cpu0 unhandled rdmsr: 0xa [770644.262883] kvm: 31889: cpu0 unhandled rdmsr: 0xb [909290.636655] kvm[31619]: segfault at 40 ip 7fcb3d8c4254 sp 7fcb41bcaec0 error 4 in kvm[7fcb3d82e000+33b000] Please drop me hints if I can help debugging it (a week later, after returning from LinuxCon Japan), thank you. Thanks, Fengguang -- 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 segfaults and bad page state in 3.4.0
On Mon, Jun 04, 2012 at 08:35:30PM +0800, Fengguang Wu wrote: Hi Gleb, On Mon, Jun 04, 2012 at 02:56:50PM +0300, Gleb Natapov wrote: On Mon, Jun 04, 2012 at 07:46:03PM +0800, Fengguang Wu wrote: Hi, I'm running lots of kvm instances for doing kernel boot tests. Unfortunately the test system itself is not stable enough, I got scary errors in both kvm and the host kernel. Like this. What do you mean by in both kvm and the host kernel. Do you have I mean the host side's kvm user space process and kernel seem to have problems. similar Oopses inside your guests? If yes can you post one? There are all kinds of problems in the guest kernel, too. Probably I built in too many modules (take a debian config and s/=m/=y/) and enabled too many debug options. Many of the bugs I ran into have already been reported by others in LKML. Here are more weird things. Two more boot errors.. storvsc device driver (from Microsoft..) bug: [ 108.445777] hv_vmbus: registering driver storvsc [ 108.498750] [ cut here ] [ 108.502649] kernel BUG at /c/kernel-tests/intel/drivers/base/driver.c:227! [ 108.502649] invalid opcode: [#1] SMP DEBUG_PAGEALLOC [ 108.502649] CPU 0 [ 108.502649] Modules linked in: [ 108.502649] [ 108.502649] Pid: 1, comm: swapper/0 Not tainted 3.2.0-rt13+ #1 Bochs Bochs [ 108.502649] RIP: 0010:[8197f395] [8197f395] driver_register+0x24/0x116 [ 108.502649] RSP: 0018:8800162c5e60 EFLAGS: 00010246 [ 108.502649] RAX: 84131c40 RBX: 8411e580 RCX: 25232522 [ 108.502649] RDX: RSI: 82dac59f RDI: 8411e580 [ 108.502649] RBP: 8800162c5ea0 R08: 0002 R09: 84f32270 [ 108.502649] R10: R11: R12: [ 108.502649] R13: 83aeeeff R14: R15: [ 108.502649] FS: () GS:88001740() knlGS: [ 108.502649] CS: 0010 DS: ES: CR0: 8005003b [ 108.502649] CR2: CR3: 03e12000 CR4: 06f0 [ 108.502649] DR0: DR1: DR2: [ 108.502649] DR3: DR6: 0ff0 DR7: 0400 [ 108.502649] Process swapper/0 (pid: 1, threadinfo 8800162c4000, task 8800162c0040) [ 108.502649] Stack: [ 108.502649] 8800162c5eb0 8800162c5e70 8800162c5e80 8411e560 [ 108.502649] 83aeeeff [ 108.502649] 8800162c5ed0 827e3b18 83e6eda8 845d6460 [ 108.502649] Call Trace: [ 108.502649] [827e3b18] __vmbus_driver_register+0x4a/0x5c [ 108.502649] [8445fcc4] ? rtsx_init+0x29/0x29 [ 108.502649] [8445fcf9] storvsc_drv_init+0x35/0x3f [ 108.502649] [81002099] do_one_initcall+0x7f/0x13a [ 108.502649] [843e4caa] kernel_init+0xce/0x148 [ 108.502649] [82db5604] kernel_thread_helper+0x4/0x10 [ 108.502649] [82dac9b4] ? retint_restore_args+0x13/0x13 [ 108.502649] [843e4bdc] ? start_kernel+0x412/0x412 [ 108.502649] [82db5600] ? gs_change+0x13/0x13 [ 108.502649] Code: 5c 41 5d 41 5e 5d c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 48 8b 47 08 48 89 fb 48 83 78 68 00 75 02 0f 0b 48 83 78 30 00 74 07 48 83 7f 30 00 75 1c 48 83 78 38 00 [ 108.502649] RIP [8197f395] driver_register+0x24/0x116 [ 108.502649] RSP 8800162c5e60 [ 110.913751] ---[ end trace 184c66c6768bd651 ]--- [ 110.967270] swapper/0 used greatest stack depth: 3688 bytes left [ 111.021415] Kernel panic - not syncing: Attempted to kill init! [ 111.075053] Pid: 1, comm: swapper/0 Tainted: G D 3.2.0-rt13+ #1 [ 111.130699] Call Trace: [ 111.185972] [82d5d34d] panic+0xa0/0x1b3 [ 111.241642] [82dabdda] ? _raw_write_unlock_irq+0x2e/0x47 [ 111.294939] [810a55f8] do_exit+0x9b/0x7b7 [ 111.349523] [810a31cd] ? kmsg_dump+0x82/0x135 [ 111.402315] [82dad653] oops_end+0xaf/0xb8 [ 111.454034] [8104beb4] die+0x5a/0x66 [ 111.505217] [82dad181] do_trap+0x11a/0x129 [ 111.555117] [81049b4a] do_invalid_op+0x98/0xa1 [ 111.603546] [8197f395] ? driver_register+0x24/0x116 [ 111.651247] [810d2423] ? trace_hardirqs_off_caller+0x3f/0x9e [ 111.700511] [816a457d] ? trace_hardirqs_off_thunk+0x3a/0x3c [ 111.748561] [82dac9e4] ? restore_args+0x30/0x30 [ 111.796413] [82db547b] invalid_op+0x1b/0x20 [ 111.844369] [82dac59f] ? _raw_spin_unlock_irqrestore+0x3e/0x61 [ 111.893537] [8197f395] ? driver_register+0x24/0x116 [ 111.943061] [827e3b18] __vmbus_driver_register+0x4a/0x5c [ 111.993386] [8445fcc4] ? rtsx_init+0x29/0x29 [ 112.043646] [8445fcf9] storvsc_drv_init+0x35/0x3f
