Date: Wed, 23 May 2007 18:54:29 +0200 From: "Attilio Rao" <attilio@freebsd.org> To: "Robert Watson" <rwatson@freebsd.org> Cc: Goran Gajic <ggajic@afrodita.rcub.bg.ac.yu>, freebsd-current@freebsd.org Subject: Re: Kernel hanging after today cvsup at Timecounter "TSC Message-ID: <3bbf2fe10705230954pc9d013dpcbe678cd296b4105@mail.gmail.com> In-Reply-To: <20070523103815.W28780@fledge.watson.org> References: <Pine.LNX.4.64.0705221600300.23596@afrodita.rcub.bg.ac.yu> <20070522134724.L28780@fledge.watson.org> <20070522202914.GB64542@bunrab.catwhisker.org> <20070523103815.W28780@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
2007/5/23, Robert Watson <rwatson@freebsd.org>: > > On Tue, 22 May 2007, David Wolfskill wrote: > > >> I saw an identical problem when I booted a kernel from yesterday with > >> kernel modules from a week or so earlier, only mine froze before getting to > >> the Timecounter line, rather, immediately after the vga0 line. Perhaps > >> we're looking at an issue with mixing modules with a kernel from > >> before/after the compiler upgrade? > > > > I'm about as certain as I can be that ssuch "module-mixing" did not cause > > the hang that I saw on my laptop today, as I was able to successfully boot > > from a kernel built (along with world, at the time) on 19 May (after the gcc > > 4 import). > > > > In my case, the keyboard was unresponsive (e.g., didn't go into "scroll > > lock" mode when I used the keyboard chord to request that), and the fan > > started gaining speed pretty rapidly, so I elected to power-cycle the > > machine aftter a few seconds of trying less disruptive means of getting its > > attention. > > > > I believe the last message displayed had the word "probe" in it. I am > > certain that the system hadn't tried to mount any file systems yet. > > > > Sorry I don't have more specifics handy. I did save the hanging kernel, of > > course. > > Indeed, looks like I was on the wrong track -- with INVARIANTS enabled, I see > something more sensible. Apologies for any typos, this is hand-transcribed: > > vga0: <Generic ISA VGA> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 > panic: corupt spinlock > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x32: leave > db> bt > Tracing pid 0 tid 0 td 0xc0b36620 > kdb_enter(...) at kdb_enter+0x32 > panic(...) at panic+0xc5 > 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_int0+0x21 > --- interrupt, eip = 0xc099409b, esp=0xc1020cb7, 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 > > I've uploaded the actual stack trace with arguments as > > http://www.watson.org/~robert/freebsd/20070523-panic.png Ok, it seems that the new time_lock spinlock is initialized too late, and infact cpu_initclocks() is called before it is initialized. It is enough to move the mtx_init() just before the cpu_initclocks() in kern_clock.c::initclocks(). Can someone try that and report if it works? I'm sorry for that, but I (and presumabily other people testing the patch) never got that problems on all machines we used (probabilly beacause this is just triggered when attaching vgaX). Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3bbf2fe10705230954pc9d013dpcbe678cd296b4105>