Date: Wed, 23 May 2007 17:46:44 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Jeff Roberson <jeff@FreeBSD.org> 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 Message-ID: <20070523174102.L12345@fledge.watson.org> In-Reply-To: <200705202211.l4KMBo8a028637@repoman.freebsd.org> References: <200705202211.l4KMBo8a028637@repoman.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <attilio@FreeBSD.org> > 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: <Generic ISA VGA> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070523174102.L12345>