HDTenEightyP/NetNews huggingface dataset:
From: tgt@neon.ecn.purdue.edu (Conan the Librarian)
Subject: Re: Help with X386 and xmd!!!!
Organization: Purdue University Engineering Computer Network
Date: Mon, 7 Sep 1992 23:25:11 GMT

In article <1992Sep6.115915.3934@desire.wright.edu> cse0935@desire.wright.edu writes:
>I'm in some dire need of help with X386.  Any help would be much appreciated.
>Here is my xdm-errors file.....
>
>X386 Version 1.2E 1.0.1  / X Window System
>(protocol Version 11, revision 0, vendor release 5000)
>error (pid 90): IO Error in XOpenDisplay
>error (pid 88): Display :0 cannot be opened
>X386 Version 1.2E 1.0.1  / X Window System
>(protocol Version 11, revision 0, vendor release 5000)
>error (pid 93): IO Error in XOpenDisplay
>error (pid 88): Display :0 cannot be opened
>X386 Version 1.2E 1.0.1  / X Window System
>(protocol Version 11, revision 0, vendor release 5000)
>error (pid 95): IO Error in XOpenDisplay
>error (pid 88): Display :0 cannot be opened
>X386 Version 1.2E 1.0.1  / X Window System
>(protocol Version 11, revision 0, vendor release 5000)
>error (pid 98): IO Error in XOpenDisplay
>error (pid 88): Display :0 cannot be opened
>error (pid 88): Display :0 is being disabled
>
   (stuff deleted)

DITTO!!  I am also getting the above messages in the xdm-errors
file.  I am trying to startup in 640x480 mode (I have an ATI Graphics
Ultra card) so I have commented out the Chipset, Vendor, etc.
lines of the Xconfig file.  "Modes" is left defined as 640x480.

As soon as xinit starts (at the end of the startx script) my
screen blanks, I get the Version info, and then nothing!  I
can get characters to echo on the screen, but I get no
usable response and am unable to recover without rebooting.

I have read the INSTALL notes and the FAQ; I am using the patched
kernel provided with the X386 1.2E 1.0.1 binaries on agate.
I have made vga ("mknod /dev/vga c 12 0" or something like that)
I have tweaked the Xconfig file to locate my Microsoft mouse
on com1.  I see nothing else left to do.

>
>I would appreciate any help anyone could give me, as I'm dying to see Xwindows
>and don't think I can sleep 'till then.


PLEASE, SOMEONE IN THE KNOW, HELP US!!!!!!! :-)

-tom
--
Tom Tobin				UUCP:     pur-ee!tgt	
Dept. of ChE				INTERNET: tgt@ecn.purdue.edu
Purdue University			Ma Bell:  home (317) 463-0189
W. Lafayette, IN 47907				  office "   494-4052 
Newsgroups: comp.unix.bsd
From: chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko)
Subject: Re: 386bsd & timezone
Organization: Technical University of Graz, Austria
Distribution: usa
Date: Fri, 11 Sep 92 19:41:28 GMT

In article <EICHIN.92Sep11051611@tsx-11.mit.edu> eichin@athena.mit.edu (Mark W. Eichin) writes:
>>> My solution was just to set the CMOS information to reflect standard
>	Has anyone made changes to get 386BSD to update the CMOS time
>from the kernel time? xntp3 builds and works out of the box, but if
>the CMOS time drifts far enough, at the next reboot xntpd will declare
>that "something is wrong" and won't try to fix it.
>				_Mark_ <eichin@athena.mit.edu>
>				MIT Student Information Processing Board

Yes, I have written a clock.c that does this.
It does not handle DST (yet), because I don't know how the RTC handles it.
Are the values for DAYST and DAYEND in the original clock.c correct
for the 386 RTC ? If you have any information on DST (switch dates in
the various Areas etc) please send it to me. Also, I have not yet seen
a BIOS that lets you choose which DST Area you are in, so which one
does it use ?

