HDTenEightyP/NetNews huggingface dataset:
From: veit@du9ds3.uni-duisburg.de (Holger Veit)
Newsgroups: comp.unix.bsd
Subject: Re: German keyboard
Date: 6 Oct 92 09:31:05 GMT
Reply-To: veit@du9ds3.uni-duisburg.de
Organization: Uni-Duisburg FB9 Datenverarbeitung
NNTP-Posting-Host: du9ds3.uni-duisburg.de

In <1992Oct5.153058.29683@unibi.uni-bielefeld.de> chr@bio128.uni-bielefeld.de (Christian Bartling) writes:


>Is it possible to use the German keyboard arrangement under BSD 0.1, or  
>supports BSD only the US keyboard layout ?

>---
>Christian Bartling
>chr@bio128.uni-bielefeld.de

Since the national keyboard question occurs quite often:
I wrote a pccons replacement package entitled 'keycap-0.1.0.tar.Z' which
allows mapping any national keyboard layout to the console. This package
will very likely become standard in the next 386bsd release. This package
is currently not compatible with X11 (not even with the kernel patches for 
X386), but there is a new (restricted) beta release 0.1.1 which fully supports
(the coming version of) XFree86-1.2. If you are interested in the betakit,
send me mail. Otherwise the 0.1.0 version is at
ftp.uni-duisburg.de in /pub/unix/386bsd-0.1/unofficial/keycap-0.1.0.tar.Z.

Holger

-- 
|  |   / Dr. Holger Veit         | INTERNET: veit@du9ds3.uni-duisburg.de
|__|  /  University of Duisburg  | "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
|  | /   Dept. of Electr. Eng.   |   Sorry, the above really good fortune has
|  |/    Inst. f. Dataprocessing |      been CENSORED because of obscenity"
Newsgroups: comp.unix.bsd
From: greg@coombs.anu.edu.au (Greg Price)
Subject: I'm a dud...and need help!
Keywords: cdrom
Organization: Computer Services Centre, Australian National University
Date: 27 Sep 92 04:10:06 GMT

This is my confession!

I bought a CD-ROM drive (Sound Galaxy CR-522-B with a Panasonic Drive).
There is a dos driver (fine), but I wanted to get programming info and
the retailer has been unable to get it. The interface is the AT type,
ie proprietary. Apparently the drive can be used on Sound Blasters, any
way, I want the low level programming info so I could work on a driver
for 386BSD, but I appear to be stuck. I have asked for help in alt.cd-rom
and a pc group, but got no responses, so I ask two things.

1) Does anyone know how/where I could get programming info I need, or

2) If I could get it swapped for the SCSI version of the panasonic drive
   what types of scsi controller could/should I get for it. The Adaptec
   1542 costs as much as the drive alone! I don't mind working on the
   drivers for a different type of controller, but I would need info for
   it (ie the scsi controller and possibly some stuff about the drive,
   although the scsi should be standard). Is it anticipated more scsi
   controllers will be supported, etc?

There is my case, so please,  * * H E L P * * !
Thanks,
Greg
(greg@coombs.anu.edu.au)

Xref: sparky comp.unix.bsd:6540 comp.os.linux:11960
From: peter@NeoSoft.com (Peter da Silva)
Newsgroups: comp.unix.bsd,comp.os.linux
Subject: SMS OMTI ESDI/MFM controllers
Date: 29 Sep 92 03:48:30 GMT
Article-I.D.: NeoSoft.1992Sep29.034830.5656
Organization: NeoSoft Communications Services -- (713) 684-5900

