Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 May 1995 13:18:10 +0200 (MET DST)
From:      sven@stack.urc.tue.nl (Sven Berkvens)
To:        questions@FreeBSD.org
Subject:   Lots of questions
Message-ID:  <199505191118.NAA17498@zen.stack.urc.tue.nl>

next in thread | raw e-mail | index | archive | help
Hi everyone!

I am one of the system administrators of the university's computer
association. We are current running FreeBSD 2.0 RELEASE on three
computers. One is acting as an NFS server and contains a lot of
harddisks. The other two get most of their stuff from that NFS server.

The server contains two WD8003EP ethernet cards. One is for the NFS
network (which is local to the three computers) and one is for
normal network access. The other two computers have a similar setup,
except that they contain two NE2000's.

I mention the above because it may have something to do with my qeustion:
when I type 'arp -a' to view the ARP cache, all it says (on all three
machines) is:

? (0.0.0.0) at (incomplete)
? (0.0.0.0) at (incomplete)
? (0.0.0.0) at (incomplete)
? (0.0.0.0) at (incomplete) permanent
? (0.0.0.0) at (incomplete)
? (0.0.0.0) at (incomplete)

One machines has more 0.0.0.0 than another, but all outputs are similar.
Does this mean that the machines will try an ARP resolve for every packet
they send or is my 'arp' just broken? I don't know exactly how much network
load ARP resolves cost, but I can imagine that it is not desirable.
Also, I cannot query a host for its ARP address:

Turtle: /home/sven> arp zen
zen (131.155.140.130) -- no entry

Turtle: /home/sven> arp nfszen
nfszen (131.155.14.130) -- no entry

And that, while it's constantly receiving and sending NFS data to nfszen.

Anyone know what's going on here?

-------------------------------------------------------------------------------

Now I have a question about the pty/tty's the FreeBSD employs.
It seems that when somebody logs in, the pty/tty pair in the /dev
directory is chown(2)'ed to that person. That's quite normal :)
Now, when he/she logs out, the pty/tty is AUTOMATICALLY chown(2)'ed
back to root and given the mode rw-rw-rw-. This is not a real problem,
but the problem is this:

Say somebody is running ELM. For some reason, he thinks the computer
hanging (for example, it takes too long) and he presses ALT-X (using
PC NCSA Telnet) which closes the connection. The pty/tty pair gets chowned
back to root and they are no longer associated with the ELM process.
When ELM does a read(2) to check for terminal input, read(2) returns
0 (I guess as an EOF condition). ELM interprets this wrong (so does
TIN for example) and does not see this as an error; even worse, these
programs interpret it as a keystroke. Now comes the problem. These
program think 'Hey, this is NOT a key I know, lets tell the user and
wait for another key'. The write(2)s fail but ELM and TIN don't notice.
However, they get stuck in a loop and start eating processor time,
because they keep on getting "wrong keys".

My questions about this:

Is read(2) not supposed to return -1 to indicate an error (like write(2) does)?
Why does the tty/pty immediate get chown(2)'ed back to root (and more
important: who does this??) instead of leaving it behind as it was and
then chown(2)-ing it to another user when necessary (like on SVR4)?

------------------------------------------------------------------------------

Another question: is there a stat-daemon available for FreeBSD?

------------------------------------------------------------------------------

Will the new version of FreeBSD be able to handle bad sectors on disks and
harddisks? And what about bad sectors in the swap partition? And why isn't
it (yet) possible to swap out of a file?

------------------------------------------------------------------------------

We run XFree86 version 3.1.1 and that works perfectly, except that when
you quit the X server, it sometimes nukes the consoles. They either totally
disappear (the X server reports VT_ACTIVATE failed), or they just don't
display anything (they do work, but you can't see anything except a kind of
cursor (ours normally flashes, but this one doesn't) which does not move).
Commands that are typed are responded to however. I can't seem to get
vidcontrol(1) to do anything about it either. Restarting the X server works
(the X screen is displayed properly) but quitting it renders the same
result. By the way, this only happens sometimes, not always.

In all cases, the getty(1) processes do keep on running. Respawning them
manually does not solve the problem.

The video card used is an ET 4000 with 1 MB of memory, running in 1024x768x256
and in 1024x768x2 modes. Both modes sometimes render the console useless after
quitting the X server, which is done normally by the way: not with
CTRL-ALT-BackSpace.

Does anybody have the same problem? And does anybody know what I can do
to get back my console?

-------------------------------------------------------------------------------

Thank you for your time which you took to read this!

With kind regards,
Sven Berkvens (System Administrator)




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199505191118.NAA17498>