From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 00:28:40 1993 From: nix@stekt4.oulu.fi (Tero Manninen) Subject: Re: 713/714 kernel & misc problems To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 792 Sender: NetBSD-Admin@cbmuucp.commodore.com > I took the 713 sources and compiled (removing unnecessary > devices) making a good vmunix. > > > Problems: > - kernel boots fine into single user, but screen mode > is really messed, like a HAM mode or something > (background is yellowish, characters are smeared), > but system functions well (I can type and do things). Oops, I forgot to mention the problematic system: A3000 25MHz, 16+2M ram 105M + 425M SCSI disk Archive Viper SCSI tape drive gcc 2.4.3 (vmunix compiled in netbsd) system configuration file modifications were these: removed a2091 and gvp11 configurations removed le0 and tiga0 configurations missing strncpy.s and strncmp.s were copied from NetBSD-current lib/libc/../m68k directory. I used the newest loadbsd binary (loadbsd.713). ++Tero From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 01:19:25 1993 From: niklas@appli.se (Niklas Hallqvist) To: netbsd-amiga@cbmuucp.commodore.com Subject: My PAL problems... Sender: NetBSD-Admin@cbmuucp.commodore.com I've now got somewhat further on the path to a 724x564 CC screen. The Y axis only needed the leading WAIT intruction patched to wait for 28 instead of 41 and the PAL vbl shoud check for 27 rather than 40. I think these could be changed generally, but I'm not sure. Chris? I still have problem with the X resolution though. If I use a hstart of 0x5d, the first char is about 8 pixels in from the left edge of the visible area and I can get 704 pixels width. If I try to make it wider the HSYNC gets lost. Now if I set hstart to 0x5c or less, the diplay jumps about 16 pixels left, so I cannot see the first char on each line. Although now I can extend the width. In ADOS I can get this screenmode so it's not my monitor that's bad. Could it be some ddfstart magic, not using the default calculation that's needed. Someone got any clues? Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 01:24:38 1993 From: niklas@appli.se (Niklas Hallqvist) To: nix@stekt4.oulu.fi Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: 713/714 kernel & misc problems Sender: NetBSD-Admin@cbmuucp.commodore.com Tero wrote: > - kernel boots fine into single user, but screen mode > is really messed, like a HAM mode or something > (background is yellowish, characters are smeared), > but system functions well (I can type and do things). Did you change the default resolution parameters {ite,view}_default_{height,width}? If so you could be bitten by the autocentering code, I was :-( I hope to sometime soon have a Hints file (or even a patch) to make overscan simpler. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 04:11:17 1993 From: Bill Squier To: netbsd-amiga@cbmuucp.commodore.com Subject: USA mirror for NetBSD Sender: NetBSD-Admin@cbmuucp.commodore.com Does anyone on this list have the power to get an FTP site to do a nightly mirror of ftp.eunet.ch:software/os/bsd/NetBSD/NetBSD-Amiga? With the size of the recent releases, I get pangs of guilt every time I yank that much data across the ocean... -wps From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 09:13:51 1993 From: dvb@ssd.kodak.com (Dave Blaszyk) To: tsarna@endicor.com Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: NetBsd on CDROM? Content-Length: 0 Sender: NetBSD-Admin@cbmuucp.commodore.com I would like to clarify... My understanding is that the NetBSD distribution would be included with "other" non-related Fred Fish disks. (ie. Fred Fish disks 0-nnn and AMINET stuff). Since "other" stuff would be included, I assume that there would be a need to "place" the NetBSD distribution on it's own session of a CD. What I am in favor of is a CD, with only NetBSD. This CD will allow me to boot and/or install NetBSD directly from /dev/cdrom or to my hard disk of choice. -dvb-) From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 09:14:03 1993 From: dvb@ssd.kodak.com (Dave Blaszyk) To: markus@techfak.uni-bielefeld.de Cc: tsarna@endicor.com, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: NetBsd on CDROM? Content-Length: 0 Sender: NetBSD-Admin@cbmuucp.commodore.com Although I agree with a "central" distribution scheme. I don't believe that using a FF CDROM as the best solution. Since to distribute the CD properly you would need a multi-session disk and most people or even some don't have support for multi-session disks. The best possible distribution would be similiar to how Linux is provided by Yadgrsill (sp?). A complete, bootable version of Linux... Just my thoughts, -dvb- /-// \\-\Dave Blaszyk e-mail : dvb@ssd.kodak.com /-//\ /\\-\(716) 253-7953 mail : Eastman Kodak ///d// \\v// \\b\\\ C Plant, Bldg. 10 MC 39011 \\\// \// \\/// Rochester, New York 14620 From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 10:57:28 1993 From: Ralph Schmidt Subject: Re: NetBsd on CDROM? To: dvb@ssd.kodak.com (Dave Blaszyk) Cc: tsarna@endicor.com, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1242 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I would like to clarify... > > My understanding is that the NetBSD distribution would be included with "other" > non-related Fred Fish disks. (ie. Fred Fish disks 0-nnn and AMINET stuff). > > Since "other" stuff would be included, I assume that there would be a need to > "place" the NetBSD distribution on it's own session of a CD. Just want to correct something here. You don't really mean Multi-Session..Multi-Session has only a meaning with multiple writes to that CD. The CDRom driver or the software has to map the multiple session rootblocks on one root-block, so the software sees the new contents of the cdrom. You mean Multiple-Volumes on the CDRom. ISO9660 supports something like that but by now i haven't seen any CD that has multiple-volumes and don't know any Amiga ISO9660 filesystem that supports that. Anyway...what's the problem to mix NetBSD with AmigaOS on one volume ? I can't see one. > > What I am in favor of is a CD, with only NetBSD. This CD > will allow me to boot and/or install NetBSD directly > from /dev/cdrom or to my hard disk of choice. > Would be nice..indeed. Regards -- Ralph Schmidt laire@uni-paderborn.de University of Paderborn (Germany) From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 12:34:13 1993 From: Tero Manninen Subject: Re: 713/714 kernel & misc problems To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 432 Sender: NetBSD-Admin@cbmuucp.commodore.com > Tero wrote: > > - kernel boots fine into single user, but screen mode > > is really messed, like a HAM mode or something [...] > Did you change the default resolution parameters > {ite,view}_default_{height,width}? If so you could be > bitten by the autocentering code, I was :-( Nope.. just made 'config AMIGA' and 'make' Then copied the vmunix to amigados via bffs mounted filesystem and 'loadbsd vmunix'. > Niklas ++Tero From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 13:28:11 1993 From: mykes@shell.portal.com (Mike Schwartz) Subject: X11R5-contrib.tar.gz To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 190 Sender: NetBSD-Admin@cbmuucp.commodore.com It's a bad file (the one on ftp.eunet.ch) to the best of my knowledge... /net/u2/netbsd/packages amiga0# gzip -d X11R5-contrib.tar.gz gzip: X11R5-contrib.tar.gz: unexpected end of file From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 13:57:53 1993 From: Peter.Sjostrom@ludd.luth.se Subject: Re: USA mirror for NetBSD To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 468 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Does anyone on this list have the power to get an FTP site to do a > nightly mirror of ftp.eunet.ch:software/os/bsd/NetBSD/NetBSD-Amiga? > > With the size of the recent releases, I get pangs of guilt every time > I yank that much data across the ocean... There are already some 10 sites who does mirror NetBSD-Amiga!!! ftp.wustl.edu does, but might be late, ftp.luth.se has a very good speed across the Atlantic and will get 24 Mbit/s January 3. /Peter From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 14:13:32 1993 From: Philippe BRAND Subject: Re: X11R5-contrib.tar.gz To: mykes@shell.portal.com (Mike Schwartz) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Organization: Telesystemes/Symedia Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 708 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello, Mike Schwartz writes: > It's a bad file (the one on ftp.eunet.ch) to the best of my knowledge... > /net/u2/netbsd/packages amiga0# gzip -d X11R5-contrib.tar.gz > gzip: X11R5-contrib.tar.gz: unexpected end of file "In case" ;-) you want the complete one, please get it AFTER 07:00 pm and BEFORE 09:00 am GMT time. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: phb@colombo.telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 15:59:37 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: NetBsd on CDROM?" (Dec 1, 10:42am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Ralph Schmidt , dvb@ssd.kodak.com (Dave Blaszyk) Subject: Re: NetBsd on CDROM? Cc: tsarna@endicor.com, NetBSD-Amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 1, 10:42am, Ralph Schmidt wrote: [...] > You mean Multiple-Volumes on the CDRom. ISO9660 supports something like that > but by now i haven't seen any CD that has multiple-volumes and don't know > any Amiga ISO9660 filesystem that supports that. > Anyway...what's the problem to mix NetBSD with AmigaOS on one volume ? > I can't see one. Thats what i mean... Just one CD and readable from both OS, AmigaDOS and NetBSD. That way we can provide the ADOs programms needed to boot NetBSD on the CD itself. Even better, you could devellop special kernel versions (i.e. for 040) under ADos with the same sources, mo loss but share. > > What I am in favor of is a CD, with only NetBSD. This CD > > will allow me to boot and/or install NetBSD directly > > from /dev/cdrom or to my hard disk of choice. > > > Would be nice..indeed. Not really /dev/cdrom though, but / if you boot from CD-ROM. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 16:12:25 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: X11R5-contrib.tar.gz Sender: NetBSD-Admin@cbmuucp.commodore.com > > It's a bad file (the one on ftp.eunet.ch) to the best of my knowledge... > > /net/u2/netbsd/packages amiga0# gzip -d X11R5-contrib.tar.gz > > gzip: X11R5-contrib.tar.gz: unexpected end of file > > "In case" ;-) you want the complete one, please get it AFTER 07:00 pm and > BEFORE 09:00 am GMT time. > Sorry about that I believe my ftp session was terminated before I had the entire file, but I didn't get an error message. Should have checked the file sizes! I would like to give it another shot, if nobody objects. Also, when un-taring X11R5-bin.tar I was running low on disk space so I : gunzip -c X11R5-bin.tar.gz | tar -tvf - I got an error message after unpacking about 47MB worth of files, I am not sure if I was able to unpack all the files. How many files should be under the X11R5/bin directory? -Rob From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 16:21:18 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: leland@wacky.acet.org, mw@eunet.ch Subject: Re: X11R5 now under NetBSD-Amiga/incoming Cc: NetBSD-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > gurus:-)). I moved the files over to contrib/bsd/X11, together with > the R4 betas (are they still needed?). > I am not sure I can run X11R5 with just 4Megs of fast memory. I am strapped for money right now having bought a A3000, Tape drive, extra HardDisks just for NetBSD, in the last 2 months. I just can't spring for more memory right now. Perhaps there are other people in the same position. -Rob From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 18:05:07 1993 From: maze@diku.dk Subject: Kronos controller from C Ltd. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 557 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, Has anybody done a driver for C Ltd's Kronos SCSI-controller? I'm the lucky owner of such an arcane piece of hardware, but I don't have experience writing drivers for Unix. I've written a tape driver for the thing under AmigaDOS, though, so I know a little about SCSI. If anybody else on the list has such a controller, I'm very interested; driver or not. Maybe we can work something out. -- Mads Haahr (maze@diku.dk), | The right to arm bears Department of Computer Science, | is the right to be free. University of Copenhagen | From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 23:27:43 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: netbsd-amiga@cbmuucp.commodore.com Subject: New Correct X11R5-contrib.tar.gz Sender: NetBSD-Admin@cbmuucp.commodore.com I have just uploaded the complete/valid and tested -rw-rw-r-- 1 ftp 4161691 Dec 1 22:14 X11R5-contrib.tar.gz (Same name) to NetBSD-Amiga/incoming. So the X11R5-contrib.tar.gz under contrib/bsd/X11 -rw-rw-r-- 1 ftp 253952 Nov 30 15:11 X11R5-contrib.tar.gz should be deleted! -Rob From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 1 23:57:19 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: New Correct X11R5-contrib.tar.gz To: leland@wacky.acet.org (Robert Leland - PSI) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 521 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have just uploaded the complete/valid and tested > -rw-rw-r-- 1 ftp 4161691 Dec 1 22:14 X11R5-contrib.tar.gz (Same name) > to NetBSD-Amiga/incoming. > > So the X11R5-contrib.tar.gz under contrib/bsd/X11 > -rw-rw-r-- 1 ftp 253952 Nov 30 15:11 X11R5-contrib.tar.gz > should be deleted! Done, moved it over to contrib. Thanks again! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 02:07:17 1993 From: ahh@netcom.com (Andy Heffernan) Subject: GDB uploaded to ftp.eunet.ch To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga Mailing List) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I just uploaded GDB 4.9 and some associated junk to software/os/bsd/NetBSD/NetBSD-Amiga/incoming on ftp.eunet.ch. Anything you might find on wuarchive.wustl.edu is junk. Here is the README file: ------------------------------------------------------------------------ Here is a set of files to get GDB working on the #713 NetBSD-Amiga kernel. Unfortunately, the kernel requires some patching again. One of the patched files is arch/amiga/include/reg.h, so make sure to copy it to /usr/include/machine when done. There are 4 files to look at: gdb-4.9-README this file gdb-4.9.gz gdb 4.9 binary gdb-4.9-amigabsd-diffs.gz diffs to gdb 4.9 source distribution sys713-debug-diffs.gz diffs to kernel to get debugging working There can be problems doing backtraces (e.g., using the 'where' command) in that the stack-frame tracing code sometimes sees bogus frame pointers past start() and prints them out. It looks ugly, but nothing bad really happens. If you have problems with this, please send mail to me, Andy Heffernan, at ahh@netcom.com. ------------------------------------------------------------------------ To Markus and other kernel people, the kernel diffs are as follows. o The change to kern/sys_process.c was to fix an uninitialized-variable problem so ptrace() would work. o The change to arch/amiga/include/reg.h is to make sure the array size NIPCREG is large enough to contain the register indices (notably PC) used in arch/amiga/amiga/machdep.c. *** kern/sys_process.c-orig Sun Sep 5 19:06:20 1993 --- kern/sys_process.c Tue Nov 30 21:16:28 1993 *************** *** 108,113 **** --- 108,114 ---- vm_map_lookup_done(tmap, out_entry); /* Find space in kernel_map for the page we're interested in */ + kva = 0; rv = vm_map_find(kernel_map, object, off, &kva, PAGE_SIZE, TRUE); if (!rv) { *************** *** 199,204 **** --- 200,206 ---- rv = vm_fault(map, pageno, VM_PROT_WRITE, FALSE); /* Find space in kernel_map for the page we're interested in */ + kva = 0; rv = vm_map_find(kernel_map, object, off, &kva, PAGE_SIZE, TRUE); if (!rv) { *** arch/amiga/include/reg.h-orig Sun Oct 24 09:48:19 1993 --- arch/amiga/include/reg.h Wed Nov 24 20:06:16 1993 *************** *** 66,75 **** #define PC (17) #define PS (16) ! #define NIPCREG 17 #ifdef IPCREG int ipcreg[NIPCREG] = ! {D0,D1,D2,D3,D4,D5,D6,D7,A0,A1,A2,A3,A4,A5,A6,A7,PC}; #endif #ifdef KERNEL --- 66,75 ---- #define PC (17) #define PS (16) ! #define NIPCREG 18 #ifdef IPCREG int ipcreg[NIPCREG] = ! {D0,D1,D2,D3,D4,D5,D6,D7,A0,A1,A2,A3,A4,A5,A6,A7,PS,PC}; #endif #ifdef KERNEL -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 08:28:59 1993 From: oster@skorpio.usask.ca Subject: Emacs 19.22 w/ X11 support (binaries) To: netbsd-amiga@cbmuucp.commodore.com X-Envelope-To: netbsd-amiga@cbmuucp.commodore.com Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com The main binaries for GNU Emacs 19.22 (with X11R5 support) can be found on ftp.eunet.ch in /software/os/bsd/NetBSD/NetBSD-Amiga/incoming as emacs-19.22.netbsd.tar.gz Get the readme first - emacs-19.22.netbsd.readme I'm only including the executables as I think (hope) the old .el and .elc files (and everything else) will work just fine (I briefly tested this, and things seemed to work - if this doesn't seem to work for you let me know, and I'll upload the rest of the stuff as well. The new lisp/, etc/, info/ and support files require about 15 meg (roughly 4 meg compressed) so I figured I'd wait to see if they were really needed before uploading them too...) Enjoy... Later... Greg Oster oster@cs.usask.ca From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 09:59:11 1993 From: Calvin Chu Subject: sun-lamp.cs.berkeley.edu To: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com I hear there has been massive changes in the sun-lamp NetBSD tree... should I be getting it or is it a waste of time? o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 10:42:18 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Help: DMAINTR should no longer be entered!! Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com I'm trying to get NetBSD #714 running on an A3000T (2M chip, 4M fast, don't know if it's a PROTO scsi or not -- I had it open today but forgot to check :-<). I keep getting reams of "DMAINTR should no longer be entered!!" error messages, though everything seems to work anyway. I tried this with and without sync inhibited for unit 6, where the drive (Maxtor 120 meg) is. Any ideas? With here's what I get with _scsi_debug set: issue_select 6 wait_for_select: 11 8e [1a] ixfer_start 10, 2, 50000 ixfer_out {10} 28 00 00 00 f6 aa ixfer_out_done >CSR:19 - using 714 kernel and new /sbin & co. binaries I can't > mount /tmp to memory file system (mfs). supplied > /sbin/mount_mfs is set to read_only and if I set it to > executable mount isn't succesfll then either :-/ get new newfs and disklabel binaries from bin-newest, 713 enlarged the size of the disklabel, accomodating for amigados partitions. > new system -> login to my account cause a trap( ... ) > (why?? and shouldn't that be a core dump instead?). The trap message is still a debugging relict. As soon as we get a debugger parsing core dumps reliably, I can turn this off... > - new console code seems to be much faster than old. But is sure slower than the 644 one... > - how about gdb? Last time I left NetBSD development > because lack of debugger, so what is the situation now? Just saw that Andy uploaded diffs, I'll try them out ... > - where are the loadbsd sources? I could try (again) > some bootblock code generation. > (The code has been almost ready for ages, but debugging > is pain without gdb). sys/arch/amiga/stand/loadbsd. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 13:20:38 1993 From: Alain Chofardet Subject: Re: NetBSD and A500/040 ok? To: osymh@gemini.oscs.montana.edu (Michael Hitch) (Michael Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com (ML NetBSD) Mailer: Elm [revision: 72.14] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi. > >No, GVP Series II doesn't run on an A4000. > > Hmm - I've got one person who is running NetBSD on his A4000 and I though he > was using a GVP Series II card. > Yes, it's right. But it doesn't work fine. There is some problems while transfering big files. A friend of mine has bought a GVP card for his 4000, but sold it immediatly. He's now waiting for the A4091. > >|> Tha A4091 should be able to use the 53C710 driver I did for the PPI Zeus > > Very interesting. Thanks. Alain Chofardet. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 16:53:47 1993 From: David Crooke Sender: dcc@dcs.ed.ac.uk To: netbsd-amiga@cbmuucp.commodore.com Subject: 713/714 kernel & misc problems, Installation niceties Sender: NetBSD-Admin@cbmuucp.commodore.com Kiddie questions, for someone less busy than Markus Wild... From: Markus Wild Date: Thu, 2 Dec 1993 10:37:58 +0100 (MET) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1263 Sender: NetBSD-Admin@cbmuucp.commodore.com > - using 714 kernel and new /sbin & co. binaries I can't > mount /tmp to memory file system (mfs). supplied > /sbin/mount_mfs is set to read_only and if I set it to > executable mount isn't succesfll then either :-/ get new newfs and disklabel binaries from bin-newest, 713 enlarged the size of the disklabel, accomodating for amigados partitions. I don't quite follow this - under 644 I don't do anything to format the swap partition (no newfs), it just comes up on its own and mounts - or does mount_mfs do something clever with it? Does this mean people who have built the system under 644 should get the new newfs and reinstall /usr ? "Oh no, not again!", thought the bowl of petunias. Also, with this kernel, the console doesn't quite scroll right (I'm using the default reduced-size HiRes-Interlace mode; I'll change when I work out how) and leaves a line of blue (colour 3 ?) at the top of the screen. When I reboot I get the text area of the console screen going crazy with what looks like 32 pixel wide horizontal striping interspersed with other psychadelic behaviour, and I have to give it the Vulcan nerve pinch (Ctrl-A-A). A final problem I have is with sendmail - the /etc/rc hangs at this point going into multi-user mode, so I commented it out. Is this normal? On a more positive note I managed to resize the root partition; It seems to me that around 10Mb is more sensible, to acoomodate the new /bin and /sbin. I take it someone has uploaded an up to date version? On the subject of updating installation, is someone still owrking on an up to date installation note and FAQ? The one on ftp.eunet.ch still seems to refer to usrbin.tgz etc. and also is a bit out of date in other respects (i.e. recommending 50Mb for /usr). If not, could I modestly offer my services to write a ne one; having just got NetBSD running myself, it is fresh in my mind. Any advice/comments very welcome Dave P.S. My setup: A3000/25, 2 Chip, 8 Fast PPI Mercury 68040/28, No ram Maxtor 7345SR 50 DH0, 24 swap, 10 rootfs, 100 /usr, 30 /home 35 BSD scratch /dev/sd6g, 65 AmigaDOS scratch Quantum 52S 25 DH1, 25 DH2 (BSD bootstrap and backups :-) David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 1408, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 5164 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 17:17:32 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: 713/714 kernel & misc problems, Installation niceties Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 2, 3:39pm, David Crooke wrote: > > Kiddie questions, for someone less busy than Markus Wild... ... > I don't quite follow this - under 644 I don't do anything to format > the swap partition (no newfs), it just comes up on its own and mounts > - or does mount_mfs do something clever with it? I think mount_mfs uses newfs to create the /tmp filesystem. I had to update the newfs before I could mount /tmp. Since I was switching back and forth for a little while, I had to keep switching newfs :-(. > Does this mean people who have built the system under 644 should get > the new newfs and reinstall /usr ? "Oh no, not again!", thought the > bowl of petunias. No, you just need to put the new binaries (newfs and disklabel) on /usr/sbin. [I think the disklabel size change is only internal to the kernel, not the actual disk.] > Also, with this kernel, the console doesn't quite scroll right (I'm > using the default reduced-size HiRes-Interlace mode; I'll change when > I work out how) and leaves a line of blue (colour 3 ?) at the top of > the screen. When I reboot I get the text area of the console screen I had a report about the blue line on an A4000, and just recently noticed it on my system when I was running screen. I had wondered if it was something on my '040 kernel, but it looks like it's not CPU specific. > going crazy with what looks like 32 pixel wide horizontal striping > interspersed with other psychadelic behaviour, and I have to give it > the Vulcan nerve pinch (Ctrl-A-A). There's a big bug in the reboot code (due to a bug in gas) so that the reboot code doesn't get copied to chip memory. When the MMU is turned off, the code disappears and the pc is pointing to random garbage. The older kernels allocated chip memory from the high end, so the reboot code in the chipmem copy of the kernel remained intact. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 18:07:32 1993 From: Markus Landgraf To: osymh@gemini.oscs.montana.edu Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: 713/714 kernel & misc problems, Installation niceties Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 2, 3:39pm, David Crooke wrote: > > Kiddie questions, for someone less busy than Markus Wild... ... > I don't quite follow this - under 644 I don't do anything to format > the swap partition (no newfs), it just comes up on its own and mounts > - or does mount_mfs do something clever with it? I think mount_mfs uses newfs to create the /tmp filesystem. I had to update the newfs before I could mount /tmp. Since I was switching back and forth for a little while, I had to keep switching newfs :-(. mount_mfs _is_ newfs, you can do a symbolic link. The program just behaves in different ways depending on how it was started. mount_mfs formats the memory file system, mounts it to the given mount point and deletes all stuff, when it is unmounted. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 20:55:21 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: kiddie questions (ha ha :-) Sender: NetBSD-Admin@cbmuucp.commodore.com | |Kiddie questions, for someone less busy than Markus Wild... | | From: Markus Wild | Date: Thu, 2 Dec 1993 10:37:58 +0100 (MET) | X-Mailer: ELM [version 2.4 PL20] | Content-Type: text | Content-Length: 1263 | Sender: NetBSD-Admin@cbmuucp.commodore.com | | > - using 714 kernel and new /sbin & co. binaries I can't | > mount /tmp to memory file system (mfs). supplied | > /sbin/mount_mfs is set to read_only and if I set it to | > executable mount isn't succesfll then either :-/ | | get new newfs and disklabel binaries from bin-newest, 713 enlarged | the size of the disklabel, accomodating for amigados partitions. | |I don't quite follow this - under 644 I don't do anything to format |the swap partition (no newfs), it just comes up on its own and mounts |- or does mount_mfs do something clever with it? I think they may have fixed disklabel (something that did not work with the 644 kernel). Now that it works, probably mount_mfs is trying to use it and.... |Does this mean people who have built the system under 644 should get |the new newfs and reinstall /usr ? "Oh no, not again!", thought the |bowl of petunias. I think the problem only occurs for the mfs filesystem. I don't follow why this is, but I did not have to reinstall anything more than newfs and disklabel to get /tmp to mount correctly. Anyone shed some light here? |Also, with this kernel, the console doesn't quite scroll right (I'm |using the default reduced-size HiRes-Interlace mode; I'll change when |I work out how) and leaves a line of blue (colour 3 ?) at the top of |the screen. When I reboot I get the text area of the console screen |going crazy with what looks like 32 pixel wide horizontal striping |interspersed with other psychadelic behaviour, and I have to give it |the Vulcan nerve pinch (Ctrl-A-A). Sorry, I am still at v713. |A final problem I have is with sendmail - the /etc/rc hangs at this |point going into multi-user mode, so I commented it out. Is this |normal? Yes, I had the same problem. I commented this and all the other net daemons out. After all, I have no ethernet to connect to. The sendmail thing might be a sendmail.cf problem. I didn't look because I have no one to send mail to either :-( |On a more positive note I managed to resize the root partition; It |seems to me that around 10Mb is more sensible, to acoomodate the new |/bin and /sbin. I take it someone has uploaded an up to date version? | |On the subject of updating installation, is someone still owrking on |an up to date installation note and FAQ? The one on ftp.eunet.ch still |seems to refer to usrbin.tgz etc. and also is a bit out of date in |other respects (i.e. recommending 50Mb for /usr). If not, could I |modestly offer my services to write a ne one; having just got NetBSD |running myself, it is fresh in my mind. I think this would be a very good idea. All of those docs are in need of a re-write/update. You get my vote of encouragement to work on 'em. I just don't have much time right now. You see, I am a new dad again and 2 kids is more than 2x the fun :-) Cheers! Rob Tulloh +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 22:38:00 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: 713/714 kernel & misc problems, Installation niceties To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1670 Sender: NetBSD-Admin@cbmuucp.commodore.com > I think mount_mfs uses newfs to create the /tmp filesystem. I had to > update the newfs before I could mount /tmp. Since I was switching back and > forth for a little while, I had to keep switching newfs :-(. Just - in all the "swap" reasoning - don't forget that the swap partition is not "mounted" at startup. Although swap appears in fstab, it is only used as TEMPLATE device for mfs (which is a vram disk). That's why you need new newfs to mount new tmp, not because of swap. > No, you just need to put the new binaries (newfs and disklabel) on > /usr/sbin. [I think the disklabel size change is only internal to the > kernel, not the actual disk.] That's why I jumped in.. *DON'T* put them into /usr/sbin, they belong into /sbin. I discovered by coincidence that there are several programs appearing in /usr/sbin, that are also in /sbin. Check this: cd /sbin for i in *; do if [ -x /usr/sbin/$i ]; echo $i; fi done and if you're happy with the result, replace the echo $i with rm /usr/sbin/$i ... > > I work out how) and leaves a line of blue (colour 3 ?) at the top of > > the screen. When I reboot I get the text area of the console screen > > I had a report about the blue line on an A4000, and just recently noticed > it on my system when I was running screen. I had wondered if it was something > on my '040 kernel, but it looks like it's not CPU specific. I have some blue line when going into X-mode. Perhaps the second plane isn't properly cleared in the start? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 22:54:18 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: kiddie questions (ha ha :-) To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1799 Sender: NetBSD-Admin@cbmuucp.commodore.com > I think they may have fixed disklabel (something that did not work > with the 644 kernel). Now that it works, probably mount_mfs is trying > to use it and.... No, but mfs is the only fs so far that uses a REAL disklabel.. the scsi-based filesystems all use virtual disklabels, that I compose out of the information from the RDBs. > I think the problem only occurs for the mfs filesystem. I don't follow > why this is, but I did not have to reinstall anything more than > newfs and disklabel to get /tmp to mount correctly. Anyone shed some > light here? Clear now? > |A final problem I have is with sendmail - the /etc/rc hangs at this > |point going into multi-user mode, so I commented it out. Is this > |normal? > > Yes, I had the same problem. I commented this and all the other net > daemons out. After all, I have no ethernet to connect to. The sendmail > thing might be a sendmail.cf problem. I didn't look because I have > no one to send mail to either :-( The only daemon (or rather, demon, in in this case?:-)) you have to comment out is named. Or, as an alternative, what I do here, add two lines to the named.boot file: forwarders aaa.bbb.ccc.ddd slave (replace the aaa... thing with the address of a host you're connecting to with slip/ppp, or use a phantasy-number if you don't do any network connections). This way, the named needs only one attempt at finding out that there is no network, the normal way, it would try to connect to all listed root servers before timing out, thus leading to the "locked up" system. Anyway, the easiest way to get rid of the problem is to comment the starting of named out. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 2 23:10:17 1993 From: Markus Landgraf To: mw@eunet.ch Cc: rtulloh@oneway.austin.ibm.com, netbsd-amiga@cbmuucp.commodore.com Subject: just asking Sender: NetBSD-Admin@cbmuucp.commodore.com I don't wanna be any kind of annoying, but how are the shlibs ? I was posting some days ago that I am interested in a port of X for domino/merlin grafik adapters and I was advised to wait until shibs are ready ( and I think this is wise myself). ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 00:18:01 1993 From: Howard Dobson Subject: Re: Re X and 713/714 To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 343 Sender: NetBSD-Admin@cbmuucp.commodore.com > The trouble come from the grf_cc.c. The xserver use the ioctl to map the > graphic memory. In the kernel <709 the ioctl map the graphic memory. > in Newer version the ioctl map the register.... > > The trouble is fixed in X11R5 > With X11r4 you may patch the driver (regsize=0) I still get MMU panic with X11R5 and vmunix.714. Any ideas? From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 04:27:10 1993 To: "NetBSD-Amiga" From: "Matthias Scheler" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: IntuiNews 3.141592654 (Right Now) Subject: Re: NetBsd on CDROM? Organization: Amiga User Group University Paderborn Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Markus, > Not really /dev/cdrom though, but / if you boot from CD-ROM. Booting from CD-ROM ? How ? No /tmp ! I know that you can boot from SunOS-CDs, but I don't think you get a real UNIX enviroment but a special installation program. BTW: Why has this mailing list no Reply-To ? -- Matthias Scheler FidoNet : Matthias Scheler@2:243/6310.10 Internet: tron@lyssa.pb.owl.de From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 07:59:52 1993 To: Amiga NetBSD List Subject: Quick question From: ggk@tirith.uucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com Okay, my status vs. NetBSD. I've run the 709 kernel to the point where it asks me to log in. It's quite happy with this, so far. I even finally managed to get vi working. However, the hard disk it's on is impossibly cramped for space, and it's flaking out and losing data on me. Little trivial detail, but could the root password get included in the install notes so that when you forget to change it you can do something other than the three finger salute? So, it may be time to buy a new disk. Are there any particular drives which are better or worse under NetBSD than others? I have an A3000 with the stock Quantum LP52S and a dying Rodime RO3000T. One particularly nice drive that I've found for a really good price specifies an interface of ``SCSI-2 (Fast)'' - will this work on my A3000 or not? The transfer rates it claims are ``Synch. 5.0 MB/s, Fast Synch. 10.0 MB/s.'' - doesn't sound like SCSI, but is it backwards compatible? My other question - has anyone looked at doing a driver for the Supra internal modems? I have a 2400zi+, which is a separate product code from the 2400zi, but I think they might be the same driver. Gregory Kritsch | 3A Computer Engineering at UWaterloo ggk@tirith.uucp | "Life is a highway ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 09:15:08 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: just asking To: landgraf@crunch.ikp.physik.th-darmstadt.de (Markus Landgraf) Cc: mw@eunet.ch, rtulloh@oneway.austin.ibm.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 525 Sender: NetBSD-Admin@cbmuucp.commodore.com > I don't wanna be any kind of annoying, but how are the shlibs ? I'm currently recompiling the whole system to use them, so far I think they work fine. Besides, I was very happy to see they're actually a superset of SunOS shared libs, including the very nice SVR4 feature of lazy binding, and without the need for those dreadful *.sa files. I like them :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 10:11:22 1993 To: ggk%tirith@xenitec.on.ca Cc: Amiga NetBSD List , mehlhaff@flood.berkeley.edu Subject: Re: Quick question of Thu, 02 Dec 1993 22:49:13 -0500 <9312022249.AA00398@tirith.ocunix.on.ca> From: 'Evil' ERic Mehlhaff Sender: NetBSD-Admin@cbmuucp.commodore.com >One particularly nice drive that I've found for a really good price >specifies an interface of ``SCSI-2 (Fast)'' - will this work on my A3000 >or not? The transfer rates it claims are ``Synch. 5.0 MB/s, Fast Synch. >10.0 MB/s.'' - doesn't sound like SCSI, but is it backwards compatible? I don't know what kind of transfer rates you can expect from it, but the SCSI-2 disks _will_ work on amigas (at least they do on my stock A3000). SCSI-2 is supposedly fully backwardly compatible. ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 10:14:12 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Quick question To: ggk%tirith@xenitec.on.ca Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1953 Sender: NetBSD-Admin@cbmuucp.commodore.com > me. Little trivial detail, but could the root password get included in > the install notes so that when you forget to change it you can do > something other than the three finger salute? I'd suggest not installing a passwd at all in future rootfs templates. The current rootfs is ways outdated anyway, so I'd be very grateful if somebody would care to set up a new rootfs after I upload the new binary dist (with shared libs). This will probably not happen before next Thursday, as I have to do the compilation over the weekend, and won't have tape access to the internet before Thursday again. > So, it may be time to buy a new disk. Are there any particular drives > which are better or worse under NetBSD than others? I have an A3000 > with the stock Quantum LP52S and a dying Rodime RO3000T. If you disable sync, just about any drives should probably work fine. I've had some problems with Quantums recently when running sync. > One particularly nice drive that I've found for a really good price > specifies an interface of ``SCSI-2 (Fast)'' - will this work on my A3000 > or not? The transfer rates it claims are ``Synch. 5.0 MB/s, Fast Synch. > 10.0 MB/s.'' - doesn't sound like SCSI, but is it backwards compatible? May, may not work.. I'm currently using a DEC DSP3105 with NetBSD, a 3.5" 1G drive with same specs as you listed, it works very well. Of course you can't do Fast-SCSI2 with the 3000 controller chip (it's too old, and it's clocked too slow for the new revision of the chip to be able to run Fast-Sync). On the other hand, I've had an IBM 0663-E13 drive for some time, same specs, and I had nothing but troubles with that drive, although, in times where it worked, it worked nice and fast. I wouldn't exactly recommend it though for use on the A3000... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 10:17:42 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: NetBsd on CDROM? To: tron@lyssa.pb.owl.de (Matthias Scheler) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 829 Sender: NetBSD-Admin@cbmuucp.commodore.com > Booting from CD-ROM ? How ? No /tmp ! We (can and usually do) have an "mfs" tmp filesystem, a ramdisk built from virtual memory. You can do that with a read-only rootfs. > I know that you can boot from SunOS-CDs, but I don't think you get a real > UNIX enviroment but a special installation program. We'd sure need some (small) writable filesystem, and if it's just for the user to be able to store some stuff, to receive mail, etc. > BTW: Why has this mailing list no Reply-To ? I sort of prefer such lists, with those that have Reply-To it's quite a bit of pain to generate private replies. Just always answer with "g" instead of "r" and you're fine:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 12:01:11 1993 From: chammer@HRZ.Uni-Bielefeld.DE Subject: Re: Quick question To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com > One particularly nice drive that I've found for a really good price > specifies an interface of ``SCSI-2 (Fast)'' - will this work on my A3000 > or not? The transfer rates it claims are ``Synch. 5.0 MB/s, Fast Synch. > 10.0 MB/s.'' - doesn't sound like SCSI, but is it backwards compatible? Unfortunatly i get with the WD33C93B, the SCSI2 (SCSI-fast) version of the SCSI-chip more SCSI-hangs than i like it usually. This seems not to depend on the for fast-scsi necessary 20MHz input-clock i supply but only on the replacing with the b-chip. So without further looking on this problem a A3000 will not be able to deal with SCSI-FAST without a new controller. Of course just to get the drive working on a A3000 should not be a big problem... > Gregory Kritsch | 3A Computer Engineering at UWaterloo > ggk@tirith.uucp | "Life is a highway > ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL > ciao Carsten From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 14:32:59 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: grf0. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com I have this itchy feeling that there might be some new cc graphics code on the way... :^) overscan problems---minimally fixed, not happy but all resolutions work. --- a2024 mode(1024x800)---depth 2 works still trying for 1 (how odd..) this mode is too dependent on copperlist disassem from Amiga, I will probably re-write. ECS PAL works. (I hope non ECS will but I didn't change much.) Console scroll code and character put code has been optimized and will go to assembly before release (its mainly in assem now but in the C source files.) Now that my ite_std. is a ite_cc.c I can count on some more stuff and will be able to use the nice moveml to scroll the display. Many optimizations in the area of putting characters to display. (this had and still has some very slow parts. At least now the slow parts are not in ite_cc.c :^)) After this I want to look into re-writing ite.c with tables instead of HUGE switch statements as this will show a drastic improvement in parsing speed. Optimizations all around are beggining to swith from time to space, I grow weery of my kernel gaining weight with each recompile :^). Oh yah, I haven't yet done anything about the display offset stuff may or may not get this in before I release. (hey it centers on my monitor :^) Will release the iteconfig program at same time. ...Patches maybe tommorow night... (I am going to bed.) Chris. "This message has been brought to you by one sleepy programmer" From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 15:50:06 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: mw@eunet.ch Subject: Re: 713/714 kernel & misc problems, Installation niceties Cc: NetBSD-Amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > > No, you just need to put the new binaries (newfs and disklabel) on > > /usr/sbin. [I think the disklabel size change is only internal to the > > kernel, not the actual disk.] > > That's why I jumped in.. *DON'T* put them into /usr/sbin, they belong into > /sbin. I discovered by coincidence that there are several programs appearing > in /usr/sbin, that are also in /sbin. Check this: > cd /sbin > for i in *; do > if [ -x /usr/sbin/$i ]; echo $i; fi > done > and if you're happy with the result, replace the echo $i with > rm /usr/sbin/$i ... Aren't the binaries under /sbin and maybe /bin supposed to be statically linked? I believe this is in instances when you can't mount /usr for some reason you are not completely hosed with shared libraries. If the libraries are under /usr/lib then a ls built with shared libraries won't work unless you can mount /usr or there is a /lib. Also I believe there may be some securityimplications with libraries. Comments? -Rob From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 16:00:23 1993 From: olivier raoul To: netbsd-amiga@cbmuucp.commodore.com Subject: X Sender: NetBSD-Admin@cbmuucp.commodore.com I've got the 713 and X doesn't work: It seem that iteoff crash the kernel because the ioctl grfon crash and when the system reboot the screen is trashed. If i do a getconfig whith the custom-chip the grfaddr is 1 !!! I forgot to strip X binaries (compiled with -O) i can win 15 megs over the distrib. From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 18:06:35 1993 From: cactus%clinton.com@cbmvax.uucp.commodore.com (L. Todd Masco) To: Amiga NetBSD List Subject: Re: Quick question <9312022249.AA00398@tirith.ocunix.on.ca> Sender: NetBSD-Admin@cbmuucp.commodore.com 'Evil' ERic Mehlhaff writes: > > >One particularly nice drive that I've found for a really good price > >specifies an interface of ``SCSI-2 (Fast)'' - will this work on my A3000 > >or not? The transfer rates it claims are ``Synch. 5.0 MB/s, Fast Synch. > >10.0 MB/s.'' - doesn't sound like SCSI, but is it backwards compatible? > > I don't know what kind of transfer rates you can expect from it, but the > SCSI-2 disks _will_ work on amigas (at least they do on my stock A3000). SCSI-2 > is supposedly fully backwardly compatible. Speaking purely subjectively, it seems that my A3000 has sped up by about a factor of 5 since I replaced the Quantum 105LPS with the new Micropolis 1.3 GB SCSI 2 drive. Of course, I also replaced the Super Buster the same night; I don't know whether this would make a difference. -- Todd From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 18:10:09 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: NetBsd on CDROM?" (Dec 2, 8:15pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "NetBSD-Amiga" Subject: Re: NetBsd on CDROM? Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 2, 8:15pm, "Matthias Scheler" wrote: > Subject: Re: NetBsd on CDROM? > > Hi Markus, > > > Not really /dev/cdrom though, but / if you boot from CD-ROM. > > Booting from CD-ROM ? How ? No /tmp ! Not really necessary, but can be achieved with a mfs 'partition', thus, if you enoght memory, could even start X11. Thats what the Yggdrasil Linux CD does, too. > I know that you can boot from SunOS-CDs, but I don't think you get a real > UNIX enviroment but a special installation program. You do get a full flavored Unix environment. /tmp and swap (!) in memory. > BTW: Why has this mailing list no Reply-To ? Because :) Group-Reply works as a champ for me. We are not depending on UMS, and then there is no fixed default given for 'Reply-To'. The used header here gives you all information you need. A simple reply will be send to the original sender (From:) a group-reply will be send to the list (using Sender: )and the sender (From: ). This saves bandwith. I have talked with Martin, and he did acknowledeg that there is no statement which does describe in any manner how a mailling list has to act. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 18:23:46 1993 To: Robert Leland - PSI Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: 713/714 kernel & misc problems, Installation niceties From: ggk@tirith.uucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >Aren't the binaries under /sbin and maybe /bin supposed to be statically I remember there's a section in the SunOS manuals about such considerations. Static linked /bin and /sbin sounds like a good idea. Then it would make sense to have dynamic linked copies in /usr/bin and /usr/sbin. As I recall, for security reasons, all shared libraries had to come from /usr/lib OR a specific location compiled into the program. There might also have been a root-owned condition (ensure that someone with root access already installed the shlib) and a read-only condition (root owned but publicly writable could allow any to modify the lib). >Comments? >-Rob Gregory Kritsch | 3A Computer Engineering at UWaterloo ggk@tirith.uucp | "Life is a highway ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 18:52:03 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X To: raoul_o@epita.fr (olivier raoul) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 245 Sender: NetBSD-Admin@cbmuucp.commodore.com > I've got the 713 and X doesn't work: That was exactly the reason for 714... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 19:30:09 1993 From: Howard Dobson To: ggk%tirith@xenitec.on.ca Subject: Re: 713/714 kernel & misc problems, Installation niceties Cc: NetBSD-Amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > As I recall, for security reasons, all shared libraries had to come from > /usr/lib OR a specific location compiled into the program. The limitation on the location of shared libraries is only when the binary is set user or set group ID. From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 20:01:22 1993 From: savage@dg-rtp.dg.com (Ed Savage) Subject: Re: shared libs... To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > >Aren't the binaries under /sbin and maybe /bin supposed to be statically > > I remember there's a section in the SunOS manuals about such > considerations. > > Static linked /bin and /sbin sounds like a good idea. Then it would > make sense to have dynamic linked copies in /usr/bin and /usr/sbin. Yes, that's the way to do it... Static link everything that goes in /bin & /sbin. That's what we do for DG/UX. > As I recall, for security reasons, all shared libraries had to come from > /usr/lib OR a specific location compiled into the program. There might > also have been a root-owned condition (ensure that someone with root > access already installed the shlib) and a read-only condition (root > owned but publicly writable could allow any to modify the lib). As for dir & file permissions, we have: drwxr-xr-x 38 bin bin 3584 Nov 18 11:06 /usr/lib/ -rw-r--r-- 1 bin bin 627802 Nov 8 17:58 /usr/lib/libc.so -rwxr-xr-x 1 bin bin 424296 Nov 8 17:59 /usr/dglib/libc.so.1* But the dglib reference above will probably be the same dir as the libc.so. Nothing much special about permissions though - just close it up except for bin... --Ed > >Comments? > >-Rob > > Gregory Kritsch | 3A Computer Engineering at UWaterloo > ggk@tirith.uucp | "Life is a highway > ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL > -- Edward Savage DG/UX Development Data General Corporation savage@dg-rtp.dg.com 62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!savage Research Triangle Park, NC 27709 (919) 248-6207 From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 3 22:52:13 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: shared libs... To: savage@dg-rtp.dg.com (Ed Savage) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1476 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Static linked /bin and /sbin sounds like a good idea. Then it would > > make sense to have dynamic linked copies in /usr/bin and /usr/sbin. > > Yes, that's the way to do it... Static link everything that goes in /bin & > /sbin. That's what we do for DG/UX. And it's the way it's done with NetBSD, too:-) > > As I recall, for security reasons, all shared libraries had to come from > > /usr/lib OR a specific location compiled into the program. There might > > also have been a root-owned condition (ensure that someone with root > > access already installed the shlib) and a read-only condition (root > > owned but publicly writable could allow any to modify the lib). NetBSD ld.so has these security features. As soon as suid!=ruid or sgid!=rgid: - ignores LD_LIBRARY_PATH environment variable, and further removes this variable. - only searches directories preinstalled by an "ldconfig" call during boot. > As for dir & file permissions, we have: > > drwxr-xr-x 38 bin bin 3584 Nov 18 11:06 /usr/lib/ > -rw-r--r-- 1 bin bin 627802 Nov 8 17:58 /usr/lib/libc.so > -rwxr-xr-x 1 bin bin 424296 Nov 8 17:59 /usr/dglib/libc.so.1* These are not at all relevant.. (of course you'll not want to allow anyone to write there, but shouldn't that be obvious?). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 01:07:46 1993 From: Alan Bair Subject: Latest versions to use??? To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi guys/gals, I went away for Thanksgiving and have been busy at work for the last week. Now I find there are about 100 NetBSD messages to go through and it looks like a lot of changes have taken place. I want to get back into things this weekend, but need to download the latest stuff. From a quick review of the messages, is the following what I should go for: Kernel and sources for 714? X11R5 uploads Anything in new-binaries not covered by 714? Here are some things I plan to work on: 1. Updates to fontdumper.c, I saw some note from Chris Hopps. 2. Try to generate a 10MB rootfs with the latest stuff and most of the networking, sendmail, etc. turned off so beginners can run out of the box (maybe). Gurus can turn on what they want. 3. Write some updates on this new rootfs for the FAQ. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 01:22:24 1993 From: tero.manninen@oulu.fi (Tero Manninen) Subject: 713 compiled kernel console messed To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1201 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello again, I've already once announced my problems compiling a functional kernel from 713 sources for my A3000. The modifications for sources have been only two: 1) a patch that affected locore.s (from this list) 2) a patch for gdb The console was messed before these patches and still are. I have tried to compile with different configurations (config AMIGA) and currently there are only two differences to the distributed setup: ident GODZILLA changed to ident FRUCTUS timezone -1 dst changed to timezone -2 dst Compilation was done under 570 and now in the distributed 714 kernel, same efects, console is messed. The screen color is yellow, characters are like something in HAM mode, very smeared. Funny thing is that kernel appears to work besides the messed console, and with some imagination you can almost read what you typed to console.. Compiler is gcc v2.4.3 and I have tried to compile with default options (-O -mc68020 -m68881) and without -O, same effects (btw, some isofs modules had to be compiled with -O so that used "inline function" macros were compiled correctly). What the heck is going on here? Till 570, I had succesfully compiled every kernel release.. ++Tero From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 01:31:27 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Latest versions to use???" (Dec 3, 5:33pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Alan Bair , netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) Subject: Re: Latest versions to use??? Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 3, 5:33pm, Alan Bair wrote: > 1. Updates to fontdumper.c, I saw some note from Chris Hopps. > 2. Try to generate a 10MB rootfs with the latest stuff and most of the > networking, sendmail, etc. turned off so beginners can run out > of the box (maybe). Gurus can turn on what they want. > 3. Write some updates on this new rootfs for the FAQ. Consider making two versions of the rootfs, one with networking support, the other without. Thus the non-networking version shoul dbe smaller. Aehem, and wait for the sahred libs :) -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 01:37:46 1993 From: Arthur Hoffmann Subject: Re: X To: mw@eunet.ch (Markus Wild) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 487 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I've got the 713 and X doesn't work: > > That was exactly the reason for 714... > > -Markus > -- > CHUUG/EUnet Switzerland Markus Wild > Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch > CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH > Well, 714 doesn't work either, It came up with a MMU fault for X11R4 and needed a 3 finger salute, and now exactly the same thing is happening for X11R5. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 02:03:04 1993 From: Alan Bair Subject: New rootfs setup?? To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Dec 3, 5:33pm, Alan Bair wrote: > > 3. Write some updates on this new rootfs for the FAQ. > > Consider making two versions of the rootfs, one with networking support, > the other without. Thus the non-networking version shoul dbe smaller. There had been some discussion on this in the past, mainly about various ways to handle the networking setup. I was just planning on commenting out or setting flags to turn off the network related items in the rc.xx and startnet(?) files. So the root would not be any smaller. I don't think it would make much sense to leave out the few programs related to networking. Maybe a list of what can safely be deleted would be better. Then it is up to the user to remove them if they never plan on using them. > Aehem, and wait for the sahred libs :) Good point. How soon till this is ready? I imagine several people could still use a new rootfs, especially the new comers now that X Windows is available. It was not too fun to load the binary updates, find / was over 100% and then have to start over again :( So I may go ahead and release an early version for practice :) > > -- > Markus Illenseer > PS: Totally off the NetBSD topic. Have you or any others over in Europe heard of a company called SQL that sells the Software Configuration System, PCMS? -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 04:52:13 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: X Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 4, 10:03am, Arthur Hoffmann wrote: > > > I've got the 713 and X doesn't work: > > > > That was exactly the reason for 714... > > > > -Markus > > Well, 714 doesn't work either, It came up with a MMU fault for X11R4 > and needed a 3 finger salute, and now exactly the same thing is > happening for X11R5. I think the problem is that the server is attempting to write to the console. The new console stuff for the custom chip display will attempt to output to the console after it has been turned off when the display is put into the graphics mode. I would suggest trying to run the X server with stdout and stderr redirected somewhere (/dev/null or /tmp/xxx) and see if that works any better. [I just had the same trouble trying to get the X11R5 server running on my system and found where the MMU fault was occurring.] In fact, I'm typing this in from an xterm window. I love it!! I just checked the output of both Xbsd and vfwm and they both have written some data to stderr. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 06:40:05 1993 From: Howard Dobson Subject: Re: X To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 637 Sender: NetBSD-Admin@cbmuucp.commodore.com > On Dec 4, 10:03am, Arthur Hoffmann wrote: > > Well, 714 doesn't work either, It came up with a MMU fault for X11R4 > and needed a 3 finger salute, and now exactly the same thing is > happening for X11R5. > Michael Hitch provides solution > > I would suggest trying to run the X server with stdout and > stderr redirected somewhere (/dev/null or /tmp/xxx) and see if that works > any better. It works great until you try to su. I would suggest that one of the first things to start up be an xterm -C or similar X based console to avoid MMU faults when you try to su or do anything else which causes messages to go to the console. From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 07:06:47 1993 From: Arthur Hoffmann Subject: gdb & trapsignals in 713. To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 428 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I just tried out gdb on kernel 713, but when I step through programmes I always keep on getting a lot of trapsignals: Dec 4 14:21:30 atze /netbsd: trapsignal(105, 5, 0, 0, 221e) I did apply the patches. The last field keeps on changing, the others stay the same. What can be done to get rid of those messages? (gdb itself seems to work just fine :-) Thanks. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 15:50:40 1993 Subject: X From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com A few observations and questions: - First, if anybody out there is still running with a 4 Meg system, splurge and get yourself another 4 Meg quick! Kernel builds are about 3 times faster. I've yet to try X since... - When I run X11R5 server under vmunix.713, I get an MMU fault. If I direct stdin and stdout to /dev/null, I get "static" on my screen. It's not fireworks - I have a 640x400 display all right, but "snow" is displayed in the viewable area. - I understand that /dev/grf has been replaced with /dev/view. What are the major and minor numbers for these? Perhaps that's my problem. - As of last night, 714 source was not up on eunet. Should I wait until shared libs are released before getting a new source release? Anxiously awaiting answers to see if X runs better in 8M. With 4M, you page every time you type a character in XTerm, as XTerm, Xbsd and bash (readline) cannot be residient at once :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 15:54:44 1993 Subject: Kernel font From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Here's an interesting kernel font to try. This is not copyright, and mw is free to include it as the default distribution font if he wishes: begin 777 dej.font.gz M'XL( *2O "T )V8:5L300R /]-?L=Z**#OMMJ565"BM]WV+@$"WM%):[2$HX MXF]W.MNQ29/,[,J'//LL>3?'))GIC'O#SD$O;@;[[=U!G%WI]7OC7:.X M.\U1.U@-2M7<6%1JQYV#]DAK55Q:W;[6"$_RH?-3':-4CEU*>[O#N-OIQ8E?X MPW9_, KL']+K=YO#HUC3JX&JYG+\)_?'@V%_L+FEE4YS"^%)J[449).YLZKPX M[8D;LR^'X40_DUQ87M1!+2X;/#(O)1F29RTU?L[B:^8EE%X?-'Z>P56#?Y[_X MK,8O<,X;1"5J=2.5>5/'06G\XA17%:-@9)@':BOF?6$FD?5+UGI]9G$JUXTTX MGU(*> +QRQ8G%E.E[HJ,0QF!H"!^U>)4#4K6*XU?LW@(EB8"2Q;)E:#Q18Q'X M AX)^'6,2S+B0M#XDHA/K;LS?R.==:EE;F)<"54G65_&5:= B19G92Q678A;X MIF:4I:ZGN&*LA\ 6ZH(&P?.VXT!C0AR^4=1ZP>(*Q*Z +44DQ".+-XBK::P7X M;>P"#OUA4E="UIEUEZ9N@I>Y=8>9=UM?D7&2.B;V"E?S-5*B]$V"W^)PVMU2X MPU:Y<0';9$7X8(+?9JS#&.?CG<-7,4X'IF-T:_R.W#)YXC9=][OA:V:=9^$>(.N>TQVU_A /*R>NZ/'@$78^.0@!Y>ES7G#^L<5IJ5!)X M%^X)MKX.FD4H'H0_Q7@%X(44^#.YXRA(,__Y22N-#KIP>USL=+L,!>O[%B<+X MQ/0=Q9N<=>@\O0J >&SQPBSSGLD#\98=V>8U_Y9R'>WT-/%/G#ZUUIT71^2Y7\TG;%HFDUH\XO&0D^.TL9K[GX MJSKW+M,7&U;JN%F2-?[M?ZM.&?R[+W;WZ6+@Z7?FP@WB0^:^3NPX>N$VXIRGX M24O #8*/4^'B_O[#AX.J8^XJCT5TO R\D%^9\)/;F#_PO^X '"J36R!@ "Z9X X end -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 22:32:00 1993 From: ahh@netcom.com (Andy Heffernan) Subject: Re: gdb & trapsignals in 713. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hi, > I just tried out gdb on kernel 713, but when I step through programmes > I always keep on getting a lot of trapsignals: > > Dec 4 14:21:30 atze /netbsd: trapsignal(105, 5, 0, 0, 221e) This is from a printf in sys/arch/amiga/amiga/trap.c. Remove the printf (or comment it out), remove trap.o from your compile directory if you're not using mkdep, and rebuild. > The last field keeps on changing, the others stay the same. What can > be done to get rid of those messages? (gdb itself seems to work just > fine :-) I think the third field is the trap code; in this case it indicates a bus error from the processor. I would expect a lot of trace traps, but I've had this commented out so long I forget. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 22:53:32 1993 From: Hartmut Kuehn Subject: supra controller ?! To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 748 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all ! What about the Supra SCSI Controller Wordsync Series 3 ?? I havent read netbsd news and mails for weeks and didnt follow if anything happens ... Hope it works now ?! :-) Bye ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@cs.tu-berlin.de * * (or kuehaaaf@w250zrz.zrz.tu-berlin.de) * * BITNET: KUEHN@DB0TUI11.BITNET * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 23:09:08 1993 From: Bill Squier To: NetBSD-Amiga@cbmuucp.commodore.com, dej@eecg.toronto.edu Subject: Re: X Sender: NetBSD-Admin@cbmuucp.commodore.com >Subject: X >From: David Jones >To: NetBSD-Amiga@cbmuucp.commodore.com > >A few observations and questions: > >- First, if anybody out there is still running with a 4 Meg system, splurge > and get yourself another 4 Meg quick! Kernel builds are about 3 times > faster. I've yet to try X since... > > [...] > >Anxiously awaiting answers to see if X runs better in 8M. With 4M, you >page every time you type a character in XTerm, as XTerm, Xbsd and bash >(readline) cannot be residient at once :-) > X runs beautifully in 8M. With only 2M free to start with in a 4M system, you're pretty much taxing the paging algorithm to its useful limits. LRU becomes somewhat of a non-sequitor when you're constantly swapping. I must say that the R5 server is a lot faster than I expected! Great work! On a sadder note, I think the x11r5-bin distribution is missing xdm and twm. Twm I couldn't care less about, but xdm would be nice. Also, xload (as far as the man page states) uses the /dev/kmem interface to the kernel, which means that /dev/kmem should be group kmem+r and xload should be sgid kmem. This setup doesn't work. As far as I recall, the suid root that xload has in the distribution doesn't work either. (can't read namelist from /vmunix) Fixes? >-- >David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto >email: dej@eecg.utoronto.ca, finger for more info > -wps From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 4 23:26:44 1993 From: William J. Coldwell To: Hartmut Kuehn Subject: Re: supra controller ?! Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com From: Hartmut Kuehn >What about the Supra SCSI Controller Wordsync Series 3 ?? I have 5380 code, that's generic enough to get Supra, Nexus, MPB, C LTD., and probably even Trumpcard and any other 5380 based controller to work, simply by changing the autoconfig information and the chip offset.. the problem is that I haven't had time to investigate how to change the current scsi driver into something I can drop this Read() and Write() into. Now, if some kind soul wanted to either do the device wrapper and send it to me, or convince me that you will really do the driver - then I'll send the code to you. Once you/I have the code working, then I'll do/show the interrupt version regarding psuedo-DMA of it. Bill -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 02:06:06 1993 To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: X X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com I installed X11R4 and X11R5 and they both work fine for me with few glitches. The X11R5 server trashes the top few lines of my custom chips display. It seeps as if the copper list for the X server also has made my screen not 400 tall, too (probably related bugs). xdm still doesn't deal with logins with passwords ... I have recompiled xdm from sources and no luck. Markus W. tells me that using the getpw*() functions will automatically use shadow passwords if the program (xdm) is suid root. Nope. Perhaps the problem below is simply a permissions one on things in /dev. I may have fixed these things along the way :-) >>>>> mh == osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: mh> On Dec 4, 10:03am, Arthur Hoffmann wrote: > > > I've got the 713 and X doesn't work: > > > > That was exactly the reason for 714... > > > > -Markus > > Well, 714 doesn't work either, It came up with a MMU fault for X11R4 > and needed a 3 finger salute, and now exactly the same thing is > happening for X11R5. mh> I think the problem is that the server is attempting to mh> write to the console. The new console stuff for the mh> custom chip display will attempt to output to the console mh> after it has been turned off when the display is put into mh> the graphics mode. I would suggest trying to run the X mh> server with stdout and stderr redirected somewhere mh> (/dev/null or /tmp/xxx) and see if that works any better. mh> [I just had the same trouble trying to get the X11R5 mh> server running on my system and found where the MMU fault mh> was occurring.] In fact, I'm typing this in from an xterm mh> window. I love it!! mh> I just checked the output of both Xbsd and vfwm and they mh> both have written some data to stderr. mh> Michael mh> -- mh> Michael L. Hitch INTERNET: osymh@montana.edu Computer mh> Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of mh> Systems and Computing Services Montana State University mh> Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 02:58:15 1993 From: Kevin M Mccarthy Subject: FTP SITE IN US!!! To: NetBSD-Amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 1181 Sender: NetBSD-Admin@cbmuucp.commodore.com Ok, I have set up an fsp/ftp site for NetBSD-Amiga in the US. It is a 486 running Linux with experimental network code. (Only marginally reliable). Anyway, read the login message for more info. It is not finished, but the mirroring is working fine. You will find the NetBSD mirror in /pub/mirrors/ftp.eunet.ch/NetBSD-Amiga It is all that is there now. In the near future, it will have a /pub/os/bsd/NetBSD-Amiga directory which will have links in it to make it easier to navigate. att2.cs.mankato.msus.edu (134.29.8.241) FTP att2.cs.mankato.msus.edu (134.29.8.241) PORT 21 FSP Please, if you have any questions, or problems write: signals@att2.cs.mankato.msus.edu (BTW, use the fsp server if you can.) -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 03:35:11 1993 From: William J. Coldwell To: netbsd-amiga@cbmuucp.commodore.com Subject: alt.sys.amiga.netbsd Sender: NetBSD-Admin@cbmuucp.commodore.com I have been informed that there are people who are echoing this mailing list locally into a newsgroup. Since there is so much mail on this list, perhaps we should consider starting our own newsgroup. This mailing list consists of ~250 entries, of which some are being locally echoed.. so basically, I have no way of knowing the real number of readers. What do you think? -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 10:54:59 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: X on Retina done Sender: NetBSD-Admin@cbmuucp.commodore.com A alpha V -0.001 of X11R5 has born on my retina this night. it's parents are raoul_o for portage and me for hardware routines. this version will not be released until we find a bug in displaying some fonts. more over no optimisations have been made, so the server is quite a bit slow. (it is as slow as the custom chip 16 colors mode). for now, only 1024x768x256 resolution is supported, but I'm writing a sort of retina define monitor to create monitor def. So resolutions settings will reside in a config-file somewhere is /usr/X11/lib naybe. I'm looking for other depth as 15bits, 16bits, 24bits and 4bits for speed (maybe mono) those mode could be usefull to test applications which must support mono or true color. 24 bits may be 3 times slower tha 256bits mode. THE DEBUGGING TAKES A LOTS OF TIME< BECAUSE gdb-2.19 DOSN'NT WORK !!! IF FILES ARE NOT COMPILED WITH -g OPTION, I'VE GOT PTRACE ERRORS (under #709) (I made a mistake, it's gdb-4.19) IF COMPILED WITH -g OPTION: STACK IS ALLWAS EMPTY. so I'm using the default debugging package (printf, ErrorF, perror, exit, return ... :-( ) Any ideas for gdb ??? lahaye_o@epita.fr From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 13:15:45 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X To: mykes@shell.portal.com Cc: osymh@gemini.oscs.montana.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 616 Sender: NetBSD-Admin@cbmuucp.commodore.com > Perhaps the problem below is simply a permissions one on things in > /dev. I may have fixed these things along the way :-) For all you SnoopDOS/trace/truss lovers out there.. there *is* something similar in NetBSD, not quite as confortable as the mentioned tracers, but still tremendously useful. ktrace -i startx (the -i is to inherit the trace flag by children) should leave you a nice dump to be later analized with "kdump | less" or so. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 13:30:16 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X on Retina done To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1460 Sender: NetBSD-Admin@cbmuucp.commodore.com > A alpha V -0.001 of X11R5 has born on my retina this night. I love it! > of retina define monitor to create monitor def. So resolutions settings will reside > in a config-file somewhere is /usr/X11/lib naybe. You could use the config environment of the XFree86 server? This one allows quite extensive setup possibilities for the various VGA registers.. > 24 bits may be 3 times slower tha 256bits mode. I'd suggest you really concentrate on 8bit mode in the beginning. 24bit mode is not only dead slow, but you can't get any decent resolutions out of it anyway (unless you ways overclock the board...). 4bit gfx would probably be a very neat thing (and XFree does have this 16color option I think). > THE DEBUGGING TAKES A LOTS OF TIME< BECAUSE gdb-2.19 DOSN'NT WORK !!! > IF FILES ARE NOT COMPILED WITH -g OPTION, I'VE GOT PTRACE ERRORS (under #709) > (I made a mistake, it's gdb-4.19) > IF COMPILED WITH -g OPTION: STACK IS ALLWAS EMPTY. Hm, I got newest gdb from gnu yesterday, and that was 4.11.. I've tried to implement support for shared libs, but that will of course be subject to massive testing (which I couldn't do yet). Shared libs are functional now, I'll try to make a new binary distrib for next Thursday (can't get at a tape drive hooked up to the network before..). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 20:47:13 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Re: X on retina Sender: NetBSD-Admin@cbmuucp.commodore.com > You could use the config environment of the XFree86 server? This one > allows quite extensive setup possibilities for the various VGA registers.. Of course, that would be a good idea, but XFree parameters are not the parameters given by retina define monitor: uder XFree, the HT (Horizontal Total) is the exact value. under retina-define-monitor, the given value is HT-5 (which is the value to store to the hardware) so on one hand some one will want to use XFree config files and on the other hand, some ones will want to use retinaDefineMonitor. what should I do ? My solution is to use a retina define-monitor compatible config file which could be generated by my future XDefineMonitor (not written yet) >I'd suggest you really concentrate on 8bit mode in the beginning. 24bit > mode is not only dead slow, but you can't get any decent resolutions out > of it anyway (unless you ways overclock the board...). 4bit gfx would > probably be a very neat thing (and XFree does have this 16color option > I think). Of course, I'll really concentrate on 8bit until it works. After this I'll look for 4bit-mode or 16bit mode (don't know actually) 24bit mode will be released for developper who want to test true color (even if it's slow, it's quite usefull). > Hm, I got newest gdb from gnu yesterday, and that was 4.11. Good thing (I told you that I had v4.19, but I don't exactly remeber the exact version). lahaye_o@epita.fr olivier.lahaye@ramses.gna.org From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 5 20:47:29 1993 Subject: Re: alt.sys.amiga.netbsd To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit From: swt@garble.affinity.mn.org (Stephen W. Thomas) Content-Type: text/plain; charset=US-ASCII Content-Length: 1399 Sender: NetBSD-Admin@cbmuucp.commodore.com > Date: Sat, 4 Dec 93 18:26:09 -0800 > From: William J. Coldwell > Subject: alt.sys.amiga.netbsd > > I have been informed that there are people who are echoing this mailing list > locally into a newsgroup. Since there is so much mail on this list, perhaps > we should consider starting our own newsgroup. [...] > What do you think? I think this is a good idea. But perhaps instead of going through the trouble of starting a new group comp.unix.amiga could be used. It seems that most of the traffic is currently netbsd related. If c.u.a became flooded with messages from other unixes, like linux, a new group then could be created. Say c.u.a.netbsd. For those who do not have Usenet access a relay, if one does not already exist, could be setup to copy messages posted on c.u.a to a mailing list. >From what I can see the main advantage of using an existing news group is that this group is already carried by a greater number of machines. Not everyone has access to alt groups since a lot of sites don't carry the alt hierarchy, or all parts of the hierarchy, and won't necessary add alt.sys.amiga.netbsd. -- Stephen W. Thomas UUCP: swt@affinity.mn.org Affinity Computer Applications, Inc. VOICE: (612) 484-2905 4740 Hodgson Road FAX: (612) 483-4069 Shoreview, MN 55126-6042 USA BIX: affinity From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 03:58:18 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1088 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: succ. NetBSD inst. on A500-040 Sender: NetBSD-Admin@cbmuucp.commodore.com I just installed the most current rootfs on my Amiga and started up vmunix-40.713. I don't know if anybody has tried this on an 040 accelerated Amiga 500, but everything seemed to work flawlessly. Here is my configuration: Amiga 500 (all ECS w/ KS 2.04) GVP Impact Series II controller Progressive Peripherals 68040 accelerator (28MHz w/ fully func. 040) 2MB Chip RAM, 8MB 16 bit Fast RAM, 4MB 32 bit Fast RAM Quantum 525LPS drive NetBSD only used my 8MB 16 bit Fast RAM, but that was to be expected. It did recognize my 2MB Chip RAM and currently thinks that I own an A2000-040. :-) I have only mounted the root fs so far, so haven't really gone digging deep into things. Actually my modem is still downloading bin-usr.gnu.tar.gz and I also have a physics exam coming up tomorrow. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 05:08:51 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1375 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: newfs probs Sender: NetBSD-Admin@cbmuucp.commodore.com Oh great... having just said that the installation went fine, I already bumped into my first problem. I can't even create a file system. I have set up my partitions according to our NetBSD FAQ (root-8MB swap-36MB /usr-60MB /opt-60MB /home-25MB /home2-17MB on UNIT 0 drive). When I type newfs /dev/rsd0d I get a message like newfs: ioctl (GDINFO): Invalid argument can't read disk label .......... and errors message about disk label which I am supposed to ignore ........ When I go ahead and try to mount the partition using mount -av (my /etc/fstab file is set up correctly) it won't mount the partitions and report an errors message of the sort "Bogus super block" for each partition. Any help on getting this to work is very welcome. :) Thanks. Stefan P.S. I am using the /pub/NetBSD-Amiga/rootfs.tgz and the vmunix-040.713 kernel from eunet. This is on an Amiga 500 with 8MB 16 Bit RAM, 2MB Chip RAM, PPI040, GVP Series II, Quantum 525LPS. Oh... the reboot command severely crashes my computer (awfully weird display on both modem LCD-display and monitor). ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 05:40:04 1993 From: Roy Trevino To: NetBSD-Amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: anyone interested in a competing X server? Sender: NetBSD-Admin@cbmuucp.commodore.com Just for thrills, I ported my own, independent X11R5 server "Xami" to NetBSD last weekend (generic monochrome sample server). After tweaking it all week and this weekend, it is starting to look pretty complete. Required less than 100 lines of new, well placed code; works on an unmodified 709 kernel. Anyways, the question is, with the very nice "French" (?) version already out there, is there anybody out there who is interested in another server? (just the server itself since existing clients, libs, etc., should be compatible). Or a very minimal X setup? If so, I could upload it next weekend so someone could help me test it out. Being monochrome, it has the advantages of being small (500k) and fast. (Visions of x11perf/xstones/otherXbogusbenchmarks wars :-). No plans to tweak the cfb Pixblit routines for ecs yet though. Or would that just confusing and a waste of disk space and bandwidth? If so, I'll just keep it to myself and be quiet. I plan to get a new graphics card as soon as I figure out which one (spectrum?), and would really like to have X11 running on it (my real motivation for doing my own port: guaranteed support). Maybe then would be a better time. Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 06:16:45 1993 From: Abeech@splat.paxnet.com.au Subject: A lower resolution console? To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 360 Sender: NetBSD-Admin@cbmuucp.commodore.com Is it now possible to have something like a 640x200 console with definable foreground/background pens? The only thing that stops me from using NetBSD at the moment is the high-res console and the black on white text. My eye sight is not strong enough to read it! So if a lower resolution is possible will someone please tell me how to do it. Thanks. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 08:04:35 1993 From: niklas@appli.se (Niklas Hallqvist) To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: newfs probs Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Stefan" == Stefan G Berg writes: Stefan> newfs: ioctl (GDINFO): Invalid argument can't read disk label Stefan> .......... and errors message about disk label which I am Stefan> supposed to ignore ........ Is anybody maintaining the FAQ? Add this question: Q: A program generates something like "iotcl (GDINFO): invalid argument", why? A: Starting with version 713 support for Non-BSD partitions was added. This meant that pre-713 binaries of programs depending on sizeof (struct disklabel) got obsolete. Specifically newfs, mount_mfs (which is a link to newfs) and disklabel didn't work anymore. Newer versions of these can be gotten from ftp.eunet.ch, either in bin-newest or in bin-sbin.tar.gz if it's newer than Nov 22 1993. If you've compiled the thing yourself, recompile it making sure that you use a post-713 version of sys/disklabel.h which can be found either in a recent (post-713) bsdsyssrc.xxx.tar.gz archive. Niklas From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 12:38:45 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: intalling on a gvp 030 X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com I'm about to install netbsd on a friend's A2000/GVP030 machine and I would like to know from someone else who's done it already how to name the partitions BSDR, BSDS, BSDA, etc. using faaaastprep. I haven't seen faaaastprep in a couple years, but my friend told me that he couldn't find any text box in faaastprep that had a hex number in it for his partitions other than the "mask" field. Also, he has a toggle gadget for file system type that has 3 choices: ofs, ffs, and afs. Does he have an old version of faaastprep? If he does, would someone out there uuencode and mail me a copy of the new faastprep? Or are people copying devs:gvpscsi.device to devs:scsi.device and using hdtoolbox? (sounds dangerous) ... From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:03:57 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: intalling on a gvp 030 Sender: NetBSD-Admin@cbmuucp.commodore.com you can use hdtoolbox with any scsi.device. just launch it from the shell like this: 1> hdtoollbox my-scsi.device and it should works. lahaye_o@epita.fr From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:16:08 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1232 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A lower resolution console? Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Abeech (Abeech), in <9312060512.AA02972@paxnet.com.au> on Dec 6 you wrote: >Is it now possible to have something like a 640x200 console with definable >foreground/background pens? The only thing that stops me from using NetBSD >at the moment is the high-res console and the black on white text. My eye >sight is not strong enough to read it! So if a lower resolution is possible >will someone please tell me how to do it. A related issue. I believe NetBSD currently opens a 640x400 NTSC interlaced hires screen with 4 bitplanes. Am I correct with that asssumption? I don't like interlace myself either, but what is real bad is that a 16 color screen saturates my 16 bit Chip RAM bandwidth (yeah... still have an Amiga 500), making my serial port totally useless. The maximum bps rate I can go to is 4800... which is very depressing on a 14.4kbps modem. If I can drop it to 1 or 2 bitplanes, then things should be fine. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:21:30 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A2630 To: NetBSD-Admin@cbmuucp.commodore.com (Alain Chofardet) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > First, I have problems with memory tests : my A2630 has 2Meg autoconfig on > the board, and I have a DKB2632 memory expansion on it (4Meg). I hope this gets working as I intend to use the 2632 (when I get some more money :^) ). [...] > Moreover, my GVP Series I SCSI controller is going to make me crazy. > A friend of mine lent me a GVP Series II. Me too! :^) My friend lent me an Accelerator, which sucks becuase the dma blows. I loose bytes durring serial transfers. It did allow me to design better CC graphics code however becuase if my code wasn't fast enough the screen never displayed... :^) Anyway can someone please look into what needs to be done to get GVP series I controllers working? I am sure alot of people are still using them. > > I found big problems using FaaastPrep to configure BSD partitions; it seems not > to work as HDToolBox. Yes use HDToolBox.> [...] > Any idea, assuming it is possible my install isn't clean ? Hmm, regarding the no root thing, that was what I got originally when I tried to use the Series I controller, if your trying that forget it for now and use your friends series II. > > Thanks. Alain. > From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:21:59 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A lower resolution console? To: NetBSD-Admin@cbmuucp.commodore.com (Stefan G. Berg) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > A related issue. I believe NetBSD currently opens a 640x400 NTSC > interlaced hires screen with 4 bitplanes. Am I correct with that > asssumption? I don't like interlace myself either, but what is real No, it uses a 2 plane (4 color) the new cc stuff allows you to specify whatever you want, 713 allowed it to be binpatch changed. [...] > Stefan > > ,-------------------------------------------------------, > |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| > |Internet sgberg@ucs.indiana.edu MIME // AMIGA | > |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | > `-------------------------------------------------------' > Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:22:27 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1397 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: succ. NetBSD inst. on A500-040 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Michael (Michael L. Hitch), in <9312060655.AA20313@gemini.oscs.montana.edu> on Dec 5 you wrote: >> NetBSD only used my 8MB 16 bit Fast RAM, but that was to be expected. >> It did recognize my 2MB Chip RAM and currently thinks that I own an >> A2000-040. :-) > > I never did add support to check for the PPI card and print A500. If >you want to see A500 printed, you can always binpatch it in :-). The >next version of loadbsd will pass all the memory segments to NetBSD, >but NetBSD won't make use of it yet. It does have the capability of >using chip memory or 16 bit fast memory (if NetBSD isn't loaded in >16 bit fast memory) as a DMA bounce buffer for the A2091 and GVP11 >controllers. I was also thinking of adding an option to loadbsd that >would use the highest priority fastmem for NetBSD instead of the largest. Yes, an _option_ to use highest priority memory would definitely be a good idea. There are probably enough people out there like me who have high priority 32 bit memory, but more low priority 16 bit memory in their machine. That way I could decide which one to pick. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:23:43 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: new cc stuff. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com Well I have uploaded the newest cc stuff to ftp.eunet.ch as incoming/newcc-stuff.tar.gz If you want the problems described below fixed and can recompile the kernel goahead and grab it, markus will probably include them in the kernel for next release if not. (note the new iteconfig program :^) BTW also note my comments to the X folks. Please if everyone could limit the reports of "problems with the new cc console" to my problems and not problems with X I would be happier. I spent a good deal of time on my code and it appears that it is not being used by the X folks, I can't seem to initiate any sort of communication with them, so when problems arise between our code its not my fault and I don't wish to be blamed. I am not copping an attitude, however, I am a little disapointed as I wrote the view device with ddx's in mind. It would be very easy to interface X to the view device and would allow everyone to have a console AND X open at the same time, with the current kernel. Then as (and if) other display cards were added into the view graphics subsytem, X would also work correctly on those. I am rambling, I guess I just need some people to support me and convince the X people that they probably need to 1) send me a letter, maybe even let me look at there code.. 2) use the /dev/view interface. I would like to make clear however that I am very pleased that someone is working on X and I thank everyone involved for there time. :^) Now here is the README from newcc-stuff.tar.gz: * * * 12/6/93 7:12am. Ok here are the latest patches to the CC console and graphics subsystem. - iteconfig: is a configuration program that can dynamically change your console's settings. It has been placed under GNU Copyleft so the source is included. You will have to whip a Makefile together to build it---I use the bsd system, and mine just wouldn't make (no pun intended) sense to include. - cc-fixes.diff: these are the diffs necsessary to use the iteconfig program and you should probably apply them to your 713 kernel sources. I expect Markus will include them in the next release. Enjoy. : Whats fixed overscan: it works but is a little korny sometimes sorry. The only bug I found so far is with an width of 642 it just doesn't center correctly. I also am not happy that my overscan abilities do not match that of C='s. I will perhaps look into there method at some later time. If your curious C= is offseting the bitmap pointers by -2 bytes and doing funky things with the ddfstart under 2.0+ so that they can get a tighter fit. You'll probably notice that I have to move the screen left at certain widths (644+,674+,708+) This is becuase datafetch must be a multiple of 4 and must also not cross the $d8 boundry, what C= is doing is offseting the bitmap pointers by -2 and delaying display so they can get widths of multiples of 2 (word). I suppose I have just figured out how to do it while typeing this README...so next time we should have this ability. colors: not that anyone noticed but the /dev/view device's colormap functions were disabled by Markus. They are now implemented in a cleaner fashion so they can be used. iteconfig uses them to allow you to change the screen colors. 2024: 1024x800 sorry this mode still appears to be dead. I haven't had the time to look into it. It is enabled however and a quasi-functioning 1024x800x2 (NOTE only depths of 2) can be made to display through iteconfig if your kernel allows. AGA: someone send me a newer computer :^) ECS: ECS PAL is now working so that people with NTSC machinces can use it. X: Why is it that as the author of the Custom chips code I haven't received one letter from these people? I wonder if they relize that using the view device as it was designed will allow people to have a console open and X at the same time... HEY X PEOPLE. there is no need to use the /dev/console for X try /dev/view01. (Actually I did receive one [letter] from Philip asking for my source which I gave. no questions asked. no replies received.) I just need a little communication here. :^) Again Enjoy, Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 15:24:02 1993 From: Ari Yrj\vl\d To: netbsd-amiga@cbmuucp.commodore.com Subject: intalling on a gvp 030 Sender: NetBSD-Admin@cbmuucp.commodore.com > I'm about to install netbsd on a friend's A2000/GVP030 machine and > I would like to know from someone else who's done it already how to > name the partitions BSDR, BSDS, BSDA, etc. using faaaastprep. I haven't > seen faaaastprep in a couple years, but my friend told me that he Forget Fartprep, it's crap. Only use it, if you want to destroy your RDB, as it writes garbage to RDB fields it thinks are not worthy. Add "SCSI_DEVICE_NAME=gvpscsi.device" to HDToolbox's tool types and you can use that instead. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 16:19:30 1993 From: niklas@appli.se (Niklas Hallqvist) To: niklas@appli.se Cc: sgberg@charon.bloomington.in.us, netbsd-amiga@cbmuucp.commodore.com Subject: Re: newfs probs Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Niklas" == Niklas Hallqvist writes: >>>>> "Stefan" == Stefan G Berg writes: Stefan> newfs: ioctl (GDINFO): Invalid argument can't read disk label Stefan> .......... and errors message about disk label which I am Stefan> supposed to ignore ........ Niklas> Is anybody maintaining the FAQ? Add this question: Niklas> Q: A program generates something like "iotcl (GDINFO): invalid Niklas> argument", why? Niklas> A: Starting with version 713 support for Non-BSD partitions Niklas> was added. This meant that pre-713 binaries of programs Niklas> depending on sizeof (struct disklabel) got obsolete. Niklas> Specifically newfs, mount_mfs (which is a link to newfs) and Niklas> disklabel didn't work anymore. Newer versions of these can be Niklas> gotten from ftp.eunet.ch, either in bin-newest or in Niklas> bin-sbin.tar.gz if it's newer than Nov 22 1993. If you've Niklas> compiled the thing yourself, recompile it making sure that you Niklas> use a post-713 version of sys/disklabel.h which can be found Niklas> either in a recent (post-713) bsdsyssrc.xxx.tar.gz archive. Oops! The last sentence missed the alternate source of sys/disklabel: a post-713 release of bin-usr.include.tar.gz! Niklas From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:26:38 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: markus@TechFak.Uni-Bielefeld.DE Subject: Re: Latest versions to use??? Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com |On Dec 3, 5:33pm, Alan Bair wrote: |> 1. Updates to fontdumper.c, I saw some note from Chris Hopps. |> 2. Try to generate a 10MB rootfs with the latest stuff and most of the |> networking, sendmail, etc. turned off so beginners can run out |> of the box (maybe). Gurus can turn on what they want. |> 3. Write some updates on this new rootfs for the FAQ. | | Consider making two versions of the rootfs, one with networking support, | the other without. Thus the non-networking version shoul dbe smaller. | Aehem, and wait for the sahred libs :) Fantastic idea! Let me add a vote for this approach. Rob From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:36:17 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: A2630 Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 2:34pm, Alain Chofardet wrote: > The DKB2632 isn't autoconfig but starts at 0x7c00000. The 713 kernel do > recognize it but assumes running on an A3000. > > To solve the problem, this is my proposition on 713 sources (Markus) : > > Modify sys/arch/amiga/amiga/autoconf.c like that ... > and sys/arch/amiga/dev/device.h The next version of the kernel should have a patchable flag to control the configuration process. This is just another kludge, but easier to change if you can't recompile the kernel. > Changing root device to sd1a > > bpf:sl0 attached > bpf:ppp0 attached > bpf:lo0 attached > > panic : cannot mount root > > And we stops there. When I hit a key, the kernel dumps to the Syquest... > > Any idea, assuming it is possible my install isn't clean ? Do you have _scsi_no_dma patched to 1? If not, that is probably where your problem is. The GVP Series II controller can not DMA into memory outside the 68000 address space. The next version of the kernel should automatically supress DMA transfers on the A2091 and GVP11 drivers if the I/O buffer is not in the 68000 address space. In addition, these drivers can be configured to use either chip memory or Zorro II memory (if any Zorro II memory is available and not used to load NetBSD) as a DMA buffer. Using chip memory works, but seems to disrupt the display a bit. If you want to try a kernel with these features, I can provide it for you to try out. [Besides, I would like some verification that my latest '040 changes will allow the same kernel to run on a '030.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:37:23 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: intalling on a gvp 030 Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 3:48pm, Ari Yrj\vl\d wrote: > > I'm about to install netbsd on a friend's A2000/GVP030 machine and > > I would like to know from someone else who's done it already how to > > name the partitions BSDR, BSDS, BSDA, etc. using faaaastprep. I haven't > > seen faaaastprep in a couple years, but my friend told me that he > > Forget Fartprep, it's crap. Only use it, if you want to destroy > your RDB, as it writes garbage to RDB fields it thinks are not worthy. And PPI Zeus users should NOT use the PPI ScsiToolBox program - it will clobber the filesystem information in the RDB and render the disk unbootable. [I think there is another bug in the PPSscsi2.device driver, but I haven't had the time to track it down.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:45:56 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: 713 compiled kernel console messed Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 9:09am, Chris Hopps wrote: > > Compilation was done under 570 and now in the distributed 714 kernel, > > same efects, console is messed. The screen color is yellow, characters > > are like something in HAM mode, very smeared. Funny thing is that > > kernel appears to work besides the messed console, and with some > > imagination you can almost read what you typed to console.. > > This is very odd... have you tried to compile the kernel under NetBSD? > i haven't heard anyone with console problems like this, that doesn't mean > there aren't bugs, but I can't imagine what would cause such oddness. > > to everyone: anyone else experianced anything similar to this? I noticed the same thing when I attempted to patch some of the ite_default* values to try to get an overscanned screen. I only tried it once and got the same results. I had thought about digging into the code and playing with the parameters I was patching, but that hasn't been a big priority [and I probably won't even try it now that the new cc console stuff is there to play with]. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:53:38 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: NetBSD-Amiga@cbmuucp.commodore.com, dej@eecg.toronto.edu Subject: Re: X Sender: NetBSD-Admin@cbmuucp.commodore.com |A few observations and questions: | |- First, if anybody out there is still running with a 4 Meg system, splurge | and get yourself another 4 Meg quick! Kernel builds are about 3 times | faster. I've yet to try X since... Well, I am still building on a 4MB system, but this only the fault of NetBSD right now -- it is ignoring my other 4.5MB of RAM. Any news about fragmented memory support? I would look myself but I have too many things to do right now with this new baby (just call me dad!) :-) Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 17:54:45 1993 To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Latest versions to use??? X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> RT == rtulloh@oneway.austin.ibm.com (Rob Tulloh) wrote: RT> |On Dec 3, 5:33pm, Alan Bair wrote: |> 1. Updates to fontdumper.c, I saw some note from Chris Hopps. |> 2. Try to generate a 10MB rootfs with the latest stuff and most of the |> networking, sendmail, etc. turned off so beginners can run out |> of the box (maybe). Gurus can turn on what they want. |> 3. Write some updates on this new rootfs for the FAQ. RT> | RT> | Consider making two versions of the rootfs, one with RT> networking support, | the other without. Thus the RT> non-networking version shoul dbe smaller. | Aehem, and RT> wait for the sahred libs :) RT> Fantastic idea! Let me add a vote for this approach. RT> Rob Let me cast a MAJOR NEGATIVE vote to this approach. Even if you don't have slip or a network, there are reasons to still have networking installed. Term is one such program. It is the next best thing to SLIP, and if you are going to modem to the internet from your netbsd machine, you will WANT to use term (trust me :-) And it requires the networking stuff installed. The networking stuff is SMALL and there's no reason to not include it in the rootfs distribution. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:07:50 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. Sender: NetBSD-Admin@cbmuucp.commodore.com Our port of X11 uses mmap to map the divice driver memory. then X11 uses this memory as a frame buffer. no more use of the driver. Note that ite is closed when switching to graphic mode. Actualy, these beta version (no shared libs) is printing debug informations assuming you've launched it from another console. it seems that was this debug info which crashes #713 closed ite driver. so ite should ignore these message when closed. all debug info will be removed in final version. You can ru Xbsd like this: Xbsd >foo or Xbsd >/dev/null /* for normal usage */ > 1) send me a letter, maybe even let me look at there code.. > 2) use the /dev/view interface. does /dev/view know how to deal with the retina board ??? The code will of course be available when it'll be cleaned (no debug ErroF, ...) You shouldn't blame us for those time delays, because actualy, we've got a huge amount of school work (X224 and X225 total rewrite, final exams, reports for DecNet (250 pages), report for X224 ... :-((( ) Actually I'd like to continue to debug the retina X11 port, but these last 3 days, I coundn't look any NetBSD peace of code :-((. Sorry, All those things (Scool CPU over load ;-) ) will desapear in December the 23th. And then, We'll be able to work 24 hour a day ... lahaye_o@epita.fr raoul_o@epita.fr brand_o@epita.fr == brother@epita.fr From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:18:09 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: mykes@shell.portal.com Subject: Re: Latest versions to use??? Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com | |Let me cast a MAJOR NEGATIVE vote to this approach. Even |if you don't have slip or a network, there are reasons to |still have networking installed. Term is one such program. |It is the next best thing to SLIP, and if you are going |to modem to the internet from your netbsd machine, you |will WANT to use term (trust me :-) And it requires |the networking stuff installed. The networking stuff |is SMALL and there's no reason to not include it in the |rootfs distribution. Well, never mind then. I was just looking for a way to get the disk requirements and memory requirements reduced. I am in no position to buy a new disk right now and 100MB is all I can spare for the time being. Anyhow, it looks like others thought this a bad idea too. Sorry I jumped to conclusions so quickly. I should have read the rest of my mail first. Yes, I do want to use term. I am just waiting to compile it when I can use all 8MB of my RAM instead of just 4MB. I compiled screen and that took 1.5 hours! I will wait to do term when the situation improves. The zlib idea sounds good to me though. Perhaps this could be controlle from an environment variable so that users could turn this on as needed? Just an idea.... Rob From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:43:36 1993 From: jyork@iastate.edu To: netbsd-amiga@cbmuucp.commodore.com Subject: Accellerators, 32bit mem, and the GrandSlam Sender: NetBSD-Admin@cbmuucp.commodore.com >From: sgberg@charon.bloomington.in.us (Stefan G. Berg) >Yes, an _option_ to use highest priority memory would definitely be a >good idea. There are probably enough people out there like me who have >high priority 32 bit memory, but more low priority 16 bit memory in >their machine. That way I could decide which one to pick. >Stefan This would be a great idea, but how about merging memory segments? Is this possible? I have only 2M of 32bit mem, but 4M (soon 8) of 16bit mem. Does NetBSD's MMU usage method prohibit this? Also, since I have a FrankenAmiga, is anyone working on support for the IVS GrandSlam/Trumpcard Pro cards? I don't think they use DMA. Is this the reason they aren't usable yet? If they can be used by patching some of the existing code, please tell me how. The product code is 2112/52 ($840/$34). I hope that at least gets someone working... :) I'd love to help, but I've never done this sort of device-level coding before. I am willing to test though... Long live the Amiga, and NetBSD!!! ********************************************************************* * * * * Programming is like pinball. The reward * Justin York * * for doing a good job is the chance to do * * * it over again! * jyork@iastate.edu * * * * ********************************************************************* From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:44:39 1993 From: Alain Chofardet Subject: A2630 To: NetBSD-Amiga@cbmuucp.commodore.com (ML NetBSD) Mailer: Elm [revision: 72.14] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi. I tried to boot NetBSD on my A2000 last week-end; there is several problems for me. First, I have problems with memory tests : my A2630 has 2Meg autoconfig on the board, and I have a DKB2632 memory expansion on it (4Meg). The DKB2632 isn't autoconfig but starts at 0x7c00000. The 713 kernel do recognize it but assumes running on an A3000. To solve the problem, this is my proposition on 713 sources (Markus) : Modify sys/arch/amiga/amiga/autoconf.c like that 730a731 > case PROD_GVP_SERIES_I : 1071a1073,1077 > case MANUF_CBM_2: > switch (cd->cd_Rom.er_Product) { > case PROD_CBM_2_A2630: > return (0); /* A2630 - Accelerator Card for A2000 */ > } and sys/arch/amiga/dev/device.h 108a109 > #define PROD_CBM_2_A2630 81 124a126 > #define PROD_GVP_SERIES_I 3 Moreover, my GVP Series I SCSI controller is going to make me crazy. A friend of mine lent me a GVP Series II. I found big problems using FaaastPrep to configure BSD partitions; it seems not to work as HDToolBox. Finally, I succeed in making the kernel recognize BSD partitions, but the kernel didn't go further. This is an approximate copy of the screen when it crashed : NetBSD 0.9 (713) (...) realmem 4194304 availmem 1761280 RealtimeClock A2000 rtclock0 par0 grf0 grf0 grf0 grf1 (retina) grf1 dma0 : GVPII DMA scsi0: SCSI id 7 GVPIIscsi0 sd0:QUANTUM ... sd0 at GVPIIscsi0, slave 0 sd1:SYQUEST SQ555 ... sd1 at GVPIIscsi0, slave 1 Changing root device to sd1a bpf:sl0 attached bpf:ppp0 attached bpf:lo0 attached panic : cannot mount root And we stops there. When I hit a key, the kernel dumps to the Syquest... Any idea, assuming it is possible my install isn't clean ? Thanks. Alain. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:45:23 1993 To: Alan Bair Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: rootfs/networking, gzip filesystem X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> ab == Alan Bair wrote: > > The zlib idea sounds good to me though. Perhaps this could be > controlle from an environment variable so that users could turn this > on as needed? Just an idea.... ab> I think this is a VERY good idea. It allows those that ab> want to have this behavior to have it and those that want ab> a normal behaving system to it have it too. It also ab> allows it to be dynamic. With zlibc, you don't turn it on or off. If you gzip ANY file you have by hand (your choice to do so) then you may tell ANY program that is not statically linked (i.e. uses zlibc) can open/read the gzipped file as if it weren't compressed. > > Rob > ab> -- ab> Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design ab> Software & Mail Stop OE-320 Computer Services) 6501 ab> William Cannon Dr. West (512) 891-2336 Austin, TX ab> 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 18:48:13 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 5:06pm, olivier lahaye wrote: > > Actualy, these beta version (no shared libs) is printing debug informations > assuming you've launched it from another console. > it seems that was this debug info which crashes #713 closed ite driver. > so ite should ignore these message when closed. > all debug info will be removed in final version. > You can ru Xbsd like this: > Xbsd >foo > or > Xbsd >/dev/null /* for normal usage */ Is the X11R5 server using stdout or stderr? I found that there was one line of output sent to stderr, so I had to use: Xbsd 2>/tmp/X.err (The data printed was just something like "Size: 65???".) Also, I think the crashes only occur with the cc code. When the ite device is closed, it releases some data structures that were set up when it was opened. When the cc cursor or putc routines were called, they attempted to use those data structures and crashed. [I'm starting to get the hang of examining MMU fault panics :-).] > The code will of course be available when it'll be cleaned > (no debug ErroF, ...) > You shouldn't blame us for those time delays, because actualy, > we've got a huge amount of school work (X224 and X225 total rewrite, > final exams, reports for DecNet (250 pages), report for X224 ... :-((( ) I'd say you've done a great job so far! X11R5 is running rather nicely on my PPI 33Mz Zeus system. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 19:32:56 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Accellerators, 32bit mem, and the GrandSlam Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 11:31am, jyork@iastate.edu wrote: > Also, since I have a FrankenAmiga, is anyone working on support > for the IVS GrandSlam/Trumpcard Pro cards? I don't think they > use DMA. Is this the reason they aren't usable yet? If they can > be used by patching some of the existing code, please tell me how. > The product code is 2112/52 ($840/$34). I hope that at least gets > someone working... :) I'd love to help, but I've never done this > sort of device-level coding before. I am willing to test though... What SCSI chip do these cards use? If it's the 5380, it will require a completely new driver. I have just purchased a second A2000 which included a Supra Wordsync board, which uses the 5380. Since I have quite a bit of experience with the 5380, I will probably be looking at trying to get a driver working for the Supra. [My A1000 and A2000 used a homebuilt SCSI interface using the 5380 and I've worked on the driver for quite a while. I also was able to get the Amiga Mach kernel to use that controller - which was non-DMA and non-interrupt.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 20:21:19 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Accellerators, 32bit mem, and the GrandSlam To: NetBSD-Admin@cbmuucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > >From: sgberg@charon.bloomington.in.us (Stefan G. Berg) > > >Yes, an _option_ to use highest priority memory would definitely be a > >good idea. There are probably enough people out there like me who have > >high priority 32 bit memory, but more low priority 16 bit memory in > >their machine. That way I could decide which one to pick. > > >Stefan > > This would be a great idea, but how about merging memory segments? > Is this possible? I have only 2M of 32bit mem, but 4M (soon 8) of > 16bit mem. Does NetBSD's MMU usage method prohibit this? Everyone does know about mergemem from workbench 1.3 right? If your memory is contigous but not merged into a single memlist netbsd doesn't seem to think its contiguous (bogus). You can run Mergemem (Sys:system/mergemem) and like magic netbsd will use the extra ram I am currently doing this with 4 M 32 on a 2630, 2M on a gvp csontroller and 2M on a supra 8M board. > > ********************************************************************* > * * * > * Programming is like pinball. The reward * Justin York * > * for doing a good job is the chance to do * * > * it over again! * jyork@iastate.edu * > * * * > ********************************************************************* > Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 22:30:32 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: zlibc To: mykes@shell.portal.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2292 Sender: NetBSD-Admin@cbmuucp.commodore.com > Time to pass another linux-ism by everyone, particularly > mtk... especially now that we will soon be having shared > libs. Well, if this is linux-ism, it sure shows why I don't like linux.. > However, to make this REALLY perfect, you would want to be > able to run the foo.z program. This requires a change to > the kernel loader to load gzipped bins. The advantage of > this? It would allow us to gzip compress all of /usr/bin > all of /usr/local/bin, all of /usr/bin/X and so on. The > result is FAR LESS disk space requirements for the > binaries. That 8M rootfs partition would be half full > instead of too small :-) Just to give you some backgrounds on WHY I hate this idea.. Unix fs is based on a quite interesting scheme of demand loading executables. This means, starting an executable means to tell the memory system, where IN THEORY the disk blocks pertaining to the executable would wind up in memory. However, *no* information is transferred from disk to memory yet. Instead, the program is started, causing page faults along the way, thus only loading what it really uses. Shared libraries work in exactly the same way. Now, suppose you have all the files compressed. Every open would then require reading (and uncompressing) whole files, no matter whether it's only the first two bytes I'm interested in, it would uncompress the whole 2 Megs or so. If you do this on a poorly powered A500, with a 68000 and the xpk filesystem, I can somewhat understand why you're doing it. However, if you do this to a fast machine that is able to even run a Unix system, well, then I just can't understand why you're running unix at all.. > I am proposing is quite similar. Unlike xfh, the entire > netbsd filesystem is compressable/decompressable. xfh Sure.. listen. If you want to distribute such a thing, go ahead. Just make sure I don't have absolutely no, none at all, really no, relations to it... > comments? mtk: I already know you don't like it (too much > like linux :-) Bull.. I stated why I don't like it, and I wouldn't like it being added to any default distribution for Linux, either... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 23:35:30 1993 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: zlibc X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> mtk == mw@eunet.ch (Markus Wild) wrote: > Time to pass another linux-ism by everyone, particularly > mtk... especially now that we will soon be having shared > libs. mtk> Well, if this is linux-ism, it sure shows why I don't mtk> like linux.. > However, to make this REALLY perfect, you would want to be > able to run the foo.z program. This requires a change to > the kernel loader to load gzipped bins. The advantage of > this? It would allow us to gzip compress all of /usr/bin > all of /usr/local/bin, all of /usr/bin/X and so on. The > result is FAR LESS disk space requirements for the > binaries. That 8M rootfs partition would be half full > instead of too small :-) mtk> Just to give you some backgrounds on WHY I hate this mtk> idea.. mtk> Unix fs is based on a quite interesting scheme of demand mtk> loading executables. This means, starting an executable mtk> means to tell the memory system, where IN THEORY the mtk> disk blocks pertaining to the executable would wind up mtk> in memory. However, *no* information is transferred from mtk> disk to memory yet. Instead, the program is started, mtk> causing page faults along the way, thus only loading mtk> what it really uses. Shared libraries work in exactly mtk> the same way. Now, suppose you have all the files mtk> compressed. Every open would then require reading (and mtk> uncompressing) whole files, no matter whether it's only mtk> the first two bytes I'm interested in, it would mtk> uncompress the whole 2 Megs or so. If you do this on a mtk> poorly powered A500, with a 68000 and the xpk mtk> filesystem, I can somewhat understand why you're doing mtk> it. However, if you do this to a fast machine that is mtk> able to even run a Unix system, well, then I just can't mtk> understand why you're running unix at all.. mtk: if what I propose is implemented, ONLY the binaries and ONLY those binaries that you by hand run gzip on must be uncompressed as you describe. And even if you DID decompress a binary, you would do so to /tmp or someplace like that and do your demand loading from there. The issue is not the speed of the CPU, it is the cost of drive space. Some people either have only 400M drives, which is a nice sized bsd setup - BUT they insist on keeping 150M of it for amigaos. Or if you want to keep the sunlamp tree and kernel sources and objects - you need even MORE hard drive space. Other people are like me and simply don't want to add a hard drive to run netbsd - I've seen MANY people say "forget it" when they hear the disk requirement for netbsd. Many many amiga users are europeon university students who simply don't have the money to spend on hard drives. Keep this in mind, markus - I have 3 gig of hard disk, and I probably can care less to use this feature. It isn't for me, but for others I know can take advantage of it. > I am proposing is quite similar. Unlike xfh, the entire > netbsd filesystem is compressable/decompressable. xfh mtk> Sure.. listen. If you want to distribute such a thing, mtk> go ahead. Just make sure I don't have absolutely no, mtk> none at all, really no, relations to it... No, markus. I won't go near it if you won't. I'm not going to spring something on the netbsd world you've made for everyone. It's your football, and you can take it home with you so nobody else can play. I just offered an idea - a good idea. > comments? mtk: I already know you don't like it (too much > like linux :-) mtk> Bull.. I stated why I don't like it, and I wouldn't like mtk> it being added to any default distribution for Linux, mtk> either... The one for linux ONLY does gzip decompression for reading purposes. It does NOT do loading of gzipped binary executables nor does it gzip compress when writing. Among the linux community it is VERY VERY popular. There are people with 60 whole megabytes of hard disk running linux and X and they compress everything they can to make the system usable. No, netbsd is NOT linux. It doesn't have to have all the good things we or others can think of putting in. It doesn't make the ideas bad ones. mtk> -Markus mtk> -- mtk> CHUUG/EUnet Switzerland Markus Wild mtk> Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch mtk> CH-8004 Zuerich Fax: +41 1 291 46 42 mtk> S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 6 23:36:09 1993 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.042:06.11.93.22.16.57] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: zlibc From: "hamish (h.i.) macdonald" Sender: "hamish (h.i.) macdonald" To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: zlibc Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> On Mon Dec 6 17:09:00 1993, >>>>> mtk wrote: mw> Bull.. I stated why I don't like it, and I wouldn't like it being mw> added to any default distribution for Linux, either... Ditto. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 00:35:09 1993 From: niklas@appli.se (Niklas Hallqvist) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Chris" == Chris Hopps writes: Chris> - iteconfig: is a configuration program that can dynamically Chris> change your console's settings. It has been placed under GNU Chris> Copyleft so the source is included. You will have to whip a Chris> Makefile together to build it---I use the bsd system, and mine Chris> just wouldn't make (no pun intended) sense to include. I love this little gem, nice work! Chris> overscan: it works but is a little korny sometimes sorry. The Yeah, this time I can have my 724x566 ite screen and even move it sideways with iteconfig -X, Just great!!! From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 00:43:42 1993 Subject: zlibc From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com One question: Why has no one proposed a compressed filesystem? That is, something like Stacker or Doublespace for MessyDrugs. Simply compress the disk blocks themselves. This can be implemented as a new block device that sits between the filesystem and the raw disk. I would be willing to run a compressed filesystem for my system binaries. I think zlibc is a gross hack. I am probably not alone. BTW, if I built cp with zlibc, then what does cp foo.z bar.z do? :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 01:28:49 1993 To: David Jones Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: zlibc X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> dj == David Jones wrote: dj> One question: Why has no one proposed a compressed dj> filesystem? My zlib suggestion is pretty much a compressed filesystem. I don't think you want an entire filesystem compressed though. What I do think you want is something like the way manpages work - they are kept in compressed form in /usr/man/cat1 and are uncompressed when you want to read them to /usr/man/man1 (well, bsd man may not work exactly like this, but the idea is what's important). There's likely to be a huge percentage of manpages that you never read at all (or only once in a great while) - keeping these uncompressed all the time is just a waste of space. Deleting them means you don't have them when you want them. My suggestion for loading binaries would actually be easy to implement in a shell (as opposed to on the kernel level). The shell would maintain a dir of uncompressed bins and compressed ones. When you run a compressed bin, it would uncompress it to the uncompressed subdir, make a link to the uncompressed bin, and then do system() or exec() on the program. I look at my /usr/bin and /usr/local/bin and /usr/bin/X11 subdirs and see a massive waste of space (in the sense of uncompressed man pages). For example, I so rarely run the colrm program or banner or most of the games that I could care less if it took a little extra time to decompress those programs at runtime. For X theres many many many of these programs I so rarely run... The space benefit may indeed be worth the decompress wait time. dj> That is, something like Stacker or Doublespace for dj> MessyDrugs. Simply compress the disk blocks themselves. dj> This can be implemented as a new block device that sits dj> between the filesystem and the raw disk. mtk had the perfect reasoning for why a compressed filesystem like stacker is not desireable. The executable files for unices are divided into page-size blocks to make demand loading of binaries simple to implement. You couldn't easily demand load a compressed executable (imagine seek to specific offset in file, read 4K...). But mpeg files do compress nicely with gzip, so if you had an entire partition of just mpeg files, a compressed filesystem sorta makes sense. However, with the zlibc scheme, you could just do: gzip *.mpg on all your partitions and have the same benefit. Of course, my suggestion has the added benefit of allowing you to pick and choose which mpg's to compress... dj> I would be willing to run a compressed filesystem for my dj> system binaries. I think zlibc is a gross hack. I am dj> probably not alone. Well, I think Unix is a great big hack. It is just a glorified CP/M with a million hacks on top of it. The issue to me is whether zlibc makes unix more useful to more people. If you think running a compressed filesystem makes sense to make your system binaries compressable, then zlibc makes perfectly good sense. Note that I never ever suggested compressing /bin or /sbin. I feel strongly that those should be -static linked binaries and should never require something like zlibc or a shell enhancement to run. dj> BTW, if I built cp with zlibc, then what does dj> cp foo.z bar.z dj> do? :-) That's a great question. It makes a copy of foo.z as bar.z :-) But it decompresses and recompresses along the way ... I have to look at zlibc for linux closer. It may not be sensative at ALL to the .z extension. It may just look for file.z to open if file is not found (and uncompress it...). zlibc for linux, for sure, only does gzip decompression and NOT compression. dj> -- dj> David Jones, M.A.Sc student, Electronics Group (VLSI), dj> University of Toronto email: dej@eecg.utoronto.ca, finger dj> for more info From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 01:44:07 1993 From: David Crooke Sender: dcc@dcs.edinburgh.ac.uk To: NetBSD-Amiga@cbmuucp.commodore.com From: David Crooke Subject: FAQ/Install, 714 and 040, printer Sender: NetBSD-Admin@cbmuucp.commodore.com Is anyone working on the install docs? I have started to write an up to date install document, but I don't want to duplicate anyone else's efforts. If everyone's happy with me doing it I was also going to upload an updated, larger rootfs (e.g. 10MB), with bin-bin.tar.gz, bin-sbin.tar.gz and the bin-newest stuff installed, the networking disabled, no password for root, etc. etc. Not much help I know, but it will free the more knowledgeable to work on more useful things. I had thought that 714 had integrated 040 support, but it hangs on my system (A3000/PPI 040) in 040 mode, although it works fine with the 030. Is this normal? Also, the printer daemon doesn't seem to work, although lpr/lpq do their thing (and report that it isn't working). Suggestions? Dave David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 1408, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 5164 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 02:17:17 1993 Subject: Re: zlibc From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > mtk had the perfect reasoning for why a compressed > filesystem like stacker is not desireable. The executable > files for unices are divided into page-size blocks to make > demand loading of binaries simple to implement. You > couldn't easily demand load a compressed executable > (imagine seek to specific offset in file, read 4K...). Not true. My idea of a compressed filesystem is based on the compressed virtual disk. That is, you make the disk surface itself look bigger than it really is (through compression) and run the regular BSD filesystem on top of it. Now, when you demand-load an executable, the page request gets mapped to a spot on the virtual disk. The virtual compression driver figures out the location of the physical page, brings it in to a buffer, and decompresses from the buffer into the requested page. Think about demand-loading a binary over NFS. What's the difference (structuarally) between a network protocol stack and a compressor? The virtual block size could be 8K (bigger is better). The underlying physical block ranges from 512 bytes to 8K, depending on the compressability of the contents of the virtual block. A virtual-to-physical block map must be maintained on disk by the virtual compression disk driver. This is not a simple linear mapping - the physical location of a virtual block must be stored in a table. Ideally, the physical location should mirror the logical location so as so minimize seeking when reading contiguous virtual blocks. In addition, the filesystem and virtual disk need to communicate so that minor inconsistencies and gotchas can be resolved. For example, if you write 100 virtual blocks to a disk with 1000 blocks free, do you get 900 blocks left? Perhaps not. If the 1000 free blocks are physical * 8K blocks, then you may get more than 900 free blocks. The effect is that the virtual disk's size can vary over time. The BSD filesystem is meant for fixed-size disks. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 02:45:54 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: nfs server not working X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com starting with vmunix.709, nfs on netbsd stopped working - it no longer allows nfs mounts. I can boot my amiga under vmunix.644 and nfs mounts work properly. Under vmunix 709, 713, and 714, no luck. Here's some info in case it helps someone figure out the problem: / sun# rpcinfo -u amiga0 mount program 100005 version 1 ready and waiting / sun# showmount -e amiga0 export list for amiga0: /usr mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org /tmp mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org /proj mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org /opt mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org /home2 mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org /home mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org / mac.sf-bay.org,mac.sf-bay.org,sun.sf-bay.org,sun.sf-bay.org,dell.sf-bay.org,dell.sf-bay.org / sun# / sun# mount -t nfs amiga0:/usr /mnt mount: amiga0:/usr: Invalid argument mount: giving up on: /mnt / dell# mount -t nfs -av mount: wrong fs type, amiga0:/ already mounted, /net/amiga0 busy, or other error mount: mount point /net/amiga0/usr does not exist mount: mount point /net/amiga0/sbin does not exist mount: mount point /net/amiga0/bin does not exist mount: mount point /net/amiga0/proj does not exist mount: mount point /net/amiga0/opt does not exist / dell# mount -t nfs amiga0:/usr /mnt mount: amiga0:/usr failed, reason given by server: unknown nfs status return value: 22 From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 03:08:02 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: rootfs/networking, gzip filesystem From: mwm@contessa.phone.net (Mike Meyer) Organization: Missionaria Phonibalonica Sender: NetBSD-Admin@cbmuucp.commodore.com > With zlibc, you don't turn it on or off. If you gzip ANY > file you have by hand (your choice to do so) then you may > tell ANY program that is not statically linked (i.e. uses > zlibc) can open/read the gzipped file as if it weren't > compressed. "Tell ANY program..." So how do you tell it whether or not something should be unzipped? In particular, how do you make "cp /tmp/foobar.z ~ftp/pub" not unzip foobar? How does du, dump/restore, etc. work with this? It sounds like doing things like: find . -name '*.c' -print | xargs grep FooBarBaz won't work quite right. on Dec 6 you wrote: >Is anyone working on the install docs? I have started to write an up >to date install document, but I don't want to duplicate anyone else's >efforts. If everyone's happy with me doing it I was also going to >upload an updated, larger rootfs (e.g. 10MB), with bin-bin.tar.gz, >bin-sbin.tar.gz and the bin-newest stuff installed, the networking >disabled, no password for root, etc. etc. Not much help I know, but it >will free the more knowledgeable to work on more useful things. We have a NetBSD FAQ, which goes through the whole installation process. It isn't quite up to date, but I used it to guide my installation and there were only a few minor points which needed to be changed. I emailed the FAQ maintainer about those. It is quite a good document I think... even for the absolute beginner. I mean, the document even describes in detail how to partition your drives and such. Why don't you get in touch with Guenther (s_grau@ira.uka.de). Maybe you have touched some areas in your doc., which might supplement the FAQ. Updating the rootfs is a very good idea (in fact that was one of the "bugs" in the current FAQ). That would be a lot of help for the newcomers, trying to get NetBSD up and running. Actually NetBSD seems to be very easy to install, as it is. Maybe I am just getting more experienced at this, but I had a whole lot more trouble getting Linux up on a 486 (especially the dual boot feature was a pain). >I had thought that 714 had integrated 040 support, but it hangs on my >system (A3000/PPI 040) in 040 mode, although it works fine with the >030. Is this normal? Mine, too. Funny, but I also had the impression that 714 has 040 support build in. We both must have been wrong. :) Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 04:58:31 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: new cc stuff. To: NetBSD-Admin@cbmuucp.commodore.com (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com I am replying to a reply to this message I wish I actaully would receive the original but I have been waiting for 8 hours now I don't think its gonna get here...ugh. > On Dec 6, 5:06pm, olivier lahaye wrote: > > > > Actualy, these beta version (no shared libs) is printing debug informations > > assuming you've launched it from another console. > > it seems that was this debug info which crashes #713 closed ite driver. > > so ite should ignore these message when closed. > > all debug info will be removed in final version. > > You can ru Xbsd like this: > > Xbsd >foo > > or > > Xbsd >/dev/null /* for normal usage */ Maybe the reason I never get letters from the X people is becuase I *never* get letters from the X people :^) I wonder why I haven't received this one yet as it obviously went to the main list. Is this a problem with the mailing list? > > The code will of course be available when it'll be cleaned > > (no debug ErroF, ...) > > You shouldn't blame us for those time delays, because actualy, > > we've got a huge amount of school work (X224 and X225 total rewrite, > > final exams, reports for DecNet (250 pages), report for X224 ... :-((( ) I too have a large amount of school work... and Consultron... and... :^) I know how your feeling :^). This is probably going to be my worst semester in college becuase of all the time I spent on NetBSD, I am not asking for pity however just wanted to let you know. I think its stupid that I let my grades suffer for this project...The problem is I am a programmer---I like to program---so far I *really* like kernel programming and so it drew me away from my school work. Next semseter I have a systems programming (431) class maybe it'll be interesting enough to get me to go :^) Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 05:07:35 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: FAQ/Install, 714 and 040, printer Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 8:18pm, Stefan G. Berg wrote: > >I had thought that 714 had integrated 040 support, but it hangs on my > >system (A3000/PPI 040) in 040 mode, although it works fine with the > >030. Is this normal? > > Mine, too. Funny, but I also had the impression that 714 has 040 > support build in. We both must have been wrong. :) The only source for an 030/040 integrated kernel is from me at the current time. Unfortunately the anonymous ftp site that I keep the current kernels on doesn't appear to be available. I think the next kernel that Markus makes available should contain the 030/040 integrated support (assuming that the 030 still works, since I don't have any way to test it). The 714 kernel is just the 713 with some bug fixes so that X will work on it. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 06:15:56 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A2630 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312061608.AA26374@gemini.oscs.montana.edu> osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > Do you have _scsi_no_dma patched to 1? If not, that is probably where > your problem is. The GVP Series II controller can not DMA into memory > outside the 68000 address space. The next version of the kernel should Not quite true... Series II '030 Accelerator's controller can. It'd be nice not to have to go through bounce buffers when it isn't neccesary. How to tell when it is and when it isn't? Well... I would suggest looking at the autoconfig list. If there is manufacturer 2017 memory starting at >0x00FFFFFF, it's safe to do 32bit DMA. If there isn't 2017 ram in the >24 bit space, it's either not safe or it doesn't matter. (alternately, I suppose you could look at the Mask values in the RDB, or make it binpatchable (blech).). I wish GVP hadn't been so stingy with product numbers... Hmm, come to think of it, that method isn't 100% correct either. If someone has a SII '030 and a plain SII, (do multiple SCSI controllers work anyway?) one needs bounce buffers and the other doesn't... Hmm, maybe we can just get GVP to tell us how THEY tell the difference :-) > automatically supress DMA transfers on the A2091 and GVP11 drivers if the > I/O buffer is not in the 68000 address space. In addition, these drivers > can be configured to use either chip memory or Zorro II memory (if any > Zorro II memory is available and not used to load NetBSD) as a DMA buffer. > Using chip memory works, but seems to disrupt the display a bit. Bounce buffer support is great though! Thanks a lot! -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 06:41:11 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: A2630 Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 7, 12:33am, Ty Sarna wrote: > Not quite true... Series II '030 Accelerator's controller can. It'd be > nice not to have to go through bounce buffers when it isn't neccesary. > How to tell when it is and when it isn't? Well... I would suggest > looking at the autoconfig list. If there is manufacturer 2017 memory > starting at >0x00FFFFFF, it's safe to do 32bit DMA. If there isn't 2017 > ram in the >24 bit space, it's either not safe or it doesn't matter. > (alternately, I suppose you could look at the Mask values in the RDB, or > make it binpatchable (blech).). I think for now it will probably have to be binpatchable :-(. The RDB values wouldn't necessarily indicate anything. The HC8+ card driver will accept any address and handle it correctly. > Hmm, come to think of it, that method isn't 100% correct either. If > someone has a SII '030 and a plain SII, (do multiple SCSI controllers > work anyway?) one needs bounce buffers and the other doesn't... Hmm, > maybe we can just get GVP to tell us how THEY tell the difference :-) I think multiple controllers will work, but I think you would have to configure the kernel to only have support for the GVP controller and specify an entry for each. I'm not real clear on how everything fits together, but it looked like defining one of each for the A3000, A2091, and GVP11 controllers could cause problems if there are two or more of the same controller type. I suspect that GVP may not have a problem telling the controllers apart. When the SII '030 configures, it probably uses the driver from the '030 board. When the Zorro II board configures, it would probably use the driver contained on that board. Not having a GVP '030 board, I can't tell if the driver is exactly the same or not. Michael From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 06:43:05 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1550 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: help! "panic: init died" prob Sender: NetBSD-Admin@cbmuucp.commodore.com I was just installing bin-sbin.tar.z and setting up NetBSD so that it can run in multiuser mode (as described in the FAQ, changing gettytab, passwd, group, etc...) when during the next boot-up of NetBSD, I encountered the following message: WARNING: bad date in battery clock panic: init died hit any key to boot/dump... >syncing disk... done cannot set battery backed up clock dump to dev 401, offset 57584 dump 1 2 3 4 5 6 7 8 ***BOOOM*** I was quite bad, really. My modem LCD display started flickering real bad and the screen went wild (reminded me of some of those cracked games on a C64, when they did their decompression or whatever they did). Anyway, it was the same crash I would get when running "reboot". First: Please somebody tell me that I didn't destroy my AmigaDOS partitions! :-| I checked, but with some 300MB of junk, I obviously couldn't check everything. What does the offset 57584 stand for? If that is a cylinder number, then it would be somewhere in the beginning of my main AmigaDOS partition. I hope not. Second: How can I fix NetBSD? I hope I don't have to redo what I did in the last 57 hours. Thanks again (NetBSD has an awesome support, really :-) Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 07:07:45 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: help! "panic: init died" prob Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 3, 3:49pm, Stefan G. Berg wrote: > dump 1 2 3 4 5 6 7 8 ***BOOOM*** > > > > I was quite bad, really. My modem LCD display started flickering real > bad and the screen went wild (reminded me of some of those cracked > games on a C64, when they did their decompression or whatever they > did). Anyway, it was the same crash I would get when running "reboot". That's not suprising, since a reboot is exactly what it is doing at that point. > First: Please somebody tell me that I didn't destroy my AmigaDOS > partitions! :-| I checked, but with some 300MB of junk, I obviously > couldn't check everything. What does the offset 57584 stand for? If > that is a cylinder number, then it would be somewhere in the beginning > of my main AmigaDOS partition. I hope not. The offset should be the block number where the dump is written to and should be within the swap partition. > Second: How can I fix NetBSD? I hope I don't have to redo what I did > in the last 57 hours. Hmm. The only other time I saw the "init died" panic, the problem appeared to be a memory problem. That panic indicates that the init process exited for some reason. The easiest way I can think of is to create another partition for the initial rootfs, install the rootfs on it, change the old root parition to something else (i.e. BSDG). Then you should be able to boot from the good root filesystem and examing the old one. The quickest thing would be to rename the sbin/init on the original root and copy the /sbin/init on the temporary root. Then reboot AmigaDOS and change back to the original root. That should fix it if the problem is a corrupt /sbin/init file. If you don't have any place to create the second rootfs, and your swap area is big enough, you can temporarily steal space from that partition. If your swap partition is too small and you don't have any other place to get space for a temporary root, it's a little harder. In this case you could mount the root partition on AmigaDOS with the BFFSfilesystem, make a backup of it, then put the original rootfs back on it. If you made a tar backup of the bad root, then you could restore it on NetBSD. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 07:22:30 1993 From: heinz@igd.fhg.de X-Mailer-Igd: ## IGD.FHG.DE ## Mon, 6 Dec 93 12:56:59 +0100 Subject: Re: intalling on a gvp 030 To: mykes@shell.portal.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1164 Sender: NetBSD-Admin@cbmuucp.commodore.com **** **** ****I'm about to install netbsd on a friend's A2000/GVP030 machine and ****I would like to know from someone else who's done it already how to ****name the partitions BSDR, BSDS, BSDA, etc. using faaaastprep. I haven't ****seen faaaastprep in a couple years, but my friend told me that he ****couldn't find any text box in faaastprep that had a hex number in it ****for his partitions other than the "mask" field. Also, he has a toggle ****gadget for file system type that has 3 choices: ofs, ffs, and afs. **** ****Does he have an old version of faaastprep? If he does, would someone ****out there uuencode and mail me a copy of the new faastprep? Or are ****people copying devs:gvpscsi.device to devs:scsi.device and using ****hdtoolbox? (sounds dangerous) ... **** You should try hdtoolbox gvpscsi.device in a shell. I think, it should also work with tooltypes from workbench, but can't remember the exact tooltype. Klaus -- Klaus Heinz * * The amount of intelligence on heinz@igd.fhg.de * * this planet is a constant ; * * the population grows From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 08:11:20 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 859 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Tandberg TDC3600 good for NetBSD? Sender: NetBSD-Admin@cbmuucp.commodore.com asg@world.std.com posted an add for refurbished Tandberg TDC3600 drives for $189 on some Amiga newsgroup. These are SCSI drives which can write 5-6MB/min and store up to 250MB on a DC6250 tape. They supposedly have been tested on an Amiga with Quarterback and BTN driver. This sounds like a pretty good deal to me, does anybody know if I can use that drive with NetBSD? It does mention BSD386/FD and Linux on the compatibility list. BTW, if somebody has a better suggestion for a backup medium, I'm open to suggestions (most critical is the cost for me). Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 08:28:55 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: help! "panic: init died" prob To: NetBSD-Admin@cbmuucp.commodore.com (Stefan G. Berg) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I was just installing bin-sbin.tar.z and setting up NetBSD so that it > can run in multiuser mode (as described in the FAQ, changing gettytab, > passwd, group, etc...) when during the next boot-up of NetBSD, I > encountered the following message: > > WARNING: bad date in battery clock > panic: init died [..] Did you by chance recompile a kernel? If so and it was 709 or less AND you are not using mtk's ``as'' then this will happen. It has to do with PCREL code in locore (icode which exec()'s ``/sbin/init'' will be trying to exec ``bin/init.'') > > Stefan Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 08:46:34 1993 From: Markus Landgraf To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Is there PPP or SLIP? What about networking anyway? Sender: NetBSD-Admin@cbmuucp.commodore.com I have heard something about network support in NetBSD, but I haven't seen anything really. Do we have PPP or SLIP for NetBSD? If so, what would I need to get? You need nothing, You already have all You need. NetBSD has both ppp and slip. I am currently using ppp and that is what You should prefer, too. The central man page about ppp is that of the ppp deamon pppd. BTW PPP works great. I use ftp, nfs and X via PPP connection. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 08:54:14 1993 From: oster@skorpio.usask.ca Subject: Re: zlibc To: NetBSD-Amiga@cbmuucp.commodore.com X-Envelope-To: NetBSD-Amiga@cbmuucp.commodore.com Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com On Mon, 6 Dec 93 14:11 PST mykes@shell.portal.com said: > >>>>> mtk == mw@eunet.ch (Markus Wild) wrote: > > > Time to pass another linux-ism by everyone, particularly > > mtk... especially now that we will soon be having shared > > libs. > > mtk> Well, if this is linux-ism, it sure shows why I don't > mtk> like linux.. > > > However, to make this REALLY perfect, you would want to be > > able to run the foo.z program. This requires a change to > > the kernel loader to load gzipped bins. The advantage of > > this? It would allow us to gzip compress all of /usr/bin > > all of /usr/local/bin, all of /usr/bin/X and so on. The > > result is FAR LESS disk space requirements for the > > binaries. That 8M rootfs partition would be half full > > instead of too small :-) This all sounds reasonable at first but.... (see later...) > mtk> Just to give you some backgrounds on WHY I hate this > mtk> idea.. > > mtk> Unix fs is based on a quite interesting scheme of demand > mtk> loading executables. This means, starting an executable > mtk> means to tell the memory system, where IN THEORY the > mtk> disk blocks pertaining to the executable would wind up > mtk> in memory. However, *no* information is transferred from > mtk> disk to memory yet. Instead, the program is started, > mtk> causing page faults along the way, thus only loading > mtk> what it really uses. Shared libraries work in exactly > mtk> the same way. Now, suppose you have all the files > mtk> compressed. Every open would then require reading (and > mtk> uncompressing) whole files, no matter whether it's only > mtk> the first two bytes I'm interested in, it would > mtk> uncompress the whole 2 Megs or so. If you do this on a > mtk> poorly powered A500, with a 68000 and the xpk > mtk> filesystem, I can somewhat understand why you're doing > mtk> it. However, if you do this to a fast machine that is > mtk> able to even run a Unix system, well, then I just can't > mtk> understand why you're running unix at all.. I certainly see your point Markus. When I first read about the proposed change, I thought it sounded kinda neat, but all this talking about it has gotten me thinking (horrors! :-) ) and now I have to agree with you (Markus (mtk)). > mtk: if what I propose is implemented, ONLY the binaries > and ONLY those binaries that you by hand run gzip on must > be uncompressed as you describe. And even if you DID > decompress a binary, you would do so to /tmp or someplace > like that and do your demand loading from there. Ok.. this is where I got doing some thinking about this. How much to you have to "bloat" /tmp so that it can hold everything that you are currently running? For example, if you have only 4 megs of fast ram, you have only 8 megs of swap, and you therefore need *at least* 12 megs in /tmp to hold the uncompressed versions of everything that you might want loaded into memory (note: the 12 meg figure doesn't allow for the fact that the executables are demand paged, and if you only load some fraction of the total pages of a program, you'll certainly need more than just 12Meg). Sure you might save some space in physical storage, but don't you just push part of the problem to /tmp? Maybe you just have to be able to afford to have a much bigger /tmp (i.e. bigger than your /swap so that the demand paging will actually be useful)? On another train of thought: would this type of system be smart enough to re-use an xterm that it uncompressed a while ago? If so, it would need some way to know when it could get rid of the xterm from /tmp..... I guess one would just never compress those programs you used the most often, because under this scheme you'd certainly end up loosing disk space... (in the end, you need sizeof(uncompressed_program) + sizeof(compressed_program) for each program you run...) > The issue is not the speed of the CPU, it is the cost of > drive space. Some people either have only 400M drives, > which is a nice sized bsd setup - BUT they insist on > keeping 150M of it for amigaos. Or if you want to keep > the sunlamp tree and kernel sources and objects - you need > even MORE hard drive space. Other people are like me and > simply don't want to add a hard drive to run netbsd - I've > seen MANY people say "forget it" when they hear the disk > requirement for netbsd. Many many amiga users are europeon > university students who simply don't have the money to > spend on hard drives. > > Keep this in mind, markus - I have 3 gig of hard disk, > and I probably can care less to use this feature. It isn't > for me, but for others I know can take advantage of it. An honourable thought :-) Seriously: people without the resources (like I was some time ago) are quite thankful that the developers are thinking about them. > > I am proposing is quite similar. Unlike xfh, the entire > > netbsd filesystem is compressable/decompressable. xfh > > mtk> Sure.. listen. If you want to distribute such a thing, > mtk> go ahead. Just make sure I don't have absolutely no, > mtk> none at all, really no, relations to it... > > No, markus. I won't go near it if you won't. I'm not > going to spring something on the netbsd world you've > made for everyone. It's your football, and you can take > it home with you so nobody else can play. I just offered an idea - > a good idea. I'm certainly glad that you offered the idea - if no-one presents ideas, then we make no progress. I don't feel, however, that this idea is something we want to see in a "general" NetBSD (or any other unix...) > > comments? mtk: I already know you don't like it (too much > > like linux :-) > > mtk> Bull.. I stated why I don't like it, and I wouldn't like > mtk> it being added to any default distribution for Linux, > mtk> either... > > The one for linux ONLY does gzip decompression for reading > purposes. It does NOT do loading of gzipped binary Ahh.. ok.. that might explain why it is actually working reasonably well there... I can see gzip decompression being somewhat desirable for datafiles that you are going to be reading sequentially, but not for executables. > executables nor does it gzip compress when writing. > Among the linux community it is VERY VERY popular. There :-) 386 processors are popular among Linux people too :-) (No offense to those working on porting Linux to other architectures -- I just wanted to point out that popularity does not always equal "good" (that, and get a dig in against Intel :-) )) > are people with 60 whole megabytes of hard disk running > linux and X and they compress everything they can to > make the system usable. Yup, and I think it's great that they are able to run in that small of space. > No, netbsd is NOT linux. It doesn't have to have all the good > things we or others can think of putting in. It doesn't make the > ideas bad ones. You are quite correct here. Just because something is from Linux doesn't inherently make it bad. However: because (as you said) NetBSD is not Linux, we should examine those ideas closely to see if they would provide a real benefit. > mtk> -Markus > mtk> -- > mtk> CHUUG/EUnet Switzerland Markus Wild > mtk> Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch > mtk> CH-8004 Zuerich Fax: +41 1 291 46 42 > mtk> S=mw;P=EUnet;A=EUnet;C=CH Just my $0.02 (CDN) Hope I'm not too far out to lunch... Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 11:05:47 1993 From: niklas@appli.se (Niklas Hallqvist) To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Is there PPP or SLIP? What about networking anyway? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Stefan" == Stefan G Berg writes: Stefan> I have heard something about network support in NetBSD, but I Stefan> haven't seen anything really. Do we have PPP or SLIP for Stefan> NetBSD? If so, what would I need to get? This should be in the FAQ! Someone posted an excellent "get SLIP running" text a month or so ago. At least MTK himself runs PPP, maybe he can tell us what is needed for that. I can only answer your question regarding SLIP: You don't need *any* extras! Briefly the steps are: 1 Dialup (and maybe login to) a SLIP port (kermit is a good way to do this). 2 slattach -a -h -s 38400 //dev/tty00 3 ifconfig sl0 LOCAL-IP-ADDR REMOTE-IP-ADDR -arp -trailers up 4 route add 0.0.0.0 REMOTE-IP-ADDR Niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 12:19:28 1993 To: "NetBSD-Amiga" From: "Matthias Scheler" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: IntuiNews 3.141592654 (Right Now) Subject: NetBSD on A4000/040 Organization: Amiga User Group University Paderborn Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, what about running NetBSD on an A4000/040 ? Has anyboday written a driver for the internal IDE hostadapter or even better for the Z3-Fastlane ? -- Matthias Scheler tron@lyssa.pb.owl.de From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 12:34:03 1993 Subject: Equipping an A1200 for NetBSD To: NetBSD-Amiga@cbmuucp.commodore.com From: David MacKinnon X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1093 Sender: NetBSD-Admin@cbmuucp.commodore.com I've been looking at equipping my 1200 for use with netbsd, and was looking for some advice for what hardware to purchase :-) Speedwise how would NetBSD be on a 33Mhz '030, or is a 50Mhz a great boon and definately worth the money? Also, is anybody working on a driver for the IDE controller in the 1200/4000, or should i spend some extra money for a SCSI controller. (Would I really be in a better position for driver support?) YAQ, is anybody looking at having X-Windows or even the shell run in a 31Khz mode rather than PAL or NTSC interlaced? :-) How hard would such an addition be? How would NetBSD react to PCMCIA devices? They would need a special driver I take it? And, finally, can 4megs fast/2megs chip RAM run NetBSD, or is 8megs really needed to be of any use? I've probably forgotten a few things along the way, but that's the basics Any help or advice would be greatly appreciated. (And yes, I considered buying a second-hand 3000, but they aren't all that common, and by the time i got it equipped it would be well beyond my price range) -David (davidm@it.com.au) From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 13:01:11 1993 From: niklas@appli.se (Niklas Hallqvist) To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Tandberg TDC3600 good for NetBSD? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Stefan" == Stefan G Berg writes: Stefan> asg@world.std.com posted an add for refurbished Tandberg Stefan> TDC3600 drives for $189 on some Amiga newsgroup. These are Stefan> SCSI drives which can write 5-6MB/min and store up to 250MB on Stefan> a DC6250 tape. They supposedly have been tested on an Amiga Stefan> with Quarterback and BTN driver. This sounds like a pretty Stefan> good deal to me, does anybody know if I can use that drive Stefan> with NetBSD? It does mention BSD386/FD and Linux on the Stefan> compatibility list. It sounds standard enough as it works with both QB & BTN. I don't know if anyone has tested this drive on NetBSD, but if it won't work with the default kernel, it's not hard to add support (if you can compile your own kernel, that is). I'm 99.9% sure you (possibly with help from the list) can get it to work. However I make no promises. MTK: How about some binpatch-able default tape-parameters? It would make things easier for those who need to fine-tune tape characteristics. Maybe it's already possible, I haven't checked lately. Niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 13:35:54 1993 From: Alain Chofardet Subject: A2630 To: NetBSD-Amiga@cbmuucp.commodore.com (ML NetBSD) Mailer: Elm [revision: 72.14] Sender: NetBSD-Admin@cbmuucp.commodore.com Once again... I had mail problems yesterday. Hi. I tried to boot NetBSD on my A2000 last week-end; there is several problems for me. First, I have problems with memory tests : my A2630 has 2Meg autoconfig on the board, and I have a DKB2632 memory expansion on it (4Meg). The DKB2632 isn't autoconfig but starts at 0x7c00000. The 713 kernel do recognize it but assumes running on an A3000. To solve the problem, this is my proposition on 713 sources (Markus) : Modify sys/arch/amiga/amiga/autoconf.c like that 730a731 > case PROD_GVP_SERIES_I : 1071a1073,1077 > case MANUF_CBM_2: > switch (cd->cd_Rom.er_Product) { > case PROD_CBM_2_A2630: > return (0); /* A2630 - Accelerator Card for A2000 */ > } and sys/arch/amiga/dev/device.h 108a109 > #define PROD_CBM_2_A2630 81 124a126 > #define PROD_GVP_SERIES_I 3 Moreover, my GVP Series I SCSI controller is going to make me crazy. A friend of mine lent me a GVP Series II. I found big problems using FaaastPrep to configure BSD partitions; it seems not to work as HDToolBox. Finally, I succeed in making the kernel recognize BSD partitions, but the kernel didn't go further. This is an approximate copy of the screen when it crashed : NetBSD 0.9 (713) (...) realmem 4194304 availmem 1761280 RealtimeClock A2000 rtclock0 par0 grf0 grf0 grf0 grf1 (retina) grf1 dma0 : GVPII DMA scsi0: SCSI id 7 GVPIIscsi0 sd0:QUANTUM ... sd0 at GVPIIscsi0, slave 0 sd1:SYQUEST SQ555 ... sd1 at GVPIIscsi0, slave 1 Changing root device to sd1a bpf:sl0 attached bpf:ppp0 attached bpf:lo0 attached panic : cannot mount root And we stops there. When I hit a key, the kernel dumps to the Syquest... Any idea, assuming it is possible my install isn't clean ? Thanks. Alain. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 14:02:01 1993 From: niklas@appli.se (Niklas Hallqvist) To: tron@lyssa.pb.owl.de Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: NetBSD on A4000/040 Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Matthias" == Matthias Scheler writes: Matthias> what about running NetBSD on an A4000/040 ? Has anyboday Matthias> written a driver for the internal IDE hostadapter or even Matthias> better for the Z3-Fastlane ? I don't know the answers to Matthias' questions, but I have a related question. Wasn't there someone that was compiling a compatibility list for NetBSD, i.e. what hardware had been tested? Together with the FAQ this could bring down the list's volume quite a bit I think. BTW. Who is maintaining the FAQ these days? How often is it planned to send it to the mailing list? Do new subscribers get a free copy when subscribing? These may be FAQ's I know :-) but I have *already* wasted bandwitdh. Niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 15:25:14 1993 From: dvb@ssd.kodak.com (Dave Blaszyk) To: billc@icecube.rain.com Cc: ghost@cs.tu-berlin.de, netbsd-amiga@cbmuucp.commodore.com Subject: Re: supra controller ?! Content-Length: 0 Sender: NetBSD-Admin@cbmuucp.commodore.com I would be very much interested in this code, as I am "working" on the IVS Vector SCSI support. Please send me more information about this code. -dvb- /-// \\-\Dave Blaszyk e-mail : dvb@ssd.kodak.com /-//\ /\\-\(716) 253-7953 mail : Eastman Kodak ///d// \\v// \\b\\\ C Plant, Bldg. 10 MC 39011 \\\// \// \\/// Rochester, New York 14620 From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 15:55:26 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: /dev/view To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com If anyone is curious abou tthis /dev/view I have been talking about there is a neat progrma in incoming/views-try2.tar.gz that has a program and source that gives a nice demo. Warning though the current kernel doesn't have views enabled, so changes are nec. markus changed a few things when he grafted my code for 713 not his fault just a mistake. I sent him mail so it may get fixed for the next kernel... in the mean time instructions are included for the few (minimal) changes nec. to get it to work. The program only displays patterns and color so don't go through the trouble if this won't impress you :^) The X people should get this however as an example on how to use the /dev/view interface. Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 15:55:41 1993 From: Arthur Hoffmann Subject: new cc stuff. To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1226 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I just downloaded and installed the new cc-stuff. I'm impressed :) Great work! I still have some questions about it. When I start up NetBSD (with the cc-stuff) the console looks a bit strange: background colour is Black, writing is purple, except for underscores and minus symbols, they are green, the coursor is Yellow and all the letters are very smeary. There are 100 ! lines of text displayed with no overscan. The writing is really hard to read, (small & smeary), but I could manage to decipher the help messages of iteconfig -h :) . Now for the first Time all my monitor is used 70 lines 90 charcacters wide. :-) Now I would like to know where in the kernel sources I need to do what in order to make the kernel come up wiht the iteconfig settings. At the moment I added a line to /etc/rc saying: iteconfig -X 2 -Y-2 -H 560 -W 724 This works fine for the current kernel, but when I use an older kernel (709 for X) I need to comment out that line. Thanks for any help. btw. I don't know what I need to do to get X to work on 713. Several people mentioned to start it like Xbsd >/dev/null, but my system still panics. What's the trick? Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 16:06:12 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: new cc stuff. To: NetBSD-Admin@cbmuucp.commodore.com (Arthur Hoffmann) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hi, > I just downloaded and installed the new cc-stuff. > I'm impressed :) Great work! Thanks :^) > > I still have some questions about it. > When I start up NetBSD (with the cc-stuff) the console looks > a bit strange: > background colour is Black, writing is purple, except for > underscores and minus symbols, they are green, the coursor > is Yellow and all the letters are very smeary. > There are 100 ! lines of text displayed with no overscan. > The writing is really hard to read, (small & smeary), but > I could manage to decipher the help messages of iteconfig -h > :) . Now for the first Time all my monitor is used 70 lines > 90 charcacters wide. :-) Oh dear it seems that you may be booting into the 640x800 2024 mode but you don't have a 2024 :^) you probably want to examine _ite_default_height if its 800 then change it to 400 (or whatever you want by default) The only reason this would happen is if GRF_A2024 was enable when the kernel was compiled... I wonder... ANyway it shouldn't have been. > Now I would like to know where in the kernel sources I need to > do what in order to make the kernel come up wiht the > iteconfig settings. At the moment I added a line to > /etc/rc saying: > iteconfig -X 2 -Y-2 -H 560 -W 724 > This works fine for the current kernel, but when I use an older > kernel (709 for X) I need to comment out that line. as above either recompile without the option GRF_A2024 (in amiga/conf/[SYSTEM]) or binpatch _ite_default_height. ite_default_height ite_default_width ite_default_depth, are the booting defaults BTW. they are in ite_cc.c > Thanks for any help. > > btw. I don't know what I need to do to get X to work on 713. > Several people mentioned to start it like Xbsd >/dev/null, but > my system still panics. What's the trick? I think you need the 714 kernel, but then my patches will go away :^) (there is no source for 714 so I can't help.) > Arthur. > > Arthur Hoffmann > hoffmann@nutmeg.ntu.edu.au Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 16:45:14 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 8, 12:20am, Arthur Hoffmann wrote: > I still have some questions about it. > When I start up NetBSD (with the cc-stuff) the console looks > a bit strange: > background colour is Black, writing is purple, except for > underscores and minus symbols, they are green, the coursor > is Yellow and all the letters are very smeary. > There are 100 ! lines of text displayed with no overscan. > The writing is really hard to read, (small & smeary), but > I could manage to decipher the help messages of iteconfig -h > :) . Now for the first Time all my monitor is used 70 lines > 90 charcacters wide. :-) I noticed the same thing. > Now I would like to know where in the kernel sources I need to > do what in order to make the kernel come up wiht the > iteconfig settings. At the moment I added a line to I think the problem is that the ite driver defaults now use the A2024 setting - which is 800 lines. I binpatched _ite_default_height to 400 and got back a "normal" screen (except that it seems to be only 79 characters wide instead of 80). Now I just need to figure out why I don't get my screen display when I start X11R5. > btw. I don't know what I need to do to get X to work on 713. > Several people mentioned to start it like Xbsd >/dev/null, but > my system still panics. What's the trick? There is a bug in 713 that was fixed in 714. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 16:54:40 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 7, 9:59am, Chris Hopps wrote: > Oh dear it seems that you may be booting into the 640x800 2024 mode > but you don't have a 2024 :^) you probably want to examine > _ite_default_height if its 800 then change it to 400 (or whatever you > want by default) > > The only reason this would happen is if GRF_A2024 was enable when the > kernel was compiled... I wonder... ANyway it shouldn't have been. I first tried configuring without GRF_A2024 and ended up with a number of references to undefined symbols. I haven't looked into why yet, I just changed the ite_default_height for the A2024 entry. I think the cc code is missing some #ifdef statements for some of the various graphics options. Michael From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 16:55:15 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: new cc stuff. To: NetBSD-Admin@cbmuucp.commodore.com (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I think the problem is that the ite driver defaults now use the A2024 > setting - which is 800 lines. I binpatched _ite_default_height to 400 and > got back a "normal" screen (except that it seems to be only 79 characters > wide instead of 80). This only happens if the kernel was compiled with the GRF_A2024 option it seems it was if it happened to you too. > > Michael Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 17:06:55 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: new cc stuff. To: NetBSD-Admin@cbmuucp.commodore.com (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Dec 7, 9:59am, Chris Hopps wrote: > > Oh dear it seems that you may be booting into the 640x800 2024 mode > > but you don't have a 2024 :^) you probably want to examine > > _ite_default_height if its 800 then change it to 400 (or whatever you > > want by default) > > > > The only reason this would happen is if GRF_A2024 was enable when the > > kernel was compiled... I wonder... ANyway it shouldn't have been. > > I first tried configuring without GRF_A2024 and ended up with a number > of references to undefined symbols. I haven't looked into why yet, I > just changed the ite_default_height for the A2024 entry. I think the > cc code is missing some #ifdef statements for some of the various graphics > options. Ah that would probably be in grf_cc_?dl_mode.c or grf_cc_a2024_mode.c I will check it out. You should have sent me a note complaining :^) The kernel will probably shrink a few K without GRF_A2024... > > Michael > Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 17:11:37 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 954 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: vipw complains that :up=: is missing in termcap Sender: NetBSD-Admin@cbmuucp.commodore.com The vipw commands doesn't start up. It complains that my termcap is missing a :up=" feature. I got my termcap from the bin-usr.share.tar.gz file on eunet. Should I get a different termcap from somewhere? I got my init crash fixed. I noticed that I must have moved the whole /sbin directory over to another partition yesterday night (hgrm... morning). No wonder that I couldn't boot anymore. :) Stefan P.S. If somebody would just cut and paste all my questions into our current FAQ, we probably would have a pretty complete document RSN. What about it? Should I just go ahead and do it myself? Do we have somebody actively maintaining the FAQ at the moment? ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 18:37:07 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1759 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: FAQ/Install, 714 and 040, printer Sender: NetBSD-Admin@cbmuucp.commodore.com Hi David (David Crooke), in <14161.9312071253@barley.dcs.ed.ac.uk> on Dec 7 you wrote: >It took me 3 or 4 tries to figure out all the inconsistencies, e.g. >files called "bin-usr.bin.tar.gz and not usrbin.tgz", files not >mentioned that you need, rebuilding rootfs, bigger /usr needed. The >very fact that Guenther has not replied to my messages in the mailing >list and that the "FAQ" (it is really an install document) hasn't been >updated in 6 months would seem to indicate that he's too busy to do it >just now. Yes, there are a few bugs in it. Well, maybe you are right that we need to revise/replace it. And yes, the FAQ has only a few frequently asked questions at the end, so it is more like an installation document for now. But I think that is ok at least as long as it is still a fairly small file. >I'll mail Guenther and see what he's up to - failing any requests to >the contrary I will go ahead. He actually sent me a copy of the latest FAQ, but maybe you are right, that he is too busy at the moment to work on it. I haven't heard from him either, since then. I think a lot of the questions I have asked recently should go into the FAQ (actually a couple people mentioned that). I don't store too much old email on my computer, but I can go back and save whatever there is left of my old questions. The big question now is, if Guenther is/can still maintaining the FAQ. At the moment we don't even have a current copy at ftp.eunet.ch. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 19:31:06 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: Latest versions to use???" (Dec 6, 8:13am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mykes@shell.portal.com Subject: rootfs (Re: Latest versions to use???) Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 6, 8:13am, mykes@shell.portal.com wrote: > Let me cast a MAJOR NEGATIVE vote to this approach. Even > if you don't have slip or a network, there are reasons to > still have networking installed. Term is one such program. > It is the next best thing to SLIP, and if you are going > to modem to the internet from your netbsd machine, you > will WANT to use term (trust me :-) And it requires > the networking stuff installed. The networking stuff > is SMALL and there's no reason to not include it in the > rootfs distribution. I have been thinking about this and other problems which may occure when you have no network stuff at all, and finally beleive it for myself that it's nonsense to have such an approach. Not only term (what a woderfull programm, indeed; irc typing at HOME, not remotly, no slow-slip, no un-understandable ppp :) is a reason to leave the network stuff in the rootfs; also simple stuff like telnet, rsh, and so on are sometimes even required on a stand-alone machine. Thus: Make it one rootfs, but have a decent, nicely behaving and easy to handle /etc/rc. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 20:03:38 1993 From: Roy Trevino To: netbsd-amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: Tandberg TDC3600 good for NetBSD? Sender: NetBSD-Admin@cbmuucp.commodore.com sgberg@charon.bloomington.in.us writes: > > asg@world.std.com posted an add for refurbished Tandberg TDC3600 > drives for $189 on some Amiga newsgroup. These are SCSI drives which > can write 5-6MB/min and store up to 250MB on a DC6250 tape. They > ... > supposedly have been tested on an Amiga with Quarterback and BTN > driver. This sounds like a pretty good deal to me, does anybody know > if I can use that drive with NetBSD? It does mention BSD386/FD and > Linux on the compatibility list. I bought this same model drive from this same exact person. It worked great for AmigaDOS using either BTN or ScsiTape (ff791). Then when NetBSD came along I used it extensively for all those big tar files on eunet with no problems. This is on an A3000T internal scsi controller. But here's the catch - It worked great for the 644 kernel, while my CDROM did not. But for 709, it strangely would not back up anymore - only restore. However, my CDROM magically started working. I think it has to do with sync mode being disabled for 709 by default but enabled in 644 by default. Perhaps one needs sync and the other needs no sync. Or maybe something to do with dma. I was just too lazy to figure it out just yet - I just use 644 for backups still ;-). Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 20:18:21 1993 From: niklas@appli.se (Niklas Hallqvist) Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: new cc stuff. + gdb question Sender: NetBSD-Admin@cbmuucp.commodore.com I still have a problem I've had all the time with Chopps cc code. It won't switch between PAL and NTSC on my OCS A2000. What I choose in ADOS before loading BSD will remain until I reboot. It would be real nice to be able to switch the mode to NTSC after a few hours in front of the shakey PAL screen. GDB (the latest version on eunet) segfaults for me after a trapsignal(76, 11, -1, ffffff, d4a6e) or similar. Yes, I have patched my kernel source and recompiled. Anyone else seen this? Niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 20:22:50 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: Re: zlibc To: mykes@shell.portal.com Cc: dej@eecg.toronto.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1685 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > >>>>> dj == David Jones wrote: > > dj> One question: Why has no one proposed a compressed > dj> filesystem? > > My zlib suggestion is pretty much a compressed filesystem. > I don't think you want an entire filesystem compressed > though. What I do think you want is something like the > way manpages work - they are kept in compressed form > in /usr/man/cat1 and are uncompressed when you want to > read them to /usr/man/man1 (well, bsd man may not work > exactly like this, but the idea is what's important). > There's likely to be a huge percentage of manpages that > you never read at all (or only once in a great while) - > keeping these uncompressed all the time is just a waste > of space. Deleting them means you don't have them when > you want them. > > My suggestion for loading binaries would actually be easy > to implement in a shell (as opposed to on the kernel > level). The shell would maintain a dir of uncompressed > bins and compressed ones. When you run a compressed bin, > it would uncompress it to the uncompressed subdir, make a > link to the uncompressed bin, and then do system() or > exec() on the program. Grab the gzip sources from prep.ai.mit.edu or one of its mirrors. It has a program you can run on executables to compress them and make them uncompress themselves on the fly. It requires no changes to anything else. If you can live with the performance penalty, this is certainly the simplest solution. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 21:27:35 1993 Subject: Files needed? To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] From: atle schulstad Sender: atle.schulstad@hedmarkdh.no Sender: NetBSD-Admin@cbmuucp.commodore.com Hi! I have finally decided to try and install NETBSD. BUT the current FAQ seems to be a bit outdated, so what are the files I need to run BSD MINUMUM. I allready have: bin-usr.sbin.tar.gz bin-usr.bin.tar.gz bin-usr.gnu.tar.gz rootfs.gz Is there a new FAQ somewhere? Cheers, Atle. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:04:07 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: FAQ/Install, 714 and 040, printer To: David.Crooke@dcs.edinburgh.ac.uk Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1516 Sender: NetBSD-Admin@cbmuucp.commodore.com > Is anyone working on the install docs? I have started to write an up > to date install document, but I don't want to duplicate anyone else's > efforts. If everyone's happy with me doing it I was also going to I appreciate any efforts to provide more documentation, since I really hate to write docs, but I don't know about all currently active doc writers. I think there are quite a few of them (FAQ maintainers, man page writers, etc). I'd really like to thank you people! > upload an updated, larger rootfs (e.g. 10MB), with bin-bin.tar.gz, > bin-sbin.tar.gz and the bin-newest stuff installed, the networking > disabled, no password for root, etc. etc. Not much help I know, but it > will free the more knowledgeable to work on more useful things. Perhaps wait for the new set of binaries? I really hope to upload them this week.. > I had thought that 714 had integrated 040 support, but it hangs on my > system (A3000/PPI 040) in 040 mode, although it works fine with the > 030. Is this normal? Nope, 714 was just a quick bug fix release since 713 had absolutely broken X-support.. I'm right now running a unified kernel thanks to the recent patches Mike Hitch sent me (it runs on my '30, I guess it also runs on Mike's '40, so that's a nice, all in one kernel again). Only problem right now on the '30 at least is, it doesn't reboot :-( -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:09:09 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Is there PPP or SLIP? What about networking anyway? To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 739 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have heard something about network support in NetBSD, but I haven't > seen anything really. Do we have PPP or SLIP for NetBSD? If so, what > would I need to get? Both work fine. I don't remember exactly whether both the pppd and chat binaries were included in the last bin-dist, they sure will be in the next release. I've used ppp extensively, and I have to rate it very reliable. The new release will include the new 2.0a pppd, which amazingly fixed a problem I encountered with our local Livingstone terminal server, causing spuriose drops in transmission thruput. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:11:03 1993 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: FAQ/Install, 714 and 040, printer To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 982 Sender: NetBSD-Admin@cbmuucp.commodore.com > >It took me 3 or 4 tries to figure out all the inconsistencies, e.g. > >files called "bin-usr.bin.tar.gz and not usrbin.tgz", files not > >mentioned that you need, rebuilding rootfs, bigger /usr needed. I just found, that the bin-usr.include (or something like that) called package in newest binary packages contain some links to /home disk. For example: lrwxrwxrwx 1 root 21 Nov 28 18:58 net@ -> /home/usr/src/sys/net lrwxrwxrwx 1 root 26 Nov 28 18:58 netccitt@ -> /home/usr/src/sys/netccitt -rw-rw-r-- 1 root 4606 Mar 21 1993 netdb.h lrwxrwxrwx 1 root 25 Nov 28 18:58 netinet@ -> /home/usr/src/sys/netinet lrwxrwxrwx 1 root 24 Nov 28 18:58 netiso@ -> /home/usr/src/sys/netiso lrwxrwxrwx 1 root 23 Nov 28 18:58 netns@ -> /home/usr/src/sys/netns The thing is, that my kernel sources are in /usr/src, not /home/usr/src.. Just to overcome this problem, I created a liink "ln -s /usr" to /home. ++Tero From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:19:04 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: help! "panic: init died" prob To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1715 Sender: NetBSD-Admin@cbmuucp.commodore.com > I was just installing bin-sbin.tar.z and setting up NetBSD so that it > can run in multiuser mode (as described in the FAQ, changing gettytab, > passwd, group, etc...) when during the next boot-up of NetBSD, I > encountered the following message: > > WARNING: bad date in battery clock > panic: init died > hit any key to boot/dump... > >syncing disk... done > cannot set battery backed up clock > dump to dev 401, offset 57584 > dump 1 2 3 4 5 6 7 8 ***BOOOM*** > > Hmm.. did you got something wrong installing the new /sbin/init, for example? What type of amiga are you using, that the realtime-clock isn't readable? BTW: the offset indicated above is a block offset into your swap-partition. The dumper tries to deposit its droppings (:-)) at the far end of the swap partition, so as to have a chance of the dump surviving reboot, so it can be stored to disk with savecore. > First: Please somebody tell me that I didn't destroy my AmigaDOS > partitions! :-| I checked, but with some 300MB of junk, I obviously Should not be possible (hey, I can't give you any warranties, but I'd be fairly confident if it was my drive, ie. I wouldn't get out my backup tapes...). > Second: How can I fix NetBSD? I hope I don't have to redo what I did > in the last 57 hours. Hm, I fear you either have to reinstall the old rootfs, or mount a temporary other partition as rootfs (just fiddle with the disk types in hdtoolbox). Then take a look at what you did to poor /sbin/init... :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:38:43 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1583 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: NetBSD now thinks my A500 is an A3000. Sender: NetBSD-Admin@cbmuucp.commodore.com I set a couple jumpers on my GVP Series II controller to disable the 8MB of 16 bit Fast RAM. I just wanted to get the taste of NetBSD running on my PPI040 at full speed (using the 4MB of 32 bit RAM). Well, whereas previously NetBSD thought that I have an A2000 with a ZEUS card I believe, it now thinks that I have an A3000 with an A3000 internal SCSI controller (at which point it just hangs). Being a now-nothing, I really wouldn't know how to fix this by compiling my own kernel (I hope to learn though). Can somebody maybe add proper detection for the PPI accelerator or possibly the Series II controller? ShowConfig reports the following for my system: PROCESSOR: CPU 68040/68882fpu CUSTOM CHIPS: ECS PAL Agnus (id=$0020), ECS Denise (id=$00fc) VERS: Kickstart version 37.175, Exec version 37.132, Disk version 38.30 RAM: Node type $a, Attributes $5 (FAST), at $8000000-$83fffff (4.0 meg) Node type $a, Attributes $205 (FAST), at $200000-$9fffff (8.0 meg) Node type $a, Attributes $303 (CHIP), at $400-$1fffff (~2.0 meg) BOARDS: Board (unidentified): Prod=2026/187($7ea/$bb) (@$e90000 64K) <-PPI Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$ea0000 64K) RAM (unidentified): Prod=2017/10($7e1/$a) (@$200000 8meg Mem) Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 22:57:38 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: zlibc To: oster@skorpio.usask.ca Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 4538 Sender: NetBSD-Admin@cbmuucp.commodore.com > > mtk> it. However, if you do this to a fast machine that is > > mtk> able to even run a Unix system, well, then I just can't > > mtk> understand why you're running unix at all.. > > I certainly see your point Markus. When I first read about the > proposed change, I thought it sounded kinda neat, but all this talking > about it has gotten me thinking (horrors! :-) ) and now I have to > agree with you (Markus (mtk)). Glad we're leaving the emotional ground to more reasoning :-) > How much to you have to "bloat" /tmp so that it can hold everything > that you are currently running? For example, if you have only 4 megs > of fast ram, you have only 8 megs of swap, and you therefore need *at > least* 12 megs in /tmp to hold the uncompressed versions of everything > that you might want loaded into memory (note: the 12 meg figure > doesn't allow for the fact that the executables are demand paged, and > if you only load some fraction of the total pages of a program, you'll > certainly need more than just 12Meg). The problem gets even more absurd if you take into account shared libraries. Considering that most of the binaries, that now are taking up considerable space, will shrink quite noticeably, the space gained by compression gets smaller and smaller. I think there once was a comparision of "ls" linked dynamically under SunOS, compared to "our" NetBSD ls. Although ls, being in /bin, is still statically linked, I did a dynamic link to compare sizes, here's what I got: text data bss dec hex 16384 8192 0 24576 6000 ls.shared 106496 8192 5956 120644 1d744 /bin/ls For many X-programs, results will probably look even more drastic, as they usually just set up some widgets and then wait in the event loop, with most of the code being in the shared libraries. > On another train of thought: would this type of system be smart enough > to re-use an xterm that it uncompressed a while ago? If so, it would Probably not without kernel support, or a *VERY* sophisticated runtime loading system, keeping sort of a shared cache of executables (all adding up to disk space...). > > The issue is not the speed of the CPU, it is the cost of > > drive space. Some people either have only 400M drives, > > which is a nice sized bsd setup - BUT they insist on > > keeping 150M of it for amigaos. Or if you want to keep > > An honourable thought :-) Seriously: people without the resources > (like I was some time ago) are quite thankful that the developers are > thinking about them. I'd think providing support to handle compressed data to some very SPECIFIC programs would be a much better idea. Man pages come to mind, there really should be a better man command for BSD (and one that doesn't suffer from a GNU copyleft:-)). As an alternative that I use quite often to compressing stuff, is to put things I really only use once in a year or two, out to tape. Have a games tape. Have a tape of your X11-source tree. There's really no reason to have the complete MIT sources on your drive, once the whole system is running stable. Put them on tape, and get them back if you want to apply any patches, for example, then put them back. > Ahh.. ok.. that might explain why it is actually working reasonably > well there... I can see gzip decompression being somewhat desirable > for datafiles that you are going to be reading sequentially, but not > for executables. I'd still prefer to have this capability in the respective application, not kludged into the open call of a shared library. There could be a shared library to implement easy, transparent opening of compressed files. Applications could then use functions from that library to access files, instead of using plain open(). Doing it this way would prevent us from "cp foo.z /tmp" decompressing foo.. Another idea, for those that absolute must have compressed executables: how about writing some SFX like loader, that you paste in front of compressed executables? Would just uncompress the binary and run it. If you put the loader into an external shared object (similar to ld.so) you could also maintain a cache of executables, so they only have to be uncompressed once (and could perhaps be dynamically flushed again, if space for the executable cache is exceeded?). I'm not saying I'll implement this, just showing there'd really be better approaches than to hack libc.so... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:04:26 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Tandberg TDC3600 good for NetBSD? To: niklas@appli.se (Niklas Hallqvist) Cc: sgberg@charon.bloomington.in.us, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 609 Sender: NetBSD-Admin@cbmuucp.commodore.com > MTK: How about some binpatch-able default tape-parameters? It would > make things easier for those who need to fine-tune tape characteristics. > Maybe it's already possible, I haven't checked lately. Tapes are a mistery to me at least.. looking at the driver, there do seem to exist some common defaults, but then, there seem to be subtle differences, too, so I'd doubt there's an easy attempt at just providing some patchable defaults ? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:04:36 1993 From: Russel Miranda Subject: Re: A2630 To: "Michael L. Hitch" Cc: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Mon, 6 Dec 1993, Michael L. Hitch wrote: > I suspect that GVP may not have a problem telling the controllers apart. > When the SII '030 configures, it probably uses the driver from the '030 > board. When the Zorro II board configures, it would probably use the > driver contained on that board. Not having a GVP '030 board, I can't > tell if the driver is exactly the same or not. They are exactly the same... or rather - it's the same ROM - there may be extra code in there. I can disable the ROM on all but the accelerator and it will be able to access all the drives on both cards (Accelerator and HC8). )Russ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:05:01 1993 From: Russel Miranda Subject: Re: A2630 To: Ty Sarna Cc: NetBSD-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Tue, 7 Dec 1993, Ty Sarna wrote: > Hmm, come to think of it, that method isn't 100% correct either. If > someone has a SII '030 and a plain SII, (do multiple SCSI controllers > work anyway?) one needs bounce buffers and the other doesn't... Hmm, > maybe we can just get GVP to tell us how THEY tell the difference :-) I think they just use the MASK value in the RDB - I have to set the mask differently for the drives I have on my S-II accel than the drives on my S-II hard card. > Bounce buffer support is great though! Thanks a lot! What I hope for someday is that the drives on the accelerator's controller can DMA into the accelerator's 32-bit RAM, and the drives on the hard card can DMA into the hard card's 16-bit RAM (which currently is not even recognized by NetBSD). Every other transfer should use some sort of buffer - preferably one in RAM it can DMA to! So many different configurations! )Russ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:19:03 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: new cc stuff. To: chopps@emunix.emich.edu (Chris Hopps) Cc: NetBSD-Admin@cbmuucp.commodore.com, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 862 Sender: NetBSD-Admin@cbmuucp.commodore.com > Oh dear it seems that you may be booting into the 640x800 2024 mode > but you don't have a 2024 :^) you probably want to examine > _ite_default_height if its 800 then change it to 400 (or whatever you > want by default) > > The only reason this would happen is if GRF_A2024 was enable when the > kernel was compiled... I wonder... ANyway it shouldn't have been. Hm.. I enabled ALL of the provided monitor definitions, true to the philosophy of the generic kernel. You shouldn't mistake the direction to include the driver (including GRF_A2024 in the config file) to mean to also make it the default driver. That should be, if you don't want to just make LCD assumptions, a separate option. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:31:41 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: new cc stuff. + gdb question To: niklas@appli.se (Niklas Hallqvist) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 917 Sender: NetBSD-Admin@cbmuucp.commodore.com > I still have a problem I've had all the time with Chopps cc code. > It won't switch between PAL and NTSC on my OCS A2000. What I choose > in ADOS before loading BSD will remain until I reboot. It would be > real nice to be able to switch the mode to NTSC after a few hours in > front of the shakey PAL screen. Hm.. can you switch PAL/NTSC on OCS at all?? I remember some pretty rude copperlist-interrupt hack to early-terminate pal frames to fake a 60Hz display... > GDB (the latest version on eunet) segfaults for me after a > trapsignal(76, 11, -1, ffffff, d4a6e) or similar. Yes, I have > patched my kernel source and recompiled. Anyone else seen this? Hm, I have a 4.11 gdb up and apparently working. I'll include it in the new bin dist. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 7 23:38:16 1993 From: Darren Reed Subject: Re: zlibc To: mw@eunet.ch (Markus Wild) Cc: oster@skorpio.usask.ca, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 196 Sender: NetBSD-Admin@cbmuucp.commodore.com Has anyone here looked at using TCX for NetBSD ? TCX allows you to have compressed binaries which are decompressed, in-space when you run them. They aren't immediately recompressed, however. From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 00:22:47 1993 To: "NetBSD-Amiga" From: "Matthias Scheler" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: IntuiNews 3.141592654 (Right Now) Subject: intalling on a gvp 030 Organization: Amiga User Group University Paderborn Sender: NetBSD-Admin@cbmuucp.commodore.com Hi mykes, > I'm about to install netbsd on a friend's A2000/GVP030 machine and > I would like to know from someone else who's done it already how to > name the partitions BSDR, BSDS, BSDA, etc. using faaaastprep. I haven't > seen faaaastprep in a couple years, but my friend told me that he > couldn't find any text box in faaastprep that had a hex number in it > for his partitions other than the "mask" field. Also, he has a toggle > gadget for file system type that has 3 choices: ofs, ffs, and afs. No need for it ... > Does he have an old version of faaastprep? If he does, would someone > out there uuencode and mail me a copy of the new faastprep? Or are > people copying devs:gvpscsi.device to devs:scsi.device and using > hdtoolbox? (sounds dangerous) ... GVP has autoboot, so there should be no disk based device. Why don't you just use "HDToolBox gvpscsi.device" ? I never used the RDB editor which came with my Z3-Fastlane. -- Matthias Scheler tron@lyssa.pb.owl.de From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 02:42:21 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: new cc stuff. + gdb question To: NetBSD-Admin@cbmuucp.commodore.com (Niklas Hallqvist) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I still have a problem I've had all the time with Chopps cc code. > It won't switch between PAL and NTSC on my OCS A2000. What I choose > in ADOS before loading BSD will remain until I reboot. It would be > real nice to be able to switch the mode to NTSC after a few hours in > front of the shakey PAL screen. I need to know what to do to make OCS switch to PAL. I have searched every hardware book I have (ARKM, Abicus (hiss)) even the non HW stuff (which is of no basic use here...) It seems in some example programs I saw that all people were doing was changing GfxBase->DisplayRows to 256 instead of 200. So thats how I coded it add the extra space. I relize it doesn't work not even on my ECS amiga (ECS works now becuase of the beamcon register) Under ECS I set the PAL bit in the beamcon register if someone could tell me how to do this under OCS I would be happy to toss it in. [..] > > Niklas > Chris. From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 07:22:02 1993 From: kcd@cbmvax.uucp.commodore.com (Ken Dyke - Amiga Gfx and FMV) Subject: Installation?!? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com Okay...so I decided to finally break down and try installing the latest version of NetBSD on my A3000/040 this evening and have run into a few snags: 1) How the **** do you format a new partition? I've tried using newfs and/or mfs, and both of them complain that they don't know the disk type of the partition that I want to format. I'm fairly certain I have everything set up correctly with HDToolBox. In case it's important, my configuration is: SCSI Device 1: Maxtor P1-17s, which the first 400Mb or so set up to be /usr. Indentifier is 0x42534444, partition name is BSDD. (the rest of the disk is for AmigaDOS) SCSI Device 6: Quamtum 80Mb, with 20Mb of swap, 8Mb root, and the rest dedicated to swap space. 2) I am constantly getting the ancient "DMAINTR: should no longer be entered" error message whenever disk access occurs. Any idea what this is and if there's any way to fix it? 3) Just for grins, I attempted to install bin-bin.tar stuff, at which point I got: "dmanext at end" (or something like that) and a kernel panic. Anyone want to take a shot at any of these? Thanks, Ken From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 07:34:01 1993 From: Bob Slawson To: kcd@cbmvax.uucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Installation?!? Sender: NetBSD-Admin@cbmuucp.commodore.com > Anyone want to take a shot at any of these? Did you get the updated binary for `newfs' from the bin-newest directory? BobS P.S. I just tried private mail to kcd@cbmvax.uucp.commodore.com but it bounced. From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 09:00:37 1993 From: Calvin Chu Subject: Recompile To: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com NetBSD thinks my A2000/2091 is a A3000 and is (trying to) do 32-bit DMA. Obviously that's a bad thing. Ok, how do I set DMA off? I have a feeling that I have to do a recompile, which isn't a problem... now the problem is that the config program doesn't seem to work. I did a snoopdos and it seems to be trying to call inet.library and quitting. It's also trying to do some stuff with "../compile/amiga" -- beats the hell out of me. The config I'm using is the config.gz that was sitting on the NetBSD site. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAizPXUAAAAEEANNwzasX+nZfGPb4R/DaJ4z7kF2mBgyYsqTR4fMRyqJTeRMw aHBJlbZztiTKk2ZpzamCS6xroG6m34M5kwtuk2OMOb19sWa3y7YPWFx1qdk3ZQ06 /TdRy/nYIIWzG4+myMymnvYHZlgaoEGVTZfS9U+Tqv6AtDym6ZYplMRSmDTBAAUR tCpDYWx2aW4gQ2h1IDxkaWF2b2xvQGF6dXJlLmVuZ2luLnVtaWNoLmVkdT4= =9MhY -----END PGP PUBLIC KEY BLOCK----- From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 09:20:50 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Installation?!? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312080510.AA01093@cbmvax.cbm.commodore.com> kcd@cbmvax.uucp.commodore.com (Ken Dyke - Amiga Gfx and FMV) writes: > 2) I am constantly getting the ancient "DMAINTR: should no longer be entered" > error message whenever disk access occurs. Any idea what this is and if > there's any way to fix it? > > 3) Just for grins, I attempted to install bin-bin.tar stuff, at which point > I got: "dmanext at end" (or something like that) and a kernel panic. I have both of these symptoms on a 3000T (plain 030 model). Certain operations (newfs and ps sometimes, and boot with -a always) cause the "dmanext at end" panic. To repeat from my previous message, this is with vmunix #714, and the machine currently has 2M chip, 4M fast. I too would appreciate any help with these problems. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 11:13:03 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: X11R5 server using stdout or stderr Sender: NetBSD-Admin@cbmuucp.commodore.com X11 closes stdout, so we're using ErroF(...) which is printf for stderr. we can't send a new version of X for now as phb@colombo.telessys-innov.fr is "unavailable". I've heared tha shared libs will be soon here. If we can have this support, the next release will uses these libs For now, I'm working on the retina X11 support, but it seems that there's a bug in the cfb.banked routines which crashes X when a window is moved form outside to inside the screen or when I try to pull down the xterm menu ??? :-(( And as my dbx tells me that the stack is 0x00 when seg-fault occures, I can't find the bug. So I'm waiting for a good dbx. I've also recompiled ctwm (twm 3D) and xpm-3.2a.tar.z for NetBSD and it works fine (in color under the retina :-)) ). lahaye_o@epita.fr From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 11:18:10 1993 From: niklas@appli.se (Niklas Hallqvist) To: swalter@avalon.unizh.ch Cc: netbsd-amiga@cbmuucp.commodore.com Subject: SIM kernel debugger Sender: NetBSD-Admin@cbmuucp.commodore.com [To Stefan: this message is CC:d to the NetBSD mailinglist: netbsd-amiga@cbmuucp.commodore.com] [To NetBSDers: Stefan is the author of a system independent debugger called SIM, which previously has been used in the AmigaMach (aka KludgeMach) project. I've brought up the subject of debugging NetBSD kernels with SIM] >>>>> "Stefan" == walter stefan writes: Stefan> No problem. Mach or NetBSD - the general project (to get a Stefan> free UNIX working on the Amiga) is still the same, so I still Stefan> help where I can. You can of course use either the old or the Stefan> new SIM for NetBSD. I can send you the new version (it is far Stefan> from being finished but already much better than the old one) Stefan> and the neccessary information about how to start it, how to Stefan> make a symbol list, etc. Stefan> It may be a good idea to ask the other developers though. If Stefan> someone was short before porting some real UNIX debugger this Stefan> would of course be the better solution. I don't know how happy Stefan> the developpers who haven't worked on Mach before will be when Stefan> they have to use SIM since it still mainly is an assembly Stefan> language debugger. BTW, is there a mailing list for NetBSD? So... Is there someone working on a kernel debugger? SIM has the advantage of running on the CC console for those that does not have terminals. It's mostly assembly language level but Stefan said in an earlier note to me that he was about to put in source line info in there. Stefan: the main ftp-site for NetBSD is ftp.eunet.ch (just round the corner, right :-) ) If there is space there, you could put a package in software/os/bsd/NetBSD/NetBSD-Amiga/incoming for those of us that like kernel-hacking to try to integrate with NetBSD. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 17:38:40 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: NetBSD-Amiga@cbmuucp.commodore.com, dej@eecg.toronto.edu Subject: Re: zlibc Sender: NetBSD-Admin@cbmuucp.commodore.com With all this discussion about the concept and usefulness of virtual disks and compressed files/filesystems... I would just like to point out that virtual disks are the whole game with logical volume manager packages like come with OSF/1 and AIX 3.x systems. Just so that someone doesn't try and say this isn't feasible. I don't think it would be a stretch to provide an LVM with a compression feature. Just thinking out loud... Rob From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 17:58:33 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: mykes@shell.portal.com Subject: Re: zlibc Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com Well, it sounds to me like zlibc is a good one. You don't have to use it unless you want to and that's nice for everyone. The issue of compressed executables is interesting too, but I think the zlibc idea is a more general solution for the problem of resources. You just compress up the data files and let the library handle them transparently. BTW, it occurs to me that compressed executables could be implemented with the following scheme (ugly, but easy). Compress the command, create an alias or shell function for that command which would uncompress the command to run it (from /tmp or something). This is kludgy, but does not require any changes to the kernel, the filesystem, or the libraries. Right? Thinking out loud again :-) Rob From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 18:15:00 1993 Subject: Replies From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I'm not sure if it has ever occurred to people but... If you are replying to a posting from this list, then the person who posted the original message will get your reply, through the list. There is no need to Cc: the poster's private mail. The original poster will get two copies if you do. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 18:57:08 1993 From: paul theodoropoulos Subject: Re: Replies To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 842 Sender: NetBSD-Admin@cbmuucp.commodore.com > I'm not sure if it has ever occurred to people but... > > If you are replying to a posting from this list, then the person who > posted the original message will get your reply, through the list. > > There is no need to Cc: the poster's private mail. The original > poster will get two copies if you do. the ELM mailer, which enjoys great popularity, has what some consider a "broken" group reply function - it does exactly what you've described above. after composing a group reply, the sender can always go back and manually edit the header lines, but more often than not, one forgets to do so. in this case, because the subject of my mail concerns that deficit, i'll leave the headers untouched so you can see how ELM decides to direct this group reply to the list. -- paul theodoropoulos pt@crl.com diogenes@well.sf.ca.us From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 19:11:08 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Installation?!? To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 719 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have both of these symptoms on a 3000T (plain 030 model). Certain > operations (newfs and ps sometimes, and boot with -a always) cause the > "dmanext at end" panic. To repeat from my previous message, this is with > vmunix #714, and the machine currently has 2M chip, 4M fast. I too would > appreciate any help with these problems. I don't know what's going here.. Just to make sure it's not a "simple" problem of running out of physical memory, I started 50 emacses, which consumed about 25M of swapspace, the system was (and still is) healthy.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 20:56:23 1993 From: ahh@netcom.com (Andy Heffernan) Subject: Re: new cc stuff. + gdb question To: mw@eunet.ch (Markus Wild) Cc: niklas@appli.se, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 504 Sender: NetBSD-Admin@cbmuucp.commodore.com > > GDB (the latest version on eunet) segfaults for me after a > > trapsignal(76, 11, -1, ffffff, d4a6e) or similar. Yes, I have > > patched my kernel source and recompiled. Anyone else seen this? > > Hm, I have a 4.11 gdb up and apparently working. I'll include it in > the new bin dist. Want some floating-point diffs for both gdb and the kernel? -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 23:02:06 1993 X400-Originator: /dd.id=1619692/g=hamish/i=hi/s=macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.417:08.11.93.21.33.25] X400-Content-Type: P2-1984 (2) Content-Identifier: re:NetBSD now... From: "hamish (h.i.) macdonald" Sender: "hamish (h.i.) macdonald" To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com Subject: re:NetBSD now thinks my A500 is an A3000. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> On Tue Dec 7 16:45:00 1993, >>>>> Stefan wrote: s> ZEUS card I believe, it now thinks that I have an A3000 with an s> A3000 s> ShowConfig reports the following for my system: s> RAM: Node type $a, Attributes $5 (FAST), at $8000000-$83fffff (4.0 meg) ^^ This does not have the MEMF_LOCAL flag, which an A3000 would have. This is one thing you can use to differentiate this case (i.e. it won't help you determine that you *do* have an A3000, but it can certainly indicate that you *don't*. From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 8 23:04:42 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: X11R5, MMU Panic, etc. X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com It's been an interesting day... I had been using nfs mounted partitions for /bin, /sbin, /usr, and X11R5 and had the old old bin*.tgz stuff installed on my hard drive (new /sbin bins and /bin for booting to the nfs partitions though). Everything except for nfs file-serving was working great - especially X. I never saw the mmu fault problem with the X11R5 stuff. Then I decided to move all the new bin* onto my local hard drive to free up that nfs disk space. After copying the stuff from nfs to local drives, X started giving me the MMU fault and it took a bit of poking around to get it to work reasonably... I had to modify the startx script, for example, to add 2> /dev/null to the line that does xinit. I didn't need to do that when X11 was on the nfs partitions. I had been using xdm too, and that also broke causing mmu fault kernel crashes after moving to local hard drive. I am certainly proficient enough at unix to figure out permission/ownership issues - indeed after doing: tar cvfp - /net/X11R5 | { cd /local/X11R5 ; tar xvfp - } I noticed that all the X11R5 owner/permissions ended up wrong and thus I reinstalled X11R5 by untarring the X11R5-*.tgz stuff from scratch to get correct ownership/permissions again. I found that I had to make some of the X binaries SUID for them to work: Xbsd, startx, and xdm. I've pretty much gotten it so X works as I want. Here's the problems I have and seek solutions to: If I startx or use xdm (started from /etc/ttys for console), I can not use xconsole or xterm -C to intercept console messages. This alone makes X unusable (and dangerous for my filesystems :( because anytime I telnet/login to netbsd with X running, or su to become root, a console message is printed: "LOGIN BY USER %s ON DEV ptyx" or "SU BY USER %s..." and this causes the MMU panic. I noticed in the /usr/lib/X11/xdm/Xsetup_0 file that the line to start xconsole was commented out (it shouldn't be - take note of this :). xconsole _should_ be open/running when xdm asks for login/password, but it doesn't. After login from xdm and try to run xconsole by hand, it opens a window with: "Can't open console" in it. running xterm -C causes no console messages to be directed to the xterm - and console log message and MMU fault happens. xterm is also suid root and owner root, so it should not be having problems with permissions and /dev/console. This is so serious X can't be used (by me at least, currently). If you have your machine on a net by PPP, SLIP, PLIP, or ethernet or even just localhost (127.0.0.1) and telnet to your netbsd machine while X is running, MMU panic! The following other programs are guaranteed to cause the panic: login, su. Also, any cp command that fills a partition to 110% causes a console message: "filesystem full" and thus an MMU panic. You get the idea how bad this is :( I just noticed that /etc/syslog.conf has the following lines: *.err root *.notice;auth.debug root *.alert root *.emerg * Hopefully the "root" and "*" can be redirected to a file and thus stop the console errors... It may be a temporary solution until the next beta release (or whatever) of X11R5. OK, next problem is with xdm itself. It doesn't ever validate any login that has a password. Markus tells me it is because netbsd uses shadow passwords - but he also tells me that any program that us owner/suid root and uses the getpw*() functions automagically uses shadow passwords. I made xdm suid/owner root, but it doesn't make a difference. I also got the xdm sources from the X11R5 source tree (mit/clients subdir) and built it from scratch and it has the same problem - "invalid password" unless there is NO password for the user in question. Am I the only one who's seen this? Has someone figured out how to get it to work? Last problem - the Xbsd server appears to have a copperlist/screen problem. The top 5-10 scanlines of the X display are trashed and anything that renders there (windows/borders/etc.) is also trashed. This could very well be because in the 2 bitplane display, one of the planes has trash/random memory and it is never cleared while the other plane is rendered to. To summarize: 1) MMU fault and can't redirect /dev/console to xconsole 2) xdm doesn't validate passwords. 3) Xbsd server (or ite_cc) leaves trash on the screen A note to Markus (for sure he knows about it): /sbin/reboot causes fireworks instead of yellow screen or true reboot on my 16M A3000. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 02:52:58 1993 From: Bill Squier To: mykes@shell.portal.com, netbsd-amiga@cbmuucp.commodore.com Subject: Re: X11R5, MMU Panic, etc. Sender: NetBSD-Admin@cbmuucp.commodore.com >Date: Wed, 8 Dec 1993 13:43:00 -0500 >Subject: X11R5, MMU Panic, etc. >From: mykes@shell.portal.com >Sender: NetBSD-Admin@cbmuucp.commodore.com > Let me preface ALL my comments with the fact that I'm running vmunix.709, with patches supplied by the porters of X11R5. (I believe their regsize patch is in error, but I use it anyway). I've rebuilt 709 by hand to add support for my tape drive, but otherwise it's stock (+ X11R5 patches) I have an ECS A2000/GVP Series II/8M 32bit. >I had to modify the startx script, for example, to add 2> /dev/null to >the line that does xinit. I didn't need to do that when X11 was on the I need no such line. (see next comment) >If I startx or use xdm (started from /etc/ttys for console), I can not >use xconsole or xterm -C to intercept console messages. xterm -C successfully traps console messages for me, but xconsole fails for non-root users. Even if I _don't_ run `xterm -C' from non-priv'ed accounts, I don't get any panics. (of course, I only get the console messages in /var/log/messages...) >OK, next problem is with xdm itself. It doesn't ever validate >any login that has a password. Markus tells me it is because >netbsd uses shadow passwords - but he also tells me that any >program that us owner/suid root and uses the getpw*() functions >automagically uses shadow passwords. I made xdm suid/owner >root, but it doesn't make a difference. I also got the xdm >sources from the X11R5 source tree (mit/clients subdir) and >built it from scratch and it has the same problem - "invalid >password" unless there is NO password for the user in question. >Am I the only one who's seen this? Has someone figured out how >to get it to work? I wish I had figured this one out (finals are _OVER_ after Monday, so I should be able to look at this a little more). My experience with `xdm' is identical to yours. >Last problem - the Xbsd server appears to have a copperlist/screen >problem. The top 5-10 scanlines of the X display are trashed and >anything that renders there (windows/borders/etc.) is also trashed. >This could very well be because in the 2 bitplane display, one of >the planes has trash/random memory and it is never cleared while >the other plane is rendered to. I don't experience this display munging at all. (ECS A2000) --------- Have you gotten xload to work? According to docs, it needs to be in group kmem, and sgid in order to read /dev/kmem, and it is indeed. /dev/kmem is read for owner (root)/group (kmem)... -wps From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 03:38:58 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A2630 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312070534.AA14870@gemini.oscs.montana.edu> osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > I think for now it will probably have to be binpatchable :-(. The RDB > values wouldn't necessarily indicate anything. The HC8+ card driver will > accept any address and handle it correctly. Ouch, I didn't think of that. Hmm.... Well, hopefully there is a way to tell the controllers apart easily. There are just way too many binpatchable things as it is :-( Maybe, rather than binpatching, we could come up with an extensible information format (array of tooltype-like strings?) that the loadbsd command could pass to the kernel, and the kernel could pick out what it wanted. At least this is slightly more user-friendly, can be compatible between different version, and it allows one to use the same kernel with different options rather than keeping multiple patched copies around or binpatching values as needed. I'd love to be able to reconfigure a precompiled kernel as easily as adding: GVPII_32BITDMA=ON,OFF # on for first controller, off for second SCSI_NOSYNC=sd4,sd6 (SCSI_DEBUG=VERBOSE) # can uncomment this one when debugging SCSI_DEBUG=OFF # otherwise use this CC_MODE=A2024_15HZ # to set default mode CC_DEPTH=1 CC_COLORS=0x888888,0x000000 AUTOBOOT=TRUE # like -a ASKROOT=FALSE # like no -b STEAL_4MEG=FALSE # like no -k to a file or an icon or something. I'd be willing to work on the loader side of this, if someone wants to do the kernel side (I can't do much on the kernel side until I get my DMAINTR/dmanext at end problems straightened out. I don't trust the filesystem to stay sane :-<). > specify an entry for each. I'm not real clear on how everything fits > together, but it looked like defining one of each for the A3000, A2091, > and GVP11 controllers could cause problems if there are two or more > of the same controller type. I saw a comment to that affect, but it isn't very clear. Probably because nobody has tried it to see what actually happens :-) > I suspect that GVP may not have a problem telling the controllers apart. > When the SII '030 configures, it probably uses the driver from the '030 > board. When the Zorro II board configures, it would probably use the They have a binddrivers-type driver as well, though. Also, someone else said that they thought the ROMs on the SII and SII'030 were identical. > driver contained on that board. Not having a GVP '030 board, I can't > tell if the driver is exactly the same or not. We have one of each, and we're planning to play "musical expansion boards" this weekend anyway, so I'll take a look. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 03:39:17 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Installation?!? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <199312081719.SAA23625@eunet.ch> mw@eunet.ch (Markus Wild) writes: > > I have both of these symptoms on a 3000T (plain 030 model). Certain > > operations (newfs and ps sometimes, and boot with -a always) cause the > > "dmanext at end" panic. To repeat from my previous message, this is with > > vmunix #714, and the machine currently has 2M chip, 4M fast. I too would > > appreciate any help with these problems. > > I don't know what's going here.. Just to make sure it's not a "simple" > problem of running out of physical memory, I started 50 emacses, which > consumed about 25M of swapspace, the system was (and still is) healthy.. I get about 50 of the DMAINTR messages when boting single-user, before I even get to the root shell. I don't think it's a memory problem. I'm also guessing Ken has more memory than I do. I know, 4M isn't really enough... I hope to add more soon. [As a side note, the -k switch does interesting things on a 4M machine. "Using 0M FAST MEM at ..." *POOF* :-> (and no, I have the DMAINTR/dmanext problems without -k... I only tried -k just to see what would happen when it tried to boot on an 0M machine :->) -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:15:34 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) From: dfisk@level10.uucp.commodore.com (David Fisk) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation?!? Sender: NetBSD-Admin@cbmuucp.commodore.com > Okay...so I decided to finally break down and try installing the latest version > of NetBSD on my A3000/040 this evening and have run into a few snags: > > 1) How the **** do you format a new partition? I've tried using newfs and/or > mfs, and both of them complain that they don't know the disk type of the > partition that I want to format. I'm fairly certain I have everything set > up correctly with HDToolBox. In case it's important, my configuration is: Has anyone newfs'ed a partition with the 714 and the new newfs? I just re-partitioned my hard drive and got the same messages. I finally went back to the old version of newfs and an old kernel in order to get back up and running. Dave ------------------------------------------------------------------------------ David Fisk Home: - dfisk%level10@merk.com ...uunet!merk!level10!dfisk Work: - dfisk@drilex.dri.mgh.com From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:33:28 1993 From: Russel Miranda Subject: Re: A2630 To: NetBSD-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Thu, 9 Dec 1993, Ty Sarna wrote: > Ouch, I didn't think of that. Hmm.... Well, hopefully there is a way > to tell the controllers apart easily. There are just way too many > binpatchable things as it is :-( Maybe, rather than binpatching, we > could come up with an extensible information format (array of > tooltype-like strings?) that the loadbsd command could pass to the If it turns out the code is identical, why not just use the mask value in the RDB? If the address fits the mask, DMA, if not, don't DMA? My mask for drives on my SII accelerator is 0xFFFFFFFE and for drives on the SII hard card (ZII) it is 0x00FFFFFE. If the destination is in the 24-bit address space (ORing with the inverse of the mask yields zero), the hard card DMAs, if not, it has a little buffer [could be in chip mem, but really just has to be in any memory that fits the mask]. The accelerator's interface has no such limitations, EVERY even address fits the mask. > I saw a comment to that affect, but it isn't very clear. Probably > because nobody has tried it to see what actually happens :-) I'll try anything you want to send at me... I have the wierdest setup imaginable with regard to GVP controllers... I have 3 in my machine at once. Don't ask why - it just happened. One is a hard-card, one is a hard-card with 8 megs of RAM, and one is on the series II accelerator. All have drives attached. Right now, I'm only using drives off the accelerator's HD - it is the only one that is recognized without any modifications to the kernel. > They have a binddrivers-type driver as well, though. Also, someone else > said that they thought the ROMs on the SII and SII'030 were identical. Yes, I think they are. I've played mix'n'match with the FaaastROMs (tm?) and it doesn't matter - now whether the code within the driver does different things depending on the hardware it finds - that I can't answer. Both the accelerator and the hardcards use GVP's Dual Port RAM Controller (the chip marked DPRC), and the WD SCSI chip - so I would expect them to be very, very similar. > We have one of each, and we're planning to play "musical expansion > boards" this weekend anyway, so I'll take a look. If you want me to try anything - let me know. To add to the confusion, I also have an IOExtender in here - which also identifies with the same manufacturer/product codes. )Russ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:42:50 1993 From: Russel Miranda Subject: Re: X11R5, MMU Panic, etc. To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Wed, 8 Dec 1993, Bill Squier wrote: > I have an ECS A2000/GVP Series II/8M 32bit. I'm living in the past, with an OCS Denise, but ECS Agnes, same accel. > >I had to modify the startx script, for example, to add 2> /dev/null to > >the line that does xinit. I didn't need to do that when X11 was on the > > I need no such line. (see next comment) I have been running startx redirected to /dev/null, or I get the MMU panic. > >If I startx or use xdm (started from /etc/ttys for console), I can not > >use xconsole or xterm -C to intercept console messages. > > xterm -C successfully traps console messages for me, but xconsole fails > for non-root users. Even if I _don't_ run `xterm -C' from non-priv'ed > accounts, I don't get any panics. (of course, I only get the console > messages in /var/log/messages...) I've been getting panics every time things go out to the console. I am now trying out xterm -C (under root's privleges) but I haven't had anything go out to the console yet. I'd force something, but I have some work I want to do before having to reboot again! > >Last problem - the Xbsd server appears to have a copperlist/screen > >problem. The top 5-10 scanlines of the X display are trashed and > >anything that renders there (windows/borders/etc.) is also trashed. > >This could very well be because in the 2 bitplane display, one of > >the planes has trash/random memory and it is never cleared while > >the other plane is rendered to. > > I don't experience this display munging at all. (ECS A2000) I do. Perhaps it is an OCS problem? The first few lines have something in the next bit plane, it appears to my untrained eye... Anything that is displayed in this region is the wrong color - or rather, the wrong color anywhere there is something set in the other bitplane. It is not damaged in any way - just the wrong color. Anyway - fvwm looks really nice! And it actually gives poor NTSC OCS pepole like me some X-real estate to drop windows on! )Russ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:49:15 1993 From: Abeech@splat.paxnet.com.au Subject: Some really silly questions! To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 513 Sender: NetBSD-Admin@cbmuucp.commodore.com Greetings All! Well thanks to Chris H I can now see what I'm doing with NetBSD. A lower resolution and change of pens has really helped! Now I have two really silly questions. 1. Is the internal DFx: drives supported? If they are then what /dev/... are they? 2. Which /dev block files represents the internal serial and parallel ports? -- Adrian V. Beech E-Mail: adrianb@spectrum.adsp.sub.org Abeech@splat.paxnet.com.au From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:50:07 1993 From: ahh@netcom.com (Andy Heffernan) Subject: Re: X11R5, MMU Panic, etc. To: mykes@shell.portal.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1673 Sender: NetBSD-Admin@cbmuucp.commodore.com mykes writes: > OK, next problem is with xdm itself. It doesn't ever validate > any login that has a password. Markus tells me it is because > netbsd uses shadow passwords - but he also tells me that any > program that us owner/suid root and uses the getpw*() functions > automagically uses shadow passwords. I made xdm suid/owner > root, but it doesn't make a difference. I also got the xdm > sources from the X11R5 source tree (mit/clients subdir) and > built it from scratch and it has the same problem - "invalid > password" unless there is NO password for the user in question. > Am I the only one who's seen this? Has someone figured out how > to get it to work? If you want to start narrowing down the problem, try compiling and running this program: #include #include #include #include main(argc, argv) int argc; char *argv[]; { struct passwd *pw; int i; if (argc < 2) { fprintf(stderr, "Usage: %s name ...\n", argv[0]); exit(1); } for (i = 1; i < argc; i++) { struct passwd *pw = getpwnam(argv[i]); if (pw) printf("%s/%d/%s\n", pw->pw_name, pw->pw_uid, pw->pw_passwd); else printf("%s ???\n", argv[i]); } exit(0); } Run as an ordinary user, and as root, and as an ordinary user with the executable setuid-root, giving it names of accounts with and without passwords. Check /etc/master.passwd if you forget which have passwords. (Not running X and have ancient libraries, so my positive results may not count for much...) -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 04:55:36 1993 From: Calvin Chu Subject: Multiple Controllers To: NetBSD-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com Just tried plugging in two 2091's in last night. The computer wouldn't even power up (!). Have no idea why. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 05:26:43 1993 From: jyork@iastate.edu To: NetBSD-amiga@cbmuucp.commodore.com Subject: Slingshot500 and A2091?? Sender: NetBSD-Admin@cbmuucp.commodore.com Does anyone here have experience with the Slingshot500 adapter. It lets the A500 have one A2000 slot in addition to the other connection. Are these reliable? If I bought one of these and an A2091 HD controller, I could run NetBSD, but I wasn't sure if it would interfere with my accellerator or External HD/Memory card (I'm not giving up on the GransSlam, but nobody's really working on a driver for it yet). If anyone has experience with the Slingshot and ANY other board, please E-mail me at: Justin York jyork@iastate.edu From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 07:10:08 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A2630 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article Russel Miranda writes: > > On Thu, 9 Dec 1993, Ty Sarna wrote: > > Ouch, I didn't think of that. Hmm.... Well, hopefully there is a way > > to tell the controllers apart easily. There are just way too many > > binpatchable things as it is :-( Maybe, rather than binpatching, we > > could come up with an extensible information format (array of > > tooltype-like strings?) that the loadbsd command could pass to the > > If it turns out the code is identical, why not just use the mask value > in the RDB? If the address fits the mask, DMA, if not, don't DMA? > My mask for drives on my SII accelerator is 0xFFFFFFFE and for drives > on the SII hard card (ZII) it is 0x00FFFFFE. If the destination is in Michael L. Hitch said that he thinks the drivers handles that stuff itself, so that you can safely put 0xFFFFFFFE even with the Zorro-II SII. Hence, you can't count on the mask value :-( > I'll try anything you want to send at me... I have the wierdest setup > imaginable with regard to GVP controllers... I have 3 in my machine at > once. Don't ask why - it just happened. One is a hard-card, one is a > hard-card with 8 megs of RAM, and one is on the series II accelerator. > All have drives attached. Right now, I'm only using drives off the > accelerator's HD - it is the only one that is recognized without any > modifications to the kernel. Ah... that's one bit of information. Have you tried making config entries for each controller, say sd, s2d, and s3d, to see if it will work? > Yes, I think they are. I've played mix'n'match with the FaaastROMs (tm?) > and it doesn't matter - now whether the code within the driver does Well, at least that indicates that there IS a way to tell the boards apart. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 07:22:05 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Some really silly questions! Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312072225.AA03312@paxnet.com.au> Abeech@splat.paxnet.com.au writes: > 1. Is the internal DFx: drives supported? If > they are then what /dev/... are they? Not in the current version, and I don't know of any drivers in development. I would hope that anyone writing a floppy driver (or anything else) would write a message to the list so that someone else doesn't waste time duplicating the same work. Also, my personal wishes for a floppy driver: - Work in either Amiga or PC mode so that PC disks can also be used, with msdosfs (once its fixed to run on bigendian machines). PC mode should be selected by a different set of minor device numbers (0-3 Amiga, 4-7 PC). - Support HD floppies (now that I actually have one :->) HD support should not require differnet minor numbers, but be automatic with detection of the HD hole. (are the low-level programming details of HD floppy drives documented anywhere? I don't think the Hardware RKM covers them). > 2. Which /dev block files represents the internal > serial and parallel ports? There are no block devices for the serial and parallel ports, only character devices (since serial and parallel ports are naturally character-at-a-time devices). -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 07:26:57 1993 From: Russel Miranda Subject: Re: A2630 To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Thu, 9 Dec 1993, Ty Sarna wrote: > Michael L. Hitch said that he thinks the drivers handles that stuff > itself, so that you can safely put 0xFFFFFFFE even with the Zorro-II > SII. Hence, you can't count on the mask value :-( Hmmm. I'm not sure about this. But even if it IS true, you could require that for NetBSD people use the field like it was intended! > Ah... that's one bit of information. Have you tried making config > entries for each controller, say sd, s2d, and s3d, to see if it will > work? No. How would I put that in the config file? I'll try it out next kernel compile if you give me some tips. > Well, at least that indicates that there IS a way to tell the boards > apart. I'll ask some questions and see if there is a definite way. I know some people who might know. )Russ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 07:43:51 1993 From: Russel Miranda Subject: Re: X11R5, MMU Panic, etc. To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Wed, 8 Dec 1993 mykes@shell.portal.com wrote: > If I startx or use xdm (started from /etc/ttys for console), I can not > use xconsole or xterm -C to intercept console messages. This alone > makes X unusable (and dangerous for my filesystems :( because anytime > I telnet/login to netbsd with X running, or su to become root, a > console message is printed: "LOGIN BY USER %s ON DEV ptyx" or > "SU BY USER %s..." and this causes the MMU panic. I just tried xterm -C, and it works for me. I'm using the 714 kernel, and X11R5. I started X as root, and I executed the xterm -C as root also. Then, I logged in as myself in another xterm, and did an su. The message popped up in the other xterm - no problem. As did several silo overflow messages when running term (is there any way to speed up that serial driver code?). Your mileage may vary. )Russ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 09:35:47 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X11R5, MMU Panic, etc. To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: mykes@shell.portal.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 568 Sender: NetBSD-Admin@cbmuucp.commodore.com > Have you gotten xload to work? According to docs, it needs to be > in group kmem, and sgid in order to read /dev/kmem, and it is indeed. > /dev/kmem is read for owner (root)/group (kmem)... It shouldn't have to be sgid kmem for NetBSD. We have a new system call that is able to get the load average without reading /dev/kmem. Just make sure it uses the getloadavg() function and links with -lutil. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 09:47:07 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Some really silly questions! To: Abeech@splat.paxnet.com.au Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 454 Sender: NetBSD-Admin@cbmuucp.commodore.com > 1. Is the internal DFx: drives supported? If > they are then what /dev/... are they? Nope. > 2. Which /dev block files represents the internal > serial and parallel ports? /dev/tty00, /dev/par. I changed the serial driver quite a bit after 714, hopefully to the better... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 09:49:06 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Multiple Controllers To: diavolo@engin.umich.edu (Calvin Chu) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 351 Sender: NetBSD-Admin@cbmuucp.commodore.com > Just tried plugging in two 2091's in last night. The computer wouldn't > even power up (!). Have no idea why. It wouldn't boot (even amigados), or it just wouldn't boot into bsd? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 10:00:11 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X11R5, MMU Panic, etc. To: amigaman@esu.edu (Russel Miranda) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1134 Sender: NetBSD-Admin@cbmuucp.commodore.com > I just tried xterm -C, and it works for me. I'm using the 714 kernel, and > X11R5. I started X as root, and I executed the xterm -C as root also. > Then, I logged in as myself in another xterm, and did an su. The message > popped up in the other xterm - no problem. As did several silo overflow > messages when running term (is there any way to speed up that serial > driver code?). You're serious about those silo overflows???? This would mean that a level 5 interrupt driver, which is hardly blocked out, was still not fast enough to keep up with incoming data. This driver puts incoming characters into a ring buffer, and at vbl-level this buffer is then emptied into the regular tty queue. Having a silo-overflow (instead of the ringbuffer filling up) would mean that the UART gets a new character without the first having been read. At what speed are you running the serial port? I'm running ppp on 38k4 for a long time, and never had any such problems... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 10:11:35 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: X11R5, MMU Panic, etc. To: NetBSD-Admin@cbmuucp.commodore.com (Markus Wild) Cc: amigaman@esu.edu, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I just tried xterm -C, and it works for me. I'm using the 714 kernel, and > > X11R5. I started X as root, and I executed the xterm -C as root also. > > Then, I logged in as myself in another xterm, and did an su. The message > > popped up in the other xterm - no problem. As did several silo overflow > > messages when running term (is there any way to speed up that serial > > driver code?). > > You're serious about those silo overflows???? This would mean that a Probably has a gvp II accelerator---like me. You need to turn DMA off otherwise you'll get loads of silo overflows---like me. I was talking to Ralph Babel he told me that (and I don't know anything about the WD chip) the transfer size (a 24 bit value) needs to be set to 512 for the GVPII accelerators to work correctly with DMA. This is what the GvpPatch for amigados does. Again this 512 value is for the WD chip not the GVP DMA. Ralph said it had something to do with the bus not being fast enough to handle the big transfers. Currently I have to run with DMA off (its very slow too.) becuase of the prblems that are created with it on.. Here's hoping that someone can implement what Ralph was talking about :^). > -Markus Chris. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 12:04:49 1993 X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2674 From: BSDList@erixami.linet.org (Erik Karlin) To: netbsd-amiga@cbmuucp.commodore.com Cc: Erik_Karlin@erixami.linet.org Subject: Re: Recompile Sender: NetBSD-Admin@cbmuucp.commodore.com > > NetBSD thinks my A2000/2091 is a A3000 and is (trying to) do 32-bit DMA. > Obviously that's a bad thing. Ok, how do I set DMA off? I have a > feeling that I have to do a recompile, which isn't a problem... now the > problem is that the config program doesn't seem to work. I did a > snoopdos and it seems to be trying to call inet.library and quitting. > It's also trying to do some stuff with "../compile/amiga" -- beats the > hell out of me. The config I'm using is the config.gz that was sitting > on the NetBSD site. > Does anyone compile NetBSD under AmigaDOS? I cannot get it to compile AT ALL...the problem is that the make that is included with gcc 2.5.4 is GnuMake, but it doesn't recognize the '.include "<>"' directive. I changed it to a include, which kinda worked, but then GnuMake complains about '.if/.else/.endif' which I have no kludge for...I tried looking at the man pages for make that are with the Ados gcc dist., but the man page is for the BSD version of make, not the gnu version...So, I downloaded the make-3.68.tar.gz package, and looked through the info files, it won't recognize them...I also grabbed the /usr/share/mk/*.*.mk files for bsd make, just in case. Next I tried dmake, which looked promising, but it immediately redefined the variable S, so that is out... Is it at all possible to compile netbsd under amigados anymore? I cannot simply recompile the kernel under bsd, since NetBSD still thinks my GVP IO Extender is a gvp controller, and ignores my 2091 on my A2000/2630...I was going to just recompile the kernel with a different vendor string to recognize a GVP product in config/AMIGA so that it wouldn't guess at a gvp product... Oh, it would seem that the config program doesn't correctly make the ../../compile/AMIGA directories, but after making those dirs by hand, it worked, sorta...the machine symlink it creates there is invalid, since AmigaDos doesn't allow directory(circular) links, and I had to use opus to remove the machine link, and just copy the machine include files into the 'machine' directory instead. Does anyone have any suggestions...perhaps a true BSD compatible make for amigados? anyone have the sources for it...or has anyone fixed the GVP card identification? BTW- the first time I tried, I used #include/#if/#else/#endif, ie c-syntax, and I actually got ALL the modules of vmunix to compile, it just didn't link correctly, cause gnumake saw the '#' as a comment, so I don't know what exactly I was or wasn't including...certainly not ANY other Makefile.inc files...oops:) Please let us know... -Erik Karlin erik@erixami.linet.org From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 15:33:21 1993 To: olivier lahaye Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: X11R5 server using stdout or stderr X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> ol == olivier lahaye wrote: ol> I've also recompiled ctwm (twm 3D) and xpm-3.2a.tar.z for ol> NetBSD and it works fine (in color under the retina :-)) ol> ). ol> lahaye_o@epita.fr Latest version of xpm is xpm-3.2g (that I know of). :-) From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 16:17:37 1993 To: tsarna@endicor.com (Ty Sarna) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Some really silly questions! X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> Ty == tsarna@endicor.com (Ty Sarna) wrote: Ty> In article <9312072225.AA03312@paxnet.com.au> Ty> Abeech@splat.paxnet.com.au writes: > 1. Is the internal DFx: drives supported? If > they are then what /dev/... are they? Ty> Not in the current version, and I don't know of any Ty> drivers in development. I would hope that anyone writing Ty> a floppy driver (or anything else) would write a message Ty> to the list so that someone else doesn't waste time Ty> duplicating the same work. Also, my personal wishes for a Ty> floppy driver: I translated floppy hardware driver code to 'C' and sent it to Markus W. a long time ago. These drivers read/write amiga trackdisk format - you can use the disk in AmigaOS, but only with trackdisk.device (no amigados filesystem is on the disk). This means you can use DiskCopy to make duplicates of it.... When inserted in the drive with AmigaDOS running, you get a disk icon on the screen and the INFO command shows the disk 100% full (OS won't damage it by writing to it). The blitter is used to decode and encode MFM, but since there is no "QBlit()" functionality in netbsd kernel, it busy waits (fix it anyhow you choose). If anyone wishes to volunteer to make a device in the kernel from these routines, e-mail to Markus (mw@eunet.ch) and ask for the sources. Ty> - Work in either Amiga or PC mode so that PC disks can Ty> also be used, with msdosfs (once its fixed to run on Ty> bigendian machines). PC mode should be selected by a Ty> different set of minor device numbers (0-3 Amiga, 4-7 Ty> PC). They don't support msdos (my drivers) but I do have some msdos drivers somewhere (in assembly). The way my routines work is as follows: You would have /dev/fd0 through /dev/fd9. When you mount one of those devices (or simply access, actually) the drivers search in the physical drives for a floppy disk formatted with the ID 0, 1, .. 9. This scheme lets you move the floppy to any drive and the routines will find the disk. Indeed, the routines are smart enough to allow you to move the floppy disk WHILE it is writing to it even (no guarantee this won't damage the disk :-) While reading, you will get 100% error free reads even if you eject/insert/eject/insert the floppy many times during the read operation. Not so scary as AmigaDOS? :-) The benefit of this system is that you can mount up to 10 floppies in one floppy drive. The only issue is that when the disk is not found in the drives, you would probably want a requester like AmigaDOS has: "Please insert fd6 in any drive"... As for MSDOS, there is mtools which reads/writes msdos under linux or netbsd for PC and also on Suns (and probably MANY other unix computers). Ty> - Support HD floppies (now that I actually have one :->) Ty> HD support should not require differnet minor numbers, Ty> but be automatic with detection of the HD hole. (are the Ty> low-level programming details of HD floppy drives Ty> documented anywhere? I don't think the Hardware RKM Ty> covers them). I don't suspect there's much difference for the HD floppies to the software. Perhaps only #sectors/track is the only difference :-) Also a switch in cia register (or whatever) to make the drive go half speed. > 2. Which /dev block files represents the internal > serial and parallel ports? Ty> There are no block devices for the serial and parallel Ty> ports, only character devices (since serial and parallel Ty> ports are naturally character-at-a-time devices). Ty> -- Ty> Ty Sarna "Oh, I don't know *everything*. I don't Ty> tsarna@endicor.com even know how fish work." -- Joel, Ty> MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 17:32:20 1993 From: mw@eunet.ch (Markus Wild) Subject: gdb4.11/binutils-2.3 To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 428 Sender: NetBSD-Admin@cbmuucp.commodore.com I've put my working directory including gdb-4.11 and binutils-2.3 into contrib/bsd/gdb411bu23.tar.gz. Should compile right away, but you probably want to wait for the shared libs release, or you'll have to take shlib.o as object out of the netbsd config file. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 17:33:02 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: A2630 Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 8, 10:27pm, Russel Miranda wrote: > If it turns out the code is identical, why not just use the mask value > in the RDB? If the address fits the mask, DMA, if not, don't DMA? > My mask for drives on my SII accelerator is 0xFFFFFFFE and for drives > on the SII hard card (ZII) it is 0x00FFFFFE. If the destination is in > the 24-bit address space (ORing with the inverse of the mask yields zero), > the hard card DMAs, if not, it has a little buffer [could be in chip mem, > but really just has to be in any memory that fits the mask]. The > accelerator's interface has no such limitations, EVERY even address fits > the mask. But my ZII hard card does have 0xFFFFFFFE as the mask, so this won't work either. > If you want me to try anything - let me know. To add to the confusion, I > also have an IOExtender in here - which also identifies with the same > manufacturer/product codes. I did put some changes in the autoconf code to try to distinguish the IOExtender card from the SCSI card. If the card doesn't have a diagnostic vector (er_Reservec0c-0f are zero), the board should configure as a serial device rather than a SCSI controller. I think these changes are in the last changes I sent Markus, so they won't show up until the next kernel release. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 18:02:31 1993 From: Calvin Chu Subject: Re: Multiple Controllers To: Markus Wild Cc: NetBSD-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Thu, 9 Dec 1993, Markus Wild wrote: > > Just tried plugging in two 2091's in last night. The computer wouldn't > > even power up (!). Have no idea why. > > It wouldn't boot (even amigados), or it just wouldn't boot into bsd? Basically, with the second 2091 card plugged in, flipping the power switch does nothing at all. No lights turn on, no motors turn on, no noises *nothing.*. I thought that I burned out the motherboard after I plugged that second 2091 in! I removed the second 2091 and flipped the switch everything was a-ok. I know that multiple gvp scsi's are no problem, I also know that putting a gvp SII and a supra wordsync is also no prob. I have no idea why 2 2091's prevent powering up. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 18:09:14 1993 From: Calvin Chu Subject: Re: Recompile To: Erik Karlin Cc: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Wed, 8 Dec 1993, Erik Karlin wrote: > Oh, it would seem that the config program doesn't correctly make > the ../../compile/AMIGA directories, but after making those dirs > by hand, it worked, sorta...the machine symlink it creates there > is invalid, since AmigaDos doesn't allow directory(circular) links, > and I had to use opus to remove the machine link, and just copy > the machine include files into the 'machine' directory instead. I tried all of that, I havn't tried hex editing the "../compile/AMIGA" off the config file but I may do that if there's no other way to compile NetBSD under AmigaDOS. Would be nice if somebody would explain how to set up the compile.. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 18:32:59 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Recompile To: NetBSD-Admin@cbmuucp.commodore.com (Calvin Chu) Cc: BSDList@erixami.linet.org, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Wed, 8 Dec 1993, Erik Karlin wrote: [...] > I tried all of that, I havn't tried hex editing the "../compile/AMIGA" > off the config file but I may do that if there's no other way to compile > NetBSD under AmigaDOS. When I used to compile under amigados, it was much simpler. The problem is that we are trrying to have the distributed system be as ompatible with sun-lamp sources as possible, this inludes using bsd makes. You need to get bsdmake from aminet to do anything with urrent soures. > Would be nice if somebody would explain how to set up the compile.. Download vmunix and rootfs. boot unix get rest of binaries. put source in bsd filesystem and type make. The problem is I don't belive any of the active developers are building under amigados anymore so don't look for support there. > o/ \o/ o <| | /|\ |> <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu > /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! Chris. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 20:05:43 1993 From: Russel Miranda Subject: Re: X11R5, MMU Panic, etc. To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Thu, 9 Dec 1993, Markus Wild wrote: > You're serious about those silo overflows???? This would mean that a > level 5 interrupt driver, which is hardly blocked out, was still not fast > enough to keep up with incoming data. This driver puts incoming characters > into a ring buffer, and at vbl-level this buffer is then emptied into the > regular tty queue. Having a silo-overflow (instead of the ringbuffer filling > up) would mean that the UART gets a new character without the first having > been read. At what speed are you running the serial port? I'm running > ppp on 38k4 for a long time, and never had any such problems... Quite serious. I'll send you a clip of the xterm -C next time it happens (I get them on the console too, but it's much harder to clip them out!). I run it at 19200 - I have a 14.4kbps modem hooked up, but I usually connect at 9600. )Russ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 20:19:55 1993 From: DCG9367@tntech.edu Subject: Re: Multiple Controllers To: diavolo@engin.umich.edu Cc: NetBSD-amiga@cbmuucp.commodore.com X-Vms-To: IN%"diavolo@engin.umich.edu" X-Vms-Cc: IN%"NetBSD-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com >Basically, with the second 2091 card plugged in, flipping the power >switch does nothing at all. No lights turn on, no motors turn on, no >noises *nothing.*. I thought that I burned out the motherboard after I >plugged that second 2091 in! I removed the second 2091 and flipped the >switch everything was a-ok. > >I know that multiple gvp scsi's are no problem, I also know that putting >a gvp SII and a supra wordsync is also no prob. I have no idea why 2 >2091's prevent powering up. I have a similar setup with no problems. I have a GVP 040 Combo, which has its own GVP SII scsi, and 2 A2091's. Both of the 2091 have the autoboot jumper set to DISABLE AUTOBOOT. I don't see why that would cause a problem. Do you have HD's mounted on the 2091's using the onboard power plug? I don't see how you could have a power problem, unless one of the 2091's is fried. Do both of them work? I blew my serial port a while back by frame grounding the +12/-12 while gropping for the serial port! (Listen to the warnings about plugging in cables with the machine on!!) Anyway, it basically shorted the serial ship, shorting +12/-12 together. The machine would not come on with the motherboard getting both +12/-12. It would work when I unplugged either from the motherboard. Maybe you have the same problem. The power supply WILL NOT come on if it detects a short. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 20:39:33 1993 Subject: Re: Some really silly questions! To: netbsd-amiga@cbmuucp.commodore.com From: Frank "Crash" Edwards Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 930 Sender: NetBSD-Admin@cbmuucp.commodore.com mykes@shell.portal.com sayeth: > Ty> - Support HD floppies (now that I actually have one :->) > Ty> HD support should not require differnet minor numbers, > Ty> but be automatic with detection of the HD hole. (are the > Ty> low-level programming details of HD floppy drives > Ty> documented anywhere? I don't think the Hardware RKM > Ty> covers them). > >I don't suspect there's much difference for the HD floppies to the >software. Perhaps only #sectors/track is the only difference :-) >Also a switch in cia register (or whatever) to make the drive go >half speed. I believe the hardware spins the drive at the reduced speed when it detects the whole, ie. there's no software control. As you pointed out above, only sectors/track is different. -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data: 813/787-3675 crash@azhrei.EEC.COM From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 20:57:11 1993 From: Bill Squier To: amigaman@esu.edu, mw@eunet.ch Subject: Re: X11R5, MMU Panic, etc. Cc: NetBSD-Amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >From: mw@eunet.ch (Markus Wild) >Message-Id: <199312090855.JAA25327@eunet.ch> >Subject: Re: X11R5, MMU Panic, etc. >> I just tried xterm -C, and it works for me. I'm using the 714 kernel, and >> X11R5. I started X as root, and I executed the xterm -C as root also. >> Then, I logged in as myself in another xterm, and did an su. The message >> popped up in the other xterm - no problem. As did several silo overflow >> messages when running term (is there any way to speed up that serial >> driver code?). > >You're serious about those silo overflows???? This would mean that a >level 5 interrupt driver, which is hardly blocked out, was still not fast >enough to keep up with incoming data. This driver puts incoming characters >into a ring buffer, and at vbl-level this buffer is then emptied into the >regular tty queue. Having a silo-overflow (instead of the ringbuffer filling >up) would mean that the UART gets a new character without the first having >been read. At what speed are you running the serial port? I'm running >ppp on 38k4 for a long time, and never had any such problems... > I get them all the time on my lowly A2000 (GVP@33Mhz 030). 38.4K SLIP connection to my 486. -wps From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 21:13:07 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: FAQ From: Guenther Grau Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all, I always think twice, before I post something to the mailinglist to to a newsgroup, but this time it think it is really necessary to show up. The reason is that there have been a lot of questions concerning the FAQ. I would like to clear things up. The current author of the NetBSD-Amiga-FAQ is Guenther Grau (s_grau@ira.uka.de), which is me :-). Unless someone comes up and provides us with a better FAQ or is willing to take my job over, I will try to do my best to maintain it. I have two problems doing my job: 1) Limited time: Yes, I know everybody complains about this, but it is very difficult to maintain the NetBSD-Amiga-FAQ those days, because NetBSD is devoloping that fast. When things have settled down a bit, maintaining the FAQ will possible be an easier job to do. Each time I rewrite the FAQ, I only see that it is already old, before I am able to release it. 2) Hardware limitations: I currently don't have the necessary hardware to run NetBSD on (A1000 :-(), and I am missing the money to buy me a new Amiga :-(. Therefore, when it comes to NetBSD specific questions, I am not able to speak from my own experience, but I have to rely on what is said on the mailing-list. So, you may ask: Why are you doing this job? I volunteered, because I thought somebody had to do it. I have worked with unix for more than four years now and I therefore have a good knowledge of unix. I even know the internals of unix quite well, as operating systems fascinated me from the beginning. I also wanted to support NetBSD in the way I am able to, without the needed hardware. I wanted to free the developers from this task, because they can do more useful things than writing docs, which they don't write anyway :-) Now, for the future of the FAQ. I would like to restructure the FAQ and divide it into several seperate sections, which could be maintained by different people. I would like mtk to make a directory called docs and put all the documents we have in there. We should also remove the obsolete docs, as they may be confusing. There should be sections on o A general overview o An installation guide o A troubleshooting-section (the real FAQ) o A compatibility list o A networking guide o An X-Windows guide o A general Unix-guide o Who is working on what o A wish list o ... David (David.Crooke@dcs.edinburgh.ac.uk) volunteered to write a new super-dooper up-to-date installation guide, so i can remove this section from the FAQ :-) Anybody else, who wants to contribute to the documentation or wants to take over the maintainance of a seperate section, please feel free to contact me. Guenther (s_grau@ira.uka.de, Maeuschen@irc) P.S.: I will upload the "current" version of the FAQ to ftp.eunet.ch now. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 22:09:43 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X11R5, MMU Panic, etc. To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: amigaman@esu.edu, mw@eunet.ch, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 444 Sender: NetBSD-Admin@cbmuucp.commodore.com > I get them all the time on my lowly A2000 (GVP@33Mhz 030). 38.4K SLIP > connection to my 486. Hmm.. does anybody else have this problem, and does *NOT* have a GVP board? I really start to think that the best thing you can do with GVP boards is to use them as door stops... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 22:45:16 1993 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd-amiga@cbmuucp.commodore.com Subject: netbsd Sender: NetBSD-Admin@cbmuucp.commodore.com I would like to know if support for other hard drive controller is included in the current release of NetBSD.Is it possible to have a compatibility list? Also what will happen is you have more than one scsi controller in your machine ,which scsi host that BSD will prefer? Thanks for you help, Michel Beausejour mbeausej@qc.bell.ca From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 9 23:21:20 1993 From: Bill Squier To: groo@menger.eecs.stevens-tech.edu, mw@eunet.ch Subject: Re: X11R5, MMU Panic, etc. Cc: NetBSD-Amiga@cbmuucp.commodore.com, amigaman@esu.edu Sender: NetBSD-Admin@cbmuucp.commodore.com >From: mw@eunet.ch (Markus Wild) >Subject: Re: X11R5, MMU Panic, etc. >> I get them all the time on my lowly A2000 (GVP@33Mhz 030). 38.4K SLIP >> connection to my 486. > >Hmm.. does anybody else have this problem, and does *NOT* have a GVP >board? I really start to think that the best thing you can do with GVP >boards is to use them as door stops... > You are correct. It is soley a GVP problem, as they are unable to properly implement DMA with their boards. The "fix" is to patch the DMA xfer size down to 512bytes, as previously stated on this list. What GVPPatch does under AmigaDOS is monitor calls to OpenDevice() to activate the patch only during serial transfer sessions. (I _believe_ they hook OpenDevice(), haven't looked at the source...) So, in theory, a "fix" for NetBSD would be to watch serial port opens and patch the DMA size, or simply fix the DMA size at 512bytes all the time. (or even just turn it off). -wps From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 00:12:28 1993 From: Calvin Chu Subject: Somebody Upload? To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com Can somebody upload makebsd for the amiga to the NetBSD directory? I can't find this anywhere. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 00:24:06 1993 From: niklas@appli.se (Niklas Hallqvist) To: groo@menger.eecs.stevens-tech.edu Cc: groo@menger.eecs.stevens-tech.edu, mw@eunet.ch, NetBSD-Amiga@cbmuucp.commodore.com, amigaman@esu.edu Subject: Re: X11R5, MMU Panic, etc. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Bill" == Bill Squier writes: Bill> You are correct. It is soley a GVP problem, as they are unable Bill> to properly implement DMA with their boards. The "fix" is to Bill> patch the DMA xfer size down to 512bytes, as previously stated Bill> on this list. What GVPPatch does under AmigaDOS is monitor Bill> calls to OpenDevice() to activate the patch only during serial Bill> transfer sessions. (I _believe_ they hook OpenDevice(), haven't Bill> looked at the source...) Bill> So, in theory, a "fix" for NetBSD would be to watch serial port Bill> opens and patch the DMA size, or simply fix the DMA size at Bill> 512bytes all the time. (or even just turn it off). Very, very, ugly... But I will probably do just that (the seropen thingy), but I doubt MTK would want to incorporate such code in his pet :-) I'll look into it after the next source release, as I think MTK said the serial driver had changed. Niklas From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 00:47:25 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Some really silly questions! Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article Frank "Crash" Edwards writes: > I believe the hardware spins the drive at the reduced speed when it > detects the whole, ie. there's no software control. As you pointed > out above, only sectors/track is different. The software has to be able to tell when it's opeating on a HD floppy, though, else it would only read the first half of tracks (or maybe read a double-length track into a regular-sized track buffer). AFAIK, the speed is controlled by the hole and not by software, but the software is still going to have to know how what to do when operating on HD floppies. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 00:50:16 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A2630 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article Russel Miranda writes: > > > Ah... that's one bit of information. Have you tried making config > > entries for each controller, say sd, s2d, and s3d, to see if it will > > work? > > No. How would I put that in the config file? I'll try it out next kernel > compile if you give me some tips. This is completely untested, but I'm guessing the relevant parts would look something like: master gvp11scsi0 at manufacturer 2017 product 11 master gvp11scsi1 at manufacturer 2017 product 11 master gvp11scsi2 at manufacturer 2017 product 11 # each one picks off the first unused configdev that matches, right? disk sd0 at gvp11scsi0 slave 0 disk s1d0 at gvp11scsi1 slave 0 disk s2d0 at gvp11scsi2 slave 0 disk sd1 at gvp11scsi0 slave 1 disk s1d1 at gvp11scsi1 slave 1 disk s2d1 at gvp11scsi2 slave 1 # ... 2,3,4,5 ... disk sd6 at gvp11scsi0 slave 6 disk s1d6 at gvp11scsi1 slave 6 disk s2d6 at gvp11scsi2 slave 6 tape st0 at gvp11scsi0 slave ? tape s1t0 at gvp11scsi1 slave ? tape s2t0 at gvp11scsi2 slave ? tape st1 at gvp11scsi0 slave ? tape s1t1 at gvp11scsi1 slave ? tape s2t1 at gvp11scsi2 slave ? Is this correct? -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 02:09:27 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: X11R5, MMU Panic, etc. To: NetBSD-Admin@cbmuucp.commodore.com (Niklas Hallqvist) Cc: groo@menger.eecs.stevens-tech.edu, mw@eunet.ch, NetBSD-Amiga@cbmuucp.commodore.com, amigaman@esu.edu X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Bill> So, in theory, a "fix" for NetBSD would be to watch serial port > Bill> opens and patch the DMA size, or simply fix the DMA size at > Bill> 512bytes all the time. (or even just turn it off). Right now I run scsi_no_dma *all* the time, I would be happy for a cleaner patch that simply lowered the transfer size *all* the time and didn't try and guess when was a good time. You see with DMA on it also steps on Display priorities, and so you get messy jumpy displays if you are running with an interlaced screen. > > Very, very, ugly... But I will probably do just that (the seropen thingy), > but I doubt MTK would want to incorporate such code in his pet :-) > I'll look into it after the next source release, as I think MTK said the > serial driver had changed. Please Niklas :^) just turn it on all the time keep my displays from jumping :^) Or even better yet, supply support for the GVP I card becuase then I can drop this 22Mhz GVP accelerator and plug my 25Mhz 2630 back in. I understand you may be busy however so just do what you can find time to do. If I have to leave scsi_no_dma on then I will. :^) > > Niklas > Chris. From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 11:55:39 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Multiple Controllers To: diavolo@engin.umich.edu (Calvin Chu) Cc: mw@eunet.ch, NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 687 Sender: NetBSD-Admin@cbmuucp.commodore.com > Basically, with the second 2091 card plugged in, flipping the power > switch does nothing at all. No lights turn on, no motors turn on, no Hm, perhaps you're drawing too much current off the power supply with two 2091? Do both have an internal drive hooked to them (ie. drawing power from the Z2 bus)? Amiga power supplies (at least mine in the A3000, and to what I remember, in my previous A2000 too) usually shut down if too much current is drawn from them. That would explain your machine not doing anything... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 12:41:16 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: X11R5, MMU Panic, etc. To: niklas@appli.se (Niklas Hallqvist) Cc: groo@menger.eecs.stevens-tech.edu, mw@eunet.ch, NetBSD-Amiga@cbmuucp.commodore.com, amigaman@esu.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1105 Sender: NetBSD-Admin@cbmuucp.commodore.com > Bill> So, in theory, a "fix" for NetBSD would be to watch serial port > Bill> opens and patch the DMA size, or simply fix the DMA size at > Bill> 512bytes all the time. (or even just turn it off). > > Very, very, ugly... But I will probably do just that (the seropen thingy), > but I doubt MTK would want to incorporate such code in his pet :-) > I'll look into it after the next source release, as I think MTK said the > serial driver had changed. I uploaded new stuff today.. it's still in incoming, and I guess I'll at least extract kernel sources from the generic source archive, but for those that can't wait: there are new bin- archives, names should be obvious. I didn't upload a new "share", this is pretty static. Didn't upload new kernel binary yet, the kernel sources are included in src0712.tar.gz though. Please make sure to use new loadbsd (either recompile from sources, or get new binary out of the bin/ directory). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From markus@TechFak.Uni-Bielefeld.DE Fri Dec 10 14:53:05 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA14187; Fri, 10 Dec 93 08:43:15 EST Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA07501; Fri, 10 Dec 93 08:42:54 EST Received: from techfac.TechFak.Uni-Bielefeld.DE by cbmmail.commodore.com (4.1/SMI-4.1) id AA14178; Fri, 10 Dec 93 08:42:51 EST Received: from gimpel.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA15648; Fri, 10 Dec 1993 14:42:50 +0100 Received: by gimpel.techfak.uni-bielefeld.de (4.1/pk.931118/dumb) id AA28344; Fri, 10 Dec 93 14:42:48 +0100 Message-Id: <9312101342.AA28344@gimpel.techfak.uni-bielefeld.de> From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Date: Fri, 10 Dec 1993 14:42:47 MET In-Reply-To: jvasher@cquest.mi.org (Joe Vasher) "Latest version of IXem.library" (Dec 9, 1:30pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: jvasher@cquest.mi.org (Joe Vasher), netbsd@cbmuucp.commodore.com Subject: Re: Latest version of IXem.library Status: RO On Dec 9, 1:30pm, Joe Vasher wrote: > Subject: Latest version of IXem.library > > > My Mail FTP site only has version 39.44 of the ixem.library. Could someone > PLEASE! send me the latest version of ixem.library... Or maybe someone that is > in michigan could give me the number to a bbs that has it to download.. Thanks. No need. All you need for loadbsd it what you have. Dont worry about loadbsd to complain about Inet: -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 17:12:08 1993 From: Alain Chofardet Subject: Test To: NetBSD-Amiga@cbmuucp.commodore.com (ML NetBSD) Mailer: Elm [revision: 72.14] Sender: NetBSD-Admin@cbmuucp.commodore.com If you see this message, please tell me "hello". Thanks. Alain Chofardet. From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 18:03:05 1993 From: Calvin Chu Subject: Re: Multiple Controllers To: Markus Wild Cc: NetBSD-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Fri, 10 Dec 1993, Markus Wild wrote: > Hm, perhaps you're drawing too much current off the power supply with > two 2091? Do both have an internal drive hooked to them (ie. drawing power > from the Z2 bus)? Amiga power supplies (at least mine in the A3000, and to > what I remember, in my previous A2000 too) usually shut down if too much > current is drawn from them. That would explain your machine not doing > anything... Well, I don't really need the second 2091. I'm just using it as a hard drive mounting "bay." I have the 2091 pluggeed in but unslotted and my machine is running fine. Can somebody compile me a v713 kernal that'll work on an A2000, 68030/MMU/FPU 8 megs 32 bit, 2 megs fast, 1 meg chip, (11 megs) that's running on a 2091 with all BSD partitions residing in one hard drive? I want to get into this but it seems that the NetBSD development outstripped the compilibility from the AmigaDOS side. I hear the next version of the kernal may reecognise my configuration better... right now, BSD thinks i have a 32 bit dma controller. . . o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAizPXUAAAAEEANNwzasX+nZfGPb4R/DaJ4z7kF2mBgyYsqTR4fMRyqJTeRMw aHBJlbZztiTKk2ZpzamCS6xroG6m34M5kwtuk2OMOb19sWa3y7YPWFx1qdk3ZQ06 /TdRy/nYIIWzG4+myMymnvYHZlgaoEGVTZfS9U+Tqv6AtDym6ZYplMRSmDTBAAUR tCpDYWx2aW4gQ2h1IDxkaWF2b2xvQGF6dXJlLmVuZ2luLnVtaWNoLmVkdT4= =9MhY -----END PGP PUBLIC KEY BLOCK----- From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 10 18:22:25 1993 From: jma@sunspot.ssl.berkeley.edu (Jim Alexander) Subject: Please take me off To: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 277 Sender: NetBSD-Admin@cbmuucp.commodore.com To whoever the list admin is: Please remove me! -- -------------------------------------------------------------------------- Jim Alexander | "If there's nothing wrong with me, there jma@sunspot.ssl.berkeley.edu| must be something wrong with the universe." From jvasher%cquest%mbsun.mlb.org@heifetz.msen.com Fri Dec 10 22:01:20 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA15271; Fri, 10 Dec 93 15:51:55 EST Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA07748; Fri, 10 Dec 93 15:51:32 EST Received: from garnet.msen.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA15262; Fri, 10 Dec 93 15:51:29 EST Received: from heifetz.msen.com by garnet.msen.com with smtp (Smail3.1.28.1 #11) id m0p8EoK-000EgeC; Fri, 10 Dec 93 15:51 EST Received: by heifetz.msen.com (/\==/\ Smail3.1.22.1 #22.11) id ; Fri, 10 Dec 93 15:51 EST Received: by mbsun.mlb.org (/\==/\ Smail3.1.28.1 #28.10) id ; Fri, 10 Dec 93 15:49 EST Received: by cquest.mi.org (V1.16/Amiga) id AA002y5; Thu, 9 Dec 93 07:22:56 EST Date: Thu, 9 Dec 93 07:22:56 EST Message-Id: <9312091222.AA002y4@cquest.mi.org> X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd@cbmuucp.commodore.com Subject: Formating the drives then mounting. Status: RO I followed the Install document almost exactly right down to the number of partitions and sizes with very minor differences (I think) The proj or bsd_proj was limited to 10 megs instead of 20 megs. Also, I used unit 5 for the the /proj /opt /home /home2 /usr. Well everything went smooth right upto the point were I went to format the drives.. I did that like stated in the install guide.. newfs /dev/rsd5d newfs /dev/rsd5e newfs /dev/rsd5f newfs /dev/rsd5g newfs /dev/rsd5h Above was one of my other minor changes unit 5 instead of 1. I got the following errors; incorrect arguement (something close to that) cannot read label from disk.. (something along those lines) I did as the docs stated and ignored (even though I think the first one shouldn't have been) and formated all the drives. I then created my fstab file and inserted the unit 5 in place of the unit 1 and it would not mount them.. Said something about a super block... I'm sure I missed something but can anyone offer suggestions on what to check from here.. Couple of notes. I have vmunix.714 and I'm not sure what verision the rootfs file that I got was. But I think it's real old because the readme's that came with it were only at 450. One other problem I noticed when booting up it will say found seven megs of ram, Yet I actually have 9 megs 8 of which is fast 32 bit, and 1 meg of chip. Once I had it boot up were it saw all 8 megs. But don't know why this happened... Do I have to format the sd6b or the /tmp. At least what I have read in the install docs mention nothing of this. Thanks -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 11 16:00:32 1993 From: mw@eunet.ch (Markus Wild) Subject: sorry, missing symlinks To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 901 Sender: NetBSD-Admin@cbmuucp.commodore.com In my recent upload I forgot to include the following symlinks, please add them if you consider recompiling the sources: 115492 2 lrwxr-xr-x 1 root 10 13 Nov 28 15:16 /usr/src/gnu/usr.bin/gas/config/Makefile.amiga -> Makefile.m68k 107553 2 lrwxr-xr-x 1 root 10 4 Nov 28 15:48 /usr/src/gnu/usr.bin/ld/amiga -> m68k 109174 2 lrwxr-xr-x 1 root 10 7 Dec 2 21:04 /usr/src/usr.bin/gprof/amiga.c -> hp300.c 109209 2 lrwxr-xr-x 1 root 10 7 Dec 2 21:04 /usr/src/usr.bin/gprof/amiga.h -> hp300.h Sorry. Then, I apparently forgot to upload bin-sbin.tar.gz, I'm right now doing this. Last thing: there's no new /bin/sh, please keep your old one!! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 11 17:55:22 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Rootfs Sender: NetBSD-Admin@cbmuucp.commodore.com The he who makes a new rootfs he may consider to include a /etc/termcap and some basic network tools, i.e. ftp, rz/sz, preinsalled /etc/remote. Yesterday i tried netbsd on my Amiga 2000 (beaver) running on a 40MB squest media and ran into the problem, that i could start the network (Ethernet) but couldnt get any byte because ftp (/usr/bin/ftp) was missing :) And it is really annoying that you dont have a termcap in the generic rootfs, because you cant do anything off the box. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 11 18:28:08 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Problems with moving files from AMIGA DOS TO NETBSD Sender: NetBSD-Admin@cbmuucp.commodore.com I have spent the last day trying to move files from amiga dos to netbsd. I have followed the instructions (OLD AS THEY MAY BE). But for some reason it will not find the files. Here's what I tried: filetodev 151206 67686 bin.tgz gvpscsi.device 5 1000 my quatums info: BSD_HOME start cyl 869 End cyl 1258 blocks per cyl 174 heads 1 from netbsd I type mount -av (everything mounts up after useing an older kernal vmunix.644 to format the drives.) Under both kernal verisons 644 and 714 I have tried using: Tar xzvfp /dev/rsd5g errors cannot uncompress: file or directory not found. I also can't see the files. So after trying everything I can think of. I switch to the modem install. (DAMN KERMITS A BITCH TO SETUP) I have an IBM sitting next to my amiga. So I put the newfs.gz disklabel.gz and ps.gz on the ibm managed to null modem (I have no hair left on my head) all the files over to netbsd... and then tried Tar xzvfp /home/ps.gz same warnings no file no directory. I tried this on both kernal versions.... Anyways, I gots no more hair to pull. Can anyone see mistakes I'm making. I would really like to get the filetodev method working.. But I can't see no way to do this.. Is there a program that comes with the rootfs that will handle just .gz files if so How THE HELL do I use it... I at least managed to get the newfs.gz and disklabel.gz and ps.gz (WHAT EVER THAT IS) onto netbsd. So I don't think i'm in all that bad of shape. Also, If someone can tell me a place to ftp docs/manuals/sugestions/readme files that explains these features and commands I will search the ends of the earth and get those files. The only ones I know of is some aman.tar.z or something like that but have not found them. Please Help! k -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 02:55:54 1993 From: Kevin M Mccarthy Subject: vmunix.720 To: netbsd-amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 804 Sender: NetBSD-Admin@cbmuucp.commodore.com I am not sure that I am not doing something wrong, but when I use vmunix.720 on my 4meg fast 2meg chip A3000 with ECS display, I get a blank grey screen, nothing else, no drive activity nothing.. Is there something that needs to be binpatched? Any help would be appreciated. BTW every other kernel since WAY BACK (pre 644) has worked fine. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 03:31:58 1993 From: oster@skorpio.usask.ca Subject: Re: vmunix.720 To: NetBSD-amiga@cbmuucp.commodore.com X-Envelope-To: NetBSD-amiga@cbmuucp.commodore.com Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com On 11 Dec 1993 19:52:59 -0600 (CST) Kevin M Mccarthy said: > > I am not sure that I am not doing something wrong, but when I use > vmunix.720 on my 4meg fast 2meg chip A3000 with ECS display, I get a blank > grey screen, nothing else, no drive activity nothing.. Is there something > that needs to be binpatched? Any help would be appreciated. BTW every other > kernel since WAY BACK (pre 644) has worked fine. You are not alone.... 720 on my machine (12meg fast, 2meg chip, A3000, ECS) doesn't work either. Nor do any of the 5 other kernels I've compiled today from the new sources :-( . What are we missing? The time the kernels work is after I run "term 3.4" (Under AmigaDOS, not term1.08 under NetBSD) I've tried the kernels with both the original (well, the second most recent release) and the new versions of the /bin and /sbin files. On the times it come up, it says it's opened a 640x400 4 color display. The screen is black, all the characters are about half as high as they should be, and they are all multi-colored and hard to read. The "text" screen is about 80x98 (yup.. 98 rows of text... go figure...) BTW: you still get kernel panics when you try and run X11 under 720 :-( . I re-directed the output of my script to /dev/null, and it made it a little further... but I ended up with a blank screen and was forced to hard-reboot... :-( I initially suspected that the kernel was somehow defaulting to some "different" display mode (or for some graphics card), but I disabled everything other than the "hires interlace", and it still wouldn't work. (turning on debugging (acdebug) doesn't help either... the screen just goes blank, and stays that way (CTRL-Amiga-Amiga) I've tried compiling with the "views" stuff, but I must have missed something, because I couldn't get it to compile properly... I'm still hoping I can figure out what the problem with 720 is, but I'm running out of things to try.... > > -- > Kevin McCarthy signals@krypton.mankato.msus.edu Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 06:10:42 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: vmunix.720 To: NetBSD-Admin@cbmuucp.commodore.com (Kevin M Mccarthy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I am not sure that I am not doing something wrong, but when I use > vmunix.720 on my 4meg fast 2meg chip A3000 with ECS display, I get a blank > grey screen, nothing else, no drive activity nothing.. Is there something > that needs to be binpatched? Any help would be appreciated. BTW every other > kernel since WAY BACK (pre 644) has worked fine. You need the newest loadbsd in NetBSD-Amiga/bin/. > Kevin McCarthy signals@krypton.mankato.msus.edu Chris. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 06:20:17 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: vmunix.720 To: NetBSD-Admin@cbmuucp.commodore.com Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > You are not alone.... 720 on my machine (12meg fast, 2meg > chip, A3000, ECS) doesn't work either. Nor do any of the 5 other > kernels I've compiled today from the new sources :-( . What are we > missing? The time the kernels work is after I run > "term 3.4" (Under AmigaDOS, not term1.08 under NetBSD) > I've tried the kernels with both the original (well, the second most > recent release) and the new versions of the /bin and /sbin files. When was the last time you downloaded the loadbsd program? It has changed more than once. It won't boot unless you have the right loadbsd binary. > > On the times it come up, it says it's opened a 640x400 4 color > display. The screen is black, all the characters are about half as > high as they should be, and they are all multi-colored and hard to > read. The "text" screen is about 80x98 (yup.. 98 rows of text... go Hmm, have you been following this group? This was explained, its 2024 mode, it needs to be enabled but you need to change _ite_default_height to something alot less than 800 (which it will be) if your getting the weird colors and 98 rows of text. > figure...) BTW: you still get kernel panics when you try and run X11 > under 720 :-( . I re-directed the output of my script to /dev/null, > and it made it a little further... but I ended up with a blank screen > and was forced to hard-reboot... :-( > > I initially suspected that the kernel was somehow defaulting to some > "different" display mode (or for some graphics card), but I disabled This is indeed what happend. > everything other than the "hires interlace", and it still wouldn't work. I am suprised it compiled :^). > (turning on debugging (acdebug) doesn't help either... the screen > just goes blank, and stays that way (CTRL-Amiga-Amiga) > > I've tried compiling with the "views" stuff, but I must have missed > something, because I couldn't get it to compile properly... I am going to re-release some patches now that I have the new source. > > I'm still hoping I can figure out what the problem with 720 is, but > I'm running out of things to try.... > > Greg Oster Chris. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 07:01:41 1993 From: oster@skorpio.usask.ca Subject: Re: vmunix.720 To: NetBSD-amiga@cbmuucp.commodore.com X-Envelope-To: NetBSD-amiga@cbmuucp.commodore.com Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com > > You are not alone.... 720 on my machine (12meg fast, 2meg > > chip, A3000, ECS) doesn't work either. Nor do any of the 5 other > > kernels I've compiled today from the new sources :-( . What are we > > missing? The time the kernels work is after I run > > "term 3.4" (Under AmigaDOS, not term1.08 under NetBSD) > > I've tried the kernels with both the original (well, the second most > > recent release) and the new versions of the /bin and /sbin files. > > When was the last time you downloaded the loadbsd program? I compiled the one that came with the 0712 source :-) (That be new enough :-) (I also have the 713 loadbsd...) > It has > changed more than once. It won't boot unless you have the right > loadbsd binary. > > > > > On the times it come up, it says it's opened a 640x400 4 color > > display. The screen is black, all the characters are about half as > > high as they should be, and they are all multi-colored and hard to > > read. The "text" screen is about 80x98 (yup.. 98 rows of text... go > > Hmm, have you been following this group? Yup... since the beginning :-) > This was explained, its 2024 > mode, it needs to be enabled but you need to change > _ite_default_height to something alot less than 800 (which it will be) > if your getting the weird colors and 98 rows of text. Ya.. Ok.. I had assumed (perhaps foolishly?) that it wouldn't have been left for a default of 2024... (I looked thru the old messages and found the discussion from earlier this week - I'd read them when they were first posted, but this has been a busy week :-) ) > > figure...) BTW: you still get kernel panics when you try and run X11 > > under 720 :-( . I re-directed the output of my script to /dev/null, > > and it made it a little further... but I ended up with a blank screen > > and was forced to hard-reboot... :-( > > > > I initially suspected that the kernel was somehow defaulting to some > > "different" display mode (or for some graphics card), but I disabled > > This is indeed what happend. > > > everything other than the "hires interlace", and it still wouldn't work. > > I am suprised it compiled :^). Well... it took a but of "convincing" :-) (The Makefile generated by config is forcing the compile of the pal, 2024, etc. stuff.. I just had to turf the appropriate reference to the .o files, and it linked just fine..) > > (turning on debugging (acdebug) doesn't help either... the screen > > just goes blank, and stays that way (CTRL-Amiga-Amiga) > > > > I've tried compiling with the "views" stuff, but I must have missed > > something, because I couldn't get it to compile properly... > > I am going to re-release some patches now that I have the new source. I'll be waiting :-) > > > > I'm still hoping I can figure out what the problem with 720 is, but > > I'm running out of things to try.... > > > > > Greg Oster > > Chris. Thanks for the info... I'm off to see if I can't get a good compile... Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 07:19:44 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix.720 Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 11, 11:55pm, oster@skorpio.usask.ca wrote: > > > > You are not alone.... 720 on my machine (12meg fast, 2meg > > > chip, A3000, ECS) doesn't work either. Nor do any of the 5 other > > > kernels I've compiled today from the new sources :-( . What are we > > > missing? The time the kernels work is after I run > > > "term 3.4" (Under AmigaDOS, not term1.08 under NetBSD) > > > I've tried the kernels with both the original (well, the second most > > > recent release) and the new versions of the /bin and /sbin files. > > > > When was the last time you downloaded the loadbsd program? > > I compiled the one that came with the 0712 source :-) (That > be new enough :-) (I also have the 713 loadbsd...) I wouldn't bet on it! The new kernel is expecting another data structure following the ConfigDev structure at the end of the kernel. The loadbsd from 713 won't include that data structure - the new loadbsd will. [In case anyone is curious as to what that data structure is, it's a list of the memory segments from the AmigaDOS MemList. One small step toward support of multiple memory areas.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 09:05:16 1993 To: Amiga NetBSD List Subject: Question about WD33C93A PROTO chip, and more disk info From: ggk@tirith.uucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com Okay, this has probably been beaten to death BEFORE I joined the mailing list, but... I had my A3000 apart today, and I have a chip labelled: WD33C93A-PL 00-04 9035 040157190102 PROTO which I'm assuming is a prototype version of the controller chip. From what I've read on this list so far, NetBSD won't run for me until I upgrade that chip to a non-PROTO version. I'd like to know what the problems are with the PROTO chip, because NetBSD does run for me (this might be worth including in the FAQ so people with PROTO chips can suspect the problem without having to rip their machine apart). However, I have not yet managed to get an entire /usr partition going, so I've never really gone to multi-user mode (only as far as the login: prompt). I do get the occasional SCSI sense error message on the console, but I attribute these to faults on the drive (the drive is flaky under AmigaDOS, and the sense errors always occur on the same disk blocks, so I really doubt it's the driver or the controller). Is it possible the scsi driver has been fixed to work with the prototype chip, or have I simply not done anything to invoke the problem? Finally, I'm one step (financial justification) away from buying a large Hitachi rigid disk for my Amiga, mainly to run NetBSD. Does anyone have any comments about/experience with Hitachi drives? Thanks for any information. Gregory Kritsch | 3A Computer Engineering at UWaterloo ggk@tirith.uucp | "Life is a highway ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 09:11:56 1993 From: Roy Trevino To: netbsd-amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: Alternative X11 server "Xami" uploaded to eunet Sender: NetBSD-Admin@cbmuucp.commodore.com Ok, there seemed to be just enough interest in my xserver during the week to get me to upload it this weekend. So I have. Since I couldn't be absolutely sure it would work with the other X11R5 clients, libs, etc., I decided to make a small (2.5Mb compressed) standalone distribution (server, some fonts, some clients, but not many). So you can try it with only about 5Mb to spare, or just pull the server out of it and try that. It is monochrome only but small and fast. It only works with the 709 kernel currently, but my next project is to move it to the latest kernel and add lots of other features. I moved it to the incoming area on eunet under "Xami_rev0.tar.gz". Source available but not recommended at this stage. Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 09:38:13 1993 From: Alan Bair Subject: vmunix 720 loading & compiling problems To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I was working on the new rootfs, when all the 720 stuff showed up, so I thought I would switch to using that instead of 709. Well I have run into similar problems as reported below, which I'll now add to. Maybe I should stick with doing a 709 rootfs. > > > It has > > changed more than once. It won't boot unless you have the right > > loadbsd binary. > > I picked up the new one in the NetBSD-Amiga/bin and was able to boot my custom built kernel, but the orignal one failed with a nice blue screen. > > This was explained, its 2024 > > mode, it needs to be enabled but you need to change > > _ite_default_height to something alot less than 800 (which it will be) > > if your getting the weird colors and 98 rows of text. I had the same strange display on my custom kernel, I'll have to try this change. As Greg said, the mailing list (and work) has been very busy :) > > > everything other than the "hires interlace", and it still wouldn't work. > > > > I am suprised it compiled :^). > > Well... it took a but of "convincing" :-) (The Makefile generated by > config is forcing the compile of the pal, 2024, etc. stuff.. I just > had to turf the appropriate reference to the .o files, and it linked > just fine..) I tried turning off GRF_A2024 & GRF_PAL in the config file, but ended up with the following undefined references: std_dlace_copper_list[_size] & std_a2024_copper_list[_size]. I found that in grf_cc_global.c these are #ifdef'd out with GRF_A2024. It looks like the config options need some more consideration as to their affects. I don't need either of those modes, but they seem to be required at this point. Here are some other more general problems I found in building the kernel. This was all done using the 709/713 kernel and pre-720 /usr/... files. 1. The sys/lib/libkern/amiga/DEFS.h file needs updating as was mentioned with the 709(?) release to change "/**/" to "##". Is there maybe a new gcc or something else to avoid these patches. 2. The DEFS.h is also missing from the sys/lib/libkern/m68k directory. 3. The strncmp.s & strncpy.s files are missing from sys/lib/libkern/amiga. I copied them from my 709 area, which were previously copied from sun-lamp. 4. The Makefile built by config has LD=ld.old. This should be LD=ld. 5. The default config file AMIGA, has 040 FP support turned on, with the FPSP option. It seems like this should not be there considering there is a AMIGA40 config file. Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", will work again, it is very handy. With 720, it says it is loading, then syncing, then a grey screen and nothing more. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 09:56:46 1993 From: Alan Bair Subject: Re: Question about WD33C93A PROTO chip, and more disk info To: ggk%tirith@xenitec.on.ca Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Okay, this has probably been beaten to death BEFORE I joined the mailing > list, but... > > I had my A3000 apart today, and I have a chip labelled: > WD33C93A-PL > 00-04 9035 > 040157190102 > PROTO > which I'm assuming is a prototype version of the controller chip. From > what I've read on this list so far, NetBSD won't run for me until I > upgrade that chip to a non-PROTO version. It runs just fine with the PROTO chip. I had one until a few days ago. I had some strange behavior with tape and SyQuest drives, so I went ahead and upgraded. > > I'd like to know what the problems are with the PROTO chip, because > NetBSD does run for me (this might be worth including in the FAQ so > people with PROTO chips can suspect the problem without having to rip > their machine apart). However, I have not yet managed to get an entire > /usr partition going, so I've never really gone to multi-user mode (only > as far as the login: prompt). > > I do get the occasional SCSI sense error message on the console, but I > attribute these to faults on the drive (the drive is flaky under > AmigaDOS, and the sense errors always occur on the same disk blocks, so > I really doubt it's the driver or the controller). > > Is it possible the scsi driver has been fixed to work with the prototype > chip, or have I simply not done anything to invoke the problem? It apparently has some internal timing problems and hangs under certain cases. Markus worked hard on working around these problems, first with his work on MACH and now with NetBSD. As far as I know, he has succeded. > > Finally, I'm one step (financial justification) away from buying a large > Hitachi rigid disk for my Amiga, mainly to run NetBSD. Does anyone have > any comments about/experience with Hitachi drives? Sorry, don't have any advice on this. > > Thanks for any information. > > Gregory Kritsch | 3A Computer Engineering at UWaterloo > ggk@tirith.uucp | "Life is a highway > ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 10:28:28 1993 From: Calvin Chu Subject: Compile To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com Can somebody out there compile me a version of 713 or 714 or newer, that can boot into NetBSD from AmigaDOS? -- on a A2000/2091 setup that is. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 11:17:13 1993 From: Alan Bair Subject: Re: vmunix 720 loading & compiling problems To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > > This was explained, its 2024 > > > mode, it needs to be enabled but you need to change > > > _ite_default_height to something alot less than 800 (which it will be) > > > if your getting the weird colors and 98 rows of text. > > I had the same strange display on my custom kernel, I'll have to try this > change. As Greg said, the mailing list (and work) has been very busy :) I used binpatch to change the ite_default_height from 800 to 400 on both my custom kernel and the prebuilt one. This allowed both of these to boot under Ados. I then ran into problems with mounting /tmp, but this onlly required the bin-newest disklabel and newfs to fix. I put these in /sbin, hope that is correct. I built the iteconfig utility, nice wrork Chris. Now I need to work on the fontdumper code. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 14:18:11 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: vmunix.720 To: signals@krypton.mankato.msus.edu (Kevin M Mccarthy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 737 Sender: NetBSD-Admin@cbmuucp.commodore.com > I am not sure that I am not doing something wrong, but when I use > vmunix.720 on my 4meg fast 2meg chip A3000 with ECS display, I get a blank > grey screen, nothing else, no drive activity nothing.. Is there something > that needs to be binpatched? Any help would be appreciated. BTW every other > kernel since WAY BACK (pre 644) has worked fine. You *are* using the new loadbsd binary, I put one into bin/ on ftp.eunet.ch. Reason is, the new kernel expects to find a memory list after the kernel binary, and it gets pretty mean if there is no such thing there... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 14:21:51 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: vmunix.720 To: oster@skorpio.usask.ca Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 656 Sender: NetBSD-Admin@cbmuucp.commodore.com > > When was the last time you downloaded the loadbsd program? > > I compiled the one that came with the 0712 source :-) (That > be new enough :-) (I also have the 713 loadbsd...) It's not :-) Seriously, the new changes were necessary after Mike Hitch gave me his new patches to unify the '30 and '40 kernels. He implemented passing the ados memory lists into the kernel, something which I think makes perfect sense. So, you need a loadbsd that does the passing of this list.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 14:29:45 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: vmunix 720 loading & compiling problems To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1392 Sender: NetBSD-Admin@cbmuucp.commodore.com > 1. The sys/lib/libkern/amiga/DEFS.h file needs updating as was mentioned > with the 709(?) release to change "/**/" to "##". Is there maybe > a new gcc or something else to avoid these patches. No, but I have /lib/cpp be a symlink to the current cpp (i.e. in /usr/gnu/lib/gcc-lib/netbsd/2.5.6/cpp). Then, in I just have CPP=/lib/cpp -traditional in the Makefile templates in /usr/share/mk, and everything's fine. > 4. The Makefile built by config has LD=ld.old. This should be LD=ld. *NO*. The new ld (dealing with shared libs) can't currently generate a valid kernel, you have to use ld.old. > 5. The default config file AMIGA, has 040 FP support turned on, with the > FPSP option. It seems like this should not be there considering > there is a AMIGA40 config file. There is no longer an AMIGA40 generic configuration. You can of course try to build an '40 only kernel, but there is no reason any longer to build two kernels per distribution, kernels should now work on both cpus. > Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", > will work again, it is very handy. With 720, it says it is loading, then > syncing, then a grey screen and nothing more. I'm missing it too.. Mike?:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 14:45:27 1993 From: Abeech@splat.paxnet.com.au Subject: Where is /dev/par? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 271 Sender: NetBSD-Admin@cbmuucp.commodore.com Yo everyone, Hmmm... thats funny I have no /dev/par! What is the major/minor numbers so I can do a makedev? -- Adrian V. Beech E-Mail: adrianb@spectrum.adsp.sub.org Abeech@splat.paxnet.com.au From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 16:43:31 1993 From: tjhayko@io.org (Tom Hayko) Subject: where is vmunix.720? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 473 Sender: NetBSD-Admin@cbmuucp.commodore.com I'm trying to get NetBSD working on my A4000/A2091 combination (finally got the 2091 away from my wife :). I know that vmunix-40.713 won't work (it thinks I'm running on a 3000 and I get MMU faults, the same as Patrick Vervoorn), and I'm trying to get a copy of vmunix.720. I tried ftp.eunet.ch, att2.cs.mankato.msus.edu and ftp.luth.se and it does seem to be on any of them. Where can I get it? Will it work any better on my A4000/A2091? Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:15:58 1993 Subject: Keeping track of new releases From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I believe that someone (I volunteer myself) should maintain a list of current releases and the state of all software on ftp.eunet.ch. For example, I hear of a new kernel (720). This requires a new loadbsd. I think it introduces shared libraries, which may require new binaries (to take advantage of it). However, when building the kernel, you now need to use an older version of ld - the shared library-aware version won't work. Especially for someone not keeping absolutely current on the list, this can be overwhelming. What I propose is the following: I prepare a document detailing: - All additional functionality introduced by each kernel release - Requirements/suggestions to run the new kernel (e.g. new loadbsd, shared library binaries, new X stuff...) - Requirements to compile the new kernels. (I will test-compile before I update the list. Remember the problems with /src/lib/libc and gcc -traditional?) This way, anyone can at a glance ensure that s/he has all necessary software to upgrade the system, and that said upgrade will make a functional difference to the system. For example, I don't have an 040, so any upgrade whose only purpose is to provide 040 functionality is of no use to me. I can wait for the new kernels. To achieve these ends (if it is agreed that such a quick-start guide is a good thing), I would appreciate it if the people involved with building the new kernels would email me (in addition to posting to the mailing list) detailing what they did. After I test (or ask someone else to test if I don't have the right HW), then I will either update the document, or attempt to solve build problems privately. The document itself will be posted to this list, comp.unix.amiga, as well as on ftp.eunet.ch. If it is agreed to do this, then I would appreciate confirmation of the requirements to run .720. (Loadbsd, ld, etc.) Comments? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:32:30 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1199 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: vmunix720 color probs Sender: NetBSD-Admin@cbmuucp.commodore.com I just got vmunix720 from eunet and also updated my loadbsd and /bin and /sbin directory with the new archives. It boots all right and seems to work just fine except that the display is almost unreadable. I am getting some 80x100 characters in some kind of green/pink color combination. What is this, mega-interlace? :-) I noticed that some other people have the same problem, is there a fix for this? I am running on a standard ECS Amiga 500 with PPI040 and GVP controller. One other thing. With the new loadbsd program I can finally make use of my 32 bit memory, correct? Do we have a manual for the new loadbsd program somewhere? I don't have a clue as to what the new options mean. Basically I have 8MB of 16 bit Fast RAM and 4MB of 32 bit Fast RAM. Under 713 the 32 bit Fast RAM was completey ignored which did wonders when compiling (talking about an afternoon to compile tcsh!). Thanks, Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:47:42 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Where is /dev/par? To: Abeech@splat.paxnet.com.au Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 289 Sender: NetBSD-Admin@cbmuucp.commodore.com > Hmmm... thats funny I have no /dev/par! What is the major/minor > numbers so I can do a makedev? mkdev /dev/par c 11 0 -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:48:38 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Where is /dev/par? To: Abeech@splat.paxnet.com.au Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 203 Sender: NetBSD-Admin@cbmuucp.commodore.com Oops that should have been mknod :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:54:06 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: mw@eunet.ch Subject: Shared library programs under /bin Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com I noticed that the /bin/arch program uses shared libraries, there may be others. I thought all /bin /sbin programs used only statically linked libraries! It this a mistake on the NetBSD makefile and not a NetBSD-Amiga thing and... who do be report bugs to if they are a generic NetBSD problems? -Rob From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 17:58:05 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Shared library programs under /bin To: leland@wacky.acet.org (Robert Leland - PSI) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 794 Sender: NetBSD-Admin@cbmuucp.commodore.com > I noticed that the /bin/arch program uses shared libraries, > there may be others. /bin/arch should be a symlink to /usr/bin/machine, that's why it uses shared libs. It's there because some (read: SunOS) programs expect it to be in /bin. > I thought all /bin /sbin programs used only statically linked libraries! Correct. > It this a mistake on the NetBSD makefile and not a NetBSD-Amiga thing and... > who do be report bugs to if they are a generic NetBSD problems? It should be symlink to /usr/bin/machine, and isn't in /bin because it deserves to be there because of system maintenance, but because of compatibility. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 18:12:20 1993 From: Kevin M Mccarthy Subject: bin/loadbsd To: NetBSD-Amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 932 Sender: NetBSD-Admin@cbmuucp.commodore.com I've downloaded loadbsd from the bin directory twice from ftp.eunet.ch and Many times from att2.cs.mankato.msus.edu and they are both 6696 bytes long and refuse to execute. I get "loadbsd: file is not executable" when I try to run it. I have transfered it gziped and lharced and they extract okay, but won't run. I am using NcFTP so they should be transfered in binary format. Could someone please upload a gziped binary for the most recent loadbsd? Thanks in advance. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 19:06:45 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: AS To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com Well again I have as from markus (after recompile from sources) and as with the old one (bin-usr.bin...) Its flaky. Now however I think I need it and cannot suplement it with gas2.x becuase I need PIC (haven't taken the time to figure out what exactly PIC is :^) ). What do I mean by flaky? I mean I get odd errors as if ``as'' were trashing the stack. With the latest version it seems to always take the form: as: /var/tmp/cc000243.s:660: Error: Ignoring attempt to re-define symbol from 0. to 0 where that last 0 can be any old number. This only happens intermitently on the same source file so that why I figure its a memory trashig problem. Ugh, don't know what to do. I have some patches for grf_cc and friends but I cannot recompile the kernel to test them. Chris. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 19:35:45 1993 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: AS To: chopps@emunix.emich.edu (Chris Hopps) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 680 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well again I have as from markus (after recompile from sources) and as > with the old one (bin-usr.bin...) Its flaky. Now however I think I > need it and cannot suplement it with gas2.x becuase I need PIC > (haven't taken the time to figure out what exactly PIC is :^) ). BTW, can gas 1.38.1 from the gcc 2.3.3 package create pc relative code? This would be needed when I translate my boot block code to disk.. Then another thing.. at boot block executing time the display hasn't been opened. It would be quite nice to put some output from boot loader to console. So, how do I create a display where to put data (for example by graphics.library Move() and Text())?. ++Tero From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:06:22 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix 720 loading & compiling problems Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 2:30am, Alan Bair wrote: > 5. The default config file AMIGA, has 040 FP support turned on, with the > FPSP option. It seems like this should not be there considering > there is a AMIGA40 config file. Since the kernel now supports both the '030 and '040, a generic kernel should include the FPSP option to include the '040 floating point support. The only thing the FPSP option does now is control whether the FPSP package is included, or (if the FPSP option is missing) a dummy file that will cause kernel panics on any '040 floating point exception. > Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", > will work again, it is very handy. With 720, it says it is loading, then > syncing, then a grey screen and nothing more. It's been working on all my kernels, but I haven't checked the 720 kernel yet. It does boot and run on my '040 system (after patching _ite_default_heigth to 400). I'll check if the kernel reboot works on my system with the 720 kernel image. [It's also quite possible that I broke something on the '030 code since I am not able to test that yet.] Another thing to be aware of with the kernel reboot logic - the running kernel and the new kernel have to have an exact match in the locore.s code. This is because the running kernel copies the new kernel to chipmem, then shuts off the MMU. If the reboot code isn't an exact match, there will be a discontinuity between the mapped and unmapped code which you can guess might cause severe confusion. I've had lots of fun with this because of all the extensive changes I've made to locore.s Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:11:05 1993 From: tjhayko@io.org To: netbsd-amiga@cbmuucp.commodore.com Subject: More Amiga 4000/A2091 stuff Sender: NetBSD-Admin@cbmuucp.commodore.com I got vmunix720, and the new loadbsd, and gave it a try. The new kernel recognizes the 2MB on my A2091, but still thinks I am running on a A3000 with a 68040, and dies with MMU traps. Is this because it thinks I'm running an A3000? How do I binpatch _is_a4000 so that it knows it's running on an A4000? Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:19:52 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix 720 loading & compiling problems Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 2:23pm, Markus Wild wrote: > > 5. The default config file AMIGA, has 040 FP support turned on, with the > > FPSP option. It seems like this should not be there considering > > there is a AMIGA40 config file. > > There is no longer an AMIGA40 generic configuration. You can of course > try to build an '40 only kernel, but there is no reason any longer to > build two kernels per distribution, kernels should now work on both > cpus. The 720 kernel does boot and run on my '040 (after patching the _ite_default_height to 400). I don't know how you would build an '040 only kernel, unless you strip out all the '030 code :-). There shouldn't be any #ifdefs relating to '030/'040 stuff anymore. > > Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", > > will work again, it is very handy. With 720, it says it is loading, then > > syncing, then a grey screen and nothing more. > > I'm missing it too.. Mike?:-) Hmmm. I'll have to check if the 720 kernel will reload on my system. I may very well have broken the '030 portion of that. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:25:17 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: where is vmunix.720? Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 10:34am, Tom Hayko wrote: > I'm trying to get NetBSD working on my A4000/A2091 combination (finally got > the 2091 away from my wife :). I know that vmunix-40.713 won't work (it > thinks I'm running on a 3000 and I get MMU faults, the same as Patrick > Vervoorn), and I'm trying to get a copy of vmunix.720. I tried ftp.eunet.ch, > att2.cs.mankato.msus.edu and ftp.luth.se and it does seem to be on any of > them. Where can I get it? Will it work any better on my A4000/A2091? Wasn't the vmunix.720 in the incoming directory instead of the kernel directory? The 720 kernel will have a flag that you can binpatch to disable the A3000 check. The symbol is _a3000_flag and should be patched to 0 if you don't have an A3000, but do have memory above 0x07000000. There is also a corresponding flag for the A4000: _a4000_flag should be binpatched to a 1 to run on an A4000 (sorry, I haven't figured out a way to automatically detect it yet). I think it should work with the A2091. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:25:41 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: AS To: NetBSD-Admin@cbmuucp.commodore.com (Chris Hopps) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Well again I have as from markus (after recompile from sources) and as > with the old one (bin-usr.bin...) Its flaky. Now however I think I > need it and cannot suplement it with gas2.x becuase I need PIC > (haven't taken the time to figure out what exactly PIC is :^) ). Well I have an idea on why some binaries from markus (I also tried the as from the binary distrib) don't work. I think that the GVP accelerators may be broken in regards to odd aligned memory access could this be a problem? I ran across this when I was working on CrossPC. We had code to check for some wierdness only found on the GVP accelerators. I can look it up if anyone thinks this might be the problem. (I will probably do this anyway :^) Hmmm. Thats the only differenc I can think of (that matters) between Markus' 3000 and my 2000 (the one that doesn't matter I am guessing is available memory.) > > Chris. > Chris. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:33:42 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix720 color probs Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 11:23am, Stefan G. Berg wrote: > I just got vmunix720 from eunet and also updated my loadbsd and /bin > and /sbin directory with the new archives. It boots all right and > seems to work just fine except that the display is almost unreadable. > I am getting some 80x100 characters in some kind of green/pink color > combination. What is this, mega-interlace? :-) > > I noticed that some other people have the same problem, is there a fix > for this? I am running on a standard ECS Amiga 500 with PPI040 and GVP > controller. It's a problem with the new cc console stuff that tries to set up the display for the A2024. The quick fix is to binpatch _ite_default_height to 400. > One other thing. With the new loadbsd program I can finally make use > of my 32 bit memory, correct? Do we have a manual for the new loadbsd > program somewhere? I don't have a clue as to what the new options > mean. Basically I have 8MB of 16 bit Fast RAM and 4MB of 32 bit Fast > RAM. Under 713 the 32 bit Fast RAM was completey ignored which did > wonders when compiling (talking about an afternoon to compile tcsh!). Nope - not yet :-(. Someone will need to make the changes to amiga_init.c and pmap.c to handle non-contiguous memory if you want to use all the fast memory. The new loadbsd just passes all the memory segement information to the kernel, but the only thing the kernel can do with it at the moment is attempt to use the 16-bit memory as a DMA buffer for the A2091 and GVP11 scsi drivers [and I need to rethink how to do the GVP11 stuff now that I know that some GVP11 controllers can use DMA with 32 bit memory]. I put an option in loadbsd [-p, I think] that was going to force loadbsd to use the highest priority fast memory segement instead of the largest, but I didn't change the code to actually do it yet. In your case, that would only give you the ability to run NetBSD in the 4M 32 bit RAM - in which case the only use that could be made of the 16 bit memory would be as a DMA buffer for the GVP controller. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:39:56 1993 From: tero.manninen@oulu.fi (Tero Manninen) Subject: hard disk for A3000 & netbsd? To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 590 Sender: NetBSD-Admin@cbmuucp.commodore.com Is there any list of hardware what works with NetBSD? My interest is now directed to SCSI disks that would work with A3000 proto-scsi chip. One, quite interesting, option is to buy a 1G SCSI-2 disk (Seagate ST11200N 1050 MB 10,5 ms Fast-SCSI-2). Other possibilities include a ibm disk (IBM "Spittfire" 1050 MB 8.5 ms 512 kb cache Fast-SCSI-2) and a HP disk (Hewlett-Packard C2247 1050 MB 10,5 ms SCSI-2). A 2G disk would, of course, be better, but I'm not planning to spend that much money to a disk (like Seagate BARRACUDA, 2100 MB 6 ms) So, any experiences, recommendations? ++Tero From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:50:41 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Where is /dev/par? To: NetBSD-Admin@cbmuucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Yo everyone, > > Hmmm... thats funny I have no /dev/par! What is the major/minor > numbers so I can do a makedev? Well, if you need to know this stuff you can always look in sys/arch/amiga/amiga/conf.c There is an array organized by major device numbers. Minors are the unit numbers. I don't know what par is (on the amiga side at the moment) though. > -- > Adrian V. Beech E-Mail: adrianb@spectrum.adsp.sub.org Chris. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 20:58:15 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: vmunix 720 /dev/reboot problem Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 2:23pm, Markus Wild wrote: > > Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", > > will work again, it is very handy. With 720, it says it is loading, then > > syncing, then a grey screen and nothing more. > > I'm missing it too.. Mike?:-) Looks like it's the gas pc-relative problem. Try binpatching the vmunix720 kernel: binpatch -a 0x164a -w -r 0x28 vmunix720 binpatch -a 0x1652 -w -r 0x1c vmunix720 and see if that fixes the problem. The source change should be to replace the explicit pc@() references: | ok, turn off MMU.. tstl _cpu040 jne Lreload040 | lea pc@(zero-.+2),a3 lea zero,a3 pmove a3@,tc | Turn off MMU | lea pc@(nullrp-.+2),a3 lea nullrp,a3 pmove a3@,crp | Turn off MMU some more pmove a3@,srp | Really, really, turn off MMU jra Lreload2 Lreload040: [Since the kernel is mapped with VA=0, the absolute virtual address will be the same as the physical address, so a pc-relative address shouldn't be required, right?] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 21:13:19 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix 720 /dev/reboot problem Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 12:51pm, Michael L. Hitch wrote: > On Dec 12, 2:23pm, Markus Wild wrote: > > > Is there any idea when the method of rebooting, "cp vmunix /dev/reboot", > > > will work again, it is very handy. With 720, it says it is loading, then > > > syncing, then a grey screen and nothing more. > > > > I'm missing it too.. Mike?:-) > > Looks like it's the gas pc-relative problem. Try binpatching the vmunix720 > kernel: > binpatch -a 0x164a -w -r 0x28 vmunix720 > binpatch -a 0x1652 -w -r 0x1c vmunix720 > and see if that fixes the problem. It looks like the same problem will exist for the reboot code, so the same change needs to be made to the '030 MMU code in the reboot routine. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 21:16:53 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: Re: vmunix 720 loading & compiling problems To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 579 Sender: NetBSD-Admin@cbmuucp.commodore.com > 1. The sys/lib/libkern/amiga/DEFS.h file needs updating as was mentioned > with the 709(?) release to change "/**/" to "##". Is there maybe > a new gcc or something else to avoid these patches. Say, Markus, why don't you apply the patch I supplied for DEFS.h and SYS.h before releasing a new set of sources. It should alow these files to work with K&R and ANSI cpp. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 21:45:44 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 2601 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: vmunix720 color probs Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Michael (Michael L. Hitch), in <9312121927.AA06079@gemini.oscs.montana.edu> on Dec 12 you wrote: >On Dec 12, 11:23am, Stefan G. Berg wrote: >> I just got vmunix720 from eunet and also updated my loadbsd and /bin >> and /sbin directory with the new archives. It boots all right and >> seems to work just fine except that the display is almost unreadable. >> I am getting some 80x100 characters in some kind of green/pink color >> combination. What is this, mega-interlace? :-) > > It's a problem with the new cc console stuff that tries to set up the >display for the A2024. The quick fix is to binpatch _ite_default_height >to 400. Great, that fixed the problem. >> One other thing. With the new loadbsd program I can finally make use >> of my 32 bit memory, correct? Do we have a manual for the new loadbsd >> program somewhere? I don't have a clue as to what the new options >> mean. Basically I have 8MB of 16 bit Fast RAM and 4MB of 32 bit Fast >> RAM. Under 713 the 32 bit Fast RAM was completey ignored which did >> wonders when compiling (talking about an afternoon to compile tcsh!). > > I put an option in loadbsd [-p, I think] that was going to force loadbsd >to use the highest priority fast memory segement instead of the largest, >but I didn't change the code to actually do it yet. In your case, that >would only give you the ability to run NetBSD in the 4M 32 bit RAM - in >which case the only use that could be made of the 16 bit memory would be >as a DMA buffer for the GVP controller. I tried disabling my 16 bit memory and here is what happened. My machine booted fine with the 4MB of 32 bit memory. It definitely felt faster than before, although it now had very little memory to run on. However when I wanted to mount my other partitions with "mount -av" it just hung when mount /tmp (is that for the swap partition?). I tried mounting the drives one by one by hand (all except /tmp). That worked fine. Then I typed exit to get into multi user mode and it hung again. It just sat there the cursor still movable (CTRL-C's would display), but otherwise nothing happened. Any idea what the problem might have been? I had to patch _a3000_flag in order to keep NetBSD from thinking that I have an Amiga 3000. This is still on my Amiga 500 with PPI040 and GVP controller. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 22:50:21 1993 From: Russel Miranda Subject: Re: AS To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Sun, 12 Dec 1993, Chris Hopps wrote: > Well I have an idea on why some binaries from markus (I also tried the > as from the binary distrib) don't work. I think that the GVP > accelerators may be broken in regards to odd aligned memory access > could this be a problem? I ran across this when I was working on > CrossPC. We had code to check for some wierdness only found on the > GVP accelerators. I can look it up if anyone thinks this might be the > problem. (I will probably do this anyway :^) Hmmm. Thats the only > differenc I can think of (that matters) between Markus' 3000 and my > 2000 (the one that doesn't matter I am guessing is available memory.) I remember this from the old series I accelerators. There was a PAL upgrade that would fix the problem -- although I don't know if they even offer it anymore (they might - if you have one, call). I don't think the series II (combo, GForce) accelerators have this problem. )Russ From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 23:05:09 1993 From: Alan Bair Subject: Re: vmunix 720 loading & compiling problems To: mw@eunet.ch (Markus Wild) Cc: abair@sol.sps.mot.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > 1. The sys/lib/libkern/amiga/DEFS.h file needs updating as was mentioned > > with the 709(?) release to change "/**/" to "##". Is there maybe > > a new gcc or something else to avoid these patches. > > No, but I have /lib/cpp be a symlink to the current cpp (i.e. in > /usr/gnu/lib/gcc-lib/netbsd/2.5.6/cpp). Then, in I just have > CPP=/lib/cpp -traditional in the Makefile templates in /usr/share/mk, > and everything's fine. I remember setting up a link like that in the past. Is the 2.5.6 version a new one with the 720 binary release? I had to make these same edits in the past and I was using the then current GNU cpp. > > > 4. The Makefile built by config has LD=ld.old. This should be LD=ld. > > *NO*. The new ld (dealing with shared libs) can't currently generate > a valid kernel, you have to use ld.old. OK, that sounds like a good reason, but where is ld.old. Compiling as root with no changes to the PATH, ld.old is not found by the Makefile. By the way, I have not loaded the new binaries, in case that provided a "new" ld along with the previous version renamed to ld.old. The built kernel works just fine using "ld". > > > 5. The default config file AMIGA, has 040 FP support turned on, with the > > FPSP option. It seems like this should not be there considering > > there is a AMIGA40 config file. > > There is no longer an AMIGA40 generic configuration. You can of course > try to build an '40 only kernel, but there is no reason any longer to > build two kernels per distribution, kernels should now work on both > cpus. Well, in the amiga/config directory, there is both AMIGA and AMIGA40. I figured the AMIGA40 one was to add extra stuff for 040 support. Besides, if I don't comment out the FPSP option in the AMIGA config, the build complains that it can't find the .../fpsp/fpsp.o file during a "cp" command. So it looks like even the dummy file to panic on FP code usage on a 040 is missing or in the wrong place. I don't have an 040, so I just commented out the FPSP in AMIGA and my custom config files. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 23:16:52 1993 From: Alan Bair Subject: rootfs setup issues To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Markus, I am working on a new rootfs, hopefully based on 720 at this point. So I want to clear up some things on the /sbin vs /usr/sbin and other issues. Several days ago you posted a script that would appear to delete any files found in /usr/sbin that were also in /sbin. Should there be no duplication between these two directories? I already understand that the /sbin programs should be staticly linked and the /usr/sbin ones can now be dynamically linked. I pressume the file command should be able to indicate this difference. However, when I tried to run it, there was a complaint about not finding the /etc/magic file. You have been providing updated binaries with various releases, which I will include in the rootfs, but besides the original rootfs, where could I get the none binaries like /etc/magic? I pressume they originated from sun-lamp, but did you have to make any changes for the Amiga version? -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 12 23:36:18 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Suggestions for Additions to NETBSD faq Sender: NetBSD-Admin@cbmuucp.commodore.com Here are a few things that I discovered, and with the help of alot NETBSD pro's I was able to get this far. But feel these items need to be mentioned in the fact. INSTALLING NETBSD: 1> Use a pre 713 kernel with current rootfs that is out there (I really hope someone would do a new one. I would offer but I'm not all that sure what I'm doing. 2> HDToolBox (I think) has a bug in it when reading in information from some hd's. It seems that It will not read the correct number of heads, and blocks per track. This may have something to do with the gvpscsi.device or the 240meg hd. (I don't really know) but try using filetodev with the info from HDToolBox and it wont work. I do have a suggestion for a fix. Use gvpFastprep read in info from the hd and select the menu item make mountlist. This gives you two things, the info needed if you wish to use filetodev or a mountlist that you can use with DCP and bffsfilesystem. 3> Make a tar file of gzip, ps, newfs, and disklabel. Use dcp or filetodev and put this on your scratch device. Then format your drives and mount them as the faq states. Untar the above created file and make a directory in your /usr/bin copy gzip to this partition and rename it compress. Make sure you use the programs to do the formating. Then at this point you can switch to the new kernal a 3> Make a tar file of gzip, ps, newfs, and disklabel. Use dcp or fileto dev to move this tar to your scratch area. Untar this file and put ps, newfs, and disklabel in there proper places. Reboot under the 713 - or above kernal and continue on with the formating and mounting of the drives. Now create a dir /usr/bin and copy gzip into this area. Rename it to compress from this point on you can use the tar [z] command to uncompress the files. From this point on its just a mater of coping the *.tgz files to your scratch and "tar xzvpf /dev/rsd#(letter). 4> Using Kermit (HA!) This may help a little (I havn't tried this) because I manged to figure out DCP and my mount problems.. create a file in ~root .kermrc put your choices for the following: set receive packet 9024 set send packet 9024 set file name literal set file type binary set window 3 set line /dev/tty00 set speed 38400 This will set up kermit every time it's started. I'm not sure about the window 3 until you get /usr/bin files installed. I was helped by (michael Hitch) But feel that would be very helpfull if you use the modem install.. 5> Man pages (I havn't verified this yet) Should be in Usr-Share.tar.gz Hope this helps, I know all the folks that told me about the above made my life easier. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 00:01:44 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: AS To: NetBSD-Admin@cbmuucp.commodore.com (Russel Miranda) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > I remember this from the old series I accelerators. There was a PAL > upgrade that would fix the problem -- although I don't know if they even > offer it anymore (they might - if you have one, call). I don't think the > series II (combo, GForce) accelerators have this problem. Your right the new ones don't (including mine.) so I am back to square one. Is anyone else using this ``as''? > )Russ Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 00:08:01 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: vmunix 720 loading & compiling problems Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 3:58pm, Alan Bair wrote: > > > 5. The default config file AMIGA, has 040 FP support turned on, with the > > > FPSP option. It seems like this should not be there considering > > > there is a AMIGA40 config file. > > > > There is no longer an AMIGA40 generic configuration. You can of course > > try to build an '40 only kernel, but there is no reason any longer to > > build two kernels per distribution, kernels should now work on both > > cpus. > > Well, in the amiga/config directory, there is both AMIGA and AMIGA40. I > figured the AMIGA40 one was to add extra stuff for 040 support. Besides, > if I don't comment out the FPSP option in the AMIGA config, the build > complains that it can't find the .../fpsp/fpsp.o file during a "cp" command. > So it looks like even the dummy file to panic on FP code usage on a 040 is > missing or in the wrong place. I don't have an 040, so I just commented out > the FPSP in AMIGA and my custom config files. The dummy file is in amiga/fpsp/fpspnull.s. If the FPSP option is not in the config file, it should assemble this file and link it with the kernel. I looked at the bsdsyssrc distribution and it looks like the amiga/fpsp/fpsp.o file is missing. I think it was included in the 713 source tree though. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 00:34:44 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 2513 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Suggestions for Additions to NETBSD faq Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Joe (Joe Vasher), in <9312090914.AA0037q@cquest.mi.org> on Dec 9 you wrote: >INSTALLING NETBSD: > > 2> HDToolBox (I think) has a bug in it when reading in information > from some hd's. It seems that It will not read the correct number > of heads, and blocks per track. This may have something to do with > the gvpscsi.device or the 240meg hd. (I don't really know) > but try using filetodev with the info from HDToolBox and it wont > work. I do have a suggestion for a fix. Use gvpFastprep read in > info from the hd and select the menu item make mountlist. This > gives you two things, the info needed if you wish to use filetodev > or a mountlist that you can use with DCP and bffsfilesystem. Joe, thanks for posting this. There are a couple helpful pointers in here for those starting from scratch (many of these problems I stumbled over last week myself :) I just wanted to add to your second point. I used FaaastPrep (how many a's was that again?) for getting the mountlist entry, too. It made the creation of the mountlist entries much more easier (for use in the bffsfilesystem). But I would strongly discourage anybody from using FaaastPrep for anything but this purpose. It works fine for the normal Amiga user who just needs a handful of normal partitions. On the other hand, for the specific needs of NetBSD it is totally useless. People have mentioned this before and I will say it again (this should go into the FAQ or installation document). FaaastPrep will write bogus information into certain fields which you previously set correctly with HDToolBox. Also it won't allow you to add more than eight partitions, in fact now where I have some 12 partitions, it will just crash on my machine! > 4> Using Kermit (HA!) This may help a little (I havn't tried this) > because I manged to figure out DCP and my mount problems.. On my Amiga 500 with 040 and using with 16 bit Fast RAM (haven't tried it with 32 bit RAM), my serial port is next to useless. I could barely get a reliable 4800bps out of the serial port. In AmigaDOS I don't have any problems at all to go up to 57600bps. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 00:49:24 1993 From: tjhayko@io.org To: netbsd-amiga@cbmuucp.commodore.com Subject: A4000/A2091 getting closer Sender: NetBSD-Admin@cbmuucp.commodore.com I'm getting closer :). Thank you Michael for your help. I've binpatched vmunix720 so that _a3000_flag is 0 and the _a4000_flag is 1. I've also binpatched _scsi_no_dma to 1 so that it won't try to do dma transfers to the 12MB on my A4000's motherboard. This seems to get around the previous problem I was having with MMU traps, but now it can't seem to find root. I've tried recreating root with both filetodev and dcp, and when I mount a partition with BFFS, I can read it with no problems. BTW, I also patched _ite_default_height to 400 so that I can read the messages. Is there anyway I can get it to use DBLNTSC instead of NTSC Interlace? Here is the output I get when I use loadbsd to load my patched kernel: (misc copyright stuff deleted) Amiga/A4000A2000 MC68040CPU real mem = 12582912 avail mem = 9486336 using 102 buffers containg 835584 bytes of memory 3 Amiga memory segments segment 0 at 07400000 size 00c00000 segment 1 at 00200000 size 00200000 segment 2 at 00001020 size 00200000 ZorroII memory at 01bfc000-01dfc000 Realtime clock A3000 rtclock0 [1/4] par0 [1/6] grf0: 640x400 4 color custom chips display grf0 [1/7] ser0 [1/3] dma0: A2091 DMA a2091scsi0: [514/3] sd0: TOSHIBA MK234FB rev 1.81 207025 512 byte blocks sd0 at a2091scsi0, slave0 root on sd0 bpf: sl0 attached bpf: ppp0 attached bpf: lo0 attached panic: cannot mount root hit any key to boot/dump > Any idea what I can try next? Thanks.. Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 01:09:10 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: A4000/A2091 getting closer Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 6:34pm, tjhayko@io.org wrote: > Thank you Michael for your help. I've binpatched vmunix720 so that _a3000_flag > is 0 and the _a4000_flag is 1. I've also binpatched _scsi_no_dma to 1 so > that it won't try to do dma transfers to the 12MB on my A4000's motherboard. > This seems to get around the previous problem I was having with MMU traps, > but now it can't seem to find root. I've tried recreating root with both > filetodev and dcp, and when I mount a partition with BFFS, I can read it with > no problems. BTW, I also patched _ite_default_height to 400 so that I can > read the messages. Is there anyway I can get it to use DBLNTSC instead of > NTSC Interlace? Here is the output I get when I use loadbsd to load my DBLLNTSC is an AGA chipset feature, isn't it? If so, someone is going to have to figure out how to set up the display for that and add it to the cc console code. I would guess that this information is among the AGA programming specifics that Commodore doesn't want us to know or use. > Amiga/A4000A2000 MC68040CPU ^^^^^ [Oops - looks like I forgot an else clause :-(.] > dma0: A2091 DMA > a2091scsi0: [514/3] > sd0: TOSHIBA MK234FB rev 1.81 207025 512 byte blocks > sd0 at a2091scsi0, slave0 > root on sd0 > Any idea what I can try next? Thanks.. Try patching _sddebug to 1. This should print out all the disk partition information and you can tell if the proper partitions are being recognized. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 01:32:51 1993 From: Calvin Chu Subject: HDToolbox To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com Doees it matter if the correct number of heads are read by HDToolbox? My drive is a 4 head 330, but it reads it as 1 head.... o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 01:36:43 1993 From: tjhayko@io.org To: netbsd-amiga@cbmuucp.commodore.com Subject: A4000/A2091 works! (Thank Michael!) Sender: NetBSD-Admin@cbmuucp.commodore.com I've finally got my A4000/A2091 running NetBSD. Thanks to some help from Michael Hitch, I found that I had typed in the wrong identifiers for my root partition. Fixed 'em up, and it booted. I guess I'll download the rest of the binaries now that it'll boot. Thanks again, Michael. Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 02:15:48 1993 From: Roy Trevino To: NetBSD-Amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: still having vmunix720 loading problems... Sender: NetBSD-Admin@cbmuucp.commodore.com Hmmm. Ack! After reading all this mail on getting vmunix720 to load/compile, I still cannot boot it! All loadbsd does (the 6696 byte one) is say "Using 16M FASTMEM at 0x7000000, 2M CHIPMEM" on the AmigaDOS side (which is correct and what it normally says). But then the screen just flashes once and I'm stuck with a bunch of frozen AmigaDOS windows and nothing to do but C-A-A. Sometimes it garbles the screen just a little beore locking up, but never even gets around to clearing it. This is on my A3000T 030+16M+2M. I have patched the kernel many novel and different ways as well as recompiling it on the NetBSD side many novel and different ways, to no avail. All other kernels have booted w/o a hitch for me. Is it possible that the loadbsd is dependent on these new binary distributions that I have not yet downloaded? Also, what do all the loadbsd options mean? I have yet to see these all in one place yet. I think I know what -a, -p and maybe -k mean. What else may I have missed? It is possible that I missed something key since mail is down about 20% of the time here. Thanks! Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 02:36:07 1993 Subject: Can't boot 720 From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Count me in as another poor soul who cannot boot 720. I am using a version of loadbsd that is 6696 bytes in length. I have also tried compiling the loadbsd in /sys/arch/amiga/stand/loadbsd. I have tried booting the pre-built 720 kernel as well as the result of compiling the kernel myself. In all cases, after the standard "Using 2M chip, 8M fast" message, I get a blank screen. No hard disk activity (which is what I'd expect if the kernel were running but the graphics were not working). My system: A3000/16, 2M chip, 8M fast Maxtor LXT-5340S. I have not replaced any of my binaries. In theory, I should see messages even before the kernel execs init. I have had no problems booting kernels since 644. Compiling is always an adventure, but once I get the first successful build, there are no problems. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 02:58:48 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Length: 669 From: sgberg@charon.bloomington.in.us (Stefan G. Berg) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: HDToolbox Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Calvin (Calvin Chu), in on Dec 12 you wrote: >Doees it matter if the correct number of heads are read by HDToolbox? My= =20 >drive is a 4 head 330, but it reads it as 1 head....=20 It did the same thing for my Quantum 525LPS. I got 1 head, but there actually are 6. It never caused any problems for me. Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu MIME // AMIGA | |Bitnet sgberg@indiana GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 03:25:46 1993 Subject: Can't boot 720? Here's why! From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com If you can't reliably boot vmunix.720 then try this: disable Enforcer I can boot 720 just nice with Enforcer off. This problem also existed in the Mach startup code. The problem is that if you copy the kernel to fast RAM before shutting off the MMU, then you MAY overwrite the MMU tables that Enforcer has set up. Enforcer uses AllocMem() to place the MMU tables anywhere in memory, and it does not use the MMU to protect its own tables. I don't have time to track this one down. My favorite debugging technique back when Mach was all the rage was to add instructions that write different values into $DFF180 at various points in the startup code. This register controls color 0, and by writing $F00, $0F0, $00F, etc, you can narrow down where the crash is occurring. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 03:30:44 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: HDToolbox Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 7:22pm, Calvin Chu wrote: > Doees it matter if the correct number of heads are read by HDToolbox? My > drive is a 4 head 330, but it reads it as 1 head.... I'm sure that the correct number of heads are being read by HDToolbox. What I think is happening is that the drive is probably a newer drive that has several zones, each with a different number of sectors per track. I suspect that HDToolbox takes SectorsPerTrack*Heads*Cylinders and compares that value with the disk capacity. If the result is larger than the actual capacity, HDToolbox looks like it takes the reported SectorsPerTrack, multiplies that by the number of Heads, then divides the actual capacity by that value - which will be the number of cylinders reported by HDToolbox. Since AmigaDOS isn't going to care what the actual disk geometry is, HDToolbox picks the value of 1 head, but SectorsPerTrack*Heads sectors. This results in the same size "cylinder" as Heads surfaces with SectorsPerTrack sectors. [The above isn't quite correct - I just checked the parameters on my Maxtor 7345S and while the drive reports 4 heads and 96 sectors per track, HDToolbox pick 1 head and 192 sectors per track - with the result that the number of cylinders is almost twice the actual number of cylinders.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 03:54:44 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Can't boot 720? Here's why! Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 9:18pm, David Jones wrote: > If you can't reliably boot vmunix.720 then try this: > > disable Enforcer > > I can boot 720 just nice with Enforcer off. > > This problem also existed in the Mach startup code. The problem is > that if you copy the kernel to fast RAM before shutting off the MMU, > then you MAY overwrite the MMU tables that Enforcer has set up. > Enforcer uses AllocMem() to place the MMU tables anywhere in memory, > and it does not use the MMU to protect its own tables. This shouldn't be the problem with NetBSD. Loadbsd uses malloc to allocate the memory for the kernel image. When loadbsd has everything ready to go, it shuts off the MMU and Amiga DMA, then copies the kernel to chip memory. I did just look to verify how it worked and I noticed that the code that turns off the '030 MMU uses the pc@(xx-.+2) addressing. If loadbsd was created with a version of gas that changes how that address format is processed, it could cause a problem. [I also just downloaded the loadbsd from ftp.luth.se and verified that it matched the file I've been using, and I just disassembled it to verify that the lea instruction was correct.] > I don't have time to track this one down. My favorite debugging technique > back when Mach was all the rage was to add instructions that write > different values into $DFF180 at various points in the startup code. > This register controls color 0, and by writing $F00, $0F0, $00F, etc, > you can narrow down where the crash is occurring. That's exactly what I did on Mach and NetBSD when trying to get the '040 MMU setup going. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 04:06:22 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: still having vmunix720 loading problems... Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 6:08pm, Roy Trevino wrote: > Is it possible that the loadbsd is dependent on these new binary > distributions that I have not yet downloaded? Loadbsd is a standalone AmigaDOS program and the only dependancy is the register contents passed to the kernel and the data passed at the end of the kernel. > Also, what do all the loadbsd options mean? I have yet to see these all > in one place yet. I think I know what -a, -p and maybe -k mean. Well, how about: -a boot up to multiuser mode. -b ask for which root device [I have roots on 3 different disks at times]. -k reserve the first 4M of fast mem [Some one else is going to have to answer that it is used for]. -p Currently not used - it's to specify that the highest priority fastmem segement is to be used for NetBSD instead of the largest segment. The higher priority segment is usually faster (i.e. 32 bit memory), but some people have smaller amounts of 32 bit memory. -t This is a "test" option. It prints out the memory list information being passed to the kernel and also exits without actually starting NetBSD. > What else may I have missed? It is possible that I missed something key > since mail is down about 20% of the time here. Are you running Enforcer? That seemed to be causing the problem for one person. I've looked at the code and don't see anything obvious as to why Enforcer would cause any problems. It works fine on my Zeus 040 card, but I can't verify it still works on an '030. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 04:34:32 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A4000/A2091 getting closer To: NetBSD-Admin@cbmuucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > This seems to get around the previous problem I was having with MMU traps, > but now it can't seem to find root. I've tried recreating root with both > filetodev and dcp, and when I mount a partition with BFFS, I can read it with Hey, whie your at it try device-streams its very very easy to use (you can use your partition names) :^) FAQ Entry: Use device-streams instead of the filetodev nightmare (its useful but far far to dangerous.) (This should be re-written :^) > no problems. BTW, I also patched _ite_default_height to 400 so that I can > read the messages. Is there anyway I can get it to use DBLNTSC instead of > NTSC Interlace? Here is the output I get when I use loadbsd to load my > patched kernel: Heh, send me your 4000, I'll whip up some AGA modes then. Its fairly easy to write them though so if you wanted to you could do it. I like the first option better though. :^) > Tom Hayko > tjhayko@io.org Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 04:43:19 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: AS To: tero.manninen@oulu.fi (Tero Manninen) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > BTW, can gas 1.38.1 from the gcc 2.3.3 package create pc relative > code? This would be needed when I translate my boot block code to > disk.. Yes all of them should be able to create PC rel code the question is how correct is it? It seems the safest way to do things currently is (in order of preference) don't use PC rel. or use format pc@(symbol) it gets very incompatible from that point on. > > Then another thing.. at boot block executing time the display hasn't > been opened. It would be quite nice to put some output from boot > loader to console. So, how do I create a display where to put data > (for example by graphics.library Move() and Text())?. Are you talking about NetBSD? > ++Tero > Chris. From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 04:52:57 1993 From: tjhayko@io.org To: chopps@emunix.emich.edu, NetBSD-Admin@cbmuucp.commodore.com Subject: Re: A4000/A2091 getting closer Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >Hey, whie your at it try device-streams its very very easy to use (you >can use your partition names) :^) > dcp will let you use partition names too. >Heh, send me your 4000, I'll whip up some AGA modes then. Its fairly >easy to write them though so if you wanted to you could do it. I like >the first option better though. :^) I've got NetBSD running, but I seriously doubt that my 105MB drive will be enough to do much development. Hmmm, maybe I can convince my wife that a 500MB SCSI disk willl do nicely as a Christams present :) Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 05:19:49 1993 To: Kevin M Mccarthy Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: bin/loadbsd X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com The X bit (execute bit) under amiga isn't being set. Use the amigados protect program to add the X bit. :-) >>>>> kmm == Kevin M Mccarthy wrote: kmm> I've downloaded loadbsd from the bin directory twice kmm> from ftp.eunet.ch and Many times from kmm> att2.cs.mankato.msus.edu and they are both 6696 bytes kmm> long and refuse to execute. I get "loadbsd: file is not kmm> executable" when I try to run it. I have transfered it kmm> gziped and lharced and they extract okay, but won't run. kmm> I am using NcFTP so they should be transfered in binary kmm> format. Could someone please upload a gziped binary for kmm> the most recent loadbsd? Thanks in advance. kmm> -- kmm> Kevin McCarthy signals@krypton.mankato.msus.edu kmm> ------------------------------------------------------------------------------- kmm> "If I were a carpenter, I'd hammer on my piglet, I'd kmm> collect the $7 and I'd buy a big prosthetic forehead and kmm> wear it on my real head." -They Might Be Giants kmm> ------------------------------------------------------------------------------- kmm> HELLO! I'm a .signature virus! Join in and copy me into kmm> yours! From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 05:20:57 1993 From: Roy Trevino To: NetBSD-Amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: solution found!!! (to my loadbsd720 problems) Sender: NetBSD-Admin@cbmuucp.commodore.com Ok, I gave up and started debugging the loadbsd code, having nothing better to do :-). (I live to debug.) And found the problem has to do with having no expansion devices on my Amiga. Consider this code fragment from loadbsd. num_cd is presumably the number of configured devices. Since I have none, this number is zero. So the for() loop will never get executed. Too bad, because that is the only place kcd is initialized, and then it goes straight into kmem_list as a big 0 (not where the kernel really is). *knum_cd = num_cd; if (num_cd) for (kcd = (struct ConfigDev *) (knum_cd+1); cd = FindConfigDev (cd, -1, -1); *kcd++ = *cd) ; kmem_list = (struct MEM_LIST *)kcd; Here's what I do instead. Notice the total lack of the if() statement, replaced instead by "cd = 0;": *knum_cd = num_cd; cd = 0; for (kcd = (struct ConfigDev *) (knum_cd+1); cd = FindConfigDev (cd, -1, -1); *kcd++ = *cd) ; kmem_list = (struct MEM_LIST *)kcd; This now works great on my A3000T 030+16M+2M! Magically, I can boot again! Probably a lot of other people without expansion devices too!!! (if they have the fixed code, that is). Here are the actual diffs, mine vs original 720 loadbsd: 151,152c151,152 < cd = 0; < for (kcd = (struct ConfigDev *) (knum_cd+1); --- > if (num_cd) > for (kcd = (struct ConfigDev *) (knum_cd+1); I guess I always wanted to load up gcc on the amigados side anyways so that I could build the new fontdumper :-). At last I can go back to X11. Life is good again! Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 06:01:16 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: solution found!!! (to my loadbsd720 problems) Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 9:13pm, Roy Trevino wrote: > Consider this code fragment from loadbsd. num_cd is presumably the > number of configured devices. Since I have none, this number is zero. > So the for() loop will never get executed. Too bad, because that is > the only place kcd is initialized, and then it goes straight into > kmem_list as a big 0 (not where the kernel really is). Ouch! Ooops! [Guess who added the kmem_list code?] > I guess I always wanted to load up gcc on the amigados side anyways > so that I could build the new fontdumper :-). At last I can go back to > X11. Life is good again! I don't think you will be able to run X11 on the 720 kernel without a slight modification to the console routines [in ite_cc.c, when the ite console is shut off by enabling graphics, there is now a viewioctl that removes the current view - since the grfon routine doesn't display the view, nothing will display; I just removed the VIEW_REMOVE ioctl call (in the 713 version of that code - I think it is the same in the 720 version)]. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 06:02:27 1993 From: Calvin Chu Subject: Booting 714 To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com I binpatched all the a3000 flags to 0 and all the 2091 related flags to 1 and I got it to boot farther than before. It no longer searches for the a3000scsi... but now, it finds all the hard drives, it locates the right partition, then it seems to have trouble locating the root partition and mmu panics. I don't know what to do from here. I tried doing the same with 720 but 720 simply boots "blows up" and freezes the keyboard led, starts spewing wierd stuff out the serial ports, etc... I tried binpatching _ite_default_height to 400 with no luck. What do I do? Also, I couldn't find the 720 loadbsd (?) is there one for AmigaDOS? All I can find is the the loadbsd in the NetBSD-Amiga directory. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 06:05:59 1993 From: Calvin Chu Subject: Re: Can't boot 720? Here's why! To: David Jones Cc: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Sun, 12 Dec 1993, David Jones wrote: > If you can't reliably boot vmunix.720 then try this: > > disable Enforcer > > I can boot 720 just nice with Enforcer off. Enforcer seems to have nothing to do with it. Booting the kernal with a disabled startup doesn't help. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 07:02:40 1993 From: Calvin Chu Subject: MMU Panic To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com The previously described MMU panic/crash... real mem = 8388608 avail mem = 5488640 using 102 buffers containing 835584 bytes of memory panic: kernal jump to zero hit any key to boot/dump... dreg 000000A FFFFFFFF 00000100 00000001 00000002 00000000 0000000D 0000000D areg 009BE3C 00000000 0000CF42 00010001 00072618 000956D4 FFFFFF24 DEFFFFFC (lots of stuff) Kernal stack (FFFFFE52): (stuff) panic: mmu fault >trap: bad kernal access at 2 . . . o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 07:31:58 1993 From: oster@skorpio.usask.ca Subject: Re: solution found!!! (to my loadbsd720 problems) To: NetBSD-amiga@cbmuucp.commodore.com X-Envelope-To: NetBSD-amiga@cbmuucp.commodore.com Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com > Ok, I gave up and started debugging the loadbsd code, having nothing > better to do :-). (I live to debug.) And found the problem has > to do with having no expansion devices on my Amiga. "Having nothing better to do :-)" - :-) I'm glad to see that someone has free time to work on this :-) > Consider this code fragment from loadbsd. num_cd is presumably the > number of configured devices. Since I have none, this number is zero. > So the for() loop will never get executed. Too bad, because that is > the only place kcd is initialized, and then it goes straight into > kmem_list as a big 0 (not where the kernel really is). > > *knum_cd = num_cd; > if (num_cd) > for (kcd = (struct ConfigDev *) (knum_cd+1); > cd = FindConfigDev (cd, -1, -1); > *kcd++ = *cd) ; > kmem_list = (struct MEM_LIST *)kcd; > > Here's what I do instead. Notice the total lack of the if() statement, > replaced instead by "cd = 0;": > > *knum_cd = num_cd; > cd = 0; > for (kcd = (struct ConfigDev *) (knum_cd+1); > cd = FindConfigDev (cd, -1, -1); > *kcd++ = *cd) ; > kmem_list = (struct MEM_LIST *)kcd; > > This now works great on my A3000T 030+16M+2M! Magically, I can boot again! > Probably a lot of other people without expansion devices too!!! (if they > have the fixed code, that is). Bravo!!!!! I can now boot with some regularity again... (A3000 030+12M+2M) The only way I'd been able to get a good boot is if I powered down the machine first :-( (No, I wasn't running Enforcer either...) Now I've been able to do 3 successful boots in a row (without a power cycle!)- a new world record for me with this new kernel :-) > Here are the actual diffs, mine vs original 720 loadbsd: > > 151,152c151,152 > < cd = 0; > < for (kcd = (struct ConfigDev *) (knum_cd+1); > --- > > if (num_cd) > > for (kcd = (struct ConfigDev *) (knum_cd+1); > > > I guess I always wanted to load up gcc on the amigados side anyways > so that I could build the new fontdumper :-). At last I can go back to > X11. Life is good again! Do you have X11 working??? I thought Michael H. said that something wasn't setup right in the cc... the times I have gotten the kernel to boot I've tried getting X11 running - I've run Xbsd (outputs redirected to/dev/null) and xterm -C. According to "ps -aux", they are running, but my monitor is just black.... (I can kill the processes, so at least I'm getting around the MMU panics...) > Roy > -------------------------------------------------------------------- > Roy Trevino Intel Corp. > E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 > "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" > Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 08:32:47 1993 From: Alan Bair Subject: fontdumper uploaded To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Since some of you have not been able to compile the fontdumper, I have uploaded the executable and source to ftp.eunet.ch:.../NetBSD-Amiga/incoming as fontdumper.tar and fontdumper.readme. These are based on the source released with the 720 sources. I also tried to update the code to support compiling under SAS/C, but could not produce a usable executable. Markus Wild, The dumpfont.* files in the incoming directory can probably be erased. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 10:56:51 1993 From: Tero Manninen Subject: Re: AS To: chopps@emunix.emich.edu (Chris Hopps) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 734 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Then another thing.. at boot block executing time the display hasn't > > been opened. It would be quite nice to put some output from boot > > loader to console. So, how do I create a display where to put data > > (for example by graphics.library Move() and Text())?. > > Are you talking about NetBSD? This is at the time when we are still running in AmigaOS. The code currently reads /vmunix out of fixed scsi unit (my boot device is 6) and boots into netbsd when the boot loader is run from AmigaDOS shell. Next step is to compile pc relative code and move it to my hard disk boot blocks. At the time of boot block execution Amiga exec and libs & devs are usable, but no display is opened. > > ++Tero > > > Chris. > ++Tero From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 17:11:22 1993 From: David Crooke Sender: dcc@dcs.ed.ac.uk To: netbsd-amiga@cbmuucp.commodore.com From: David Crooke Subject: [dcc@dcs.ed.ac.uk: Preceeding FAQ] Sender: NetBSD-Admin@cbmuucp.commodore.com I have uploaded this to ftp.eunet.ch, file upload/INSTALL.714. Apologies for the wasted mail bandwidth. David David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 1408, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 5164 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 17:20:14 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Anyone have a working 4M configuration Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com ANyone have a 4M machine working reliably? I'm having tons of trouble. I'm also wondering if my DMAINTR/dmanext at end troubles might be related. I've resorted to running with _scsi_no_dma set for the moment. (and boy is it slooow!) Problems I'm having (these are all with 720 and the latest binaries, a 2Mchip/4Mfast '030 A3000 with an A2065, and a 64M swap partition [I figured I'd leave room for future expansion -- I don't want to run a 4M machine forever :->]): - Attempts to compile anything cause the machine to grind to a halt and eventually panic. This even happens with small compiles. The effect seems to be cumulative (almost like swap is getting filled up?) - attempting to bring the system up multi user (via logout from the single-user shell) die similarly. - swapinfo doesn't work. It exits with "swapinfo: panic: nswapmap goof". - mount -t mfs panics the machine, with either the mount_mfs from the latest bin-sbin, or with the latest newfs renamed to mount_mfs (shouldn't these be identical?) Here's a typical panic: vm_fault(d6000, 16c8000, 3, 0) -> 1 type 8, code [mmu,,ssw]]: 401070d trap type 8, code = 401070d, v = 16c8008 pid = 38, pc = 0005A044, ps = 2300, sfc = 0001, dfc = 0001 [followed by register and stack dumps] panic: MMU fault. Would anyone out there (particularly a 3000 owner) be willing to try running with 4M for awhile? If you have an 8M machine, run loadbsd -k, otherwise you'll have to modify loadbsd to only give 4M to NetBSD). -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 17:20:40 1993 From: David Crooke Sender: dcc@dcs.ed.ac.uk To: netbsd-amiga@cbmuucp.commodore.com From: David Crooke Subject: Draft Install Note Sender: NetBSD-Admin@cbmuucp.commodore.com Here is a first draft of an install note. It is of course out of date since vmunix.720 has come out, but I would appreciate comments and clarifiactions. Also, what is the procecure for uploads to eunet? Do they have to go via MW? David David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 1408, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 5164 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 How To Get NetBSD Going on Your Amiga - A Beginner's Guide ---------------------------------------------------------- v0.01 (First Draft) December 1993 - kernel vmunix.714 This is a short note I wrote to help other people installing NetBSD for the first time: I am no expert, I am a beginner too, and hopefully this will be beneficial to the simplicity of this note. I would appreciate any comments by e-mail to dcc@dcs.ed.ac.uk, or by post to 12 West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. Please note that NetBSD for the Amiga is under continual development, and any documentation inevitably goes out of date as soon as it is written - so don't take this as absolute truth! 1. What is NetBSD? NetBSD is a PD version of the BSD operating system - in layman's terms, it is a Unix clone. When it runs on an Amiga, it takes over the entire machine, turning it into a Unix workstation. 2. What kind of Amiga do I need? You will need an Amiga with: a. An MMU (i.e. 68020+68851, 68030 (not EC), or 68040 (not EC)) In particular, this rules out standard A1200's and A4000/030's, and most A1200 accelerator cards. b. A supported hard disk controller Currently, supported controllers include the A3000 builtin, A2091, PPI Zeus and GVP Series II. Support for other controllers is being worked on; in particular, someone should be supporting the A1200/A4000 builtin IDE fairly soon. c. Enough memory 4MB of FastRAM is probably now a minimum, and you will need at least 1MB of ChipRAM due to the way the kernel is loaded. 3. How much disk space will it take? A lot. As much as you can spare and then some :-) Realistically, you need around 80-100Mb to install a reasonable system, before you do anything with it. Read the rest of this note to help you decide what your requirements will be. 4. How can I find out more? Join the NetBSD mailing list - send a message to NetBSD-Admin@cbmuucp.commodore.com with the body "subscribe". Note that NetBSD is not a Commodore product and is in no way associated Read the Usenet News group comp.unix.amiga Installing NetBSD ----------------- Installation is best done in two phases: 1. Obtain the AmigaDOS bootstrap tools and root filesystem image and install and test them 2. Set up partitions and install the system software and applications you need Before describing these procedures, I will briefly discuss the Amiga's RDB hard disk paritioning mechanism and the Unix file system. Before you install anything, read through the entire procedure carefully and think about how you want to divide up your disk space. The Unix File System -------------------- Unlike most operating systems, in which the file system is a collection of separate devices with a tree of directories on each, Unix views the file system as one big tree - like all good computer trees, it is upside down, with the root at the top. Distinct trees of files (e.g. different disks or partitions, or even file systems from another computer on a network) are plugged in at various points in the tree (this action is called "mounting"). When choosing how to partition your system, remember that Unix file systems have soft links - this allows directories or even individual files to be placed elsewhere in the file system (e.g. in another partition) with a link pointing to the real location. So accurate partitioning isn't as crucial as with other operating systems. In the final event you can always back up your files, repartition and reinstall once you have used NetBSD for a while and get to know your needs better. The Amiga RDB System -------------------- The Rigid Disk Block (RDB) is the mechanism the Amiga uses to store information about hard disk partitions. The first cylinder of any hard disk (or similar device on a SCSI bus) is reserved for this information. When you partition a disk (with HDToolBox, FaastPrep, etc.) the paritioning program will write this data on the disk - when the computer boots under AmigaOS, it reads this to determine what the partitions of the disk are, what filing systems they have, whether or not it should mount them automatically, and whether they can be used to boot the system. NetBSD also uses the RDB information to locate its partitions on the hard disk(s); however, it ignores the AmigaOS partition names, and instead uses the DosType designator to identify the different BSD partitions. The DosType is a four byte field; the AmigaOS filing system types are given by the characters "DOS" followed by a number (currently from 0 to 3, e.g. OFS is 0, FFS is 1, DCFFS is 3). In hexadecimal, the code for FFS is "0x444F5301". NetBSD partitions use this field to identify the partition name; the root partition is named ASCII "BSDR", i.e. 0x42534452, swap is "BSDS" (0x42534453) and other partitions are "BSDD", "BSDE" etc. (0x42534444, 0x42534445 etc.) Phase I - Installing Root and Booting NetBSD -------------------------------------------- ******************************************************************* * It is STRONGLY recommended that you back up all your hard disks * * before attempting to install NetBSD * ******************************************************************* You will need to obtain the relevant files from ftp.eunet.ch or one of the mirror sites. At eunet the files are in directory "pub/NetBSD-Amiga", the kernel binaries are in "pub/NetBSD-Amiga/kernel", and some tools are in "pub/NetBSD-Amiga/contrib/ados". Some of the utilities you may already have, and some may be available from other places which do not carry NetBSD. All filenames will henceforth assume the NetBSD-Amiga directory. Disk space: You'll need about 2-3Mb as a minimum on the AmigaDOS side for tools and bits and pieces; temporary space to unpack stuff is virtually essential as well (unless you have loads and loads of RAM). You will need to make two of the NetBSD hard disk partitions; one for the rootfs (8MB for the old version, 10MB for the new), and one for the swap (twice the size of your FastRAM). Before doing this part of the installation, read the rest of this note and decide what you want your final disk partitions to look like. Software you will need: 1. gzip (GNUzip) - this is the GNU file compression utility. available from Aminet and elsewhere. All the NetBSD stuff is compressed with it. 2. filetodev - this (dangerous toy) writes blocks of data to a disk "in the raw". You will use to lay down the rootfs image. It is provided with BFFS in the file "contrib/ados/bffs11.lzh". (Once you have NetBSD up and running, BFFS allows you to read files in NetBSD partitions while using AmigaDOS). An alternative to this is DCP which allows you to specify partitions rather than block numbers. 3. loadbsd - this AmigaOS program boots NetBSD. Get the newest version (currently named "loadbsd713") 4. A kernel image, from the subdirectory "kernel". The current version is "vmunix.714", which does not include 68040 support. Later kernels will do so. Earlier kernels have different versions for use with the 040, e.g. "vmunix.713-040" 5. A root file system image. The old version, dated 13-Jun-93, which is 16448 blocks (about 8MB) when unpacked, is called "rootfs.gz". Hopefully, by the time you read this, a more up-to-date rootfs will have been uploaded. You will also need a suitable AmigaDOS hard disk partitioning utility; it is recommended that you use Commodore's own HDToolBox, as certain 3rd party products will not allow you to make the settings you need (notably GVP's "FaastPrep"). Doing the installation: 1. Download and unpack the files mentioned above and have them ready to use on your Amiga. e.g. to unpack rootfs.gz, "gzip -d rootfs.gz". The AmigaOS utilities will be packed with things like LhA. Note the size in blocks of the rootfs you have downloaded - this can be calculated by getting the size in bytes of the unpacked version from the AmigaOS "list" command and dividing by 512: size in blocks = size in bytes / 512 The original rootfs was 16448 blocks in size; wherever you see this number, substitute the size you have calculated. 2. Start up HDToolBox - if you have a GVP or other non-Commmodore controller, you will need to start it from the shell (CLI) and give it the name of the device driver (e.g. for GVP II "hdtoolbox gvpscsi.device") You will create the BSD partitions on the respective disks using the following procedure - instructions refer to the HDToolBox supplied with AmigaOS 2.04; other versions or other RDB editors may be slightly different: - Select the drive by clicking on it - Click on "Partition Drive" (HDToolBox partition mode) - Click on "New Partition" - Click on the empty space where the partition will go - Grab the arrow under the partition and adjust the size - Grab the partition box (black rectangle) and move it if need be - Change the "Bootable?" option to "No" - Click in the device name box (marked "CHANGE_ME") and alter it to something sensible (NetBSD doesn't care) - Click on "Advanced Options" to turn them on - Click on "Change File System for Partition" (HDToolBox File System Menu). You will find the default setup (usually FFS) - Click on "Custom File System" - Change "Blocks Reserved" and "PreAlloc" to 0 - Change "Auto mount this partition?" to "No" - Change "Use Custom boot code?" to "No" - The "Identifier" or "DosType" box will show something like 0x444F5301 (FFS). Change this to the BSD partition identifier (e.g. for the Root Partition, 0x42534452) - Click "OK" to return to partition mode - Note the "Start Cylinder" and "End Cylinder" numbers for the partition, and note the SCSI device number (usually 0 to 6) of the disk it is on - If all partitions for this drive are done, click "Ok" to return to the main screen. Click "Save Changes to Drive". If you are overwriting old partitions you will get a warning - if you're not sure what you've done is right, think again, but if you are, click "Continue". 3. Create a partition for the rootfs using the method above; it should be exactly or just over the size of the rootfs you downloaded (i.e. 16448 blocks or more for the old version) - any extra space will be wasted for the moment, but once you have NetBSD running it is possible to rebuild the rootfs, so if you want to leave a bigger space for it, that's OK. The partition type should be 0x42534452 (ASCII "BSDR"). 4. Create a swap partition - this will be used as swap space for NetBSD's virtual memory, and for scratch space (the /tmp directory). It should be at least TWICE the size of the Amiga's RAM. The partition type should be 0x42534453 ("BSDS"). NetBSD only uses swap space when running (no permanent files are stored on it), so you can use it as scratch space for AmigaDOS in between NetBSD sessions (e.g. as swap space for GigaMem) if you like. 5. You need to know the number of blocks per cylinder for the drive on which you made the root partition. You can find this out from the drive type editor in HDToolBox: - From the main screen, select the drive in question - Click "Change Drive Type" - Click to select the type matching the drive - Click on "Edit Old Drive Type" - Note the number of heads and blocks per track - Click "Quit" etc. to get out of this mode The number of blocks per cylinder is the number of heads multiplied by the number of blocks per track. Note: This drive "geometry" is imaginary; most hard disks put a variable number of blocks on a track depending on its radius, and SCSI devices talk in block numbers, but AmigaDOS likes to have cylinder, head and block. Therefore you can have different geometries for different drives of the same type depending on how they were first partitioned, what controller you have, etc. DO NOT trust values from a leaflet that came with the drive, find out from HDToolBox. 6. You are now finished with HDToolBox - if you have overwritten old partitions, it will force you to reboot when you quit. 7. Now we will put the rootfs image in the partition we reserved for it. ******************************************************************** * You are reminded again of the advice to back up the rest of your * * system. This stage is highly dangerous and one mistake could * * trash the contents of your hard disk(s)! * ******************************************************************** We need to know which block number the partition starts at, which we calculate as: Start Block = Start Cylinder * Blocks Per Cylinder using the values for the drive you noted in stage 5, and the cylinder numbers for the partition. If you forgot to note this, go back into HDToolBox and check the values. Calculate the size in blocks, using: Size = (End Cylinder - Start Cylinder) * Blocks Per Cylinder This size should be at least as large as the rootfs image (16448 or more blocks). If it isn't, go back to stage 3 and make it bigger. Ensure that the image is uncompressed, i.e. you have an AmigaDOS file "rootfs" of size 8421376 and not "rootfs.gz". We will use the filetodev program to write the image to the disk; it takes 6 parameters: - the start block number - the image size (i.e. 16448 or whatever, not the partition size) - the name of the file ("rootfs") - the AmigaDOS device name for your controller (e.g. "gvpscsi.device") - the device number of the disk - the number of buffers to use (e.g. 1000) Example: I have an A3000, and I am placing my NetBSD partitions on a Maxtor 7345SR which is unit 6 (using the built-in SCSI controller). Geometry for the Maxtor, from HDToolBox: Unit = 6 Cylinders = 3518 Heads = 1 (not true in reality; see stage 5) Blocks Per Track = 192 I calculate Blocks Per Cylinder = 1 * 192 = 192 The BSDR partition: Start Cylinder = 3408 End Cylinder = 3517 Start block: 3408 * 192 = 654336 I check the size: (3517 - 3408) * 192 = 20928 (bigger than 16448) I use the following command: filetodev 654336 16448 rootfs scsi.device 6 1000 Note: If filetodev scares the willies out of you (I have trashed my AmigaDOS system partition more than once with it), some kindly person (Chris Hooper) has written a slightly less dangerous tool, called "dcp". Get it from the ftp site and use it instead if you like. 8. You are now ready to test NetBSD in single user mode. Use the versions of loadbsd and vmunix that you got (ensure that they have been decompressed first), e.g. loadbsd713 vmunix.714 If all goes well, the Amiga will go through a soft reboot, and you should see a plain screen with something like: (C) ....... Regents of the University of California ..... godzilla.eunet.ch.... AMIGA A3000 (68030, 68882 25MHz FPU) .... sd6: Maxtor 7345 rev. 9.60 .... root device /dev/sd6a ... root(1)$ _ NetBSD is running in single user mode, and the prompt is from the shell (bash). Try a few simple commands (e.g. "ls -l"). When bored, use the command "reboot". If it doesn't work, look for suggestions below, and ask for help on the News and mailing list forums. Phase II - Installing the Software and Setting Up Multi-User Mode ----------------------------------------------------------------- Read the whole section before proceeding. You should now have a minimal NetBSD installation with rootfs and swap partitions. We will now create additional partitions to install the operating system and other software. To calculate the size(s) needed, use the following rough formula: HDToolBox size (MB) = (Installed blocks / 2048) * 1.2 The reason for the 1.2 scaling factor (apart from a safety margin) is that NetBSD reserves part of each partition: a partition will be reported as being 100% full when it still has some space left - root and other superusers will be allowed to write to the partition, but ordinary users will not. The following table gives the installed size in 512 byte blocks for each of the bin-...gz archives: Archive Unpacks to Installed Size ------- ---------- -------------- These files are essential for proper operation of NetBSD: bin-bin.tar.gz /bin (Included in new rootfs) bin-sbin.tar.gz /sbin (Included in new rootfs) bin-usr.include.tar.gz /usr/include 2258 bin-usr.sbin.tar.gz /usr/sbin 10960 bin-usr.bin.tar.gz /usr/bin 25686 bin-usr.lib.tar.gz /usr/lib 2416 bin-usr.libexec.tar.gz /usr/libexec 3882 bin-usr.share.tar.gz /usr/share 25038 (Total: 70240) Not essential, but useful: bin-usr.gnu.tar.gz /usr/gnu 61156 bin-usr.games.tar.gz /usr/games approx 7000 ? To begin with, I decided to make a 100Mb partition for /usr, and to make a 70Mb partition to be mounted as /home, for the BSD users' home directories. Since I used the old rootfs I rebuilt it to have a root partition 11MB in size. Decide what partitions you want; you could just rebuild the rootfs (see below) onto one enormous partition and keep everything there, but the usual caveats about backups etc. apply to NetBSD as much as to AmigaDOS. In the instructions that follow I assume my system with the partitions I detailed above; vary them according to what you have set out. Now decide how you are going to get the bin-...gz files into NetBSD - basically, you need a temporary space to copy them to. If you are lucky enough to have a SCSI tape drive you can use that, otherwise the easiest way is to create an extra NetBSD partition, which we will leave unformatted, and to use that. 1. Set the partitions up with HDToolBox, using the same method as before. The partitions should be given types 0x42534444 ("BSDD"), 0x42534445 ("BSDE") etc. up to 0x42534448 ("BSDH") If you are using more than one drive, reuse the names (i.e. start from "BSDD" with each drive). If you will be using a scratch partition (rather than tape) to install the files, create it too. It will have to accom /etc/fstab /dev/sd6a / ufs rw 1 1 /dev/sd6b /tmp mfs rw 1 1 /dev/sd6d /usr ufs rw 1 1 /dev/sd6e /home ufs rw 1 1 Note that /tmp is mfs while the others are ufs. If you make a mistake, exit with Ctrl-D and start again. 8. Now look at the file system; the "df" command shows all mounted partitions and their size: df It should show just the root partition. 9. Now we tell mount to mount all the partitions listed in /etc/fstab: mount -av and try df again: df All of your partitions should appear. If there are any problems, use the command "umount -av" to unmount the partitions and go back and do /etc/fstab again. 10. Now we will shut down NetBSD and get the files ready to install. Unmount the partitions: umount -av and then flush the file system buffers: sync ; sync ; sync and then: reboot You should follow this procedure every time you shut down NetBSD to avoid corrupting the file system. 11. The procedure for installing a bin-...gz archive is as follows: - from AmigaOS, put it on your temporary space (i.e. tape or scratch partition) - Boot NetBSD and mount the partitions - Unpack it into the NetBSD filesystem - Shutdown NetBSD, reboot AmigaOS and do the next one Of course, if you have more than one scratch partition, or more than one blank tape, you can do several in one NetBSD cycle. The procedure for a scratch partition is: a. Calculate its start block and size as you did with rootfs; my scratch partition starts at cylinder 541 and ends at 861, so I calculated: start block = 541 * 192 = 103872 size = (841 - 541) * 192 = 61440 b. In AmigaOS, uncompress the archive, e.g. gzip -d bin-usr.bin.tar.gz c. Calculate the tar file's size in blocks, by: Blocks = File size / 512 e.g. Size of bin-usr.bin.tar = 12892160 / 512 = 25180 d. Use filetodev to put it on the scratch partition, e.g. filetodev 103872 25180 bin-usr.bin.tar scsi.device 6 1000 e. Boot up NetBSD, mount the partitions, and unpack the file into the root directory, e.g. mount -av cd / tar xvfp /dev/sd6g It should be possible to just dump the compressed archive onto the partition and decompress it on the fly (using "tar xvzfp /dev/sd6g") but I couldn't get this to work with filetodev. The procedure for tape is slightly easier. Just put the compressed file on the tape, e.g. copy bin-usr.bin.tar.gz tape: Then boot NetBSD and unpack it: mount -av cd / tar xvzfp /dev/rst0 The "z" tells tar that the file is still compressed, and instructs it to pipe it through gzip. When shutting down NetBSD, remember to unmount the partitions and flush the file system buffers: umount -av sync ; sync ; sync reboot 12. After a few repetitions, you should have all the software installed. We can now configure NetBSD for single user mode. Boot up NetBSD, and use the following commands: mount -av (as always) export TERM=vt100 (needed by the editors) If you used the old rootfs, edit /etc/gettytab (with vi, emacs or whatever) and change ":ap:" to ":np:" in the entry for default (around line 20), e.g. vi /etc/gettytab Most generic Unix books have a chapter on using "vi", but here is a minimum to get you started: Vi is a "modal editor", i.e. the keys work differently depending on the mode. Normal Mode: h Left l Right j Down k Right i Enter insert mode, starting before the current character x Delete a character :d Delete a line Insert Mode: Type text to insert it, press ESC to end. You may now want to change the list of users. Edit the password file with: vipw The file consists of lines like this: fred:k%56Fj:234:567::0:0:Fred Bloggs:/home/fred:/bin/bash Each represents a user. The colons (":") separate the fields. The important ones are the 2nd one (their password, encrypted), the 3rd and 4th (user and group id's), the 8th (real name), 9th (login directory) and 10th (login program). Make sure that root has no encrypted password (for now), and that there is a user to log in as. Make one for yourself if you like. Exit vi, and the user database will be updated. If you have added users, create their home directories as follows: mkdir /home/fred ; chown fred /home/fred If you used the old rootfs, edit /etc/rc and comment out the line which starts the program "named". 13. To start multi user mode, exit the single user mode shell: exit Rebuilding the Root Partition ----------------------------- When you received it, the rootfs image you got was a canned copy of a fully formatted partition, and there was no way you could alter the size. If you installed NetBSD using the old 16448 block rootfs and are updating the binaries, or for other reasons of your own, you may find there is insufficient space in the root partition and you may wish to rebuild it to create one of a larger size. Restructuring other partitions is fairly easy, as you can archive them, etc., but the root partition requires a bit of trickery as detailed below. If you want to expand the root partition to occupy a larger space you reserved for it earlier, repeat this procedure twice, copying it away and back again. 1. Create the new partition for root, and give it a partition type which makes it an ordinary partition, e.g. 0x42534448 "BSDH" 2. Start up NetBSD 3. Format the new partition, make a mount point and mount it, e.g. newfs /dev/rsd6h mkdir /newroot mount /dev/sd6h /newroot 4. Use the following commands to copy the partition. Note the l option to tar (local file system only) which stops it trying to copy other partitions which may be mounted to the root one, and from incestuously trying to copy /newroot. cd / tar clfp - | (cd /newroot ; tar xvlfp - ) 5. Unmount and shutdown, and return to AmigaOS, e.g. umount -av umount /newroot sync ; sync ; sync reboot 6. When AmigaOS boots, enter HDToolBox and alter the partition types, changing the "newroot" partition to root (0x42534452 "BSDR") and removing the "BSDR" label from the old root partition. 7. Boot NetBSD and check that your new root partition is working From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 18:10:41 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Binusr-gnu.tar.gz on ftp.eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com Has anyone else ftp'ed the above named file and found it to be corrupted. Says something about .gz file violated. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 18:37:31 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: NetBSD-Amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: Re: solution found!!! (to my loadbsd720 problems) Sender: NetBSD-Admin@cbmuucp.commodore.com |I guess I always wanted to load up gcc on the amigados side anyways |so that I could build the new fontdumper :-). At last I can go back to |X11. Life is good again! What a pain to have to load gcc on the Amiga side just to compile simple programs. I do this, but it uses up nearly all my available disk space on my 40MB partition. Of course, I have all of unix/usr/bin in there and that accounts for a lot of the space used. I just think that many folks are not going to be so lucky and have space to spare. Maybe there should be binary distribs for fontdumper et al like there is for loadbsd and binpatch. Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 18:46:23 1993 From: Roy Trevino To: NetBSD-amiga@cbmuucp.commodore.com Subject: solution found!!! (to my loadbsd720 problems) Sender: NetBSD-Admin@cbmuucp.commodore.com Greg Oster writes: > > > > This now works great on my A3000T 030+16M+2M! Magically, I can boot again! > > Probably a lot of other people without expansion devices too!!! (if they > > have the fixed code, that is). > > Bravo!!!!! I can now boot with some regularity again... (A3000 > 030+12M+2M) The only way I'd been able to get a good boot is if I > powered down the machine first :-( (No, I wasn't running Enforcer > either...) > > Now I've been able to do 3 successful boots in a row (without a power > cycle!)- a new world record for me with this new kernel :-) Wow - I could never do even a single boot until the fix, and it hasn't failed yet. I tried a lot, believe me. Hmmm, maybe kcd is initialized to a random number which only sometimes works. For me this number was always 0, giving instant lock up. I still get a funny bootup message, something like "Zorro memory at 00000000+00000000" though. Say Michael, are you planning to put a new loadbsd binary on eunet? Several people are asking me about it now! > > Do you have X11 working??? I thought Michael H. said that something > wasn't setup right in the cc... the times I have gotten the kernel to > boot I've tried getting X11 running - I've run Xbsd (outputs > redirected to/dev/null) and xterm -C. According to "ps -aux", they > are running, but my monitor is just black.... (I can kill the > processes, so at least I'm getting around the MMU panics...) > He is quite right of course. My own server (Xami) does the same (black screen) right now. That's ok though, since I've been wanting to reimplement with Chris H's views stuff for a while now. If it's anything like iteconfig, it should be a pleasant experience. When I said "At last I can go back to X11", I meant X11 *development* :-). Roy From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 19:53:56 1993 From: Alan Bair Subject: Re: vmunix 720 loading & compiling problems To: David.Crooke@dcs.ed.ac.uk Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi David, I picked up your install notes along with your rootfs suggestions. I'll make notes of any changes required with the install notes and send them to you when I am ready to upload the new rootfs. > > > Since you are going to make the new rootfs, can I offer the list of > things that were out of date in the old one, which prompted me to > consider uploading a new version, so you can fix them all in yours. I > am currently using vmunix.713-040 and vmunix.714 with a very simple > setup (I have yet to rebuild a kernel). I'll probably stick with the 714 release, due to the problems with 720. Then follow up with a 720 rootfs when it is working. > > These are the changes I made w.r.t. the original 405 rootfs: > > 1. Fixed /etc/termcap as in the old Install/FAQ > > 2. Edited out the chaff from the passwd file (e.g. Dennis Ritchie), > leaving root with no password, the utility stuff, and one user with no > password (e.g. mw) > > 3. Rebuilt it onto a larger partition, to allow enoguh room for > bin-bin.tar.gz etc. without going "100% full". I found 10Mb to be > enough, and installed them. This is also what I was settig up. > > 4. Created /dev nodes for the printer (/dev/lp and /dev/par as 11 0) I think I have all the /dev nodes described so far. > > 5. Fixed /etc/rc to disable network stuff (commented out named), and > changed /etc/hosts from MW's specific setup to a generic > "amy.domain.domain". I was also planning on turning off things like sendmail, which are of little value on a standalone machine. > > The other thing I would suggest is including the generic 720 kernel as > /vmunix, and someone else suggested it would be a good idea to include > tools like ftp so that the /usr partition could be set up over the > network. Yes, it turns out that kerrmit also needed moving in the orignal rootfs to be usable. I'll try to get the necessary items in place. > > I'd be grateful to know when this rootfs has been uploaded so I can > change the install info I am writing. > > Cheers > Dave > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 19:59:14 1993 From: cactus%clinton.com@cbmvax.uucp.commodore.com (L. Todd Masco) To: NetBSD-Amiga@cbmuucp.uucp.commodore.com Subject: Re: solution found!!! (to my loadbsd720 problems) Sender: NetBSD-Admin@cbmuucp.commodore.com Rob Tulloh writes: > What a pain to have to load gcc on the Amiga side just to compile simple > programs. I do this, but it uses up nearly all my available disk space > on my 40MB partition. If you've got a CD-ROM drive, I suggest buying Fred Fish's "Fresh Fish" monthly CD. He includes gcc (and a bunch of other gnu stuff, plus PasTeX) on them, configured to be runnable from the CD (incl. CBM headers, including for 3.0). It'll be slow, but should be fine for small numbers of compiles. -- Todd Masco | "life without caution/ the only worth living cactus@clinton.com, DoD #269 | love for a man/ love for a woman SysAdmin, Clinton Group, Inc. | love for the facts/ protectless" - A Rich From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 20:07:16 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Question about WD33C93A PROTO chip, and more disk info" (Dec 12, 2:44am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: ggk%tirith@xenitec.on.ca, Amiga NetBSD List Subject: Re: Question about WD33C93A PROTO chip, and more disk info Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 12, 2:44am, ggk@tirith.uucp.commodore.com wrote: [...] > which I'm assuming is a prototype version of the controller chip. From > what I've read on this list so far, NetBSD won't run for me until I > upgrade that chip to a non-PROTO version. Where did you read about this? This is pure nonsense. I have but this fine PROTO-Chip, and i run NetBSd since the beginning, never encountered problems. The ONLY problem which may occure is that some drives (!) do not like to be enabled to the sync mode, which the PROTO does not handle properly. Again: this depends on the drives you are using, and the kludges in the kernel. Dear FAQ-writers: add that netBSd runs fine with the PROTO-Chip. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 20:08:01 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 13, 10:39am, Ty Sarna wrote: > ANyone have a 4M machine working reliably? I'm having tons of trouble. > I'm also wondering if my DMAINTR/dmanext at end troubles might be > related. I've resorted to running with _scsi_no_dma set for the moment. > (and boy is it slooow!) I've noticed that I haven't been able to run in 4M anymore. My system will hang up when it tries to do something with a larger partition (fsck will do it, as will trying to just mount the partition). It acts like a process it getting stuck in some kind of wait state, but since I can't run ps at that point, I can't verify that. The console is still active, as characters still echo, but the current process seems to have stopped running. I did verify that I could get into multiuser mode with 5M of memory, so I'm kind of suspicious that maybe the kernel is getting too big to run in 4M. > - mount -t mfs panics the machine, with either the mount_mfs from the > latest bin-sbin, or with the latest newfs renamed to mount_mfs > (shouldn't these be identical?) > > Here's a typical panic: > > vm_fault(d6000, 16c8000, 3, 0) -> 1 > type 8, code [mmu,,ssw]]: 401070d > trap type 8, code = 401070d, v = 16c8008 > pid = 38, pc = 0005A044, ps = 2300, sfc = 0001, dfc = 0001 That looks like the kernel got a memory fault that it shouldn't have. I'll have to try the mount on my 68040 and see if I get a similar fault. > Would anyone out there (particularly a 3000 owner) be willing to try > running with 4M for awhile? If you have an 8M machine, run loadbsd -k, > otherwise you'll have to modify loadbsd to only give 4M to NetBSD). This is the first I've heard of problems running on a 68030. I thought maybe my problem was specific to the 68040, but now it doesn't look like it. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 20:09:22 1993 From: Alan Bair Subject: Re: fontdumper uploaded To: rtrevino@sedona.intel.com (Roy Trevino) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Roy, > > I have been using your fontdumper and like it a lot. Here is a > thought: I have a bunch of Amiga fonts that I like very much, and > would like to use them with X11. It would (maybe) be very easy to modify > fontdumper to dump in X11 bdf format (or snf or pcf for that matter). > They could then be added to *any* xserver fontpath on any machine, > not necessarily just NetBSD. The first concern I have about your idea, especially the "use any where" idea, is that there may be legal considerations. If you convert Commodore fonts which are Copyrighted, it may not be legal to use them on other than the Amiga they came with. I'm no lawyer, so this is just my view on the subject. > > I guess my question is (especially to prevent duplicating any work and > also because it is after all, your program not mine :-)... > > a) have you already given this any thought/working on this? or if not Nope. > b) are you interested at all in supporting these add-ons? or if not Not really due to the legal question and that I know nothing about the X11 font formats. Besides, I don't think any of the Amiga fonts I have are any better than the ones supplied with X Windows (my opinion). > c) would you mind if I have a go at it? and if so > d) should this be a separate program or would you want to > just merge everything into yours when it's done? Sure, give it a try. However, I would recommend making it a separate program, like "amiga2X11font". You can start with the fontdumper code. > > Thanks, > Roy > -------------------------------------------------------------------- > Roy Trevino Intel Corp. > E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 > "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:33:36 1993 From: Roy Trevino To: abair@amcu-tx.sps.mot.com, rtrevino@sedona.intel.com Cc: netbsd-amiga@cbmuucp.commodore.com Subject: fontdumper uploaded Sender: NetBSD-Admin@cbmuucp.commodore.com Alan Bair writes: > Hi Roy, > > > > > I have been using your fontdumper and like it a lot. Here is a > > thought: I have a bunch of Amiga fonts that I like very much, and > > would like to use them with X11. It would (maybe) be very easy to modify > > fontdumper to dump in X11 bdf format (or snf or pcf for that matter). > > They could then be added to *any* xserver fontpath on any machine, > > not necessarily just NetBSD. > > The first concern I have about your idea, especially the "use any where" idea, > is that there may be legal considerations. If you convert Commodore fonts > which are Copyrighted, it may not be legal to use them on other than the > Amiga they came with. I'm no lawyer, so this is just my view on the subject. You have a good point here. Copyrighted fonts would have to stay on the Amiga, and if used would also have to converted individually by the owner (just like the kernel font). However, there's lots of PD Amiga fonts too, just as there are loads of PD X11 fonts. Hmm, maybe they are already related? > ... > > b) are you interested at all in supporting these add-ons? or if not > > Not really due to the legal question and that I know nothing about the X11 > font formats. Besides, I don't think any of the Amiga fonts I have are any > better than the ones supplied with X Windows (my opinion). bdf font files are very straight forward text formats. I think a very few Amiga fonts are very worth shifting :-). I'll let you know how it turns out :-). Thanks, Roy From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:44:48 1993 From: Markus Wild Subject: Re: vmunix 720 /dev/reboot problem To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 426 Sender: NetBSD-Admin@cbmuucp.commodore.com > > binpatch -a 0x1652 -w -r 0x1c vmunix720 > > and see if that fixes the problem. > > It looks like the same problem will exist for the reboot code, so the same > change needs to be made to the '030 MMU code in the reboot routine. I'll give it a try... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:47:18 1993 From: Markus Wild Subject: Re: Can't boot 720 To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 727 Sender: NetBSD-Admin@cbmuucp.commodore.com > Count me in as another poor soul who cannot boot 720. > > I am using a version of loadbsd that is 6696 bytes in length. I have also Sounds healthy... > tried compiling the loadbsd in /sys/arch/amiga/stand/loadbsd. I have > tried booting the pre-built 720 kernel as well as the result of compiling > the kernel myself. > > In all cases, after the standard "Using 2M chip, 8M fast" message, I get > a blank screen. No hard disk activity (which is what I'd expect if the > kernel were running but the graphics were not working). This is really weird... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:49:41 1993 From: Markus Wild Subject: Re: lkm To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 478 Sender: NetBSD-Admin@cbmuucp.commodore.com > The man, files,examples exist for lkm (link kernel module) but the entry > in conf.c don't existe. Why lkm don't work? I (finally...) included Robs changes to conf.c to include support for LKM devices. Sorry... (not yet in 720, but will be in next release, as the file has now physically changed on disk:-)). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:50:25 1993 From: Markus Wild Subject: Re: Can't boot 720? Here's why! To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 888 Sender: NetBSD-Admin@cbmuucp.commodore.com > If you can't reliably boot vmunix.720 then try this: > > disable Enforcer > > I can boot 720 just nice with Enforcer off. Things get weirder now.. I have enforcer enabled all the time... > This problem also existed in the Mach startup code. The problem is > that if you copy the kernel to fast RAM before shutting off the MMU, > then you MAY overwrite the MMU tables that Enforcer has set up. But I'm not doing this... I load the kernel wherever I get some (legal) memory from the system, then shut off any ints, DMA & MMU, and copy it to CHIP-mem! The startup code then copies it back to start of fastmem and finally reenables the MMU. There must be some other phaenomemon involved than just the fastmem issue.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:54:29 1993 From: Markus Wild Subject: Re: vmunix 720 loading & compiling problems To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 951 Sender: NetBSD-Admin@cbmuucp.commodore.com > Another thing to be aware of with the kernel reboot logic - the running > kernel and the new kernel have to have an exact match in the locore.s code. > This is because the running kernel copies the new kernel to chipmem, then > shuts off the MMU. If the reboot code isn't an exact match, there will > be a discontinuity between the mapped and unmapped code which you can guess > might cause severe confusion. I've had lots of fun with this because of all > the extensive changes I've made to locore.s This can't be the full wisdom on why /dev/reboot currently does not work. If I boot with kernel X, and as pretty much the first thing I do in single- user mode is copy kernel X to /dev/reboot, I'd expect it to reboot, as it is identical to the running kernel... Well, hangs:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:55:05 1993 From: Markus Wild Subject: Re: solution found!!! (to my loadbsd720 problems) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 773 Sender: NetBSD-Admin@cbmuucp.commodore.com > I don't think you will be able to run X11 on the 720 kernel without a > slight modification to the console routines [in ite_cc.c, when the ite > console is shut off by enabling graphics, there is now a viewioctl that > removes the current view - since the grfon routine doesn't display the > view, nothing will display; I just removed the VIEW_REMOVE ioctl call > (in the 713 version of that code - I think it is the same in the 720 > version)]. Argl.. so much for automatic application of diffs.. Sorry!! Just extend the #if 0 to cover that REMOVE ioctl too, and you should be fine (so I hope...). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:55:07 1993 From: Markus Wild Subject: Re: Keeping track of new releases To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1553 Sender: NetBSD-Admin@cbmuucp.commodore.com > I believe that someone (I volunteer myself) should maintain a list of > current releases and the state of all software on ftp.eunet.ch. Good idea... > a good thing), I would appreciate it if the people involved with > building the new kernels would email me (in addition to posting to > the mailing list) detailing what they did. After I test (or ask > someone else to test if I don't have the right HW), then I will either > update the document, or attempt to solve build problems privately. > The document itself will be posted to this list, comp.unix.amiga, as > well as on ftp.eunet.ch. > > If it is agreed to do this, then I would appreciate confirmation of > the requirements to run .720. (Loadbsd, ld, etc.) To boot 720, you need the new loadbsd currently available in bin/ on ftp.eunet.ch. You can also recompile loadbsd from the sources distributed in either src0712.tar.gz (which stands for sources at December 7, not version 712...) or bsdsyssrc.720.tar.gz. To *build* 720, make sure you use ld.old, as "dictated" by the Makefile, as well as probably "config.amiga", not "config". I didn't get around updating config. If you *add* assembly code, make sure to currently *not* use any branch-relative opcodes starting with "b", always use the variable-range "j" ops, ie. don't use "bra", use "jra", etc. The reason is, current gas generates wrong offsets for "b" ops. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:55:13 1993 From: Markus Wild Subject: Re: Re: X on retina To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 867 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hm, I got newest gdb from gnu yesterday, and that was 4.11. > Good thing (I told you that I had v4.19, but I don't exactly remeber the > exact version). How's shared library support for X? :-) As a hint, you probably want to use the basic approach of SVR4, not that for SunOS style shared libraries. Mainly, because NetBSD shared libraries don't use split .so and .sa files. To generate a shared library, you best create a normal archive out of the pic objects first, call it libFOO_pic.a, and then do: ld -Bshareable -Bforcearchive -o libFOO.so.MAJOR.MINOR libFOO_pic.a replace FOO with library name (X11, Xt, etc), MAJOR and MINOR should be obvious from the X11 config file (probably 5 0). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:55:22 1993 From: Markus Wild Subject: Re: vmunix720 color probs To: sgberg@charon.bloomington.in.us Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1322 Sender: NetBSD-Admin@cbmuucp.commodore.com > I tried disabling my 16 bit memory and here is what happened. My > machine booted fine with the 4MB of 32 bit memory. It definitely felt > faster than before, although it now had very little memory to run on. > However when I wanted to mount my other partitions with "mount -av" it > just hung when mount /tmp (is that for the swap partition?). I tried /tmp is backed up by the swap partition. Does your system have a swap-partition? > mounting the drives one by one by hand (all except /tmp). That worked > fine. Then I typed exit to get into multi user mode and it hung again. Of course, since pretty much the first thing it does is mount -a... If not already enabled (don't remember), try stty status ^t before doing they multiuser boot. That way, if the system hangs like you describe > It just sat there the cursor still movable (CTRL-C's would display), you should get a line of status information of WHERE your system hangs. > but otherwise nothing happened. Any idea what the problem might have > been? I had to patch _a3000_flag in order to keep NetBSD from thinking > that I have an Amiga 3000. Did you set _scsi_no_dma for a try? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 21:57:22 1993 From: Markus Wild Subject: Re: hard disk for A3000 & netbsd? To: tero.manninen@oulu.fi (Tero Manninen) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1501 Sender: NetBSD-Admin@cbmuucp.commodore.com > Is there any list of hardware what works with NetBSD? I think the FAQ includes one, Guenther? > My interest is now directed to SCSI disks that would work with A3000 > proto-scsi chip. One, quite interesting, option is to buy a 1G SCSI-2 > disk (Seagate ST11200N 1050 MB 10,5 ms Fast-SCSI-2). Other Don't know about this one. > possibilities include a ibm disk (IBM "Spittfire" 1050 MB 8.5 ms 512 Is this one of the 0663E-13 series? I had *major* troubles with such a drive, although it was pleasantly fast in those times where it didn't quit service before I could take any measures... > kb cache Fast-SCSI-2) and a HP disk (Hewlett-Packard C2247 1050 MB > 10,5 ms SCSI-2). I'm currently a very happy user of a DEC DSP3105 drive. You might add that drive to your list of considerable drives too, it's a 1G drive, 9.8ms FAST-SCSI-2. Also awaylable as 1.2G and 1.6G. No, I don't earn any money by promoting it, nor by not promoting the IBM drive... > A 2G disk would, of course, be better, but I'm not planning to spend > that much money to a disk (like Seagate BARRACUDA, 2100 MB 6 ms) Althouth the Barracuda is a very fast drive, there should be less expensive, albeit less fast, 2G drives too. Note that the above experiences were made with an AM33c93, not with the WD proto, but I thought they'd help you nevertheless. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:15:21 1993 Subject: Can't boot 720 From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Just an update... Enforcer has nothing to do with it. The problem really is, as was revealed earlier, a bug in loadbsd that fails for those whose Amigas don't need expansion devices :-) Loadbsd used to be memory-contents dependent. Using XIcon or shell, Enforcer or not, all can change the layout of garbage in your memory prior to running NetBSD. Red herrings abound... -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:16:04 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Binusr-gnu.tar.gz on ftp.eunet.ch To: jvasher@cquest.mi.org (Joe Vasher) Cc: netBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 452 Sender: NetBSD-Admin@cbmuucp.commodore.com > Has anyone else ftp'ed the above named file and found it to be corrupted. Says > something about .gz file violated. Just ungzip'd it on ftp.eunet.ch, and this worked without any such problems. To give you a hint whether your copy is corrupt, this is a sum of the file: 46442 10458 -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:21:28 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Anyone have a working 4M configuration To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 552 Sender: NetBSD-Admin@cbmuucp.commodore.com > vm_fault(d6000, 16c8000, 3, 0) -> 1 > type 8, code [mmu,,ssw]]: 401070d > trap type 8, code = 401070d, v = 16c8008 > pid = 38, pc = 0005A044, ps = 2300, sfc = 0001, dfc = 0001 Hm, this dies in pmap_enter_ptpage, which surely was affected by the recent addition of the '40 code. I don't say this IS because of the '40 code, but it could be ... Mike? Sorry, this is too easy.. but.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:35:36 1993 From: Bill Squier To: chopps@emunix.emich.edu, mw@eunet.ch Subject: Re: AS Cc: NetBSD-Admin@cbmuucp.commodore.com, netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >From: Markus Wild >> Well I have an idea on why some binaries from markus (I also tried the >> as from the binary distrib) don't work. I think that the GVP >> accelerators may be broken in regards to odd aligned memory access >> could this be a problem? I ran across this when I was working on > >Hm, I don't want to discourage you.. but what would be considered >"odd" in this context? Normal system usage (that is, not using >/dev/rsd*) will never try to transfer non page-aligned, non page-sized >blocks. For raw i/o, if a buffer is at an odd address, it is handled >by PIO, not with DMA. Besides, if you're using scsi_no_dma (which I >recall you said you're doing), alignment should be no issue at all, as >the whole transfer is then done by reading/writing the data register >of the wd-chip, and using the cpu to store/fetch data to/from >memory... No, the original GVP accelerators (not SCSI host adapters) had problems accessing memory on odd boundaries. That is, the _030_ couldn't do it. As far as I know, this problem has been cleared up in all future releases of accels, and they released an upgrade to the originals that fixed the problem. (this was years ago that this problem happened) -wps From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:40:22 1993 From: Markus Wild Subject: Re: A4000/A2091 getting closer To: tjhayko@io.org Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 558 Sender: NetBSD-Admin@cbmuucp.commodore.com > segment 2 at 00001020 size 00200000 > ZorroII memory at 01bfc000-01dfc000 These two sound VERY bogus.. seg#2 is certainly starting at 0x0, and the range of Z2 memory seems completely off, should start at 0x00200000 as the previous segment 1 showed... > root on sd0 Not "changing root device to" ?? Unless you're using a non-generic kernel, the message should be "changing to", not "on". -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:41:04 1993 From: Markus Wild Subject: Re: MMU Panic To: diavolo@engin.umich.edu (Calvin Chu) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 407 Sender: NetBSD-Admin@cbmuucp.commodore.com > dreg 000000A FFFFFFFF 00000100 00000001 00000002 00000000 0000000D 0000000D > areg 009BE3C 00000000 0000CF42 00010001 00072618 000956D4 FFFFFF24 DEFFFFFC Although these can be of some help, much more interesting if the value of the pc... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:41:31 1993 From: Markus Wild Subject: Re: solution found!!! (to my loadbsd720 problems) To: rtrevino@sedona.intel.com (Roy Trevino) Cc: NetBSD-Amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 754 Sender: NetBSD-Admin@cbmuucp.commodore.com > This now works great on my A3000T 030+16M+2M! Magically, I can boot again! > Probably a lot of other people without expansion devices too!!! (if they > have the fixed code, that is). > > Here are the actual diffs, mine vs original 720 loadbsd: > > 151,152c151,152 > < cd = 0; > < for (kcd = (struct ConfigDev *) (knum_cd+1); > --- > > if (num_cd) > > for (kcd = (struct ConfigDev *) (knum_cd+1); > > Thanks for the diff, just applied it to my sources! Grin, after a long time, looked at loadbsd.c again, that sucker really changed over the past months :-)) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:41:37 1993 From: Markus Wild Subject: Re: AS To: chopps@emunix.emich.edu (Chris Hopps) Cc: NetBSD-Admin@cbmuucp.commodore.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 991 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well I have an idea on why some binaries from markus (I also tried the > as from the binary distrib) don't work. I think that the GVP > accelerators may be broken in regards to odd aligned memory access > could this be a problem? I ran across this when I was working on Hm, I don't want to discourage you.. but what would be considered "odd" in this context? Normal system usage (that is, not using /dev/rsd*) will never try to transfer non page-aligned, non page-sized blocks. For raw i/o, if a buffer is at an odd address, it is handled by PIO, not with DMA. Besides, if you're using scsi_no_dma (which I recall you said you're doing), alignment should be no issue at all, as the whole transfer is then done by reading/writing the data register of the wd-chip, and using the cpu to store/fetch data to/from memory... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:42:02 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 13, 10:12pm, Markus Wild wrote: > > vm_fault(d6000, 16c8000, 3, 0) -> 1 > > type 8, code [mmu,,ssw]]: 401070d > > trap type 8, code = 401070d, v = 16c8008 > > pid = 38, pc = 0005A044, ps = 2300, sfc = 0001, dfc = 0001 > > Hm, this dies in pmap_enter_ptpage, which surely was affected by the > recent addition of the '40 code. I don't say this IS because of the > '40 code, but it could be ... Mike? Sorry, this is too easy.. but.. With all the places the '030 and '040 code is different, it is certainly likely. I'll look around that area later tonight and double check it. I tried to mount the /tmp partition when running in 4M. I don't get a fault, but the mount process does hang. I looked at the process structures on one of the hangs and it looks like the process is waiting for a free page, so I think the available memory is getting close to the edge of not working. I'll be digging into this more. For those who can build their own kernel (and aren't running on the '040, you can configure the kernel to not load the fpsp.o file by commenting out the FPSP option in the config file. This should make the kernel smaller and may free up enough memory to run. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:42:06 1993 From: Markus Wild Subject: Re: rootfs setup issues To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1120 Sender: NetBSD-Admin@cbmuucp.commodore.com > Several days ago you posted a script that would appear to delete any files > found in /usr/sbin that were also in /sbin. Should there be no duplication > between these two directories? No, there shouldn't. > I already understand that the /sbin programs should be staticly linked and > the /usr/sbin ones can now be dynamically linked. I pressume the file Yup. > command should be able to indicate this difference. However, when I tried > to run it, there was a complaint about not finding the /etc/magic file. Damn.. that rootfs really is "slightly" outdated.. I uploaded a current magic.gz into ftp.eunet.ch incoming. > You have been providing updated binaries with various releases, which I > will include in the rootfs, but besides the original rootfs, where could > I get the none binaries like /etc/magic? I pressume they originated from > sun-lamp, but did you have to make any changes for the Amiga version? Nope, plain vanilla sunlamp. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:45:08 1993 From: Markus Wild Subject: Re: X11R5, MMU Panic, etc. To: chopps@emunix.emich.edu (Chris Hopps) Cc: NetBSD-Admin@cbmuucp.commodore.com, amigaman@esu.edu, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1802 Sender: NetBSD-Admin@cbmuucp.commodore.com > I was talking to Ralph Babel he told me that (and I don't know > anything about the WD chip) the transfer size (a 24 bit value) needs > to be set to 512 for the GVPII accelerators to work correctly with > DMA. This is what the GvpPatch for amigados does. Again this 512 > value is for the WD chip not the GVP DMA. Ralph said it had something > to do with the bus not being fast enough to handle the big transfers. > > Currently I have to run with DMA off (its very slow too.) becuase of > the prblems that are created with it on.. > > Here's hoping that someone can implement what Ralph was talking about :^). Could anyone with a GVP controller and the system ready to compile a kernel try the following patch: *** gvp11dma.c Sun Nov 21 22:37:26 1993 --- /tmp/gvp11dma.c Mon Dec 13 19:29:55 1993 *************** *** 77,82 **** * the buffer pages are physically contiguous (MAXPHYS/NBPG) and the * buffer is not page aligned (+1). */ ! #define DMAMAXIO (MAXPHYS/NBPG+1) struct dma_chain { --- 77,83 ---- * the buffer pages are physically contiguous (MAXPHYS/NBPG) and the * buffer is not page aligned (+1). + * Sigh, GVP wants 512 byte blocks, NBPG almost stalls the machine.. */ ! #define DMAMAXIO (MAXPHYS/512+1) struct dma_chain { *************** *** 249,253 **** dcp->dc_addr = (char *) kvtop(addr); ! if (count < (tcount = NBPG - ((int)addr & PGOFSET))) tcount = count; dcp->dc_count = tcount; --- 250,254 ---- dcp->dc_addr = (char *) kvtop(addr); ! if (count < (tcount = 512 - ((int)addr & 511))) tcount = count; dcp->dc_count = tcount; -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 22:52:04 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Anyone have a working 4M configuration Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312131856.AA07573@gemini.oscs.montana.edu> osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > I've noticed that I haven't been able to run in 4M anymore. My system > will hang up when it tries to do something with a larger partition (fsck > will do it, as will trying to just mount the partition). It acts like I have no trouble mounting or fscking a 9M partition, as long as I have DMA disabled (if I don't it dmanext panics, particularly on newfs and fsck) > a process it getting stuck in some kind of wait state, but since I can't > run ps at that point, I can't verify that. The console is still active, > as characters still echo, but the current process seems to have stopped > running. I did verify that I could get into multiuser mode with 5M of This is kind of like what I get. The console is active and seems to be at full speed, but the rest of the system slows down. If I leave it for a few minutes, it eventually panics. > memory, so I'm kind of suspicious that maybe the kernel is getting too > big to run in 4M. Too big to run at reasonable speed I can understand, but it shouldn't be crashing. Hmmm... I seem to remember something about troubel with 4M i386 machines on current-users, but the details are really fuzzy. Anyone remember anything about that? -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 23:18:19 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Status NetBSD bugs Sender: NetBSD-Admin@cbmuucp.commodore.com I thought I would pass this on, information on general and not so general NetBSD bugs: > > In article , conklin@kaleida.com (J.T. Conklin) writes: > |> > For example, to send a query about all the bugs: > |> > $ Mail -s "--summary" query-pr@sun-lamp.cs.berkeley.edu < /dev/null > |> > > |> > If you want to know more about a particular bug, let's say bug 40: > |> > $ Mail -s "--full 40" query-pr@sun-lamp.cs.berkeley.edu < /dev/null > |> -Rob From NetBSD-Admin@cbmuucp.commodore.com Mon Dec 13 23:36:35 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Anyone have a working 4M configuration Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article tsarna@endicor.com (Ty Sarna) writes: > In article <9312131856.AA07573@gemini.oscs.montana.edu> osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > > I've noticed that I haven't been able to run in 4M anymore. My system > > will hang up when it tries to do something with a larger partition (fsck > > will do it, as will trying to just mount the partition). It acts like > > I have no trouble mounting or fscking a 9M partition, as long as I have ^^ panic: brain: lost sync with fingers Oops. 9M isn't my idea of a large partiton. That was supposed to say '999M'. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 01:31:48 1993 From: niklas@appli.se (Niklas Hallqvist) To: tsarna@endicor.com Cc: NetBSD-amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Ty" == Ty Sarna writes: Ty> ANyone have a 4M machine working reliably? I'm having tons of Ty> trouble. I'm also wondering if my DMAINTR/dmanext at end troubles Ty> might be related. I've resorted to running with _scsi_no_dma set Ty> for the moment. (and boy is it slooow!) I run an A2000/GVP11 with 4M FAST quite reliably, although not as stable as I would want to :-) I run with DMA enabled without any problems (well, I have maximized the transfer size to 512 bytes in order to diminish the silo overflows, but they still appear, not as often though). I have just 8MB swap and suffer from severe thrashing, but it works.... A small note: I have configured my kernel to be minimal, i.e. no NFS and no extra SCSI or graphic drivers. At boot time I have about 1.9 MB free usermem. Niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 02:52:59 1993 Subject: A thought about custom chips display To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com The more I use netbsd and X, the more I wonder about how we should add some wisdom to the graphics chips display code. For example, chopps has done a NIFTY job of reworking the display/console code already. One thing I notice right off the bat is that no matter what ite_default_width and ite_default_height I have, I am stuck with a border of some size around the display area. Can't help it - that's the way the amiga chips work. However, I have a white background with black text on it (or is it grey...). What this means is that the border around my display is bright white. It seems like not much of a problem, but it is if you consider that this burns in the phospher of your monitor. This is why we have screen blankers - to protect the phospher. So what I suggest is that the display code be modified so that it either: 1. renders reverse video and swaps colors 0/1 or 2. renders text into bitplane 1 instead of 0 and cursor into the other plane. The result is that the border will be BLACK. I still want my white background with black text in the display area... X looks nice that way. I have compiled xlock for X11R5 and when I invoke the screenblanker, the border remains white and the screenblanker only works on the interior... I hope I make good sense. Cheerios :-) From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 03:05:35 1993 From: Bill Squier To: chopps@emunix.emich.edu, mw@eunet.ch Subject: Re: X11R5, MMU Panic, etc. Cc: NetBSD-Admin@cbmuucp.commodore.com, NetBSD-Amiga@cbmuucp.commodore.com, amigaman@esu.edu Sender: NetBSD-Admin@cbmuucp.commodore.com >From: Markus Wild >Subject: Re: X11R5, MMU Panic, etc. >> [...deleted...] > >Could anyone with a GVP controller and the system ready to compile a >kernel try the following patch: > > [...keep snipping...] Will try it tonight. I'm sure I won't be pleased with the performance. :-) -wps From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 03:08:36 1993 Subject: Fixed kernel, works nice, X tips To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com I built and fixed a kernel for people to try. I made a tar.gz file for it and uploaded it to ftp.eunet.ch in the .../NetBSD-Amiga/incoming dir, filename is vmunix.mykes.tgz. Here's the readme for the kernel: --- readme --- I went to the trouble of building this new vmunix for people to try/use. I've fixed the following things: 1. reboot and /dev/reboot fixed (replaced pc@() addressing with abs addressing in locore.s) 2. applied some unpublished patches to grf_cc given to me by chopps. I will let him make the patches public (they are his, after all). 3. modified the grf_cc sources for pal display to set max width to 768 and max height to 578. Previous values were 724 and 566. ALl I changed was initialization values to these. I don't promise they work at that rez :-) 4. modified kbd.c to have 200us delay for handshaking. To the best of my knowledge, this should fix the key repeat problems that some are having. I can't promise it works. Markus W. has informed me that the fix I made only affects keyboard during prompts for mmu panic, etc. THere were two places in the source that used 85us, and mtk already fixed one of them. 5. The _ite_default_height is set to 448 and _ite_default_width is set to 688. Why? because I want my X at that resolution :-) So, if you want to fiddle with the values, try chopps' iteconfig stuff or use binpatch on the amigaos side: binpatch -s _ite_default_height -r 400 (or whatever) vmunix.721 binpatch -s _ite_default_width -r 640 (or whatever) vmunix.721 Notes: You must use the loadbsd in .../NetBSD-Amiga/bin/loadbsd from ftp.eunet.ch for any kernel >= 720 to work. chopps' patch has X working wonderfully for me. If you want to compile X programs, you must link -static. This is due to the X11R5 libs not being shared libs (yet). Please french guys: make new shared X libs and release retina server soon :-)))) I have xdm working. I had to recompile xdm from X11R5 source tree (got it from ftp site) and link with -lcrypt to get it to really work. The xdm distributed with X11R5 does NOT do shadow passwords correctly. I'm not sure I can upload a working binary, as such... But you now know how to make your own xdm (remember gcc -static for linking). Once you have your working xdm (test it as root: xdm -nodaemon) you can have netbsd autostart xdm from your /etc/ttys file. Here's two lines from my file so you can see what to change/add: #console "/usr/libexec/getty std.9600" vt200 on secure # ITE console console "/usr/bin/X11/xdm -nodaemon" vt200 on secure Warning: if you don't have fixed xdm binary, then xdm will not let you login if you have ANY password at all. You can vipw and remove your password and use the xdm distributed by the french genii :-) Another X tip: you can use xmodmap to remap your mouse buttons on a two button mouse. I needed this so I could select with left button and paste with right (in xterm, etc.). To do this, add to your ~/.xsession: xmodmap -e "pointer = 1 3 2" mykes@shell.portal.com From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 03:08:49 1993 From: Calvin Chu Subject: Deringer To: NetBSD-Amiga List Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com Is anybody out theree running NetBSD on a Deringer 030? Somebody replied a while back and said hee is running on a Deringer.. I'd like to know how NetBSD is set up for it.... thanks. o/ \o/ o <|><|> <|\ Ciao ragazzi! :-) diavolo@azure.engin.umich.edu /| / \ /| / \ // \\ / \ La universita' del Michigan! Va blu!!!!!!!!!!!!! From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 03:09:31 1993 From: niklas@appli.se (Niklas Hallqvist) To: mw@eunet.ch Cc: tsarna@endicor.com, NetBSD-amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "MTK" == Markus Wild writes: >> vm_fault(d6000, 16c8000, 3, 0) -> 1 type 8, code [mmu,,ssw]]: >> 401070d trap type 8, code = 401070d, v = 16c8008 pid = 38, pc = >> 0005A044, ps = 2300, sfc = 0001, dfc = 0001 MTK> Hm, this dies in pmap_enter_ptpage, which surely was MTK> affected by the recent addition of the '40 code. I don't MTK> say this IS because of the '40 code, but it could be MTK> ... Mike? Sorry, this is too easy.. but.. I have had problems in pmap_enter_ptpage when running out of kernel memory. If I remember correct the ste was NULL. I used to get this when using my AmigaDOS FS in memory-hogging ways (recursive scans of large directories with large files). I guess out of memory conditions aren't correctly handled... Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 03:37:48 1993 From: DCG9367@tntech.edu Subject: Re: Deringer To: diavolo@engin.umich.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"diavolo@engin.umich.edu" X-Vms-Cc: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I used to have a Derringer 030 at 25mhz for my 500. Then I upped to a 2000 for a while, and then got a GVP G-Force040. When I had the Derringer in both machines, NetBSD worked flawlessly. The only problem is that DMA MUST be turned off if NetBSD is loaded into 32-bit ram. I don't know if this is still true, but I had to do it. Other than that, I had no problems with it working. BTW, the isa_3000 (spelling?) patch must be 0 if NetBSD is loaded into the 32-bit ram on the Derringer. If you need any more info, drop me a line. David. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 05:18:44 1993 From: tjhayko@io.org To: netbsd-amiga@cbmuucp.commodore.com Subject: Mount partitions problem Sender: NetBSD-Admin@cbmuucp.commodore.com I'm running vmunix720 patched up to run on my A4000/A2091, and I'm trying to rebuild my partitions the way I want. I've got a Toshiba 105MB drive partitioned into my BSDR (8MB), BSDS (24MB, since I've got 12MB of memory), BSDD (30MB, hopefully /usr soon), BSDE (16MB, hopefully /home), and BSDF (20MB, /opt but to be used to tranfer files between NetBSD and AmigaDOS). I've done a newfs with what I think is the newest version of newfs, but when I try to do a mount -av with the following fstab: /dev/sd0a / usf rw 1 1 /dev/sd0d /usr ufs rw 1 1 /dev/sd0f /opt ufs rw 1 1 /dev/sd0e /tmp ufs rw 1 1 I get messages about /usr and /opt no such file. Any helpful hints? Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 06:07:36 1993 From: Alan Bair Subject: Re: Mount partitions problem To: tjhayko@io.org Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I'm running vmunix720 patched up to run on my A4000/A2091, and I'm trying > to rebuild my partitions the way I want. I've got a Toshiba 105MB drive > partitioned into my BSDR (8MB), BSDS (24MB, since I've got 12MB of memory), > BSDD (30MB, hopefully /usr soon), BSDE (16MB, hopefully /home), and BSDF > (20MB, /opt but to be used to tranfer files between NetBSD and AmigaDOS). > I've done a newfs with what I think is the newest version of newfs, but when > I try to do a mount -av with the following fstab: > > /dev/sd0a / usf rw 1 1 > /dev/sd0d /usr ufs rw 1 1 > /dev/sd0f /opt ufs rw 1 1 > /dev/sd0e /tmp ufs rw 1 1 > > I get messages about /usr and /opt no such file. Any helpful hints? You need to have the directory you want to mount on already in place. In your case, I suspect that /usr and /opt are missing. > > Tom Hayko > tjhayko@io.org > > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 08:58:39 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A thought about custom chips display To: NetBSD-Admin@cbmuucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > The more I use netbsd and X, the more I wonder about how we should add > some wisdom to the graphics chips display code. For example, chopps > has done a NIFTY job of reworking the display/console code already. > > One thing I notice right off the bat is that no matter what > ite_default_width and ite_default_height I have, I am stuck with a border > of some size around the display area. Can't help it - that's the way > the amiga chips work. However, I have a white background with black I will add the border blanking into the next set of patches (after the X fix ones :^) I wanted to get the gfx tested before I messed with this stuff, I think it works ok now so I will borderblank. :^) Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 09:15:37 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: CC patch to fix X and stuff. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com Ok here is the patches that everyone should apply to there grf system, it will hopefully allow 2 things: Running X (``mykes'' says this is a go :^) and pruning cc modes through recompile, I added some more ifdefs :^) begin 600 cc-X-fix.diff.gz M'XL( /<.#"T" \U:_Y.:R!+_V?TK.G>5G*Y?%A"_K-Y>5;+9RUDOV:22O4ON M75U9"*-0B\ #=.-+Y?[VUSV#@"R@&%/UK&15Z.GNZ?Y,]V<&WSKV!BP'@DUP MH?FZ>:$MK85V8;#U")X^76JZ[[+/GN883Y^>&=9\#NUK!9H^TU=^8*T9#!2I M_7CLQ<*?T_^IKD=O4TV1%'6Z= W6T:'RB+/S\_/C;-7>N Z\9#I '^3+D3H8 MJ3W\<-D]:[?;U1VI?5@)=;("DCI2>B/\P-6=[[ZXQ]U>JSL$_I6LT==+P$_M M,P XYW\NSIKPHS4'@\TMAQE0?_7^U^ESLMC ^_CO1\O1[97!X(?('<^WUAWS MAWR#9*([2)GL]EM=58J-XBLTK6!J:*'6_L5DALTV4TRFSYP0GEV!]+D[KM4 M+LX!G5)1F#D@=FWDB11MTR-/4)/DEJ^RU53M#$$Y"#I=N[#]<-2EP)E'!D MGD%%55J*VDU,*JJ*%_I;HU\CDSMX('OD334LF"?"@6%70T(L7Q$+\;A3H"%1 MEL&#/,+R<6(\B-H"SYX= Y/D5J=S(?Z)F:$4Z2VJ2\KEH*5>YFO+(@C*RF5+QL8;3UKN M=O'"((;@N+24XLW5],'U#8@Y#4II*SNO MGU__B^:2ZQ*N.WE;W+?C9$[+7KYZ?_-GQ,?&9T] K#EN::EYTQ"B.:A22U;5 M-/$KTE#,YS)Z#U5;PPS*[?PMCM6( DAIIMN_IT>Q?J%A)4@WFA MV^ _7;WU^_;HPC0ELV>[)9P(R("*5XMM*3 M6TJO=_"LN>;4;!ZM1,>?9D_=Z4GH?$T3^MA#<6DY,P=+69L MM5#M0=' BX;+ @@TQPHWH)M,OPMU\ESMKA$!"*,NF_'/5*#NMD=8 T."Y61&)0 MTT'[)!R$!DIY'O.GMA6$?_T]3B1H M^IG[4YLY>R0"Z[]L+!;I(TMB#AE[8D>&B.C%&Y+OC8C3Y*A2U(LX_)/CP/GD M.' ^J0BK@Y.8N\S[?5SFEYGM[R#>>F5 9-B:SO*A5';6T=P+Z.9>0#\Y*;GNR'30\MU M#( MTX7C^NCGW/7%%+R5[[EH.5*/4ZQ'.J^@+3 M>7A""L:0DFM ,ZQA;1T0P46&A M"@/KZ4(S#)_B^=F8SR5)2JGA.:6,VJY[#UJ(45@$6RV) EIPJ,!W5XXQ];0% MJ],5%P.IKX+0I1,9H7$"2W0$K! ^@<=<3'F+A_+Z6BBM\1<7Q;I*SVMY=+ . MKRV==>#.1!\>M,TCZ0<&.BHV-5R+,Q>Q]HD#3\,:XP2NS3J/1M#MN6UY,&/A M V,.&5MV -YQMQX;L&P;16'EF(C=#:&$@V?.-([_K#S>"EQ 1&^XI0T+>5:T MM6;9LSQ_ZJAQXZYP)K[S4XC3)_R33^*I=58\-#7G/N@TLC=H&4^$MZ)3TG , M9>"Z3H?N[N1N/N.YQ]S-EAU3\XT'7"%3NL:"8+PKR9,L)/G)Y3E^F&U"%DRI M\/KN UW -SZ.#Z65E _N#Y-_WR"TU\$6V@T^ .!+],[G.*=94'G&>@#1*71T M/D?EX-.G3ULHTFL==!XL U-_!7U5&M-WDUD+DVJ#*HD+W''\KHRC85^WOD;3 M%&?Y?_0:<#--FBI;/$*@.8 )\"AUCSM26;K>9S MO, QK^OM")PP:M?KD,V,F(RPPS]G\A%/+IYH1N!S+:J2.U-R%:1,2.R M56C,R+-E[)A*E2VL&/=KC=^J8<1F*\L.+2<. )>9ST@DEJ&U(_I+2U0$[/NX M4#1;C"JJHR\G']Z]?OXG1UE20\^2>EZ7HV-1ZJ/8_GIY1^S;[L?S2ZB3L(%M MXMJHXU)<,'B@9;JVL!VB5[B$\&;447#(-.(0;GP2F^=$+B>3D9/)*4[6'[8& M:F8C'#&=(/17>LCY2N#.0SWY)%C5CX+/PJMWO]].[NJ6UX!ZO;Y"ONPL&I;7 MWGZ,AS4N1"&O9S4WHJ?K%V+O#]]VY_RS806X7#:=DB=5J4W^4&U= M[ASS;Y\RZ40,7KV9(I-\>SM"R^*5B:N8%=07GG@"\#B'XI6C]-=?\[5BXSY< M;?[&N=N2U7Z*44L24NQ>,LM(T"\)-]-?4]/L.^'PE M.NX#)>.G !N2Q9F*%;+4-UH+T=>.H-W4,[ H:?<,>^.#Z]]#?0(++*5!@[KG M%LPK#TF%2"3JCQ"%#0Z5_?8QUA1U"!I DMN?7/&56=<"T1IIC6S7AA6:Q.1( MY3WZCKU-M"ZN[8[W,E+V!GZS0MWL\ *)4#5$$T1EKL.BB62R3E-L1,FCS0!] M)ZQ_X=<>K8CSA8=%Y5FR,$B>+XZTL.7,712UN*B@6@+)0G FMF.SYS-^:1_*W"+L9_K:+WQP* MUXR*=K,JA6L>1^&:$85K[F"^B,(U2RE<=N7D\J_F/O[5S.5?S5S^U=S#OYK[ M^%\K!<9>W_SYNT? M-X]M?15LA1Y#B*WWVY)?BF_/3BJ=]&#[+3SIV=XK.^G9RCQ^QM-32T]ZXH&[ MO^56Y9'2+3[I(1+92Q_GDYKM#WW2:_"0L]#TV'A5#"5IG',_M7SI',0N^N5= MH5ZJ SGWTSN[B"0KZ5_,T"../KF[V:J>?ISZ#=$;H5;.^<' GU=PZ)+[?%MOB"93UPVV'^:=4ZA[I +.G<]<)L=/]#\&>YZ2*-0 end From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 09:52:04 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Xami To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com Ack I just killed some mail (actually archived it but its pretty hard to get at now) So I don't have the Xami's authors name sorry. What I wanted to say is about using the view stuff. The problem is currently we have no way to to allow multiple things like console and X I guess we need to chnage some stuff (will be working on these now) in ite and other places to support swapping the input focus around and such. This will allow multiple consoles etc. Currently however I was under the impression (as markus informed me) that X somehow co-exists with /dev/console so that both cannot be run at the same time (displayed) As for right now I would say code it using the mix of grf0 (ick). Currently grf0 is only a hack into the view code but this hack also works to syncronize things. -OR better yet- If you wanted to open up other screens however you can use the view devices, actually you do all your graphics into views, how? tell grf[0] to turn off (not needed but at least it avoids the consoel popinng up sometime when the user won't be able to type into it.) Then open /dev/view00 .. /dev/viewXX for each screeen you want (view00 currently will return EBUSY but thats ok you should be handling this :^) Is your input and output coming from the /dev/console? I am not sure that is all clear so I will try and do a walk through pseudo boot of an X like thing: tell /dev/console to turn off. This should cause /dev/console to lose the input focus. open /dev/ms and /dev/kbd to get input from user. open /dev/viewXX where XX is 00 then 01 until you get either a valid fd or your error is not EBUSY (signifying someone else is using it) use ioctl to get bitmap VIEW_GETBITMAP use ioctl to get colors VIEW_GETCOLORMAP use mmap to map the bitmap into your process space. Now you can do anything to the view/bitmap that you want render into it using the mapped mem and can change the colors (ex: in iteconfig and view code I uploaded) using ioctl VIEW_SETCOLORMAP. Whats so nice abou tthis? You don't have to worry about the silly stuff behind whats happening. Oh BTW ioctl VIEW_SETSIZE and VIEW_GETSIZE to set or find a new display size (whatchout however as this will possibly de-allocate and re-allocate the bitmap so you should get the bitmap struct again and remap it into your process. As you can see this was my first attempt at RTG I guess becuase there are some really kooky boards out ther it doesn't quite work becuase the boards cannot mmap the entire bitmap at once. Dunno how to handle this I have some ideas at how retina could be done but I don't know much about other display cards. I also want to add to the view spec (and my grf monitor stuff) some more ways to ask for specific display types Right nowit just uses a closest fit algorithm to pick the display mode. This is not good enough as we need to allow programs to say *NO INTERLACE* or *NO HIRES* etc... The view device alsocan be expanded (backward compatibly) to allow oversized bitmaps as my /dev/grf (in dev/grf/*) allows for this. Although my /dev/grf probably needs some more params to specify the X and Y deltas inside the oversized bitmap (I used the speced deltas for giving everyone there adustable display offsets :^) ) Anyway I really hope you do use this method as its the cleanest and will in the future I am sure add support transparently to your X server for other display cards (or AGA mode etc :^) Chris. From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 10:13:06 1993 From: chammer@HRZ.Uni-Bielefeld.DE Subject: Re: Question about WD33C93A PROTO chip, and more disk info To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) (Markus Illenseer) Cc: ggk%tirith@xenitec.on.ca, netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Dec 12, 2:44am, ggk@tirith.uucp.commodore.com wrote: > [...] > > which I'm assuming is a prototype version of the controller chip. From > > what I've read on this list so far, NetBSD won't run for me until I > > upgrade that chip to a non-PROTO version. > > Where did you read about this? This is pure nonsense. > I have but this fine PROTO-Chip, and i run NetBSd since the > beginning, never encountered problems. I could not switch sync on with the proto before 709. with pl08 it worked terrific. With 709 it does not work at all any longer with sync. > > The ONLY problem which may occure is that some drives (!) do not like > to be enabled to the sync mode, which the PROTO does not handle > properly. Again: this depends on the drives you are using, and > the kludges in the kernel. > > Dear FAQ-writers: add that netBSd runs fine with the PROTO-Chip. This is only in a way true since 709 :) > > -- > Markus Illenseer > ciao Carsten From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 10:28:30 1993 To: Markus Illenseer Cc: Amiga NetBSD List Subject: Re: Question about WD33C93A PROTO chip, and more disk info From: ggk@tirith.uucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >On Dec 12, 2:44am, ggk@tirith.uucp.commodore.com wrote: > Where did you read about this? This is pure nonsense. > I have but this fine PROTO-Chip, and i run NetBSd since the > beginning, never encountered problems. It was in the last month or two, reading the mailing list. No one ever said ``The proto chip will not work'' but there were hints that it did not work well... Nothing very specific, so I decided to ask. > The ONLY problem which may occure is that some drives (!) do not like > to be enabled to the sync mode, which the PROTO does not handle Perhaps this the problem I read about. Like I said, it was kind of vague, but I was suprised that I'd had no problems when I found the proto chip in my machine. Does this mean I need a new chip to enable sync? Does sync mode work properly with the non-proto chip? > Dear FAQ-writers: add that netBSd runs fine with the PROTO-Chip. Or perhaps itemize the potential sync mode problems with the proto chip. In fact, I've yet to really see anything documenting why inhibit_sync is set and so forth... >Markus Illenseer Gregory Kritsch | 3A Computer Engineering at UWaterloo ggk@tirith.uucp | "Life is a highway ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 13:00:47 1993 From: Tero Manninen Subject: Re: AS To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1089 Sender: NetBSD-Admin@cbmuucp.commodore.com > > BTW, can gas 1.38.1 from the gcc 2.3.3 package create pc relative > > code? This would be needed when I translate my boot block code to > > disk.. > > Create? You'll have to code pcrelative.. ??? I'd like to do things in C, not in assembly! The question should have been whether gcc produces such assembly that gas can compile in to pc relative binary, or not. > > Then another thing.. at boot block executing time the display hasn't > > been opened. It would be quite nice to put some output from boot > > loader to console. So, how do I create a display where to put data > > (for example by graphics.library Move() and Text())?. > > Not opening a display > from ADos would also have the benefit that NetBSD can profit from some > of the compatibility built into the newer chipsets that behaves like > older chipsets as long as its not initialized properly. That would > mean that AGA probably behave like ECS if not initialized as AGA, and > opening a screen could just cause right this... Ok, I'll leave the textual output only for debugging purposes to the source. ++Tero From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 18:32:51 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: GVP dma patch (tried it) Cc: mw@eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com Howdy! I tried this last night... |Could anyone with a GVP controller and the system ready to compile a |kernel try the following patch: | |*** gvp11dma.c Sun Nov 21 22:37:26 1993 |--- /tmp/gvp11dma.c Mon Dec 13 19:29:55 1993 |*************** |*** 77,82 **** | * the buffer pages are physically contiguous (MAXPHYS/NBPG) and the | * buffer is not page aligned (+1). | */ |! #define DMAMAXIO (MAXPHYS/NBPG+1) | | struct dma_chain { |--- 77,83 ---- | * the buffer pages are physically contiguous (MAXPHYS/NBPG) and the | * buffer is not page aligned (+1). |+ * Sigh, GVP wants 512 byte blocks, NBPG almost stalls the machine.. | */ |! #define DMAMAXIO (MAXPHYS/512+1) | | struct dma_chain { |*************** |*** 249,253 **** | | dcp->dc_addr = (char *) kvtop(addr); |! if (count < (tcount = NBPG - ((int)addr & PGOFSET))) | tcount = count; | dcp->dc_count = tcount; |--- 250,254 ---- | | dcp->dc_addr = (char *) kvtop(addr); |! if (count < (tcount = 512 - ((int)addr & 511))) | tcount = count; | dcp->dc_count = tcount; | Unfortunately, the system still hangs on boot up. I tried it with and without 32-bit RAM enabled. Perhaps I need newer kernel sources. I am still using v713 until 720 (or later) becomes more stable. Did anyone else try and see different behaviour? Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 18:38:15 1993 From: Russel Miranda Subject: Re: Can't boot 720 To: NetBSD-Amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Mon, 13 Dec 1993, Markus Wild wrote: > > Count me in as another poor soul who cannot boot 720. > > > > I am using a version of loadbsd that is 6696 bytes in length. I have also > > Sounds healthy... ... Could you put a $VERS string in loadbsd, and/or maybe have it print out a version message when you use it? It might squash a little confusion if people didn't have to explain what size it is or what directory it was in when they ftped it. )Russ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:19:20 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Setting up UUCP on NETBSD can it be done? Sender: NetBSD-Admin@cbmuucp.commodore.com With the files that are currently distributed for NETBSD can you set up UUCP? Is there any online documentation for the commands? What directory (if these files exist) can I find these files? Can someone recomend any written material on setting up UUCP. Thanks in advance. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:21:29 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: GGC is that included in any of the tar files. Sender: NetBSD-Admin@cbmuucp.commodore.com Where can I find the GCC file, short of some little tar files like emacs and gdb and what have you! I have got all the major tar files except gnuusr.tar.gz which is like 10 megs. And under my first attempt to ftp it corupted... Will that contain the GCC files, or do I need to look for something else? -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:21:44 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Problems with Extracting Tar files currently out. Sender: NetBSD-Admin@cbmuucp.commodore.com I have ftp'ed most of the new files out there and have noticed that a few problems (concerns) occured when unpacking. In the various tar files I received warnings as follows: Cannot create link file or directory exist! File (tar, compress, gzip, mount-????, init) busy cannot extract! Could not create directory: it exists! Also, I received warnings about files existing! But feel that I would prefered that the older files would have just been overwritten. Something else, I was using my /opt directory for my transfer area and this wasn't formated. Could this have been creating any of my above problems with tar. Perhaps something was looking to put files on the /opt directory. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:36:02 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Re: Problems with Extracting Tar files currently out. Sender: NetBSD-Admin@cbmuucp.commodore.com When installing the new distribution you'll notice that files that were once soft links are now hard links or just copied to a different name. I believe tar could/can replace soft links with other softlinks, regular files with other regular files but does't know how to make a softlink into a regular file, which is good! I did rm * on each individual directory and started from a clean slate saving away gzip, tar, and sh. -Rob From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:40:49 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: netBSD-Amiga@cbmuucp.commodore.com, jvasher@cquest.mi.org Subject: Re: Problems with Extracting Tar files currently out. Sender: NetBSD-Admin@cbmuucp.commodore.com > File (tar, compress, gzip, mount-????, init) busy cannot extract! Does gnu tar have a 'install' option ala the 'install' command? This would work. -Rob From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 19:47:11 1993 From: jdresser@altair.Tymnet.COM (Jay Dresser) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A thought about custom chips display Sender: NetBSD-Admin@cbmuucp.commodore.com [...] > This is why we have screen blankers - to protect the phospher. Which protects the screen in a uniform way. [...] > The result is that the border will be BLACK. I still want my white > background with black text in the display area... X looks nice that > way. And the result of that is that you will have a burned out rectangle where the white was, and not [less] burned out where the black border was. Which would you rather have, uniformly burned out with no visible pattern on the screen, or a dark rectangle? A simple screen blanker would be better. On that note, a guy here at work wrote an interesting screen blanker after hearing of Sun research that shows that phospher is burned out by a _continuous_ image, and that a brief rest is actually adequate. His blanker moves a black band roughly a half inch high down the screen every 5 minutes. This gives the phospher the one second "rest" it needs to keep it from being burned out. Of course the advantage is that you can still see what's on the screen. J From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 20:00:55 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Problems with Extracting Tar files currently out. Sender: NetBSD-Admin@cbmuucp.commodore.com | | | | I have ftp'ed most of the new files out there and have noticed that a |few problems (concerns) occured when unpacking. In the various tar files I |received warnings as follows: | | Cannot create link file or directory exist! | File (tar, compress, gzip, mount-????, init) busy cannot extract! | Could not create directory: it exists! | | Also, I received warnings about files existing! But feel that I would |prefered that the older files would have just been overwritten. | | Something else, I was using my /opt directory for my transfer area and |this wasn't formated. Could this have been creating any of my above problems |with tar. Perhaps something was looking to put files on the /opt directory. No, I think this has to do with files that are executing at the time you do the install. So things like sh, mount, init, etc will have been executed and the file will be 'busy'. I don't know what the workaround is other than renaming the files you cannot install and then try re-installing them. Anyone else have an idea? Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 20:09:28 1993 From: Kevin M Mccarthy Subject: Re: Problems with Extracting Tar files currently out. To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 917 Sender: NetBSD-Admin@cbmuucp.commodore.com Rob Tulloh Spoketh: > > No, I think this has to do with files that are executing at the time > you do the install. So things like sh, mount, init, etc will have > been executed and the file will be 'busy'. I don't know what the workaround > is other than renaming the files you cannot install and then try re-installing > them. > > Anyone else have an idea? > > Rob Try doing this in single-user mode... That should help with some of it. (init etc...) -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 20:09:39 1993 From: Alan Bair Subject: Re: Problems with Extracting Tar files currently out. To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > No, I think this has to do with files that are executing at the time > you do the install. So things like sh, mount, init, etc will have > been executed and the file will be 'busy'. I don't know what the workaround > is other than renaming the files you cannot install and then try re-installing > them. > > Anyone else have an idea? I think for most of these, if you do the untaring while in single user mode, the programs will not be in use, so they can be over-written. For the root directory, you need to have a copy that you untar into, thus having those files free again. > > Rob > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From nd22+@andrew.cmu.edu Tue Dec 14 20:24:14 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA25647; Tue, 14 Dec 93 14:14:09 EST Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA10353; Tue, 14 Dec 93 14:13:49 EST Received: from andrew.cmu.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA25635; Tue, 14 Dec 93 14:13:45 EST Received: from localhost (postman@localhost) by andrew.cmu.edu (8.6.4/8.6.4) id OAA15390 for NetBSD@cbmuucp.commodore.com; Tue, 14 Dec 1993 14:13:40 -0500 Received: via switchmail; Tue, 14 Dec 1993 14:13:36 -0500 (EST) Received: from unix1.andrew.cmu.edu via qmail ID ; Tue, 14 Dec 1993 14:12:45 -0500 (EST) Received: from unix1.andrew.cmu.edu via qmail ID ; Tue, 14 Dec 1993 14:12:20 -0500 (EST) Received: from mms.4.60.Nov..4.1993.10.47.32.pmax.ul4.EzMail.2.0.CUILIB.3.45.SNAP.NOT.LINKED.unix1.andrew.cmu.edu.pmax.ul4 via MS.5.6.unix1.andrew.cmu.edu.pmax_ul4; Tue, 14 Dec 1993 14:12:19 -0500 (EST) Message-Id: Date: Tue, 14 Dec 1993 14:12:19 -0500 (EST) From: "Nathan J. Dohm" To: NetBSD@cbmuucp.commodore.com Subject: 720 boot problems Cc: Status: RO At the risk of pointing out the obvious... If you're trying to boot vmunix720 and you've binpatched ite_default_height so you can see, make sure you binpatch it on both sides (AmigaDOS and NetBSD). Changing only one of them (either one) causes you to get a completely blank screen and nothing else, as has been described. Regarding another question, I run a 4 MB A3000 system and have no problems at all. -- Nathan From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 21:33:13 1993 From: Bill Squier To: netbsd-amiga@cbmuucp.commodore.com, rtulloh@oneway.austin.ibm.com Subject: Re: GVP dma patch (tried it) Cc: mw@eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com >From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) > >Howdy! > >I tried this last night... > >|Could anyone with a GVP controller and the system ready to compile a >|kernel try the following patch: >| >|*** gvp11dma.c Sun Nov 21 22:37:26 1993 > [...snip...] > >Unfortunately, the system still hangs on boot up. I tried it with and >without 32-bit RAM enabled. Perhaps I need newer kernel sources. I am >still using v713 until 720 (or later) becomes more stable. Did anyone >else try and see different behaviour? > >Rob I patched 709's gvp11dma.c, and it boots fine, runs a little slower, but still produces some silo overflows. I get them rarely anyway, and I didn't have time to fully test it last night (hence, no report to this list). In the next few days I can scrape together some time to do a full investigation. -wps From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 21:45:10 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: GVP dma patch (tried it) Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 14, 3:19pm, Bill Squier wrote: > >From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) > > > >Howdy! > > > >I tried this last night... > > > >|Could anyone with a GVP controller and the system ready to compile a > >|kernel try the following patch: > >| > >|*** gvp11dma.c Sun Nov 21 22:37:26 1993 > > [...snip...] > > > > >Unfortunately, the system still hangs on boot up. I tried it with and > >without 32-bit RAM enabled. Perhaps I need newer kernel sources. I am > >still using v713 until 720 (or later) becomes more stable. Did anyone > >else try and see different behaviour? > > > >Rob > > I patched 709's gvp11dma.c, and it boots fine, runs a little slower, > but still produces some silo overflows. I get them rarely anyway, > and I didn't have time to fully test it last night (hence, no > report to this list). > > In the next few days I can scrape together some time to do a full > investigation. I do not see what difference the changes would make. If I remember correctly, that section of the code is just breaking up the I/O request into a series of contiguous physical pages. Changing the value being checked from NBPG to 512 just makes the code do more work with the same result. For example, assume that the I/O request consists of 2 pages (16k bytes). If the two pages happen to be contiguous, the result will be one I/O starting with the first physical page and a length of 16K. It won't matter if you check every 512 bytes or every 8192 bytes. If that same I/O uses two non-contiguous physical pages, the result will be two entries: one for each physical page with a length of 8192. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:01:32 1993 From: jdresser@altair.Tymnet.COM (Jay Dresser) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A thought about custom chips display Sender: NetBSD-Admin@cbmuucp.commodore.com > Wrong. As it is now, you have a white border and white rectangle > with X in it. When you run an X screen blanker, the rectangle goes > black/blanked and the border stays white. Apparently X screen blankers simply blank the pixels and not the color registers. The latter would be more correct for Amiga, but admittedly machine dependent. > I still prefer xlock. That way, if my cats walk across my keyboard > while I'm sleeping, they don't type stuff into my editor or whatever. C'mon, give your cats more credit. They might code something interesting. :) From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:45:20 1993 From: Markus Wild Subject: Re: Setting up UUCP on NETBSD can it be done? To: jvasher@cquest.mi.org (Joe Vasher) Cc: netBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 600 Sender: NetBSD-Admin@cbmuucp.commodore.com > With the files that are currently distributed for NETBSD can you set > up UUCP? Is there any online documentation for the commands? What directory > (if these files exist) can I find these files? Can someone recomend any > written material on setting up UUCP. Thanks in advance. I don't think I included the uucp stuff in the recent binaries, mainly because I didn't test them. Try getting the 1.04 taylor package up... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:46:17 1993 From: Markus Wild Subject: Re: AS To: nix@stekt.oulu.fi (Tero Manninen) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 699 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Create? You'll have to code pcrelative.. > > ??? I'd like to do things in C, not in assembly! > The question should have been whether gcc produces such > assembly that gas can compile in to pc relative binary, or not. Hm, gcc can't currently output pcrelative code (just PIC, but that's not what you want). As far as I remember, gcc-1.40 distributed as the Amiga Unix compiler supported some sort of pcrel code generation, I however don't remember how well it did this. I don't think that code made it into any gcc2 release. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:46:19 1993 From: Markus Wild Subject: Re: Problems with Extracting Tar files currently out. To: jvasher@cquest.mi.org (Joe Vasher) Cc: netBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 895 Sender: NetBSD-Admin@cbmuucp.commodore.com > Cannot create link file or directory exist! If you're overwriting existing stuff, these warnings can happen.. > File (tar, compress, gzip, mount-????, init) busy cannot extract! Happens if you're trying to overwrite a currently running executable. This means that this executable wasn't updated in your filesystem, so take care! > Could not create directory: it exists! Harmless. > Something else, I was using my /opt directory for my transfer area and > this wasn't formated. Could this have been creating any of my above problems > with tar. Perhaps something was looking to put files on the /opt directory. Directory or partition? I don't see how you'd want to format a directory... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:46:45 1993 From: Markus Wild Subject: Re: A thought about custom chips display To: mykes@shell.portal.com Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1100 Sender: NetBSD-Admin@cbmuucp.commodore.com > some wisdom to the graphics chips display code. For example, chopps > has done a NIFTY job of reworking the display/console code already. I'll second THAT ! > So what I suggest is that the display code be modified so that it > either: > > 1. renders reverse video and swaps colors 0/1 > or > 2. renders text into bitplane 1 instead of 0 and cursor into > the other plane. > > The result is that the border will be BLACK. I still want my white > background with black text in the display area... X looks nice that > way. How about 3. do the "BorderBlank" trick if ECS is enabled? That way you can have your text/background colors in the way you really like them, and still have a dark border. I'd never use a Workbench screen (well, now in Retina times things look different, but I remember the past:-)) without blanked borders, and if it's just a neat trick to get rid of the one flickering line in NTSC mode on the top:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:46:46 1993 From: Markus Wild Subject: Re: GGC is that included in any of the tar files. To: jvasher@cquest.mi.org (Joe Vasher) Cc: netBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 599 Sender: NetBSD-Admin@cbmuucp.commodore.com > Where can I find the GCC file, short of some little tar files like > emacs and gdb and what have you! I have got all the major tar files except > gnuusr.tar.gz which is like 10 megs. And under my first attempt to ftp it > corupted... Will that contain the GCC files, or do I need to look for > something else? Well, gdb, emacs, gcc, guess what, they're gnu programs.. so they're in the gnu archive, sorry bout that... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:47:08 1993 From: Markus Wild Subject: Re: Anyone have a working 4M configuration To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, tsarna@endicor.com, NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 778 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have had problems in pmap_enter_ptpage when running out of kernel > memory. If I remember correct the ste was NULL. I used to get this > when using my AmigaDOS FS in memory-hogging ways (recursive scans of > large directories with large files). I guess out of memory conditions > aren't correctly handled... Hm.. perhaps this depends on the actual amount of available physical memory, whether memory shortage is handled gracefully or not? As I said, I've started 50 emacses consuming around 25M of swap-space, and didn't have a single problem with this. Don't tell me my 12m could handle this amount ... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 22:47:56 1993 From: Markus Wild Subject: Re: GVP dma patch (tried it) To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com, mw@eunet.ch X-Mailer: ELM [version 2.4 PL23alpha2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 471 Sender: NetBSD-Admin@cbmuucp.commodore.com > Unfortunately, the system still hangs on boot up. I tried it with and > without 32-bit RAM enabled. Perhaps I need newer kernel sources. I am > still using v713 until 720 (or later) becomes more stable. Did anyone > else try and see different behaviour? Sigh.. would have been too good, wouldn't it... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 23:18:26 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: GVP dma patch (tried it) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 420 Sender: NetBSD-Admin@cbmuucp.commodore.com > I do not see what difference the changes would make. If I remember > correctly, that section of the code is just breaking up the I/O request Hm, you realize though that the intention was different?:-)) Argl, was a quick hack, probably too quick... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 23:22:07 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 14, 9:56pm, Markus Wild wrote: > > I have had problems in pmap_enter_ptpage when running out of kernel > > memory. If I remember correct the ste was NULL. I used to get this > > when using my AmigaDOS FS in memory-hogging ways (recursive scans of > > large directories with large files). I guess out of memory conditions > > aren't correctly handled... > > Hm.. perhaps this depends on the actual amount of available physical > memory, whether memory shortage is handled gracefully or not? As I said, > I've started 50 emacses consuming around 25M of swap-space, and didn't > have a single problem with this. Don't tell me my 12m could handle this > amount ... I have been using a modified version of loadbsd that lets me "fine tune" the amount of memory (i.e. I can specify the memory size like 4096K, 4104K, etc). I found that with my current version of the 713 kernel, if I increased the memory to 4115K, the kernel would run. It does lots of paging, but it does run. I even ran X11R5 and an xterm process. However, with 1 page less of memory, processes get hung up. Looking at where they were hanging, I found the process in a "thread sleep" state and further figured out that the process was waiting for a "vm_page_free_count" event. More work led me to the vm_fault routine, where a vm_fault attempts to allocate a page to satisfy the page fault, but is unable to allocate a free page. The process then goes to sleep until a page is available and then tries to get the page again. There seems to be a critical point at which it never is able to get a free page. One thing that bothers me about this is that when the process is put to sleep, the vm_page_free_count was usually sitting at 10. In looking at the vm code, that count should be the number of pages in the free page queue and a page allocate should be satisified. As far as I can tell, vm_page_free_count should track the number of pages in the free page queue, so I'm going to try putting a check in the page allocate routine to verify that. Along the same line, I looked at the code in pmap_enter_ptpage and the previous information about the MMU fault. The PC appears to come from the store of the new page table entry into the segment table, and the fault address information is in the area of the user page tables. The error return from vm_fault indicates that the address was invalid. It looks like the address should be valid though, since it is in the user page table space. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 23:30:44 1993 To: Markus Wild Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Problems with Extracting Tar files currently out. X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> mtk == Markus Wild wrote: > Cannot create link file or directory exist! mtk> If you're overwriting existing stuff, these warnings can mtk> happen.. > File (tar, compress, gzip, mount-????, init) busy cannot extract! mtk> Happens if you're trying to overwrite a currently mtk> running executable. This means that this executable mtk> wasn't updated in your filesystem, so take care! > Could not create directory: it exists! mtk> Harmless. > Something else, I was using my /opt directory for my transfer area and > this wasn't formated. Could this have been creating any of my above problems > with tar. Perhaps something was looking to put files on the /opt directory. mtk> Directory or partition? I don't see how you'd want to mtk> format a directory... As an aside... I had none of these problems. What I had done was to build tar and gzip again and had them installed in /usr/local/bin. For some reason, I could never get the older tar+gzip to do xzvfp - I always got "stdin not in compressed format" error message... I noticed the same problem with pjotr's system when I telnetted there and built some stuff for him. Because I had tar+gzip in /usr/local/bin, and /usr/local/bin is on my path, I was able to do: rm /bin/* and then tar xzvfp /tmp/usr-bin.tgz (and the same for each of the bin-*.tgz files. For what it's worth, I'm paranoid. I do not trust to simply untar the new bin-*.tgz over the existing filesystem (already installed /bin for example). If you had an old /bin/foo and the new archive does not have a new /bin/foo, then you have the new bin-bin.tgz installed plus the old /bin/foo. My paranoia is that I neither want the old /bin/foo nor do I wish to risk the old /bin/foo being incompatible with new bins that it works with. When I imagine running a mixture of old tcp/nfs daemons with new tcp/nfs daemons, I can only see problems. Now, I must point out that before you rm /usr/lib/*, you should consider that if you had installed X11 or built your own libraries to install there, then you would be erasing these too. I had links to the X11 libs in /usr/lib that I wanted to preserve. So I did: cd /usr/lib and then rm individual files by hand to keep what I wanted. I should also point out that mtk's bin-*.tgz have links made in them that did not work on my system. His X11 links point to some odd place that my X11 isn't at :-) A good thing about tar is that it will not overwrite your links. If you keep your /usr/lib/X11 link in place, when you untar the usr-usrlib.tgz file, it won't destroy the perfectly good link you already made. Another thing I remember is that the new bin-bin.tgz file did not have a /bin/sh in it! TO fix that, I simply made a link to bash for it: ln -s /bin/bash /bin/sh. Lastly, I had problems building a kernel from the bsdsyssrc720.tgz, but the src0712.tgz file had all the files needed, in the right places, to build kernels. A word of advice: use the AMIGA config file as a starting point. The GODZILLA one will not build a working kernel. (makes me wonder how mtk does it :-) Apply chopps' patches if you want X to work. mtk> -Markus mtk> -- mtk> CHUUG/EUnet Switzerland Markus Wild mtk> Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch mtk> CH-8004 Zuerich Fax: +41 1 291 46 42 mtk> S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Dec 14 23:35:12 1993 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A thought about custom chips display X-Billboard: watch this space :-) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Mumail [version 2.3b i486-Linux] From: mykes@shell.portal.com Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> mtk == mw@eunet.ch (Markus Wild) wrote: > mtk> How about 3. do the "BorderBlank" trick if ECS is > mtk> enabled? That way you can have your text/background > mtk> colors in the way you really like them, and still have a > mtk> dark border. I'd never use a Workbench screen (well, now > mtk> in Retina times things look different, but I remember > mtk> the past:-)) without blanked borders, and if it's just a > mtk> neat trick to get rid of the one flickering line in NTSC > mtk> mode on the top:-) > > Perhaps you misunderstand... > > If I have a 640x400 console, then there are borders around the edge of > the console. These borders are what would normally be displayed as > overscan pixels. These borders are displayed in color register 0 mtk> No, now you did misunderstand.. I wasn't talking about mtk> Retina at all here. Since you're not picking up the mtk> topic, I get the impression you don't even know about mtk> those new ecs registers.. there is now a way to set the mtk> the border, to not just extend ala overscan, but really mtk> cut the display off at the edge of the displayed area mtk> (repeat, instead of doing overscan with the border being mtk> the background color, make the border just shut off the mtk> display). This was primarily thought for use together mtk> with new features for genlocking, but it is REAL handy mtk> even without genlocks. It's one or two bits in one of mtk> the new ECS registers. If you want to give it a try from mtk> ADos, try BBlank.lha, I think that's its name. mtk> -Markus mtk> -- mtk> CHUUG/EUnet Switzerland Markus Wild mtk> Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch mtk> CH-8004 Zuerich Fax: +41 1 291 46 42 mtk> S=mw;P=EUnet;A=EUnet;C=CH OK, my mistake... However, is there an accurate way in netbsd to determine if you have ECS chipset? My understanding is that A500 with accelerator confuses netbsd into thinking it is an A3000. To do custom ECS tricks on non ECS chipset does not provide the desired effect. Again, my solution works for ECS and non-ECS and costs nothing but a few minutes of coding time... Cheerios From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 00:19:31 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Happy XMas Sender: NetBSD-Admin@cbmuucp.commodore.com No, don't worry, this is not a vt100 trailer :-) Just download xmas.tar.gz from eunet (incoming), and have fun. Merry XMas and happy new year to you all ! -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 00:57:07 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A thought about custom chips display Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <199312142054.VAA00191@godzilla.eunet.ch> Markus Wild writes: > How about > 3. do the "BorderBlank" trick if ECS is enabled? That way you can have > your text/background colors in the way you really like them, and still > have a dark border. I'd never use a Workbench screen (well, now in > Retina times things look different, but I remember the past:-)) without > blanked borders, and if it's just a neat trick to get rid of the one > flickering line in NTSC mode on the top:-) I think that's the best solution, but I don't know if OCS Denise users are going to be satisfied. I swapped machines with my coworker last week, but kept the 2320 and my monitor and he kept his FlickerFixer and monitor. Unfortunately, I forgot to also keep the ECS Denise from the computer I had, and I now have those nasty flickering lines and jagged borders on my AmigaDOS machine :-(. I think I'll may have to find an excuse to open both machines up again soon... [hi rklint! :-)] Oh well, at least the NetBSD machine has ECS... now if only it had enough memory to run properly :-(. At any rate, adding BorderBlank looks very easy. I don't think you even need to check for ECS, it'll just be a no-op on OCS. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 01:23:06 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: A thought about custom chips display Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article mykes@shell.portal.com writes: > > mtk> even without genlocks. It's one or two bits in one of > mtk> the new ECS registers. If you want to give it a try from > mtk> ADos, try BBlank.lha, I think that's its name. I believe all that's neccesary to get BorderBlank is to just set bit 5 in BPLCON3. There's also a BorderTransparent bit (4), but I think that has to do with wether the border is transparent to a genlock or not. > OK, my mistake... However, is there an accurate way in netbsd to > determine if you have ECS chipset? My understanding is that A500 > with accelerator confuses netbsd into thinking it is an A3000. To > do custom ECS tricks on non ECS chipset does not provide the desired The chips themselves can tell you what version they are: Agnus: bits 8 to 14 of VPOSR provide a chip version. A value of 20 or 30 indicates ECS Agnus. (there are actually 4 pre-AGA versions acording to the hardware RKM... OCS, OCS+EHB, and I guess two versions of ECS?) Denise: The register DENISEID will have 0xFC in the lower 8 bits for ECS. This register is new for ECS and if read on OCS will be whatever was last on the bus (so you need to atomicly get some other value on the bus, then check and see if reading DENISEID gets you 0x??FC or the value written before). [under AmigOS, you should just look in GfxBase->ChipRevBits0] However, BPLCON3 is new for ECS anyway, so it should be safe to just write to it, and on OCS nothing will happen (right?). -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 01:23:17 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Anyone have a working 4M configuration Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <199312132112.WAA08030@eunet.ch> mw@eunet.ch (Markus Wild) writes: > > vm_fault(d6000, 16c8000, 3, 0) -> 1 > > type 8, code [mmu,,ssw]]: 401070d > > trap type 8, code = 401070d, v = 16c8008 > > pid = 38, pc = 0005A044, ps = 2300, sfc = 0001, dfc = 0001 > > Hm, this dies in pmap_enter_ptpage, which surely was affected by the > recent addition of the '40 code. I don't say this IS because of the > '40 code, but it could be ... Mike? Sorry, this is too easy.. but.. If it helps any, I tried it with 714 and got exactly the same behavior: vm_fault(c2000, 169e000, 3, 0) -> 1 type 8, code [mmu,,ssw]]: 401070d trap type 8, code = 401070d, v = 169e000 pid = 3, pc = 000595E6, ps = 2300, sfc = 0001, dfc = 0001 [register and stack dumps here] panic: MMU fault. One thing that did help was decreasing the sze of my swap partiton to 8M. That at least allows me to go multi-user or mount mfs, though I still can't compile the kernel. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 03:53:22 1993 From: tjhayko@io.org Subject: New Binaries in incoming? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 514 Sender: NetBSD-Admin@cbmuucp.commodore.com I've finally got around to looking at my mail and poking around on a couple of NetBSD ftp sites. Does the kernel new kernel uploaded by mykes include shared lib support? What is different about the new binaries in the incoming directory? I don't have quite enough space for the old ones, but if the new rootfs (which I can't find anywhere, where is it?) and the new binaries really only take 130000 blocks (I'm talking base stuff plus GNU stuff here), I just might have enough room. Tom Hayko tjhayko@io.org From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 07:14:08 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: new rootfs suggestion & a useful tip for single-user mode Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com Whoever builds a new rootfs should remember to update /etc from NetBSD-current on sun-lamp. They should also include a minimal termcap in /usr/share/termcap/termcap.sys in the rootfs, which brings me to the handy tip: if /usr is mounted, umount it mkdir -p /usr/share/termcap copy the file below to /usr/share/termcap/termcap.src remount /usr if desired This gives you a minimal termcap so that you can still use a visual editor when running single user. When you mount /usr, the full termcap will hide the minimal one. Personally, I find it really annoying to be in single user mode, wanting to edit some configuration item or another, and to have to go mounting stuff in order to be able to edit anything. Here's a minimal termcap that's sufficient for the NetBSD console (which is vt220-like). Note that "dumb" and "unknown" are included as synonyms for vt220. You wouldn't want aliases like this normally, but running single-usr assumes you're doing something unusual anyway, and it's handy when TERM hans't been set to vt220 yet. ---snip snip--- vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ :do=^J:co#80:li#24:cl=50\E[;H\E[2J:sf=2*\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:is=\E[1;24r\E[24;1H:\ :if=/usr/share/tabset/vt100:\ :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=^H:\ :ho=\E[H:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:pt:sr=2*\EM:vt#3:xn:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr: vt200|vt220|dec-vt220|vt200-js|vt220-js|dec vt200 series with jump scroll:\ :im=\E[4h:ei=\E[4l:mi:dc=\E[P:dm=:ed=:al=\E[L:\ :cs=\E[%i%d;%dr:sf=\ED:sr=\EM:sb=\EM:\ :ce=\E[K:cl=\E[H\E[J:cd=\E[J:cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:\ :so=\E[7m:se=\E[27m:us=\E[4m:ue=\E[24m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:\ :is=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h\E[1;24r\E[24;1H:\ :rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:\ :tc=vt100: dumb|unknown:\ :tc=vt220: ---snip snip--- -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 07:14:14 1993 From: Roy Trevino To: chopps@emunix.emich.edu Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Xami Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Chris, > Ack I just killed some mail (actually archived it but its pretty hard > to get at now) So I don't have the Xami's authors name sorry. I hope you actually mean me and not the Xbsd author. But applies either way. Sorry for the late reply - I had to implement all this stuff first. > What I wanted to say is about using the view stuff. The problem is > currently we have no way to to allow multiple things like console and > X I guess we need to chnage some stuff (will be working on these now) > in ite and other places to support swapping the input focus around and > such. This will allow multiple consoles etc. Currently however I was > under the impression (as markus informed me) that X somehow co-exists > with /dev/console so that both cannot be run at the same time (displayed) > I just finished updating the kernel to enable views, and implemented my Xami entirely with views on vmunix.720. Very straightforward, as expected. Only console problem is that I cannot use /dev/view00 to get default height and width for X screen, since it's "busy". Both coexist otherwise. In fact, I would definitely not want to close the console, or it may pre-empt xconsole from working properly. View is a particular boon for making xconsole work for Xserver debugging, since you no longer have to do xinit >& /tmp/x.log. Just xinit and xconsole! > ... > If you wanted to open up other screens however you can use the view > devices, actually you do all your graphics into views, how? tell > grf[0] to turn off (not needed but at least it avoids the consoel > popinng up sometime when the user won't be able to type into it.) Currently I don't turn off console for reasons listed above. Also, what about if you *want* to be able to pop up the console (with some special keys, ala Amiga-N/Amiga-M). Need some way to refocus keyboard/ mouse on the console. > > Then open /dev/view00 .. /dev/viewXX for each screeen you want (view00 > currently will return EBUSY but thats ok you should be handling this :^) I swiped all your functions from views.c for this. And bits of main() as well :-). > ... > tell /dev/console to turn off. This should cause /dev/console to lose > the input focus. > > open /dev/ms and /dev/kbd to get input from user. Opening kbd/mouse automatically steals kbd/mouse from console. > > open /dev/viewXX where XX is 00 then 01 until you get either a valid > fd or your error is not EBUSY (signifying someone else is using it) > > use ioctl to get bitmap VIEW_GETBITMAP > ... Worked great. Server would have worked first time except I forgot to swap the sense of the mouse buttons :-) (was backwards i vmunix.709) Things get really strange if one sends button events in the wrong order :-). > > Chris. > > Now to just figure out: a) how to allocate space for cursor font for hardware cursor routines via ioctls. One hack: use a view! b) how to then do ioctls to enable/change the cursor sprite c) how to use in general the blitter at the ioctl level. (any ideas?) This may be the only way to make color ecs acceptably fast. Thanks, Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 10:20:43 1993 From: Arthur Hoffmann Subject: X still MMU-faulting To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 312 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi I can't get X11R5 to work on my A3000 NetBSD machine. It always MMU faults. I'm running kernel 720 and applied the recent patches to enable X, but still it mmufaults. Even the kernel that mykes uploded mmufauls, and that was supposed to work. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 13:15:51 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: No Room to install GNUUSR on the usr partition What to do? Sender: NetBSD-Admin@cbmuucp.commodore.com As I was wonder about the bin-usrgnu.tar.gz file when expanded would take up 26 mgegs. It seems I only had 20 or so megs left on my usr partition. Now I set my system up as it was in the faq (very close): /usr sd5d 50megs /proj sd5e 14megs /opt sd5f 50megs /home sd5g 50megs /home2 sd5h 18megs /root sd6a 8megs /swap sd6b 16megs usrgnu will not unpack onto the usr directory but couldn't I go into to the /opt directory and unpack it and that would leave a usr/ directory in there and then somehow tell the system it's there.. Is that what a softlink is used for. If so could someone tell me the best way to go about this... Thanks. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 16:58:28 1993 From: Alan Bair Subject: Re: new rootfs suggestion & a useful tip for single-user mode To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Ty, Thanks for the inputs. > > Whoever builds a new rootfs should remember to update /etc from > NetBSD-current on sun-lamp. They should also include a minimal termcap ^^^^^^^^ I asked Markus W. about this the other day and he indicated that he is using non-binaries straight off sun-lamp. So I need to check on updating that stuff. > in /usr/share/termcap/termcap.sys in the rootfs, which brings me to the > handy tip: > > if /usr is mounted, umount it > mkdir -p /usr/share/termcap > copy the file below to /usr/share/termcap/termcap.src > remount /usr if desired > > This gives you a minimal termcap so that you can still use a visual > editor when running single user. When you mount /usr, the full termcap > will hide the minimal one. Personally, I find it really annoying to be > in single user mode, wanting to edit some configuration item or another, > and to have to go mounting stuff in order to be able to edit anything. Thanks for the tip. Others have been asking for a starter termcap, so I'll look at using your idea. > > -- > Ty Sarna "Oh, I don't know *everything*. I don't > tsarna@endicor.com even know how fish work." -- Joel, MST3K > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 17:22:54 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Xami To: rtrevino@sedona.intel.com (Roy Trevino) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Hi Chris, > > > Ack I just killed some mail (actually archived it but its pretty hard > > to get at now) So I don't have the Xami's authors name sorry. > > I hope you actually mean me and not the Xbsd author. But applies either way. > Sorry for the late reply - I had to implement all this stuff first. Sure did :^) > I just finished updating the kernel to enable views, and implemented my > Xami entirely with views on vmunix.720. Very straightforward, as > expected. Only console problem is that I cannot use /dev/view00 to > get default height and width for X screen, since it's "busy". Both > coexist otherwise. In fact, I would definitely not want to close the > console, or it may pre-empt xconsole from working properly. View is a > particular boon for making xconsole work for Xserver debugging, since > you no longer have to do xinit >& /tmp/x.log. Just xinit and > xconsole! Right, I don't knonw anything about X I assumed that the console should be closed, guess not. :^) > > Currently I don't turn off console for reasons listed above. Also, > what about if you *want* to be able to pop up the console (with some > special keys, ala Amiga-N/Amiga-M). Need some way to refocus > keyboard/ mouse on the console. Maybe these keys could be caught by X and it could close kbd? dunno it will need to know when to reopen them too I guess. I was connsidering writing a CX like daemon when I started messing with ite.c, not there yet. > Now to just figure out: > a) how to allocate space for cursor font for hardware cursor routines > via ioctls. One hack: use a view! > b) how to then do ioctls to enable/change the cursor sprite > c) how to use in general the blitter at the ioctl level. > > (any ideas?) > This may be the only way to make color ecs acceptably fast. Well: I had though about supplying a mouse daemon but that is not in my immediate plans and would require changes to /dev/view and would not be a part of the kernel. There are no sprites :^( Sprites didn't figure quickly into the RTG system I had dreamt up. I still have problems with RTG, let alone trying to get a sprite into the system. :^) Use of the CPU is much faster than the blitter on all machines that NetBSD currently (and probably hereforth) runs on. > > Thanks, > Roy I know I didn't help much from above. You'll need to do a mouse cursor as either a complement function, or save/restore the part of the screen that you render the cursor into. Chris. From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 17:24:45 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: sed, regcomp, and manpages To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1070 Sender: NetBSD-Admin@cbmuucp.commodore.com Has anyone noticed some unusual behavior with sed and regcomp, and displaying manpages? I noticed that sed is not working properly under 720. It doesn't pass any of the tests, and segs whenever I try to do anything non-trivial with it. I also tried grabbing the old statically linked sed and a sed from a sun3. Neither of those seem to be working correctly either. I traced one source of segmentation violation to recomp(), but I can't try to build or test it because to do so you need a functioning sed. recomp() in the gnu regex library does not seem to be working quite the way it should either. Any suggestions? I have also discovered that whenever I try to display something with fancy formatting, say a manpage, the kernel vectors off into infinity. Seems that something's wrong with the ite stuff. Has anyone else discovered any of these problems? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 17:33:19 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: jvasher@cquest.mi.org, netBSD-Amiga@cbmuucp.commodore.com Subject: Re: No Room to install GNUUSR on the usr partition What to do? Sender: NetBSD-Admin@cbmuucp.commodore.com | As I was wonder about the bin-usrgnu.tar.gz file when expanded would |take up 26 mgegs. It seems I only had 20 or so megs left on my usr partition. |Now I set my system up as it was in the faq (very close): | | /usr sd5d 50megs | /proj sd5e 14megs | /opt sd5f 50megs | /home sd5g 50megs | /home2 sd5h 18megs | /root sd6a 8megs | /swap sd6b 16megs | | usrgnu will not unpack onto the usr directory but couldn't I go into |to the /opt directory and unpack it and that would leave a usr/ directory in |there and then somehow tell the system it's there.. Is that what a softlink is |used for. If so could someone tell me the best way to go about this... This was my problem exactly. I had set up my system according to the FAQ and I found that I would be short about 10+MB for all of /usr. I used soft links to work around the problem. Now, chunks of /usr/gnu are soft linked to /home/GNU. All of /usr/local is linked to /home/LOCAL. You can do the links any way you want. I just put parts of /usr on /home. I think the FAQ should be updated to provide more accurate estimates for partitioning so that users don't end up short in the end. Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 17:56:49 1993 From: Alan Bair Subject: Re: No Room to install GNUUSR on the usr partition What to do? To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: jvasher@cquest.mi.org, netBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > | As I was wonder about the bin-usrgnu.tar.gz file when expanded would > |take up 26 mgegs. It seems I only had 20 or so megs left on my usr partition. > |Now I set my system up as it was in the faq (very close): > | > | /usr sd5d 50megs > | /proj sd5e 14megs > | /opt sd5f 50megs > | /home sd5g 50megs > | /home2 sd5h 18megs > | /root sd6a 8megs > | /swap sd6b 16megs > | > ... deleted stuff ... > do the links any way you want. I just put parts of /usr on /home. I think > the FAQ should be updated to provide more accurate estimates for > partitioning so that users don't end up short in the end. > > Rob As an ex-sysadmin in real life, I would recommend doing away with the large number of partitions. Something more like the following would make better use of the potentially small amount of disk space available for NetBSD. /usr sd5d 82megs /opt sd5f 50megs /home sd5g 50megs /root sd6a 8megs /swap sd6b 16megs I don't see any real purpose for the original /proj and /home2. You may even want to merge /opt and /home. When I put NetBSD on my 88M SyQuest, I just have /root, /swap and /usr. Some people my be concerned about trashing partitions and thus want to keep things separate. However, the main thing to watch for is to keep the development areas separate from the system, like /root and /usr. Then if your program goes wild and trashes the directory structure, you only lost the development area and not the OS. Then you just restore from the backups you have been making. > > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > + Rob Tulloh WPX Development rtulloh@austin.ibm.com + > + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + > +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 18:09:21 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: new patches. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com I light of Roy getting his Xami runing under 720+ I need to get some patches to people right away that enable the view device. What these patches fix: slighlty odd handling of mode guessing for overscan NTSC would switch to PAL when people probably didn't want it to---fixed. now enables Border blank on systems that support it (ECS). enables view device and changes standard config files to create 10 views by default. NOTE: when recompiling don't forget to run config.amiga again. I created these patches from the default 720 sources patched from my earlier diffs. So if you want to use these you need to have patched your source with my previous diffs. Here they are. begin 600 chopps-pl2.diff.gz M'XL( $;Y#BT ^T;:W.;2/*S_"MZD\J5Y" 9$.B!=EWE.%XG58E]96\>>[M; M%(*1X8* B3;F\=OWYX90$@"](R3NXK*4:"GNV>FWXT&RQF-H'DJP].0F),P M'\ARU&;HN"W&X# M U#.#*#(@-?- X":1::ZXSEQW10\(2(N,>.& '/0L1$@2(3/B'_P%!X[GNE. M+ */I@ZY;=F/$&92 HN8;IW"&@,$'1V"'Q!/ -/U(R* XYNQ*P"?0@!DBFN M]^_?0V3[$]>"(0&#@9&78Q(X/**3663D>*3&)J"\LV4UX"/\B1CS.Z!3+JZ? M+0"!=0J-[P.BA\2PZO7#1J,!WL1U_4#@K&88MZ$3DP64.:9L.XTENBCV@X2, M>#Z"YZ>-2+S 5!0*=K%*#T\!53'30V"$5 V04P."4 M%%M&6ND(;C8X!T 8 MS8>AQ>>1!,#KAE"KH?XD18,C'#Y"$%5'BCWV)Q'A^!>O+]]NX].%YA]-" AX\O*[%"TB)C MPXP.K(UB)&5_=/+ZY?G)(N?9R(KX.$.LO?8]%N2@ [*H88#$D%46'7-DN=@H M21J*1>V6QT9)E05)S<5&#E!3^PDB,K'\)@]'-1+;)*1N-P^>>C5)1(=<@*). M.3P3=_6V-6 ;4,0R]7"D9V^NGIV^.GE[MB;:EVV4>'YV<7;U\K15KLPYC'64 M.D? 4M]KXQZ@3_U0%+5V>>HK()]7,IH'>E*IDE5%0(UF*J:WG6(%N[X?+.N7 MJ[U,OUM(]S]G;ZX+-TD'UI$EQ5OP#U'1,,=7BI!1+;A'7Y-[%>ZA] 1)Z>?< M@P)4<8_NL:7X+B]>_5ZZ23JXKA@I[G:B9)1+XDR#U/^..$>.2Z(6 Q3N-3>^ MCE!SZ 5R5:KEFB=>$&TW(RX2;:;*AJ^3E:YK) M?[HAB[*"%:-%EKO"U10KW&DU@\4\B#52M]3!-F-'G1795;B MEX1(4L_=ZJ.)9\)A V8+UG/# S8WCZE\66D'L-:R/F&9KY]>7K2_[OI6%X+S M2M*@0$LM/W1N*BQ]%?VF!6&QW=RX_M!PU[7Z%'LKBT^)\^F$9MJNII07C2M8 MS5NZHFIJI]S2%550>K.L36_[J7T]=D; 'U!84#^_^E4_.[UN()Q^/L*5_NSL MY#4:%O;XXIV('_@L8/+.1O_]BEH='Y3I8"TQ0.(90Y? T \MM+6A:W@?N#D^ M)A[J+YD!$8?89@8X3"#P'2\F(3/;HFWT1:&?:W7ZDM!7OYMMF+[K\Z5O9MFI M1O=CU?9&L=S>)8[;^XOA1:S0JN6^IE:T19(H"9*H9O%[:/K!/=2CV-+Q*L"0 MYCI1+$ N_(U"8TRB/W[57UU>G/\EP *N'CE_D\9@TS0@<.7C]SCP(RGUP]U^FC%OW]H!3Y?@GY]P%/&8DDTI3Q MD)(HSCS?5"1;9RE[APQE[S4[V9:[F2=G^-OYX,V]3;VYD!GWYW;%75;XDQ+Y&L;=+*FI9L/91W)W(I\.Z'EUS,KWW]39R_W]^_DT#-_WGH!V\^^SU 2;-8#!#LU 4%Y%Z!*&X:24EY= M3:YH;KNRT.UE@83:6?/8\\>.9[C,#UHV<6[L&$U-5CL#6##&L7''L6X=*[81 MJ2LK@P6GR7!FG'KM1:O&"><9M65QB5&*DS&2Y%X1(XL$C(>T-(A+20<5'C_X M_M/H\5#[[^]G_[(B[[+_XM0B8C.D?-.V,$#9?_M(RK,+E\9WT1I^'V+9.KX' MN_2'P7X;Q#C'8L44,JGI$M?QDPT;<:.'8T>2JASY2!YLA\4>3N-0D*T!/7JN]4:;F8 MV*J\43N=/94W:B&CC8WSH3%OVFC&5X6X7VQGI/N+Z$B.LXE1%$RMBNM3M"U)/SATD8X#9K[G\ MIUPX/7EUJC]_^>[%R_,7=1O-:XK_;#2G*6G G\F/K_13KT_T6S^T&O6Z3?XE MWF';T_CY9[7QJ3ZEMUV\_81#43)T?-RF]],H&3L^[C4:LZ/ZD!HW_[%8HB/$ MC4@A1OZWX!ULD$EQ*_MCE&L^MDJI5IOZ#',;LT;79[1%>TC'UC#;%+7 3*M/ M3A014K/$4J/B49+4QF8Y_Z8) RC93R_TXP3-8PQR$3T^8YI.\Y@>)&L>6TX4 MN,8]SX]-J8$QD:&.8@89T!#9E&"$P7'HNU82"I,C"#@6&2A3C]S"U' G)(+( MQ[AMQ#":Q).0L-=0(IA$!*%DS-\K22AI@(2Q<<^.FPT)/?V.6HKAUB8>W!)P MQH%+QL2+X:T3QA/#A5/?BWR7'P_B;*BXT+"-B1OK6?8NV!T?&Q10I75!F4B* M:.Z*\>^*<.^+<>^+<-,2(H<_=.*Q@>I@0P/^\@DC&R5:#/U;/8C#!N2"RB@D M:$6V$XQ1Y/-H:V8;#5)#7.UN*6;U(< /)/2(JX]\+T8/VMPQ^4'((I?A(VLX M97*6WF)OS(T/S#E;Q(UV9$@<6DX M&BZD)T4-0Z>K@%1H1T M:*FX1@/I9^^2 =9KX01]FQ]899SUY/H7^#B;2>![?02?!W.;S1@PRL@?Q2:[ =C/Y@J_YKD!W1[?*85V6*7*%?#OX!(@K''X@X ![ end From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 18:12:42 1993 From: Kevin M Mccarthy Subject: Re: new patches. To: chopps@emunix.emich.edu (Chris Hopps) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1605 Sender: NetBSD-Admin@cbmuucp.commodore.com Chris Hopps Spoketh: > > I light of Roy getting his Xami runing under 720+ I need to get some > patches to people right away that enable the view device. > > What these patches fix: > > slighlty odd handling of mode guessing for overscan NTSC would > switch to PAL when people probably didn't want it to---fixed. > > now enables Border blank on systems that support it (ECS). > > enables view device and changes standard config files to create 10 > views by default. NOTE: when recompiling don't forget to run > config.amiga again. > > I created these patches from the default 720 sources patched from my > earlier diffs. So if you want to use these you need to have patched > your source with my previous diffs. > > Here they are. [uuencoded stuff deleted] I was wondering if someone could please upload a kernel with all the new patches installed AND support for views compiled in? I only have 4 megs of memory and I usually have to let compiles go overnight to build a new kernel. I MUCH prefer it when I can download a binary... (I was sad to see the MW's distributed 720 kernel didn't have views :-( ) Anyway Thanks in advance -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 18:18:36 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: sed, regcomp, and manpages To: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2259 Sender: NetBSD-Admin@cbmuucp.commodore.com > Has anyone noticed some unusual behavior with sed and regcomp, and > displaying manpages? I noticed that sed is not working properly under > 720. It doesn't pass any of the tests, and segs whenever I try to do > anything non-trivial with it. I also tried grabbing the old > statically linked sed and a sed from a sun3. Neither of those seem to > be working correctly either. I'm using a SunOS sed, without problems. *HOWEVER* ********* There *is* a kernel bug in the current kernel, that I couldn't track down. I know what happens, I don't know why it happens... What does happen: - in certain circumstances - signals are delivered with one long too much (!) on the stack, that is, the signal stack looks like this: signal handler ..... +---------+ handler parameters.. | | ... +---------+ saved proc context | | ... | | ... = = ... | | ... +---------+ extra long +---------+ - on restore of the proc context after returning from the signal handler, that long is left there, and - who wonders - leads to a severe process crash. The misteriose thing about this is that it doesn't happen always, just under some weird context. I can reproduce it by rlogin into my system as "mw", and there trying to do another rlogin. The second rlogin always fails. I also tried playing around with the size of the exported environment, and thought that enlarging the environment sometimes got rid of the bug, but I can't really confirm this. > I traced one source of segmentation violation to recomp(), but I can't > try to build or test it because to do so you need a functioning sed. > recomp() in the gnu regex library does not seem to be working quite > the way it should either. Any suggestions? I could be that those functions really are buggy, but you should try and run the program in question with ktrace, and see whether the crash happens immediately after a sigreturn. So.. anybody just had a bright light turn on in your human kernel?:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 18:30:43 1993 To: Chris Hopps Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Xami From: ggk@tirith.uucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >Maybe these keys could be caught by X and it could close kbd? dunno it >will need to know when to reopen them too I guess. I was connsidering >writing a CX like daemon when I started messing with ite.c, not there yet. Okay, I don't know how ite/grf/view/kbd/mouse are configured right now, but, I was just thinking about this problem and thought maybe I should toss some ideas out for arguments' sake. What if, in addition to /dev/viewXX, there were /dev/mouseXX and /dev/kbdXX devices (where XX are numbers). From an application standpoint, you open exclusive inputs and outputs (with matched numbers). The kernel must then provide a user focus for each of these devices. The focused view would be visible on screen, the focused keyboard would get keyboard information (make sure focus changes only happen when there are no keys pressed??), and the focused mouse would get mouse information (again, make sure no mouse buttons are pressed). It should be possible to change these focii in a configurable manner. Some people will want Motif like changes where keyboard, mouse and view change together, others will want Intuition like changes, where keyboard and mouse change together, independantly from view. I'm sure someone will want to be able to use their mouse on one view, type on the keyboard in another, and look at a third... Things that really need to be thought about: what about multiple displays? How about when the view focus changes, it affects only the display to which the view is associated, leaving whatever was last active on the other display. Actual focus changes. Perhaps a special keyboard device which can be programmed to trap only certain keys before they get sent through the /dev/kbdXX interface. Then, user configurable keystrokes could be watched for by a daemon to change keyboard/mouse/view focii. >There are no sprites :^( Sprites didn't figure quickly into the RTG >system I had dreamt up. I still have problems with RTG, let alone >trying to get a sprite into the system. :^) Well, since at least one graphics device (cc) supports a hardware sprite, I think support for them should be included. Since one graphics device that supports hardware sprites draws them using huge pixels (again, cc) it should be configurable. I think it is part of a view to know whether a hardware cursor can be rendered or not, and to handle that rendering. From an X server, it means if'ing out (or using pointers to functions or something) the cursor rendering code. Another thing to think about is a DUALPF screen - provide a monochrome overlay akin to certain sun graphics boards. >Use of the CPU is much faster than the blitter on all machines that >NetBSD currently (and probably hereforth) runs on. Yes, but, by the same token, I'm sure on a fast enough machine I could write a PIO SCSI driver that is at least as fast as DMA. The difference is PIO consumes many cycles from other things the machine could be doing, whereas DMA happens without much processor involvement. Same with the blitter. If I decide to turn OpaqueMove on in twm (once I get NetBSD and X installed and running...), I want the blitter to move the windows (if possible) not the CPU - that way everything else in the system can stay running. Just my thoughts. >Chris. Gregory Kritsch | 3A Computer Engineering at UWaterloo ggk@tirith.uucp | "Life is a highway ...!xenitec!tirith!ggk | Life is a stinking highway!" -BNL From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 18:38:15 1993 Subject: Re: Xami To: netbsd-amiga@cbmuucp.commodore.com From: Phil Mucci X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 417 Sender: NetBSD-Admin@cbmuucp.commodore.com Someone said that the CPU is faster for blitting that the blitter itself. While this is true, the whole purpose of the custom chips is asynchronous execution. If I'm doing lots of window moves in X, and computing at the same time, I'd rather have the blitter doing all the work. Also, a separate blitter routine would be nice as it would allow people with accelerated gfx cards to write their own routines. -Phil From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 19:06:25 1993 From: Roy Trevino To: netbsd-amiga@cbmuucp.commodore.com Subject: Xami Sender: NetBSD-Admin@cbmuucp.commodore.com > > > > > Currently I don't turn off console for reasons listed above. Also, > > what about if you *want* to be able to pop up the console (with some > > special keys, ala Amiga-N/Amiga-M). Need some way to refocus > > keyboard/ mouse on the console. > > Maybe these keys could be caught by X and it could close kbd? dunno it > will need to know when to reopen them too I guess. I was connsidering > writing a CX like daemon when I started messing with ite.c, not there yet. > I would rather not have to catch these at the application level (ie X). Seems like the keyboard would work with views at the kernel level to automagically refocus on the top view. For example - /dev/kbd and /dev/mouse opened for read by many programs (may need different device numbers though), but only the top view gets input delivered. I have no idea what a "CX like daemon" is - maybe it is just this? > ... > Use of the CPU is much faster than the blitter on all machines that > NetBSD currently (and probably hereforth) runs on. > True, but how about if the CPU is already busy? I am hoping I can use them *both* - there are plenty of other things the CPU can be doing, from calculating shapes in X to keeping that kernel compile going :-). > ... > Chris. > Roy From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 19:46:01 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: sed, regcomp, and manpages Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312151607.AA01557@public.btr.com> eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) writes: > I have also discovered that whenever I try to display something with > fancy formatting, say a manpage, the kernel vectors off into > infinity. Seems that something's wrong with the ite stuff. > > Has anyone else discovered any of these problems? I saw this one last night... I looked at a man page and right after one display-style transition (bold section header, \n\t, normal text) it started drawing characters in blue vertically up the screen from the current cursor position, and obviously kept going right through memory, as the machine wedged. -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 19:59:11 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: X still MMU-faulting Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 15, 6:46pm, Arthur Hoffmann wrote: > I can't get X11R5 to work on my A3000 NetBSD machine. > It always MMU faults. I'm running kernel 720 and applied > the recent patches to enable X, but still it mmufaults. > Even the kernel that mykes uploded mmufauls, and that > was supposed to work. I don't think anyone other than me has any patches to fix the MMU faulting when running the X11R5 server. Now that I have upgraded my sources to 720 and applied the recent (well, recent as of last night) console fixes, I have been able to check my changes to fix the MMU faulting. The problem is that there is one place the ite console doesn't check to see if the console is really enabled. This doesn't hurt the Retina console, but will cause an MMU fault on the cc console code. Here's the patches I used to fix the problem - it doesn't call the ite_cursor routine when the console has been switched to graphics mode. It seems to be doing the trick for me. *** src/sys/arch/amiga/dev/ite.c Mon Dec 6 19:48:06 1993 --- sys/arch/amiga/dev/ite.c Wed Dec 15 05:15:44 1993 *************** *** 513,519 **** hiwat++; cc = iteburst; } ! (*itesw[ip->type].ite_cursor)(ip, START_CURSOROPT); while (--cc >= 0) { register int c; --- 513,520 ---- hiwat++; cc = iteburst; } ! if ((ip->flags & (ITE_ACTIVE|ITE_INGRF)) == ITE_ACTIVE) ! (*itesw[ip->type].ite_cursor)(ip, START_CURSOROPT); while (--cc >= 0) { register int c; *************** *** 531,537 **** iteputchar(c, tp->t_dev); spltty(); } ! (*itesw[ip->type].ite_cursor)(ip, END_CURSOROPT); if (hiwat) { tp->t_state |= TS_TIMEOUT; timeout((timeout_t) ttrstrt, (caddr_t) tp, 1); --- 532,539 ---- iteputchar(c, tp->t_dev); spltty(); } ! if ((ip->flags & (ITE_ACTIVE|ITE_INGRF)) == ITE_ACTIVE) ! (*itesw[ip->type].ite_cursor)(ip, END_CURSOROPT); if (hiwat) { tp->t_state |= TS_TIMEOUT; timeout((timeout_t) ttrstrt, (caddr_t) tp, 1); Michael From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 21:24:54 1993 From: Roy Trevino To: NetBSD-amiga@cbmuucp.commodore.com Subject: Re: sed, regcomp, and manpages Sender: NetBSD-Admin@cbmuucp.commodore.com > > I have also discovered that whenever I try to display something with > > fancy formatting, say a manpage, the kernel vectors off into > > infinity. Seems that something's wrong with the ite stuff. > > > > Has anyone else discovered any of these problems? > > I saw this one last night... I looked at a man page and right after one > display-style transition (bold section header, \n\t, normal text) it > started drawing characters in blue vertically up the screen from the > current cursor position, and obviously kept going right through memory, > as the machine wedged. Count me as as another who experienced this - running rn, my newsreader highlights the subject with reverse vid. As soon as it finishes with the highlight, it dispenses with the kernel too. Same characteristics as above - memory spear made up of blue vertical garbled characters. Sounds like a minor but potent bug in ite vt200 emulation. Roy From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 21:31:13 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Re: No Room to install GNUUSR on the usr partition What to do? Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312151648.AA24980@sol-tx.sps.mot.com> Alan Bair writes: >As an ex-sysadmin in real life, I would recommend doing away with the large >number of partitions. Something more like the following would make better >use of the potentially small amount of disk space available for NetBSD. > > /usr sd5d 82megs > /opt sd5f 50megs > /home sd5g 50megs > /root sd6a 8megs > /swap sd6b 16megs > >I don't see any real purpose for the original /proj and /home2. You may even >want to merge /opt and /home. When I put NetBSD on my 88M SyQuest, I just >have /root, /swap and /usr. > >Some people my be concerned about trashing partitions and thus want to keep >things separate. However, the main thing to watch for is to keep the >development areas separate from the system, like /root and /usr. Then if >your program goes wild and trashes the directory structure, you only lost >the development area and not the OS. Then you just restore from the backups >you have been making. I think after going through the install process I have enough knowledge now to make the above judgements. Unfortunatly, the changes suggest, will not be practical. Unless I can repartition the hd without disturbing the amigados side and loose data in one of the directorys on the BSD side.. My suggestion would be that an explanation of the various directories and min required to store x - x files.. Be added to the faq... I was under the impression that I had to have a /home /home2 /opt /usr /proj. But actually seeing I discovered how to use the ln -s filepath filepath command It's not a problem now... -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 22:59:10 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: sed, regcomp, and manpages To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 647 Sender: NetBSD-Admin@cbmuucp.commodore.com > I saw this one last night... I looked at a man page and right after one > display-style transition (bold section header, \n\t, normal text) it > started drawing characters in blue vertically up the screen from the > current cursor position, and obviously kept going right through memory, > as the machine wedged. This *must* be a cc-console bug, I never ever have seen such a behavior with the Retina console, and as you can perhaps imagine, I'm using it quite excessively :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Wed Dec 15 23:18:31 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: sed, regcomp, and manpages To: rtrevino@sedona.intel.com (Roy Trevino) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 539 Sender: NetBSD-Admin@cbmuucp.commodore.com > characteristics as above - memory spear made up of blue vertical > garbled characters. Sounds like a minor but potent bug in ite vt200 > emulation. Although not completely impossible, to repeat myself, if it were a plain emulator bug (ie. in the ite.c, device-independent part), I should have experienced the very same problem with the Retina console, which I didn't. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 00:19:01 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sed, regcomp, and manpages To: NetBSD-Admin@cbmuucp.commodore.com (Markus Wild) Cc: tsarna@endicor.com, NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I saw this one last night... I looked at a man page and right after one > > display-style transition (bold section header, \n\t, normal text) it > > started drawing characters in blue vertically up the screen from the > > current cursor position, and obviously kept going right through memory, > > as the machine wedged. > > This *must* be a cc-console bug, I never ever have seen such a behavior > with the Retina console, and as you can perhaps imagine, I'm using it > quite excessively :-) Well I agree it sure sounds like a cc bug, however I can display manpages perfectly here with underline, bold and inverse without any side effects. I also didn't change anything just compiled the distributed src0712.tar.gz code. I even tried all 3, with the shell command % printf "\033[1m\033[4m\033[7mHello World\033[0m" Which correctly printed "Hello World" in bold-underlie-inverse type. Can someone verify that the above command sends there kernel to lala land? It sure didn't on my machine. > -Markus From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 00:19:09 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Kernel config suggested changes Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com I noticed a whole bunch of minor stuff in the config/build process. Patches are included below for some of it. I hoped to test them before posting, but the best I could do was to grep around and make sure that the unused stuff really was unused, and to check makefiles, etc, to make sure they looked right. Anyway, here goes: - options "HAVE_USL_UFS" is a no-op, as far as I can tell. - cpu-dependant stuff shhould really be set with the cpu keyword :-) Rather than "options FPSP", FPSP support should be included if '040 support is desired. The standard way to do this is with something like 'cpu "M68040"' in the config file. This is how the other ports do stuff. (patch included to make fpsp dependant on 'cpu "M68040"'). - The above begs the question, what does 'cpu "A3000"' mean? Answer: nothing, except in the definition of SBIC_CLOCK_FREQUENCY in dev/scsireg.h, which in turn isn't used anymore. Hence, we can scrap that dependency (patch included) and then scrap cpu A3000 in favor of cpu M68020, M68030, and M68040 definitions. - Makefile.amiga should include ${KERN_IDENT} in the newvers command line. It wasn't, hence the empty () in the "NetBSD 0.9a () [...]" string displyed at boot or via /kern/version. Patch included. - The other ports are calling their kernel "netbsd" rather than "vmunix". I switched my symlinks around to have vmunix and 386bsd (is that one still used other than on the i386?) point to /netbsd. Here are the patches, followed by the my config file, which is set up for these changes. *** /usr/src/sys/arch/amiga/conf/files.amiga.orig Mon Dec 13 00:08:16 1993 --- /usr/src/sys/arch/amiga/conf/files.amiga Mon Dec 13 00:02:13 1993 *************** *** 69,76 **** arch/amiga/dev/grf/grf_view.c optional grf arch/amiga/dev/grf/grfcc.c optional grf arch/amiga/dev/view.c optional grf ! arch/amiga/fpsp/fpsp.o optional fpsp ! arch/amiga/fpsp/fpspnull.s optional not fpsp kern/syscalls.c standard arch/amiga/sunos/sun_disklabel.c optional compat_sunos arch/amiga/sunos/sun_ioctl.c optional compat_sunos --- 69,76 ---- arch/amiga/dev/grf/grf_view.c optional grf arch/amiga/dev/grf/grfcc.c optional grf arch/amiga/dev/view.c optional grf ! arch/amiga/fpsp/fpsp.o optional m68040 ! arch/amiga/fpsp/fpspnull.s optional not m68040 kern/syscalls.c standard arch/amiga/sunos/sun_disklabel.c optional compat_sunos arch/amiga/sunos/sun_ioctl.c optional compat_sunos *** /usr/src/sys/arch/amiga/dev/scsireg.h.orig Mon Dec 13 00:13:04 1993 --- /usr/src/sys/arch/amiga/dev/scsireg.h Mon Dec 13 00:13:07 1993 *************** *** 308,319 **** #define sbic_isa_select(cmd) (((cmd)>0x5)&&((cmd)<0xa)) #define PAD(n) char n; - #ifdef A3000 - #define SBIC_CLOCK_FREQUENCY 143 /* according to A3000T service manual */ - #endif - #ifdef A2091 - #define SBIC_CLOCK_FREQUENCY 77 - #endif #define SBIC_MACHINE_DMA_MODE SBIC_CTL_DMA typedef struct { --- 308,313 ---- *** /usr/src/sys/arch/amiga/conf/Makefile.amiga.orig Mon Dec 13 00:32:37 1993 --- /usr/src/sys/arch/amiga/conf/Makefile.amiga Mon Dec 13 00:33:30 1993 *************** *** 89,95 **** vers.o: newvers newvers: ! sh $S/conf/newvers.sh ${CC} $(CFLAGS) -c vers.c clean: --- 89,95 ---- vers.o: newvers newvers: ! sh $S/conf/newvers.sh ${KERN_IDENT} ${CC} $(CFLAGS) -c vers.c clean: And here's my config file (/sys/arch/amiga/conf/ROUS): ---snip snip--- machine "amiga" #cpu "M68020" cpu "M68030" #cpu "M68040" ident ROUS timezone 5 dst maxusers 16 maxfdescs 2048 # Standard options #options QUOTA options SWAPPAGER,VNODEPAGER,DEVPAGER options INET options NFS,NFSSERVER,NFSCLIENT options MFS options ISOFS options FIFO #options MSDOSFS options KERNFS options FDESC #options ISO #options TPIP # Graphics options options GRF options GRF_CUSTOM_CHIP_MODES options GRF_OCS options GRF_ECS #options GRF_ACS options GRF_NTSC options GRF_PAL options "GRF_A2024" options "COMPAT_43" options "TCP_COMPAT_42" options "COMPAT_NOMID" options "PANICWAIT" # Compatibility options options SYSVSHM,SYSVMSG,SYSVSEM options COMPAT_SUNOS #options HPUXCOMPAT # Options specific to this host. options DEBUG,DIAGNOSTIC,FPCOPROC # options PANICBUTTON options KTRACE #options "BUFPAGES=900" options "NKMEMCLUSTERS=256" #options GENERIC #options PROFTIMER,"PRF_INTERVAL=500" #options KGDB,"KGDBDEV=15*256+2","KGDBRATE=19200" options "PPP_OUTQ_SIZE=4096" #config netbsd swap generic config netbsd root on sd0a swap on sd0b # manufacturer 1 is a pseudo and stands for `builtin' master a3000scsi0 at manufacturer 1 product 1 #master a2091scsi0 at manufacturer 514 product 3 #master gvp11scsi0 at manufacturer 2017 product 11 #master zeusscsi0 at manufacturer 2026 product 150 #master magnumscsi0 at manufacturer 1058 product 17 #master floppy0 at manufacturer 1 product 2 # further builtin devices device ser0 at manufacturer 1 product 3 #device clock at manufacturer 1 product 4 device par0 at manufacturer 1 product 6 disk sd0 at a3000scsi0 slave 0 #disk sd0 at a2091scsi0 slave 0 #disk sd0 at gvp11scsi0 slave 0 #disk rz0 at zeusscsi0 slave 0 #disk rz0 at magnumscsi0 slave 0 disk sd1 at a3000scsi0 slave 1 #disk sd1 at a2091scsi0 slave 1 #disk sd1 at gvp11scsi0 slave 1 #disk rz2 at zeusscsi0 slave 1 #disk rz2 at magnumscsi0 slave 1 disk sd2 at a3000scsi0 slave 2 #disk sd2 at a2091scsi0 slave 2 #disk sd2 at gvp11scsi0 slave 2 #disk rz2 at zeusscsi0 slave 2 #disk rz2 at magnumscsi0 slave 2 disk sd3 at a3000scsi0 slave 3 #disk sd3 at a2091scsi0 slave 3 #disk sd3 at gvp11scsi0 slave 3 #disk rz3 at zeusscsi0 slave 3 #disk rz3 at magnumscsi0 slave 3 disk sd4 at a3000scsi0 slave 4 #disk sd4 at a2091scsi0 slave 4 #disk sd4 at gvp11scsi0 slave 4 #disk rz4 at zeusscsi0 slave 4 #disk rz4 at magnumscsi0 slave 4 disk sd5 at a3000scsi0 slave 5 #disk sd5 at a2091scsi0 slave 5 #disk sd5 at gvp11scsi0 slave 5 #disk rz5 at zeusscsi0 slave 5 #disk rz5 at magnumscsi0 slave 5 disk sd6 at a3000scsi0 slave 6 #disk sd6 at a2091scsi0 slave 6 #disk sd6 at gvp11scsi0 slave 6 #disk rz6 at zeusscsi0 slave 6 #disk rz6 at magnumscsi0 slave 6 tape st0 at a3000scsi0 slave ? #tape st0 at a2091scsi0 slave ? #tape st0 at gvp11scsi0 slave ? #tape tz0 at zeusscsi0 slave ? #tape tz0 at magnumscsi0 slave ? tape st1 at a3000scsi0 slave ? #tape st1 at a2091scsi0 slave ? #tape st1 at gvp11scsi0 slave ? #tape tz1 at zeusscsi0 slave ? #tape tz1 at magnumscsi0 slave ? device grf0 at manufacturer 1 product 7 device grf1 at manufacturer 18260 product 6 # builtin clock (should all identify as "rtclock") device rtclocka0 at manufacturer 1 product 4 device rtclockb0 at manufacturer 1 product 9 # ethernet board device le0 at manufacturer ? product ? # my dear A2410 #device tiga0 at manufacturer 1030 product 0 pseudo-device sl 1 pseudo-device ppp 1 pseudo-device bpfilter 16 pseudo-device ite 2 pseudo-device kbd 1 pseudo-device mouse 2 pseudo-device pty pseudo-device loop pseudo-device ether #pseudo-device vn 10 ---snip snip--- -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 01:15:40 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: Re: sed, regcomp, and manpages To: chopps@emunix.emich.edu (Chris Hopps) Cc: NetBSD-Admin@cbmuucp.commodore.com, tsarna@endicor.com, NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 733 Sender: NetBSD-Admin@cbmuucp.commodore.com > I even tried all 3, with the shell command > % printf "\033[1m\033[4m\033[7mHello World\033[0m" > Which correctly printed "Hello World" in bold-underlie-inverse type. > Can someone verify that the above command sends there kernel to lala land? > It sure didn't on my machine. I just tried it out and went into AMIGA_FIREWORKS_MODE. My setup is: A2500 (A2630+A2091) 4MB 32-bit RAM 1MB Chip RAM ECS Agnus ECS Denise kernel: #720 + the patches that were posted yesterday I'm running a customized kernel (not generic), no NFS, no A2024 support, and I don't think I have the PAL stuff compiled in. I'm also sometimes getting text stuck in the wrong bitplanes or in the borders. It never erases. Hope this helps. Eduardo From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 02:04:08 1993 From: Kevin M Mccarthy Subject: Re: sed, regcomp, and manpages To: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1137 Sender: NetBSD-Admin@cbmuucp.commodore.com Eduardo E. Horvath eeh@btr.com Spoketh: > > > > I even tried all 3, with the shell command > > % printf "\033[1m\033[4m\033[7mHello World\033[0m" > > > Which correctly printed "Hello World" in bold-underlie-inverse type. > > > Can someone verify that the above command sends there kernel to lala land? > > It sure didn't on my machine. > > I just tried it out and went into AMIGA_FIREWORKS_MODE. My setup is: This is strange.. I used to get the vertical bar of characters when I read man pages as well, but I switched from the generic vmunix.720 to vmunix.mykes today and the problem ceased. So something that was changed between the two kernels is the culprit I guess. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 02:19:27 1993 From: Bill Squier To: chopps@emunix.emich.edu, rtrevino@sedona.intel.com Subject: Re: Xami Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >From: Roy Trevino >c) how to use in general the blitter at the ioctl level. I was going to look in to a scheme to do something similar for writing /dev/audio. I imagine there should be a general way to map chip mem address space into user or system address space. (Unix kernel hacking is new to me). If not, can't we fix some area of chipmem for the blitter and some for /dev/audio with the chipmem stealing routines in the kernel startup? Boy do I have to take some time and trace through a NetBSD startup so I know what the hell's going on! -wps From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 02:52:08 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Xami To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: rtrevino@sedona.intel.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > >From: Roy Trevino > > >c) how to use in general the blitter at the ioctl level. > > I was going to look in to a scheme to do something similar for writing > /dev/audio. I imagine there should be a general way to map chip mem > address space into user or system address space. (Unix kernel hacking > is new to me). If not, can't we fix some area of chipmem for the blitter > and some for /dev/audio with the chipmem stealing routines in the kernel > startup? Please look in cc_audio.c example uses in ite_cc.c on how to play samples. /dev/audio should be a snap. I wrote cc_audio.c with /dev/audio in mind. cc_chipmem.c is a chipmem heap. cc_blitter.c is the framework for blitter routines all setup and ready to be added to (it handles the basic interrupts right now.) > -wps Chris. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 02:58:29 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: sed, regcomp, and manpages To: NetBSD-Admin@cbmuucp.commodore.com (Markus Wild) Cc: rtrevino@sedona.intel.com, NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > characteristics as above - memory spear made up of blue vertical > > garbled characters. Sounds like a minor but potent bug in ite vt200 > > emulation. > > Although not completely impossible, to repeat myself, if it were a > plain emulator bug (ie. in the ite.c, device-independent part), I should > have experienced the very same problem with the Retina console, which > I didn't. Not true, I use a vector table with an index based on the style for a slected character in the cc putc routine, if ite.c is sending invalid styles then it may vector into nowhere. bounds checking is inappropriate for putc as the only reason I use a vector table is for speed. It sounds like this is whats happening, however, I don't think ite.c is sending invalid styles as they are defined values. I will look over the vector jump routine again to make sure its not doing something odd, but I dought it as it works here fine. If it were broken it should break on everyones machine. > -Markus From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 07:15:32 1993 From: niklas@appli.se (Niklas Hallqvist) To: mw@eunet.ch Cc: mw@eunet.ch, tsarna@endicor.com, NetBSD-amiga@cbmuucp.commodore.com Subject: Re: Anyone have a working 4M configuration Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "MTK" == Markus Wild writes: >> I have had problems in pmap_enter_ptpage when running out of kernel >> memory. If I remember correct the ste was NULL. I used to get >> this when using my AmigaDOS FS in memory-hogging ways (recursive >> scans of large directories with large files). I guess out of >> memory conditions aren't correctly handled... MTK> Hm.. perhaps this depends on the actual amount of available MTK> physical memory, whether memory shortage is handled gracefully or MTK> not? As I said, I've started 50 emacses consuming around 25M of MTK> swap-space, and didn't have a single problem with this. Don't MTK> tell me my 12m could handle this amount ... That was not what I meant. I have no problem when user-mode programs uses much memory. It's when the kernel itself eats memory this happens to me. The ADOS FS I have (lots of credit to Frank "Crash" Edwards) keeps an in-core cache of all active ADOSFS inodes' (anodes) block numbers (well, those that have been seen). This is needed in order to make seeks in large files reasonably fast, otherwise every seek would have to start from the beginning (ADOS FSs isn't very nice in this way). As you can guess this can take up a whole lot of memory when dealing with *huge* files, especially when they are dealt with in groups, like backing up an archive directory. I'm redoing exactly this area for the BSD-copyrighted version, but it's not yet ready (lack of time is the biggest obstacle). Anyway, vmstat -m shows an increasing memory usage and suddenly pmap_enter_ptpage bombs. Now I'm not complaining about this, as it is my code that triggers the problem here. Maybe I have a leak or something. I just put my $.02 in when I saw that someone else had seen a pmap_enter_ptpage fault in a *standard* kernel on a lowmem machine. Niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 13:10:49 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: NetBSD development mailing list. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com It is beginning to look as if we need another mailing list strictly for development of NetBSD. Could someone in a position to handle this give an opinion on how hard it would be to set up another list, say, netbsd-amiga-devel@... I still want to read the other list its just that sometimes I don't have time to do the parsing myself and need to get at the more meaty posts and then do other important things... Chris. From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 16:36:34 1993 From: Alan Bair Subject: Re: NetBSD development mailing list. To: chopps@emunix.emich.edu (Chris Hopps) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com How about putting a keyword in the subject line for important items like patches or upload announcements. This avoids the need for a second E-mail list, but still lets you find those postings of importance. Besides, unless the new list is some how restricted, I think you would find the same group of people moving over there. I know I would want to hear what is going on :) > > It is beginning to look as if we need another mailing list strictly > for development of NetBSD. Could someone in a position to handle this > give an opinion on how hard it would be to set up another list, say, > netbsd-amiga-devel@... > > I still want to read the other list its just that sometimes I don't > have time to do the parsing myself and need to get at the more meaty > posts and then do other important things... > > Chris. > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 17:45:25 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: I WANT MY MAN WORKING AGAIN! WHAT TO DO? Sender: NetBSD-Admin@cbmuucp.commodore.com I downloaded the 3.+ meg file that contains the man for netbsd, bin-usr.share file and copied it over to netbsd, un tared it and ran make install a couple of minor warnings and BAM! Everything worked great. I could type a command such as "man rm" and it would explain to me exactly everything I ever wanted to know about RM but was really afraid to ask.. So I'm really grinnin' at this point.. "hey I might be able to figure out what I'm doing now!" Well unfortunatly the story doesn't stop here. I come across two more files with the words "MAN" in them one being manpages, and the last being aman.1.0 (something) So I get em'. Great I'm thinking, I'm going to beable to figure out more.. Well I install manpages and run make install all goes well I test it out to see if it's working and the other man is working still And sure as heck things are going great.. I can can get Iformation on almost anything by just typing "man " or "man " or "ect..." Wait there is another manual, MORE INFORMATION!!! I Have to get it installed. So I do, I run make install kicks out with a bunch of warnings missing directorys So I add the directorys and make install agian. It works great now to test it.. "man rm" wooooohhhhhhhhh! lets try that again.. "man printf" SHITTTTTTT! what's happened? All my helps gone :( so I tried remaking the original and now it's saying it can't make install any longer. Something is real wrong here. To top it off the Makefile.inc that was in the share library (I though maybe needed to be deleted so I do...) I don't think that was the right move. It still won't make it again, and Now I can't get any "man help" HELP! -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 18:20:49 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: netbsd-amiga@cbmuucp.commodore.com Subject: new kernel, sources? Sender: NetBSD-Admin@cbmuucp.commodore.com Howdy, Did anyone respond to yesterday's request for a new kernel release with all the patches applied and views compiled in? Also, will there be a new source release that contains all of these bits too? I am interested in moving up to shared libraries, but don't want to risk missing some fix or feature. Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 18:26:39 1993 From: rtulloh@oneway.austin.ibm.com (Rob Tulloh) To: netbsd-amiga@cbmuucp.commodore.com Subject: shared libraries and space requirements Sender: NetBSD-Admin@cbmuucp.commodore.com Howdy again! Have disk space requirements gone down since shared libs were introduced? I am curious since I plan to repartition when I upgrade to v720 (or later) and I would like to know what I can expect in terms of resource usage. Rob +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + Rob Tulloh WPX Development rtulloh@austin.ibm.com + + IBM, Bldg 42, Rm 1B061, 11400 Burnet Rd. Austin, TX (512) 823-6287 + +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 18:34:06 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: NetBSD-amiga@cbmuucp.commodore.com Subject: Device driver duplication of code. Sender: NetBSD-Admin@cbmuucp.commodore.com I have started to look into how we can stop duplicating code for each new SCSI controller card thats added. For instance st.c -> tz.c seem identical except for the name of the structures etc. The part that scares me is when code starts diverging just do a diff on st.c and tz.c. There has got to be a workable solution we can live with! I would hate for our kernel to become as bloated as a Sun kernel and top the 1M mark. It has grown by 50% in the last 6 months. Would interested parties please e-mail me off-line, when you have the chance? I would like you opinions as to the scope of this project: One question that comes to mind is: Do we have a need to support using two or more SCSI controller cards at the same time? Is 1 sufficient? Why or Why not? Can any one suggest a good book on device drivers for the BSD4.3 brand of OS we have. I hope not to actually need to use it but... I heard there is alot of junk out there. -Rob From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 18:34:43 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "new kernel, sources?" (Dec 16, 11:13am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: rtulloh@oneway.austin.ibm.com (Rob Tulloh), netbsd-amiga@cbmuucp.commodore.com Subject: Re: new kernel, sources? Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 16, 11:13am, Rob Tulloh wrote: > Subject: new kernel, sources? > Howdy, > > Did anyone respond to yesterday's request for a new kernel release > with all the patches applied and views compiled in? Also, will there > be a new source release that contains all of these bits too? I am > interested in moving up to shared libraries, but don't want to risk > missing some fix or feature. There is: get vmunix.mykes.tar.gz on eunet .../incoming Source release son, i was told. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 19:14:03 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: NetBSD development mailing list. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312161200.AA29060@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > It is beginning to look as if we need another mailing list strictly > for development of NetBSD. Could someone in a position to handle this > give an opinion on how hard it would be to set up another list, say, > netbsd-amiga-devel@... There was some talk of creating a NetBSD/Amiga newsgroup, and everyone said "just use comp.unix.amiga". So, howabout if we move "user" discussions there and use the mailing list for development discussion? Maybe we should rename the list to NetBSD-Amiga-Devel at the same time. Comments? -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 21:42:21 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netBSD-Amiga@cbmuucp.commodore.com Subject: Re: NetBSD development mailing list. Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9312161526.AA10667@sol-tx.sps.mot.com> Alan Bair writes: If you want to call my board I will give you a newsreader I wrote that will take and combined all posts on a particualar subject which makes it much easier to follow a group. It works only from the amiga dos side, but later plan to port it to the netbsd side... It uses an on the fly indexer as well as one you can run from dcron or patch into uuxqt... It handles mailing lists just like a newsgroup also.. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 21:59:31 1993 From: William J. Coldwell To: Alan Bair Subject: Noted. ( was: NetBSD development mailing list.) Cc: chopps@emunix.emich.edu (Chris Hopps), netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com I will work on a solution to this over this weekend. Until then, let's let the list return to netbsd, and not admin crap (there's enough mail travelling to everyone's mailbox). Thanks, Bill -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 22:33:50 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Shared library problems Sender: NetBSD-Admin@cbmuucp.commodore.com Since I had updated my kernel to the 720 version, I decided it was time to upgrade to the new binaries. The /bin and /sbin binaries installed and ran fine. Then I installed the /usr/bin and /usr/sbin binaries (and the /usr/lib and /usr/libexec files). When I tried to start up multiuser mode I got segment violations all over the place, and ended up with several core.* files filling up the root partition. When trying to logon, I just got another segment violation. After looking through the crt0.s source to see how the shared libraries were implemented, I figured out that the shared library can be mapped any where in the user process and somehow things are adjusted so the necessary addresses are dynamically adjusted as appropriate. Since I assume that this involves instructions and addresses in data that are modified, this presents a big problem on the 68040 when running with caches enabled. I first tried running my kernel with the copyback cache disabled, but it still gave me segment violations or bus errors when trying to run a binary that used a shared library. The next step was to run with both data and instruction caches turned off. Then I was able to execute binaries fine and was able to boot up into multiuser mode. I then tried running the kernel with the data cache enabled, but with copyback disabled. That also seemed to run fine. Has anyone else running on a 68040 system attempted to run with the latest binaries, or am I the first? Is there any provision in NetBSD for a user level program to push the data and instruction caches? It looks like the shared library initialization is going to need something like this to work correctly. Michael From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 22:40:21 1993 From: mw@eunet.ch Subject: Re: shared libraries and space requirements To: rtulloh@oneway.austin.ibm.com (Rob Tulloh) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 867 Sender: NetBSD-Admin@cbmuucp.commodore.com > Have disk space requirements gone down since shared libs were > introduced? I am curious since I plan to repartition when I I'd say shared libs have brought considerable space savings, mostly in /usr/bin area. Quite a bit of programs in /usr/gnu have not yet been recompiled to take advantage of shared libs, so I guess we can expect even more space savings in the future. Another remark: kernel-development and the current binary distribution of the system are not very tightly coupled. You could run the new shared binaries with an old kernel, as well as you can use a new kernel on old binaries. There's no excuse to wait installing shared libraries if you don't trust the current kernel :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 22:52:03 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: shared libraries and space requirements Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 16, 10:26pm, mw@eunet.ch wrote: > Another remark: kernel-development and the current binary > distribution of the system are not very tightly coupled. You > could run the new shared binaries with an old kernel, as well > as you can use a new kernel on old binaries. There's no excuse > to wait installing shared libraries if you don't trust the > current kernel :-) How about if the shared libraries don't work? They appear to have severe problems when running on a 68040 with the caches enabled. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 23:03:12 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: Shared library problems To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1064 Sender: NetBSD-Admin@cbmuucp.commodore.com > After looking through the crt0.s source to see how the shared libraries > were implemented, I figured out that the shared library can be mapped any > where in the user process and somehow things are adjusted so the necessary > addresses are dynamically adjusted as appropriate. Since I assume that > this involves instructions and addresses in data that are modified, this > presents a big problem on the 68040 when running with caches enabled. Makes sense... > Is there any provision in NetBSD for a user level program to push the > data and instruction caches? It looks like the shared library initialization > is going to need something like this to work correctly. I think the hp300 port had/has a cachectl system call, that allows such things (mainly to control the huge VAC on some hp300). We'll probably need such a thing too? Unfortunately, that's an area I can't test at all... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 23:20:06 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Shared library problems Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 16, 10:58pm, Markus Wild wrote: > > Is there any provision in NetBSD for a user level program to push the > > data and instruction caches? It looks like the shared library initialization > > is going to need something like this to work correctly. > > I think the hp300 port had/has a cachectl system call, that allows > such things (mainly to control the huge VAC on some hp300). We'll > probably need such a thing too? Unfortunately, that's an area I can't > test at all... I remember seeing some references to flushing the external cache, but it was from withing the kernel (called from the disk driver, I think). Ah, I just searched through some of the hp300 port and found a comment that trap 12 is the cachectl "syscall" for both HPUX and BSD. It appears that the same code is in the amiga code: locore.s has trap12 call cachectl() in amiga/sys_machdep.c, which makes the appropriate calls to the routines in locore.s that should work on the 68040. All I need now is to have the shared libraries do the appropriate "syscall". Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Dec 16 23:34:09 1993 Subject: Re: NetBSD development mailing list. To: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit From: swt@garble.affinity.mn.org (Stephen W. Thomas) Content-Type: text/plain; charset=US-ASCII Content-Length: 975 Sender: NetBSD-Admin@cbmuucp.commodore.com > From: tsarna@endicor.com (Ty Sarna) > > In article <9312161200.AA29060@emunix.emich.edu> chopps@emunix.emich.edu (Chris Hopps) writes: > > It is beginning to look as if we need another mailing list strictly > > for development of NetBSD. Could someone in a position to handle this > > give an opinion on how hard it would be to set up another list, say, > > netbsd-amiga-devel@... > > There was some talk of creating a NetBSD/Amiga newsgroup, and everyone > said "just use comp.unix.amiga". So, howabout if we move "user" > discussions there and use the mailing list for development discussion? > Maybe we should rename the list to NetBSD-Amiga-Devel at the same time. > > Comments? This is a good idea. I'm all for it. -- Stephen W. Thomas UUCP: swt@affinity.mn.org Affinity Computer Applications, Inc. VOICE: (612) 484-2905 4740 Hodgson Road FAX: (612) 483-4069 Shoreview, MN 55126-6042 USA BIX: affinity From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 00:15:43 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Shared library problems Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article tsarna@endicor.com (Ty Sarna) writes: > sun3 binaries on '040s. (does one need to use the Sun ld.so or will the > NetBSD ld.so work for sun3 binaries? I guess I should try it... If the And the answer is: NetBSD ld.so won't run sun3 dynamicly linked programs. I get a trapsignal() then a segfault. This really limits the usefulness of Sun binary compatibility, since most Sun software is dynamicly linked :-( -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 00:23:13 1993 From: DCG9367@tntech.edu Subject: Re: NetBSD development mailing list. To: netBSD-Amiga@cbmuucp.commodore.com X-Vms-To: IN%"netBSD-Amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com >There was some talk of creating a NetBSD/Amiga newsgroup, and everyone >said "just use comp.unix.amiga". So, howabout if we move "user" >discussions there and use the mailing list for development discussion? >Maybe we should rename the list to NetBSD-Amiga-Devel at the same time. The only problem to this is that I DO NOT have UseNet access. It would be a REAL PAIN IN THE REAR to get the feeds unless someone copied them to the mailing list, but then you have defeated the purpose of having two mailing lists. I guess that this casts a NO vote for me. David. From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 09:25:27 1993 From: mw@eunet.ch Subject: Re: Shared library problems To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1270 Sender: NetBSD-Admin@cbmuucp.commodore.com > In article tsarna@endicor.com (Ty Sarna) writes: > > sun3 binaries on '040s. (does one need to use the Sun ld.so or will the > > NetBSD ld.so work for sun3 binaries? I guess I should try it... If the > > And the answer is: NetBSD ld.so won't run sun3 dynamicly linked > programs. I get a trapsignal() then a segfault. This really limits the > usefulness of Sun binary compatibility, since most Sun software is > dynamicly linked :-( The problem is more the different system call semantics than ld.so. A NetBSD process and a SunOS process use different ways to pass the system call number into the kernel. One uses d0, one passes it on the stack. To run shared SunOS binaries (which I do frequently) you make yourself a /sun directory. Then, copy SunOS ld.so into /usr/lib (remember, NetBSD has it in /usr/libexec !), and edit /usr/lib/ld.so and replace all references to /usr into /sun. You can then have a /sun/lib symlink point into your SunOS /usr/lib directory with the SunOS shared libs. In the same go, also replace /etc by /sun, so ld.so.cache doesn't collide. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 11:34:38 1993 From: swalter@avalon.unizh.ch (walter stefan) Subject: SIM kernel debugger To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 771 Sender: NetBSD-Admin@cbmuucp.commodore.com Okay, for those of you who are interested, I've uploaded the newest version of SIM to ftp.eunet.ch into ../NetBSD-Amiga/incoming. There is some sample assembly source code that shows how to integrate SIM into another program and a very small documentation. The source assembles with A68K, which I guess everyone of you can get. Please note that this program is not finished. There is no complete documentation yet so you need to have a hacker-attitude and some curiosity to find out about what SIM can do. It may have problems with highly expanded Amigas too, but I hope it doesn't. If you have problems to get it running or questions etc., please e-mail me. Good luck! - Stefan -- Stefan Walter - swalter@avalon.unizh.ch 'Ranma no Bakaaaaa!' - Akane From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 14:06:15 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Re: NetBSD development mailing list." (Dec 16, 4:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), NetBSD-amiga@cbmuucp.commodore.com Subject: Re: NetBSD development mailing list. Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 16, 4:38pm, Ty Sarna wrote: > There was some talk of creating a NetBSD/Amiga newsgroup, and everyone > said "just use comp.unix.amiga". So, howabout if we move "user" > discussions there and use the mailing list for development discussion? > Maybe we should rename the list to NetBSD-Amiga-Devel at the same time. I second that. I get the feeling that many newbies (sorry newbies :) that this mailinglist get crowded with 'how to install' and 'my A500/40 does not work' questions (and answers). Not that this is bad, but this maillinglist is by far the most-traffic list i ever read. Every idea which could reduce the traffic gets my vote. As we all do read c.u.a, i guess it's there where questions about installing and other problems should be questioned. I believe that renaming this list is not a good idea. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 15:37:58 1993 Subject: Compiling w/ shlibs From: David Jones To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I just installed the new binaries last night. Problem: when compiling a program, gcc now stops with unresolved references to __DYNAMIC. Something isn't set up right. What? P.S. Don't rename /bin/sh to /bin/old.sh before installing the new bin-bin.tar.gz. I did, and didn't realize that the new bin had no shell, and rebooted. Using diskX to binary edit the BSD filesystem was most educational :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 17:32:33 1993 From: Alan Bair Subject: New 720 rootfs coming To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I finally obtained all the new 720 based software and am in the process of building a new rootfs. I will try to include most of the suggestions that various people have posted. I hope to upload a rootfs_720.gz this weekend. I'll send out an announcement when its ready. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 17:34:40 1993 From: Alan Bair Subject: Booting any 720 kernel To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Here is something I have noticed about the 720 kernels, either Markus W. original or Myke S. new one. If I just go with the kernel as is, all I get is a blue screen, nothing more. If I change ite_default_height to 400 it boots just fine. I have not tried slowly increasing from 400 to see if I can use a higher value like the 448 Myke has. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 17:41:59 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Shared library problems Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <199312170819.JAA21352@eunet.ch> mw@eunet.ch writes: > The problem is more the different system call semantics than ld.so. A > NetBSD process and a SunOS process use different ways to pass the > system call number into the kernel. One uses d0, one passes it on the > stack. To run shared SunOS binaries (which I do frequently) you make > yourself a /sun directory. Then, copy SunOS ld.so into /usr/lib > (remember, NetBSD has it in /usr/libexec !), and edit /usr/lib/ld.so > and replace all references to /usr into /sun. You can then have a > /sun/lib symlink point into your SunOS /usr/lib directory with the > SunOS shared libs. In the same go, also replace /etc by /sun, so > ld.so.cache doesn't collide. Of course, all this requires you to have a spare SunOS license lying around. I don't mind borrowing a prgram or two from my sun3 for testing purposes, but I don't want to have all the SunOS shared libraries permanently installed :-( -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 17:50:52 1993 From: David Crooke Sender: dcc@dcs.ed.ac.uk To: netbsd-amiga@cbmuucp.commodore.com From: David Crooke Subject: Install Note, US/Can mirror Sender: NetBSD-Admin@cbmuucp.commodore.com After incorporating suggestions, I have uploaded the note to ftp.eunet.ch as pub/NetBSD-Amiga/incoming/NetBSD.Install.714 Could someone move it up a directory if they deem it appropriate? I tested all the ftp sites I was aware of and listed the ones with reasonably up to date mirrors; one thing that concerns me is that we no longer seem to have an up to date mirror in North America, which is where most NetBSD-able Amigas are (lots of transatlantic traffic!). Would it be possible to persuade Aminet to carry a NetBSD mirror, or failing that, just a site in N.A. ? Dave David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 1408, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 5164 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 18:01:16 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Booting any 720 kernel Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 17, 10:24am, Alan Bair wrote: > Here is something I have noticed about the 720 kernels, either Markus W. > original or Myke S. new one. If I just go with the kernel as is, all I > get is a blue screen, nothing more. If I change ite_default_height to > 400 it boots just fine. I have not tried slowly increasing from 400 to > see if I can use a higher value like the 448 Myke has. I think that around 454 or so, the monitor selection code will pick a hires-PAL mode. Chris sent out a second set of changes to the cc console code that may have changed that - I haven't checked this out yet. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Fri Dec 17 23:18:56 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Shared library problems Sender: NetBSD-Admin@cbmuucp.commodore.com On Dec 16, 10:58pm, Markus Wild wrote: > > Is there any provision in NetBSD for a user level program to push the > > data and instruction caches? It looks like the shared library initialization > > is going to need something like this to work correctly. > > I think the hp300 port had/has a cachectl system call, that allows > such things (mainly to control the huge VAC on some hp300). We'll > probably need such a thing too? Unfortunately, that's an area I can't > test at all... The hp300 port does have a "system call" and that code is still in the Amiga port. It uses trap 12 and passes the arguments in D0, D1, D2. I was able to make a couple of patches (using binpatch) to ld.so to do the trap 12 in the library initialization routines and now seem to be able to run fine on the 68040 with all caches enabled. The patches effectively add a call to the cachectl routines in both the rtl() and binder_entry() routines. The cachectl call loads d0 with 0x80000004 [CC_EXTPURGE|CC_IPURGE] and does a trap 12. This does a push on the data cache and invalidates the instruction cache when running on a 68040. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From leland@wacky.acet.org Sat Dec 18 00:06:09 1993 Return-Path: Received: from wacky.acet.org.acet.org ([192.188.104.18]) by mwunix.mitre.org (5.65c/SMI-2.2) id AA23258; Fri, 17 Dec 1993 18:06:03 -0500 Received: by wacky.acet.org.acet.org (4.1/SMI-4.1) id AA00775; Fri, 17 Dec 93 18:03:26 EST Date: Fri, 17 Dec 93 18:03:26 EST From: leland@wacky.acet.org (Robert Leland - PSI) Message-Id: <9312172303.AA00775@wacky.acet.org.acet.org> To: hubert.feyrer@rrzc1.rz.uni-regensburg.de Subject: Re: Emacs-19.21 (w/ X11 support) Status: RO Hubert: When Emacs/X11 is started up it checks for the existance of the DISPLAY enviromental variable, if this is set or if the -display option is used it will open its own window independant of the xterm. I use emacs regularly both GNU and lucid emacs and haven't experienced this problem. It's only when I don't specify the display is when I get into problems. Hope this helps. -Rob From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 01:58:27 1993 From: mw@eunet.ch Subject: Re: Compiling w/ shlibs To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 746 Sender: NetBSD-Admin@cbmuucp.commodore.com > Problem: when compiling a program, gcc now stops with unresolved references > to __DYNAMIC. Something isn't set up right. What? Hm, check you're using the new ld and new /usr/lib/crt0.o. You should if you're using new binaries, but you never know.. > P.S. Don't rename /bin/sh to /bin/old.sh before installing the new > bin-bin.tar.gz. I did, and didn't realize that the new bin had no shell, > and rebooted. Using diskX to binary edit the BSD filesystem was most > educational :-) Yuck.. that's why I mentioned explicitly to this list before NOT to screw old /bin/sh... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 02:01:50 1993 From: mw@eunet.ch Subject: Re: Shared library problems To: tsarna@endicor.com (Ty Sarna) Cc: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 679 Sender: NetBSD-Admin@cbmuucp.commodore.com > Of course, all this requires you to have a spare SunOS license lying > around. I don't mind borrowing a prgram or two from my sun3 for testing > purposes, but I don't want to have all the SunOS shared libraries > permanently installed :-( This was not the point. You said you don't rate SunOS compatibility useful if it can only deal with static binaries. I just told you how to deal with dynamic libraries. Whether you want to spare the disk space to keep SunOS stuff or not, is a totally different thing ;-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 02:08:54 1993 From: mw@eunet.ch Subject: Re: Install Note, US/Can mirror To: David.Crooke@dcs.ed.ac.uk Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 381 Sender: NetBSD-Admin@cbmuucp.commodore.com > After incorporating suggestions, I have uploaded the note to > ftp.eunet.ch as pub/NetBSD-Amiga/incoming/NetBSD.Install.714 > > Could someone move it up a directory if they deem it appropriate? Done, thank you! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 06:23:53 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: Booting any 720 kernel To: NetBSD-Admin@cbmuucp.commodore.com (Michael L. Hitch) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I think that around 454 or so, the monitor selection code will pick a > hires-PAL mode. Chris sent out a second set of changes to the cc console > code that may have changed that - I haven't checked this out yet. Indeed this was one of the changes made now anything below 482 won't be PAL (unless you go real low and get PAL non-interlace) > Michael Chris. From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 09:29:41 1993 To: "NetBSD-Amiga" From: "Matthias Scheler" Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: IntuiNews 3.141592654 (Right Now) Subject: Re: NetBSD development mailing list. Organization: Amiga User Group University Paderborn Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Markus, > I second that. I get the feeling that many newbies (sorry newbies :) > that this mailinglist get crowded with 'how to install' and 'my A500/40 > does not work' questions (and answers). Not that this is bad, but this > maillinglist is by far the most-traffic list i ever read. Every idea > which could reduce the traffic gets my vote. Mine too ... (Because I've to poll all mails via modem which is still a pain because my uplink still hasn't activated batch smtp for me). -- Matthias Scheler tron@lyssa.pb.owl.de From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 11:35:16 1993 X-Mailer: AVM - V1.3.2 From: rudy@dorn.ruhr.de (Rudolf Neuhaus) To: netbsd-amiga@cbmuucp.commodore.com Subject: latest binaries & kernel Sender: NetBSD-Admin@cbmuucp.commodore.com I finally had some spare time to look into NetBSD again and noticed a few flaws when using the new binaries. The first problem was, that I was missing /bin/sh in the bin-bin file. There won't be a single user shell then, and there won't be a shell executing /etc/rc ;) So I made a link to bash. Now that works. Then there's no /bin/tar - it's /bin/Tar. No problem with that, but a different one. Just untaring with xzpf did not work because tar tries to use compress - not gzip. The new compress also needs shared libs, and cannot extract gziped archives. Otherwise everything ran fine (Standart A3000 with Retina). I'll try to install X this weekend ;) There is no Retina X server yet, is there? Thanks for your work, Rudy --- Rudolf Neuhaus home: ->rudy@dorn.ruhr.de 44137 Dortmund (FRG) work: rudy@iml.fhg.de Tel. +49(0) 231/134404 uni : uphd02@zx1.hrz.uni-dortmund.de From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 16:37:48 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Shared library problems Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <199312180049.BAA23304@eunet.ch> mw@eunet.ch writes: > > Of course, all this requires you to have a spare SunOS license lying > > around. I don't mind borrowing a prgram or two from my sun3 for testing > > This was not the point. You said you don't rate SunOS compatibility useful This _is_ the point. Any x can't be considered generally useful unless a goodly number of people have access to item y which it requires. :-) If something like PC-Task requires MS-DOS to run, great, you go buy a copy of MS-DOS. SunOS for the Sun3 isn't *nearly* as easy or inexpensive to obtain. Probably the easiest way to obtain one would be to buy a machine with SunOS -- of course, then what do you run on the Sun? (you want me to waste good hardware? :->) Now, maybe the SunOS license allows the shared libraries and ld.so to be run on more than one machine at the same time with only a single license, but I doubt it. Most folks don't even have a single license... > if it can only deal with static binaries. I just told you how to deal > with dynamic libraries. Whether you want to spare the disk space to keep > SunOS stuff or not, is a totally different thing ;-) I have the disk space, I have the libraries. I don't have a second license. I doubt most NetBSD/Amiga users will even get as far as the second. I'm not complaining, I thnik it's great that we have this feature even if only a few people can make use of it right now. What I'm saying is, "gee, wouldn't it be nice if we could make this feature work for more people?". It doesn't look like it would be very hard to cook up SunOS style versions of ld.so and libc.so, which would cover most uses. (hmm... we might need libdl too). -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 18:51:13 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Swap overallocation in i386 BSD's Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com I'm forwarding this from comp.os.386bsd.bugs, since it may be relevant to the 4M machine problem. It specified 386-based BSD systems, but they may be aware of the non-386 port, and it sounds like it might be a machine-indepedent thing to me. In article root@candle.uucp (Bruce Momjian) writes: > I am running BSD/386 from BSDI. When running with 5MB of RAM, I found > that the system locked up about once every week. In researching the > problem with Mike Karels of BSDI, I think we have found a bug that > exists on BSD/386 and most free 386-based *BSD systems. Here are the > details. > > First, let me define copy-on-write(COW): When a process forks, the OS > maps the address space of both the parent and child to the same memory > pages, and both process start running. If either process makes changes > to its shared memory pages, the OS makes a copy of the shared page. One > process gets the original, another gets the copy. > > Ok, here is the bug we have found: If a process forks a child, and the > parent writes to its memory pages (forcing a COW), and those pages are > paged out to swap before the child exec's or exits, the parent's and > child's swap space is not released until the parent exits. > > The ramifications of this is that if you have a long-running process > that forks a lot, like a shell, and your system does a lot of paging, > those long-running process will allocated more and more swap until they > exit. It is particularly a problem with non-csh shells (csh, uses > vfork and exec), because they often run scripts by forking themselves, > and the child running the script may exist for quite some time without > exec'ing or exit'ing. > > Here are Mike Karels more detailed words on the subject: > > --------------------------------------------------------------------------- > > ... The problem here is that if the process forks, and the parent modifies > data pages while the child exists, it must make copies of those pages > (copy-on-write after fork). If those copies are paged out, then both > the copies and the originals will occupy space until the parent exits, > even if the child exits. > > I think I described the chains of shadow objects that were accumulating, > and the fact that those are supposed to get coalesced. It turns out > that the code to coalesce does not work if an object has been paged out. > This is the scenario that causes problems: > > - a long-lived program forks repeatedly, > - the parent modifies data space before the child does exec or exit, > and > - the parent's modified pages get paged out before child does exec > or exit. > > The only situation in which this seems to be a problem is if a login > shell (or any long-running interactive shell) runs scripts by forking > and running them directly. This will not happen with csh; I don't > know about ksh or bash. (It does not happen with csh because it uses > vfork, and re-exec's itself if running a csh script). It also does > not happen if the scripts are "executable" scripts, i.e. those that start > with #!/bin/sh. It is also a problem only if the script or other system > activity uses enough memory for the shell to be paged out while the > script is running. > > The bad news is that this problem is not easy to solve... However, I > think there are some workarounds that can be used for the moment. > > --------------------------------------------------------------------------- > > My experience with 5MB of RAM and 20MB of swap running several screens > (no X, no networking) was that because I never logged out, my shell > accumulated swap space until it ran out. About every 7 days the system > had to be rebooted (everything had stopped running). > > I hope this helps explain some lockup problems some people may be > having. Has anyone solved this problem? I don't know the specifics of > why it is occurring, or why it is hard to solve, but if someone has > already solved it, I would love to hear about it. > > Attached is a program that illustrates the problem. With MAKE_CHILD > undefined, swap space is allocated the first time through the loop, and > stays pretty constant. With MAKE_CHILD defined, swap decreases rapidly > each time through the loop until the system runs out of swap space and > locks up. Note that each child is killed before the loop is restarted, > yet the swap space continues to decline rapidly. You will need to > define some things at the top before you compile, including your systems > program for monitoring swap space. > > --------------------------------------------------------------------------- > > > /* show swap overallocation bug in child processes */ > /* Bruce Momjian, root@candle.uucp */ > > /* tabs = 4 */ > > #include > #include > #include > #include > > #define MAKE_CHILD > > /* make this higher if you have more than 8 MB of RAM */ > #define SYSTEM_RAM 4 > > /* program to show remaining swap space, vmstat? */ > #define SHOWSWAP "swaptotal" > > int k = 1024; > > void main() > { > char *y; > int c_pid; > int j; > char *t; > > /* make my address space big */ > if ( (y=malloc(SYSTEM_RAM*k*k)) == NULL) > { > perror("Malloc"); > exit(1); > } > > while (1) > { > #ifdef MAKE_CHILD > if ((c_pid = fork()) == 0) > sleep(1000); > #endif > > /* parent touches memory to force COW copy */ > for (j=0,t=y; j < SYSTEM_RAM*k*k; j+=k) > { > *t = 'x'; > t += k; > } > > #ifdef MAKE_CHILD > kill(c_pid,SIGHUP); > #endif > > puts("done "); > system(SHOWSWAP); > } > /* NOT REACHED */ > } > > -- > Bruce Momjian | 830 Blythe Avenue > root%candle.uucp@bts.com | Drexel Hill, Pennsylvania 19026 > + If your life is a hard drive, | (215) 353-9879(w) > + Christ can be your backup. | (215) 853-3000(h) From NetBSD-Admin@cbmuucp.commodore.com Sat Dec 18 21:57:48 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: GCC 2.5.6 problems. Sender: NetBSD-Admin@cbmuucp.commodore.com I can't compile X for retina du to a bug is as in the gcc 2.5.6 distrib: I've got: GCC internal compiler error: as got fatal signal 6 any ideas ? lahaye_o@epita.fr From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 19 01:38:27 1993 From: mw@eunet.ch Subject: Re: GCC 2.5.6 problems. To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1335 Sender: NetBSD-Admin@cbmuucp.commodore.com > I can't compile X for retina du to a bug is as in the gcc 2.5.6 distrib: > > I've got: > > GCC internal compiler error: as got fatal signal 6 Hm.. could you try to generate assembly source, and run the assembler manually? That would perhaps lead you to the instruction that's causing the abort.. BTW: as for gcc-2.5.6. This was a VERY late addition to the distribution, I just felt I had to include the newest version of the compiler, more so since 2.4.5 really had code-generation flaws for m68k. However, I didn't recompile the system, so I failed to notice that the dreadful fix-includes script had generated a lot of bogus header files, that cause all sorts of problems. Here's the simple cure: remove everything in /usr/gnu/lib/gcc-lib/netbsdamiga/2.5.6/include *EXCEPT* the following (at least that's what I did after discovering the problem): total 50 -rw-r--r-- 1 root 10 495 Dec 8 19:26 README -rw-r--r-- 1 root 10 3719 Dec 8 22:08 float.h -rw-r--r-- 1 root 10 2922 Dec 8 19:26 limits.h -rw-r--r-- 1 root 10 9573 Dec 8 19:30 math-68881.h -rw-r--r-- 1 root 10 5394 Dec 8 19:25 math.h drwxr-xr-x 2 root 10 512 Dec 8 19:31 objc -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 19 05:08:03 1993 From: Alan Bair Subject: New rootfs_720.gz uploaded To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I have completed the new rootfs for the 720 release. I have uploaded the following files to the NetBSD-Amiga/incoming area on ftp.eunet.ch: rootfs_720.gz rootfs_720.readme One problem that I found that would be nice to fix, is to have a tar that makes use of gzip instead of uncompress. I noticed that in the new binaries, Markus W. had /bin/TAR and /sbin/Tar instead of tar. I made links from tar to each of these. They both static and appear to be identical. I'll try to build a new tar, but if someone already has one for NetBSD, please let me know. Merry Xmas and Happy New Year!!! Here is the rootfs_720.readme: ------------------------------------------------------------------------- 12/18/93 The accompaning rootfs_720.gz file is the new rootfs based on the 720 NetBSD release. To handle the increased program sizes and to leave some free space the rootfs has been increased from 8MB to 10MB, 20480 Blks. Use this increased size when following the installation instructions in the FAQ or written by David Crooke. I built this rootfs from scratch using the following items. The 720 release binaries uploaded by Markus Wild in the incoming directory. The latest /etc files from sun-lamp. Various files from the old rootfs, in particular the /dev, /var, /root, /lib & /kern directories. The original 720 kernel. In the process of setting up this rootfs, I also tried to incorporate the ideas suggested by various people on the mailing list. These included turning off networking and placing helpfull tools in the /usr in the rootfs. The tools in /usr should hopefully make it easier to install the rest of the NetBSD system. Look at the README.setup file in the rootfs for more details. The new /etc from sun-lamp made it much easier to turn off the networking. I also placed some *.EXAMPLE files in /etc to help get you started with the networking setup if you decide to try turning it back on. The main files you will have to edit are: myname, defaultdomain, hosts, netstart, gateways, resolv.config, hostname.* and exports. The one file you will want to edit, even if you don't use the networking setup, is the /etc/myname file. This file contains the name of your node, the default is "myname". The localtime file is linked to /usr/share/zoneinfo/US/Central, since that is the timezone I live in. The passwd file has been trimed and a non-root account, guest, has been setup for your use. The guest home directory is in /home on the rootfs. I hope this rootfs will make it easier for more people to use of the Amiga implemetation of NetBSD. Thanks to Markus Wild and all the other people that have worked on this project. Alan Bair abair@amcu-tx.sps.mot.com PS: If you find any problems or have suggestions for improving the rootfs setup, please let me know. ------------------------------------------------------------------------- -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From local@cbmuucp.commodore.com Sun Dec 19 12:00:18 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA06909; Sun, 19 Dec 93 05:55:53 EST Received: by cbmuucp.commodore.com (4.1/SMI-4.1) id AA13359; Sun, 19 Dec 93 05:55:33 EST Return-Path: Received: by cbmuucp.commodore.com (4.1/SMI-4.1) id AA13354; Sun, 19 Dec 93 05:55:32 EST Date: Sun, 19 Dec 93 05:55:32 EST From: local@cbmuucp.commodore.com (local account) Message-Id: <9312191055.AA13354@cbmuucp.commodore.com> To: netbsd@cbmuucp.commodore.com Subject: Test - please note LIST changes Sender: NetBSD-Admin@cbmuucp.commodore.com Status: RO The NetBSD-Amiga mailing list is being reorganized. Stay tuned for more information. From NetBSD-Admin@cbmuucp.commodore.com Sun Dec 19 12:45:12 1993 From: William J. Coldwell To: netbsd-amiga@cbmuucp.commodore.com Subject: ATTN: MAILING LIST CHANGES **READ OR DIE** Cc: netbsd@iceCuBE.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com The new list structure for NetBSD on the Amiga: NetBSD-Amiga - This is the main list that contains helpful information on installation and general questions about NetBSD on the Amiga. New kernel versions and binaries announcements will appear in this list. A Frequently Asked Questions will be posted bi-weekly to monthly. NetBSD-X - This is the list for installation and development specifically geared towards running X under NetBSD on the Amiga. NetBSD-Dev - This is the list for specifically for kernel hackers. How to get on (or off of) the lists: To: NetBSD-Request@cbmuucp.commodore.com Subject: SUBSCRIBE NETBSD Allow a couple of days for the transaction to occur. If after a few days nothing happens, then resend the request. Some acceptable subjects: SUBSCRIBE X - this will get you on the NetBSD-X list. UNSUBSCRIBE NETBSD-DEV - this will remove you from the NetBSD-Dev list. SUBSCRIBE - this will get you on the NetBSD-Amiga list (the default). Acceptable aliases: admin: netbsd-admin@cbmuucp.commodore.com netbsd-request@cbmuucp.commodore.com billc@iceCuBE.rain.com X list: netbsd-x@cbmuucp.commodore.com x@cbmuucp.commodore.com Dev list: netbsd-dev@cbmuucp.commodore.com dev@cbmuucp.commodore.com NetBSD list: netbsd-amiga@cbmuucp.commodore.com netbsd@cbmuucp.commodore.com Past postings: Past postings to any of the groups are not archived here. No official policy of archives has been established at this time. Generally, you can get old stuff by asking (not that it's worth anything, since there is a F.A.Q). Policy: Commodore Business Machines, Commodore International Limited, or any of it subsideraries neither cares, nor endorses this mailing list, the NetBSD project on the Amiga, or anything affiliated with this project (muchless even knows what NetBSD is, or what a mailing list is, for that matter). They are just nice enough to allocate some CPU and disk space for us, for which we are virtually grateful (just nod your head and smile, like when some is talking to you in a foreign language and you have no translator near). -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From brian@arc002.sci.fau.edu Tue Dec 21 07:46:44 1993 Received: by arc002.sci.fau.edu (5.57/Ultrix3.0-C) id AA13879; Tue, 21 Dec 93 01:45:18 -0500 Date: Tue, 21 Dec 93 01:45:18 -0500 From: brian@arc002.sci.fau.edu (Brian ???) Message-Id: <9312210645.AA13879@arc002.sci.fau.edu> To: hubert.feyrer@rrzc1.rz.uni-regensburg.de Subject: Re: your mail Status: RO I still cant get it too work. I have tried 709,714,and 721 kernels. they see my amigados 52 meg quantum then stop there, i do not get a bash, all my netbsd stuff is on my fuji drive. I am using the latest .tgz files and rootfs, loadbsd etc. I tried both with and without inhibit_sync. Could I try your kernel? That is if it will work for me, my fuji is in scsi6 and contains all my netbsd stuff, i have a 16 mhz 3000. i would just like to get a bash prompt! Do you think removing the jumper that i told you aboutm the one that when removed enables sync handshake between the host and the drive, do you think that would help? Brian From postmaster@cbmuucp.commodore.com Tue Dec 21 23:34:45 1993 From: William J. Coldwell To: netbsd@cbmuucp.commodore.com Subject: Duplicates & Ettiquette Cc: x@cbmuucp.commodore.com, dev@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com If you are getting duplicates of the same message _on the same list_ then you may have subscribed more than once. If this is the case, then you need to send me a nice little message stating to trace down the other copy of your name and to delete it.. do _not_ send an UNSUBSCRIBE message in the case, as I'll delete all of the occurances of your name. If you have a message that pertains to two or even all three of the lists, then you can crosspost it.. under the conditions that is _REALLY DOES_ apply to the lists (because generally when people respond, it will be CC:'ed to all lists because they didn't follow the next set of instructions). Watch your CC:!! Make sure that if you are sending a private response that you _don't_ include a list(s). Make sure that if the topic starts to lean specifically towards one list, that your reply is _ONLY_ on that list. Many people are subscribed to 2 or more lists here, so when you post, please use caution... otherwise you may be flame fried into a crisp. Thanks, Bill -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From postmaster@cbmuucp.commodore.com Wed Dec 22 05:37:16 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Dev@cbmuucp.commodore.com Subject: Problem with new ld Sender: postmaster@cbmuucp.commodore.com The new ld in the new binaries seems to have a problem with multiply defined symbols. I was trying to compile a program and had an extra file that I shouldn't have. The extra file defined some symbols that were already in other files. When using the new gcc/ld, the command would appear to complete, but no executable was generated and no error messages. I finally booted off another disk that still had the old binaries and found that there were multiply defined symbols. I booted back with the disk that had the new binaries, removed the extra file, and was able to create the executable OK. It looks like the new ld doesn't complain about multiply defined symbols, but also won't create the executable. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From postmaster@cbmuucp.commodore.com Wed Dec 22 07:48:46 1993 Subject: Logical abstraction of disk space allocation? To: netbsd-amiga@cbmuucp.uucp.commodore.com From: Frank "Crash" Edwards Organization: Edwards & Edwards Consulting, Palm Harbor, FL X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3071 Sender: postmaster@cbmuucp.commodore.com Well, now that there are multiple mailing lists for NetBSD, I'm not sure this is the right place for this... I've been using the IBM RS/6000 lately and I've come to respect the Logical Volume abstraction for allocation of disk space (other things cause no end of annoyance, but..) This message is to ask about the possibility of including state-of-the-art disk space management technology into NetBSD-Amiga. Basically, their "LVM" product (Logical Volume Manager) creates the idea of a virtual disk drive in which disk space need not be allocated contiguously. Since the "virtual drive" is really multiple drives, the space does not even need to be on a single drive. In addition, since the LVM is a layer between the /dev/hdxx software interface and the physical device drivers, filesystems can be extended dynamically *while the filesystem is mounted and in use*!! (Of course, shrinking them back again is a might bit more difficult :-) Mirroring can be done at this level also, in which case the LVM simply puts the disk buffer into two device driver queues instead of one. Using IBM terminology (ugh!), multiple "physical volumes", ie. disk drives, are organized together into "volume groups". All allocations take place within a volume group so a filesystem can't be larger than a VG. The VG is a software entity and does not need to be on a single SCSI adapter or whatever. Each PV is broken down into chunks of a given size (usually 4MB on the rs6k) and this size becomes the minimum unit of allocation. For instance, the default installation of the rs6k creates a single VG, "rootvg". The required filesystems are put into this VG: / (root), /usr, /tmp, /var, and /home. Paging space and the dump device are also allocated at install time, but don't have filesystems on them as the others do. The above scenario would result in an entry in /dev for each logical volume: Device Name: Filesystem Used For: /dev/hd1 /usr /dev/hd2 /tmp /dev/hd3 /home /dev/hd4 / /dev/hd5 /blv (used only to hold the boot image stuff) /dev/hd6 paging space /dev/hd7 dumpdev /dev/hd8 logdev (for journalled filesystems) /dev/hdisk0 access to raw disk drive : : This scheme works fairly well. FSCK and friends can still access /dev/whatever to do their job, the mount command still uses the same syntax, etc. But when the system gets low on space in a given filesystem, it can be dynamically extended by grabbing space from the part of the VG that hasn't been allocated yet. So the ideal strategy is to not allocate space unless you need it. That way there will be unallocated chunks that can be used later as needed. Anyway, this is the software that the OSF has adopted. It provides a good layer of insulation from the hassles of disk space management and filesystem quirkiness. -- Frank "Crash" Edwards Edwards & Edwards Consulting Voice: 813/786-3675 Unix/AIX & OS/2: Training, Programming, and SysAdmin Data: 813/787-3675 crash@azhrei.EEC.COM "You can't have everything. Where would you put it?" -- Steven Wright From postmaster@cbmuucp.commodore.com Wed Dec 22 12:35:44 1993 From: olivier raoul To: netbsd-amiga@cbmuucp.commodore.com Subject: 720 and GRFON Sender: postmaster@cbmuucp.commodore.com GRFON on 720 produce a black screen in any case. There is no effect when you it on the video buffer. So the best way to have X on 720 is to suppress GRFON... In such case you have the console on the screen like the sun :-)) And the cursor is on overlay plane. From postmaster@cbmuucp.commodore.com Wed Dec 22 12:41:41 1993 From: olivier raoul To: netbsd-amiga@cbmuucp.commodore.com Subject: X and shared libs..... Sender: postmaster@cbmuucp.commodore.com The sharelibs don't work in the following case: prog.c extern char string[]; main(){ printf("%s\n",string); } lib.c char string[]="123456"; ---------------- ---------------- gcc -c lib.c -fpic warning size <-1.... ld -B........... gcc prog.c -o prog /usr/lib/libtoto.so.1.1 both case: 1- string is undefined 2- string is defined but it bad (if you speficie the size of string the prog work...) Xt use a lot of these arrays to share strings (XtN..) i don't no why gcc don't generate the correct size. From postmaster@cbmuucp.commodore.com Wed Dec 22 15:32:49 1993 From: niklas@appli.se (Niklas Hallqvist) To: raoul_o@epita.fr Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: X and shared libs..... Sender: postmaster@cbmuucp.commodore.com >>>>> "olivier" == olivier raoul writes: olivier> i don't no why gcc don't generate the correct size. Exactly this problem was fixed for svr4 configurations (and m88k and i386-osfrose) Oct 20 1993 and was one of the last things done before 2.5.0 came out. I know because I discovered it compiling libXt with the FSF-compiler (I'm a co-developer of GCC, mostly working on G++). What needs to be done is to supply an ASM_FINISH_DECLARE_OBJECT which emits a size directive. I belive MTK will know what to do... Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From postmaster@cbmuucp.commodore.com Wed Dec 22 16:25:53 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Documentation on ftp.eunet.ch From: Guenther Grau Sender: postmaster@cbmuucp.commodore.com Hi all, I wanted to announce a new form of documentation on ftp.eunet.ch. I decided to break up the FAQ into several parts that all live in NetBSD-Amiga/DOCS. It is still in incoming, but I expect mtk to move it into the main directory. I asked him to remove some of the old documentation and to move rest of the documentation into DOCS. The FAQ is still kind of out of date, but this will change hopefully after xmas. I will remove all the parts covered by seperated documents. This will help to keep it up-to-date. I also introduced some new documentation. The most important are projects and wish-list. projects contains a list of projects people currently are working on. It contains all the projects I am aware of, but this does not mean, that it is complete. To make it complete and up-to-date, ***** PLEASE ****** send the current maintainer of these files (which is s_grau@ira.uka.de at the moment) any wishes or any information about the projects you are working on. This helps to avoid two people working on the same thing without knowing form each others efforts. On the other hand we know, what people are working on and don't think we simply have to wait until its ready. This is some sort of software-management. For the files of length NULL, please feel free to contact me (s_grau@ira.uka.de) if you want to write some of these. Guenther P.S.: Merry Xmas to all of you :-) From postmaster@cbmuucp.commodore.com Wed Dec 22 16:43:51 1993 Subject: Running out of swap From: David Jones To: NetBSD-Dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com What is supposed to happen on a VM-based Unixoid system when it runs out of swap space? I thought of two possibilities: - The process sleeps waiting for a free swap page - The process is sent a SIGSEGV, killing it The above presumes that brk() (if used at all) does not return an error simply because there is not enough swap to cover the requested memory area. After all, the process could be using sparse memory addressing which would not require the entire area to be backed. Well, I tried it out on NetBSD. And.... :-) vm_fault(98000,1704000,3,0) -> 1 type 8, code [mmu,ssw]:401070d and an ensuing panic. I have saved the core image (8M of it!) if anyone is interested in doing the autopsy. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From postmaster@cbmuucp.commodore.com Wed Dec 22 17:03:45 1993 From: mw@eunet.ch Subject: Re: 720 and GRFON To: raoul_o@epita.fr (olivier raoul) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 476 Sender: postmaster@cbmuucp.commodore.com > GRFON on 720 produce a black screen in any case. There is no effect when you it > on the video buffer. So the best way to have X on 720 is to suppress GRFON... > In such case you have the console on the screen like the sun :-)) > And the cursor is on overlay plane. Sounds like a good first approach to me. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Wed Dec 22 17:38:01 1993 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: 720 and GRFON Sender: postmaster@cbmuucp.commodore.com On Dec 22, 12:28pm, olivier raoul wrote: > GRFON on 720 produce a black screen in any case. There is no effect when you it > on the video buffer. So the best way to have X on 720 is to suppress GRFON... > In such case you have the console on the screen like the sun :-)) > And the cursor is on overlay plane. Chris Hopps posted a set of patches that fix the problem. What was happening is that GRFON shuts off the console, which removes the display. The GRFON didn't re-enable the display, so the screeen remained blank. The console patches will enable the display when you do a GRFON. [I think the vmunix.mykes.tgz kernel includes these patches so that you can run X.] I've got both sets of patches that Cris posted and am able to run the X11R5 server with no problems. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From postmaster@cbmuucp.commodore.com Wed Dec 22 18:06:04 1993 From: olivier lahaye To: netbsd-amiga@cbmuucp.commodore.com Subject: X on Retina works Sender: postmaster@cbmuucp.commodore.com It's done, the server is here. Actually, 1024x768x8 at 80Hx refresh rate. Soon It'll accept retina define monitor. After, I'll rewrite retina define monitor for NetBSD. It's very slow as it's written in C language and there's no 68K code. (we had to remove 68k code as it wasn't designed to manage banked operations :-( ) but later, I'll have a look a t it. I'll ask phb to upload it soon (january the 3rd when I'll be back). lahaye_o@epita.fr raoul_o@epita.fr From postmaster@cbmuucp.commodore.com Wed Dec 22 18:44:13 1993 From: Philippe BRAND Subject: Re: X on Retina works To: lahaye_o@epita.fr (olivier lahaye) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Organization: Telesystemes/Symedia Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 586 Sender: postmaster@cbmuucp.commodore.com olivier lahaye writes: About X-Retina: > I'll ask phb to upload it soon (january the 3rd when I'll be back). I take some hollidays at home but I will be able to upload it before next year. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: phb@colombo.telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From postmaster@cbmuucp.commodore.com Wed Dec 22 18:47:54 1993 From: olivier lahaye To: netbsd-x@cbmuucp.commodore.com Subject: X on Retina works Sender: postmaster@cbmuucp.commodore.com It's done, the server is here. Actually, 1024x768x8 at 80Hx refresh rate. Soon It'll accept retina define monitor. After, I'll rewrite retina define monitor for NetBSD. It's very slow as it's written in C language and there's no 68K code. (we had to remove 68k code as it wasn't designed to manage banked operations :-( ) but later, I'll have a look a t it. I'll ask phb to upload it soon (january the 3rd when I'll be back). lahaye_o@epita.fr raoul_o@epita.fr From postmaster@cbmuucp.commodore.com Wed Dec 22 18:54:55 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "Serial mice and X" (Dec 21, 2:57pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Russel Miranda , NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Serial mice and X Sender: postmaster@cbmuucp.commodore.com On Dec 21, 2:57pm, Russel Miranda wrote: > Subject: Serial mice and X > Has anyone considered doing a /dev/mouse that would work with a serial > mouse? Sure, we have Amiga mice, but a 3 button serial mouse from the > local junk PC dealer is nice and cheap, and I'm pretty sure X wouldn't > care at all! It adds tons of flexibility, and it sounds like a pretty > easy driver to do. Do you have the protocoll ? I have no idea how to get it, and i have no intention to look at x86 code ... The idea is not bad, but i fear it is not that important and will take a while. > And if anyone ever writes a driver for the IOextender (or any other > serial port expansion board), it will be quite useful! It will, sure. Without that, i couldnt run my modem and the serial mouse at the same time, eh? While were at it, a small hint (may be too late): H&W in Germany has some original 3 button pregnant Amix mice left. -- Markus Illenseer From postmaster@cbmuucp.commodore.com Wed Dec 22 19:09:58 1993 From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) "X on 721" (Dec 21, 4:16pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: David Jones , NetBSD-X@cbmuucp.commodore.com Subject: Re: X on 721 Sender: postmaster@cbmuucp.commodore.com On Dec 21, 4:16pm, David Jones wrote: > size 64000 > console: Error 20, errno 1: Operation not permitted > > waiting for X server to shut down Looks like xinit was unable to start Xbsd (or even to find it). Have you implied all the needed tricks/hints/clues ? I mean the /tmp/.X11-unix and the /usr/bin/X11/X softlinks ? -- Markus Illenseer From postmaster@cbmuucp.commodore.com Wed Dec 22 23:05:02 1993 From: mw@eunet.ch Subject: Re: X and shared libs..... To: raoul_o@epita.fr (olivier raoul) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1554 Sender: postmaster@cbmuucp.commodore.com > The sharelibs don't work in the following case: > > prog.c > > extern char string[]; > main(){ printf("%s\n",string); } > > lib.c > > char string[]="123456"; > > ---------------- > ---------------- > > gcc -c lib.c -fpic > warning size <-1.... I tried to fix this according to the hint Niklas Hallqvist gave, but then I discovered - quite puzzled.. - that my copy of gcc didn't exhibit the problems you're describing. I tried to reproduce your case, but with my gcc (2.5.6, the one distributed in the new binaries) I didn't get any warning (which came from as, btw), and the resulting library linked fine with prog.c, creating a working executable. The only case I could imagine that you're having troubles with gcc is, if you should be using an old version of gcc that still produces SunOS style PIC without .size directives. I now built 2.5.7 with the patch Niklas suggested, but I wasn't able to reproduce a change in behavior. Furthermore, I got the impression from trying to understand what the patch does, that it only plays some role in error-recovery (at least it references an error node...). So, any definite answers to this problem? I'll wait installing the new 2.5.7 gcc so I can still verify whether the problem really exists with the 2.5.6 gcc I distributed, if someone can come up with an example that exhibits the problem. The above example worked fine for me. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Thu Dec 23 01:32:06 1993 From: niklas@appli.se (Niklas Hallqvist) To: mw@eunet.ch Cc: raoul_o@epita.fr, netbsd-amiga@cbmuucp.commodore.com Subject: Re: X and shared libs..... Sender: postmaster@cbmuucp.commodore.com >>>>> "MTK" == mw writes: MTK> I now built 2.5.7 with the patch Niklas suggested, but I wasn't MTK> able to reproduce a change in behavior. Furthermore, I got the MTK> impression from trying to understand what the patch does, that it MTK> only plays some role in error-recovery (at least it references an MTK> error node...). Hmm, did I suggest a specific patch? Or did you look at the config/svr4.h macro: /* Output the size directive for a decl in rest_of_decl_compilation in the case where we did not do so before the initializer. Once we find the error_mark_node, we know that the value of size_directive_output was set by ASM_DECLARE_OBJECT_NAME when it was run for the same decl. */ #define ASM_FINISH_DECLARE_OBJECT(FILE, DECL, TOP_LEVEL, AT_END) \ do { \ char *name = XSTR (XEXP (DECL_RTL (DECL), 0), 0); \ if (!flag_inhibit_size_directive && DECL_SIZE (DECL) \ && ! AT_END && TOP_LEVEL \ && DECL_INITIAL (DECL) == error_mark_node \ && !size_directive_output) \ { \ fprintf (FILE, "\t%s\t ", SIZE_ASM_OP); \ assemble_name (FILE, name); \ fprintf (FILE, ",%d\n", int_size_in_bytes (TREE_TYPE (DECL))); \ } \ } while (0) I must say, the comment confuses me, but I *know* the reason for this macro. The error_mark_node is probably just a flag value in this case. Pre 2.5 gcc parsed full initializers before emitting any code. In those versions the size of initializers were known before the emitting. When RMS put his pet in, this size couldn't be calculated until after the emitting phase (at least for char x[] = {...} type of decls). Most architectures don't care about the size directive (well, maybe debuggers do) but some shared-lib implementations do, notably SVR4. Hey MTK, aren't you on GCC2 list anymore? I think you used to be, wasn't it so? Well, I haven't looked a bit at the NetBSD gcc port, certainly not as, ld and ld.so, so I don't know if anything here applies. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From postmaster@cbmuucp.commodore.com Thu Dec 23 05:25:18 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Help! From: "John Reddersen" Sender: postmaster@cbmuucp.commodore.com I decided that while on break I would try and get NetBSD installed on my A3000 Tower, and everything seemed to install ok. I got the new rootfs installed, set up a swap and a usr partition (that's all for now), and got the new loadbsd.720 (I think) and both vmunix.720 and vmunix.721. The problem is that when I do a loadbsd vmunix.720 or 721 all I get is a blank gray screen! My A3000T has a 210Meg Quantum PD210S at scsi id 6, 12 meg fast and 2 meg chip. I binpatched both vmunix's to change the screen size to 640x400 (I figured I'd see what the best size was later) and as far as I understand, I don't need to do the inhibit_sync thing anymore right? It doesn't seem to read from the drive for more than an instant when I do the loadbsd, then it just sits there until I reboot it. Any ideas? Thanks! (I did have it running before once with the 613 kernel, but needed the diskspace...) --- .-------------------------.---------------------------------------------. | John Reddersen | Work: Durham 138 Helproom (515) 294-1314 | | jredders@iastate.edu | Home: Friley, 3393 Knapp (515) 296-3996 | | ///\ . .. _ . | "If at first you don't succeed, so much | | \X//--\|V||(_,/-\ | for skydiving!" - unknown author | `-------------------------^---------------------------------------------' From postmaster@cbmuucp.commodore.com Thu Dec 23 05:59:41 1993 X-Authentication-Warning: maelstrom.berkeley.edu: mehlhaff owned process doing -bs To: "John Reddersen" Cc: netbsd-amiga@cbmuucp.commodore.com, mehlhaff@ocf.Berkeley.EDU Subject: Re: Help! of Wed, 22 Dec 1993 22:18:52 -0600 <9312230418.AA07509@iastate.edu> From: "'Evil' ERic Mehlhaff" Sender: postmaster@cbmuucp.commodore.com "John Reddersen" recently wrote: >I decided that while on break I would try and get NetBSD installed on my A3000 >Tower, and everything seemed to install ok. I got the new rootfs installed, >set up a swap and a usr partition (that's all for now), and got the new >loadbsd.720 (I think) and both vmunix.720 and vmunix.721. The problem is that >when I do a loadbsd vmunix.720 or 721 all I get is a blank gray screen! I suggest you double-check your version of loadbsd. I had a similar problem, and it was solved by grabbing loadbsd from ftp.eunet over again. Eric mehlhaff, mehlhaff@ocf.berkeley.edu From postmaster@cbmuucp.commodore.com Thu Dec 23 11:07:25 1993 From: olivier raoul To: mw@eunet.ch, raoul_o@epita.fr Subject: Re: X and shared libs..... Cc: netbsd-amiga@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com Sorry mw, this example works (the only one!!!) this example is bugged lib.c char string[]={'a','b'}; i hope that the patch work..... (I will go to do some ski, and i will come back on 4 janury 1994). From postmaster@cbmuucp.commodore.com Thu Dec 23 11:48:01 1993 From: wunderling@sc.ZIB-Berlin.DE (Roland Wunderling) To: netbsd-amiga@cbmuucp.commodore.com Subject: yet another HELP mail Sender: postmaster@cbmuucp.commodore.com Hello NetBSD-Amiga, last night I tried to install NetBSD and ran into problems :-( (Oh, you guessed that?! :-) ) I tried with loadbsd.720, rootfs_720 and both vmunix.720 and vmunix.721 I binpatched them to _scsi_no_dma -r 1, since I own an old GVP Impact 3001 with 4MB and a seperate GVP Series II controler. Further, I tried both setups for _inhibit_sync. And here is what I get: AMIGA2000 MC 68030 CPU+MMU, 25MHz MC68882 FPU real mem = 4194304 avail mem = 1720320 using 51 buffers containing 417792 bytes of memory 2 Amiga memory segments segment 0 at 00200000 size 00400000 segment 1 at 00000000 size 00100000 ZorroII memory at 00000000-00000000 Realtime clock A2000 rtclock0 [1/9] par0 [1/6] grf0: 688x448 4 color custom chips display grf0 [1/7] ser0 [1/3] dma0: GVPII DMA scsi0: scsi id 7 GVPIIscsi0 [2017/11] (*) scsi0: target 6 now synchronous, period=256ns, offset=8 sd6: QUANTUM LP240S GM240S01X rev, 479350 512 byte blocks sd6 at GVPIIscsi0, slave 6 Changing root device to sd6a bpf: sl0 attached bpf: ppp0 attached bpf: lo0 attached panic: cannot mount root hit any key to boot/dump... > Of course line (*) does not appear if I binpatch _inhibit_sync. There is some weirdness about my installation of rootfs: FaaastPrep and dcp are telling me, that my harddisk would have 4 heads and 66 blocks/cylinder, yielding 264 blocks per track. This corresponds to the "partition drive" option of HDToolBox, where I need 94 block for a 12 MB BSDR-partition (I want to live in future :-) ). On the other hand, HDToolBox did not show any drive, when selecting "Change Drive Type". Hence, I decided to try "New Drive Type" (instead of "Edit Old Drive Type") and selected "read Drive configuration". This "read": 1 head at 174 blocks/cylinder. Anyhow, I tried to filetodev with both drive geometries 174 and 264 --- without success. So, if anybody want's me to live a happy xmas --- please help me! :-) Roland From postmaster@cbmuucp.commodore.com Thu Dec 23 13:02:03 1993 From: mw@eunet.ch Subject: Re: X and shared libs..... To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, raoul_o@epita.fr, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1554 Sender: postmaster@cbmuucp.commodore.com > Hmm, did I suggest a specific patch? Or did you look at the config/svr4.h > macro: Exactly :-) > I must say, the comment confuses me, but I *know* the reason for this > macro. The error_mark_node is probably just a flag value in this case. > Pre 2.5 gcc parsed full initializers before emitting any code. > In those versions the size of initializers were known before the emitting. > When RMS put his pet in, this size couldn't be calculated until after > the emitting phase (at least for char x[] = {...} type of decls). Well, the example given to exhibit the bug, didn't.. I then saw some construct that caused a .size of -1, and that was (from memory): static char *foo[] = { "bleh", "blah", "gargel", }; However, both versions, old and "fixed" gcc, did a .size -1 on this construct. > Most architectures don't care about the size directive (well, maybe > debuggers do) but some shared-lib implementations do, notably SVR4. NetBSD does, too. In fact, "our" shared libraries are much more like SVR4 shared libs than like SunOS. I felt like dejavu when I did the netbsd gcc, somehow I did almost the same thing months ago for Amiga Unix already :-) > Hey MTK, aren't you on GCC2 list anymore? I think you used to be, Hmm.. I definitely was.. looks like I "vanished", but frankly, I'm quite happy this way, I already get ways too much mail without being on the gcc2 list... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Thu Dec 23 19:42:49 1993 From: William J. Coldwell To: netbsd@cbmuucp.commodore.com Subject: BFFS 1.3!! (FWD: Call for a few Beta testers) Sender: postmaster@cbmuucp.commodore.com The magnificent Chris Hooper scribbled: > I am planning on releasing BFFS 1.3 on December 31, > 1993. I am looking for (a few) beta testers to try > out the filesystem before the release date. > > For those who do not know, BFFS 1.3 is an AmigaDOS > device handler which can read and write UNIX BSD 4.2 > filesystems directly. This distribution of BFFS > is the first read/write version which also includes > a number of updated and new filesystem tools. > > Anyone interested, please email me by December 26th. > Send your mail to cdh@mtu.edu Please note that I plan > on limiting the testing to about five testers, so > those that get back to me quickest "win." If I can > call it that. ;) > > Thank-you. > > - Chris Hooper > cdh@mtu.edu No Chris... thank _you_. ;-) -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From postmaster@cbmuucp.commodore.com Thu Dec 23 20:34:47 1993 From: Dave R. Madsen Subject: x11r5 lib problem To: netbsd-amiga@cbmuucp.commodore.com Cc: madsen@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: postmaster@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com Hello all. I have installed the entire x11r5 package from ftp.eunet.ch as well as the latest binary distributions, but I seem to be unable to successfully build my own X clients with the r5 libraries. I have no problem using the clients that came with the r5 distribution, but any clients I build myself exit with the error: Error: Can't open display: :0.0 I have tried switching over to the r4 libs, and the clients I build seem to work fine then, but I would like to build them with the r5 libraries (and some clients require r5). Does anyone have any suggestions as to what may be wrong with my setup? Dave -- Dave R. Madsen | Computer Science Department | Office: 107 Atanasoff Systems Support Group | Iowa State University | twisted@iastate.edu Project Vincent WGA | Ames, Iowa | madsen@cs.iastate.edu From postmaster@cbmuucp.commodore.com Thu Dec 23 22:49:56 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-amiga@cbmuucp.commodore.com Subject: X11R5-bin.tar.gz is that contain the smaller tar files Sender: postmaster@cbmuucp.commodore.com On ftp.eunet.ch there is a file that is 13 megs its called sometihng like X11R5-bin.tar.gz. Then right below it there are about 6 other X11R5 files are those files what makes up the larger 13 meg file. I would much rather download the smaller files one at a time. because I keep having problems ftping the larger files. Could someone please help.. Thanks. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From postmaster@cbmuucp.commodore.com Fri Dec 24 01:51:58 1993 From: Arthur Hoffmann Subject: segmentation faults using SED. To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 245 Sender: postmaster@cbmuucp.commodore.com Hi. Ever since I installed the new binaries I have problems with sed. It coredumps on signal 11 segmentation fault all the time. Does anyone know what the problem might be? Thanks. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From postmaster@cbmuucp.commodore.com Fri Dec 24 04:04:53 1993 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd@cbmuucp.commodore.com Subject: hd ctrlrs Sender: postmaster@cbmuucp.commodore.com Well, i can't find a a2091,so what is my best choice the Serie II from GVP or their new A4008 because i really want to run Unix. Second question, is some work done already on the IDE drives? Thanks, Michel Beausejour P.S if i use the controllers from GVP am i going to experience the problem of loosing data on the serial port at high baud rates? From postmaster@cbmuucp.commodore.com Fri Dec 24 05:21:33 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Problem fixed and some other stuff... From: "John Reddersen" Sender: postmaster@cbmuucp.commodore.com Well, it seems that my problem with booting NetBSD on my A3000T was that it didn't have any cards, so that little bug in loadbsd caught me. Dave Madsen was nice enough to send me the version he compiled with the patches applied. This should be uploaded to ftp.eunet.ch since it works with cards too (right?). Even with the new loadbsd though, I still can't get Mykes vmunix.721 to boot. It still just gives a gray screen... Here's a few helpful hints for those installing the new rootfs: I copied the gzip from the /usr/bin in the new rootfs to /bin and then made links to it called compress and uncompress (also in /bin). After doing this tar xzvfp works fine to uncompress the other files, since the /usr in the rootfs gets hidden when you mount your usr partition... Having all three in the /usr/bin directory is a bit of a wast since the one gzip can do all of them if linked properly. Also, why are both more and less in the /bin directory the same thing: less? Does anyone know why the mini termcap thing in the new rootfs doesn't work with vi? One last thing, could someone who knows list all the binpatchable options for the latest kernel? I don't have the diskspace to build my own kernel, but I'd like to be able to play with whatever settings I can :-) --- .-------------------------.---------------------------------------------. | John Reddersen | Work: Durham 138 Helproom (515) 294-1314 | | jredders@iastate.edu | Home: Friley, 3393 Knapp (515) 296-3996 | | ///\ . .. _ . | "If at first you don't succeed, so much | | \X//--\|V||(_,/-\ | for skydiving!" - unknown author | `-------------------------^---------------------------------------------' From postmaster@cbmuucp.commodore.com Fri Dec 24 07:32:39 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Weird problem gets weirder. To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: postmaster@cbmuucp.commodore.com Hello fellow kernel hackers, Well if you are unfamiliar with my troubles I will relate them to you: I have had problems with certain prgrams, `gas' and `emacs' to name a few, what the problems are are hard to describe but take my word they look like intermitent memory trashing problems--even more so like stack but I can't be sure on this one. Happy news is I have discovered a way to remove them, I boot without my 16 bit ram. Isn't that nice :^) Nice and nasty is about all. So I am reporting to you that for some reason the kernel or user programs (my intuition leans more towards the kernel) Is messing up somehow with 16 bit ram. My system is odd becuase I have 4M of 32 bit at 0x200000 and then 2M of 16 bit at 0x600000 and another 2M at 0x800000. I can run mergemem to make them look like a single large contiguous chunk or not and then netbsd uses the first 4M of 32 bit only. My first and best guess doesn't appear to be correct, I thought maybe the ram was being used for the kernel *and* for GVP bounce buffers but my kernel had use_z2_mem set to zero, so thats not what was happening. I have: 4M on GVP 030/22 2M on GVP series I 2M on supra ram card. 1M chip. ECS chipset A2000. Its not as very important to me now to get them fixed as I can now buy some more GVP ram and continue to develop for NetBSD. It should probably get loked into though. Any quick guesses? Chris. From postmaster@cbmuucp.commodore.com Fri Dec 24 18:20:02 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-x@cbmuucp.commodore.com Subject: X working on my system. It just freezes! Sender: postmaster@cbmuucp.commodore.com I have finally gotten all the binarys for X11R5 and unpacked them into home/X11R5 the following directorys exists: bin lib and contrib. Also, I have the following softlink setup: in /usr/bin/ X@ -> /home/X11R5/bin. Now when I type xinit or startx it justs reads from disk and freezes I can then hit ctrl c and break out (this is under vmunix720.) If I switch to vmunix.721 it will just lock on boot up. Could someone tell me what I'm missing. Also I am running a Gvp 030/40mhz G-force. I recall some mention of turning DMA on or off but have no idea what is needed... And In the readme for mykes.vmunix it mentions something about clues/setups ect. And some /tmp/.v-unix file... Is there a readme file floating around telling how to install this program? Thanks. From postmaster@cbmuucp.commodore.com Fri Dec 24 19:22:30 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-amiga@cbmuucp.commodore.com Subject: Unknown user -g when ever I tried to make?! Sender: postmaster@cbmuucp.commodore.com It seems that I always get this error when Ever I try to make up man or whatever needs a makefile. For example I'm trying to install the X11R5 man and when I type make it kicks out with a warning. install -g unknown user. When I edit the Makefile to see what's gooing on, it has -g ${BINGRP} also there's another ${BINOWN} how do you set these variables so the system won't kick out with a warning when using make? Thanks From postmaster@cbmuucp.commodore.com Fri Dec 24 19:51:17 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: mfs, anyone? To: netbsd@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3230 Sender: postmaster@cbmuucp.commodore.com I was recently looking at the output of df and noticed that /tmp was gone. I tried mounting it by hand. It seemded to work. I got the standard warning: Warning: calculated sectors per cylinder (693) disagrees with disk label (690) I then tried 'ktrace -i /sbin/mount_mfs /dev/sd0b /tmp', and here's what happened: 76 ktrace RET ktrace 0 76 ktrace CALL execve(0xefffbbe,0xefffb6c,0xefffb7c) 76 ktrace NAMI "/sbin/mount_mfs" 76 newfs RET execve JUSTRETURN 76 newfs CALL open(0xefffbcc,0,0x4) 76 newfs NAMI "/dev/sd0b" 76 newfs RET open 4 76 newfs CALL fstat(0x4,0xefffb04) 76 newfs RET fstat 0 76 newfs CALL ioctl(0x4,0x42946465 ,0xe75e) 76 newfs RET ioctl 0 76 newfs CALL write(0x2,0xefff02c,0x4f) 76 newfs GIO fd 2 wrote 79 bytes "Warning: calculated sectors per cylinder (693) disagrees with disk la\ bel (690) " 76 newfs RET write 79/0x4f 76 newfs CALL gettimeofday(0xefff664,0) 76 newfs RET gettimeofday 0 76 newfs CALL getpid 76 newfs RET getpid 76/0x4c 76 newfs CALL sigaction(0x1e,0xefff65c,0xefff650) 76 newfs RET sigaction 0 76 newfs CALL fork 77 newfs RET fork 76/0x4c 77 newfs CALL break(0x17aa8) 77 newfs RET break 0 77 newfs CALL getpagesize 77 newfs RET getpagesize 8192/0x2000 77 newfs CALL break(0x18000) 77 newfs RET break 0 77 newfs CALL getrlimit(0x2,0xefff664) 77 newfs RET getrlimit 0 77 newfs CALL setrlimit(0x2,0xefff664) 77 newfs RET setrlimit 0 77 newfs CALL break(0x1ffe000) 77 newfs RET break 0 76 newfs RET fork 77/0x4d 77 newfs CALL break(0x2000000) 77 newfs RET break 0 76 newfs CALL wait4(0x4d,0xefff6bc,0,0) 77 newfs CALL kill(0x4c,0x1e) 76 newfs PSIG SIGUSR1 caught handler=0x602c mask=0x0 code=0x0 77 newfs RET kill 0 77 newfs CALL setsid 77 newfs RET setsid 77/0x4d 77 newfs CALL close(0) 77 newfs RET close 0 77 newfs CALL close(0x1) 77 newfs RET close 0 77 newfs CALL close(0x2) 77 newfs RET close 0 77 newfs CALL chdir(0x3bcf) 77 newfs NAMI "/" 77 newfs RET chdir 0 77 newfs CALL close(0x4) 77 newfs RET close 0 77 newfs CALL getpid 77 newfs RET getpid 77/0x4d 77 newfs CALL mount(0x3,0xefffbd6,0,0xefff6f8) 77 newfs NAMI "/tmp" 77 newfs RET mount -1 errno 19 Operation not supported by device 77 newfs CALL write(0x2,0xefff00c,0xb) 77 newfs RET write -1 errno 9 Bad file descriptor 77 newfs CALL write(0x2,0xe593,0x1) 77 newfs RET write -1 errno 9 Bad file descriptor 77 newfs CALL exit(0x1) 76 newfs RET wait4 RESTART 76 newfs CALL exit(0) I'm running a customized 720 kernel plus some patches. Any ideas? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From postmaster@cbmuucp.commodore.com Sat Dec 25 00:02:41 1993 From: NetBSD Administrator To: chopps@emunix.emich.edu, postmaster@cbmuucp.commodore.com Subject: Re: X11R5-bin.tar.gz is that contain the smaller tar files Cc: netbsd-x@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com CC: netbsd-x@cbmuucp.commodore.com Watch the headers please. Originally from Chris Hopps (master of the display): > On ftp.eunet.ch there is a file that is 13 megs its called sometihng > like X11R5-bin.tar.gz. Then right below it there are about 6 other X11R5 files You need them *aaallll* muhahahah :^) really though the 13 meg file is the GNU software like groff (text formater for man pages) and emacs and GNU gcc the compiler. Chris. From postmaster@cbmuucp.commodore.com Sat Dec 25 01:36:59 1993 From: kxs5829@ultb.isc.rit.edu (K.X. Saunders) Subject: trying to get X11R5 to work To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 657 Sender: postmaster@cbmuucp.commodore.com I just installed the 720 build of everything. I couldn't get the 720 kernel to boot again after the first successful try. The one time it did work, it had that squished font problem from way back when, but each character was multi-colored. However, the 721 build from Mykes worked like a champ. I downloaded the X11R5 server and tried to run it. It flashes the screen white and then crashes with an MMU fault. I didn't do any setup, just typed X& to see if it would work. I've never installed X before, obviously. My setup is a 3000T/030, 4MB fast, 2MB chip, 720 binaries, 721 kernel. Anybody know what I need to do to get X to run? - Kyle From postmaster@cbmuucp.commodore.com Sat Dec 25 01:59:26 1993 From: Tim Newsham Subject: NetBSD-Amiga installation problems To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com My setup: a2000 gvp 030 board + 1 meg ram - board 0 gvp scsi board + 4 megs ram - board 1 quantum 80 meg - scsi 0 maxtor 245 meg - scsi 1 PROCESSOR: CPU 68030/68882fpu/68030mmu CUSTOM CHIPS: ECS NTSC Agnus (id=$0030), Normal Denise (id=$00ff) VERS: Kickstart version 37.210, Exec version 37.151, Disk version 38.30 RAM: Node type $a, Attributes $5 (FAST), at $1000000-$10fffff (1.0 meg) Node type $a, Attributes $5 (FAST), at $280000-$5fffff (3.5 meg) Node type $a, Attributes $303 (CHIP), at $400-$fffff (~1.0 meg) BOARDS: Initial RAM-containing board configured by KickIt (?) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$ea0000 64K) Problem: when I 'loadbsd.720 vmunix.714' it starts booting into BSD but will not read the 'BSDR' partition. Intead it ends in repeated scsi errors. The last few lines of the boot go like this: scsi0: scsi id 7 GVPIIscsi [2017/11] sbic_wait TIMEO @640 with asr=x0 csr=x8a when the BSDR partition is on board 0. When the BSDR partition is attached to board 1 I get instead: scsi0: scsi id 7 GVPIIscsi [2017/11] no suitable root. Setups: I've tried many: vmunix.714 vmunix.720 - this one gave the same error, but the screen mode was some weird hires that I could barely make out on my monitor filetodev streamtodev maxtor + quantum on board 1. booting off maxtor maxtor on board 0, quantum on board 1. booting off maxtor. maxtor + quantum on board 0. booting off maxtor maxtor + quantum on board 0. booting off quantum maxtor + quantum on board 1. booting off quantum I've deleted and re-created the BSDR and other BSD partitions several times with HDToolBox. Someone walked me through checking for 'scsi sync inhibit' or something like that. He said I'm o.k. with that right now. MTK said its my board going into command mode before the software is expecting it to (I think, if I remember correctly). Some suggested I take out the second scsi card but this isnt a possibility because I have 4 megs of normal simms on it, and the accelerator only takes GVP's weird simms. The best theory going right now is that the autoconfig code is getting confused about the two cards and they are somehow conflicting. Please help me out here. I just spent $350 so that I can put BSD on my machine. Tim N. From postmaster@cbmuucp.commodore.com Sat Dec 25 03:03:27 1993 From: luebberw@lp.musc.edu To: NetBSD-Amiga@cbmuucp.commodore.com Subject: .... Sender: postmaster@cbmuucp.commodore.com Okay, I give up. Why do I get the scrunched up font with multicolored letters when I boot up vmunix.720? Thanks in advance, R. Luebbert From postmaster@cbmuucp.commodore.com Sat Dec 25 03:35:01 1993 From: Russel Miranda Subject: Re: NetBSD-Amiga installation problems To: Tim Newsham Cc: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: postmaster@cbmuucp.commodore.com On Fri, 24 Dec 1993, Tim Newsham wrote: > My setup: > a2000 > gvp 030 board + 1 meg ram - board 0 > gvp scsi board + 4 megs ram - board 1 > quantum 80 meg - scsi 0 > maxtor 245 meg - scsi 1 I have a similar setup - plus I have another GVP SCSI controller, and an IOExtender board. > when I 'loadbsd.720 vmunix.714' it starts booting into BSD but > will not read the 'BSDR' partition. Intead it ends in repeated > scsi errors. The last few lines of the boot go like this: > > scsi0: scsi id 7 > GVPIIscsi [2017/11] > sbic_wait TIMEO @640 with asr=x0 csr=x8a > > when the BSDR partition is on board 0. [...] Here at least it appears to be talking to the drive, although obviously not successfully. > [...] When the BSDR partition is > attached to board 1 I get instead: > > scsi0: scsi id 7 > GVPIIscsi [2017/11] > no suitable root. Here, I doubt it found the drive. It never finds any of the drives I have hooked up to boards 1 or 2, only up to board 0. > Some suggested I take out the second scsi card but this isnt a possibility > because I have 4 megs of normal simms on it, and the accelerator only > takes GVP's weird simms. I don't think that should be necessary, as my setup is very similar. > The best theory going right now is that the autoconfig code is getting > confused about the two cards and they are somehow conflicting. But then mine should be confused as well(?) and I'm typing this from NetBSD right now! BTW, my BSD ROOT and SWAP are on a Quantum 105LPS, and I am also using a Quantum 80S (Prodrive) for one of my NetBSD partitions - so those drives work. I am also using a Maxtor 200 meg drive for two partitions, but I can't vouch for the 245. I have sync inhibited on all of them - I would often get sbic_wait TIMEO messages if I used sync. Best of luck - I'm pretty sure your setup SHOULD work, eventually! )Russ From postmaster@cbmuucp.commodore.com Sat Dec 25 04:01:35 1993 From: Tim Newsham Subject: Re: NetBSD-Amiga installation problems To: amigaman@esu.edu (Russel Miranda) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com > > I have sync inhibited on all of them - I would often get sbic_wait TIMEO > messages if I used sync. ok.. how do I go about making sure the sync in inhibited? Its probably already so but I'd like to make sure. > )Russ From postmaster@cbmuucp.commodore.com Sat Dec 25 09:58:09 1993 From: Geff Hanoian Subject: Re: vmunix.720 / scrunched font To: luebberw@lp.musc.edu Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 696 Sender: postmaster@cbmuucp.commodore.com > > > Okay, I give up. Why do I get the scrunched up font with multicolored >letters when I boot up vmunix.720? > >Thanks in advance, >R. Luebbert > 1. Get binpatch (if you don't already have it). 2. 'binpatch -s _ite_default_height -r 400 [kernel name]' Note .. this command comes striaght from the vmunix.mykes.readme file from the NetBSD-Amiga/incoming dir. This turns the screen into a black text on white background. Enjoy. ------------------------------------------------------------------------------ ... talkin' about liquid. Rich enough to own your own jet. Rich enough not to waste time. Fifty, a hundred million dollars Buddy, a player or nothing. -Wall Street (1985) From postmaster@cbmuucp.commodore.com Sat Dec 25 10:16:13 1993 From: Tim Newsham Subject: The saga continues (installation blues) To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com I'm sorry if this is a repeat. Its been several hours since I tried to send this in and I havent gotten back a copy (the other times I got back a copy immediately). I've tried various combinations of options when booting from the quantum drive (scsi id 0): _scsi_no_dma _inihibit_sync 0 6 7 (all others = 0) -------------- --- --- --- x x x x x x x x x x x x x x x x x none of these combinations worked. (refresher: GVP accelerator as board 0, with scsi bus with two drives quantum at scsi0 , maxtor at scsi6, controller at scsi7, second SCSI board as board 1, no drives, 4 megs ram) Tim N. From postmaster@cbmuucp.commodore.com Sat Dec 25 14:04:03 1993 From: niklas@appli.se (Niklas Hallqvist) To: mw@eunet.ch Cc: raoul_o@epita.fr, netbsd-dev@cbmuucp.commodore.com Subject: Re: X and shared libs..... Sender: postmaster@cbmuucp.commodore.com >>>>> "MTK" == mw writes: MTK> Well, the example given to exhibit the bug, didn't.. I then saw MTK> some construct that caused a .size of -1, and that was (from MTK> memory): static char *foo[] = { "bleh", "blah", "gargel", }; MTK> However, both versions, old and "fixed" gcc, did a .size -1 on MTK> this construct. >> Most architectures don't care about the size directive (well, maybe >> debuggers do) but some shared-lib implementations do, notably SVR4. MTK> NetBSD does, too. In fact, "our" shared libraries are much more MTK> like SVR4 shared libs than like SunOS. I felt like dejavu when I MTK> did the netbsd gcc, somehow I did almost the same thing months MTK> ago for Amiga Unix already :-) You did also look at the ASM_DECLARE_OBJECT_NAME, didn't you? They're a pair, specifically size_directive_output (or sth like that) needs to be initialized there. This is just a hint, maybe there's more to it. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From postmaster@cbmuucp.commodore.com Sat Dec 25 19:56:09 1993 From: Tim Newsham Subject: The saga continues To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com I've tried various combinations of options when booting from the quantum drive (scsi id 0): _scsi_no_dma _inihibit_sync 0 6 7 (all others = 0) -------------- --- --- --- (none) x x x x x x x x x x x x x x x x x (all others = 1) none of these combinations worked. (refresher: GVP accelerator as board 0, with scsi bus with two drives quantum at scsi0 , maxtor at scsi6, controller at scsi7, second SCSI board as board 1, no drives, 4 megs ram) Tim N. From postmaster@cbmuucp.commodore.com Sat Dec 25 20:53:19 1993 From: jhardy@ccs.carleton.ca (Jim Hardy) Subject: Handshake Errors w/ Cherry Keyboards PLEASE Verify if Correct! To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 907 Sender: postmaster@cbmuucp.commodore.com Let me make sure if I have this right... The cherry keyboard CANNOT handle any handshaking slower 200us. Mykes had the keyboard handshake set to 1 handshake every 85us and this caused problems on the rev a cherry keyboards. He then changed it to 1 handshake every 200us to fix the problem... Is this not backwards?? Should it not be every 65 us? or 70us? The hardware reference manual states that software should handshake the keyboard at LEAST every 75us. So am I right in saying that there is nothing wrong with the keyboard according to the specs? It is improperly coded software? (No insults intended I'm just trying to figure out if I have a leg to stand on in getting another one from commodore.) Also what handshake does the rev b keyboard allow that it works with all these other program (Various protected games the cherry turns itself off & the obvious problems with netbsd) work properly?? From postmaster@cbmuucp.commodore.com Sat Dec 25 21:33:19 1993 From: sbusko@cap.gwu.edu (Steve Busko Jr.) To: netbsd-dev@cbmuucp.commodore.com Subject: Hurdles Sender: postmaster@cbmuucp.commodore.com Hello developers! Again, I'd like to thank all for their work. (this will be on dev topic...) But!, now that we have most major things (shared libs, X, etc..) in some useable form, I'd very much like to see the little things like minor bug fixes, etc, start getting some attention please. With so many different people doing different things w/ the kernel I've gotten lost as to what patches to apply to where??? So, please take my plea into some thought, as I've seen "stable" things get more unstable as NetBSD expands. I'm comfortablly running as it is w/ 709's vmunix, X11R4 & newest bins. But there are some things that's stopped working the way they did. On vi & more now I'm core dumping on some searches where never did before. Kermit dies also on rec of a file now. ntalkd I can't get to load (something about address taken?) This is a older bin tho and may need updating? All the above are w/ the 709 kernel, honestly I haven't tried 720 or 721 for these problems as I like using X, but I figured that since they're static that's it's probably the new bins? Thank you for your time and I hope those problems help. I just wish I knew more advanced programming to help... - Steve -- EOT ** sbusko@cap.gwu.edu --- Steve Busko Jr. (CyberMatrix) ****** **** Cyberpunk, the attitude, get it! | Do what thou wilt is **** ****** Only Amiga makes it possible! | the whole of the law. ** From postmaster@cbmuucp.commodore.com Sat Dec 25 21:54:53 1993 From: mw@eunet.ch Subject: Re: X and shared libs..... To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, raoul_o@epita.fr, netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 735 Sender: postmaster@cbmuucp.commodore.com > MTK> However, both versions, old and "fixed" gcc, did a .size -1 on > MTK> this construct. > You did also look at the ASM_DECLARE_OBJECT_NAME, didn't you? They're > a pair, specifically size_directive_output (or sth like that) needs to > be initialized there. This is just a hint, maybe there's more to it. Nah.. I must have been on drugs when I made the changes first. Second look at the code showed some pretty silly mistakes... :-/ Well, now works as required. Had to also change gas to allow .size to follow a symbol declaration. Now compiling X-libraries :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Sun Dec 26 06:54:38 1993 From: jgallego@crash.cts.com "...." (Dec 24, 8:55pm) X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: luebberw@lp.musc.edu, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: .... Sender: postmaster@cbmuucp.commodore.com Use: binpatch -s _ite_default_height -r 400 vmunix This will give you a 640x400 screen. You can also use 200 instead of the 400. Jose~ From postmaster@cbmuucp.commodore.com Sun Dec 26 09:19:47 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-x@cbmuucp.commodore.com Subject: Help? X11 install on a Gforce GVP 030/40mhz Sender: postmaster@cbmuucp.commodore.com I can't get VMUNIX.721 to come up. I have no problems with 720 but that will not run X11 stuff. when I boot vmunix.721 (mykes) the disk runs only when loading the kernel. It then freezes with a gray screen and after about 60 sseconds, it will goto the insert workbench animation.. I have not done anything as far as installing X11R5 except unpack all the files and put in a couple of soft links. (no configuring what so ever) Could my freezing have ssomething to do with the fact that I don't have X configure yet. Is the new kernel looking for a file that's not there. (keep in mind that It works great booting up in single user mode on vmunix720. Does the new kernel (721) need something that may not be there for X11R5? The only binpatching I have done, is tried _scsi_no_dma 1 & I tried 255 I'm not really sure what it's looking for... then I set the default height to 200 and width to 640. Nothing more. I have a GVP G-Force 030/40mhz which I had to buy a new cpu chip that has mmu active. Two scsi drives id 5 is a 240 meg hd, and unit 6 is a 43 meg hd. Unit 6 is were rootfs was unpacked. Is there ssomething else I need to binpatch to make this work? Has anyone had luck getting this to work on a G-force setup like mine???? Please help! Thanks. -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From postmaster@cbmuucp.commodore.com Mon Dec 27 03:55:41 1993 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd@cbmuucp.commodore.com Subject: somebody there!!! Sender: postmaster@cbmuucp.commodore.com IS SOMEBODY THERE???? i've posted twice the same question and nobody replied! what's wrong? me? bye michel From postmaster@cbmuucp.commodore.com Mon Dec 27 11:10:52 1993 From: Philippe BRAND Subject: Xbsd server for Retina To: NetBSD-x@cbmuucp.commodore.com (NetBSD Liste) Organization: Telesystemes/Symedia Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 627 Sender: postmaster@cbmuucp.commodore.com Hello! Perhaps I'm a little bit late for CHristmas present but anyway you can find on colombo.telesys-innov.fr (192.70.117.81) retinax.tar.gz in /pub/NetBSD. Remember that the Retina X server is on Beta stage. Happy new year to all of you. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: phb@colombo.telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From postmaster@cbmuucp.commodore.com Mon Dec 27 19:04:02 1993 From: luebberw@lp.musc.edu To: NetBSD-Amiga@cbmuucp.commodore.com Subject: VMUnix 728 Sender: postmaster@cbmuucp.commodore.com Just grabbed vmunix.728 from eunet. Strangely enough, it loads and then I get a blank grey-white screen. I didn't have this problem with any of the previous versions. Is anyone else having these problems? Thanks R. Luebbert From postmaster@cbmuucp.commodore.com Mon Dec 27 22:15:53 1993 From: mw@eunet.ch Subject: Re: Xbsd server for Retina To: phb@colombo.telesys-innov.fr (Philippe BRAND) Cc: NetBSD-x@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 704 Sender: postmaster@cbmuucp.commodore.com > Perhaps I'm a little bit late for CHristmas present but anyway you can Never too late for something like THIS!! *THANKS* > find on colombo.telesys-innov.fr (192.70.117.81) > retinax.tar.gz in /pub/NetBSD. I'm ftp'ing right now to ftp.eunet.ch, perhaps others should wait until it's here, as I remember, the link to telesys isn't one of the fastest... The file will be in incoming, while it is transferring it has an '.transferring' appended, you better not get it in that state :-) > Happy new year to all of you. Same from me :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Mon Dec 27 22:21:39 1993 From: Kevin M Mccarthy Subject: vmunix.728 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 659 Sender: postmaster@cbmuucp.commodore.com So what's the story with 728? Any new features? I either missed the message about it while my system was down or there wasn't one... Also, why are views dis-abled again on this kernel? Is there a reason that none of the distributed kernels have had views enabled? -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- Better the pride that resides in a citizen of the world, than the pride that divides when a colourful rag is unfurled. -Neil Peart ------------------------------------------------------------------------------- From postmaster@cbmuucp.commodore.com Mon Dec 27 22:21:50 1993 From: mw@eunet.ch Subject: Re: VMUnix 728 To: luebberw@lp.musc.edu Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 647 Sender: postmaster@cbmuucp.commodore.com > Just grabbed vmunix.728 from eunet. Strangely enough, it loads and > then I get a blank grey-white screen. I didn't have this problem with any > of the previous versions. Is anyone else having these problems? Don't know what happend here, but to all '40 owners: do *not* download this kernel! Although I did configure it for "cpu m68040", it did link with fpspnull instead of the full blown thing, so it doesn't include fpu stuff. I'll upload a fixed version tonite. Sorry! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Mon Dec 27 22:33:09 1993 From: DCG9367@tntech.edu Subject: Re: Weird problem gets weirder. To: chopps@emunix.emich.edu Cc: netbsd-dev@cbmuucp.commodore.com X-Vms-To: IN%"chopps@emunix.emich.edu" X-Vms-Cc: IN%"netbsd-dev@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: postmaster@cbmuucp.commodore.com >Happy news is I have discovered a way to remove them, I boot without >my 16 bit ram. I have had the EXACT same problem. I have a 2000 with a GVP G-Force 040 with 4mb 32-bit, 2mb on a 2091, another 2mb on another 2091, and 2mb on a GVP ram card. I was working with Michael Hitch, trying to get the 040 kernel to work on my 040 board and was having several probelms with kernel panics. I finally traced it down to the COPYOUT function in locore.s. I patched a function in kern_exec.c which was calling that to use strlen instead of the copyoutstr. That fixed that problem (something was copying the wrong string length and causing bad mem accesses), but I still had problems with booting. On a whim, I changed loadbsd to use my 32-bit ram, and all problems were gone. The original kernel booted fine. Somewhere, something is broken with using 16-bit ram, at least with an 040. David. From postmaster@cbmuucp.commodore.com Mon Dec 27 22:48:15 1993 From: pepersb@cuug.ab.ca (Brad Pepers) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: 728 Sender: postmaster@cbmuucp.commodore.com I tried out the 728 kernel and had some troubles. First of all it seems this kernel version has the blue line lockup problem again. Seems that the last kernels mw generated have this problem. It happens to me whenever I try to view a man page. Also there seems to be a lot of messages coming through syslogd. My /var/log/messages file filled up my / partition in a couple minutes with what looked like copies of the /etc/ttys file. When I logged in as root my console was also filled with these messages. Also - was 728 compiled to allow people to run Xami and Xbsd? If not can someone please post what needs to be done for them to work? I asked earlier for patches but have only gotten other people asking if I had received the patch - no patches! I'm looking at working on a floppy driver. I am not familiar with netbsd though so its taking quite a while to figure things out. Do the sun-lamp files have an example floppy driver for a Intel PC or something to give me hints? Is a floppy driver created like the sd controller/device stuff? Thanks and a Merry Christmas and Happy New Year to all! +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From postmaster@cbmuucp.commodore.com Mon Dec 27 23:01:16 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: vmunix.728 To: signals@krypton.mankato.msus.edu (Kevin M Mccarthy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 691 Sender: postmaster@cbmuucp.commodore.com > So what's the story with 728? Any new features? I either missed the message Mainly a release including the bug-fixes posted over the last days. I compiled this for patrickv to see whether some of his trapsignals go away (and since I blew it with fpsp it didn't help...). > about it while my system was down or there wasn't one... Also, why are views > dis-abled again on this kernel? Is there a reason that none of the distributed > kernels have had views enabled? There should be 10 views configured for 728 and 730. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Mon Dec 27 23:08:46 1993 From: luebberw@lp.musc.edu To: NetBSD-Amiga@cbmuucp.commodore.com Subject: VMUnix 728 Sender: postmaster@cbmuucp.commodore.com I must apologize, 728 now works fine on my system (A3000) just took a little persistence and fsck. Anyway, first thing I noticed different is that this version actually reboots back into Unix like it is supposed to. :) That will save me a bunch of time. X11R5 works on my system with 728. I have a functioning Xwindows console; played around a bit with xeyes and the clocks, then got bored. Didn't try anything particularly hairy, but it seems stable even with multiple xterm sessions at once. I, too had the problems with the "blue line" running vertically up the screen when using more and man. Seems to work okay in an xterm shell. Haven't tried it anywhere else. R. Luebbert From postmaster@cbmuucp.commodore.com Mon Dec 27 23:57:12 1993 From: mw@eunet.ch (Markus Wild) Subject: Re: VMUnix 728 To: luebberw@lp.musc.edu Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 545 Sender: postmaster@cbmuucp.commodore.com > I, too had the problems with the "blue line" running vertically up the > screen when using more and man. Seems to work okay in an xterm shell. Haven't > tried it anywhere else. Ok, seems like I must have missed that essential patch that fixed the problem. If someone could just email it to me? Please don't remail it to the list, we have far enough bandwidth here already.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Tue Dec 28 01:19:51 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-amiga@cbmuucp.commodore.com Subject: Problems with 721,728, and 730 vmunix PLEASE HELP! Sender: postmaster@cbmuucp.commodore.com I cannot get version 721, 728, or 730 vmunix to come up on my system all it does is load the kernel I get a gray white screen then it puts up the amiga animation to insert disk. I have done no binpatching. I have a gvp controller, 8 megs 32 bit ram 1 meg chip both my swap and root are on unit 6 a 43 meg hard drive I have my other partitions on the 240 meg partition. I don't have anything configure (That I know of) for xwindows could this be the problem it's looking for something? Perhaps there is ssomething I need to setup fro Xwindows? Maybe a few things that need to binpatch for my system? Do I need to tell it were to find my root? Why does it just go to the insert workbench disk? Do I need to use _scsi_no_dma? if so How? Do I need to set the _sync varibles? if so How.. version 720 vmunix works fine. But everything after that point doesn't. Please help. At least could someone point me to a manual or book so I can figure out how to get these kernels working on my system? From postmaster@cbmuucp.commodore.com Tue Dec 28 01:27:51 1993 From: Tim Newsham Subject: installation problems (cont.) To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com still no luck... I have two GVP boards, one is accelerator + SCSI and the second is series II scsi + ram. I was wondering recently if there are accelerator+SCSI cards by GVP that arent supported? The docs say GVP series II cards are supported by I have no idea if my card is series II or not (just bought it used a month ago). Is this a possibility? If this is the case, is there any way I can put the drives on the scsi+ram seriesII card and boot off that? When I tried before I always got 'no suitable root'. I think it was only going to the first SCSI card to find drives. Tim N. From postmaster@cbmuucp.commodore.com Tue Dec 28 03:50:06 1993 From: sl1jq@newton.declab.usu.edu (869583 Reynolds Codi A) To: netbsd@cbmuucp.commodore.com Subject: A4000-040 IDE NetBSD? Sender: postmaster@cbmuucp.commodore.com I am very curious. I currently have an Amiga 4000-040 and I would like to see NetBSD with support for its IDE Hard Drives, is this going to be available? If if so, when? Codi Reynolds From postmaster@cbmuucp.commodore.com Tue Dec 28 19:16:11 1993 From: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Subject: Re: Problems with 721,728, and 730 vmunix PLEASE HELP! To: jvasher@cquest.mi.org (Joe Vasher) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 508 Sender: postmaster@cbmuucp.commodore.com > I cannot get version 721, 728, or 730 vmunix to come up on my system > all it does is load the kernel I get a gray white screen then it puts up the > amiga animation to insert disk. I have done no binpatching. Are you SURE you have an 030 with an MMU (not EC030)? Sounds like you don't. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From postmaster@cbmuucp.commodore.com Tue Dec 28 20:04:36 1993 From: Roy Trevino To: netbsd-amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com Subject: Re: vmunix.728 Sender: postmaster@cbmuucp.commodore.com > > > about it while my system was down or there wasn't one... Also, why are views > > dis-abled again on this kernel? Is there a reason that none of the distributed > > kernels have had views enabled? > > There should be 10 views configured for 728 and 730. > > -Markus Hmmm, views are not working for me either on 728/730. Some "Operation not supported" type errors. Perhaps they are a different major device number than 15? Does the "views" program work for you? BTW, I notice that the new libc.a does not work with my libX.a - resulting in "could not connect to :0" type errors when compiling new clients. Does this mean that the unix socket address length no longer includes the null terminator? (It originally required a mod to XConnDis.c to account for this extra char; the other workaround was that (yuck) X->X0 link). Roy -------------------------------------------------------------------- Roy Trevino Intel Corp. E-mail: rtrevino@sedona.intel.com Tel: (602) 554 2816 "mr ducks" "mr not ducks" "osar" "cmbdis" "cmwangs" "lib" "mr ducks" From postmaster@cbmuucp.commodore.com Tue Dec 28 21:21:33 1993 X-Newsreader: Base .75 From: jvasher@cquest.mi.org (Joe Vasher) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Problems with 721,728, and 730 vmunix PLEASE HELP! Sender: postmaster@cbmuucp.commodore.com In article <9312281707.AA02680@public.btr.com> eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) writes: >> I cannot get version 721, 728, or 730 vmunix to come up on my system >> all it does is load the kernel I get a gray white screen then it puts up the >> amiga animation to insert disk. I have done no binpatching. > >Are you SURE you have an 030 with an MMU (not EC030)? Sounds like you don't. I had a G-Force that came with an EC030, I spent 300 + bux buying a new 68030/40mhz which does have mmu. It works great with enforcer, and allowed me to boot up the kernels upto and including 720. Something that was patched into the 721 and later versions just causes the insert disk animation to come up. I'm booting from the amiga dos beta (40.62) could this have something to do with the problem? I'm also not sure if I have 16 bit or 32 bit fast ram but I know it's the 4meg sims that plug onto the gvp card I payed like 189.00 dollars for 4 megs. Maybe that's the problem, I read someone saying something about there 16 meg ram couldn't be found. I'm the only one running a G-Force? PROCESSOR: CPU 68030/68882fpu/68030mmu CUSTOM CHIPS: ECS NTSC Agnus (id=$0030), Normal Denise (id=$00FF) VERS: Kickstart version 40.62, Exec version 40.10, Disk version 40.35 RAM: Node type $A, Attributes $605 (FAST), at $280000-$9FFFFF (7.5 meg) Node type $A, Attributes $703 (CHIP), at $400-$FFFFF (~1.0 meg) BOARDS: Initial RAM-containing board configured by KickIt (?) RAM (unidentified): Prod=2017/9($7E1/$9) (@$200000 8meg Mem) Board + ROM (HD?) (unidentified): Prod=2017/11($7E1/$B) (@$E90000 64K) CBM A2232 serial production: Prod=514/70($202/$46) (@$EA0000 64K) -- <======================================================================> | Joe Vasher Internet: jvasher@cquest.mi.org or | | ComQuest BBS UUCP: heifetz!mbsun!cquest!jvasher | | (313)397-5047 FIDO: Joe Vasher>1:2410/403.0 | | Thanks for flying Xcel | <======================================================================> From postmaster@cbmuucp.commodore.com Wed Dec 29 00:19:22 1993 From: mw@eunet.ch Subject: Re: vmunix.728 To: rtrevino@sedona.intel.com (Roy Trevino) Cc: netbsd-amiga@cbmuucp.commodore.com, rtrevino@sedona.intel.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2109 Sender: postmaster@cbmuucp.commodore.com > BTW, I notice that the new libc.a does not work with my libX.a - > resulting in "could not connect to :0" type errors when compiling new > clients. Does this mean that the unix socket address length no longer > includes the null terminator? (It originally required a mod to > XConnDis.c to account for this extra char; the other workaround was > that (yuck) X->X0 link). No, the problem is more subtle than that.. new BSD sockaddr struct has split the 2 byte sa_family field into a 1 byte sa_family and 1 byte sa_len field (to allow for variable sized addresses). This led to miscouting the size of a struct sockaddr_un. In XConnDis.c, in function (sorry, don't have the CDRom online, so I can't make diffs. This will have to do:) static int MakeUNIXSocketConnection (phostname, idisplay, retries, familyp, saddrlenp, saddrp) do this (you'll see where it fits): addr = (struct sockaddr *) &unaddr; #ifdef SUN_LEN addrlen = SUN_LEN(&unaddr); #else addrlen = strlen(unaddr.sun_path) + sizeof(unaddr.sun_family); #endif #ifdef hpux /* this is disgusting */ Fixing this bug also "magically" fixes xinit, so no nasty symlinks in .X11-unix any longer:-) BTW: I'm working on shared versions of R5 libraries, and so far things don't look bad (I'm writing in a shared xterm, running in the beta Retina server, good work guys!). However, I have problems with Xaw, some clients crash when linked shared, and work when linked static :-( Then, there's this annoying error I can't make head or tails out of: Error: Unresolved inheritance operation for example on starting up "bitmap". Any X wits out there giving me a hint where to look? -Markus PS: gdb doesn't seem to load shared library symbols yet, I *think* our ld.so doesn't yet initialize the link field in the library information section, so gdb can't get at the loaded symbol information. However, I'll have to dig into this some deeper. -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Wed Dec 29 01:11:33 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: VMUnix 728 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: postmaster@cbmuucp.commodore.com In article <199312282313.AAA01567@eunet.ch> mw@eunet.ch writes: > BTW: I'm working on shared versions of R5 libraries, and so far things don't > look bad (I'm writing in a shared xterm, running in the beta Retina > server, good work guys!). However, I have problems with Xaw, some clients > crash when linked shared, and work when linked static :-( Then, there's this > annoying error I can't make head or tails out of: > > Error: Unresolved inheritance operation > > for example on starting up "bitmap". Any X wits out there giving me a hint > where to look? Isn't this what happens when the dynamic linker is built without -DEXPERIMENTAL? -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From postmaster@cbmuucp.commodore.com Wed Dec 29 05:29:28 1993 From: windiba@server.uwindsor.ca (Chris Windibank) Subject: Development books To: netbsd@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com Can any of the current NetBSD developers please suggest a book that describes device programming under NetBSD ? The author, name and ISBN would be great if possible. Chris From postmaster@cbmuucp.commodore.com Wed Dec 29 07:04:21 1993 From: Mike Schwartz Subject: Re: Development books To: windiba@server.uwindsor.ca (Chris Windibank) Cc: netbsd@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 281 Sender: postmaster@cbmuucp.commodore.com > > Can any of the current NetBSD developers please suggest a book that > describes device programming under NetBSD ? The author, name and ISBN > would be great if possible. > > Chris > > > The C Programming Language Kernighan and Plaugher (sorry, don't have the ISBN num.) From postmaster@cbmuucp.commodore.com Wed Dec 29 07:06:22 1993 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd@cbmuucp.commodore.com Subject: IDE/NetBSD Sender: postmaster@cbmuucp.commodore.com I try to boot from my IDE drive on my a1200 equipped with 50mhz 1230XA. Here are the last two lines that it printed before freezing: find_busslaves: for a3000scsi0 looking for sd0 at slave 0 ... and it died there Hope it will help someone in the process of debugging that. Michel Beausejour mbeausej@qc.bell.ca From postmaster@cbmuucp.commodore.com Wed Dec 29 07:13:23 1993 From: Mike Schwartz Subject: Re: Development books To: windiba@server.uwindsor.ca (Chris Windibank) Cc: netbsd@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 320 Sender: postmaster@cbmuucp.commodore.com > > Can any of the current NetBSD developers please suggest a book that > describes device programming under NetBSD ? The author, name and ISBN > would be great if possible. > > Chris > > > Oops, The C Programming Language is by Kernighan and Ritchie Another good book is Software Tools by Kernighan and Plaugher From postmaster@cbmuucp.commodore.com Wed Dec 29 07:38:01 1993 From: kxs5829@ultb.isc.rit.edu (K.X. Saunders) Subject: X11R5 setup? To: NetBSD-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 315 Sender: postmaster@cbmuucp.commodore.com Hi all, I sent a message about getting a MMU fault when starting up the X server with 721. Well, with 730, the X server puts up a stipple pattern and then exists a second or two later. So, can anybody *please* tell me what configuration and the minimum binaries necessary to get X running? Thanks, - Kyle From postmaster@cbmuucp.commodore.com Wed Dec 29 10:28:37 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Content-Length: 6122 From: root@wperkins.uucp.commodore.com (William M. Perkins) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: yet another HELP mail Sender: postmaster@cbmuucp.commodore.com In <9312231041.AA04182@vispars1.ZIB-Berlin.DE> on Dec 23 Roland Wunderling wrote: > Hello NetBSD-Amiga, > > last night I tried to install NetBSD and ran into problems :-( > (Oh, you guessed that?! :-) ) > I tried with loadbsd.720, rootfs_720 and both vmunix.720 and vmunix.721 > I binpatched them to _scsi_no_dma -r 1, since I own an old GVP Impact 3001 > with 4MB and a seperate GVP Series II controler. Further, I tried both > setups for _inhibit_sync. And here is what I get: > > AMIGA2000 MC 68030 CPU+MMU, 25MHz MC68882 FPU .... (stuff deleted) > Changing root device to sd6a > > bpf: sl0 attached > bpf: ppp0 attached > bpf: lo0 attached > panic: cannot mount root > hit any key to boot/dump... > > I saw this message and noticed that the problem described appeared to be simular to one I am having. Here the output after loadbsd is run: AMIGA2000 MC 68030 CPU+MMU, 25MHz MC68882 FPU real mem = 7864320 avail mem = 4939776 using 96 buffers containing 786432 bytes of memory 2 Amiga memory segments segment 0 at 00280000 size 00780000 segment 1 at 00000000 size 00100000 ZorroII memory at 00000000-00000000 Realtime clock A2000 rtclock0 [1/9] par0 [1/6] grf0: 640 x 400 4 color custom chips display grf0 [1/7] ser0 [1/3] dma0: a2091 DMA scsi0: scsi id 7 a2091scsi0 [514/3] st0: CIPHER ST150S2 rev G76M st0: Unsupported tape device << How serious is this? st0 at a2091scsi0, slave 5 sd6: SEAGATE ST157N rev |j, 94860 512 byte blocks sd6 at a2091scsi0, slave 6 Changing root device to sd6a bpf: sl0 attached bpf: ppp0 attached bpf: lo0 attached panic: cannot mount root hit any key to boot/dump... > I had hoped any suggestions posted for Roland might help me, but I gather the problem may be deeper.... So I will tell you some of what I did and maybe someone can point out where I went wrong. First the Config program output: CHIPS: CPU 68020/68881fpu/68851mmu, ECS NTSC Agnus, ECS Denise VERS: Kickstart version 40.62, Exec version 40.10, Disk version 40.29 RAM: Node type $a, attribute $605 (FAST), from $280000 to $9fffff Node type $a, attribute $703 (CHIP), from $400 to $fffff BOARDS: Initial RAM-containing board configured by KickIt (?) CBM A2620 68020/RAM card: Prod=514/80($202/$50) (@$200000 4meg Mem) CBM A590/A2091 HD controller: Prod=514/3($202/$3) (@$e90000 64K) CBM A2052/58.RAM | 590/2091.RAM: Prod=514/10($202/$a) (@$600000 2meg Mem) Board (unidentified): Prod=2055/0($807/$0) (@$ea0000 64K) CBM A2052/58.RAM | 590/2091.RAM: Prod=514/10($202/$a) (@$800000 2meg Mem) Board + ROM (HD?) (unidentified): Prod=1010/158($3f2/$9e) (@$eb0000 64K) (The last unidentified board is a Checkpoint Technology serial card) The way the system is being setup is to have the Amiga hard drives on the HardFrame controller and the NetBSD drives, along with the Cipher tape drive, on the A2091 controller. The system has 1 MB of Chip memory and 8 MB of Fast memory of which 4 MB is 32 bit. A test partition of 10 MB was setup on the Seagate ST157N-1 drive to see if I could boot NetBSD into single user mode. I figured if I could get that far, which everyone says is 90 % of the battle, the rest would be easy to do. So I used HDToolBox (and later RDPrep) to create a partition to hold 20480 blocks for the root file system. This is the MountList for this drive: /* RigidDiskBlock. */ SEAGATE ST157N 4|j0: disk = scsi.device Unit = 6 BytesperBlock = 512 Cylinders = 613 Heads = 6 BlocksPerTrack = 26 CylinderBlocks = 180 RDBlow = 3 ; RDBhi = 179 MinCyl = 1 ; MaxCyl = 526 Interleave = 1 HiLun = TRUE HiID = TRUE HiDrive = TRUE Reselect = TRUE # /* NetBSD Partition. */ ROOT: device = scsi.device Unit = 6 Flags = 0x0 FileSystem = L:BFFSFileSystem StackSize = 4096 Surfaces = 6 BlockSize = 512 BlocksPerTrack = 30 Reserved = 2 Interleave = 0 LowCyl = 1 ; HighCyl = 115 PreAlloc = 0 Buffers = 20 BufMemType = 1 DOSType = 0x42534452 MaxTransfer = 130560 Mask = 0x7ffffffc GlobVec = -1 Mount = 0 /*! Bootable = 0 */ BootPri = -128 Priority = 10 # /* AmigaOS Partition. */ HD2: device = scsi.device Unit = 6 Flags = 0x0 FileSystem = L:FastFileSystem StackSize = 4096 Surfaces = 6 BlockSize = 512 BlocksPerTrack = 30 Reserved = 2 Interleave = 0 LowCyl = 116 ; HighCyl = 526 PreAlloc = 0 Buffers = 20 BufMemType = 1 DOSType = 0x444f5301 MaxTransfer = 130560 Mask = 0x7ffffffc GlobVec = -1 Mount = 1 /*! Bootable = 0 */ BootPri = -128 Priority = 10 # This mountlist was generated from the Microbotics RDPrep program. If you calculate out the numbers: 114 cylinders times 6 heads (surfaces) times 30 blocks per track, you get 20520 blocks. More than enough to hold the rootfs_720 image. I used dcp to load the image to the partition, but I also used filetodev with no difference in the results. I even used dcp to copy the partition image back to a file for comparison with the original rootfs_720. Except for the fact that the file I created was larger, there were no differences. So I figure the file system image is in place correctly. The kernel I started with was the vmunix.720 file, but I have also tried the vmunix.728 and vmunix.730 with the same panic results "cannot mount root". Guenther Grau says in the NetBSD FAQ that this panic means trouble, but what kind of trouble? I used the latest loadbsd program (loadbsd.720.gz), dcp (dcp1.1.lha) and ixemul.library (version 39.47) files. I have a lot of theories as to what might be happening here but I currently cannot afford to test them all. The old Seagate ST157N-1 drive is the only drive I can play with right now. The others, a pair of Quantums, are being used to support my development and Usenet news systems. The Seagate is not on the "approved" list of hard drives in the FAQ but the Quantums are. *Sigh* Anybody got any suggestions? Bill -- William M. Perkins Usenet - wmp%wperkins@virginia.edu The Greenwood or wperkins!wmp@clem.handheld.com +1 804 750 2101 BIX - wmperkins From postmaster@cbmuucp.commodore.com Wed Dec 29 17:12:46 1993 From: leland@wacky.acet.org (Robert Leland - PSI) Subject: Re: Development books Cc: netbsd@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com > > Can any of the current NetBSD developers please suggest a book that > > describes device programming under NetBSD ? The author, name and ISBN > > would be great if possible. > > > > Chris > > > > > > This is from the NetBSD FAQ for 386 machines, my copy is very old Aug 93 but if you have a news feed you can get one from the comp.os....386bsd.development news group. Also try subscribing to the sun news groups for good tips on sys admin tips. DDJ = Dr. Dobb's Journal "Porting UNIX to the 386: A Practical Approach" (feature series) by Jolitz and Jolitz 1/91 - 7/92 11/91: DDJ "Device Autoconfiguration" 2/92: DDJ "UNIX Device Drivers, Part I" 3/92: DDJ "UNIX Device Drivers, Part II" 4/92: DDJ "UNIX Device Drivers, Part III" You can contact M&T Books (DDJ) for reprints if you can't get them from your technical library: 1-800-356-2002 (inside CA) 1-800-533-4372 (North America) 1-415-358-9500 (international) -- Wish I knew german -- 6/91: UNIX Magazin "Portierung von BSD-UNIX auf den 80386. Heimlich Liebe." 7/91: UNIX Magazin "Steighilfe." 8/91: UNIX Magazin "Systemverwaltung durch Tabellen" 9/91: UNIX Magazin "Sicher bewegen auf fremdem Terrain" 10/91: UNIX Magazin "Damit die Fehlersuche nicht zum Hurdenspringen wird" 11/91: UNIX Magazin "Alles in eine Schublade" 12/91: UNIX Magazin "Feuer und Wasser" 1/92: UNIX Magazin "Rekursives Speicher-Mapping" 2/92: UNIX Magazin "Tanz auf dem Eis" 3/92: UNIX Magazin "Aus Hanschen wird Hans" 4/92: UNIX Magazin "Das Geheimnis des Multiprogramming" 5/92: UNIX Magazin "Zeitmanagement scheibenweise" 6/92: UNIX Magazin "Magie des Kernels" 7/92: UNIX Magazin "Erkenne Dich Selbst" 9/92: UNIX Magazin "Niemand is eine Insel" 10/92: UNIX Magazin "Treiberlatein" 12/92: UNIX Magazin "Einlandung erforderlich" 1/93: iX Magazin "??" 2/93: iX Magazin "??" - Titles Unknown 3/93: iX Magazin "??" 4/93: iX Magazin "??" NOTE: The series in UNIX Magazin was moved to IX Magazin in 1/93. In addition, other major articles which discuss 386BSD in detail: 8/92: UNIX Magazin "Interview mit Bill Jolitz. Das passiert mit 386BSD" by Jurgen Fey 8/92: DDJ "Very High-Speed Networking" by W.F. Jolitz 12/92: DDJ "Inside the ISO-9660 Filesystem Format" by Jolitz and Jolitz Reprints of the first 19 parts on the UNIX Magazin series are available from: iX Redaktion Stichwort: 386BSD-Serie Verlag Heinz Heise GmbH & Co KG Helstorfer Str. 7 3000 Hannover 61 From postmaster@cbmuucp.commodore.com Wed Dec 29 18:09:53 1993 From: niklas@appli.se (Niklas Hallqvist) To: netbsd-dev@cbmuucp.commodore.com Subject: Panic trap backtraces Sender: postmaster@cbmuucp.commodore.com In GCC there is two builtin functions called __builtin_return_address and __builtin_frame_adress which both take an integer argument denoting the frame for which the values are wanted. I don't know how well these work on the m68k (there are many GCC ports where these fail to work), but if they do, this info could be used to format the kernel trap backtrace info in a much nicer way. Maybe there are limitations on the optimization level these builtins can handle, I don't know. Certainly -fomit-frame-pointer ought to be deadly. Are there anybody out there (besides me) wanting to see tracebacks like this: Frame 0 called from 0x00012345 fffffd00: 00000000 11111111 22222222 33333333 Frame 1 called from 0x00023456 fffffd14: 44444444 Frame 2 called from 0x00034567 fffffd1c: 55555555 ... Are there anyone wanting to do the implementation? I could do it, but my time is *very* limited. I guess you're still waiting for the ADOS FS release? Well, that's another one suffering from me lacking time. If I just had 4 more megs in my Amy, things would go so much faster... :-) The 4Meg-man, Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From postmaster@cbmuucp.commodore.com Wed Dec 29 18:18:53 1993 From: Petri Nordlund Subject: Re: Problems with 721,728, and 730 vmunix PLEASE HELP! To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1169 Sender: postmaster@cbmuucp.commodore.com Joe Vasher writes: >In article <9312281707.AA02680@public.btr.com> eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) writes: >>> I cannot get version 721, 728, or 730 vmunix to come up on my system >>> all it does is load the kernel I get a gray white screen then it puts up the >>> amiga animation to insert disk. I have done no binpatching. >>Are you SURE you have an 030 with an MMU (not EC030)? Sounds like you don't. >I'm also not sure if I have 16 bit or 32 bit fast ram >but I know it's the 4meg sims that plug onto the gvp card I payed like 189.00 >dollars for 4 megs. Then it's 32 bit memory. > I'm the only one running a G-Force? No, you are not alone. I have G-Force 68EC030/68882/25MHz board. Yes, it is 68EC030, and I'm sure of this. But it seems to have a working MMU. GigaMem and Enforcer work just fine. I have been using NetBSD for a couple of weeks now with 714 kernel. I have also booted with 709, 713, 720, 721 (mykes?), 728 and 730 kernels. I have 5 MB of 32-bit RAM on the board. I also compiled the 713 kernel myself, but it didn't work. It just shows a grey screen. I think I missed something when I compiled it. Petri From postmaster@cbmuucp.commodore.com Wed Dec 29 19:00:17 1993 From: luebberw@lp.musc.edu To: NetBSD-Amiga@cbmuucp.commodore.com Subject: ... Sender: postmaster@cbmuucp.commodore.com Is there any interest out there for having NetBSD available for download by modem? I have a high speed 16600 HST/V.32bis modem and plenty of disk space available if there is a genuine interest. R. Luebbert From postmaster@cbmuucp.commodore.com Wed Dec 29 19:38:59 1993 To: NetBSD-amiga@cbmuucp.commodore.com Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Development books Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: postmaster@cbmuucp.commodore.com In article <9312282322.AA22220@server.uwindsor.ca> windiba@server.uwindsor.ca (Chris Windibank) writes: > Can any of the current NetBSD developers please suggest a book that > describes device programming under NetBSD ? The author, name and ISBN > would be great if possible. Others have suggested some books on device driver programming in particular, but for a general BSD 4.3 internals book, *THE* authorative reference is the so-called "Demon book" (because it has a cute little pitchfork-carrying tennis-shoe-wearing demon on the cover): _Design and Implementation of the 4.3BSD UNIX(r) Operating System_ by Samuel J. Leffler, Marshall Kirk McKusick, Michael J. Karels, and John S. Quarterman ISBN 0-201-06196-1 Published by Addison-Wesley -- Ty Sarna "Oh, I don't know *everything*. I don't tsarna@endicor.com even know how fish work." -- Joel, MST3K From postmaster@cbmuucp.commodore.com Wed Dec 29 22:15:22 1993 From: William J. Coldwell To: mbeausej@qc.bell.ca (michel beausejour) Subject: Re: IDE/NetBSD Cc: netbsd@cbmuucp.commodore.com Sender: postmaster@cbmuucp.commodore.com >I try to boot from my IDE drive on my a1200 equipped with 50mhz 1230XA. >Here are the last two lines that it printed before freezing: > find_busslaves: for a3000scsi0 > looking for sd0 at slave 0 ... and it died there >Hope it will help someone in the process of debugging that. At the moment, there is no one debugging that because there is no IDE driver available yet. But don't despair... Bill -- Me @Home @Work William J. Coldwell Cryogenic Software Intel Corporation Attitude Adjuster billc@cryo.rain.com billc@elite.intel.com "If you wouldn't ask dumb-ass questions, I wouldn't give smart-ass answers." From postmaster@cbmuucp.commodore.com Wed Dec 29 22:39:12 1993 From: Philippe BRAND Subject: Re: ... To: luebberw@lp.musc.edu Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Organization: Telesystemes/Symedia Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 778 Sender: postmaster@cbmuucp.commodore.com luebberw@lp.musc.edu writes: > Is there any interest out there for having NetBSD available for > download by modem? I have a high speed 16600 HST/V.32bis modem and plenty > of disk space available if there is a genuine interest. Too late! :-) I managed a dayly mirror on our BBS in France. 21.600 bauds, 14.400 line 2, 2400 line 3. In france at least there is interrest in NetBSD on BBS. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: phb@colombo.telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From postmaster@cbmuucp.commodore.com Thu Dec 30 00:07:24 1993 From: Mike Schwartz Subject: Re: Development books To: jdresser@altair.Tymnet.COM (Jay Dresser) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 357 Sender: postmaster@cbmuucp.commodore.com > > > > Oops, The C Programming Language is by Kernighan and Ritchie > > Another good book is Software Tools by Kernighan and Plaugher > > Cool! Does Software Tools have stuff on device drivers? > No, Software Tools doesn't have stuff on device drivers, at least not unix internals for doing so. It does cover "device programming" whatever that is. From postmaster@cbmuucp.commodore.com Thu Dec 30 04:53:01 1993 Subject: Consoles From: David Jones To: NetBSD-X@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com I've solved my X startup problem. My problem was that the X server would quit during startup. The real problem was that XTerm was not able to redirect the console to a window. The solution was to make XTerm setuid root. Funny thing, though: using 713, I was able to run no problem. The C define UCONSOLE determines if non-root can set the console or not - see /sys/kern/tty.h. Was the "default" value of UCONSOLE changed at some point? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From postmaster@cbmuucp.commodore.com Thu Dec 30 04:57:01 1993 Subject: 730 From: David Jones To: NetBSD-Dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com Perhaps this is a FAQ; I've been away for a week (too long! :-) What's been fixed from 720->730? I note that the grf turns on properly (so you can run X). However, under 730 I get the underline gives blue up screen and barf bug, which I was not experiencing under 720. (I am using a 9x6 font for my own 720 build, does this make a difference?) When will sources for 730 be made available? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From postmaster@cbmuucp.commodore.com Thu Dec 30 05:34:49 1993 From: rAT Subject: NetBSD and A2024 monitors... ? To: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: postmaster@cbmuucp.commodore.com Hello, all. I am seriously considering installing NetBSD on my A3000 when I get a larger drive. I have a Commodore A2024 (1024x800x2) monitor that I'd *really* like to use in the full resolution. Is it possible to get the NetBSD kernel to recognize the 2024 as the console monitor and take advantage of the resolution? Does X support the 2024? Thanks in advance for any information on the subject... -rAT (He of the SubHuman Strength :^) O----O email : rat@cs.orst.edu : CS Isupport \oo/ __ "This is the most fun I've ever had with someone else's clothes!" ==\/== \/ - Kathy Lowe From postmaster@cbmuucp.commodore.com Thu Dec 30 06:27:28 1993 From: mbeausej@qc.bell.ca (michel beausejour) To: netbsd@cbmuucp.commodore.com Subject: Netbsd/panic Sender: postmaster@cbmuucp.commodore.com When i tried to boot netbsd ,after it located the drive i received the following message: panic: allocbuf desired size is zero hit any key to boot/dump... i have an st157n id 6 attached to a a2091 rom 6.6 the root partition is the first one on the drive startting at cyl 2 What's funny is that hdtoolbox said that the geomery of this drive is 6 heads 26 blocks per track and 155 blocks per cylinders, for me blocks per cylinders shall be 156 not 155????Anyhow i tried to install the rootfs like this filetodev 310 16448 rootfs scsi.device 6 1000 ( i recevie the panic : allocbuf : ...) when in reinstall the rootfs with the filetodev again: filetodev 312 16448 rootfs scsi.device 6 1000 (i received " cannot mount root") Any help will be greatly appreciated.. Many thanks Michel Beausejour mbeausej@qc.bell.ca From postmaster@cbmuucp.commodore.com Thu Dec 30 06:38:06 1993 From: rAT Subject: Re: Consoles To: David Jones Cc: NetBSD-X@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: postmaster@cbmuucp.commodore.com On Wed, 29 Dec 1993, David Jones wrote: > The solution was to make XTerm setuid root. A quick note from the Security Guy at Oregon State University... :^) I'm not sure that this is a good place to mention this, but if you're putting your machine on the net, you should know that there is a huge security hole in most versions of XTerm. Basically, making it suid root allows you to use the logging options to do nasty things. I very much recommend that you recompile XTerm *without* the logging function. This alleviates the problem. Please feel free to mail me personally if you have questions about this... -rAT (He of the SubHuman Strength :^) O----O email : rat@cs.orst.edu : CS Isupport \oo/ __ "This is the most fun I've ever had with someone else's clothes!" ==\/== \/ - Kathy Lowe From postmaster@cbmuucp.commodore.com Thu Dec 30 07:56:02 1993 From: barrett@iastate.edu To: netbsd-amiga@cbmuucp.commodore.com Subject: Configuring NetBSD Networking Sender: postmaster@cbmuucp.commodore.com I am trying to fully enable the networking of NetBSD after installing it, and I must admit that I am somewhat clueless about some of the things that are BSD-specific, as all of my experience is with Ultrix. Could someone tell me what files in /etc (and maybe /usr/etc) I have to modify to get networking fully enabled? By process of elimination, I'd like to find out what files I can safely ignore for the time being. +++++++ ++++ Marc Barrett -MB- ++ IRC nick: Cyclone | e-mail: barrett@iastate.edu + From postmaster@cbmuucp.commodore.com Thu Dec 30 16:33:20 1993 From: Alan Bair Subject: Re: Configuring NetBSD Networking To: barrett@iastate.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com Look at the /etc/netstart file. It contains variable settings that control the running of most network related items. However, you do need to have an Internet address if you are going to actually connect to the network. This needs to be setup in files such as /etc/hosts. > > I am trying to fully enable the networking of NetBSD after installing it, > and I must admit that I am somewhat clueless about some of the things that are > BSD-specific, as all of my experience is with Ultrix. Could someone tell me > what files in /etc (and maybe /usr/etc) I have to modify to get networking > fully enabled? By process of elimination, I'd like to find out what files I > can safely ignore for the time being. > > +++++++ > ++++ Marc Barrett -MB- > ++ IRC nick: Cyclone | e-mail: barrett@iastate.edu > + > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From postmaster@cbmuucp.commodore.com Thu Dec 30 17:02:06 1993 From: mw@eunet.ch Subject: shared X11 on eunet To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 442 Sender: postmaster@cbmuucp.commodore.com Just uploaded my recent shared library compilation of X11R5. Files are in ftp.eunet.ch, netbsd incoming directory. Names should be obvious, I splitted the fonts directory from the X11 lib directory for those that already have the fonts and don't want to download them again. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Thu Dec 30 18:34:38 1993 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Blue line problem To: netbsd-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.2 PL8] Sender: postmaster@cbmuucp.commodore.com To everyone having the blue line problems with kernel panics: I do not and have not ever seen this problem occur over here so I can't really do to muh debugging on it. What I need is someone who is ompiling their own kernel that has this problem to test something out. in the file ite_cc.c you'll notie that the putc() routine is really just vectoring to any number of routines based on the style. My only guess so far as to why this pani happens is that this function is being called with a bogus style and thus vetoring ito nowhere. What you an do to test this is to mask the style parameter to only acceptable values. If this clears the problem then there is a stack problem or a problem in ite.c. If it doesn't then I don't have a clue. :^) Chris. From postmaster@cbmuucp.commodore.com Thu Dec 30 21:07:30 1993 From: Kevin M Mccarthy Subject: libc.so.1.1 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 820 Sender: postmaster@cbmuucp.commodore.com I have a problem... I just installed the shared libs version of X11R5 and I now get: ld.so: /usr/lib/libc.so.1.1: Cannot read exec header So now I am screwed.... login doesn't even work properly. I can still boot into single user, but I am screwed anyway... Did this file come with X11 and it's corrupt? Or did I accidentally trash the disk or something? Any suggestions? Or better yet, where can I get a new libc.so.1.1? -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- Better the pride that resides in a citizen of the world, than the pride that divides when a colourful rag is unfurled. -Neil Peart ------------------------------------------------------------------------------- From postmaster@cbmuucp.commodore.com Thu Dec 30 21:10:26 1993 From: sl1jq@kaos.declab.usu.edu.declab.usu.edu (869583 Reynolds Codi A) To: mbeausej@qc.bell.ca, netbsd@cbmuucp.commodore.com Subject: Re: Netbsd/panic Sender: postmaster@cbmuucp.commodore.com I have the same problem as you are having. When I run NetBSD it runs fine until it says, "panic: Cannot find root". I could really use some help on this as well. Thanks From postmaster@cbmuucp.commodore.com Thu Dec 30 21:21:03 1993 From: Kevin M Mccarthy Subject: Re: libc.so.1.1 To: signals@krypton.mankato.msus.edu (Kevin M Mccarthy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1234 Sender: postmaster@cbmuucp.commodore.com Kevin M Mccarthy Spoketh: > > I have a problem... I just installed the shared libs version of X11R5 > and I now get: > > ld.so: /usr/lib/libc.so.1.1: Cannot read exec header > > So now I am screwed.... login doesn't even work properly. I can still boot > into single user, but I am screwed anyway... Did this file come with X11 and > it's corrupt? Or did I accidentally trash the disk or something? Any > suggestions? Or better yet, where can I get a new libc.so.1.1? Well, I guess I am not in as much trouble as I thought... I used bffs on that partition and libc.so.1.1 was 0 bytes in length.. I don't know why it was, but it was... So I downloaded X11R5-usr.lib.tar.gz again and re-copied libc.so.1.1 from it. This just goes to show why you don't want shared libs executables in /bin and /sbin! Sorry for the waste of bandwidth. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- Better the pride that resides in a citizen of the world, than the pride that divides when a colourful rag is unfurled. -Neil Peart ------------------------------------------------------------------------------- From postmaster@cbmuucp.commodore.com Thu Dec 30 22:05:29 1993 Subject: Underline up and barf bug FIX From: David Jones To: NetBSD-dev@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com Here's the lowdown on the underline-up-and-barf bug: The problem is in ite_cc.c, where underlines are rendered. The character is rendered in 3 parts: above the line, the underline, and below the line. The code that does the rendering is correct. The bug manifests itself when the difference between the font height and font baseline is less than 2. Here are some sample figures: My 9x6 font: baseline=6 height=9 Mach font: baseline=11 height=15 topaz/8 using fontdumper, 3.0 kickstart: baseline=6 height=8 All of the above are OK. However (!!!) peeking in /dev/kmem while running 730, I get baseline=7, height=8! The underline is put one row lower than the baseline (which is correct). For baseline=7, height=8, the underline will go on row 8, but valid rows are from 0 to 7. Oops. Barf. It would be interesting to see if Commodore changed the baseline on the Topaz font (why does a kernel I build using fontdumper have baseline=6 but mw's kernel has baseline=7?). I invite a 2.04 user to use fontdumper and build the kernel and report the results. I also invite mw to check which font he's using :-) To sum up, if the bug affects you, then binpatch _kernel_font_baseline (byte) to be 6. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info/PGP public key From postmaster@cbmuucp.commodore.com Fri Dec 31 02:26:36 1993 From: mw@eunet.ch (Markus Wild) Subject: Mosaic binary To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 318 Sender: postmaster@cbmuucp.commodore.com Uploaded a first Mosaic binary, right out of make, thought some of you might like it as much as I do. Sure looks terrific on the color retina server! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From postmaster@cbmuucp.commodore.com Fri Dec 31 04:39:52 1993 From: Tim Newsham Subject: I'm Up and running To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: postmaster@cbmuucp.commodore.com I got my system to load up BSD finally. What was wrong? Well I have 2 GVP boards, one is an accelerator card + scsi, the other is a ram card + scsi. Accelerator gets loaded as card 0 (first in the list of boards) and the ram card gets loaded as card 1. For some reason BSD doesnt work with my card 0. I'm not sure what model number it is.. my best guess is that it isnt "series II" the one supported by BSD. What I did to get up and running was to take 'loadbsd' source, and swap the storage of the two cards so that card 0 becomes card1 and card 1 becomes card 0. The list of configured devices is passed to vmunix when vmunix is run. So... question.. why doesnt BSD look through all the autoconfig cards that have hard drives on them when looking for the root partition? If it did this already then I wouldnt have had any problems installing BSD (since my drives where originally on board 1 not board 0) and I wouldnt have had to do this hack to get BSD running. Tim N. the code I added incidently is (right after the boards are read into (knum_cd+1) ): printf("%d Boards\n",num_cd); if(num_cd 1) { struct ConfigDev *abc,ttt; abc = (struct ConfigDev *) (knum_cd+1); ttt = abc[0]; abc[0] = abc[1]; abc[1] = ttt; printf("Swapped Configured device 0 and 1\n"); } From postmaster@cbmuucp.commodore.com Fri Dec 31 06:54:06 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Finally... From: "John Reddersen" Sender: postmaster@cbmuucp.commodore.com Well, I finally got NetBSD up and running in MultiUser mode (stuff takes forever to dload at 2400 baud :-)). Everything seems to be working pretty well except for man, or it could be more, which is trapsignaling on me. If I do a man csh, then /prompt to search for prompt, it reads the drive for a while, then spits out: trapsignal(63, 11, 16875520, 1018000, 2024f40). I'm running Mykes vmunix.721 and all the 720 bin, sbin, etc... One other little thing. Once when I did loadbsd and NetBSD came up there was a red and black stripe down the center of the whole screen that looked like it had basically taken my mousepointer as a brush in Dpaint and painted it down the whole screen. Everything still worked, but I couldn't see anything under the stripe and it didn't go away. Thanks to all the NetBSD'ers out there for giving me something to keep me occupied over this holiday break! --- .-------------------------.---------------------------------------------. | John Reddersen | Work: Durham 138 Helproom (515) 294-1314 | | jredders@iastate.edu | Home: Friley, 3393 Knapp (515) 296-3996 | | ///\ . .. _ . | "If at first you don't succeed, so much | | \X//--\|V||(_,/-\ | for skydiving!" - unknown author | `-------------------------^---------------------------------------------' From postmaster@cbmuucp.commodore.com Fri Dec 31 18:53:48 1993 From: leland@wacky.acet.org (Robert Leland - PSI) To: netbsd-amiga@cbmuucp.commodore.com Subject: Trashing hard disk - shgared executables? Sender: postmaster@cbmuucp.commodore.com We'll I keep trashing my Harddisk partition some how. I am running vmunix.720p4 (2 patches to view stuff, a reboot patch, and something else that was posted to the net), all shared bins. First I discovered I had trashed my /usr/sbin when I was trying to compile a kernel, I restored it. Then yesterday when I was again compiling I found my /sys/vm directory was hosed, I restored it. Then today I had to restore most of my /usr/bin, and yes I was compiling! I installed another 4M of memory Thursday, I now have 8M :-), I have more than the required swap space. I don't believe this caused the problems, Now I can run X and compile and trash my disk at the same time! ;~) My system still doesn't seem to reboot properly, either with reboot, or with /dev/reload. I am now do a umount -a then a fsck before I sync;sync;reboot. Maybe I commented something out of the kernel configuration that I needed, I dunno. I'll recompile a full kernel tonight, before I go out. Question: Has anyone else seen this? Any debugging or traps I can lay, sorta speak, to help track this down. -Rob PS: Happy NewYear!