The SMS OMTI controller is designed to support both ESDI and MFM/ST506 drives
concurrently, up to 4 drives per controller (using drive address jumpers for
addresses 0-4 instead of setting all drives for address 1 and twisting the
drive address line.

Does the 386BSD hard disk driver support this card, and if not is there a
driver for 386BSD or Linux that does?

Alternatively, does 386BSD and/or Linux support multiple hard disk controllers
(say, one MFM and one ESDI)?
-- 
Peter da Silva.  <peter@sugar.neosoft.com>.
 `-_-'   "Segodnja volka obnimal?"
  'U`
From: root@knobel.GUN.de (Root at knobel)
Newsgroups: comp.unix.bsd
Subject: Re: 386BSD - what a pain to install!
Date: 26 Sep 92 05:15:56 GMT
Organization: Andreas Klemm, 4040 Neuss, Germany

bs@Germany.EU.net (Bernard Steiner) writes:

>In article <1992Sep22.175431.1@vax.sonoma.edu>, levinson@vax.sonoma.edu writes:
>> In article <1992Sep22.225256.25660@minyos.xx.rmit.oz.au>, rcskb@minyos.xx.rmit.oz.au (Kendall Bennett) writes:
>[LOTS of laments about 386bsd deleted]

>Folks,
>face it: this is an ALPHA system. Don't expect it to be as stable as one of
>the commercial ones that have been selling for years on end.

>And *please* RTFM and the FAQ's etc before starting to natter about a system.

Hi !

386BSD WHAT A BEAUTY TO INSTALL !!!
It's faszinating how _easy_ it is to do a network based installation!
I created 3 large cpio archives out of the splitted stuff in the
bin01, etc01, src01 distribution.
If I want to install a new experimental System, I only have to
insert the boot disk, doing the basic installation and then getting
the three archives via ftp from my archive host.

You only have to initialize the ethernet board by hand.
For example: ifconfig we0 inet 149.237.4.124 netmask 255.255.255.0
after that: ifconfig we0
            verifying the settings
then: ftp 149.237.4.45
login.....
get the stuff in binary mode..... (with 190-230 Kb/s, depends on disk and
network performace)
back to local System
for i in bin01.cpio.Z etc01.cpio.Z src01.cpio.Z
do
zcat $i | cpio -icvmdul && rm $i
done
sh /tmp/..... (don't know exactly the name of the install script ? )
shutdown -todos
reboot
You have a complete UNIX Installation in about 90 Minutes or so...

And this kinda easy installation requires simply 1 Floppy Disk to boot
about 180 MB free space on harddisk.

Another good idea would be to make a backup with tape immediately 
after installation and installing with tape.
So you don't have the overhead of three large cpio archives during
installation (about 50 MB) !!!

Bye
Andreas
-- 
+++ Andreas Klemm +++ 4040 Neuss 21 +++ Germany +++ Phone: +49 2137 12609 +++
Newsgroups: comp.unix.bsd
From: tim@kimba.catt.citri.edu.au (Tim Liddelow)
Subject: xlock won't recognize password
Organization: CATT Centre at CITRI, Melbourne, Australia
Date: Tue, 29 Sep 92 22:21:58 GMT

Hi all.  I compiled up a X11R5 raw version of xlock from the X contrib
directory at one of the X mirror sites here.  The problem is that it compiled
up pretty well fine, but it won't recognize my password.  Now could this be
anything to do with crypt() I added to the standard C library ?  Or can't
it handle the shadow password entries (surely that would be built in to 
the system calls.)

Does anyone have a working version ?

Thanks
Tim.

-- 
________________________________________________________________________________
  Tim Liddelow                                          for(;;) fork();
  Systems Programmer
  Centre of Advanced Technology in Telecommunications   My brain on a bad day.
  CITRI, Melbourne, Australia                           
  internet : tim@kimba.catt.citri.edu.au                
  Phone : +61 3 282 2455   Fax : +61 3 282 2444	        
________________________________________________________________________________
From: linkt@GroupW.cns.vt.edu (Tim Link)
Newsgroups: comp.unix.bsd
Subject: 386BSD - SIOGIFCONF ioctl  *** BUG *** ????
Date: 29 Sep 92 21:45:14 GMT
Followup-To: linkt@GroupW.CNS.VT.EDU
Organization: Va Tech Communications Resources

I posted a bug/problem/question/sample-code related to the SIOGIFGONF
ioctl function (the jest of which was - is it truely returning what it
should? i.e. the network interface configuration).  After a little more
prodding AND testing on NON-386BSD systems, I'm 90% sure that that this
call DOES NOT doe what it should on 386BSD boxes.  Can anyone confirm or
deny this for 
certain AND if so is someone already working on a fix???
Thanks.... Tim
ACK!
Newsgroups: comp.unix.bsd
From: pbd@runyon.cim.cdc.com (Paul Dokas)
Newsgroups: comp.unix.bsd
Subject: X386 gives a bus error in ET4000EnterLeave()
Date: 2 Oct 92 21:11:25 GMT
Article-I.D.: shamash.48243
Organization: ICEM Systems, Inc.

I've completely rebuilt X11R5 from the original (patched) MIT source
and now I'm trying to run it, but typing "X386 :0" results in:

       X386 Version 1.2E 1.0.1  / X Window System
       (protocol Version 11, revision 0, vendor release 5000)
       Bus error

:-(

My SVGA card is a et4000 card (Diamond SpeedStar Plus) in a generic
386.  I've tried several different Xconfig's, but there seems to be
little difference:

 .
 .
 .
#
# The graphics drivers
#
vga256
  chipset "et4000"
  videoram 1024
  viewport 0 0
  virtual 1024 1024
  clocks 25 28 65 72 79 59 64
  modes "640x480" "800x600" "1024x768"

ModeDB
#Modename    clock  horzontal timing      vertical timing
 "640x480"   25     640  664  760  800    480  491  493  525
 "800x600"   36     800  824  896 1024    600  601  603  625
             40     800  840  968 1056    600  601  605  628
 "1024x768"  65    1024 1088 1200 1328    768  783  789  818

I've run X386 through gdb and found that it's dying on line 398
of et4000/driver4.c, which is:

      vgaIOBase = (inb(0x3CC) & 0x01) ? 0x3D0 : 0x3B0;

(actually in the inb() which is an inline function found in ../../compiler.h)
So it seems that I can't read/write to the needed ports. Anyone have any
suggestions?  Am I SOL because of the Diamond card?  I thought that the
proprietary clocks were only on the newer cards like the Stealth.

BTW, I've patched and rebuilt my kernel with the XSERVER patches.  I've
also created a /dev/vga with "mknod /dev/vga c 12 0".

-- 
#include <std.disclaimer>
#define FULL_NAME                          "Paul Dokas"
#define EMAIL                              "pbd@runyon.cim.cdc.com"
/* we are realizing infinite possibilities in exchange for our soul */
Newsgroups: comp.unix.bsd
From: rt@MAGEC.COM (49)
Newsgroups: comp.unix.bsd
Subject: Re: Catch What They're Saying About Us...
Date: 25 Sep 92 15:04:32 GMT
Organization: MAGNAVOX Electronics Systems Co., Fort Wayne

In article <19oe23INNqh0@agate.berkeley.edu>, wjolitz@soda.berkeley.edu (William F. Jolitz) writes:
> 
> Check out the "Re: Linux or 386BSD: neither or both ??" thread in
> comp.os.linux. It's pretty amazing what's being said about 386BSD and
> the people who've worked so hard on it.
> 
	[ Rest Deleted ]

FLAME MODE IS OFF!

I am realy saddened to see this sort of personal bickering break out.

But, What goes around comes around!  When I think back over the postings
to c.u.b. by you Lynne, many have expounded on the faults of others.
It's too bad, we will never reach our full potential this way.

-- 
Al Marshall
rt@magec.com					Standard Disclaimer...
netwrk!rt
Newsgroups: comp.unix.bsd
From: per@oslace.ENET.dec.com (Per Soderlind)
Subject: 386BSD doesn't understand Ultrix QIC tape
Reply-To: per@oslace.ENET.dec.com (Per Soderlind)
Organization: Digital Equipment Corporation A/S Norway
Date: Mon, 5 Oct 1992 19:26:45 GMT


Hi,
I'm trying to copy the 386BSD kit doing the following :

On my Ultrix workstation )
	tar cvf /dev/rmt2m 386bsd.files 
rmt?m = QIC-150 fixed block size

On my PC at home)
	tar xvf /dev/as2a

This results in a lot of error mesg.

What is the problem,
should I use rmt?l (= QIC-120 fixed block size)?
From: gab10@cd.amdahl.com (Gary A Browning)
Newsgroups: comp.unix.bsd
Subject: Re: new new scsi release beta2 part 1 of 5 (fixed)SKIP
Date: 2 Oct 92 06:20:13 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <rwa.717885468@aupair.cs.athabascau.ca>,
rwa@aupair.cs.athabascau.ca (Ross Alexander) writes:
> terry@cs.weber.edu (A Wizard of Earth C) writes:
> 
> >Currently, the command line configuration tools are abominable.  I
> shouldn't
> >have to edit my file (hoping I have the right one) to change an IRQ
> or add
> >pty's, config it, change directories (making sure I get the one named
> the
> >same as my file), make depend, make, and then manually install the
> resulting
> >executable, remembering to delete the devices which are no longer
> applicable
> >to my new configuration, and adding the ones which are but did not
> exist
> >prior to the most recent rebuild.
> 
> <yawn, another newbie...>
> 
> If you can't handle it, admit you're an incompetent and stay out of
> the kitchen.  You might change your silly mail address too; a wizard
> indeed!  Real wizards don't so much as imagine that the simple list
> of
> trivial steps you mention are worth spending time on, much less
> kvetching about.
> 
> Just run the GENERIC kernel, and leave the hacking to your betters.

