Kernel hanging after today cvsup at Timecounter "TSC

[Robert Watson]

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

The arguments to atpic_handle_intr() and atpic_enable_source() suggest that 
the interrupt fires before the code is ready to handle it, or something along 
those lines.

Robert N M Watson
Computer Laboratory
University of Cambridge