As an aside, I am wondering when the CMOS time should be set.
I have it set currently when the system time is set (in settimeofday() ),
but I think it should also be set when the system is shut down
(to save the time after adjtime() has been used). Any comments as to where
such a call to resettodr() should be put are very appreciated.


							Christoph
-- 
signature: Result too large
Newsgroups: comp.unix.bsd
From: tih@barsoom.nhh.no (Tom Ivar Helbekkmo)
Subject: [386bsd] A bugfix to my modified wd driver!
Organization: Norwegian School of Economics
Date: Tue, 15 Sep 1992 05:13:40 GMT

Well, it turns out that there's a bug in the bad144 handling in my
modified wd driver after all!  (And of course, luck (and insufficient
testing on my part) caused me never to run into it because I only
have bad sectors in partitions that start at the beginning of the
disk!)

The problem was pointed out to me, with the fix, by Terry Lee
(terry@uivlsi.csl.uiuc.edu), and is caused by not correcting the
block numbers we're looking for for partition offset.  (In my code,
I used a variable, blknum, that wasn't corrected originally because
it was never used again.)

Thanks, Terry!

Here's the patch *to the last version of my wd.c*.  If you're picked
up my stuff from barsoom.nhh.no, and this patch doesn't match your
line numbers perfectly, ftp the wd.c file again.  There have been
some efficiency updates lately...  :-)

*** wd.c.old	Tue Sep 15 06:55:09 1992
--- wd.c	Tue Sep 15 06:55:15 1992
***************
*** 418,429 ****
      lp = &du->dk_dd;
      secpertrk = lp->d_nsectors;
      secpercyl = lp->d_secpercyl;
      cylin = blknum / secpercyl;
      head = (blknum % secpercyl) / secpertrk;
      sector = blknum % secpertrk;
-     if ((du->dk_flags & DKFL_BSDLABEL) != 0 && wdpart(bp->b_dev) != WDRAW)
- 	cylin += lp->d_partitions[wdpart(bp->b_dev)].p_offset
- 	    / secpercyl;
      
  #ifdef TIHBAD144
      /* Check for bad sectors if we have them, and not formatting */
--- 418,428 ----
      lp = &du->dk_dd;
      secpertrk = lp->d_nsectors;
      secpercyl = lp->d_secpercyl;
+     if ((du->dk_flags & DKFL_BSDLABEL) != 0 && wdpart(bp->b_dev) != WDRAW)
+ 	blknum += lp->d_partitions[wdpart(bp->b_dev)].p_offset;
      cylin = blknum / secpercyl;
      head = (blknum % secpercyl) / secpertrk;
      sector = blknum % secpertrk;
      
  #ifdef TIHBAD144
      /* Check for bad sectors if we have them, and not formatting */

-tih
--
Tom Ivar Helbekkmo, NHH, Bergen, Norway.  Telephone: +47-5-959205
Postmaster for domain nhh.no.   Internet mail: tih@barsoom.nhh.no
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup
Date: 15 Sep 92 12:57:46 GMT
Organization: Uni-Duisburg FB9 Datenverarbeitung
Reply-To: veit@du9ds3.uni-duisburg.de
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <1992Sep14.232949.9093@bby.com.au> gnb@duke.bby.com.au (Gregory N. Bond) writes:

>>>>>> On 12 Sep 92 09:48:11 GMT, veit@du9ds3.uni-duisburg.de (Holger Veit) said:

>>> The program loader (kern_execve) resolves the lib references to the
>>> shared area, and makes the program's shared data segment
>>> copy-on-write so that it does not influence the memory of the
>>> library server.

>The kernel is probably the wrong place to put all this.  (kern_execve
>is hairy enough; witness the number of patches).  Instead, do it like
>SunOs does: include just enough stuff in the prolog to mmap() in a
>dynamic linker (/usr/lib/ld.so) written in PIC (with no global data)
>and jump to it.  Have it do all the fixups, then return.  Unmmap it
>and call the main() routine.

>This could be done completely independant of the kernel.

>Greg.
>--
>Gregory Bond <gnb@bby.com.au> Burdett Buckeridge & Young Ltd Melbourne Australia
>``USL has never sold long distance.  You're going after the wrong men in black 
>  hats.  (Or, in the case of Plan 9, black space suits)'' - Tom Limoncelli

