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 CambridgeReceived on Wed May 23 2007 - 12:44:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:10 UTC