Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: Christos Zoulas <christos@zoulas.com>
List: netbsd-bugs
Date: 09/19/2006 17:55:02
The following reply was made to PR kern/32682; it has been noted by GNATS.

From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Tue, 19 Sep 2006 13:51:26 -0400

 On Sep 19,  2:32pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
 -- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
 
 | Am 25.07.2006 um 12:00 Uhr -0400 schrieb Christos Zoulas:
 | >On Jul 25,  2:26pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
 | >
 | >| >| But I still see matlab failing to open a /dev/pts/? every now and
 | >| >| then, although the /dev/ptmx && /dev/pts/? way should be the only way
 | >| >| to get a pty on the machine now, so no concurrent access, right?|
 | >|
 | >| Yet another data point: When another user logs in, with or without
 | >| running Matlab, this frequently "fixes" the pty problem for the first
 | >| user.
 | >|
 | >| >I have a theory. The pty returned by ptmx is not being marked as in
 | >| >use immediately, so it can be potentially returned twice to two different
 | >| >processes. I will check.
 | >|
 | >| Did you get any further with that theory?
 | >
 | >No, I have not and I am swamped between work and moving to a new apartment
 | >(I have no working internet or computers where I've moved yet).
 | >I will be more available in a couple of weeks, sorry.
 | 
 | Hi Christos,
 | 
 | have you found any time for looking into this in the meantime? I kind 
 | of get prodded daily over the issue...  ;)
 
 I am really sorry, I forgot about it. I just looked at it again, and
 I am curious about what it is trying to do with locking, can you try this?
 [I am not sure if it compiles but it should be close].
 
 Index: arch/i386/linux_termios.h
 ===================================================================
 RCS file: /cvsroot/src/sys/compat/linux/arch/i386/linux_termios.h,v
 retrieving revision 1.7
 diff -u -u -r1.7 linux_termios.h
 --- arch/i386/linux_termios.h	11 Dec 2005 12:20:14 -0000	1.7
 +++ arch/i386/linux_termios.h	19 Sep 2006 17:37:52 -0000
 @@ -82,6 +82,7 @@
  #define LINUX_TCSBRKP		_LINUX_IO('T', 37)
  #define LINUX_TIOCTTYGSTRUCT	_LINUX_IO('T', 38)
  #define LINUX_TIOCGPTN		_LINUX_IO('T', 48)
 +#define LINUX_TIOCSPTLCK	_LINUX_IO('T', 49)
  
  #define LINUX_FIONCLEX		_LINUX_IO('T', 80)
  #define LINUX_FIOCLEX		_LINUX_IO('T', 81)
 Index: common/linux_termios.c
 ===================================================================
 RCS file: /cvsroot/src/sys/compat/linux/common/linux_termios.c,v
 retrieving revision 1.25
 diff -u -u -r1.25 linux_termios.c
 --- common/linux_termios.c	15 Feb 2006 09:31:17 -0000	1.25
 +++ common/linux_termios.c	19 Sep 2006 17:37:52 -0000
 @@ -340,6 +340,17 @@
  		}
  #endif /* NO_DEV_PTM */
  #endif /* LINUX_TIOCGPTN */
 +#ifdef LINUX_TIOCGPTLCK
 +	case LINUX_TIOCPTLCK:
 +		{
 +			int tlock;
 +			error = copyin(SCARG(uap, data), &tlock, sizeof(tlock));
 +			if (error)
 +				return error;
 +			uprintf("TIOCPTLCK %d\n", lock);
 +			return 0;
 +		}
 +#endif
  	default:
  		error = EINVAL;
  		goto out;
 
 christos