NetBSD Problem Report #32682
From hf@spg.tu-darmstadt.de Tue Jan 31 17:24:17 2006
Return-Path: <hf@spg.tu-darmstadt.de>
Received: from bounce.nt.e-technik.tu-darmstadt.de (bounce.nt.e-technik.tu-darmstadt.de [130.83.197.1])
by narn.netbsd.org (Postfix) with ESMTP id 5938A63B876
for <gnats-bugs@gnats.NetBSD.org>; Tue, 31 Jan 2006 17:24:16 +0000 (UTC)
Message-Id: <200601311724.k0VHO5Uv020555@Wintersberg.nt.e-technik.tu-darmstadt.de>
Date: Tue, 31 Jan 2006 18:24:05 +0100 (CET)
From: Hauke Fath <hf@spg.tu-darmstadt.de>
Reply-To: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@netbsd.org
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: netbsd-3 ptyfs intermittent failure with Matlab
X-Send-Pr-Version: 3.95
>Number: 32682
>Category: kern
>Synopsis: netbsd-3 ptyfs intermittent failure with Matlab
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: kern-bug-people
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue Jan 31 17:25:00 +0000 2006
>Last-Modified: Fri Oct 06 20:00:02 +0000 2006
>Originator: Hauke Fath <hf@spg.tu-darmstadt.de>
>Release: NetBSD 3.0_STABLE
>Organization:
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
>Environment:
System: NetBSD Wintersberg 3.0_STABLE NetBSD 3.0_STABLE (SPG_PIII) #1: Mon Jan 23 18:52:48 CET 2006 hf@Heiligenberg:/var/obj/netbsd-builds/3_0/i386/sys/arch/i386/compile/SPG_PIII i386
Architecture: i386
Machine: i386
>Description:
With the pty subsystem that comes with NetBSD 3, Matlab
expects to find its ptys in /dev/pts. Every once in a while,
the required pty cannot be created, which results in Matlab 13
issuing dire warnings ("...no background processes/job
control/blah"), and Matlab 14 simply aborting.
Sometimes the problem "goes away" after some tens of minutes,
at other times it needs a reboot to "fix". It is more likely
to appear with several users logged in on the machine.
The end of a Matlab 14 ktrace looks like
[...]
883 MATLAB NAMI "/dev/ptmx"
883 MATLAB RET open 7
883 MATLAB CALL ioctl(7,_IO('T',0x1,0),0xbfbf535c)
883 MATLAB RET ioctl 0
883 MATLAB CALL ioctl(7,_IOW('T',0x30,0x4),0xbfbf541c)
883 MATLAB GIO fd 7 read 40 bytes
"\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
883 MATLAB RET ioctl 0
883 MATLAB CALL stat64(0xbfbf54f0,0xbfbf5440)
883 MATLAB NAMI "/emul/linux/dev/pts/4"
883 MATLAB NAMI "/dev/pts/4"
883 MATLAB RET stat64 0
883 MATLAB CALL statfs(0xbfbf54f0,0xbfbf64f0)
883 MATLAB NAMI "/emul/linux/dev/pts/4"
883 MATLAB NAMI "/dev/pts/4"
883 MATLAB RET statfs 0
883 MATLAB CALL ioctl(7,_IOR('T',0x31,0x4),0xbfbf6528)
883 MATLAB RET ioctl -1 errno -22 Invalid argument
883 MATLAB CALL ioctl(7,_IO('T',0x1,0),0xbfbf63cc)
883 MATLAB RET ioctl 0
883 MATLAB CALL ioctl(7,_IOW('T',0x30,0x4),0xbfbf648c)
883 MATLAB GIO fd 7 read 40 bytes
"\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
883 MATLAB RET ioctl 0
883 MATLAB CALL stat64(0xbd3dd888,0xbfbf64b0)
883 MATLAB NAMI "/emul/linux/dev/pts/4"
883 MATLAB NAMI "/dev/pts/4"
883 MATLAB RET stat64 0
883 MATLAB CALL rt_sigaction(0x11,0xbfbf6200,0xbfbf6170,8)
883 MATLAB RET rt_sigaction 0
883 MATLAB CALL rt_sigprocmask(1,0xbfbf6380,0,8)
883 MATLAB RET rt_sigprocmask 0
883 MATLAB CALL open(0xbac662e0,0x8002,0)
883 MATLAB NAMI "/emul/linux/dev/pts/4"
883 MATLAB NAMI "/dev/pts/4"
883 MATLAB RET open -1 errno -13 Permission denied
883 MATLAB CALL rt_sigprocmask(1,0xbfbf02b0,0,8)
883 MATLAB RET rt_sigprocmask 0
883 MATLAB CALL kill(0x373, SIGABRT)
883 MATLAB RET kill 0
883 MATLAB PSIG SIGABRT SIG_DFL
883 MATLAB NAMI "MATLAB.core"
27966 MATLAB RET poll 0
27966 MATLAB CALL getppid
27966 MATLAB RET getppid 1
27966 MATLAB CALL kill(0x6db7, SIGKILL)
27966 MATLAB RET kill -1 errno -3 No such process
27966 MATLAB CALL kill(0x1518, SIGKILL)
27966 MATLAB RET kill 0
5400 MATLAB RET nanosleep -1 errno -4 Interrupted system call
5400 MATLAB PSIG SIGKILL SIG_DFL
27966 MATLAB PSIG SIGRT1 caught handler=0xbd4c2eb0 mask=(1,2,3,4,6,8,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,30,31,32,33))
27966 MATLAB CALL sigreturn(0x80a14b4)
27966 MATLAB RET sigreturn -1 errno -2 No such file or directory
27966 MATLAB CALL exit_group(0)
where
[hf@Wintersberg] /var/tmp > ll /dev/pts
total 0
0 crw-rw-rw- 1 root wheel 5, 0 Jan 29 22:56 0
0 crw-rw-rw- 1 root wheel 5, 1 Jan 31 03:15 1
0 crw-rw-rw- 1 root wheel 5, 2 Jan 31 00:17 2
0 crw--w---- 1 cbrown tty 5, 3 Jan 20 16:48 3
0 crw--w---- 1 hf tty 5, 5 Jan 31 18:04 5
[hf@Wintersberg] /var/tmp >
The Matlab core and ktrace.out are at
http://www.spg.tu-darmstadt.de/~hf/netbsd/matlab-ptyfs-pr.tar.bz2
(4.3 MB).
>How-To-Repeat:
Start Matlab 13/14 on a NetBSD/i386 3 machine. Try a few
times, from different user accounts.
>Fix:
None, sorry.
>Audit-Trail:
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org
Cc:
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Tue, 31 Jan 2006 12:52:19 -0500
On Jan 31, 5:25pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| >Number: 32682
| >Category: kern
| >Synopsis: netbsd-3 ptyfs intermittent failure with Matlab
| >Confidential: no
| >Severity: serious
| >Priority: medium
| >Responsible: kern-bug-people
| >State: open
| >Class: sw-bug
| >Submitter-Id: net
| >Arrival-Date: Tue Jan 31 17:25:00 +0000 2006
| >Originator: Hauke Fath <hf@spg.tu-darmstadt.de>
| >Release: NetBSD 3.0_STABLE
| >Organization:
| --
| /~\ The ASCII Ribbon Campaign Hauke Fath
| \ / No HTML/RTF in email Institut für Nachrichtentechnik
| X No Word docs in email TU Darmstadt
| / \ Respect for open standards Ruf +49-6151-16-3281
| >Environment:
|
|
| System: NetBSD Wintersberg 3.0_STABLE NetBSD 3.0_STABLE (SPG_PIII) #1: Mon Jan 23 18:52:48 CET 2006 hf@Heiligenberg:/var/obj/netbsd-builds/3_0/i386/sys/arch/i386/compile/SPG_PIII i386
| Architecture: i386
| Machine: i386
| >Description:
|
| With the pty subsystem that comes with NetBSD 3, Matlab
| expects to find its ptys in /dev/pts. Every once in a while,
| the required pty cannot be created, which results in Matlab 13
| issuing dire warnings ("...no background processes/job
| control/blah"), and Matlab 14 simply aborting.
|
| Sometimes the problem "goes away" after some tens of minutes,
| at other times it needs a reboot to "fix". It is more likely
| to appear with several users logged in on the machine.
|
| The end of a Matlab 14 ktrace looks like
|
| [...]
|
| 883 MATLAB NAMI "/dev/ptmx"
| 883 MATLAB RET open 7
| 883 MATLAB CALL ioctl(7,_IO('T',0x1,0),0xbfbf535c)
| 883 MATLAB RET ioctl 0
| 883 MATLAB CALL ioctl(7,_IOW('T',0x30,0x4),0xbfbf541c)
| 883 MATLAB GIO fd 7 read 40 bytes
| "\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
| 883 MATLAB RET ioctl 0
| 883 MATLAB CALL stat64(0xbfbf54f0,0xbfbf5440)
| 883 MATLAB NAMI "/emul/linux/dev/pts/4"
| 883 MATLAB NAMI "/dev/pts/4"
| 883 MATLAB RET stat64 0
| 883 MATLAB CALL statfs(0xbfbf54f0,0xbfbf64f0)
| 883 MATLAB NAMI "/emul/linux/dev/pts/4"
| 883 MATLAB NAMI "/dev/pts/4"
| 883 MATLAB RET statfs 0
| 883 MATLAB CALL ioctl(7,_IOR('T',0x31,0x4),0xbfbf6528)
| 883 MATLAB RET ioctl -1 errno -22 Invalid argument
| 883 MATLAB CALL ioctl(7,_IO('T',0x1,0),0xbfbf63cc)
| 883 MATLAB RET ioctl 0
| 883 MATLAB CALL ioctl(7,_IOW('T',0x30,0x4),0xbfbf648c)
| 883 MATLAB GIO fd 7 read 40 bytes
| "\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
| 883 MATLAB RET ioctl 0
| 883 MATLAB CALL stat64(0xbd3dd888,0xbfbf64b0)
| 883 MATLAB NAMI "/emul/linux/dev/pts/4"
| 883 MATLAB NAMI "/dev/pts/4"
| 883 MATLAB RET stat64 0
| 883 MATLAB CALL rt_sigaction(0x11,0xbfbf6200,0xbfbf6170,8)
| 883 MATLAB RET rt_sigaction 0
| 883 MATLAB CALL rt_sigprocmask(1,0xbfbf6380,0,8)
| 883 MATLAB RET rt_sigprocmask 0
| 883 MATLAB CALL open(0xbac662e0,0x8002,0)
| 883 MATLAB NAMI "/emul/linux/dev/pts/4"
| 883 MATLAB NAMI "/dev/pts/4"
| 883 MATLAB RET open -1 errno -13 Permission denied
| 883 MATLAB CALL rt_sigprocmask(1,0xbfbf02b0,0,8)
| 883 MATLAB RET rt_sigprocmask 0
| 883 MATLAB CALL kill(0x373, SIGABRT)
| 883 MATLAB RET kill 0
| 883 MATLAB PSIG SIGABRT SIG_DFL
| 883 MATLAB NAMI "MATLAB.core"
| 27966 MATLAB RET poll 0
| 27966 MATLAB CALL getppid
| 27966 MATLAB RET getppid 1
| 27966 MATLAB CALL kill(0x6db7, SIGKILL)
| 27966 MATLAB RET kill -1 errno -3 No such process
| 27966 MATLAB CALL kill(0x1518, SIGKILL)
| 27966 MATLAB RET kill 0
| 5400 MATLAB RET nanosleep -1 errno -4 Interrupted system call
| 5400 MATLAB PSIG SIGKILL SIG_DFL
| 27966 MATLAB PSIG SIGRT1 caught handler=0xbd4c2eb0 mask=(1,2,3,4,6,8,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,30,31,32,33))
| 27966 MATLAB CALL sigreturn(0x80a14b4)
| 27966 MATLAB RET sigreturn -1 errno -2 No such file or directory
| 27966 MATLAB CALL exit_group(0)
|
| where
|
| [hf@Wintersberg] /var/tmp > ll /dev/pts
| total 0
| 0 crw-rw-rw- 1 root wheel 5, 0 Jan 29 22:56 0
| 0 crw-rw-rw- 1 root wheel 5, 1 Jan 31 03:15 1
| 0 crw-rw-rw- 1 root wheel 5, 2 Jan 31 00:17 2
| 0 crw--w---- 1 cbrown tty 5, 3 Jan 20 16:48 3
| 0 crw--w---- 1 hf tty 5, 5 Jan 31 18:04 5
| [hf@Wintersberg] /var/tmp >
|
| The Matlab core and ktrace.out are at
| http://www.spg.tu-darmstadt.de/~hf/netbsd/matlab-ptyfs-pr.tar.bz2
| (4.3 MB).
|
| >How-To-Repeat:
|
| Start Matlab 13/14 on a NetBSD/i386 3 machine. Try a few
| times, from different user accounts.
Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
I suspect what is going on, is that you have a rogue program that is
opening old style pty's behind the pty subsystem's back, so when ptyfs
tries to open the same pty, it fails. So when it fails for pts/4 for
example, what does lsof say for /dev/{t,p}typ4?
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 2 Feb 2006 16:54:03 +0100
Gnah, when you want the bug, it doesn't show...
A coworker reported it once with a -current kernel though, so it's
not strictly netbsd-3.
Am 31.01.2006 um 17:55 Uhr +0000 schrieb Christos Zoulas:
> Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
> I suspect what is going on, is that you have a rogue program that is
> opening old style pty's behind the pty subsystem's back, so when ptyfs
> tries to open the same pty, it fails.
Sounds reasonable...
>So when it fails for pts/4 for example, what does lsof say for /dev/{t,p}typ4?
I'll keep on trying,
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
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: Wed, 8 Feb 2006 16:55:02 +0100
I finally managed to get hold of an error instance...
Ktracing Matlab 14 gave me
[tj@Katzenbuckel clpois]$ kdump | less
[...]
25647 MATLAB CALL open(0xbac662e0,0x8002,0)
25647 MATLAB NAMI "/emul/linux/dev/pts/5"
25647 MATLAB NAMI "/dev/pts/5"
25647 MATLAB RET open -1 errno -13 Permission denied
Am 31.01.2006 um 12:52 Uhr -0500 schrieb Christos Zoulas:
>Can you show what w(1) prints
Katzenbuckel# w
1:20PM up 6 days, 5:46, 1 user, load averages: 1.19, 1.49, 1.59
USER TTY FROM LOGIN@ IDLE WHAT
tj :0 - Thu07AM ? /bin/sh /usr/pkg/bin/startkde
>and the "interesting" ptys in /dev/[pt]ty??.
[tj@Katzenbuckel clpois]$ ll /dev/pts/
total 31
dr-xr-xr-x 1 root wheel 512 Feb 2 07:50 ./
drwxr-xr-x 5 root wheel 30720 Oct 23 03:27 ../
crw-rw-rw- 1 root wheel 3, 0 Oct 22 23:25 0
crw-rw-rw- 1 root wheel 3, 1 Feb 3 03:15 1
crw-rw-rw- 1 root wheel 3, 2 Feb 8 07:21 2
crw--w---- 1 hf tty 3, 3 Feb 2 11:28 3
crw-rw-rw- 1 root wheel 3, 4 Feb 8 09:39 4
>I suspect what is going on, is that you have a rogue program that is
>opening old style pty's behind the pty subsystem's back, so when ptyfs
>tries to open the same pty, it fails. So when it fails for pts/4 for
>example, what does lsof say for /dev/{t,p}typ4?
Is lsof tied to the OS version? I got a warning "...compiled for
NetBSD 2" and no output.
fstat(1) gave me
Katzenbuckel# fstat /dev/ttyp5
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
root fstat 8778 0 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root fstat 8778 1 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root fstat 8778 2 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root tcsh 19818 15 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root tcsh 19818 16 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root tcsh 19818 17 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root tcsh 19818 18 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
root tcsh 19818 19 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
hf tcsh 21122 15 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
hf tcsh 21122 16 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
hf tcsh 21122 17 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
hf tcsh 21122 18 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
hf tcsh 21122 19 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
tj bash 24622 0 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
tj bash 24622 1 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
tj bash 24622 2 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
tj bash 24622 255 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
tj kdeinit 902 20 / 1855043 crw-rw-rw- ttyp5 rw
/dev/ttyp5
Katzenbuckel# fstat /dev/ptyp5
USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
tj kdeinit 902 19 / 1854014 crw-rw-rw- ptyp5 rw
/dev/ptyp5
-- The latter is kind of interesting. What confused me, though, is
that after logging out and logging in again, Matlab did still fail
but an fstat for the relevant {p,t}typ? came up empty.
As a further data point, a coworker who uses Gnome exclusively claims
he has never seen the error (most of the people here use KDE). ISTR,
though, that I have seen Matlab fail under XFCE4 - which is set up to
start the KDE and Gnome daemons. Hmmm...
Anything else that I could check?
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
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: Wed, 8 Feb 2006 12:35:08 -0500
On Feb 8, 4:55pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| I finally managed to get hold of an error instance...
|
| Ktracing Matlab 14 gave me
|
| [tj@Katzenbuckel clpois]$ kdump | less
|
| [...]
|
| 25647 MATLAB CALL open(0xbac662e0,0x8002,0)
| 25647 MATLAB NAMI "/emul/linux/dev/pts/5"
| 25647 MATLAB NAMI "/dev/pts/5"
| 25647 MATLAB RET open -1 errno -13 Permission denied
|
|
| Am 31.01.2006 um 12:52 Uhr -0500 schrieb Christos Zoulas:
| >Can you show what w(1) prints
|
| Katzenbuckel# w
| 1:20PM up 6 days, 5:46, 1 user, load averages: 1.19, 1.49, 1.59
| USER TTY FROM LOGIN@ IDLE WHAT
| tj :0 - Thu07AM ? /bin/sh /usr/pkg/bin/startkde
|
| >and the "interesting" ptys in /dev/[pt]ty??.
|
| [tj@Katzenbuckel clpois]$ ll /dev/pts/
| total 31
| dr-xr-xr-x 1 root wheel 512 Feb 2 07:50 ./
| drwxr-xr-x 5 root wheel 30720 Oct 23 03:27 ../
| crw-rw-rw- 1 root wheel 3, 0 Oct 22 23:25 0
| crw-rw-rw- 1 root wheel 3, 1 Feb 3 03:15 1
| crw-rw-rw- 1 root wheel 3, 2 Feb 8 07:21 2
| crw--w---- 1 hf tty 3, 3 Feb 2 11:28 3
| crw-rw-rw- 1 root wheel 3, 4 Feb 8 09:39 4
|
| >I suspect what is going on, is that you have a rogue program that is
| >opening old style pty's behind the pty subsystem's back, so when ptyfs
| >tries to open the same pty, it fails. So when it fails for pts/4 for
| >example, what does lsof say for /dev/{t,p}typ4?
|
| Is lsof tied to the OS version? I got a warning "...compiled for
| NetBSD 2" and no output.
|
| fstat(1) gave me
|
| Katzenbuckel# fstat /dev/ttyp5
| USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
| root fstat 8778 0 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root fstat 8778 1 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root fstat 8778 2 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root tcsh 19818 15 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root tcsh 19818 16 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root tcsh 19818 17 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root tcsh 19818 18 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| root tcsh 19818 19 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| hf tcsh 21122 15 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| hf tcsh 21122 16 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| hf tcsh 21122 17 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| hf tcsh 21122 18 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| hf tcsh 21122 19 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| tj bash 24622 0 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| tj bash 24622 1 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| tj bash 24622 2 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| tj bash 24622 255 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| tj kdeinit 902 20 / 1855043 crw-rw-rw- ttyp5 rw
| /dev/ttyp5
| Katzenbuckel# fstat /dev/ptyp5
| USER CMD PID FD MOUNT INUM MODE SZ|DV R/W NAME
| tj kdeinit 902 19 / 1854014 crw-rw-rw- ptyp5 rw
| /dev/ptyp5
|
|
| -- The latter is kind of interesting. What confused me, though, is
| that after logging out and logging in again, Matlab did still fail
| but an fstat for the relevant {p,t}typ? came up empty.
|
| As a further data point, a coworker who uses Gnome exclusively claims
| he has never seen the error (most of the people here use KDE). ISTR,
| though, that I have seen Matlab fail under XFCE4 - which is set up to
| start the KDE and Gnome daemons. Hmmm...
|
| Anything else that I could check?
|
| hauke
This is great information. Now what application opened the pty? kde terminal?
This is the application that is not using openpty and it is trying to open
pty's directly.
christos
From: Mark Davies <mark@mcs.vuw.ac.nz>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 9 Feb 2006 08:40:25 +1300
On Thursday 09 February 2006 06:40, Christos Zoulas wrote:
> This is great information. Now what application opened the pty? kde
> terminal? This is the application that is not using openpty and it is
> trying to open pty's directly.
konsole (the kde terminal) uses the KPty class to deal with pty's. There is
conditional code in KPty to use openpty and for me at least on current
configure sets HAVE_OPENPTY to use it, dont know if thats the case for Hauke.
cheers
mark
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org, Hauke Fath <hf@spg.tu-darmstadt.de>
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Wed, 22 Feb 2006 16:47:49 +0100
Am 02.02.2006 um 15:55 Uhr +0000 schrieb Hauke Fath:
> Gnah, when you want the bug, it doesn't show...
>
> A coworker reported it once with a -current kernel though, so it's
> not strictly netbsd-3.
>
> Am 31.01.2006 um 17:55 Uhr +0000 schrieb Christos Zoulas:
> > Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
> > I suspect what is going on, is that you have a rogue program that is
> > opening old style pty's behind the pty subsystem's back, so when ptyfs
> > tries to open the same pty, it fails.
>
> Sounds reasonable...
>
> >So when it fails for pts/4 for example, what does lsof say for
>/dev/{t,p}typ4?
Doesn't look that easy.
I just encountered the bug on an idle machine that I had logged into
remotely, i.e. no KDE stuff running (the login prompter is gdm, and
there were a few leftover dbus-daemon-1 processes).
Matlab 14 aborted, and a ktrace showed me it wanted /dev/pts/1 but
didn't get it. The fstat /dev/{t,p}typ1 came up _empty_.
I opened another remote xterm, became root to install the lsof
package. The second login did successfully create /dev/pts/1. After
that, Matlab would start up just fine, and create a /dev/pts/2, but
owned root:wheel unlike 0 and 1 which were owned by my id, group tty.
Any ideas about where to go from here?
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>, gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Wed, 22 Feb 2006 13:17:58 -0500
On Feb 22, 4:47pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Doesn't look that easy.
|
| I just encountered the bug on an idle machine that I had logged into
| remotely, i.e. no KDE stuff running (the login prompter is gdm, and
| there were a few leftover dbus-daemon-1 processes).
|
| Matlab 14 aborted, and a ktrace showed me it wanted /dev/pts/1 but
| didn't get it. The fstat /dev/{t,p}typ1 came up _empty_.
|
| I opened another remote xterm, became root to install the lsof
| package. The second login did successfully create /dev/pts/1. After
| that, Matlab would start up just fine, and create a /dev/pts/2, but
| owned root:wheel unlike 0 and 1 which were owned by my id, group tty.
|
| Any ideas about where to go from here?
Can you ktrace the pty transactions on a successful matlab pty creation?
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@netbsd.org
Cc: Christos Zoulas <christos@zoulas.com>
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 23 Feb 2006 10:36:35 +0100
Christos Zoulas wrote:
>
> Can you ktrace the pty transactions on a successful matlab pty creation?
Here you are (~500 KBytes):
http://www.spg.tu-darmstadt.de/~hf/kern-32682/matlab-ktrace-2006-02-23.tar.bz2
That's the binary -- would you prefer the kdump ascii output instead?
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@netbsd.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
Hauke Fath <hf@spg.tu-darmstadt.de>
Cc:
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 23 Feb 2006 12:33:28 -0500
On Feb 23, 9:40am, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| The following reply was made to PR kern/32682; it has been noted by GNATS.
|
| From: Hauke Fath <hf@spg.tu-darmstadt.de>
| To: gnats-bugs@netbsd.org
| Cc: Christos Zoulas <christos@zoulas.com>
| Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Date: Thu, 23 Feb 2006 10:36:35 +0100
|
| Christos Zoulas wrote:
| >
| > Can you ktrace the pty transactions on a successful matlab pty creation?
|
| Here you are (~500 KBytes):
|
| http://www.spg.tu-darmstadt.de/~hf/kern-32682/matlab-ktrace-2006-02-23.tar.bz2
|
| That's the binary -- would you prefer the kdump ascii output instead?
|
No, got it. It looks fine to me. There are some namei's to /dev/ptyXX which
are weird. Have you tried removing /dev/pty* and /dev/tty* [the pseudo's
only, not the serial or wscons].
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 23 Feb 2006 18:53:44 +0100
Am 23.02.2006 um 12:33 Uhr -0500 schrieb Christos Zoulas:
>Have you tried removing /dev/pty* and /dev/tty* [the pseudo's
>only, not the serial or wscons].
No, I haven't. Wouldn't that hurt anything else?
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 23 Feb 2006 13:22:05 -0500
On Feb 23, 6:53pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Am 23.02.2006 um 12:33 Uhr -0500 schrieb Christos Zoulas:
| >Have you tried removing /dev/pty* and /dev/tty* [the pseudo's
| >only, not the serial or wscons].
|
| No, I haven't. Wouldn't that hurt anything else?
|
| hauke
Some ancient packages in pkgsrc might depend on /dev/pty** but these
days the world is linux, so most things will work. Our base software
definitely works.
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
christos@zoulas.com (Christos Zoulas)
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Fri, 24 Feb 2006 18:00:15 +0100
Am 23.02.2006 um 18:25 Uhr +0000 schrieb Christos Zoulas:
> | No, I haven't. Wouldn't that hurt anything else?
> |
> | hauke
>
> Some ancient packages in pkgsrc might depend on /dev/pty** but these
> days the world is linux, so most things will work. Our base software
> definitely works.
Kool -- the Krappy KDE 'konsole' thingie barfs because it cannot get
a pty. Unfortunately, that is pretty popular around here.
Does it matter that all the packages we use here were built on
netbsd-2? I.e. would a KDE built on netbsd-3 automagically use
/dev/ptmx?
hauke (off to go skiing for a week now :)
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>, gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Fri, 24 Feb 2006 15:19:22 -0500
On Feb 24, 6:00pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Am 23.02.2006 um 18:25 Uhr +0000 schrieb Christos Zoulas:
| > | No, I haven't. Wouldn't that hurt anything else?
| > |
| > | hauke
| >
| > Some ancient packages in pkgsrc might depend on /dev/pty** but these
| > days the world is linux, so most things will work. Our base software
| > definitely works.
|
| Kool -- the Krappy KDE 'konsole' thingie barfs because it cannot get
| a pty. Unfortunately, that is pretty popular around here.
|
| Does it matter that all the packages we use here were built on
| netbsd-2? I.e. would a KDE built on netbsd-3 automagically use
| /dev/ptmx?
|
I believe that if you recompile it, it will find the posix pty stuff.
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Mon, 17 Jul 2006 16:54:30 +0200
Am 31.01.2006 um 12:52 Uhr -0500 schrieb Christos Zoulas:
>
>Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
>I suspect what is going on, is that you have a rogue program that is
>opening old style pty's behind the pty subsystem's back, so when ptyfs
>tries to open the same pty, it fails. So when it fails for pts/4 for
>example, what does lsof say for /dev/{t,p}typ4?
Getting back to this after a while...
I have pkgsrc-2006Q1 packages out now which were built on a machine
without the /dev/[pt]ty[pqrs]? pty device files, and deployed on
clients that do not have them, either, but use ptyfs mounted to
/dev/pts instead.
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?
The details:
[ kdump | tail ...]
25589 MATLAB CALL open(0xb9f56725,0x8002,0)
25589 MATLAB NAMI "/emul/linux/dev/ptmx"
25589 MATLAB NAMI "/dev/ptmx"
25589 MATLAB RET open 8
25589 MATLAB CALL ioctl(8,_IO('T',0x1,0),0xbfbf537c)
25589 MATLAB RET ioctl 0
25589 MATLAB CALL ioctl(8,_IOW('T',0x30,0x4),0xbfbf54ac)
25589 MATLAB GIO fd 8 read 40 bytes
"\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
25589 MATLAB RET ioctl 0
25589 MATLAB CALL stat64(0xbfbf54fc,0xbfbf5434)
25589 MATLAB NAMI "/emul/linux/dev/pts/4"
25589 MATLAB NAMI "/dev/pts/4"
25589 MATLAB RET stat64 0
25589 MATLAB CALL statfs(0xbfbf54fc,0xbfbf64fc)
25589 MATLAB NAMI "/emul/linux/dev/pts/4"
25589 MATLAB NAMI "/dev/pts/4"
25589 MATLAB RET statfs 0
25589 MATLAB CALL ioctl(8,_IOR('T',0x31,0x4),0xbfbf6538)
25589 MATLAB RET ioctl -1 errno -22 Invalid argument
25589 MATLAB CALL ioctl(8,_IO('T',0x1,0),0xbfbf63ec)
25589 MATLAB RET ioctl 0
25589 MATLAB CALL ioctl(8,_IOW('T',0x30,0x4),0xbfbf651c)
25589 MATLAB GIO fd 8 read 40 bytes
"\^D\0\0\0\^D\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/4\0\0\0\0\0\0"
25589 MATLAB RET ioctl 0
25589 MATLAB CALL stat64(0xbd3d5810,0xbfbf64a4)
25589 MATLAB NAMI "/emul/linux/dev/pts/4"
25589 MATLAB NAMI "/dev/pts/4"
25589 MATLAB RET stat64 0
25589 MATLAB CALL rt_sigaction(0x11,0xbfbf6218,0xbfbf618c,8)
25589 MATLAB RET rt_sigaction 0
25589 MATLAB CALL rt_sigprocmask(1,0xbfbf6390,0,8)
25589 MATLAB RET rt_sigprocmask 0
25589 MATLAB CALL open(0xba99b2d0,0x8002,0)
25589 MATLAB NAMI "/emul/linux/dev/pts/4"
25589 MATLAB NAMI "/dev/pts/4"
25589 MATLAB RET open -1 errno -13 Permission denied
25589 MATLAB CALL rt_sigprocmask(1,0xbfbf0350,0,8)
25589 MATLAB RET rt_sigprocmask 0
25589 MATLAB CALL kill(0x63f5, SIGABRT)
25589 MATLAB RET kill 0
25589 MATLAB PSIG SIGABRT SIG_DFL
25589 MATLAB NAMI "MATLAB.core"
14493 MATLAB RET poll 0
14493 MATLAB CALL getppid
14493 MATLAB RET getppid 1
14493 MATLAB CALL kill(0x572a, SIGKILL)
14493 MATLAB RET kill -1 errno -3 No such process
14493 MATLAB CALL kill(0x1543, SIGKILL)
14493 MATLAB RET kill 0
5443 MATLAB RET nanosleep -1 errno -4 Interrupted system call
5443 MATLAB PSIG SIGKILL SIG_DFL
14493 MATLAB PSIG SIGRT1 caught handler=0xbd4be460
mask=(1,2,3,4,6,8,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,30,31,32,33))
14493 MATLAB CALL sigreturn(0x80a1ec0)
14493 MATLAB RET sigreturn -1 errno -2 No such file or directory
14493 MATLAB CALL exit_group(0)
[hf@Auernig] /<1>tmp/matlab-issues > uname -a
NetBSD Auernig.nt.e-technik.tu-darmstadt.de 3.0_STABLE NetBSD
3.0_STABLE (SPG_PIII) #0: Wed May 31 13:18:31 CEST 2006
hf@Gstoder.nt.e-technik.tu-darmstadt.de:/var/obj/netbsd-builds/3_0/i386/sys/arch/i386/compile/SPG_PIII
i386
[hf@Auernig] /<1>tmp/matlab-issues > ls -la /dev/pts/
total 31
dr-xr-xr-x 1 root wheel 512 Jun 23 03:15 .
drwxr-xr-x 5 root wheel 30720 Jul 12 03:32 ..
crw--w---- 1 ruebsam tty 5, 0 Jun 22 09:04 0
crw--w---- 1 ruebsam tty 5, 1 Jul 17 16:25 1
crw------- 1 ruebsam tty 5, 2 Jul 17 14:15 2
crw--w---- 1 hf tty 5, 3 Jul 17 16:28 3
[hf@Auernig] /<1>tmp/matlab-issues > ls -la /dev/[pt]ty??
crw-rw---- 1 uucp persons 8, 0 Jun 16 2005 /dev/tty00
crw------- 1 uucp wheel 8, 1 Jun 16 2005 /dev/tty01
crw------- 1 uucp wheel 8, 2 Jun 16 2005 /dev/tty02
crw------- 1 uucp wheel 8, 3 Jun 16 2005 /dev/tty03
crw------- 1 root wheel 47, 0 Jun 23 03:15 /dev/ttyE0
crw------- 1 root wheel 47, 1 Jun 23 03:15 /dev/ttyE1
crw------- 1 root wheel 47, 2 Jun 23 03:15 /dev/ttyE2
crw------- 1 root wheel 47, 3 Jun 23 03:15 /dev/ttyE3
crw------- 1 root wheel 47, 4 Jun 16 2005 /dev/ttyE4
crw------- 1 root wheel 47, 5 Jun 16 2005 /dev/ttyE5
crw------- 1 root wheel 47, 6 Jun 16 2005 /dev/ttyE6
crw------- 1 root wheel 47, 7 Jun 16 2005 /dev/ttyE7
crw-rw---- 1 uucp persons 8, 0 Apr 20 03:28 /dev/ttyU0
crw------- 1 uucp wheel 66, 1 Jun 16 2005 /dev/ttyU1
[hf@Auernig] /<1>tmp/matlab-issues > w
4:33PM up 25 days, 7:31, 3 users, load averages: 2.23, 2.33, 2.22
USER TTY FROM LOGIN@ IDLE WHAT
ruebsam :0 - 8:30AM ? /bin/sh /usr/pkg/bin/startkde
ruebsam pts/1 :0.0 9:07AM 7 -tcsh
hf pts/3 localhost:10.0 3:55PM 0 w
[hf@Auernig] /<1>tmp/matlab-issues >
The complete ktrace and the matlab core are at
http://www.spg.tu-darmstadt.de/~hf/netbsd/pr32682/matlab-issues.tar.bz2
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
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, netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Mon, 17 Jul 2006 10:58:55 -0400
On Jul 17, 4:54pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Am 31.01.2006 um 12:52 Uhr -0500 schrieb Christos Zoulas:
| >
| >Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
| >I suspect what is going on, is that you have a rogue program that is
| >opening old style pty's behind the pty subsystem's back, so when ptyfs
| >tries to open the same pty, it fails. So when it fails for pts/4 for
| >example, what does lsof say for /dev/{t,p}typ4?
|
| Getting back to this after a while...
|
| I have pkgsrc-2006Q1 packages out now which were built on a machine
| without the /dev/[pt]ty[pqrs]? pty device files, and deployed on
| clients that do not have them, either, but use ptyfs mounted to
| /dev/pts instead.
|
| 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?
|
| The details:
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.
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: Hauke Fath <hf@spg.tu-darmstadt.de>, gnats-bugs@NetBSD.org,
kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Tue, 25 Jul 2006 14:26:10 +0200
Am 17.07.2006 um 10:58 Uhr -0400 schrieb Christos Zoulas:
>| 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?
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
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, netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Tue, 25 Jul 2006 12:00:51 -0400
On Jul 25, 2:26pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| Am 17.07.2006 um 10:58 Uhr -0400 schrieb Christos Zoulas:
| >| 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.
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Wed, 26 Jul 2006 13:38:46 +0200
Am 25.07.2006 um 12:00 Uhr -0400 schrieb Christos Zoulas:
>| 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.
SInce I am going to spend most of August on my bicycle, that will be
allright with me. ;)
And my coworkers will have to make do with the occaional reboot,
"just like on Windows(tm)".
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
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 14:32:49 +0200
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... ;)
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
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
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 21 Sep 2006 10:20:25 +0200
Am 19.09.2006 um 13:51 Uhr -0400 schrieb Christos Zoulas:
>I am really sorry, I forgot about it.
No problem. I am here to remind you. ;)
>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].
It applied with fuzz to netbsd-3 sources, and compiled. I deployed a
patched kernel last night, and on the first login to a coworker's
machine this morning I got the dreaded Matlab abort trap. There was
no console output or anything in the logs.
So, no change here, unfortunately.
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 21 Sep 2006 08:15:25 -0400
On Sep 21, 10:20am, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| It applied with fuzz to netbsd-3 sources, and compiled. I deployed a
| patched kernel last night, and on the first login to a coworker's
| machine this morning I got the dreaded Matlab abort trap. There was
| no console output or anything in the logs.
|
| So, no change here, unfortunately.
uprintf only prints on the user's terminal. If you want output on the
console, you just need printf. I am curious if it is passing it 0 or 1.
I knew this would not change things.
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 21 Sep 2006 14:48:01 +0200
Am 21.09.2006 um 8:15 Uhr -0400 schrieb Christos Zoulas:
>| So, no change here, unfortunately.
>
>uprintf only prints on the user's terminal.
Ah. There is no output there, either.
> If you want output on the
>console, you just need printf. I am curious if it is passing it 0 or 1.
It doesn't tell, see above.
>I knew this would not change things.
Ah, okay, so I misunderstood.
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 21 Sep 2006 09:45:12 -0400
On Sep 21, 2:48pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
| >uprintf only prints on the user's terminal.
|
| Ah. There is no output there, either.
Strange. Ok, next thing is to use our regression tests on linux and
see if we can reproduce the problem. If you put #ifdef __RCSID
around RCSID and compile the ptmx.c code in /usr/src/regress/lib/libc/pty
on linux using gcc -static ptmx.c -o ptmx and then copying and running
this on NetBSD what do you get?
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
gnats-bugs@NetBSD.org
Subject: Re: kern/32682: netbsd-3 ptyfs intermittent failure with Matlab
Date: Thu, 21 Sep 2006 16:17:06 +0200
Am 21.09.2006 um 9:45 Uhr -0400 schrieb Christos Zoulas:
>Ok, next thing is to use our regression tests on linux and
>see if we can reproduce the problem. If you put #ifdef __RCSID
>around RCSID and compile the ptmx.c code in /usr/src/regress/lib/libc/pty
>on linux using gcc -static ptmx.c -o ptmx and then copying and running
>this on NetBSD what do you get?
[hf@Hochschwab] ~/src/pr32682 > uname -a
NetBSD Hochschwab.nt.e-technik.tu-darmstadt.de 3.1_RC3 NetBSD 3.1_RC3
(SPG_PIII) #2: Wed Sep 20 13:37:50 CEST 2006
hf@Hochstuhl:/var/obj/netbsd-builds/3/i386/sys/arch/i386/compile/SPG_PIII
i386
[hf@Hochschwab] ~/src/pr32682 > ./ptmx
ptmx: bad slave uid 0 != 503
[hf@Hochschwab] ~/src/pr32682 >
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: Christos Zoulas <christos@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: PR/32682 CVS commit: src/sys/kern
Date: Fri, 22 Sep 2006 15:15:56 +0000 (UTC)
Module Name: src
Committed By: christos
Date: Fri Sep 22 15:15:56 UTC 2006
Modified Files:
src/sys/kern: tty_ptm.c
Log Message:
PR/32682: Hauke Fath: netbsd-3 ptyfs intermittent failure with Matlab
For the benefit of linux emulation create a new minor device '2'
which is a ptmx with linux semantics. Linux changes the permissions
of the slave pty upon creation, not when grantpt(3) is called. The
glibc linux grantpt(3) checks that the pty is on ptyfs, and if it is,
it does nothing. To make use of this fix:
mknod /emul/linux/dev/ptmx c 165 2
chmod 666 /emul/linux/dev/ptmx
This is a lot simpler than copying a bunch of code and creating a
ptmx device just for the benefit of linux emulation.
To generate a diff of this commit:
cvs rdiff -r1.11 -r1.12 src/sys/kern/tty_ptm.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
Christos Zoulas <christos@NetBSD.org>
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 22 Sep 2006 18:55:43 +0200
Am 22.09.2006 um 15:20 Uhr +0000 schrieb Christos Zoulas:
> Modified Files:
> src/sys/kern: tty_ptm.c
Cool...
I have applied
Index: tty_ptm.c
===================================================================
RCS file: /cvsroot/src/sys/kern/tty_ptm.c,v
retrieving revision 1.4
diff -u -r1.4 tty_ptm.c
--- tty_ptm.c 30 Nov 2004 04:25:44 -0000 1.4
+++ tty_ptm.c 22 Sep 2006 16:36:10 -0000
@@ -337,8 +337,24 @@
switch(minor(dev)) {
case 0: /* /dev/ptmx */
+ case 2: /* /emul/linux/dev/ptmx */
if ((error = pty_alloc_master(p, &fd, &dev)) != 0)
return error;
+ if (minor(dev) == 2) {
+ /*
+ * Linux ptyfs grants the pty right here.
+ * Handle this case here, instead of writing
+ * a new linux module.
+ */
+ if ((error = pty_grant_slave(p, dev)) != 0) {
+ struct file *fp =
+ fd_getfile(p->p_fd, fd);
+ FILE_UNUSE(fp, p);
+ fdremove(p->p_fd, fd);
+ ffree(fp);
+ return error;
+ }
+ }
curlwp->l_dupfd = fd;
return EMOVEFD;
case 1: /* /dev/ptm */
@@ -384,6 +400,7 @@
}
bad:
fp = fd_getfile(p->p_fd, cfd);
+ FILE_UNUSE(fp, p);
fdremove(p->p_fd, cfd);
ffree(fp);
return error;
to my netbsd-3 source tree and built a kernel that will be on the lab
machines tomorrow. I should have feedback early next week...
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: Hauke Fath <hf@spg.tu-darmstadt.de>, gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 22 Sep 2006 14:20:58 -0400
On Sep 22, 6:55pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: PR/32682 CVS commit: src/sys/kern
| Am 22.09.2006 um 15:20 Uhr +0000 schrieb Christos Zoulas:
| > Modified Files:
| > src/sys/kern: tty_ptm.c
|
| Cool...
|
| I have applied
You also need to create the device node... Hopefully it will work.
christos
From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
Hauke Fath <hf@spg.tu-darmstadt.de>,
christos@zoulas.com (Christos Zoulas)
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 22 Sep 2006 21:32:18 +0200
At 18:25 Uhr +0000 22.9.2006, Christos Zoulas wrote:
> | Am 22.09.2006 um 15:20 Uhr +0000 schrieb Christos Zoulas:
> | > Modified Files:
> | > src/sys/kern: tty_ptm.c
> |
> | Cool...
> |
> | I have applied
>
> You also need to create the device node...
I did.
> Hopefully it will work.
A sample machine worked, but the problem has always been hard to reproduce
when I wanted to... "Murphy".
hauke
--
"It's never straight up and down" (DEVO)
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
christos@zoulas.com (Christos Zoulas)
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 6 Oct 2006 13:38:13 +0200
Am 22.09.2006 um 18:25 Uhr +0000 schrieb Christos Zoulas:
> You also need to create the device node... Hopefully it will work.
Looks like it's... at least... not enough.
I've had one report where the abort trap went away after trying to
start Matlab a few times; and I have just seen and ktraced a case
where Matlab behaved just like before the patch. The ktrace ends in
[...]
3309 MATLAB CALL rt_sigaction(0x11,0xbfbf63a8,0xbfbf631c,8)
3309 MATLAB RET rt_sigaction 0
3309 MATLAB CALL rt_sigprocmask(1,0xbfbf6520,0,8)
3309 MATLAB RET rt_sigprocmask 0
3309 MATLAB CALL open(0xb9f56725,0x8002,0)
3309 MATLAB NAMI "/emul/linux/dev/ptmx"
3309 MATLAB NAMI "/emul/linux"
3309 MATLAB NAMI "/emul/linux/dev/ptmx"
3309 MATLAB RET open 8
3309 MATLAB CALL ioctl(8,_IO('T',0x1,0),0xbfbf550c)
3309 MATLAB RET ioctl 0
3309 MATLAB CALL ioctl(8,_IOW('T',0x30,0x4),0xbfbf563c)
3309 MATLAB GIO fd 8 read 40 bytes
"\^A\0\0\0\^A\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/1\0\0\0\0\0\0"
3309 MATLAB RET ioctl 0
3309 MATLAB CALL stat64(0xbfbf568c,0xbfbf55c4)
3309 MATLAB NAMI "/emul/linux/dev/pts/1"
3309 MATLAB NAMI "/dev/pts/1"
3309 MATLAB RET stat64 0
3309 MATLAB CALL statfs(0xbfbf568c,0xbfbf668c)
3309 MATLAB NAMI "/emul/linux/dev/pts/1"
3309 MATLAB NAMI "/dev/pts/1"
3309 MATLAB RET statfs 0
3309 MATLAB CALL ioctl(8,_IOR('T',0x31,0x4),0xbfbf66c8)
3309 MATLAB RET ioctl -1 errno -22 Invalid argument
3309 MATLAB CALL ioctl(8,_IO('T',0x1,0),0xbfbf657c)
3309 MATLAB RET ioctl 0
3309 MATLAB CALL ioctl(8,_IOW('T',0x30,0x4),0xbfbf66ac)
3309 MATLAB GIO fd 8 read 40 bytes
"\^A\0\0\0\^A\0\0\0/dev/null\0\0\0\0\0\0\0/dev/pts/1\0\0\0\0\0\0"
3309 MATLAB RET ioctl 0
3309 MATLAB CALL stat64(0xbd3d5810,0xbfbf6634)
3309 MATLAB NAMI "/emul/linux/dev/pts/1"
3309 MATLAB NAMI "/dev/pts/1"
3309 MATLAB RET stat64 0
3309 MATLAB CALL rt_sigaction(0x11,0xbfbf63a8,0xbfbf631c,8)
3309 MATLAB RET rt_sigaction 0
3309 MATLAB CALL rt_sigprocmask(1,0xbfbf6520,0,8)
3309 MATLAB RET rt_sigprocmask 0
3309 MATLAB CALL open(0xba99b2d0,0x8002,0)
3309 MATLAB NAMI "/emul/linux/dev/pts/1"
3309 MATLAB NAMI "/dev/pts/1"
3309 MATLAB RET open -1 errno -13 Permission denied
3309 MATLAB CALL rt_sigprocmask(1,0xbfbf04e0,0,8)
3309 MATLAB RET rt_sigprocmask 0
3309 MATLAB CALL kill(0xced, SIGABRT)
3309 MATLAB RET kill 0
3309 MATLAB PSIG SIGABRT SIG_DFL
3309 MATLAB NAMI "MATLAB.core"
3441 MATLAB RET poll 0
3441 MATLAB CALL getppid
3441 MATLAB RET getppid 1
3441 MATLAB CALL kill(0xeef, SIGKILL)
3441 MATLAB RET kill -1 errno -3 No such process
3441 MATLAB CALL kill(0xcf2, SIGKILL)
3441 MATLAB RET kill 0
3314 MATLAB RET nanosleep -1 errno -4 Interrupted system call
3314 MATLAB PSIG SIGKILL SIG_DFL
3441 MATLAB PSIG SIGRT1 caught handler=0xbd4be460
mask=(1,2,3,4,6,8,10,11,12,13,14,15,16,18,19,20,21,22,23,24,25,26,27,28,30,31,32,33))
3441 MATLAB CALL sigreturn(0x80a1ec0)
3441 MATLAB RET sigreturn -1 errno -2 No such file or directory
3441 MATLAB CALL exit_group(0)
Unfortunately, I forgot to check the content and permissions of
/dev/pts before rebooting the machine. Will do next time...
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
Hauke Fath <hf@spg.tu-darmstadt.de>
Cc:
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 6 Oct 2006 10:39:49 -0400
On Oct 6, 11:40am, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: PR/32682 CVS commit: src/sys/kern
| Looks like it's... at least... not enough.
|
| I've had one report where the abort trap went away after trying to
| start Matlab a few times; and I have just seen and ktraced a case
| where Matlab behaved just like before the patch. The ktrace ends in
So it is has been working fine for a while and it broke again, or
there was no improvement? /emul/linux/dev/ptmx is major 156, minor 2?
Does the ptmx regression program work?
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: christos@zoulas.com (Christos Zoulas)
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
gnats-admin@NetBSD.org
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 6 Oct 2006 17:36:15 +0200
Am 06.10.2006 um 10:39 Uhr -0400 schrieb Christos Zoulas:
>So it is has been working fine for a while and it broke again, or
>there was no improvement?
I deployed the patched kernel + device file to a few lab machines,
first, since the PhD students were busy running simulations 24/7 for
a deadline. All machines got the update on the last weekend; I got
one complaint from a post-doc on Tuesday, and a reproducible case
that gave me the ktrace today from a diploma student in the lab. Too
little data to construct a tendency (although, it's two datapoints ;).
>/emul/linux/dev/ptmx is major 156, minor 2?
156, or rather 165?
>Does the ptmx regression program work?
[hf@Kuster] ~/src/pr32682 > file ptmx
ptmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.0, statically linked, not stripped
[hf@Kuster] ~/src/pr32682 > ./ptmx
ptmx: bad slave uid 0 != 503
[hf@Kuster] ~/src/pr32682 > ls -l /emul/linux/dev/ptmx
crw-rw-rw- 1 root wheel 165, 2 Oct 2 19:34 /emul/linux/dev/ptmx
[hf@Kuster] ~/src/pr32682 > ls -l /dev/ptmx
crw-rw-rw- 1 root wheel 165, 0 Aug 4 11:29 /dev/ptmx
[hf@Kuster] ~/src/pr32682 >
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
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: PR/32682 CVS commit: src/sys/kern
Date: Fri, 6 Oct 2006 11:59:03 -0400
On Oct 6, 5:36pm, hf@spg.tu-darmstadt.de (Hauke Fath) wrote:
-- Subject: Re: PR/32682 CVS commit: src/sys/kern
| Am 06.10.2006 um 10:39 Uhr -0400 schrieb Christos Zoulas:
| >So it is has been working fine for a while and it broke again, or
| >there was no improvement?
|
| I deployed the patched kernel + device file to a few lab machines,
| first, since the PhD students were busy running simulations 24/7 for
| a deadline. All machines got the update on the last weekend; I got
| one complaint from a post-doc on Tuesday, and a reproducible case
| that gave me the ktrace today from a diploma student in the lab. Too
| little data to construct a tendency (although, it's two datapoints ;).
|
| >/emul/linux/dev/ptmx is major 156, minor 2?
|
| 156, or rather 165?
I am dyslexic.
| >Does the ptmx regression program work?
|
| [hf@Kuster] ~/src/pr32682 > file ptmx
| ptmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
| GNU/Linux 2.2.0, statically linked, not stripped
| [hf@Kuster] ~/src/pr32682 > ./ptmx
| ptmx: bad slave uid 0 != 503
| [hf@Kuster] ~/src/pr32682 > ls -l /emul/linux/dev/ptmx
| crw-rw-rw- 1 root wheel 165, 2 Oct 2 19:34 /emul/linux/dev/ptmx
| [hf@Kuster] ~/src/pr32682 > ls -l /dev/ptmx
| crw-rw-rw- 1 root wheel 165, 0 Aug 4 11:29 /dev/ptmx
| [hf@Kuster] ~/src/pr32682 >
Hmm mine is:
$ file ptmx
ptmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped
And the ptmx program works. Can you give me an account on one of your machines?
christos
From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
christos@zoulas.com (Christos Zoulas)
Subject: Re: PR/32682 CVS commit: src/sys/kern
Date: Fri, 6 Oct 2006 19:05:37 +0200
Am 06.10.2006 um 16:00 Uhr +0000 schrieb Christos Zoulas:
> | >/emul/linux/dev/ptmx is major 156, minor 2?
> |
> | 156, or rather 165?
>
> I am dyslexic.
I'd have taken the blame gladly for a solution that simple. ;)
> | >Does the ptmx regression program work?
> |
> | [hf@Kuster] ~/src/pr32682 > file ptmx
> | ptmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
> | GNU/Linux 2.2.0, statically linked, not stripped
> | [hf@Kuster] ~/src/pr32682 > ./ptmx
> | ptmx: bad slave uid 0 != 503
> | [hf@Kuster] ~/src/pr32682 > ls -l /emul/linux/dev/ptmx
> | crw-rw-rw- 1 root wheel 165, 2 Oct 2 19:34 /emul/linux/dev/ptmx
> | [hf@Kuster] ~/src/pr32682 > ls -l /dev/ptmx
> | crw-rw-rw- 1 root wheel 165, 0 Aug 4 11:29 /dev/ptmx
> | [hf@Kuster] ~/src/pr32682 >
>
> Hmm mine is:
> $ file ptmx
> ptmx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
>GNU/Linux 2.2.5, dynamically linked (uses shared libs), for
>GNU/Linux 2.2.5, not stripped
>
Hm. I have just rebuilt the binary dynamically-linked, but it doesn't
make a difference.
> And the ptmx program works. Can you give me an account on one of
>your machines?
Sure, just send me a master.passwd line.
hauke
--
/~\ The ASCII Ribbon Campaign Hauke Fath
\ / No HTML/RTF in email Institut für Nachrichtentechnik
X No Word docs in email TU Darmstadt
/ \ Respect for open standards Ruf +49-6151-16-3281
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home