Kernel hanging after today cvsup at Timecounter "TSC

Attilio Rao attilio at
Wed May 23 17:02:20 UTC 2007

2007/5/23, Robert Watson <rwatson at>:
> 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

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).


Peace can only be achieved by understanding - A. Einstein

More information about the freebsd-current mailing list