2007/6/5, John Baldwin <[EMAIL PROTECTED]>:
On Tuesday 05 June 2007 11:43:03 am Attilio Rao wrote: > 2007/6/5, Attilio Rao <[EMAIL PROTECTED]>: > > 2007/6/5, Bruce Evans <[EMAIL PROTECTED]>: > > > > > > I get a "spin lock held too long" panic during (an interrupt in?) acpi > > > initialization on booting non-PREEMPTION SCHED_4BSD SMP. Haven't tried > > > other cases. > > > > Do you have a backtrace or any other debugging stuffs available? > > Mmm, I think I got the bug. > basically, in kern_mutex.c::_mtx_unlock_sleep(), in the not-preemptive > case what happens at some point is: > > td = curthread; > if (td->td_critnest > 0 || td1->td_priority >= td->td_priority) > return; > > thread_lock(td1); > if (!TD_IS_RUNNING(td1)) { > ... > > mi_switch(SW_INVOL, NULL); > ... > } > thread_unlock(td1); > > Which is wrong beacause td1 is not curthread and really curthread > should be locked too when context switching. > > To a first look the idea is that td and td1 should be locked both, but > I just want more time to look better at it.If this is the old #ifndef PREEMPTION manual preemption stuff, then just remove it. I've been wanting to axe it for a while, rwlocks don't do the manual preemption either, and if it is getting in the way it's best to just purge it.
Yes. More specifically, I always thought that code would just force a PREEMPTION point in the mtx_unlock(), instead it just happens in the !PREEMPTION case... is this a bug? I don't see why doing something like that in the !PREEMPTION point (but it can be I'm missing something :)). Attilio -- Peace can only be achieved by understanding - A. Einstein _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "[EMAIL PROTECTED]"
