Re: Console freeze but still alive

In message <20050210210002.GA679_at_lucy.pool-70-104-70-104.pskn.east.verizon.net>
, Skip Ford writes:
>Ian Dowse wrote:
>> FYI, I saw something similar once when I was testing my recent
>> callout changes, but I haven't seen it happen since. If the problem
>> did just appear around Sunday/Monday then I guess it could be
>> related...
>
>Yes, reverting your callout changes fixes the problem for me.
>
>In my case, with your changes the console worked fine unless I
>started X.  When switching from or exiting X, the screen would
>stay blank.  The shell still works at that point, I just couldn't
>see it.
>
>Changing video modes with vidcontrol didn't help.  My startup
>scripts do change the video mode for all screens.  I don't use
>moused at all FWIW.

Thanks for the information. Could you try the following patch? It's
probably unlikely to help, but is the only potential issue I've
spotted so far.

(In the time that a process is waiting to acquire Giant, it seems
possible that a CALLOUT_LOCAL_ALLOC callout from timeout() could
be recycled and then cancelled by another thread, causing the wrong
callout to be stopped. This patch ensures that the new callout
cancelling mechanism never applies to these timeout() callouts).

Ian

Index: kern_timeout.c
===================================================================
RCS file: /dump/FreeBSD-CVS/src/sys/kern/kern_timeout.c,v
retrieving revision 1.96
diff -u -r1.96 kern_timeout.c
--- kern_timeout.c	7 Feb 2005 02:47:33 -0000	1.96
+++ kern_timeout.c	10 Feb 2005 22:06:58 -0000
_at__at_ -251,11 +251,12 _at__at_
 					c->c_flags = CALLOUT_LOCAL_ALLOC;
 					SLIST_INSERT_HEAD(&callfree, c,
 							  c_links.sle);
+					curr_callout = NULL;
 				} else {
 					c->c_flags =
 					    (c->c_flags & ~CALLOUT_PENDING);
+					curr_callout = c;
 				}
-				curr_callout = c;
 				curr_cancelled = 0;
 				mtx_unlock_spin(&callout_lock);
 				if (c_mtx != NULL) {