This is a joke, right?  Where are the happy faces?

If this is indeed serious, please let us know as soon as possible so
that we all
can add your name to our Author Kill Lists.

If you have something to say, try and do it in an adult sort of way, will ya?
That way, someone might listen.

Have a nice day.
-- 
Gary Browning        | Exhilaration is that feeling you get just after a
		     | great idea hits you, and just before you realize
                     | what is wrong with it.
From: gpw10@phoenixcd.amdahl.com (Gary Ward)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] Only root can login & MAXUSERS > 4?
Keywords: Permission denied  MAXUSERS  386BSD
Date: 1 Oct 92 16:00:06 GMT
Organization: Amdahl Corporation, Sunnyvale CA

In article <1992Sep30.071252.4571@autelca.ascom.ch>,
nbladt@autelca.ascom.ch (Norbert Bladt) writes:
> bvickers@valentine.ics.uci.edu (Brett J. Vickers) writes:
> 
> >2. I recompiled the kernel, setting MAXUSERS to 16, so that I could
> >   at least open a few windows under X386, but it still limits me
> >   to 4 pty's.  What have I done wrong?
> The number of MAXUSERS is not related to the number of pty's you can
> access.
> In the config file for your system there is a line containing
> something
> like
> 	pty	4
> You should change this 4 to, say, 16 and voila, you will have 16
> pty's
> devices for X (after creating a new kernel with this config file, of
> course).

