From owner-cvs-all@FreeBSD.ORG Wed May 23 16:46:44 2007 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF88916A41F; Wed, 23 May 2007 16:46:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id A12E413C46C; Wed, 23 May 2007 16:46:44 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 58FFC47674; Wed, 23 May 2007 12:46:44 -0400 (EDT) Date: Wed, 23 May 2007 17:46:44 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Jeff Roberson In-Reply-To: <200705202211.l4KMBo8a028637@repoman.freebsd.org> Message-ID: <20070523174102.L12345@fledge.watson.org> References: <200705202211.l4KMBo8a028637@repoman.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_clock.c subr_prof.c subr_witness.c src/sys/sys systm.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2007 16:46:44 -0000 On Sun, 20 May 2007, Jeff Roberson wrote: > Modified files: > sys/kern kern_clock.c subr_prof.c subr_witness.c > sys/sys systm.h > Log: > - Move clock synchronization into a seperate clock lock so the global > scheduler lock is not involved. sched_lock still protects the sched_clock > call. Another patch will remedy this. > > Contributed by: Attilio Rao > Tested by: kris, jeff I believe that this commit may be causing the 'vga0' hangs being reported on current@. A brief hand transcription from parallels: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 panic: corrupt spinlock KDB enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x32: leave db> bt Tracing pid 0 tid 0 td 0xc0b36540 kdb_enter(...) at kdb_enter+0x32 panic(...) at panic+0xc5 _mtx_lock_spin_flags(...) at _mtx_lock_spin_flags+0xd4 statclock(...) at statclock+0x108 hardclock(...) at hardclock+0x37 clkintr(...) at clkintr+0xd2 intr_execute_handlers(...) at intr_execute_handlers+0xe5 atpic_handle_intr(...) at atpic_handle_intr+0xba Xatpic_intr0() at Xatpic_intr0+0x21 --- interrupt, eip = 0xc0993f2b, esp=0xc1020cb8, ebp = 0xc1020cbc --- spinlock_exit(...) at spinlock_exit+0x2b _mtx_unlock_spin_flags(...) at _mtx_unlock_spin_flags+0xdc atpic_enable_source(...) at atpic_enable_source+0x86 intr_add_handler(...) at intr_add_handler+0xb3 cpu_initclockS(...) at cpu_initclocks+0x50 initclocks(...) at initclocks+0xb mi_startup() at mi_startup+0x96 begin() at begin+0x2c The intr_execuite_handlers() call takes the same first argument as atpic_enable_source(), so it seems that the first clock tick is happening while the clock device code is still kicking off -- could we be seeing an unitialized spinlock being used, or is the memory getting overwritten? I think this is mostly turning up for Parallel users due to the way Parallels is doing clock tick timing, but that is speculation. A kernel from 20070520 works fine, a kernel from 20070521 fails... Robert N M Watson Computer Laboratory University of Cambridge