Unkillable KSE threaded proc
gallatin at cs.duke.edu
Thu Sep 9 12:12:30 PDT 2004
Julian Elischer writes:
> > thread 0xc1b617d0 ksegrp 0xc18779a0 [CPU 1]
> > thread 0xc1b614b0 ksegrp 0xc18779a0 [SUSP]
> > thread 0xc1b61320 ksegrp 0xc18779a0 [LOCK process lock c1b13200]
> > thread 0xc2b6ce10 ksegrp 0xc1a270e0 [LOCK process lock c1b13200]
> >db> call db_trace_thread(0xc1b617d0, -1)
> >sched_switch(3249936336,3244003328,3244003328,468695918,1992661338) at sched_switch+216
> >mi_switch(2,3244003328,3244003668,3244003328,3867700060) at mi_switch+455
> >maybe_preempt(3244003328,252,0,3867700072,3226402603) at maybe_preempt+153
> >sched_add(70,3867700092,3226402999,3246881184,3867189248) at sched_add+259
> >end() at 3246881184
> odd that teh stack trace stops there?? that in itself is wierd..
> I don't understand why the thread is marked as currently running on
> CPU1. it called sched_switch that should have saved its state
> and put it on teh run queue (and marked it as such) so its state should
> be RUNQ.
In another context, John recently told me:
for threads on CPUs we don't save the current thread state
anywhere when we enter the debugger, so the backtrace is
only relevant for info since the last context switch.
Maybe that explains at least this wierdness..
More information about the freebsd-threads