I am certainly not a kernel hacker, so I might be totally off, but I have found some behaviour of the 7.0-PRELEASE kernel that perplexes me. First, I am on a kernel from FreeBSD ogre 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE #9: Thu Jan 17 23:34:07 CET 2008 root_at_ogre:/usr/obj/usr/src/sys/OGRE amd64 Just built. Now, I installed /usr/ports/devel/plan9port on the system. Ignore the ONLY_FOR_ARCH i386, comment it out on amd64 and let it compile (if you are on i386 I have the same problem there, so it is not only affecting the amd64 arch. I have no access to a sparc64 at the moment). When this has compiled add /usr/local/plan9/bin to your $PATH and execute acme(1) (Rob Pike's text editor btw). Then execute the win(1) command via 9 win rc (yes, the 9 is a shell script from /usr/local/plan9/bin which shoves in some plumbing before invocation, so you must remember to add it) to get an rc-shell directly into acme. This makes for some really strange behaviour on my system. whenever I need to get access to a pty/tty things lock up for me. I have the following strange thing in /dev ogre% ls -l /dev total 2 [SNIP] crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty crw-rw-rw- 1 root wheel 1, 46 Jan 18 00:56 tty ... which I am pretty sure is bad. I also wondered why my zsh(1) invocation failed to do anything, so enter ktrace/kdump of a zsh invocation: 1319 zsh RET sigaction 0 1319 zsh CALL sigaction(SIGINT,0x7fffffffe530,0) 1319 zsh RET sigaction 0 1319 zsh CALL sigaction(SIGINT,0x7fffffffe530,0) 1319 zsh RET sigaction 0 1319 zsh CALL sigaction(SIGINT,0x7fffffffe530,0) 1319 zsh RET sigaction 0 1319 zsh CALL sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90) 1319 zsh RET sigprocmask 0 1319 zsh CALL sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90) 1319 zsh RET sigprocmask 0 1319 zsh CALL sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90) 1319 zsh RET sigprocmask 0 1319 zsh CALL sigprocmask(SIG_BLOCK,0x3b8fab60,0x3b8fab90) 1319 zsh RET sigprocmask 0 1319 zsh CALL open(0x542930,O_WRONLY|O_CREAT|O_TRUNC|O_NOCTTY,S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH) 1319 zsh NAMI "/dev/tty" Hmmm. At this point the system is barely usable. Almost everything you wish to play with hangs. What I do not like about it is that it works like an effective DOS on the system because it would seem like everybody would be able to do something like this (no root required at all). The problem is deterministic with the above usage of acme+win on amd64 and i386. I don't know if it is present on 6.x or some earlier 7.0-FOO release since I just recently began playing with the devel/plan9port port. And now for the questions: * Is this a bug or a feature? In the case it is a feature, can anybody point me to the explanation or explain it? I would be grateful for it and I think there may be more readers that would. * Should it be PR'ed? * Is there some way to fix the behaviour? J.Received on Thu Jan 17 2008 - 23:44:16 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:26 UTC