This is what I originally intended; I'm just sitting in front of a Sparc,
and curiously watch what it is doing...:-). There are two possible problems:
1. What will Sun say about using (or reverse-engineering) their solution
   (in the light of AT&T vs. BSDI/UCB...)?
2. It is rumoured that the whole Sun DL stuff depends on or contains 
   self-modifying code, which caused/s problems with SunOS look-alikes 
   like Solbourne OS/MP (was fixed by some strange patch in OS/MP). I don't
   know whether this is needed (I suppose, not), but it make me think that
   this can be not a clean solution.

What is "the net's" opinion?

Holger
-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | BITNET: veit%du9ds3.uni-duisburg.de@UNIDO
|  | /   Dept. of Electr. Eng.   | "No, my programs are not BUGGY, these are
|  |/    Inst. f. Dataprocessing |          just unexpected FEATURES"
Newsgroups: comp.unix.bsd
From: mdurkin@tsoft.sf-bay.org (Mike Durkin)
Subject: Re: Danpex EW-2016 Ethernet card on 386BSD?
Organization: The TeleSoft BBS and Public Access Unix, +1 415 969 7958
Date: Wed, 9 Sep 1992 05:07:18 GMT

In article <5fnntrg.alm@netcom.com> alm@netcom.com (Andrew Moore) writes:
>Danpex EW-2016 is an inexpensive (US$85.) allegedly WD8013-compatible
>ethernet card.  I was wondering if anyone has gotten 386BSD to
>recognize it, and if so, what configuration and jumper settings they
>used.

I have one of these cards also and after fiddling a bit with the source
found that the checksum in the probe fails.  I commented it out and am
using the card successfully, NFS mounting to and from my Sun3s with no
problems.

in if_we.c, change it to something like...
--- cut ---
	/*
	 * Here we check the card ROM, if the checksum passes, and the
	 * type code and ethernet address check out, then we know we have
	 * a wd8003 card.
	 *
	 * Autoconfiguration: No warning message is printed on error.
	 */
	for (sum = 0, i = 0; i < 8; ++i)
	    sum += inb(is->id_iobase + WD_ROM_OFFSET + i);
	if (sum != WD_CHECKSUM)
        {
            printf("we: probe: checksum failed... installing anyway\n");
            /* return (0); */
        }
	sc->we_type = inb(is->id_iobase + WD_ROM_OFFSET + 6);
--- cut ---

Since irq2 == irq9, I kept the INSTALL.NOTES defaults for the settings
and the only changes I made to the cards defaults was to set the irq
jumper to IRQ9 (2), and I think I took off the boot prom jumper although
there isn't a prom anyway.


[...]
>
>But it is not clear what "iomem" should be.  The default for we0 is
>0xd0000.  I presume this corresponds to the "RAM buffer base address"
>jumper setting on the EW-2016.  If so, these addresses appear to be
>tied to specific interrupt values.  For IRQ 15, for instance, I/O
>(i.e., port) address 0x200 and iomem 0xdc00 (sic) are required.  I

I think this is just the way the examples are put together in the docs...
don't think they're tied together.

>tried iomem 0xdc000 too (with appropriate changes to the kernel), but
>this didn't work either.  What are the implications, if any, of such
>small iomem values (i.e., 0xd000 as opposed to 0xd0000)?
>
>Finally, the default iosiz for we0 is 8K (8196).  Does it matter that
>the EW-2016 RAM buffer size is 16K?  I tried both iosiz 8196 and 16384
>to no avail.

I don't completely understand the PROM and memory addressing myself...
can someone explain this?  Unless I'm missing something, I only see
how to set the prom address and not how to pick where the iomem goes.

     Mike

-- 
Mike Durkin / mdurkin@tsoft.sf-bay.org -or- apple!tsoft!mdurkin
Newsgroups: comp.unix.bsd
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Subject: Re: extract says its corrupt, damit!
Organization: Novell NPD -- Sandy, UT
Date: Wed, 9 Sep 1992 17:29:02 GMT

