HDTenEightyP/NetNews huggingface dataset:
From: pejn@cc.uow.edu.au (Paul Nulsen)
Subject: [386bsd] Installing X386 - keyboard problems
Summary: How do I make X386 listen to the keyboard?
Keywords: 386bsd, X386, installation, keyboard
Organization: University Of Wollongong
Date: Tue, 1 Sep 92 00:05:07 GMT


Still trying to install X386 1.2E using the binaries from agate. I can now
get X to run - even succeeded in configuring a working mode. The problem is,
X is not listening to my keyboard. I think I have seen some discussion of
this problem in this group, but our news archive has a short memory. Can
anyone tell me how to fix it?

Thank you
Paul Nulsen
pejn@wampyr.cc.uow.edu.au
From: rcpt@rwa.urc.tue.nl (Piet Tutelaers)
Newsgroups: comp.unix.bsd
Subject: Re: An overview of 17" monitors
Date: 4 Sep 92 10:25:47 GMT
Reply-To: rcpt@urc.tue.nl

karl@NeoSoft.com (Karl Lehenbauer) writes:

>Correct me if I'm wrong, but all the current HDTV proposals except for MIT's
>are lower resolution than 1280x1024.

In my overview I was perhaps too much focused on 1280x1024.  The
current color 17" X-terminals or 17" X-consoles offer the 1152x900
mode.  Somebody pointed out that for real 1280x1024 mode you need at
least 19" or more. For the 1280x1024 mode you will certainly need an
expensive graphics card with more than 1MB of RAM. So for most of us
the 1152x900 or 1024x768 modes with the ET4000 chip (Sierra Color?)
will be the most affordable solution.  And a monitor having a refresh
rate of 70-72 Hz at these resolutions will make the work with it very
enjoyable.

--Piet
Newsgroups: comp.unix.bsd
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: com port and more
Organization: Novell NPD -- Sandy, UT
Date: Thu, 3 Sep 1992 17:44:01 GMT

In article <sedU9q600WAtMJ3WVW@andrew.cmu.edu> "Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu> writes:
>I just installed 386bsd last night.  Anyway, here are a few of my
>questions that have popped up early:
>  1) I have a terminal on com1 (telix running vt100), and com2 (z29 in
>ansi mode).  On the PC running telix, whenever I run an application that
>uses curses (vi) it locks the terminal.  If I drop dtr 4 times I will
>eventully kill vi and get a prompt back, but I was wondering what could
>be wrong here.  The terminal is set up as std.9600 in /etc/ttys. 
>According to telix I am at 9600,e,7,1,xon/xoff,no cts/rts though.  I
>haven't tried this with another terminal package yet.

Telix is brain damaged... or at least it doesn't quite emulate the terminal
it says it's emulating.

When "vi" (really "elVIs") starts up, it "sizes" the screen in the same
way that the X command "resize" does:  by addresing the cursor to a
ridiculously large location (usually 999 999).  On a normal ANSI compliant
terminal, this will locate the cursor in the lower right hand corner of the
screen, unless you are unfortunate enoug to have > 999 character cells in
either direction.  Telix does not do this.  You may want to use VTERM,
TERM, TinyTERM, VTKermit, or something else which works (I know these 4
and the console driver and the xterm program do).  That Telix doesn't at
least trap the "move cursor to invalid location" and locks up insteas is
real bad.  It may actually do this, but not relocate the cursor to the
lower right hand corner... if this is the case, issuing the move to 999 999
after homing the curser will also result in what "elVIs" believes is a 0x0
screen, which will also seem to "lock up", since none of the messages can
be printed.  In either case, you want to run something other than Telix.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
Newsgroups: comp.unix.bsd
From: christia@latenite.ssc.gov (Mike Christiansen)
Subject: Is gcc 2.2 availiable??
Organization: SSC Laboratory, Dallas, TX
Distribution: usa
Date: Fri, 4 Sep 1992 04:36:26 GMT

Is the latest and greatest version of gcc 2.2 (I think; the one which
supports both ansi C and C++ 3.0) availiable for 386bsd? Has anyone
compiled InterViews 3.1beta? 

