On Mon, Sep 8, 2008 at 12:56 PM, John Baldwin <jhb_at_freebsd.org> wrote: > On Tuesday 02 September 2008 09:40:49 pm Peter Wemm wrote: [..] >> I don't know if it is the same problem, but mx2.freebsd.org, running >> today's 6.4-PRERELEASE just died with: >> Sep 3 00:20:11 mx2 sshd[15333]: fatal: Read from socket failed: Connection >> resr panic: Assertion td->td_flags & TDF_SINTR failed at >> ../../../kern/subr_sleepque5 cpuid = 2 >> KDB: enter: panic >> FreeBSD 6.4-PRERELEASE #7: Tue Sep 2 19:43:27 UTC 2008 >> This was after about 3 hours of uptime. It has previously run happily >> for months at a time before today's rebuild. > > So I think what happened is that the thread was woken up while the sleepq > chain was unlocked while the thread unlocks the sx lock. The code handles > this fine already since the same race can happen when dropping the lock while > checking for signals. However, in this case TDF_SINTR won't be true anymore. > The assertion just needs to be updated. Try this: > > Index: subr_sleepqueue.c > =================================================================== > --- subr_sleepqueue.c (revision 182874) > +++ subr_sleepqueue.c (working copy) > _at__at_ -382,7 +382,7 _at__at_ > CTR3(KTR_PROC, "sleepq catching signals: thread %p (pid %ld, %s)", > (void *)td, (long)p->p_pid, p->p_comm); > > - MPASS(td->td_flags & TDF_SINTR); > + MPASS((td->td_sleepqueue != NULL) ^ (td->td_flags & TDF_SINTR)); > mtx_unlock_spin(&sc->sc_lock); > > /* See if there are any pending signals for this thread. */ This is running on mx2 right now. -- Peter Wemm - peter_at_wemm.org; peter_at_FreeBSD.org; peter_at_yahoo-inc.com; KI6FJV "All of this is for nothing if we don't go to the stars" - JMS/B5 "If Java had true garbage collection, most programs would delete themselves upon execution." -- Robert SewellReceived on Mon Sep 08 2008 - 22:44:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:35 UTC