In article <3540@ra.nrl.navy.mil> solsman@ra.nrl.navy.mil (Mark Solsman) writes:
[ ... ]
>So I did just that, and now no matter what the hell I do, extract tells me
>that etc01.71 and bin01.46 are corrupt.  Now, I am using the same disks
>are I did before, and I even re-ftp-ed them from my workstation to my PC,
>when that didn't work, I even re-ftp-ed them from agate.berkeley to my PC,
>When that didn't work, I even ftp-ed them from agate.berkeley to my 386bsd
>setup using slip.  No matter what I do, these two files etc01.71 & bin01.46
>are corrupt.
[ ... ]

	Most likely, the file containing the checksum values is corrupt.  Try
downloading that again instead -- it'll probably clear up your problem.

	The other possibility is the new files are rewritten to bad sectors
on you disk.  If you dont:

	mv etc01.71 etc01.71.bad
	mv bin01.46 bin01.46.bad

Then you will never take those sectors out of circulation (this should be
done with bad144 at a later time).


					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: jensen@convex.com (Bill Jensen)
Subject: Re: Kernel build help
Organization: CONVEX Computer Corporation, Richardson, Tx., USA
Date: Wed, 09 Sep 1992 18:32:18 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

I ran into this problem, too.  If you compare the Makefile in the
directory GENERICISA with the Makefile for your system, you will
find the problem.  I think the template used by config Makefile is
out of sync with the sources.

What is missing is creating a new file, version.c, and then compiling
it to produce a version.o.  There is a script that does some fancy
stuff to increment version numbers (and it does it incorrectly, too)
so each time you do a make, the version number gets incremented.

I patched my Makefile and I haven't yet gotten around to fixing up
the template.

Bill Jensen
Convex Computer Corp.
(214) 934-2500
Newsgroups: comp.unix.bsd
From: david@mlb.geomechanics.csiro.au (David Le Blanc)
Subject: 'xdm' with crypt? I can't login if I use xdm.
Organization: CSIRO DIT (Melb.)
Date:  5 Sep 92 05:20:59 GMT


Can someone compile up xdm with DES encryption enabled  and send me a copy?

I have the DES stuff and crypt.c installed, so now xdm cannot allow me
to log in!

