On Sat, Sep 29, 2001 at 12:52:48PM -0700, John Baldwin wrote: > > could figure out the faulting address that it trapp'd one that would help. You > could add KTR tracepoints or some such to store the log message to do that and > then examin the KTR buffer to get the actual faulting address.
Ok. In the remote debugger I got a lot more data. In fact, it brought me to linux_alarm() in /sys/compat/linux_misc.c First some data about the trapping thread: td = curthread = 0xcbb89304 looks ok kg = td->ksegrp = 0xcbb89230 looks ok td->td_proc->p_comm = "swi6: tty:sio clock" The LTP test that seems to be causing this is doing an alarm(). In linux_alarm() I see: : s = splsoftclock(); old_it = td->td_proc->p_realtimer; : td->td_proc->p_realtimer = it; splx(s); : Is the splsoftclock() acceptable locking to access td->td_proc? -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message