Better yet, change it to
	pty

If you don't specify a number, no arbitrary limit is assigned and you
can have more at any time just by making the nodes in /dev (i.e. no
additional kernel rebuilds)

> I am not sure whether you have to create the devices in /dev or whether
> they do exist already. To be sure, look in /dev for *pty* files.
> If the don't exist, you can create the device entries by calling
> 	MAKEDEV pty
> (or something similar). You should look into the MAKEDEV file to find
> out what the exact syntax is. I am sorry to be not very specific, but I
> have my 386BSD system at home and I am at work, now.
> 
> Hope this helps, anyway,
> 
> 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

-- 
+------------------------+---------------------------+
| Gary Ward              |  Amdahl Corporation       |
| gpw10@cd.amdahl.com    |  1250 East Arques Avenue  |
| Phone : (408)746-8865  |  P.O. Box 3470 M/S 142    |
|                        |  Sunnyvale, CA 94088-3470 | 
+------------------------+---------------------------+
From: forsyth@minster.york.ac.uk
Newsgroups: comp.unix.bsd
Subject: configuring special files in /dev
Date: 30 Sep 92 10:50:52 GMT
Organization: Department of Computer Science, University of York, England

try making /dev by mounting a new file system type supplied by the kernel (cf. /proc).
the file system type (VFS) provides file and directories based on
the contents of the kernel device tables.
(the struct dirent entries are generated on-the-fly in response to readdir requests.
lookup needn't generate names: it can simply search for the given names in a device table.)

it works very well.
i do something like this in my own o/s for the sun3 and 386 (not available, sorry), using
a file system interface similar in principle to VFS/Vnode, but simpler.
my file system type doesn't allow new files, directories, or symlinks to be created,
but it could.


configuration scripts can then be run by having /etc/rc (or equiv.) invoke
	/bin/test -c /dev/something && sh /etc/devinit/something
something like this is necessary to chown and chmod devices initially
(if the default settings aren't acceptable), since /dev is no longer persistent
across boots.

this approach does have the advantage that discless booting and operation is trivial.
it certainly avoids the wretched snode/vnode/realvp aliasing hacks in SunOS!
Newsgroups: comp.unix.bsd
From: sthomas@worldbank.org (Sidney F. Thomas)
Subject: Help! TinyBSD doesn't boot
Organization: The World Bank, Washington, DC, USA
Date: Fri, 2 Oct 1992 20:50:44 GMT

TinyBSD booted ok on my 386DX/16MHz Zenith at the office.
When attempting to boot on the machine at home, the system
would just hang.  The system at home is an AST 386DX/20MHz 
Premium C model with RAM Caching, Orchid Prodesigner IIs SVGA card,
4MB RAM.  I suspect a compatibility problem with the video card.
Could some kind soul tell me what the minimum system requirements 
are for TinyBSD to work.

Thanks much!

--Sidney Thomas
From: gpalmer@cs.strath.ac.uk (Gary J Palmer IE91)
Newsgroups: comp.unix.bsd
Subject: [386 BSD] Distribution discs from FTP
Date: 5 Oct 92 18:22:26 GMT
Organization: Comp. Sci. Dept., Strathclyde Univ., Glasgow, Scotland.
Originator: gpalmer@fleming-08


    Before the summer I looked at getting myself a copy of 386bsd, and 
actually ftp'ed the high density distribution discs from a local site. (At
that time they were called 'disc1.Z', etc). I have had a look again 
recently, but I can`t seem to find the discs in one piece. Can someone
tell me how to get these multiple pieces onto high density discs in the
correct order?? I do *not* require the sources or X, just the basic
system binaries.

Thanks

Gary Palmer

P.S. E-Mail replies prefered. Thanks again
-- 
JANET		: gpalmer@uk.ac.strath.cs
Other Nets	: gpalmer%cs.strath.ac.uk@ plus one of :-
BITNET: UKACRL     UUCP: ukc.uucp    Internet: nsfnet-relay.ac.uk
Programmers do it on Archimedes. #include <std.disclaimer>
From: bvickers@valentine.ics.uci.edu (Brett J. Vickers)
Subject: [386BSD] Xfree86 Diamond SpeedStar 24 1024x768 Success!
Newsgroups: comp.unix.bsd
Organization: Univ. of Calif., Irvine, Info. & Computer Sci. Dept.
Date: 1 Oct 92 03:03:10 GMT

After messing around for a long time I finally got 1024x768 mode to
work using my Diamond SpeedStar 24.  Here are the steps I had to take:

1. Boot to DOS and run VMODE MONITOR so that the card will allow a
   65MHz rate.
2. Warm boot to 386BSD (don't shut the computer off now!)
3. Make sure the following two lines are in your Xconfig:

	Clocks 25 28 61 65 25 28 61 65

	(and under the mode list...)

	"1024x768"  65  1024 1024 1096 1312   768 768 769 790

	(I borrowed that mode from someone else's post. Thanks whoever!)

4. Start up X.  It should work as long as your monitor can sync the
   required frequencies (I'm using a ViewSonic 5E).

For a long time it wouldn't start because the standard Xconfig that comes
with Xfree86 doesn't have the "Clocks" line.  I had to add it in to get the
thing to recognize the new frequencies above 28MHz.  Unfortunately, you
have to boot to DOS and run VMODE before you start 386BSD.  But if you leave
your system on for a long time (as I do), this is no big deal.  Warm boots
don't reprogram that SpeedStar's clock settings.  Hopefully, someone will
figure out how to program the sucker and we can get a 386BSD version of
VMODE.

--
Brett J. Vickers		 "Don't go around saying the world owes you
bvickers@ics.uci.edu		 a living.  The world owes you nothing.
				 It was here first."  - Mark Twain
Newsgroups: comp.unix.bsd
Date: Mon, 5 Oct 92 19:23:06 EDT
From: lim@cs.columbia.edu (Jong Gyun Lim)
Subject: Re: Gateway 486, Wangtek 5150 & Sun tape drive, KCL
Organization: Columbia University Department of Computer Science

In article <1992Oct4.170255.4029@spcvxb.spc.edu> you write:
>In article <CMM.0.90.2.718183986.lim@cs.columbia.edu>, lim@cs.columbia.edu (Jong Gyun Lim) writes:
>

[other encouraging answers saved away]

>  No problems, although you do have a second controller generating heat, etc.
>The 1542B uses different I/O ports from the IDE controller. On my BSDI system
>I ran a 210Mb IDE, 760Mb SCSI, and the tape all at the same time.
>
>  Your budget and possible growth plans should be considered when thinking
>about converting the IDE to SCSI. Is the IDE controller on the motherboard
>or on an expansion card?



I decided to stay with IDE HD, and ordered the Wangtek 5150ES and Adaptec 1542.
(Gateway offered me $200 upgrade option for the controller, so now I am
only risking $550 rather than $600. heeuh.) The IDE controller is on an
expansion card.  So, I will have two controller cards generating heat.
Will be kinda nice in the winter :)


To summarize the answers that I received through e-mail, XFree86 currently
does not support Gateway ATI Ultra Pro Video card or other 8541/A based
video cards (thanks Rik Faith and Kevin Martin for your answers.)  386BSD
does support HP IIIP with a package called "psf" or "psf3", which is
available from all archives (thanks Hellmuth Michaelis for you answer.)



>
>	Terry Kennedy		Operations Manager, Academic Computing
>	terry@spcvxa.bitnet	St. Peter's College, Jersey City, NJ USA
>	terry@spcvxa.spc.edu	+1 201 915 9381



	Jong-Gyun Lim
Newsgroups: comp.unix.bsd
From: julian@tfs.com (Julian Elischer)
Subject: Re: 386BSD Questions (16+MB ram)
Organization: TRW Financial Systems
Date: Sat, 3 Oct 1992 21:40:59 GMT

In article <1992Oct3.150747.11580@Urmel.Informatik.RWTH-Aachen.DE> kuku@acds.physik.rwth-aachen.de writes:
>
>I'm also wondering about this ongoing discussion on "16MB limit on the ISA bus".
>Recently I had a 486/33 motherboard which could be populated with 32 MB of
>4MB SIMMs. 
>
>Is 386bsd bound to a 16MB limit? I cannot believe that.
>

Well, the problem occurs with devices that use DMA.
They only have 24 address bits if they use the ISA dma (8bit)
or have their own DMA systems.

386BSD has in it a 'bounce buffer' system to allow such devices
to dma stuff down to the bounce buffer from which it is copied
to the high memory. The problem with this is it only really
works well for devices that do single section (non scatter-gather)
DMA.

For this reason the adaptec 1542 scsi driver will not support
more than 16MB on any machine.
The bustec 742a and adaptec 1742 drivers are EISA board drivers
and DO support upto 4GB ram.

I'm sure some system could be worked out where every
section of a scatter-gather operation could be
checked and those above 16MB could be relaced with
multiple 'bounce buffers' but I don't think it's
worth it..
if you want >16MB you probably want performance too
and EISA boards are getting cheaper.

incidentally, on an EISA machine there is a register that
supplies the top 8 bits of a motherboard DMA with address bits
so if the option EISA is true, we should use that rather than
the bounce buffer.

julian
.