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