Cheers.
--
David Le Blanc                         :
Email: david@mlb.geomechanics.csiro.au : `Sort of a cross between a Jaguar
CSIRO Division of Geomechanics,	       :  and a freight train.' the Alien
P.O. Box 54 Mt Waverley 3149	       : in Alien^3.
Newsgroups: comp.unix.bsd
From: wolfy@ba.ncu.edu.tw (Jann-Yea Sue)
Subject: Re: X386 & Keyboard
Summary: This is a important letter to X386's keyboard 
Reply-To: wolfy@ba.ncu.edu.tw
Organization: Sun Microsystems, Inc.
Date: Tue, 8 Sep 1992 11:08:24 GMT



Newsgroups: comp.unix.bsd
From: spel@hippo.ru.ac.za (Dr. Eberhard W. Lisse)
Subject: Re: pascal compiler for 386BSD
Organization: Katatura State Hospital, Windhoek, Namibia
Date: Mon, 14 Sep 1992 17:51:17 GMT

In <1992Sep10.030726.1065@rucs2.sunlab.cs.runet.edu> cs120323@rucs2.sunlab.cs.runet.edu (cs120323) writes:

>I am looking for a pascal compiler for 386BSD Unix.
>the source code needs to be in C as that is the only 
>compiler I have on my system at this time.

Try p2c and let the net know what happened when you tried it.

el
-- 
Dr. Eberhard W. Lisse    \          /                   (spel@hippo.ru.ac.ZA)
Katatura State Hospital   \        |                            (el@lisse.NA)
Dept of Obstetrics & Gyn   \ *    /                         Private Bag 13215
Windhoek, Namibia           ;____/ (postmaster@uonamib.NA) Postmaster NAmibia
From: eddy@aludra.usc.edu (George Edmond Eddy)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD - Filesystem Trashed !!
Date: 12 Sep 1992 22:32:51 -0700
Organization: University of Southern California, Los Angeles, CA
NNTP-Posting-Host: aludra.usc.edu

zxmsd01@mailserv.zdv.uni-tuebingen.de (Gunther Schadow) writes:


yea, i used to get dynamically corrupted files...  until my filesystem
did get trashed!  now i cannot get the damn thing to reinstall. :-(

I am using conners IDE's.  i removed the :sf entry from disktab to 
sget disklabel not to put a badsect flag in.  now i cannot even 
install 386bsd anymore.

i just dunno whatta ima gunna do...

- rusty.

Newsgroups: comp.unix.bsd
From: wolfy@ba.ncu.edu.tw (Jann-Yea Sue)
Subject: Re: how to shutdown -todos?
Reply-To: wolfy@ba.ncu.edu.tw
Organization: Sun Microsystems, Inc.
Date: Tue, 8 Sep 1992 10:58:17 GMT
From: brtmac@maverick.ksu.ksu.edu (Brett McCoy)
Newsgroups: comp.unix.bsd
Subject: Re: backup w/ compression for UN*X?
Date: 6 Sep 92 14:01:31
Organization: Kansas State University
	<1992Sep4.085828.10853@ntuix.ntu.ac.sg>
	<1992Sep06.104350.2659@rubikon.han.de>
NNTP-Posting-Host: maverick.ksu.ksu.edu
In-reply-to: toad@rubikon.han.de's message of Sun, 06 Sep 92 10:43:50 GMT

In article <1992Sep06.104350.2659@rubikon.han.de> toad@rubikon.han.de
(Peter Cleve) writes:

>Something like this: (Not a ready to go script, but it shows the idea)
>
>YourFavoriteArchiver |
>YourFavoriteCompress | (
>	   echo Insert Media > /dev/tty
>	   read dummy < /dev/tty
>	   dd of=YourFavoriteDevice bs=Foo count=YourFavoriteMediaSize
>)
>
>Reading from the Media should be implemented easily too.

There is a serious problem with this scheme.  You have to read every
single disk, or whatever, to get a file that is on the last disk.
Also, if a disk in the middle of the dump is bad there is no way to
get the data from the disks following the bad one because you can't
start reading a compressed file in the middle.

++Brett;
From: solsman@ra.nrl.navy.mil (Mark Solsman)
Newsgroups: comp.unix.bsd
Subject: bsd386 slip xfer rate disappointing.
Date: 9 Sep 92 05:55:33 GMT
Distribution: world
Organization: Naval Research Lab, Washington, DC


Is everyone getting the same response?  slip from 386/25 running bsd to
a 486/50 running slip8250 & tn3270 yeilds about .8k/second???

funny, I am using slattach /dev/com2 38400, that should be damn faster than
800 bytes/second...

also, as far as the silo overflows , I seem to only get them when I 
have a packet collision.  dont type anything until after xfers, and turn
off the damn hashing, and you dont get any overflows...  this maybe a side-
effect.
-- 
Mark Solsman                                 Building 1, Code 5160
United States Naval Research Laboratory      solsman@ra.nrl.navy.mil
Washington, DC                               (202) 767-5769
Newsgroups: comp.unix.bsd
From: stripes@pix.com (Josh Osborne)
Subject: Re: Shared Libs for X11?, was Re: 386bsd -- The New Newsgroup
Organization: Pix Technologies -- The company with no adult supervision
Date: Wed, 16 Sep 1992 00:43:29 GMT

In article <1992Sep15.143458.15689@news.cs.brandeis.edu> st923150@pip.cc.brandeis.edu writes:
>[...] A small kernel extension may be needed to alias the text
>segment to a r/w data segment (as Intel text segments are either execute only
>or execute/read, but not e/r/w).

The same RAM can (and IS) mapped by more then one segment.  As far as I can 
tell the default CS and DS point to the same RAM, so that shouldn't be a
problem.
[...]
-- 
           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
From: wjolitz@soda.berkeley.edu (William F. Jolitz)
Newsgroups: comp.unix.bsd
Subject: Re: Fixed: Runs at 8MHz, Crashes at 33MHz, 386bsd
Keywords: bug
Date: 13 Sep 92 19:13:10 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
NNTP-Posting-Host: soda.berkeley.edu

In article <j=xnk_a.alm@netcom.com> alm@netcom.com (Andrew Moore) writes:
>In article <1992Sep12.134712.17755@news.cs.indiana.edu> "Michael Squires" <mikes@moose.cs.indiana.edu> writes:
>
>    QAPlus (DOS) long memory test uncovered an intermittent RAM error
                  ^^^^
If this means 32-bit wide memory test, then I think you are correctly isolating
the problem. Note that most PC memory checkers only do 16bit loads/stores.

When I was originally doing 386bsd, I had real stability problems with my
386SX noname laptop. I eventually traced it to memory corruption. Yet, in
running various PC memory checkers for *days* without a peep, I could not
find the problem. I wrote a trivial one in the bootstrap that ran in 32bit
protected mode, and it failed in less than a second.

The problem turned out to be two problems. 1) a mechanical problem with the
extended memory card's socket (cured with a pliers), and 2) the "extended
setup" for the chipset did not set the "no interleave" bit for my odd-banked
386SX. BTW, Windows-3 also tended to be screwed by the same feature. Two
I/O instructions and no more problems.

This problem reccured when I got an ethernet card later. I found that it was
due to the I/O extension "backplane" in the laptop missing a few connections
to the toshiba slot. The company ECO'ed the laptop when the  trouble was
isolated, and mumbled something about expecting customers only to ever use
the slot for modems.

The moral of the story here is that for many PC's, 32-bit operation can 
still be the "undiscovered country".

When I was working on 2.8BSD, the PDP 11/40 in the virus lab suddenly began
doing "impossible" things. Immediately I ran diagnostics. Nothing. Got DEC
out, and they found nothing. In frustration, I keyed in the following
machine program through the front panel:
	cmp $0,$0
	beq	1b
	halt
It ran for about 30 seconds and stopped. Starting it again, it ran for a
minute and stopped. After much work swapping boards, backplanes, power
supplies, and phone calls, the DEC CE and I carefully cleaned the processor's
edge connectors, and it succeeded in running the "diagnostic" all night.


Bill.
Newsgroups: comp.unix.bsd
From: colin@marsh.cs.curtin.edu.au (Colin Manning)
Subject: Re: How to extract X386
Organization: Curtin University of Technology
Date: Mon, 7 Sep 1992 03:32:40 GMT

mark@student.business.uwo.ca (Mark Bramwell CS Staff) writes:

>I am new to bsd.  I have been able to download the file, and create a
>working bsd machine on the first try.  The networking works fine also.
>The X386 files are named differently than bin01, etc01, ....

>How does one extract these files?

cat path/X386* | uncompress | tar -xf -


>mark@student.business.uwo.ca (Mark Bramwell CS Staff)
>Western Business School  --  London, Ontario
--
Colin [colin@cs.curtin.edu.au]

"Knowledge is not knowing all the answers, but knowing where to find them."
                                                                  -anon.
Newsgroups: comp.unix.bsd
From: jsbazine@garfield.waterloo.edu (Steve Bazinet)
Subject: Dist.fs won't boot.
Reply-To: jsbazine@garfield.waterloo.edu
Organization: Department of Computing Services, University of Waterloo
Date: Fri, 4 Sep 1992 22:58:11 GMT

Ok I have downloaded dist.fs and fixit.fs but the dist.fs won't boot.  I waited
5 mins and all that happened was the drive light stayed on but the heads were
not moving. 

When I boot with fixit.fs it boots up ok...any suggestions

Steve

---
===============================================================================
=                               Steve Bazinet                                 =
=         Department of Computing Services - University of Waterloo           =
=    jsbazine@garfield.uwaterloo.ca  (or)  jsbazine@watserv1.uwaterloo.ca     =