thanks.
--
----------------------

Mike Christiansen
Superconducting Super Collider Laboratory
Controls Group
2550 Beckleymeade Ave.
MS.4002
Dallas, TX. 75237

214-708-3415
christia@latenite.ssc.gov
Newsgroups: comp.unix.bsd
From: gottloeb@eel.dsd.trw.com
Subject: GDB under 386bsd 0.1
Originator: gottloeb@eel.dsd.trw.com
Keywords: gdb, ptrace
Reply-To: gottloeb@eel.dsd.trw.com
Organization: TRW Space & Defense
Date: Fri, 4 Sep 1992 00:54:17 GMT

I have noticed a problem using gdb under 386bsd 0.1.

When at least one breakpoint has been set and the program terminates,
e.g. executes exit(), the breakpoint is not removed from the process's
text image.  When the program is subsequently re-executed under gdb,
gdb remembers that a breakpoint is supposed to at the memory location
and puts one there again.  However this time it shadows the breakpoint
instruction from the previous run rather than the original instruction.
When execution begins after reaching the breakpoint, various traps occur.

If the program is run after quitting gdb, a Trace/BPT trap occurs.

I think the problem is that gdb assumes that when ptrace modifies the
process's image the kernel either makes a private copy of the text image
or it will throw away the text image after the process terminates.
However, this is not the case - the kernel keeps the modified text image
around and executes it rather than a fresh copy from the original file.

This can be demonstrated with the following program:


#include <stdio.h>

void main() {
    printf("hello world\n");
    exit(1);
}


Compile the program:
    cc -g main.c

Start gdb
    gdb a.out

Set a breakpoint at the first line in main:
    break main

Start program execution:
    run

Continue program execution:
    cont

Quit gdb

Execute the program again:
    a.out


Does anybody have a fix or any suggestions on how to fix this?


Thanks in advance,
Jeff Gottloeb
gottloeb@gumby.dsd.trw.com
Xref: sparky comp.unix.bsd:4926 comp.os.os2.misc:28820
From: allard@isi.edu (Dennis Allard)
Newsgroups: comp.unix.bsd,comp.os.os2.misc
Subject: Re: DOS + OS/2 2.0 + 386bsd 0.1 installation .....
Date: 1 Sep 92 01:26:55 GMT
Reply-To: allard@isi.edu (Dennis Allard)
Distribution: world
Organization: USC Information Sciences Institute

jlu@cs.umr.edu (Eric Jui-Lin Lu) writes:
> After spending nights of reformats, reboots, and reinstallations, I
> kinda came out a wierd combination of DOS, OS/2, and 386bsd in one
> hard disk.  I used os-bs ...

I have not yet tried to use os-boot.  I used to have DOS, OS/2, and
386BSD each in their own primary partion, and used the OS/2 boot
manager in a fourth (and final) primary parition.  In other words, I
had:

OS/2 boot manager     1 meg
OS/2 HPFS            40 meg
DOS FAT             200 meg or so
386BSD              200 meg or so

