You shouldn't get in there if it is 0, because then how would you call
close() on a device node with no references. So it's a bug to be in
spec_close with a 0 reference count.




On Tue, Jul 26, 2011 at 01:55:37PM +0000, Jeff Billimek wrote:
> Nicholas Marriott <nicholas.marriott <at> gmail.com> writes:
> 
> > 
> > Ah yes, I found an older version before.
> > 
> > It is much more likely to be a bug in the tty layer given this.
> 
> Hi Nicholas,
> 
> So given that these panics may be related to the tty layer, I've observed the 
> following behaviors as a user not running tmux (at least as far as I know) 
> that 
> may or may not be related to tty activity:
> 
> 1. The panics occur sometimes during shutdown & reboot - not during normal 
> usage
> 2. The panics have still occurred while _not_ running the 'screen' 
> application 
> (I originally thought that screen may be a culprit given it's heavy use of 
> tty 
> stuff) but may be able to rule that one out
> 3. I'm pretty sure these panics have all occurred when running either the 
> 'terminal' application or the 'iterm2' application
> 4. I'm pretty sure that these panics have always occurred when syslogd was 
> outputting log information to a fifo (named pipe)
> 5. On two other macs I'm running OS X 10.7 and do #3 & #4 with no panics so 
> far.
> 
> It is interesting that in the kernel code we referenced they are decrementing 
> si_opencount (vp->v_specinfo->si_opencount--;) immediately before checking to 
> see if it is negative (when it is negative they throw the panic).  There are 
> no 
> guards  or other visible code that I can see to suggest that si_opencount 
> should 
> be > 0 before the decrement occurs.
> 
> What I'm trying to figure out is: Is there any possibility that this issue 
> could 
> be hardware related or is it very likely that it is purely software?
> 
> 
> ------------------------------------------------------------------------------
> Magic Quadrant for Content-Aware Data Loss Prevention
> Research study explores the data loss prevention market. Includes in-depth
> analysis on the changes within the DLP market, and the criteria used to
> evaluate the strengths and weaknesses of these DLP solutions.
> http://www.accelacomm.com/jaw/sfnl/114/51385063/
> _______________________________________________
> tmux-users mailing list
> tmux-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tmux-users

------------------------------------------------------------------------------
Magic Quadrant for Content-Aware Data Loss Prevention
Research study explores the data loss prevention market. Includes in-depth
analysis on the changes within the DLP market, and the criteria used to
evaluate the strengths and weaknesses of these DLP solutions.
http://www.accelacomm.com/jaw/sfnl/114/51385063/
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users

Reply via email to