(I'm on a 490meg Fujitsu disk)

I did not like this solution for a couple reasons.  First, since these
are all primary paritions, they are invisibile to each other.  Second,
386BSD /usr/dist/bin/shutdown -todos does not currently work if the
DOS partition is > 32 meg.

So, I now am using a different solution.

free space          2 cylinders (I'm hoping that os-boot will go here)
DOS FAT             31.2 meg  (some integral number of cylinders)
386BSD             250   meg
DOS extended       200   meg or so

I have a 160meg logical D: FAT partition in the extended partion and
I am going to install OS/2 in its own logical partition, which is
possible, according to OS/2 documentation.  I have not yet tried to do
so, however.

The advantages to my current setup are that I can now do shutdown -todos
and, once I have OS/2 up, it will be able to see the DOS D: drive,
hence enabling me to share DOS files with OS/2.


> ...  I'm not quite satisfied with this.  Since
> when I choose OS/2, OS2 boot manager menu comes up.  I wish to
> eliminate this OS/2 boot manager totally.

The only reason I can think of for it to be there is because you
have a seperate OS/2 boot manager partition which is what os-bs
is actuallty booting to when you chose OS/2.

Dennis
allard@isi.edu
Newsgroups: comp.unix.bsd
From: nbladt@autelca.ascom.ch (Norbert Bladt)
Subject: gas manual (as.1) empty in source distribution (386BSD) ?
Summary: I found an empty gas/as.1 file in the srcdist I have access to !
Keywords: 386BSD gas
Organization: Ascom Autelca AG, Guemligen, Switzerland
Date: Tue, 1 Sep 1992 06:47:25 GMT

Hi 386BSD-users, bug-fixers, etc. !

I have access to a distribution host via NFS. On this host there
is the full distribution (bindist, srcdist, etcdist, etc.) and another
tree with the sources unpacked. Now, I copied all the sources to my local
harddisk because it's faster due to the slow link used by NFS.
However, the file gas/as.1 is empty !
I checked the srcdist on this server by the famous
cat src??.?? | uncompress | cpio -itv usr/src/usr.bin/gas/as.1
commandline and the result was:
100444 root        0  Mar  3 09:28:09 1991  usr/src/usr.bin/gas/as.1
meaning that this file is really empty in the srcdist set of files.

Did anybody else discover this problem or is it just this server ?

I would like to get a complete distribution, so, if somebody can mail
this file to me, I will be happy.

Thank you in advance,

Norbert.
-- 
Norbert Bladt, Ascom Autelca AG, Worbstr. 201, CH-3073 Guemligen, Switzerland
Phone: +41 31 999 65 52			FAX: +41 31 999 65 44
Mail: nbladt@autelca.ascom.ch   UUCP: ..!uunet!mcsun!chsun!hslrswi!aut!nbladt
Newsgroups: comp.unix.bsd
From: mullens@jamsun.ic.ornl.gov (James A. Mullens)
Subject: Re: Description of Trap Codes
Organization: Oak Ridge National Laboratory
Date: Mon, 31 Aug 1992 16:56:16 GMT

In article <-13547389@nemesis>, uhclem@nemesis.UUCP writes:
|> 
|> There have been several questions about the various Trap codes
|> being encountered on the 386/486.  Here is a list of the Trap codes,
|> along with some common causes for each.
|> 
|> Trap	2	NMI Interrupt
|> 		On PC/AT systems, the NMI input to the CPU is usually
|> 		connected to the main memory parity circuit.  By the time the
|> 		error signal is generated, the data may have already been
|> 		used in an instruction, so it isn't possible to reliably
|> 		recover.
|> 

And some not-so-common causes (from various sources):

  PS50+ : I/O channel check, system watch-dog timer time-out interrupt,
          DMA timer time-out interrupt

  parity errors on any 8-bit or 16-bit board pulling the IOCHCK* line low,

  first generation of auto-switching EGA cards used NMI to trap port
  access for CGA emulation (e.g., ATI's EGA Wonder)

  Zeos Notebook low battery (perhaps other battery-based computers)

jim mullens
jcm@ornl.gov (128.219.128.17) -or- mullens@jamsun.ic.ornl.gov (128.219.64.31)
voice: 615-574-5564
Newsgroups: comp.unix.bsd
From: ccml@hippo.ru.ac.za (Mike Lawrie)
Subject: [386bsd] namelist hassles
Organization: Rhodes University, Grahamstown, South Africa
Date: Wed, 2 Sep 1992 09:48:11 GMT

Several programs on 386bsd-0.1 produce namelist error messages - what
does one do to fix this? I've done a pretty vanilla install of
{bin,src,etc}dist on a 560 Mb SCSI, 8 Mb RAM 386, and am far from being
a bsd expert.

For example:

netstat (the one referred to in the FAQ) produces "filehead or nfiles
not in namelist"

netstat -r produces "rthashsize: symbol not in namelist"

ps -aux produces "ps: nlist: can't find the following symbols: _fscale
_avail_start _avail_end:

Mike
-- 
Mike Lawrie                                    <ccml@hippo.ru.ac.za>
Director, Computing Services                   ph +27 461 22023 x 279
Rhodes University, Drostdy Rd                  fx +27 461 25049
Grahamstown 6140, South Africa
From: bob@obiwan.uucp (Bob Willcox)
Newsgroups: comp.unix.bsd
Subject: Losing data reading QIC-02 streamer tape on 386bsd 0.1
Date: 1 Sep 92 05:05:26 GMT
Organization: Bob's Place, Austin TX

I have discovered that my Wangtek 5150 EQ streamer tape drive is
discarding the first 2048 bytes of data whenever it stops then restarts.
It seems to write the tape just fine (checked on another system).  The
problem occurs regardless of what program I read the tape with (I've
tried dd, tar, afio) and is dependent upon the buffer size (bigger
buffers result in less stops/starts).  A test with dd and known data
content showed the missing data to be *exactly* the first 2048 bytes of
data for the next buffer (following the stop).

Has anyone else experienced this?  I believe that my drive and
controller are ok since they were in use on another system and working
fine before being moved to the 386bsd system.

Thanks in advance for any help you can give,
-- 
Bob Willcox                ...!{rutgers|ames}!cs.utexas.edu!uudell!obiwan!bob
Phone: 512 258-4224 (home)
       512 838-3914 (work)
From: stripes@pix.com (Josh Osborne)
Newsgroups: comp.unix.bsd
Subject: Re: 386bsd: Doesn't use BIOS?
Date: 3 Sep 92 23:09:22 GMT
Organization: Pix Technologies -- The company with no adult supervision

In article <1992Sep3.194427.14251@engage.pko.dec.com> ewanco@kalvin.enet.dec.com writes:
>I saw mentioned in the thread on the Diamond Speedstar 24[X] interface problems
>that said that 386bsd does not use BIOS and hence needs the code for the
>Speedstar.  This struck me as odd; I can understand skipping the BIOS for the
>sake of speed on certain devices, but why can't 386bsd use BIOS for proprietary
>devices like the Speedstar?  Is it an all-or-nothing thing, that is, either we
>forgo using BIOS at all or incur horrible disadvantages?  [...]

Well, most BIOS code is not rentrent which means we can't use it without
external locking.  It is also going to be orentated towards running in 
V8086 mode - so we would have to jump through a VM8086 TSS or call gate,
or some other nonsense.  We would also need to be careful to protect
the rest of the kernel for the BIOS code (in case it has bugs).

There may be some other reasons as well (like ones that make it impossable,
as opposed to the ones I listed that just make it more trubble then it's worth).

>[...].  (Then again, it is news to me that you could take advantage of
>hi-res accelerated boards through the BIOS, but that's another issue.)

Well you use the BIOS to enter various video modes, and some video BIOS
code has some other code as well.
-- 
           stripes@pix.com              "Security for Unix is like
      Josh_Osborne@Real_World,The          Multitasking for MS-DOS"
      "The dyslexic porgramer"                  - Kevin Lockwood
We all agree on the necessity of compromise.  We just can't agree on
when it's necessary to compromise.       - Larry Wall
Newsgroups: comp.unix.bsd
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: Re: X386 and Diamond Stealth: not solution
Organization: GMI Engineering&Management Institute, Flint, MI
Date: Fri, 4 Sep 1992 15:56:09 GMT

hasty@netcom.com (Amancio Hasty Jr) writes:

>In article <9460@emory.mathcs.emory.edu> sb@next.neuro.emory.edu writes:
>>> 
>>> I had just made up my mind to buy a Diamond Stealth when I heared about  
>>all
>>> this trouble. Well, I am looking for cards from other vendors now.
>>> So maybe you should give them a list of people who are _not_ going to  
>>buy a
>>> card from them, unless they change their policy.
>>> If you are doing so feel free to put my name on it.
>>> -- 
>>> Andreas Klingler
>>> asklingl@informatik.uni-erlangen.de
>>>        I'd love to help you out... Which way did you come in?
>>
>>
>>  I was just about to buy a Diamond Stealth also, but not now that
>>I've heard about diamond's uncooperative attitudes.  With the rate
>>that technology changes these days, you'd think that companies
>>couldn't afford these kinds of policies.
>It would help a lot if people would call up Diamond and express
>politly their opinion. For instance, I explained to a Diamond
>marketing person why I was taking my Stealth back - I can't
>write an X11R5 device driver to your card because you use
>a propieratory mechanism for setting the clock values on the Stealth.

>Also, be aware that future Diamonds svga cards not just the Stealth
>will not be supported by X386 due to their new novel way of setting
>the clock values.

>So call or write to Diamond, if you want to enjoy Diamond products.

>From my view, Diamond's strategy poses a bad precedence.

>Amancio Hasty

>>
>>
>>
>>  Steve Berger (sb@onripx.neuro.emory.edu)


The guys who have been maintaining X386 for commercial SYSVR4 (Wexelblat,
Dawes, etc.) are collecting such statements which they are sharing with
Diamond.  I just read the message from Wexelblat on comp.os.linux.  The
mailing address is:
		diamond@physics.su.oz.au

--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /
From: u2105545@csdvax.csd.unsw.edu.au
Newsgroups: comp.unix.bsd
Subject: [?] comp.os.386bsd
Date: 30 Aug 92 17:53:32 +1000
Organization: University of New South Wales


Hi,
Why there isn't a newsgroup "comp.os.386bsd"?
386bsd and BSD distribution are differnet, aren't they?

regards,
Shigetoh Kumagai 	shk@newt.phys.unsw.edu.au
			u2105545@csdvax.csd.unsw.edu.au
Newsgroups: comp.unix.bsd
From: CSP1DWD@MVS.OAC.UCLA.EDU (CSP1DWD)
Subject: Re: 386bsd on notebooks?
Date: 28 Aug 92 22:48:56 PDT

In article <1992Aug26.130133.26565@noao.edu>, on 26 Aug 92 13:01:33 GMT,
rstevens@noao.edu (W. Richard Stevens) writes:

>But, beware of network connectivity with a notebook.  That's the
>real problem.  SLIP works so-so, mainly due to silo overflows,
>and it's usually pretty hard to just swap in a 16550 in a notebook

IBM notebooks all seem to have 16550A uarts, at least in my school
the IBM PS/2 Model N45SL with 2Meg of RAM (expandable to 8Meg) and
including a 120Meg HD can be had for under $1900.

Zeos, I understand, has a notebook with 10Meg of RAM, a 16550 uart
and a 180Meg HD for about $3K.

The issue of FIFOed uarts for notebooks is critical, manufacturers
must be told in the strongest of terms that it only takes a few more
pennies to give us 16550 uarts, they are all resisting so far...
I look to the day when our notebooks come in with built ethernet,
a FIFOed uart and a high-speed bi-directional parallel port.

-- Denis 

Newsgroups: comp.unix.bsd
From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad)
Subject: tar 'multivolume' bugs and workaround workound
Organization: Nanyang Technological University - Singapore
Date: Wed, 26 Aug 1992 04:15:47 GMT

gnu tar 1.10 which comes with 386bsd bin01 distribution "cannot" do multivolume
compressed backup but can do uncompressed multivolume backup.

There is a need to reduce the temporary file storage for systems with limited
disk space. 0.1 method of distribution requires that the entire files must
first be loaded before they can be extracted.
	0.0 was better because it does not have to so was much faster and
does not require a lot of tmp space.

The solution was that I used to backup my root device is to

tar -cvpzf ar.tar.Z
tar -cvMf /dev/rfd1a

To extract: the O option extracts to stdout instead of to files

tar -xMOf /dev/rfd1a | tar xvzf -

I do not manage to recover the symbolic links. Maybe I missed some options.

Someone who wants to extract bin01, may try my method like this. This is only
an idea. I do not need to do it because I have sufficient disk space(60Mbyte).


cd /tmp
mread "a:*.*" . ; for all disks
tar -cvMf /dev/rfd1a

;to extract

tar -xvMOf /dev/rfd1a | uncompress | cpio -idalm 
 

Anyone would like to try?
I may do that using etc distribution which uses up 20 disketes. I have not
even managed to download all of them. The filelists already take up the
first 20 files. I cannot even extract bash which is what I need the most,
after downloading the first 20 files.

IMHO the utilities in etc01 should be distributed in normal compressed tar
format as previously was done for 0.0 instead of being jumbled into
 90 files which must all be downloaded together.

Chris, are you reading?



--
Othman bin Ahmad, School of EEE,
Nanyang Technological University, Singapore 2263.
Internet Email: eoahmad@ntuix.ntu.ac.sg
Bitnet Email: eoahmad@ntuvax.bitnet

Newsgroups: comp.unix.bsd
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: GDB under 386bsd 0.1
Keywords: gdb, ptrace
Organization: Novell NPD -- Sandy, UT
Date: Fri, 4 Sep 1992 17:58:18 GMT

In article <1992Sep4.005417.3876@gumby.dsd.trw.com> gottloeb@eel.dsd.trw.com writes:
>I have noticed a problem using gdb under 386bsd 0.1.
>
>When at least one breakpoint has been set and the program terminates,
>e.g. executes exit(), the breakpoint is not removed from the process's
>text image.  When the program is subsequently re-executed under gdb,
>gdb remembers that a breakpoint is supposed to at the memory location
>and puts one there again.  However this time it shadows the breakpoint
>instruction from the previous run rather than the original instruction.
>When execution begins after reaching the breakpoint, various traps occur.
>
>If the program is run after quitting gdb, a Trace/BPT trap occurs.
>
>I think the problem is that gdb assumes that when ptrace modifies the
>process's image the kernel either makes a private copy of the text image
>or it will throw away the text image after the process terminates.
>However, this is not the case - the kernel keeps the modified text image
>around and executes it rather than a fresh copy from the original file.
[ ... ]
>Does anybody have a fix or any suggestions on how to fix this?

	This is a long standing bug in memory management, which (I thought)
was resolved in BSD 4.2.  The problem is that text pages are not marked
dirty on write; thus the remain shared.

	An extremely graphic demonstration of this can be had by using
gdb on "su".  Patch the "su" image to start a shell without asking for
a password.  Leave the debugger running.  Type "su" on another terminal:
voila!  root!

	This is a serious issue to be addressed.  The fix is basically
to disallow use of text pages which have been marked dirty, and to force
a reload of the instance of the text page.  Since I am not sure whether
provision has been made for multiple instances of text pages representing
the same file blocks to be in core simultaneously, nor whether marking
the pages dirty would result in their being erroneously written to disk,
I am unsure as to the approach you would want to take to fix it.  Any
fix should still allow for sharing of text pages.  If I "debug" vi,
and write one of it's text pages, and there are two other users of vi,
the two users should be sharing a single copy and I should have my own.
Any other soloution will negatively impact our ability to support shared
libraries in the future (one of my pet projects 8-).


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
From: nakamura@cradle.titech.ac.jp (Kazushi NAKAMURA)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD 0.1 calendar
Date: 1 Sep 92 03:54:53 GMT
Organization: The Center for Research And DeveLopment of Educational Tech., Tokyo Inst. of Tech., Tokyo, JAPAN


	Hello,* !

From article <1992Aug30.213846.27802@math.utexas.edu>, by pgilley@blancmange.ma.utexas.edu (Phil Gilley):
> I can't seem to get calendar to work in 386BSD 0.1 (it won't produce
> any output).  I looked at calendar.c and didn't see any obvious problems.
> Does anyone have any ideas?  I don't pretend to be a unix wizard so it
> may be something trivial.

  Look at the file "~/calendar" ;Is it's format right? The format is,

	month/day	schedule
	...

For example.

	8/30	My birthday
	9/08	meeting
	...
	*/28	payment

  See "man calendar". You don't probably need to look at calendar.c .
-- 
nakamura@cradle.titech.ac.jp	CRADLE, Tokyo Institute of Technology
kazus-n@ascii.co.jp		NAKAMURA Kazushi
jo3oob@jo3oob 1293.74MHz(PM95)