From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 00:02:42 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: /dev/MAKEDEV broken for ttyx? Sender: owner-current-users@sun-lamp.cs.berkeley.edu seems to me that if you do "MAKEDEV tty0" it will fail since unit will be empty. "MAKEDEV com0" will work, however. am I missing something? from /dev/MAKEDEV: ... com*|tty*) unit=`expr $i : 'com\(.*\)'` ... -brad From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 00:06:06 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Hardware query From: "David Christiansen" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone know if the SCSI controller on the Soundblaster/SCSI card is actually an Adaptech or not? If so, is it (1542?) compatible and supported by NetBSD? I'm considering replacing my soundblaster and moving from a non- supported SCSI card, and I figure I could do it this way. Unfortunately, the outside of the box only says "Adaptech! Combining two powerful standards." (Which could mean almost anything) So does anyone have any experience with this piece of equipment? ---- David "Basil" Christiansen "...and all the world will be your enemy... basilisk@iastate.edu "and whenever they catch you, they will kill you. basilisk@vorpal.com "...but first, they must catch you." -- Watership Down "They're all dead... they just don't know it yet..." -- The Crow From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 00:06:38 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: /usr/src/sys/arch/i386/floppy/tar dumps core Sender: owner-current-users@sun-lamp.cs.berkeley.edu /usr/src/sys/arch/i386/floppy/tar dumps core for me. If I link it dynamically or link it static *without* gnumalloc, it with works fine. -brad From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 00:10:01 1994 From: mycroft@gnu.ai.mit.edu To: brad@fcr.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: /dev/MAKEDEV broken for ttyx? Sender: owner-current-users@sun-lamp.cs.berkeley.edu The MAKEDEV bug was fixed on September 13, 1993. Are you still using the 0.9 version of this file with a -current system? From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 00:26:54 1994 To: Bill & Cc: Ken Hornstein , peter@alice.wonderland.org, current-users@sun-lamp.cs.berkeley.edu Subject: Re: GET THIS BOOK :) <199407311856.OAA00234@orchard.medford.ma.us> From: Greg Hudson Content-Length: 1648 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > (There *are* structural problems with UNIX, though, especially in > the area of the terminal driver, but that's really off-topic for > this list. For example, see what happens to your shell when you run > a program which sets non-blocking mode on your TTY and then > exits...) Actually, I do think that's related to this list. The problem here is that fcntl()'s FL_NONBLOCK flag applies to the open file description pointed to by a file descriptor. Multiple processes can have file descriptors refeerring to the same open file description (e.g. the stdin of a program usually has the same OFD as the stdin of its shell), and when one process sets the file descriptor non-blocking, the other process suddenly starts getting EAGAINs from its read() and write() calls. The only explanation for this, as far as I can tell, is that no one was paying attention when they standardized this in POSIX. A simple solution is to add a second flag FD_NONBLOCK which applies only to the file descriptor. read() and other blocking system calls will return EAGAIN if either the file descriptor or its corresponding open file description are set non-blocking. This way, programs can set their file descriptors non-blocking without fear of sabotaging other processing using the same OFDs. The issue is relevant to this list because if enough operating systems add FD_NONBLOCK, POSIX may take notice of it, standardize it, and possibly even deprecate FL_NONBLOCK. Even if FD_NONBLOCK is never standardized, certain packages (for instance, Proven's threads library) can operate much more robustly with support for per-file-descriptor non-blocking flags. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 01:06:17 1994 From: mycroft@gnu.ai.mit.edu To: basilisk@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Hardware query Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've been told that the aic6360 driver works with the Soundblaster SCSI, but I wouldn't place any bets on it. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 01:57:45 1994 Subject: Re: problems with source tarballs To: mycroft@gnu.ai.mit.edu From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu, michaelv@iastate.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2090 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What happens on the kernels I build is this: it goes through all the > autoconfiguration stuff, and everything looks like it's working ok. > Then it finally gets to the part at the end where it prints the > ttymask, biomask, etc. stuff. Right there it just sits forever, > [...] > > Are you still having this problem? A probably totaly unrelated story: I managed to get this effect once, and needed a few hours to find the problem. But to keep up the tension I'll tell you the whole story: I managed to build working boot disks last Monday (via brute-force patching fd.c and disklabel.c). I then decided to change my filesystems to the new 4.4 style. After all the horror stories about fsck -c 2 I made a backup first - using "tar -l -c -v .". Fsck run fine, I installed new bootblocks and rebooted. The kernel came up, fsck started and gave up "unexpected inconsitencies, run fsck manualy" on the "/usr/src/lib/" directory. I run fsck manualy, let it clear that directory and all else worked fine. But the fs was heavily fragmented, so I newfs'd it anyway and read back the tape. Then I synced and booted... The kernel loaded, probed everything fine and then the system waited forever, nothing happend. I had a kernel debugger, so I broke into it and looked at "ps": init was running two times, so obviously it tried to fork sh for /etc/rc but couldn't. After booting from floppy and looking around (and replacing /bin/sh and /sbin/init invain) I found an empty /dev directory: Tar -l does not recurse into other filesystems. I use this option to avoid recursion on /kern/rootdev. Since I have fdesc union-mounted to /dev, tar won't backup /dev. Ooops. After rebuilding /dev the system booted fine... Martin P.S.: please, no comments about tar vs. dump; you just have to use both of them the right way. -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 02:45:29 1994 From: William J Coldwell To: msanders@eng.utah.edu Subject: Re: aaaaaiiiiiiieeee! Cc: amiga@sun-lamp.cs.berkeley.edu (Amiga) Sender: owner-amiga@sun-lamp.cs.berkeley.edu > /dev/sd6d /usr ufs rw 1 1 _IF_ the 1st partition is the NetBSD partition on the drive. >And then newfs'ed the partition. I then wanted to use bffs to move >all the other tar.gz files over, so I synced and rebooted. BFFS will not WRITE correctly anymore. But I guess that's a little late for you :-(. >having the kickstart image on HD, BUT, unfortunately that image >was lost when the HD got corrupted... So, anyone know where I can Are you sure you newfs'd the right partition? You do _not_ want to accidently newfs the wrong one. I spent this weekend recovering from newfs'ing my /dev/sd0a when I meant to disklabel /dev/sd0a early in the morning.. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 03:18:00 1994 From: Source Librarian Subject: D'oh! To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1653 Sender: owner-current-users@sun-lamp.cs.berkeley.edu (it looks like a message I sent to the current-users list last week got dropped.... if it comes around, I apologize for the repeated info) D'oh! I RTFM'd the man page for the group file for -current, and it stated that the list of users for a group has to be deliniated by commas -- oops. Sorry for the wasted bandwidth. On another note, has anyone been using tcsh 6.04 or 6.05 with -current? Here is something really strange that didn't happen with 0.9 (release). What's happening is that when I telnet from an HP (847/H30 running HP/UX 9.04) to our Dell 450/MX running -current (7/24 kernel + 7/13 userland binaries), tcsh "mangles" newlines. Instead of going to the beginning of the next line, it (in a lot of cases) does a simple linefeed and continues on. For example, when I'm using tcsh 6.05 and I do an ls, it comes out like: dingo% ls Mail/ archie/ XF/ tcp_wrapper.tar.Z dingo% This behavior doesn't happen when I telnet from a 0.9 (release) machine, only from our HP-UX machine. What makes it even more strange is that sometimes I can make it work by just logging out of the session and logging back in (works about 1/5 of the time). Even more weird: if I telnet from the HP to the 0.9 machine, and then [from 0.9] telnet to the -current machine, tcsh behaves nicely, so I don't think it's HP/UX's telnet. I don't think I can blame -current, because /bin/csh and /bin/sh work fine. I tried every stty setting, and the results are the same. Any ideas? A bug with tcsh? -Henry (src@bsginc.com) From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 03:44:38 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: fixed scripts to build 3.5" floppies Sender: owner-current-users@sun-lamp.cs.berkeley.edu I needed to bring up 1.0_BETA on a new machine, so I grabbed the scripts posted by Christos Zoulas . They didn't quite work for me, so I hacked/fixed them to build a stock 3.5 set of 3 floppies. I was able to install today with the floppies built by the script. The shar available via anon-ftp on ftp.fcr.com in pub/boot.shar (or ftp://ftp.fcr.com/pub/boot.shar for the html-aware) -brad ps: during the the process of installing the new machine I grabbed the current freebsd install floppies (1.1.5.1) and did a basic install with them. I must say, the freebsd install proceedure is very smooth and worked quite well. About 90% of their defaults where correct and if I had use them all, it would have worked. IMHO for the disk geometry section this is a big win (since most people have no clue about such things). whom ever worked on their install scripts/procedure deserves some credit... when I did the same thing for netbsd it worked, but there were no defaults and at one point it asked me for the "2nd disk" when it really ment the "3rd disk" (I know, the kernel disk does not count - but this was confusing and when I invariably put the wrong disk in I was hosed). From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 04:15:16 1994 To: Source Librarian Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: D'oh! From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Sun, 31 Jul 1994 18:54:13 -0500 (CDT) Source Librarian wrote: > > dingo% ls > Mail/ archie/ > XF/ tcp_wrapper.tar.Z > dingo% This is due to a slight incompatibility between the new telnetd and older versions of telnet...(You see this on NeXTs as well...) You can kludge support for the old, broken versions of telnet by passing telnetd the '-k' flag in inetd.conf. Works great for me... BTW...I see that you're looking at running the CERT tcp wrappers :-) My experience with them has been great. However, I have yet to get tcpd to DTRT with telnetd...It works fine with an older, more limited tcp wrapper available from OGI.EDU (in.gate)...Anybody else had this experience? Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 1 05:06:03 1994 From: Arthur Hoffmann Subject: silo overflows. To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 528 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi What do I have to do to get rid of the silo overflow problem I'm experiencing with my NetBsd-Amiga? There was a time I had none of those messages, but ever since the buffer size of the serial port was changed a few month ago the silo overflow kept on popping up again. Where are those buffers in the kernel souce and what are reasonable values to set them to? Thanks. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 05:12:18 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: Archive Viper 150 not working with 1.0_BETA Sender: owner-amiga@sun-lamp.cs.berkeley.edu My Archive Viper tape drive no longer seems to be working under 1.0_BETA. (940726 sup) using the A3000 kernel. Whenever I attempt to access the drive, I get the following errors: st0(ahsc0:4:0): illegal request st0: cannot set selected mode But it appears to be found during autoconfig: ahsc0 targ 4 lun 0: SCSI1 sequential removable st0 at scsibus0: rogue, density code 0x0, 512-byte blocks, write-enabled Please help. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 06:42:37 1994 From: tjhayko@io.org Subject: How do I boot with the bootfloppy? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 415 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've downloaded the new snapshot from rrzs3.rz.uni-regensburg.de that Bill & Chris put together, and I'm not really sure where to start. I've unDMSed the bootfloppy to a floppy, but how do I use it? I've tried doing a loadbsd of the kernel with the bootfloppy in the drive, but it still boots from my old rootfs on my hard disk. Can anybody give me some pointers? Thanks in advance. Tom Hayko tjhayko@io.org From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Aug 1 07:05:59 1994 From: Arthur Hoffmann Subject: connection refused by server To: amiga-X@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 703 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hi I have been running X for quite a while now with no problems. I used to start it with "startx" and it worked equally well for root as for users. Now I decided to get xdm going but I seem to have a problem. root access is fine, as before, but users don't work anymore, I get the following error message: Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server I had a look in the NetBSD-X faq, but couldn't find anything in there. What are the most obvious things to look for? Thanks for any help. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 07:14:31 1994 From: William J Coldwell To: tjhayko@io.org Subject: Re: How do I boot with the bootfloppy? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu PLEASE PLEASE wait for the installation doc that I'm finishing up. I'm trying to get it completed in the next few hours. It will save you the headaches (I'm still taking 800mg of Motrin ;-). -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 07:26:21 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: anybody got wine-940722 working on i386/1.0_BETA kernel? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can't get wine-940722 working on my 1.0_BETA kernel at home. solitaire dies in the same place (the popw %es from "pop.h" inside ReturnFromRegisterFunc in call.S). I've tried using gas-1.92.3 and gas-2.3, but neither make it work. anybody else had success? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 07:30:48 1994 From: wormey@eskimo.com (Space Case) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: Help? Cannot sup. X-Face: "xBPo9!">8y'(?p*x6YoBWQt("0IGaWVZg~m}tIO}lHE/P+j"2@<@C,Ge|9/FPn]XWr5M"f`+SQLFkO Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm having a bit of trouble getting sup going, and I was wondering if anybody could help me. I am running 1.0-alpha on the Mac, have rebuilt sup and term (v. 1.18). I connect up with term, it works OK, so far as I know. (trsh ls returns output from the other side.) I think I may have a configuration problem. Here is some statistics: <4 wormhole //># netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Interface default 127.0.0.1 UGS 0 0 lo0 127.0.0.1 127.0.0.1 UH 2 6 lo0 132.224.92 link#1 UC 0 0 ae0 132.224.92.16 127.0.0.1 UGHS 1 32 lo0 132.224.93.16 127.0.0.1 UH 0 0 lo0 162.148.13.255 132.224.93.16 UH 0 0 sl0 XNS: Destination Gateway Flags Refs Use Interface <5 wormhole //># netstat -in Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll ae0 1500 2.60.8c.88.29.48 1 0 3 0 0 ae0 1500 132.224.92 132.224.92.16 1 0 3 0 0 lo0 32768 38 0 38 0 0 lo0 32768 127 127.0.0.1 38 0 38 0 0 sl0 296 0 0 0 0 0 sl0 296 132.224.93 132.224.93.16 0 0 0 0 0 ppp0* 1500 0 0 0 0 0 <6 wormhole //># ps PID TT STAT TIME COMMAND 96 co Is 0:08.45 -tcsh (tcsh) 109 co S+ 0:10.98 dt 110 p0 Is+ 0:05.07 -tcsh (tcsh) 111 p1 Is+ 0:05.29 -tcsh (tcsh) 112 p2 Ss 0:05.45 -tcsh (tcsh) 156 p2 S 0:02.50 term -v /dev/tty00 161 p2 I 0:00.06 tredir 871 sun-lamp.cs.berkeley.edu:871 164 p2 R+ 0:00.67 ps I am not currently running anything over slip or enet. Thanks, ~Steve -- Steven R. Allen - wormey@eskimo.com The opposite of a profound truth may well be another profound truth. -- Bohr From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 08:37:16 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: wormey@eskimo.com (Space Case) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Help? Cannot sup. <199408010342.AA08175@eskimo.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu wormey@eskimo.com (Space Case) writes: > I'm having a bit of trouble getting sup going, and I was wondering if > anybody could help me. > > I am running 1.0-alpha on the Mac, have rebuilt sup and term (v. 1.18). > I connect up with term, it works OK, so far as I know. (trsh ls returns > output from the other side.) I think I may have a configuration > problem. Here is some statistics: You can't run sup over a term connection, at least not the last time I checked. Term is not a true network connection, and each program which runs over it must be specifically written to use it. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 08:38:22 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Jason Thorpe Cc: Source Librarian , current-users@sun-lamp.cs.berkeley.edu Subject: Re: D'oh! <9408010057.AA01238@research.CS.ORST.EDU> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Jason Thorpe writes: > This is due to a slight incompatibility between the new telnetd and > older versions of telnet...(You see this on NeXTs as well...) > > You can kludge support for the old, broken versions of telnet by passing > telnetd the '-k' flag in inetd.conf. I think the core team should consider making this standard for 1.0. Very few systems run the new version of telnet. Most notably, both SunOS 4.1.3 and Solaris 2.3 use the old telnet, and telnetting from one of them to my system barfed until I put in the -k. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 09:45:10 1994 From: Christos Zoulas "D'oh!" (Jul 31, 6:54pm) Organization: D. E. Shaw & Co. X-Address: Tower 45, 120 West 45th St., 39th Floor, New York, N.Y. 10036 X-Phone: (212) 478 0000 X-Fax: (212) 478 0101 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Source Librarian , current-users@sun-lamp.cs.berkeley.edu Subject: Re: D'oh! Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 31, 6:54pm, src@bsg.bsginc.com (Source Librarian) wrote: -- Subject: D'oh! | On another note, has anyone been using tcsh 6.04 or 6.05 with -current? Here | is something really strange that didn't happen with 0.9 (release). What's | happening is that when I telnet from an HP (847/H30 running HP/UX 9.04) to | our Dell 450/MX running -current (7/24 kernel + 7/13 userland binaries), | tcsh "mangles" newlines. Instead of going to the beginning of the next line, | it (in a lot of cases) does a simple linefeed and continues on. For example, | when I'm using tcsh 6.05 and I do an ls, it comes out like: | | dingo% ls | Mail/ archie/ | XF/ tcp_wrapper.tar.Z | dingo% | | This behavior doesn't happen when I telnet from a 0.9 (release) machine, only | from our HP-UX machine. What makes it even more strange is that sometimes I | can make it work by just logging out of the session and logging back in | (works about 1/5 of the time). Even more weird: if I telnet from the HP to | the 0.9 machine, and then [from 0.9] telnet to the -current machine, tcsh | behaves nicely, so I don't think it's HP/UX's telnet. | | I don't think I can blame -current, because /bin/csh and /bin/sh work fine. | I tried every stty setting, and the results are the same. Any ideas? A bug | with tcsh? Please read the FAQ file that comes with tcsh, particulary section 14 substituting cray with 4.4BSD: 14. On the cray, sometimes the CR/LF mapping gets screwed up. You are probably logged in to the cray via telnet. Cray's telnetd implements line mode selection the telnet client you are using does not implement telnet line mode. This cause the Cray's telnetd to try to use KLUDGELINEMODE. You can turn off telnet line mode from the cray side by doing a "stty -extproc", or you can get the Cray AIC to build a telnetd without KLUDGELINEMODE, or you can compile a new telnet client (from the BSD net2 tape), or at least on the suns use: 'mode character'. This is definitely not tcsh fault; all the shells that use command line editing suffer the same way. Try set -o emacs in the bourne shell... christos From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Aug 1 10:13:21 1994 From: Arthur Hoffmann Subject: Re: connection refused by server To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: amiga-X@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 884 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I wrote: > Hi > I have been running X for quite a while now with no problems. I used > to start it with "startx" and it worked equally well for root as for > users. > > Now I decided to get xdm going but I seem to have a problem. > root access is fine, as before, but users don't work anymore, I get > the following error message: > > Xlib: connection to ":0.0" refused by server > Xlib: Client is not authorized to connect to Server > > I had a look in the NetBSD-X faq, but couldn't find anything in there. > > What are the most obvious things to look for? > > Thanks for any help. Sorry for the wasted bandwidth, but I found the problem myself. My DISPLAY environment variable wasn't accepted somehow. I used to have it set to :0.0 (as I said it works with the startx script) For xdm I had to set it to 'atze:0' Does anyone know why this has to be this way? Thanks. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 10:20:40 1994 From: wormey@eskimo.com (Space Case) "Re: Help? Cannot sup." (Aug 1, 12:55am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mark_Weaver@brown.edu Subject: Re: Help? Cannot sup. Cc: current-users@sun-lamp.cs.berkeley.edu X-Face: "xBPo9!">8y'(?p*x6YoBWQt("0IGaWVZg~m}tIO}lHE/P+j"2@<@C,Ge|9/FPn]XWr5M"f`+SQLFkO Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Aug 1, 12:55am, Mark_Weaver@brown.edu wrote: > >wormey@eskimo.com (Space Case) writes: >> I'm having a bit of trouble getting sup going, and I was wondering if >> anybody could help me. >> >> I am running 1.0-alpha on the Mac, have rebuilt sup and term (v. 1.18). >> I connect up with term, it works OK, so far as I know. (trsh ls returns >> output from the other side.) I think I may have a configuration >> problem. Here is some statistics: > >You can't run sup over a term connection, at least not the last >time I checked. Term is not a true network connection, and each >program which runs over it must be specifically written to use it. > Hell, I used to. That's what tredir is for, is to route an IP port through the serial connection. :) ~Steve -- Steven R. Allen - wormey@eskimo.com Absentee, n.: A person with an income who has had the forethought to remove himself from the sphere of exaction. -- Ambrose Bierce, "The Devil's Dictionary" From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 10:54:36 1994 From: Arthur Hoffmann Subject: Re: Help? Cannot sup. To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1213 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > wormey@eskimo.com (Space Case) writes: > > I'm having a bit of trouble getting sup going, and I was wondering if > > anybody could help me. > > > > I am running 1.0-alpha on the Mac, have rebuilt sup and term (v. 1.18). > > I connect up with term, it works OK, so far as I know. (trsh ls returns > > output from the other side.) I think I may have a configuration > > problem. Here is some statistics: > > You can't run sup over a term connection, at least not the last > time I checked. Term is not a true network connection, and each > program which runs over it must be specifically written to use it. > > Mark > -------------------------------------------------------------------- > Email: Mark_Weaver@brown.edu | Brown University > PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science > Sup can be run with a term connection. Before you do the sup you have to type in the following: tredir 871 sun-lamp.cs.berkeley.edu:871 then use sup as usual. I get all my kernel-src updates using this method for month now. :) Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 12:02:12 1994 To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu, wormey@eskimo.com (Space Case) Subject: Re: Help? Cannot sup. <199408010455.AAA04507@localhost> From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu >You can't run sup over a term connection, at least not the last >time I checked. Term is not a true network connection, and each >program which runs over it must be specifically written to use it. but you *can* redir the supfilesrv port on the local machine to sun-lamp's supfilesrv port, and the set up the sup file to connect to the local machine. i know lots of people who sup this way (infact, in a day or two, i'll be one of them.. at least, with term's successor ;-) .mrg. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 1 12:33:32 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Re: Archive Viper 150 not working with 1.0_BETA To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1097 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > My Archive Viper tape drive no longer seems to be working under > 1.0_BETA. (940726 sup) using the A3000 kernel. Whenever I attempt to > access the drive, I get the following errors: > > st0(ahsc0:4:0): illegal request > st0: cannot set selected mode > > But it appears to be found during autoconfig: > > ahsc0 targ 4 lun 0: SCSI1 sequential removable > st0 at scsibus0: rogue, density code 0x0, 512-byte blocks, write-enabled This also happens to me using my Sankyo CP150E QIC streamer. This appeared for me using the 940709 kernel, but I have been away from NetBSD for some time, so this might even be an older problem. My guess is that it is because my Sankyo is only SCSI-1 and I guess someone implemented some SCSI-2 commands... > Please help. > > -SR Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 12:35:22 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: INSTALL doc - prerelease. Sender: owner-amiga@sun-lamp.cs.berkeley.edu Please proof for errors... send changes back to me in *E-MAIL*. Feel free to add to it. -- SOF -- Installing NetBSD-Amiga (4.4BSD UNIX) August 1st, 1994 Abstract: This document contains the very hastily written instructions for the installation the NetBSD-Amiga 1.0 (4.4BSD release of UNIX) release. NetBSD-Amiga Mailing List: majordomo@sun-lamp.cs.berkeley.edu EMail: billc@icecube.cryogenic.com CryoCafe BBS: 1-503-257-4823 IRC: #NetBSD and #Amiga NetBSD-Amiga Release 1.0 will be available on a QIC-120/150 (DC6120/DC6150) 1/4" tape from this address for US$30. NetBSD-Amiga Port c/o William Coldwell P.O. Box 16924 Portland, Oregon 97216-0924 USA SYSTEM REQUIREMENTS ~~~~~~~~~~~~~~~~~~~ Supported Standard Amigas: A4000/040, A3000, A2500/030, A2500/020 Configuration Requirements: Machine: Amiga CPU/FPU/MMU: M68020-CPU/MC68881*-FPU/M68851-MMU M68030%-CPU-MMU/MC68881*-FPU MC68040-CPU-MMU-FPU * - MC68882-FPU is acceptable % - M68EC030 is not acceptable Memory: 4 Megabytes of contigious FAST RAM or more 1 Megabytes of CHIP RAM or more Disk: 100 Megabytes of free space or more Tape: Most SCSI tape controllers, including Archive Viper, Cipher SCSI-2 ST150. Disk controller: A4000 IDE A3000 SCSI A2500 SCSI (A2091) A4091 SCSI-2 Supra WordSync SCSI GVP Series II SCSI IVS SCSI CSA Twelve Gauge SCSI CSA Magnum SCSI MacroSystem Development WarpEngine SCSI-2 Supported External Filesystems: AmigaDOS ISO-9660 (CDROM) Video controller: AGA-NTSC/PAL (15/31kHz) ECS-NTSC/PAL (15kHz) ECS-A2024-NTSC/PAL (15kHz/10Hz) Noahji (MacroSystem US) Retina Network controller: A2065 Ethernet Hydra Ethernet Input device: 2 button mouse 3 button mouse Files: ~~~~~~ release/bootfloppy.dms (REQUIRES DMS unarchiver) release/base.tar.gz (required) release/etc.tar.gz (required) release/netbsd.gz (required) tools/loadbsd.gz (required) release/comp.tar.gz (recommended) release/games.tar.gz (recommended) release/man.tar.gz (recommended) release/misc.tar.gz (recommended) release/text.tar.gz (recommended) FTP Sites: ~~~~~~~~~~ ftp.uni-regensburg.de pub/NetBSD-Amiga/release/* Disk space: ~~~~~~~~~~~ 15M for root (/) (or more) 2 * FAST RAM Megabytes for swap (i.e., 8M system == 16M swap) 45M for /usr (add 20M for sys-src, add 35M extra for X) (or more) Full Install: ~~~~~~~~~~~~~ If you have a system that meets the above requirements, and you want to check out NetBSD-Amiga, you will need to create some partitions on your harddrive(s) for it. Use the example below as a loose guide. The main thing is that you want to create a ROOT, SWAP, and USR partition of at _least_ the recommended sizes. You will have to take special note to watch the SCSI UNIT, as it has relevence on the /dev/sdX number. IMPORTANT: READ AND UNDERSTAND THIS, OR YOU WILL BE SORRY LATER ~~~~~~~~~~ Say your system has 3 SCSI devices (note: IDE drives will show up as SCSI devices under NetBSD), IDs 0, 3, and 4. These will now show up as sd0 (ID 0), sd1 (ID 3) and sd2 (ID 4). The higher the ID of the device is, the higher sd will increment. Write the IDs to sd# down! If you NetBSD partitions are on the SCSI drive at ID3, then your NetBSD system will be on /dev/sd1 - replace any references to /dev/sd0x with /dev/sd1x in the examples! An Example of a clean installation on an A4000. A4000/IDE Installation ~~~~~~~~~~~~~~~~~~~~~~ (or How Bill got NetBSD running on a an A4000/single IDE installation) You will need your 3.0 (or above) Commodore Installation diskettes. Backup anything important on your IDE drive, as it will be deleted. You will have 30M available on your IDE to hold the installation files, and your Workbench. Partition your harddrive with HDtoolbox: Select the IDE drive, and click on Partition drive. *WARNING* This is a permanent thing, so please make sure that if you have anything important, that you have backed it up on floppies or tape. Delete all your existing partitions (usually called Workbench and Work) on your IDE harddrive, by selecting a partition, and clicking on Delete Partition. You will create 4 partitions. 1st partition: Click New Partition. Click in the next free area. size = 30M AMIGADOS Partition Device Name = BSDBOOT BSDNAME = /dev/sd0d Adv. Options, Click on Change... Click File System: until you see Fast File System Turn ON Automount this partition, if it is not checked. Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option *) Click OK. * If you don't, you will not be able to mount the partition under NetBSD. 2nd partition: Click New Partition. Click in the next free area. size = 15M Partition Device Name = BSDROOT BSDNAME = /dev/sd0a Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425207 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. 3rd partition: Click New Partition. Click in the next free area. size = (the size of your contigious FAST RAM) * 2 Partition Device Name = BSDSWAP BSDNAME = /dev/sd0b Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425301 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. 4th partition: Click New Partition. Click in the next free area. size = remaining free space on the IDE. (46 or more Megabytes) Partition Device Name = BSDUSER BSDNAME = /dev/sd0e Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425507 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. Double check everything to make sure it's correct, then click on Save Changes to Drive. When you click Exit, your machine will not reboot. You will want to place the Install disk of the Commodore 3.0 (or above) Operating System, into your floppy, and install onto the BSDBOOT partition. You may need to boot off of the Workbench disk and Format the BSDBOOT partition, before Installing. ONCE YOU HAVE YOUR PARTITIONS SET UP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now, you need to get the required files on to the root directory of the AmigaDOS partition. Use a terminal program, tape drive, or copy them from another drive. Now you are ready to enter a new world. BOOTING INTO NETBSD ~~~~~~~~~~~~~~~~~~~ AmigaShell> loadbsd -b netbsd It should boot up and ask you which device you wish to boot off of. Make sure the bootfloppy disk is in the drive, and enter: fd0 and press return. This will cause the NetBSD kernel to boot off of the boot floppy in DF0:. newfs /dev/sd0a (erase it, set it up for NetBSD) -- "newfs: ioctl(WDINFO): Invalid argument." This warning is ok, just ignore it. The Amiga doesn't write disk labels (and returns an error to indicate that the attempt to write the label did not suceed). Any changes to the disk "label" still have to be done through and RDB editor. -- newfs /dev/sd0e (erase it, set it up for NetBSD) mount /dev/sd0a /altroot (mount root) mkdir /altroot/usr (make usr dir) mount /dev/sd0e /altroot/usr (mount usr on sd0e or whatever) mount_ados /dev/sd0d /mnt (mount ados partition) cd /altroot (cd to newroot) tar -zxvf /mnt/netbsd.gz (extract kernel) tar --unlink -zxvpf /mnt/base.tar.gz (extract base) tar --unlink -zxvpf /mnt/etc.tar.gz (extract the rest of etc) ==== Optional |tar --unlink -zxvpf /mnt/comp.tar.gz (extract gcc and tools) |tar --unlink -zxvpf /mnt/games.tar.gz (extract games and fun stuff) |tar --unlink -zxvpf /mnt/man.tar.gz (extract man pages) |tar --unlink -zxvpf /mnt/misc.tar.gz (extract miscellaneous stuff) |tar --unlink -zxvpf /mnt/ext.tar.gz (extract text tools and docs) ===== cd /altroot/dev (cd dev) tar -cf - /dev | tar -xvpf - (copy device files from floppy) /altroot/sbin/umount /altroot/usr (unmount usr) /altroot/sbin/mount -u -r /altroot (make new root read only) /altroot/bin/sync (sync whatever for safety) /altroot/sbin/reboot (reboot system) You'll end up in single-user mode, at which you can: mount /dev/sd0a / mount /dev/sd0e /usr cd /etc vi fstab (I hope you know how to use vi). You will want to edit the fstab file to correctly represent your / and /usr devices, as well as uncomment and edit the swap. Once you save this, you should then be able to enter multiuser mode. login: root (no password) You're in (hopefully). If all is well, then you should examine the other NetBSD-Amiga FAQs to set your system up. UPGRADING YOUR EXISTING NETBSD-0.9c SYSTEM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the NetBSD tar.gz files onto a spare area on your system {place}. This also includes a tape drive, if you are going to use one. NO MORE ROOTFS.GZ. That's right. It's history. Just make sure that you have enough space Do NOT unarchive etc.tar.gz, unless you are prepared for system specific files to be nailed in /etc (group, passwd, etc). As root: cd / tar -zxf {place}netbsd.gz (extract kernel) tar --unlink -xvzpf {place}base.tar.gz (extract base) tar --unlink -zxvpf {place}comp.tar.gz (extract gcc and tools) tar --unlink -zxvpf {place}games.tar.gz (extract games and fun stuff) tar --unlink -zxvpf {place}man.tar.gz (extract man pages) tar --unlink -zxvpf {place}misc.tar.gz (extract miscellaneous stuff) tar --unlink -zxvpf {place}ext.tar.gz (extract text tools and docs) You will have to edit your fstab to denote the ID changes (if applicable). Use disklabel to make sure things are where you think they are. REPORTING PROBLEMS ~~~~~~~~~~~~~~~~~~ Basically the kernel diags (things like boot messages and register dumps after panics) are stored in the last page of memory. These messages survive reboot so that if you have to get at them you can. The utility of choice is dmesg. Which prints this memory out. Thus if you get a panic with a register dump, instead of copying it down by hand you can simply reboot and then redirect dmesg to a file. Chris. [send this edited information to the mailing list for help] SOME HELPFUL HINTS THROWN IN. MOST HAVE BEEN CUT FROM THE MAILING LIST ======================================================================= (names have been lost, but thanks to those who gave the answers to us) A few NetBSD-Amiga WWW servers do exist. The Main one is done by Matthias Kirschnick and includes links to other NetBSD information sites. Matthias Kirschnick's NetBSD-Amiga-page > Is there a NetBSD/Amiga Web server out there? If not, then I may be Try http://dusk.rz.uni-regensburg.de/. This is a A2000 running NetBSD, and there's also a section on NetBSD on this machine. ====================================================================== > Right - as distributed, /etc/ttys runs getty on the ite0 Amiga display, > rather than "console" which would go to the configured console device. Yes and this is correct. You should enable getty's on whichever devices you want them on. The console /dev/console should always be marked as *off* however. ====================================================================== >I see when I boot the kernel: >warning found rdb->secpercyl(1098) != rdb->nsectors(74) * rdb->nheads(15) >warning lp->d_sparespercyl(12) not multiple of lp->d_ntracks(15) This is fine, this is telling you that your RDB has some conflicting values. If the partitions mount under NetBSD, then it's safe to ignore them. If they don't, then use dmesg to copy the values down and give us a yell on the mailing list. ====================================================================== > TIMEZONE = 800, DST = 1 is what I > thought it should be for me (Portland, OR, +8 GMT), but it tells me that the > time under netbsd is 7 hours slower than what the Amiga side says... what am > I missing? The TIMEZONE and DST config options set something in the kernel data (at least I think the TIMEZONE does, but I'm not sure about DST - I think when I went looking, it was never referenced anywhere). The kernel doesn't do anything at all with that data. I think there's a something that needs to be set up in /usr/share somewhere that deals with the timezones. I've never done it, so my NetBSD time is the same as AmigDOS - but NetBSD considers that time value GMT, which can cause confusion at times. Also, I don't think the stuff in /usr/share is used until you go to multi-user, so the time would probably be reported differently in single user vs multi user mode. The clock read routine just gets the current time from the Amiga clock and uses that time as-is, with no adjustments. I had thought about adjusting it based on the TIMEZONE, but never got around to trying it. Trying to handle DST in the kernel isn't as easy to do. ====================================================================== From: spcmilo@hydra.spc.uchicago.edu (David Champion) Not knowing of any such utility already existing, I came up with this braindead rexx program to reset system time under ADOS to local so that I can keep the battmem time in GMT for BSD's sake. (Well, I like keeping GMT.) I call it from s:User-Startup, right after loading rexxmast: sys:rexxc/rx rexx:warpdate.rexx Obviously, there's much room for improvement, but it does the job well enough. Even without going into detail, it should probably take the GMT offset on the command line, and my offset should probably be negative, not positive. Oh well. Anyway, thought someone might want it. /* warpdate.rexx */ /* adjust current time so battclock can keep GMT */ /* CONFIGURE HERE */ /* number of minutes short of GMT */ off = 300 /* STOP CONFIGURING */ /* do not change day by default */ changeday = '' /* find minutes after midnight */ mins = time('m') /* adjust minutes */ mins = mins - off /* if we go back a day, adjust minutes and changeday flag */ if mins < 0 then do mins = 1440 + mins changeday = 'yesterday' end /* if we go ahead a day, adjust minutes and changeday flag */ if mins > 1439 then do mins = 1440 - mins changeday = 'tomorrow' end /* extract new hour from minutes; set minutes to minutes since hour */ hour = trunc(mins / 60) mins = mins - (hour * 60) /* update seconds */ tmp = time('m') secs = time('s') secs = secs - (tmp * 60) /* create an amigados 'date' command */ datestr = 'date 'changeday' 'hour':'mins':'secs /* and change the clock */ address command datestr ====================================================================== [stolen from one of Gunther's FAQ] Hall of Fame [outdated] ---============--- Alan Bair, abair@amcu-tx.sps.mot.com, Fontdumper, Rootfs. Stefan G. Berg, sgberg@charon.bloomington.in.us, Writing documentation. Dave Blaszyk, dvb@ssd.kodak.com, a driver for IVS Vector Philippe Brand, PhB@telesys-innov.fr, X-server for custom chips, X-server for Retina. David Crooke, dcc@dcs.ed.ac.uk, Writing an installation-document. William J. Coldwell, billc@icecube.cryogenic.com, Maintaining the Mailing-List in the old days, Various programming. Guenther Grau, s_grau@ira.uka.de, Extensively writing documents. Niklas Hallqvist, niklas@appli.se, Porting the Mach VM system, that NetBSD-Amiga uses, Driver for GVP, Porting ADos-FS to NetBSD-Amiga. Rob Healey, rhealey@aggregate.com, a L0T of bug-fixes. Andy Heffernan, ahh@netcom.com, Porting GDB, compiling X11R5. Michael L. Hitch, osymh@montana.edu, Support for the 68040, Drivers for various SCSI-devices, changing loadbsd, fixing bugs, 5380-Driver, AGA-modes for the console and X, A4000 IDE driver, a L0T of bug-fixes, Implementing a floppy-driver, IVS-Vector-driver etc. Chris Hopps, chopps@emunix.emich.edu, Support for the custom chips, Reintegrating the changes back to the NetBSD-current source tree, fixing bugs and (re-)designing some of the code. Main coordinator of the source. ADos-Filesystem. Eduardo E. Horvath, eeh@btr.com, X11R5-Mono-Server. Markus Illenseer, markus@TechFak.Uni-Bielefeld.de, Writing documentation, Porting X-clients. 0liver Lahaye, lahaye_o@epita.fr, X-server for custom chips, X-server for Retina. Brad Pepers, pepersb@cuug.ab.ca, Implementing a floppy-driver. 0liver Raoul, raoul_o@epita.fr, X-server for custom chips, X-server for Retina. Stephen J. Roznowski, sjr@zombie.ncsc.mil, Building binaries from sun-lamp sources. Ty Sarna, tsarna@endicor.com, Various programming, Installation. Roy Trevino, rtrevino@sedona.intel.com, X11R5-Mono-Server. Lutz Vieweg, lkv@mania.RoBIN.de, providing information and writing a tty-device-driver for the Retina Z3 Markus Wild, mw@eunet.ch, Initially started the port of NetBSD-current to the Amiga, still working on various projects. [Others include Ken Dyke for 040 MMU code, and probably a couple of others who didn't send me e-mail in time for this document. Also, we give thanks to the NetBSD core team members, for which there wouldn't be a port at all.] -- EOF -- -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 1 12:54:28 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Re: drive to sdX assignments (Was: no title) To: chopps@emunix.emich.edu (Chris Hopps) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1410 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I just removed the hardcoding of targets to sd unit numbers. I decided > I did not want to live with this mistake through release. > > Basically this means that GENERIC will configure your sd drives like so: > > say your system has 3 drives, targets 0,3,4 these will now show up as > sd0 (target 0), sd1 (target 3) and sd2 (target 4). If you run GENERIC > you to change your fstab after upgrading to a newer kernel. > > These changes haven't yet made it into the release branch though and the > kernel on lamp is still using the old way. The next one (hopefully) won't > though. Please, wait a minute! I have a temporarily changing system. i.e. sometimes I have my little LPS240 attached and sometimes not. If this change is going to be made, this is going to invalidate my /etc/fstab as my internal drive, which is unit 6 will some- times be sd0 and sometimes sd1... :-( I don't think this is a good idea... On the other hand, I don't want to attach the LPS240S permanently as it is quite loud (it's in an external disk drive case only which doesn't give good noise absorption...). > Chris. > Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 13:05:53 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: pccons patch for non-US keyboards. X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 10569 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since I got more than 2 requests for it, here is my patch to pcccons. It's not french specific, but it only has a mapping defined for my french keyboard. To use it with another keyboard, you'll first have to add your own table: 1. Choose an option name (for example GERMAN_KBD) 2. At the beginning of pcccons.c add ''|| defined(GERMAN_KBD)'' after #if defined(FRENCH_KBD) to enable NONUS_KBD and DISPLAY_ISO8859 3. Look for 'XXXX Add tables' to see where to add your table. For non-us keyboards the struct scan_def as one more field to hold the Alt-GR map. Insert you definition of the scan_codes[] array between a set of #ifdef GERMAN_KBD .. #endif. 4. Add 'option GERMAN_KBD' to your kernel config file and rebuild your kernel. 5. Reboot. If you're switch back from pcvt, make sure that the ttyv[0-9] entries in /etc/ttys are commented out. ttyflags -a causes a kernel crash when they are there and no kernel support for them is present. *** /sys/arch/i386/isa/pccons.c.050594 Thu May 5 13:11:11 1994 --- pccons.c Sun Jul 31 13:20:44 1994 *************** *** 81,86 **** --- 81,94 ---- #define PCBURST 128 + /* + * Non-US keyboards definition + */ + #if defined(FRENCH_KBD) + # define NONUS_KBD + # define DISPLAY_ISO8859 + #endif + extern u_short *Crtat; /* pointer to backing store */ static u_short *crtat; /* pointer to current char */ static volatile u_char ack, nak; /* Don't ask. */ *************** *** 137,142 **** --- 145,153 ---- #define FUNC 0x0100 /* function key */ #define KP 0x0200 /* Keypad keys */ #define NONE 0x0400 /* no function */ + #ifdef NONUS_KBD + #define ALTGR 0x0040 /* Alt graphic */ + #endif static unsigned int addr_6845 = MONO_BASE; *************** *** 726,731 **** --- 737,764 ---- BG_MAGENTA, BG_CYAN, BG_LIGHTGREY }; + #ifdef DISPLAY_ISO8859 + static u_char iso2ibm437[] = + { + 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, + 0, 0, 0, 0, 0, 0, 0, 0, + 0xff, 0xad, 0x9b, 0x9c, 0, 0x9d, 0, 0x40, + 0x6f, 0x63, 0x61, 0xae, 0, 0, 0, 0, + 0xf8, 0xf1, 0xfd, 0x33, 0, 0xe6, 0, 0xfa, + 0, 0x31, 0x6f, 0xaf, 0xac, 0xab, 0, 0xa8, + 0x41, 0x41, 0x41, 0x41, 0x8e, 0x8f, 0x92, 0x80, + 0x45, 0x90, 0x45, 0x45, 0x49, 0x49, 0x49, 0x49, + 0x81, 0xa5, 0x4f, 0x4f, 0x4f, 0x4f, 0x99, 0x4f, + 0x4f, 0x55, 0x55, 0x55, 0x9a, 0x59, 0, 0xe1, + 0x85, 0xa0, 0x83, 0x61, 0x84, 0x86, 0x91, 0x87, + 0x8a, 0x82, 0x88, 0x89, 0x8d, 0xa1, 0x8c, 0x8b, + 0, 0xa4, 0x95, 0xa2, 0x93, 0x6f, 0x94, 0x6f, + 0x6f, 0x97, 0xa3, 0x96, 0x81, 0x98, 0, 0 + }; + #endif + /* * `pc3' termcap emulation. */ *************** *** 865,870 **** --- 898,907 ---- * break to do a scroll check. */ for (;;) { + #ifdef DISPLAY_ISO8859 + if (c & 0x80) + c = iso2ibm437[c&0x7f]; + #endif if (vs.so) wrtchar(c, vs.so_at); else *************** *** 1179,1184 **** --- 1216,1222 ---- } #define CODE_SIZE 4 /* Use a max of 4 for now... */ + #ifndef NONUS_KBD typedef struct { u_short type; char unshift[CODE_SIZE]; *************** *** 1317,1322 **** --- 1355,1511 ---- NONE, "", "", "", /* 127 */ }; + #else /* NONUS_KBD */ + + typedef struct { + u_short type; + char unshift[CODE_SIZE]; + char shift[CODE_SIZE]; + char ctl[CODE_SIZE]; + char altgr[CODE_SIZE]; + } Scan_def; + + #ifdef FRENCH_KBD + + static Scan_def scan_codes[] = { + NONE, "", "", "", "", /* 0 unused */ + ASCII, "\033", "\033", "\033", "\033", /* 1 ESCape */ + ASCII, "&", "1", "&", "", /* 2 1 */ + ASCII, "e'", "2", "\211", "~", /* 3 2 */ + ASCII, "\"", "3", "\"", "#", /* 4 3 */ + ASCII, "'", "4", "'", "{", /* 5 4 */ + ASCII, "(", "5", "(", "[", /* 6 5 */ + ASCII, "-", "6", "-", "|", /* 7 6 */ + ASCII, "e!", "7", "\210", "`", /* 8 7 */ + ASCII, "_", "8", "\037", "\\", /* 9 8 */ + ASCII, "c,", "9", "\207", "^", /* 10 9 */ + ASCII, "a!", "0", "a!", "@", /* 11 0 */ + ASCII, ")", "DG", ")", "]", /* 12 - */ + ASCII, "=", "+", "+", "}", /* 13 = */ + ASCII, "\177", "\177", "\010", "\177", /* 14 backspace */ + ASCII, "\t", "\177\t", "\t", "\t", /* 15 tab */ + ASCII, "a", "A", "\001", "a", /* 16 q */ + ASCII, "z", "Z", "\032", "z", /* 17 w */ + ASCII, "e", "E", "\005", "e", /* 18 e */ + ASCII, "r", "R", "\022", "r", /* 19 r */ + ASCII, "t", "T", "\024", "t", /* 20 t */ + ASCII, "y", "Y", "\031", "y", /* 21 y */ + ASCII, "u", "U", "\025", "u", /* 22 u */ + ASCII, "i", "I", "\011", "i", /* 23 i */ + ASCII, "o", "O", "\017", "o", /* 24 o */ + ASCII, "p", "P", "\020", "p", /* 25 p */ + NONE, "", "", "", "", /* 26 [ */ + ASCII, "$", "Pd", "$", "$", /* 27 ] */ + ASCII, "\r", "\r", "\n", "\r", /* 28 return */ + CTL, "", "", "", "", /* 29 control */ + ASCII, "q", "Q", "\021", "q", /* 30 a */ + ASCII, "s", "S", "\023", "s", /* 31 s */ + ASCII, "d", "D", "\004", "d", /* 32 d */ + ASCII, "f", "F", "\006", "f", /* 33 f */ + ASCII, "g", "G", "\007", "g", /* 34 g */ + ASCII, "h", "H", "\010", "h", /* 35 h */ + ASCII, "j", "J", "\n", "j", /* 36 j */ + ASCII, "k", "K", "\013", "k", /* 37 k */ + ASCII, "l", "L", "\014", "l", /* 38 l */ + ASCII, "m", "M", "\r", "m", /* 39 ; */ + ASCII, "u!", "%", "\231", "u!", /* 40 ' */ + ASCII, "2S", "", "2S", "2S", /* 41 ` */ + SHIFT, "", "", "", "", /* 42 shift */ + ASCII, "*", "My", "*", "*", /* 43 \ */ + ASCII, "w", "W", "\027", "w", /* 44 z */ + ASCII, "x", "X", "\030", "x", /* 45 x */ + ASCII, "c", "C", "\003", "c", /* 46 c */ + ASCII, "v", "V", "\026", "v", /* 47 v */ + ASCII, "b", "B", "\002", "b", /* 48 b */ + ASCII, "n", "N", "\016", "n", /* 49 n */ + ASCII, ",", "?", ",", ",", /* 50 m */ + ASCII, ";", ".", ";", ";", /* 51 , */ + ASCII, ":", "/", "\037", ":", /* 52 . */ + ASCII, "!", "PI", "!", "!", /* 53 / */ + SHIFT, "", "", "", "", /* 54 shift */ + KP, "*", "*", "*", "*", /* 55 kp * */ + ALT, "", "", "", "", /* 56 alt */ + ASCII, " ", " ", "\000", " ", /* 57 space */ + CAPS, "", "", "", "", /* 58 caps */ + FUNC, "\033[M", "\033[Y", "\033[k", "", /* 59 f1 */ + FUNC, "\033[N", "\033[Z", "\033[l", "", /* 60 f2 */ + FUNC, "\033[O", "\033[a", "\033[m", "", /* 61 f3 */ + FUNC, "\033[P", "\033[b", "\033[n", "", /* 62 f4 */ + FUNC, "\033[Q", "\033[c", "\033[o", "", /* 63 f5 */ + FUNC, "\033[R", "\033[d", "\033[p", "", /* 64 f6 */ + FUNC, "\033[S", "\033[e", "\033[q", "", /* 65 f7 */ + FUNC, "\033[T", "\033[f", "\033[r", "", /* 66 f8 */ + FUNC, "\033[U", "\033[g", "\033[s", "", /* 67 f9 */ + FUNC, "\033[V", "\033[h", "\033[t", "", /* 68 f10 */ + NUM, "", "", "", "", /* 69 num lock */ + SCROLL, "", "", "", "", /* 70 scroll lock */ + KP, "7", "\033[H", "7", "", /* 71 kp 7 */ + KP, "8", "\033[A", "8", "", /* 72 kp 8 */ + KP, "9", "\033[I", "9", "", /* 73 kp 9 */ + KP, "-", "-", "-", "", /* 74 kp - */ + KP, "4", "\033[D", "4", "", /* 75 kp 4 */ + KP, "5", "\033[E", "5", "", /* 76 kp 5 */ + KP, "6", "\033[C", "6", "", /* 77 kp 6 */ + KP, "+", "+", "+", "", /* 78 kp + */ + KP, "1", "\033[F", "1", "", /* 79 kp 1 */ + KP, "2", "\033[B", "2", "", /* 80 kp 2 */ + KP, "3", "\033[G", "3", "", /* 81 kp 3 */ + KP, "0", "\033[L", "0", "", /* 82 kp 0 */ + KP, ".", "\177", ".", "", /* 83 kp . */ + NONE, "", "", "", "", /* 84 0 */ + NONE, "100", "", "", "", /* 85 0 */ + ASCII, "<", ">", "<", "<", /* 86 < > */ + FUNC, "\033[W", "\033[i", "\033[u","", /* 87 f11 */ + FUNC, "\033[X", "\033[j", "\033[v","", /* 88 f12 */ + NONE, "102", "", "", "", /* 89 0 */ + NONE, "103", "", "", "", /* 90 0 */ + NONE, "", "", "", "", /* 91 0 */ + NONE, "", "", "", "", /* 92 0 */ + NONE, "", "", "", "", /* 93 0 */ + NONE, "", "", "", "", /* 94 0 */ + NONE, "", "", "", "", /* 95 0 */ + NONE, "", "", "", "", /* 96 0 */ + NONE, "", "", "", "", /* 97 0 */ + NONE, "", "", "", "", /* 98 0 */ + NONE, "", "", "", "", /* 99 0 */ + NONE, "", "", "", "", /* 100 */ + NONE, "", "", "", "", /* 101 */ + NONE, "", "", "", "", /* 102 */ + NONE, "", "", "", "", /* 103 */ + NONE, "", "", "", "", /* 104 */ + NONE, "", "", "", "", /* 105 */ + NONE, "", "", "", "", /* 106 */ + NONE, "", "", "", "", /* 107 */ + NONE, "", "", "", "", /* 108 */ + NONE, "", "", "", "", /* 109 */ + NONE, "", "", "", "", /* 110 */ + NONE, "", "", "", "", /* 111 */ + NONE, "", "", "", "", /* 112 */ + NONE, "", "", "", "", /* 113 */ + NONE, "", "", "", "", /* 114 */ + NONE, "", "", "", "", /* 115 */ + NONE, "", "", "", "", /* 116 */ + NONE, "", "", "", "", /* 117 */ + NONE, "", "", "", "", /* 118 */ + NONE, "", "", "", "", /* 119 */ + NONE, "", "", "", "", /* 120 */ + NONE, "", "", "", "", /* 121 */ + NONE, "", "", "", "", /* 122 */ + NONE, "", "", "", "", /* 123 */ + NONE, "", "", "", "", /* 124 */ + NONE, "", "", "", "", /* 125 */ + NONE, "", "", "", "", /* 126 */ + NONE, "", "", "", "", /* 127 */ + }; + + #endif /* FRENCH_KBD */ + + /* + * XXXX Add tables for other keyboards here + */ + + #endif + /* * Get characters from the keyboard. If none are present, return NULL. */ *************** *** 1431,1436 **** --- 1620,1630 ---- shift_state &= ~SHIFT; break; case ALT: + #ifdef NONUS_KBD + if (extended) + shift_state &= ~ALTGR; + else + #endif shift_state &= ~ALT; break; case CTL: *************** *** 1475,1486 **** --- 1669,1692 ---- shift_state |= SHIFT; break; case ALT: + #ifdef NONUS_KBD + if (extended) + shift_state |= ALTGR; + else + #endif shift_state |= ALT; break; case CTL: shift_state |= CTL; break; case ASCII: + #ifdef NONUS_KBD + if (shift_state & ALTGR) { + capchar[0] = scan_codes[dt].altgr[0]; + if (shift_state & CTL) + capchar[0] &= 0x1f; + } else + #endif /* control has highest priority */ if (shift_state & CTL) capchar[0] = scan_codes[dt].ctl[0]; *************** *** 1493,1498 **** --- 1699,1705 ---- capchar[0] -= ('a' - 'A'); } capchar[0] |= (shift_state & ALT); + extended = 0; return capchar; case NONE: Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 13:30:04 1994 To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Help? Cannot sup. <199408010455.AAA04507@localhost> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >wormey@eskimo.com (Space Case) writes: >> I'm having a bit of trouble getting sup going, and I was wondering if >> anybody could help me. >> >> I am running 1.0-alpha on the Mac, have rebuilt sup and term (v. 1.18). >> I connect up with term, it works OK, so far as I know. (trsh ls returns >> output from the other side.) I think I may have a configuration >> problem. Here is some statistics: >You can't run sup over a term connection, at least not the last >time I checked. Term is not a true network connection, and each >program which runs over it must be specifically written to use it. Actually, I used to sup over term all the time. The last version it worked with was 1.14. The later versions all on my root stuff, so sup didn't work anymore. I'm sure it's fixable, but I'm not willing to spend the time on it anymore since I have a real SLIP/PPP connection. --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 15:41:10 1994 Subject: Re: Archive Viper 150 not working with 1.0_BETA To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) From: "Richard H. Wood" Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1757 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Stephen J. Roznowski wrote: > > > My Archive Viper tape drive no longer seems to be working under > 1.0_BETA. (940726 sup) using the A3000 kernel. Whenever I attempt to > access the drive, I get the following errors: > > st0(ahsc0:4:0): illegal request > st0: cannot set selected mode > > But it appears to be found during autoconfig: > > ahsc0 targ 4 lun 0: SCSI1 sequential removable > st0 at scsibus0: rogue, density code 0x0, 512-byte blocks, write-enabled > > Please help. > > -SR > To add support to Stephen's report, I'm finally back to trying NetBSD again and am getting exactly the same thing using the netbsd-generic kernel off the ftp.iastate.edu Jul 21 (Jul 9 kernel?) snapshot. It worked back in December - when I first hooked the drive up to the (then brand new) A3000-UX, and before that, when installed internally in the (then, and still not brand new) A2500/030. I was using something like vmunix.731 or so. (I never installed 744.) Anyway, A3000-UX 8meg A2065 Ethernet board HD df0: 880k df2: Quantum 200 meg on SCSI unit 6 with sVr4 and ados only Maxtor 120 meg on SCSI unit 2 with NetBSD only Archive Viper 150 tape, On a related note, I'm also experiencing the reported SCSI 'hangs' (I think)... I've simply left them (retrying?) and they eventually seem to "recover." But I suspect these events may be causing other bizarre (to me at least, since I don't understand what they are, yet) errors when I attempt to enter multiuser mode. -dick -- _____________________________________ __//________________________________ rhw@woodwrk.lerctr.org - R. H. \X/ood - dwood@spd.dsccc.com 246 Bancroft Drive, Garland, TX 75040 USA +1 214 530 2595 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 1 17:03:12 1994 From: chopps@emunix.emich.edu To: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Subject: Re: drive to sdX assignments (Was: no title) <9408010944.AA23763@rpool3.rus.uni-stuttgart.de> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu You have 2 options. 1) compile your own kernel. I think this is a good idea for alot of people. 2) change you scsi ID's if you must use the GENERIC kernel. The GENERIC kernel is huge and probably has a lot of things you don't wan't go with (1). While your at it why not change your internal drive id too. having HD's at ID 6 was stupid of commodore. I realize it was they who inspired this. You want slow scsi devices at high ID's and fast scsi devices at low scsi ID's. This allows tape drives for example to have a better chance of streaming. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 17:03:27 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: taylor uucp 1.05 done--where can I put it? X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've done some testing of my merge of Taylor uucp 1.05, and it seems to work fine from home to MIT. Someone wanna offer an FTP site for a gzipped tar file? -rw-rw-r-- 1 jtk 667539 Aug 1 09:05 taylor-1.05.netbsd.tgz ==John From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 18:20:37 1994 From: Danny Lepage Subject: unable to mount BFFS device anymore To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 676 Sender: owner-amiga@sun-lamp.cs.berkeley.edu The subject says it all. I'm unable to mount BFFS partition. I'm using BFFS1.3, and the NetBSD partitions that I want to mount are BSD4.3. I get a 'not a DOS disk' when I try to access a manually mounted partition (mount xxx from mountlist.bffs). My system hangs when it's time to show the BFFS icon (when I set them to mount automatically with HDToolBox). Any clue ? I need to get my newly compiled kernel to the amiga side so I can bootstrap from it. Is there alternative to BFFS beside getting a streamer ? Also, is it possible to upgrade a BSD4.3 partition to BSD4.4 without loosing data? Thanks in advance, Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 18:50:45 1994 From: "Chris G. Demetriou" To: Mark_Weaver@brown.edu, thorpej@cs.orst.edu Subject: Re: D'oh! Cc: , Source@brown.edu, current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> You can kludge support for the old, broken versions of telnet by passing >> telnetd the '-k' flag in inetd.conf. > >I think the core team should consider making this standard for 1.0. In a word: "no." There are going to be people who run 1.0 a year from now; people are slow to upgrade. At that time, we'll be getting bug reports from them, if it doesn't work right _then_. As it is now, our telnet correctly implements the various RFC's. if your vendors' doesn't: (1) get the new version of telnet from ftp.cray.com (i think), and install it, because it probably works, or (2) bitch out your vendor, because _they're_ not conforming to the RFC's, and you're _paying_ them for support. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 18:52:15 1994 From: Source Librarian Subject: Return of "D'oh" To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3104 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm back. Thanks for all the input about my problems with tcsh and telnet from HPUX (gack). I put in -k in inetd.conf, and all is well. Thanks. Our little test -current machine is running pretty well -- it hasn't crashed once. However, we are getting some ominous messages in our syslog file (/var/log/messages). Once in a while, the aha driver tells us: Aug 1 08:45:19 news /netbsd: aha0: DMA beyond end of ISA We first thought it had to do with us having 20mb of RAM in the machine, so we pulled 4mb out to make it 16mb, but we're still getting the message. We then tried recompiling the kernel with other options, and it happened again this morning. Is this a serious problem? BTW, thanks for all the help... -Henry (src@bsginc.com) Now the bio.... Our machine: Dell 450/MX, 16mb RAM, Adaptec-1542, NE2000, Quantum 525mb, Maxtor P1-17S (1.4gig). NetBSD: 1.0 Beta (7/24 kernel w/ 7/13 userland binaries) our config file: machine "i386" cpu "I486_CPU" cpu "I586_CPU" ident BSGAHA timezone 6 dst maxusers 20 options SWAPPAGER,VNODEPAGER,DEVPAGER options FFS options INET,NFSCLIENT,NFSSERVER options "COMPAT_43" options "TCP_COMPAT_42" options XSERVER,UCONSOLE options MSDOSFS options GATEWAY options KERNFS options SCSI options "COMPAT_NOMID" options "COMPAT_09" options "MACHINE_NONCONTIG" options SYSVMSG,SYSVSEM options SYSVSHM options FIFO options MFS config netbsd root on sd0 swap on sd0 controller isa0 device pc0 at isa? port "IO_KBD" irq 1 device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 5 device lpt0 at isa? port "IO_LPT1" irq 7 device lpt1 at isa? port "IO_LPT2" device lpt2 at isa? port "IO_LPT3" controller wdc0 at isa? port "IO_WD1" irq 14 disk wd0 at wdc0 drive ? disk wd1 at wdc0 drive ? controller fdc0 at isa? port "IO_FD1" irq 6 drq 2 disk fd0 at fdc0 drive ? disk fd1 at fdc0 drive ? controller aha0 at isa? port "IO_AHA0" irq 11 drq 5 master scsibus0 at aha0 disk sd0 at scsibus0 slave ? disk sd1 at scsibus0 slave ? disk sd2 at scsibus0 slave ? disk sd3 at scsibus0 slave ? tape st0 at scsibus0 slave ? tape st1 at scsibus0 slave ? disk cd0 at scsibus0 slave ? disk cd1 at scsibus0 slave ? controller ahb0 at isa? irq 11 master scsibus1 at ahb0 disk sd0 at scsibus1 slave ? disk sd1 at scsibus1 slave ? disk sd2 at scsibus1 slave ? disk sd3 at scsibus1 slave ? tape st0 at scsibus1 slave ? tape st1 at scsibus1 slave ? disk cd0 at scsibus1 slave ? disk cd1 at scsibus1 slave ? controller aic0 at isa? port 0x340 irq 11 drq 6 master scsibus3 at aic0 disk sd0 at scsibus3 slave ? disk sd1 at scsibus3 slave ? disk sd2 at scsibus3 slave ? disk sd3 at scsibus3 slave ? tape st0 at scsibus3 slave ? tape st1 at scsibus3 slave ? disk cd0 at scsibus3 slave ? disk cd1 at scsibus3 slave ? device ed0 at isa? port 0x300 irq 9 iomem 0xd0000 vector edintr device npx0 at isa? port "IO_NPX" irq 13 pseudo-device ether pseudo-device log pseudo-device loop pseudo-device pty 32 pseudo-device sl 1 pseudo-device speaker From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 19:16:35 1994 To: current-users@sun-lamp.cs.berkeley.edu From: siegeld@deshaw.com (David Siegel) Organization: D. E. Shaw & Co. Subject: NetBSD XFree on an i486 with #9 Pro graphics card Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can't get XFree to work on an Intel 486 running NetBSD with a #9 Pro graphics card. I'm using a Sony 17Se monitor. Basically, the monitor goes into "power saving" mode. I'm using the S3 X driver. As anyone made this work? Thanks. -Dave From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 19:25:54 1994 From: Constantin Gonzalez Subject: A2024 - 10 views - audio To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1451 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! First of all I'd like to thank everybody who made NetBSD possible, I just installed the latest Beta-release and am very happy with it. However after consulting several FAQs, Newsgroups and of course this mailing- list I still have a few questions. - How does the A2024-support mentioned in the pre-released installation guide (Posted to this list this morning) work? Someone mentioned also an A2024 X-Server, where can I find it? Shouldn't that be included in the FAQ / installation-guide? - What does this '10 views configured' message at bootup mean? Is this some sort of multiple consoles as in Linux? How about an exact guide through all the messages at bootup in the FAQ? - Is someone currently working on an audio-device for NetBSD? I'm anxiously waiting for compiling maplay... :) I hope these were not-so-frequently-asked-questions... Thanks in advance for every help, Ciao, Gonz -- -------------------------------------------------------------------------- Constantin Gonzalez | EMAIL: gonzalez@rz.tu-clausthal.de Student at the | SNAIL: Muehlenstrasse 120 Technical University of | 38678 Clausthal-Zellerfeld (Germany) Clausthal | PHONE: +49 5323 1516 -------------------------------------------------------------------------- - PGP-Public-Key: type 'finger incg@sun.rz.tu-clausthal.de' - Check out http://www.rz.tu-clausthal.de/~incg/ for more info on me. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 19:47:18 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: missing lfs_cksum.c in sbin/dumplfs? Sender: owner-current-users@sun-lamp.cs.berkeley.edu supped last night; creates directory sbin/dumplfs but doesn't transfer all of the files needed. lfs_cksum.c is missing. sup -ovd was used to update my snapshot. comments? -john From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 1 19:53:22 1994 From: Subject: New Pre 1.0 Kernel, how do I get AGA doublescan? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 344 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've managed to get the new distribution that Willam Coldwell and Chris put together running, but now I can't figure out how to get the kernel to use AGA doublescan instead of interlace mode. I've tried passing in the -A flag to loadbsd, and it doesn't seem to work. What I am I doing wrong now? Thanks in advance. Tom Hayko tjhayko@io.org From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 19:57:18 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: fsck woes Sender: owner-current-users@sun-lamp.cs.berkeley.edu i supped and have the new fsck. is there any hope i can get fsck to fix what the old fsck messed up? (regarding the new filesystem directory in the old filesystem directory. its still seg fault'ing on me. i assume i can't fsck -c 2 with this cruft around. -bri From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 20:29:35 1994 To: banshee@gabriella.resort.com (Robert Dobbs) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: missing lfs_cksum.c in sbin/dumplfs? <199408011612.QAA08686@gabriella.resort.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > supped last night; creates directory sbin/dumplfs but doesn't > transfer all of the files needed. lfs_cksum.c is missing. > sup -ovd was used to update my snapshot. comments? "yes, lots." starting with "did you look for the .PATH statement in the Makefile, and see if lfs_cksum.c was in /sys/ufs/lfs, where the Makefile wanted to pull it from?" cgd From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 20:39:41 1994 To: Source Librarian Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Return of "D'oh" <199408011500.KAA21916@bsg.bsginc.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Our little test -current machine is running pretty well -- it hasn't crashed > once. However, we are getting some ominous messages in our syslog file > (/var/log/messages). Once in a while, the aha driver tells us: > > Aug 1 08:45:19 news /netbsd: aha0: DMA beyond end of ISA > > We first thought it had to do with us having 20mb of RAM in the machine, so > we pulled 4mb out to make it 16mb, but we're still getting the message. We > then tried recompiling the kernel with other options, and it happened again > this morning. Is this a serious problem? When booting, what does the BIOS say for the amount of memory you have in the system? what do the boot blocks say? what does 'dmesg' say? my guess is that your bios/firmware is 'smart', and, if you aren't using RAM to shadow the 384k I/O hole, it remaps it so that it's at MEM+0 -> MEM+384k, where MEM is the amount of RAM you have in your machine (i.e. 16M). This means that you _do_ have usable memory above 16M, and since ISA DMA only works in the first 16M, things might not work right... (in particular, normal i/o should work fine, but all 'raw' i/o, i.e. dump/restore from tape, fsck, etc., may not work. note that the fsck at boot (because of the way memory is allocated) will probably work just fine, but later ones, e.g. in /etc/daily, may not work, and may corrupt other blocks of memory.) If you have a bios option to turn the remapping off, i suggest you try it. The generic solution is bounce buffers, but it's not going to get done today. 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 21:49:17 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: taylor uucp 1.05 done--where can I put it? From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Mon, 1 Aug 1994 09:09:50 -0400 John Kohl wrote: > I've done some testing of my merge of Taylor uucp 1.05, and it seems to > work fine from home to MIT. > > Someone wanna offer an FTP site for a gzipped tar file? > > -rw-rw-r-- 1 jtk 667539 Aug 1 09:05 taylor-1.05.netbsd.tgz > > ==John Go ahead an plop it onto ftp.CSOS.ORST.EDU:/pub/NetBSD/incoming Please also send along some sort of README... CSOS is setting up UUCP service on a NetBSD hp370 (replacing an old, dying Sun 3/180), so we'd love to try it out... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 21:49:23 1994 From: Open Carefully -- Contents Under Pressure X-Disclaimer: No way are these anyone else's opinions but mine. X-Real-Name: James Graham (*NOT* "Jim" -- that's my dad) X-Extension: 4219 X-Room-Number: 3308 X-Window-System: Release 5 X-No-Relation-To: greywolf@netcom.com, greywolf@blkhole.resun.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ken Hornstein , peter@alice.wonderland.org Subject: Re: GET THIS BOOK :) Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu WRT UNIX Haters Handbook... I've had this long-standing grudge against NT simply due to its "black box"/ EGUI (Enforced Graphic User Interface) approach to systems administration. When I was first introduced to it, in much the same way that a biker's face can be introduced to the pavement, I was assigned a book called "INSIDE NT". The manager behind Windows/NT is the same person who was behind VMS (David Cutler). With the advent of NT, and all the bogosity I have heard about VMS, I have drawn the conclusion that he still can't write a decent OS. The UNIX Haters' Handbook will undoubtedly hold some appeal for those folks who have dedicated themselves to Windoze and Windoze/NoT. I still am meaning to draw up a white paper as to why Windows/NT is not a suitable operating system for real operations. Unfortunately, time is a commodity of late... And, as illustrated, anyone who thinks that screen management belongs in the kernel is a bloody idiot. Certain things are written in user-land because they can be (this is, of course, a premise which a message-passing microkernel takes to the extreme). Disclaimer: I am a BSD UNIX zealot of the first degree since I was "born and raised on a VAX running 4.1". #define AUTHOR "kenh@wrl.EPI.COM (Ken Hornstein)" /* * >Just for those amongst you who have the tollerance to satire and the * >time, get this book: * > * > The UNIX Haters Handbook * * You know, I just read that book a few days ago, and I have to say that I was * not very impressed with it. Most of the arguments seem rather contrived; it * almost seemed that they took every feature of Unix and came up with reasons * that they hated it. There's a lot of gross oversimplification ("The only * reason Unix was written was because Ken Thompson wanted to play Space Travel"), * some re-writing of history ("Remember when e-mail used to work, before Unix?"), * and some things that are just plain dumb ("Screen handling functions should be * in the kernel, where they belong ... just like VMS"). They make a few valid * points, but they don't seem to offer any better alternatives. I get the * feeling that these people wouldn't be happy with _any_ computer system. * * --Ken */ #undef AUTHOR /* "kenh@wrl.EPI.COM (Ken Hornstein)" */ -- _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so) / ___\ _ \ __\ V / \ / /__ \| | __/WHAT: UNIX System Mangler...er, Admin \ \| | < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc. 3 Harbor Dr. \___|_|\_\__\|_| \/\/ \__/___/_| Sausalito, CA 94965 (415) 332-2344 x4219 see also: gandalf@netcom.com From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 23:25:04 1994 Subject: fsck problem To: current-users@sun-lamp.cs.berkeley.edu From: "Martin Husemann" Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 719 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since I changed my /etc/fstab to include portal, kern and fdesc filesystems, I get one I-node cleared by fsck at boot every time. It always has SIZE=0 and is owned by root and dated nearly the last boot time. It doesn't seem to do anything bad, but... mount shows: /dev/sd0a on / (local) /dev/sd0c on /var (NFS exported, local) kernfs on /kern (local, read-only) procfs on /proc (local, read-only) fdesc on /dev (union) portal:16 on /p (local) Any hints? Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 1 23:31:34 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: Taylor 1.05 source kit on ftp.csos.orst.edu X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu The folks at Oregon State were kind enough to offer a home for the my Taylor 1.05 merge to NetBSD [I've also sent a copy along to J.T. Conklin who will probably integrate it into the next NetBSD release]. see ftp://ftp.cs.orst.edu/pub/NetBSD/misc/src/ README.tuucp-1.05 taylor-1.05.netbsd.tgz The README file is: The file "taylor-1.05.netbsd.tgz" is a merge of the Taylor UUCP 1.05 sources and the NetBSD 1.0 Taylor UUCP 1.04 sources. It should "just drop in" to a NetBSD 1.0 source tree under src/gnu/usr.libexec/uucp (I think that's the right place---just replace the existing 1.04 sources) ==John Kohl jtk@atria.com From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 00:22:36 1994 From: "Stephen J. Roznowski" To: donn@u.washington.edu Subject: Re: Archive Viper 150 not working with 1.0_BETA Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: Donn Cave > Subject: Re: Archive Viper 150 not working with 1.0_BETA > To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) > Date: Mon, 1 Aug 1994 09:13:28 -0700 (PDT) > > | My Archive Viper tape drive no longer seems to be working under > | 1.0_BETA. (940726 sup) using the A3000 kernel. Whenever I attempt to > | access the drive, I get the following errors: > | > | st0(ahsc0:4:0): illegal request > | st0: cannot set selected mode > | > | But it appears to be found during autoconfig: > | > | ahsc0 targ 4 lun 0: SCSI1 sequential removable > | st0 at scsibus0: rogue, density code 0x0, 512-byte blocks, write-enabled > > Sounds like it's trying to set a bad block size or density. The ``rogue'' > business means that the driver has specific support for this model, and > you can get different block size or density settings with different minor > modes. > > It's kind of random, and I'm not looking at the source (sys/scsi/st.c), > so I can't say which options are which. The options are controlled by > the 4 and 8 bits, plus 1 for no-rewind, so you might try both of them > mknod rst4 c 20 4 mknod rst8 c 20 8 (from memory.) I've tried various combinations of device numbers, but none seem to work. (0-20 if I remember correctly, both block and character). > I have fallen a bit behind in the great race to kernel perfection here, > and the above really comes from early July. It may not be worth much, > since I suppose your tape drive was working at that time. Still it sounds > very much like that's the problem. > > I feel like tape support took a big dive when we switched over to the > main tree, and I'm a little worried that getting fixes into the main tree > st driver will be difficult. Hope not. Your drive has got to be one of > the more common models in use out there, we could at least hope to work > with that. I would hope that this will be fixed before 1.0 is out, otherwise, I think that we are in for some major problems..... -SR From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 02:10:34 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: mirrors? Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu I saw that sun-lamp had new tarballs yesterday (7/31), but both of the mirrors (ftp.iastate.edu & ftp.eecs.umich.edu) have the older 7/24 tarballs. Why haven't the latest ones been mirrored yet? I don't want to get tarballs from sun-lamp because it's too heavily loaded already. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 02:11:43 1994 To: "David Christiansen" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Hardware query <9407312022.AA10250@las1.iastate.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii From: Shoji Yuen Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> On Sun, 31 Jul 1994 15:22:56 CDT, "David Christiansen" said: DC> Does anyone know if the SCSI controller on the Soundblaster/SCSI card DC> is actually an Adaptech or not? If so, is it (1542?) compatible and supported DC> by NetBSD? I'm considering replacing my soundblaster and moving from a non- DC> supported SCSI card, and I figure I could do it this way. Unfortunately, the DC> outside of the box only says "Adaptech! Combining two powerful standards." DC> (Which could mean almost anything) So does anyone have any experience with DC> this piece of equipment? I'm using a Soundblaster/SCSI-II card with the kernel as of 06/01/94 (0.9B, due to the lack of the time I haven't updated the kernel.) I'm connecting SCSI HDD to it, and it's been working fine for more than one month. :-) - Shoji Yuen shoji@cs.sunysb.edu yuen@nuie.nagoya-u.ac.jp From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 02:58:28 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: Missing columns problem Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi again, Anyone remember that missing columns problem that I'm always moaning about ? Well, I discovered an interesting thing today. I got so pissed off with this happening with NetBSD that I decided to check out Linux (boo, hiss! :) Anyway, the Linux install was quite easy but guess what ... I get the same missing columns on the Linux console too ! AAAAAAAAAARGH !! It looks like I can't win with this. I guess it must be a hardware problem but AmigaDOS works fine and my memory tester reckons everything is OK so I'm really stuck. Maybe I should buy a 24 bit graphics card ? Or a new computer ??! Nah, what the hell, if the old 720 kernel didn't do it then I guess I could still eradicate this evil problem. BTW, have you guys been sharing code with the Linux mob ? John +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAi3utxYAAAEEAK7VSevj5fswEy8Ooz7BoMgR5AwOUUrR5yWZvCiE7dB7ds/K Y7zMDvU7qDpInWeJouMJkP5G3zD6x+3Uv4s62RmDOBskled4UZbsLYwOtQn2aZxA 6tNDPy7NnuJDJdnuwJnncmJASED8ttz6G9y01tYUe/JCbhhh/ujrAAF+E35dAAUR tCtKb2huIEouIFNoYXJkbG93IDxqb2huQGljZWJlcmcuZGVtb24uY28udWs+ =Qz1o -----END PGP PUBLIC KEY BLOCK----- From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 03:07:39 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: mirrors? <9408012242.AA29366@cthulhu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I saw that sun-lamp had new tarballs yesterday (7/31), but both of the >mirrors (ftp.iastate.edu & ftp.eecs.umich.edu) have the older 7/24 >tarballs. Why haven't the latest ones been mirrored yet? I don't >want to get tarballs from sun-lamp because it's too heavily loaded >already. [one of a few email messages asking me about the tarballs...] The last sup scan was done when there were only 7/24 tarballs. The 7/31 tarballs weren't made until after Sunday's sup scan, and a sup scan hasn't run since. Chris said he's going to make up a whole new batch of tarballs (I assume binary and source) and put them on sun-lamp, then he's going to run a new sup scan Real Soon Now (which I assume means today or tomorrow). After he does so, ftp.iastate.edu will pick them up no more than half a day later. Lots of assumptions, but rest assured that your mirrors are still accurately mirroring whatever sun-lamp gives them to mirror. :-) If you ever assume ftp.iastate.edu has broken somehow, you can look in ftp.iastate.edu:/log/ and look at the timestamp on sup.log to see whether it's been run recently. It also contains the last session output from the most recent sup. If, in fact, it's not running a sup every half day, please tell me so I can fix it. If it's just having problems getting things from sun-lamp, however, that is not my fault, and there's nothing I can do. --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 03:13:37 1994 Subject: Re: NetBSD XFree on an i486 with #9 Pro graphics card To: siegeld@deshaw.com (David Siegel) Cc: current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 907 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I can't get XFree to work on an Intel 486 running NetBSD with a #9 Pro > graphics card. I'm using a Sony 17Se monitor. Basically, the monitor > goes into "power saving" mode. I'm using the S3 X driver. As anyone > made this work? Thanks. I've been trying to get it working with Freebsd 1.1.5.1 (to be upgraded to netbsd 1.0 whenn it's out), but am unsuccessful. I set up an NFS export on a local machine here and booted linux off of a distribution's boot floppies and tried to get it working with an NFS mounted XFree 2.1.1, and it worked fine. I guess there's some problem with these cards and *BSD. *sigh* I really wanted to use the card. -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 03:34:38 1994 From: Source Librarian Subject: Re: Return of "D'oh" To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 293 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > my guess is that your bios/firmware is 'smart', and, if you aren't > using RAM to shadow the 384k I/O hole, it remaps it so that it's > at MEM+0 -> MEM+384k, where MEM is the amount of RAM you have in your > machine (i.e. 16M). > Bingo. That was it. Thanks again. -Henry (src@bsginc.com) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 03:35:31 1994 Subject: Re: D'oh! To: Mark_Weaver@brown.edu Cc: thorpej@cs.orst.edu, src@bsg.bsginc.com, current-users@sun-lamp.cs.berkeley.edu From: Luke Mewburn X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1376 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Jason Thorpe writes: > > This is due to a slight incompatibility between the new telnetd and > > older versions of telnet...(You see this on NeXTs as well...) > > > > You can kludge support for the old, broken versions of telnet by passing > > telnetd the '-k' flag in inetd.conf. > I think the core team should consider making this standard for 1.0. > Very few systems run the new version of telnet. Most notably, both > SunOS 4.1.3 and Solaris 2.3 use the old telnet, and telnetting from > one of them to my system barfed until I put in the -k. Actually, I've tried the following (all accounts running tcsh as the shell) telnets: netbsd 1.0b -> solaris 2.3: ok solaris 2.3 -> netbsd 1.0b: ok netbsd 1.0b -> sunos 4.1.3: ok sunos 4.1.3 -> netbsd 1.0b: not ok. The telnet on solaris 2.3 (like a lot of the network stuff), although not being precisely BSD4.3 networking bugforbug compatible, seems to be smart enough to autodetect when it does or doesn't need the KLUDGELINEMODE stuff. So, yes, older 4.2 and probably 4.3 telnets do stuff up, but the newer telnets (>= net/2? and solaris 2.x) seem to work ok. -- ``Concealment is never as hard as people think, you Luke Mewburn must understand that. It's action while hiding that's the hard part'' -- Coyote, in Kim Stanley Robinson's `Green Mars' From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 03:50:18 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Concatenated filesystem... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Anybody set one of these up? Is there a README on it somewhere? I've yet to find one... Just got 9 hp7958 drives that I need to make usable space out of... Thanx... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 05:26:39 1994 From: "Stephen J. Roznowski" To: billc@icecube.cryogenic.com Subject: Re: INSTALL doc - prerelease Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu I noticed some typos and problems: 1. CPU - I believe that it should be MC68020 and MC68030. 2. Should probably mention ftp.iastate.edu as an ftp site. 3. In the 'BOOTING INTO NETBSD' section, it should probably have a little bit more.... Also, I believe the question that is asked is which device has the root file system (not boot from). 4. Extracting the kernel is not done with tar. 5. It will be rather slow to copy the devices from the floppy and all of the devices may not be there. Perhaps the sequence should be to copy MAKEDEV from /dev to /altroot/dev and then do a MAKEDEV all. Also, I noticed a problem with 'you/your/you're' somewhere that I can't find now. -SR From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 05:33:50 1994 From: Herb Peyerl Subject: Re: Concatenated filesystem... To: thorpej@cs.orst.edu (Jason Thorpe) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 450 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : Anybody set one of these up? I didn't have enough spindles to test it when I put it in but Mike said he's tried the concat ones... : Is there a README on it somewhere? I've yet to find one... there's the source.... :-) hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 05:36:23 1994 To: Herb Peyerl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Concatenated filesystem... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Sun, 13 Jan 1980 10:19:06 -40962758 (MST) Herb Peyerl wrote: > I didn't have enough spindles to test it when I put it in but Mike > said he's tried the concat ones... Cool...I peered at your kernel config and figured out the config entry, but I couldn't get the interleave stuff figured out...I'll try the default, I guess... > : Is there a README on it somewhere? I've yet to find one... > > there's the source.... :-) Already read it :-) If I had some spare disk, I'd fill in all of the missing stuff for the i386 in my copious free time :-) Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 06:57:06 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@alpha.bostic.com X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: [i386] new binary snapshot available... From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu There's a new i386 binary snapshot available, and i hope to be making some install floppies, and some real distributions sets, available in the next few days. Time is really tight for me right now, though. *sigh*. I've run the sup scanner, so they should be suppable now, for those of you running mirrors. 8-) chris From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 08:34:34 1994 From: chopps@emunix.emich.edu To: "Stephen J. Roznowski" Cc: donn@u.washington.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Archive Viper 150 not working with 1.0_BETA <199408012123.RAA21832@zombie.ncsc.mil> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I feel like tape support took a big dive when we switched over to the > > main tree, and I'm a little worried that getting fixes into the main tree > > st driver will be difficult. Hope not. Your drive has got to be one of > > the more common models in use out there, we could at least hope to work > > with that. Getting fixes in isn't a problem. And fixes from other platforms will also go in, this can only be a win. I was not familar with the old code and I am not too familar with the new. What features did we lose? Why did it take a dive? Considering we could put any features right back in the new code and benifit multiple arch's why hasn't any of this been made public before? > I would hope that this will be fixed before 1.0 is out, otherwise, I think > that we are in for some major problems..... Nothing regarding tapes is going to be fixed by me as I have no tape drive. If you think its important please try and debug it for us. Otherwise it will definetly be broken for release. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 09:03:31 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: comments on Install doc Sender: owner-amiga@sun-lamp.cs.berkeley.edu I _really_ appreciate all of the input so far that I have received (even the outright complaints ;-). I do ask though, that if you feel that a section have more in it, that you actually give me an IDEA of what you mean. I've received a lot of "This section needs more.", which does me no good, since I had already reached a brain freeze regarding that section. If you have time, feel free to rewrite or edit a section.. I'm not in this for the glory, I won't get offended. I want a correct document out there, otherwise tech support will be a nightmare on it. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 11:59:16 1994 From: Peter Galbavy Subject: Re: Concatenated filesystem... To: thorpej@cs.orst.edu (Jason Thorpe) Cc: Herb.Peyerl@sidney.novatel.ca, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 480 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Cool...I peered at your kernel config and figured out the config entry, > but I couldn't get the interleave stuff figured out...I'll try the > default, I guess... Well, let the rest of us in on the secret then... :) What does the config line(s) look like ? Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 12:05:48 1994 From: Alan Barrett Subject: bind-4.9.3 To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu bind-4.9.3-beta9-patch1 has been out for more than a week now, and I am not aware of any problems with it, so it seems likely that version 4.9.3 will be released soon. Are there any plans to incorporate bind-4.9.3 into NetBSD-1.0? I would be happy to do the necessary work (a simple matter of integrating NetBSD's resolver modifications). --apb (Alan Barrett) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 14:26:16 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Aug 2 03:37:40 1994 SUP Scan for current completed at Tue Aug 2 03:40:27 1994 SUP Scan for mirror starting at Tue Aug 2 03:40:27 1994 SUP Scan for mirror completed at Tue Aug 2 03:42:42 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 16:48:22 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Re: Archive Viper 150 not working with 1.0_BETA To: chopps@emunix.emich.edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1035 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I would hope that this will be fixed before 1.0 is out, otherwise, I think > > that we are in for some major problems..... > > Nothing regarding tapes is going to be fixed by me as I have no tape drive. > If you think its important please try and debug it for us. Otherwise > it will definetly be broken for release. > I am running a July 29th kernel and I have 0, zippo, ziltch problems with my 3070, i.e. CP150, tape drive beyond the usual first access burp. I tried once to get a specific entry for the CP150 in to the tree but one of the core members shot it down as it wasn't different enough from the default. I still get read errors but I got more with the old driver. From what I've seen the tape driver is BETTER than the old amiga driver, not worse. If anybodys having problems with the tape driver than either you have to update to at least July 29th or there is some other config problem who's side effect is a blortched tape device. The new tape driver works better for me and always has. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 18:10:37 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD XFree on an i486 with #9 Pro graphics card <199408012336.TAA14552@csugrad.cs.vt.edu> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I can't get XFree to work on an Intel 486 running NetBSD with a #9 Pro > > graphics card. I'm using a Sony 17Se monitor. Basically, the monitor > > goes into "power saving" mode. I'm using the S3 X driver. As anyone > > made this work? Thanks. > > I've been trying to get it working with Freebsd 1.1.5.1 (to be upgraded > to netbsd 1.0 whenn it's out), but am unsuccessful. I set up an NFS export on > a local machine here and booted linux off of a distribution's boot floppies and > tried to get it working with an NFS mounted XFree 2.1.1, and it worked fine. > I guess there's some problem with these cards and *BSD. *sigh* I really > wanted to use the card. I mailed Dave Siegel on this directly.... First of all, there are a lot of different #9 cards. Which model are you trying to get working? Secondly, If you want to redirect the startup information to a file and mail it to me, I would be happy to make a stab at why it doesn't work. I have been running a #9 928 Level 12 for 6 months now. They do work, and quite nicely I might add. Use the following to redirect the startup messages: startx > x.out 2>&1 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 19:08:03 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Archive Viper 150 not working with 1.0_BETA Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 2, 7:47am, Rob Healey wrote: > > > I would hope that this will be fixed before 1.0 is out, otherwise, I think > > > that we are in for some major problems..... > > > > Nothing regarding tapes is going to be fixed by me as I have no tape drive. > > If you think its important please try and debug it for us. Otherwise > > it will definetly be broken for release. > > ... > From what I've seen the tape driver is BETTER than the old > amiga driver, not worse. I think the general tape driver is better, but there were some drive-specific handling done in the old driver that probably isn't in the new driver. I had some trouble with an Exabyte 8mm drive because of some setup that the old driver did which isn't in the new driver. I modified the new driver to add the 8mm as another 'rouge' and was able to get the drive working. I had also added some special handling to the old driver for a DEC TZ50 tape drive. I haven't had much luck getting that to work with the new driver. [Part of the problem is that the new driver executes a SCSI command that the old driver didn't, and that command isn't supported by the DEC drive.] I think the new driver works fine with my Wangtek 5150ES drive, although I haven't tried it lately. The stupid A4000 box doesn't have a deep enough 5-1/4" bay, so I couldn't put the drive in the A4000. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:11:55 1994 From: Peter Galbavy Subject: Re: GET THIS BOOK :) To: kenh@wrl.epi.com (Ken Hornstein) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 704 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > You know, I just read that book a few days ago, and I have to say that I was > not very impressed with it. Most of the arguments seem rather contrived; it > [... deleted ...] Oh, I agree, many of the arguments are a bit off centre, but overall, it's *funny*. And also there are some very valid points. Especially about online docs and X. I will finish reading soon and then maybe see what we can change for the positive in NetBSD (jumps into flame proof underwear at this point...). Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:25:56 1994 From: Source Librarian Subject: Doh! To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1027 Sender: owner-current-users@sun-lamp.cs.berkeley.edu D'oh! Ignore my previous question -- I RTFM'd the man page for /etc/group and saw the group file now needs commas between the users. Sorry for the wasted bandwidth. I do, though, have something interesting to report (at least to me :-). My preferred interactive shell, tcsh (6.04 and 6.05), is acting kind of strange on -current. Once in a while, it will "mangle a carriage return" -- instead of returning to the beginning of the next line on a newline, it will just do a simple linefeed and continue on. For example, sometimes ls looks like bungo% ls Mail ponch newbie hobart momo pink bungo% I don't think it's current's fault, because /bin/csh /bin/sh seem to work okay. The worst of it, though, is that it's intermittent -- if I log out and log back in, it sometimes goes away. However, when it happens, it affects the whole session until I do log out -- no matter what I do with stty.... -Henry (src@bsginc.com) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:26:55 1994 From: Julian Howard Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: What will be chopped where 31st July ? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Certain USA lawyers issued certain `cease & desist' notices to various `good guys' in the Net & Free BSD communities weeks ago. Such notices are due into effect 31st July/1st August. Would those who intend to deny access (ftp'able, mirror'able, sup'able, mail sever etc) please announce advance intention now, to give everyone sufficient chance to grab whatever they want now, ready for timely & safe storage in any safe country ( Translvanyia ? ;-) thought to be free of marauding lawyers ;-) -- Julian Stacey Alternates: , Tel. +49 89 268616 TZ=GMT+1 Munich, Germany From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:33:47 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: fyi: mail From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu You should see some dated mail today. This is not old mail being resent. The Berkeley CS dept has been moving into it's new building for the last three days. Some NetBSD mail got caught up in their attempts to avoid bouncing mail while most of their machines are down. Any NetBSD mail caught in this trap should trickle out today. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:38:31 1994 Subject: Re: NetBSD XFree on an i486 with #9 Pro graphics card To: randy%dsndata%sierra@sterling.com Cc: current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 864 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I mailed Dave Siegel on this directly.... > First of all, there are a lot of different #9 cards. Which model > are you trying to get working? It's a #9 GXE level 11 VLB model. It's got 2M VRAM on it. > Secondly, If you want to redirect the startup information to a file > and mail it to me, I would be happy to make a stab at why it > doesn't work. I have been running a #9 928 Level 12 for 6 months > now. They do work, and quite nicely I might add. None of it looks abnormal. I'll try that and hope that file doesn't get lost in the system lockup. I can do this later today and post to the list. -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 19:45:48 1994 To: John Kohl Cc: mark@aggregate.com, jconklin@netcom.com, scottr@plexus.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Taylor UUCP 1.05 <199407310535.BAA11054@kolvir.blrc.ma.us> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I've already merged Tuucp 1.04/1.05 changes into a NetBSD-current/1.04 > base. It's at work, and I've built it at home, but haven't fully tested > it yet. > > Do the core folks want this for 1.0-final, or is this too much of a > change too late in the game ? in a phrase: "not on your life!!!!" if _you_ say you haven't fully tested it yet... cgd From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 20:20:34 1994 Newsgroups: culist.netbsd.amiga Path: daemon From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Subject: Re: Archive Viper 150 not working with 1.0_BETA To: amiga@sun-lamp.cs.berkeley.edu Organization: Carleton University Distribution: culist Approved: news@cunews.carleton.ca X-Mailer: Mail User's Shell (7.2.5 10/14/92) Lines: 34 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 2, 7:47am, Rob Healey wrote: > > > I would hope that this will be fixed before 1.0 is out, otherwise, I think > > > that we are in for some major problems..... > > > > Nothing regarding tapes is going to be fixed by me as I have no tape drive. > > If you think its important please try and debug it for us. Otherwise > > it will definetly be broken for release. > > ... > From what I've seen the tape driver is BETTER than the old > amiga driver, not worse. I think the general tape driver is better, but there were some drive-specific handling done in the old driver that probably isn't in the new driver. I had some trouble with an Exabyte 8mm drive because of some setup that the old driver did which isn't in the new driver. I modified the new driver to add the 8mm as another 'rouge' and was able to get the drive working. I had also added some special handling to the old driver for a DEC TZ50 tape drive. I haven't had much luck getting that to work with the new driver. [Part of the problem is that the new driver executes a SCSI command that the old driver didn't, and that command isn't supported by the DEC drive.] I think the new driver works fine with my Wangtek 5150ES drive, although I haven't tried it lately. The stupid A4000 box doesn't have a deep enough 5-1/4" bay, so I couldn't put the drive in the A4000. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 21:01:38 1994 To: Peter Galbavy Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Concatenated filesystem... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 2 Aug 1994 09:09:36 +0100 (BST) Peter Galbavy wrote: > Well, let the rest of us in on the secret then... :) Well...After dinking with it, reading the source, bugging Herb...:-) We got the kernel to confiugure ccd0...and MAKEDEV is more than happy to generate cd0a, cd0c, [ . . . ] (as well as the raw counterparts), but we're having problems actually *using* it. Can't seem to mount the entire thing...mount is looking at the label on the first disk and calling it good... > What does the config line(s) look like ? pseudo-device ccd0 on rd3c and rd4c and rd5c and rd6c Unfortunately, I can only find code for hp300s in the ccd driver...I thought about plopping in the necessary stuff to make it go on an i386, but don't have any spare drives to test it on... It doesn't look trivial to plop into a config.new platform, and the only one of those I really have around is an Amiga with barely enough disk for the OS...:-) Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 2 21:08:35 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Re: Archive Viper 150 not working with 1.0_BETA To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1179 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From Michael Hitch: | I think the general tape driver is better, but there were some | drive-specific handling done in the old driver that probably isn't in | the new driver. I had some trouble with an Exabyte 8mm drive because | of some setup that the old driver did which isn't in the new driver. I | modified the new driver to add the 8mm as another 'rogue' and was able | to get the drive working. Michael was kind enough to forward these changes to me, a couple of weeks ago, and as far as I'm concerned they're an unqualified improvement for the Exabyte EXB8200, raising it from barely usable to fairly satisfactory. I personally would add a couple of lines to suppress LOAD commands, but they're more of a nuisance than a serious problem. I was the one who said tape support had taken a dive. Stephen wasn't the first person to report problems with an Archive drive, and maybe it's the only other model with problems - in the other complaints about tape drives, I can't recall mention of any other model. It's a pretty common model, though. Maybe we should pull it from the new install doc, which would leave only the Cipher. Donn Cave, donn@cac.washington.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 21:19:25 1994 From: Brian Moore To: Julian.H.Stacey@regent.e-technik.tu-muenchen.de Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: What will be chopped where 31st July ? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Whoops! Since I'm just supping changes from sun-lamp, included deleting no-longer existing files, the NetBSD-0.9 directory is now gone from ftp.eecs.umich.edu. I'm assuming the legalities are such that my site can't have the files on it any more, but was is the 'official' party line. If I can I'll put them back up, but I have a feeling that the suits would throw a fit. Brian Moore Maintainer of NetBSD mirror on ftp.eecs.umich.edu ziff@eecs.umich.edu From owner-netbsd-users@sun-lamp.cs.berkeley.edu Tue Aug 2 21:24:25 1994 From: klee@rdcclink.rd.qms.com To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Why does the ftp.iastate.edu mirror only binaries? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi! I wanted to get the source code for the NetBSD-current, but when I logged in to sun-lamp, the anonymous ftp was refused, due to too many anonymous ftp connection(3 users). So when I tried the ftp.iastate.edu, the binaries have been updated, but the source is still March 29th version. Is there any reason why they only update the binaries? Thanks Kang From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 21:24:50 1994 From: Brian Moore To: Mike.Long@analog.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: mirrors? Sender: owner-current-users@sun-lamp.cs.berkeley.edu This was my fault. A file I changed got stomped on so that the sup file was getting connetion refused from sun-lamp. I fixed it yesterday and everything is looking fine and dandy now. Sorry, Brian Moore Maintainer of NetBSD mirror on ftp.eecs.umich.edu ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 22:21:37 1994 From: Drew Hess Subject: MSDOSFS problems To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 987 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone else had MSDOSFS problems in the last few days? I'm running a July 31 -current/i386 system (binaries and kernel), and whenever I try to cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs and I have to do a hard reset. The MS-DOS filesystem is resident on an IDE drive, so it's possible that this is a bug with my drive and the wd driver, but I've never had problems with it before and I was able to boot from a root partition on the same IDE drive last night with no problems. Anyway I thought I would post here and see if this is a common problem before I submit a bug report. On a related note, does anyone have any idea if Daytona's (and Chicago's, since they supposedly use the same scheme) long file names on FAT partitions will interfere with the NetBSD MSDOSFS driver, or are they completely transparent? I know that the driver doesn't see the LFNs but I wonder if there are any potential conflicts here.... -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 22:22:12 1994 Subject: Re: NetBSD XFree on an i486 with #9 Pro graphics card To: mmead@vt.edu Cc: randy%dsndata%sierra@sterling.com, current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 627 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > First of all, there are a lot of different #9 cards. Which model > > are you trying to get working? > It's a #9 GXE level 11 VLB model. It's got 2M VRAM on it. I've since gotten the card to work every time I reboot. However, it locks up a lot. I'm certain now that the card is defective, and have ordered another. I imagine that one will work. *knock on wood* -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 22:35:57 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: vmstat -i Sender: owner-current-users@sun-lamp.cs.berkeley.edu I note that vmstat -i on my i486 still returns nothign useful. interrupt total rate Total 0 0 and just plain ol vmstat returns this: procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ?0 ?1 ?2 ?3 in sy cs us sy id 3 0 0 83352 2304 39 8 2 0 0 1 0 0 0 0 0 140 33 83 6 10 ?0, ?1, etc? :( --Michael From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 22:46:30 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Drew Hess Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: MSDOSFS problems <9408021834.AA25028@Xenon.Stanford.EDU> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > since they supposedly use the same scheme) long file names on FAT partitions > will interfere with the NetBSD MSDOSFS driver, or are they completely > transparent? I know that the driver doesn't see the LFNs but I wonder if > there are any potential conflicts here.... > > > -dwh- > dhess@cs.stanford.edu > It is supposed to be transparent, but i'll bring home a disk from work and check. Once daytona is released, it will make sense to add this functionality to MSDOSFS. later, Adam Glass Redmond, WA From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:07:19 1994 From: "Hubert Feyrer" "Re: Concatenated filesystem..." (Aug 2, 10:02am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, Peter Galbavy Subject: Re: Concatenated filesystem... Cc: current-users@sun-lamp.cs.berkeley.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Aug 2, 10:02am, Jason Thorpe wrote: > We got the kernel to confiugure ccd0...and MAKEDEV is more than happy to > generate cd0a, cd0c, [ . . . ] (as well as the raw counterparts), but ^^^^ Shouldn't this be ccd0a? > we're having problems actually *using* it. Can't seem to mount the > entire thing...mount is looking at the label on the first disk and > calling it good... I haven't tried this yet (sheesh, I don't even have a -current system! ;-), but have you tried newfs'ing rcc0(a) or whatever? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:09:45 1994 To: Alan Barrett Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: bind-4.9.3 From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > bind-4.9.3-beta9-patch1 has been out for more than a week now, and I am > not aware of any problems with it, so it seems likely that version 4.9.3 > will be released soon. > > Are there any plans to incorporate bind-4.9.3 into NetBSD-1.0? I would > be happy to do the necessary work (a simple matter of integrating NetBSD's > resolver modifications). I guess I'll do it, eventually. If you sit down before I do, send the diffs to me. But don't bother touching the resolver at all; I'm fairly sure that our resolver is in better shape than the standard bind one. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:23:55 1994 To: Drew Hess Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: MSDOSFS problems <9408021834.AA25028@Xenon.Stanford.EDU> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Has anyone else had MSDOSFS problems in the last few days? I'm running >a July 31 -current/i386 system (binaries and kernel), and whenever I try to >cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs >and I have to do a hard reset. Just curious; have you verified that the MS-DOS filesystem isn't corrupt? I used to have similar problems until I ran CHKDSK under DOS and fixed some filesystem inconsistancies. --Ken H. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:26:55 1994 To: Michael Graff Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: vmstat -i <199408021848.NAA12644@packrat.vorpal.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I note that vmstat -i on my i486 still returns nothign useful. > >interrupt total rate >Total 0 0 I wrote some extremely icky code that made vmstat -i work; let me know if you want it. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:49:00 1994 From: Herb Peyerl Subject: Re: Concatenated filesystem... To: c9020@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 628 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : : On Aug 2, 10:02am, Jason Thorpe wrote: : > We got the kernel to confiugure ccd0...and MAKEDEV is more than happy to : > generate cd0a, cd0c, [ . . . ] (as well as the raw counterparts), but : ^^^^ : Shouldn't this be ccd0a? Yes; it should assuming that I'd made the appropriate changes to MAKEDEV which I hadn't so in Jason's case; 'cd0a' is fine. Yes; I intend to get around to this. hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 2 23:50:39 1994 From: Mike Long To: kenh@wrl.epi.com Cc: dhess@CS.Stanford.EDU, current-users@sun-lamp.cs.berkeley.edu Subject: Re: MSDOSFS problems Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Tue, 02 Aug 1994 15:28:39 -0400 >From: Ken Hornstein > [Drew Hess wrote:] >>Has anyone else had MSDOSFS problems in the last few days? I'm running >>a July 31 -current/i386 system (binaries and kernel), and whenever I try to >>cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs >>and I have to do a hard reset. > >Just curious; have you verified that the MS-DOS filesystem isn't corrupt? I >used to have similar problems until I ran CHKDSK under DOS and fixed some >filesystem inconsistancies. I have had similar problems, and CHKDSK found nothing wrong with my disk before or after. I am also using an IDE disk (Western Digital WDAC2420); the MSDOS partition was fdisk'ed and formatted using MSDOS 6.00, and is 125 MB in size (2K clusters). When I rebooted into DOS, an 0-length entry for the file I had tried to write was in the directory; so it created the directory entry OK but choked when it tried to write the data. I didn't get the problem consistently; I was able to write some small files to the MSDOS partition before my system hung. I am getting the latest sources from iastate now; at some point in the near future I'll build a kernel with DDB and see what I can find out. However, since I know little about kernel innards, that probably won't be much. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 00:16:26 1994 From: Anders Magnusson To: source@sun-lamp.cs.berkeley.edu Subject: Just added initial VAX port code. Sender: owner-current-users@sun-lamp.cs.berkeley.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 00:46:18 1994 From: Andrew Cherry To: "Eduardo E. Horvath" Subject: Re: forwarded message from Jukka Forsgren Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu "Eduardo E. Horvath eeh@btr.com" writes: > > On Sat, 30 Jul 1994, David Champion wrote: > > > > > I've heard at least one other report of problems with SCSI lockups; > > > > has anyone else had these problems or have any insights into them? > > > > > > > I'am also having problems with those lockups. I have an A3000/25, 120MB & > > > 105MB Quantum and 6MB of memory.. > > > > My SCSI locks up so often I can't build a new kernel to even try to > > stop it. (I'm about halfway through a build now, after 6 or 7 reboots > > and a few filesystem repairs.) I might be the "one other report" that > > Andrew mentioned -- thanks, but your kernel didn't help me any. > > A3000/25; Quantum LPS52, Empire 540. HP DAT connected, but not > > always powered on. This is with any kernel from mid-June to 21 Jul. > > I'm about to completely reinstall the system based on the > > -release now at sun-lamp. > > You might try applying the patch I posted yesterday to amiga-dev. It > won't hurt, and there is some slight possibility that it might help. If > you apply it and do notice some shange in behavior, please let me know. For the record, I have tried this, and I still get lockups. No changes. Sorry. :) My machine does not seem to lock up as often as David Champion's, but then again, I might have more memory (12MB) and thus might end up swapping less. The lockups occur during fairly heavy disk activity, such as when emacs autosaves a large file, or when the system starts to swap a lot (this happens with you run X11, emacs, etc.. :) ). Worse yet, my attempts to force this behavior to happen have failed (I hoped that some useful messages might be printed to the console just before the system locks up, but it always seems to happen when I don't have my xconsole window up. Murphy strikes again.) Again, my setup is: A2000 GVP G-Force 68040/SCSI, with 12MB 32-bit RAM Seagate ST31200N SCSI-2 drive (1 gig) Quantum PD015S SCSI-1 drive (100 meg) GVP I/O Extender A2024 monitor (though I doubt this is relevant :) ) I am using a kernel compiled from current sources, but I have tried kernels back to the July 9th binary dist. I have tried both with sync enabled and disabled; the same behavior occurs for both. -Andrew Cherry (cherry@planet.net) From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 3 00:47:48 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Archive Viper 150 not working with 1.0_BETA To: Donn Cave Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Tue, 2 Aug 1994, Donn Cave wrote: > I was the one who said tape support had taken a dive. Stephen wasn't the > first person to report problems with an Archive drive, and maybe it's the > only other model with problems - in the other complaints about tape drives, > I can't recall mention of any other model. It's a pretty common model, > though. Maybe we should pull it from the new install doc, which would > leave only the Cipher. Well, I have an Archive Viper 2150S, and it is working wonderfully with the kernel I supped on Jul 30, so I think taking it off the supported list is a bit premature. One problem I did find was that the device nodes have changed in the last few weeks, so I needed to rebuild st0 and rst0 from the latest MAKEDEV. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 01:30:10 1994 From: Dave Burgess Subject: Re: Hardware query To: shoji@sbleo.cs.sunysb.edu (Shoji Yuen) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1040 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > >>>>> On Sun, 31 Jul 1994 15:22:56 CDT, "David Christiansen" said: > > DC> Does anyone know if the SCSI controller on the Soundblaster/SCSI card > DC> is actually an Adaptech or not? If so, is it (1542?) compatible and supported > DC> by NetBSD? I'm considering replacing my soundblaster and moving from a non- > DC> supported SCSI card, and I figure I could do it this way. Unfortunately, the > DC> outside of the box only says "Adaptech! Combining two powerful standards." > DC> (Which could mean almost anything) So does anyone have any experience with > DC> this piece of equipment? > > I'm using a Soundblaster/SCSI-II card with the kernel as of > 06/01/94 (0.9B, due to the lack of the time I haven't > updated the kernel.) I'm connecting SCSI HDD to it, and > it's been working fine for more than one month. :-) > As long as you have the aic driver compiled into your sources. This driver will correctly probe on an Adaptec 1522 as well, but will not access any of the SCSI devices correctly. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 01:33:16 1994 From: Drew Hess Subject: Re: MSDOSFS problems To: Mike.Long@analog.com Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1480 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mike Long writes: > > >Date: Tue, 02 Aug 1994 15:28:39 -0400 > >From: Ken Hornstein > > > [Drew Hess wrote:] > >>Has anyone else had MSDOSFS problems in the last few days? I'm running > >>a July 31 -current/i386 system (binaries and kernel), and whenever I try to > >>cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs > >>and I have to do a hard reset. > > > >Just curious; have you verified that the MS-DOS filesystem isn't corrupt? I > >used to have similar problems until I ran CHKDSK under DOS and fixed some > >filesystem inconsistancies. > > I have had similar problems, and CHKDSK found nothing wrong with my > disk before or after. I am also using an IDE disk (Western Digital > WDAC2420); the MSDOS partition was fdisk'ed and formatted using MSDOS > 6.00, and is 125 MB in size (2K clusters). When I rebooted into DOS, > an 0-length entry for the file I had tried to write was in the > directory; so it created the directory entry OK but choked when it > tried to write the data. I didn't get the problem consistently; I was > able to write some small files to the MSDOS partition before my system > hung. > Yes, exactly the same thing happened to me. Trying a cp -r dir /dos copied some of the files (though in one case the files were corrupt) and then created a 0-length file for the last file in the directory and hung. Copying just a single file consistently hangs the system. -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 01:38:02 1994 From: Drew Hess Subject: Re: MSDOSFS problems To: kenh@wrl.epi.com (Ken Hornstein) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 629 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ken Hornstein writes: > > >Has anyone else had MSDOSFS problems in the last few days? I'm running > >a July 31 -current/i386 system (binaries and kernel), and whenever I try to > >cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs > >and I have to do a hard reset. > > Just curious; have you verified that the MS-DOS filesystem isn't corrupt? I > used to have similar problems until I ran CHKDSK under DOS and fixed some > filesystem inconsistancies. > > --Ken H. > No, I haven't tried CHKDSK and frankly didn't think of that. I'll try it when I get home tonight. -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 01:38:36 1994 X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Some bugs to fix for 1.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm getting the feeling that a lot of the pending PRs aren't going to get fixed for 1.0, so can I gently suggest that you look into four of them in particular. It shouldn't take more than half an hour for a core team member to look them all over and commit them. 375, 357, 358, and 362. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 01:50:36 1994 To: Ken Hornstein Cc: Drew Hess , current-users@sun-lamp.cs.berkeley.edu Subject: Re: MSDOSFS problems <9408021928.AA19958@entropic.com> X-Reposting-Policy: redistribute only with permission From: "Perry E. Metzger" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ken Hornstein says: > >Has anyone else had MSDOSFS problems in the last few days? I'm running > >a July 31 -current/i386 system (binaries and kernel), and whenever I try to > >cp a file from a NetBSD partition to an MS-DOS filesystem the machine hangs > >and I have to do a hard reset. > > Just curious; have you verified that the MS-DOS filesystem isn't corrupt? I > used to have similar problems until I ran CHKDSK under DOS and fixed some > filesystem inconsistancies. If that is indeed a consideration, a chkdsk that ran under unix would be a Good Thing. Perry From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 02:07:17 1994 From: mycroft@gnu.ai.mit.edu To: burgess@s069.infonet.net, current-users@sun-lamp.cs.berkeley.edu, shoji@sbleo.cs.sunysb.edu Subject: Re: Hardware query Sender: owner-current-users@sun-lamp.cs.berkeley.edu As long as you have the aic driver compiled into your sources. This driver will correctly probe on an Adaptec 1522 as well, but will not access any of the SCSI devices correctly. To me, that statement seems misleading. The aic6360 driver is reported to work on SoundBlasters and other devices with 6360 chips. It is reported to not work on 6260 chips, like in the 1522. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 02:14:15 1994 X-Sender: thomas@pop3.vthrc.uq.oz.au. Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: current-users@sun-lamp.cs.berkeley.edu From: Danny Thomas Subject: Re: bind-4.9.3 Sender: owner-current-users@sun-lamp.cs.berkeley.edu theo writes >> Are there any plans to incorporate bind-4.9.3 into NetBSD-1.0? I would >> be happy to do the necessary work (a simple matter of integrating NetBSD's >> resolver modifications). > >I guess I'll do it, eventually. If you sit down before I do, send the >diffs to me. But don't bother touching the resolver at all; I'm fairly >sure that our resolver is in better shape than the standard bind one. that's as may be now, but may only apply in the short term considering that the past year has probably been the first time that bind maintenance has been funded and coherently done. Paul Vixie is also going to be running a root nameserver in future to broaden the experience base. wrt to resolver something that may be worth flagging now, though I'm not sure how many modules get into resolver-level programming: >i'd like to let everybody know that several changes are coming in the next >rev or two of BIND: > >1. _res will disappear. all variables that can be set will be set > with functional interfaces rather than data interfaces. > >2. hesiod will appear. as will NIS. fallback methods will be specifiable. > >3. get{host,pw,serv,net}by*() will be stubs that talk to a local daemon > over a unix-domain socket; that daemon will have the actual DNS resolver > and NIS/Hesiod code in it. > >i mention this only because the following diff caught my eye. code like >this will stop working on the BIND resolver starting RSN (real soon now): > >> register int res_retry = _res.retry; >> >> + if ((_res.options & RES_INIT) == 0 && res_init() == -1) >> + return((nsmsg_t *)NULL); >> #ifdef DEBUG >> if (_res.options & RES_DEBUG) >> printf("_resolve: class = %d, type = %d\n", class, type); now returning traffic back to interesting issues... Danny Thomas From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 02:51:02 1994 From: vdlinden@fwi.uva.nl (Frank van der Linden) X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: current-users@sun-lamp.cs.berkeley.edu Subject: Repeatedly corrupted /dev Sender: owner-current-users@sun-lamp.cs.berkeley.edu About a week ago, my /dev directory got corrupted (NetBSD 1.0-alpha, 386/40, 2 IDE disks). It took me a while to repair that, booting from 0.9 floppies, etc. At first, I thought that it might have been the fdesc filesystem, since that was union mounted on top of /dev. So I removed that from /etc/fstab. However, it happened again today, only less severe (my system is NetBSD 1.0-beta as of July 31st by now). The symptoms are, that just 'ls' will not show certain files, and wildcard expansion will also not find them. However, 'ls -al' reports: : Bad file descriptor for all the device nodes that have been damaged. The only thing that works is 'rm -rf /dev' and then a 'MAKEDEV all'. I wonder what this could be. I am a little tight on diskspace in the root partition: /dev/wd0a 7660 7087 -193 103% / ..but I doubt that that has anything to do with it. All my filesystems are 'old' filesystems (but I am not going to upgrade them until there are 1.0 boot floppies, just to be safe) - Frank From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 06:06:12 1994 From: mycroft@gnu.ai.mit.edu To: randy%dsndata%sierra@sterling.com Subject: Re: Taylor UUCP 1.05 (patches) Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I think the last two sets of changes in your patch are rubbish. You forgot the path on the second argument to `diff'. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 06:15:53 1994 To: randy%dsndata%sierra@sterling.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Taylor UUCP 1.05 (patches) <199408030129.UAA20295@sierra.weeville.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have been running this version since it was put up for ftp. > No problems. There were a couple of hitches in the compile, > and I changed the version to 1.05 to avoid confusion. The > patches follow. Patches are relative to top level uucp dir. It looks to me like the latter two of those patches were just completely _wrong_... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 06:30:13 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: sd7-9 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu What is the point of having the devices /dev/sd7-9? It appears that nothing in the kernel will be assigned to these addresses. Should MAKEDEV be fixed? -SR From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 06:53:25 1994 To: "Chris G. Demetriou" Subject: Re: Taylor UUCP 1.05 (patches) Cc: current-users@sun-lamp.cs.berkeley.edu <9408021603.AA22129@alpha.bostic.com> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I've already merged Tuucp 1.04/1.05 changes into a NetBSD-current/1.04 > > base. It's at work, and I've built it at home, but haven't fully tested > > it yet. > > > > Do the core folks want this for 1.0-final, or is this too much of a > > change too late in the game ? > > in a phrase: "not on your life!!!!" > if _you_ say you haven't fully tested it yet... On that note.... I have been running this version since it was put up for ftp. No problems. There were a couple of hitches in the compile, and I changed the version to 1.05 to avoid confusion. The patches follow. Patches are relative to top level uucp dir. *** Makefile.inc.orig Tue Aug 2 20:19:52 1994 --- Makefile.inc Mon Aug 1 20:43:18 1994 *************** *** 7,13 **** LIBUUCP!=cd $(.CURDIR)/../libuucp; \ printf "xxx:\n\techo \$${.OBJDIR}/libuucp.a\n" | ${MAKE} -r -s -f - xxx ! VERSION= 1.04 owner= uucp bindir= /usr/bin sbindir= /usr/libexec/uucp --- 7,13 ---- LIBUUCP!=cd $(.CURDIR)/../libuucp; \ printf "xxx:\n\techo \$${.OBJDIR}/libuucp.a\n" | ${MAKE} -r -s -f - xxx ! VERSION= 1.05 owner= uucp bindir= /usr/bin sbindir= /usr/libexec/uucp *** uucico/Makefile.orig Tue Aug 2 20:19:17 1994 --- Makefile Thu Dec 16 23:59:08 1993 *************** *** 1,20 **** ! # Makefile for uucico ! # $Id: Makefile,v 1.2 1993/08/05 16:15:06 jtc Exp $ ! BINDIR= $(sbindir) ! BINOWN= $(owner) ! BINMODE= 4555 ! PROG= uucico ! SRCS= uucico.c trans.c send.c rec.c xcmd.c prot.c protg.c protf.c \ ! prott.c prote.c proti.c protj.c protz.c time.c chat.c \ ! conn.c copy.c log.c tcp.c tli.c util.c ! LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) ! DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) ! CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\" ! ! MAN8= uucico.0 ! ! .include ! .PATH: $(.CURDIR)/../common_sources --- 1,8 ---- ! # This is the Makefile for Taylor UUCP ! # $Id: Makefile,v 1.4 1993/08/05 17:56:17 jtc Exp $ ! SUBDIR= libunix libuucp libuuconf \ ! cu uuchk uucico uuconv uucp uulog uuname uupick uusched \ ! uustat uuto uux uuxqt ! .include *** uuxqt/Makefile.orig Tue Aug 2 20:19:01 1994 --- Makefile Thu Dec 16 23:59:08 1993 *************** *** 1,18 **** ! # Makefile for uuxqt ! # $Id: Makefile,v 1.2 1993/08/05 16:15:28 jtc Exp $ ! BINDIR= $(sbindir) ! BINOWN= $(owner) ! BINMODE= 4555 ! PROG= uuxqt ! SRCS= uuxqt.c util.c log.c copy.c ! LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) ! DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) ! CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\" ! ! MAN8= uuxqt.0 ! ! .include ! .PATH: $(.CURDIR)/../common_sources --- 1,8 ---- ! # This is the Makefile for Taylor UUCP ! # $Id: Makefile,v 1.4 1993/08/05 17:56:17 jtc Exp $ ! SUBDIR= libunix libuucp libuuconf \ ! cu uuchk uucico uuconv uucp uulog uuname uupick uusched \ ! uustat uuto uux uuxqt ! .include From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 06:53:45 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 2, 11:42pm, "Stephen J. Roznowski" wrote: > > What is the point of having the devices /dev/sd7-9? > > It appears that nothing in the kernel will be assigned > to these addresses. Should MAKEDEV be fixed? Oh? What makes you say that? What happens if I have 2 IDE drives and put 7 drives on my Warp Engine SCSI? (Not that I have that many drives yet :-).) Then there's my GVP SCSI board, my Supra SCSI board, and my home-made SCSI board... Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 07:01:24 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Peter Galbavy Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: "GenuineIntel" spacing ??? Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Peter Galbavy writes: > I only saw an >0.9a i386 install recently, and I like the bit > about the type of CPU... but is there supposed to be a space in > the sring "GenuineIntel" at boot time. > This is so trivial an issue that I wasn't going to raise a pr :) from what i hear from mycroft, the cpu returns a 12 byte identification (manuafacturer) string. intels return (coverted to ascii): GenuineIntel 000000000111 123456789012 which is the 12 bytes exactly -bri From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 3 08:18:46 1994 Subject: Re: A2024 - 10 views - audio From: Tim Newsham To: incg@sun.rz.tu-clausthal.de (Constantin Gonzalez) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Hi! hi > - Is someone currently working on an audio-device for NetBSD? I'm anxiously > waiting for compiling maplay... :) There is already support in the kernel for playing samples on the amiga sound hardware. It is currently used for the console beep. It should be fairly simple to add an audio device (as someone else has mentioned months ago). I'm suprised a device doesnt exist yet. If there isnt one when I come up to version 1.0 or -current then I'll work on one (although if I write one I probably wont put in support for mu-law encoded data as someone else intended to do although it should be easy to add this in afterwards as another minor device number). > Constantin Gonzalez | EMAIL: gonzalez@rz.tu-clausthal.de > Student at the | SNAIL: Muehlenstrasse 120 > Technical University of | 38678 Clausthal-Zellerfeld (Germany) > Clausthal | PHONE: +49 5323 1516 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 08:52:27 1994 X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Accessing the bugs database Sender: owner-current-users@sun-lamp.cs.berkeley.edu A few people asked me how to access the GNATS bugs database, so I'm reposting this: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From: conklin@ngai.kaleida.com (J.T. Conklin) Sender: owner-current-users@sun-lamp.cs.berkeley.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: How To Submit Bug Reports Date: Tue, 8 Feb 94 13:24:04 PST [ For the benefit of some of our newer -current-users, enclosed is a (slightly edited) copy of the USENET posting I made annoucing the introduction of the GNATS bug tracking systems. --jtc ] NetBSD switching to the GNATS bug tracking system. NetBSD has switched from the BSD bugfiler to GNU GNATS to maintain our bug database. This change will allow NetBSD developers to track bugs throughout their life cycle ("open", "analyzed", ... "closed"), assign them to the appropriate people to fix, and provide an reliable archive of bugs and their fixes. It is hoped that a better bug tracking system will allow the "core" developers to make NetBSD even better than it is today. What does the switch mean to users? * Bug reports should now submitted with the "send-pr" program. Although we appreciate bug reports sent posted in the news or sent to netbsd-bugs@sun-lamp.cs.berkeley.edu, sometimes they are accidentally overlooked. By using send-pr, you can be sure that the bug reports will be availible to the developers. Send-pr is distributed in NetBSD-current. * Bug reports will be automatically filed into the appropriate database category, and the appropriate people working on that area will be notified about the new bug. * Access to the bug database is a lot easier than with the bugfiler. Hopefully, convienent access will encourage NetBSD developers to keep up to date with the current bug list. If this occurs, the bugs you submit may be fixed faster. At the present time, there are only a few categories of bugs: "lib", for library bugs; "bin", for userlevel bugs; and "kern", for kernel bugs. More categories will be added as needed. How can I see if my bug has been fixed? * There is a email interface to our database. To query the database send mail to "query-pr@sun-lamp.cs.berkeley.edu". The mail server will send a bug database listing back to the user. * There are several flags that are useful to send to the mail server. The flags are entered in the "Subject" line: --summary Display an one-line entry for each bug --full Display the full entry for each bug --help Display a help string containing the rest of the flags. PR The Problem Report number of a particular bug 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 -- J.T. Conklin NetBSD Bug Database Administrator - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 10:33:35 1994 From: Brian Leonard To: current-users@sun-lamp.cs.berkeley.edu Subject: MSDOSFS and resolver Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've been having the same problem with msdosfs others have reported. I tried to cp something to the dos partition and ended up with a nicely hosed dosfs that chkdsk just laughed at. I'm running 7/13 bin snapshot with a newly sup'd (aug1) kernel. The other problem I'm having is that when my slip link is down, it takes up to a minute to resolve some names that are in /etc/hosts. /etc/host.conf has 'order hosts,bind' in it, so I don't understand why it would do this. I'm assuming it tries the nameserver first, times out and then goes to /etc/hosts. -- While one person hesitates because Brian Leonard he feels inferior, the other is busy paranoid@ccwf.cc.utexas.edu making mistakes and becoming superior. -- Henry C Link From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 11:03:58 1994 From: "Hubert Feyrer" "sd7-9" (Aug 2, 11:42pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 2, 11:42pm, Stephen J. Roznowski wrote: > What is the point of having the devices /dev/sd7-9? > > It appears that nothing in the kernel will be assigned > to these addresses. Should MAKEDEV be fixed? I guess these are the left-overs aftern Chris invented this (IMHO not so useful) new SCSI-encoding (sd0: first drive, ...). sd7-9 were used for IDE-drives before, if I got that right. Again: I don't like the new encoding, and I think there are lots of other people out there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 12:04:12 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: sd7-9" (Aug 3, 10:06am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Hubert Feyrer" , "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 3, 10:06am, "Hubert Feyrer" wrote: > I don't like the new encoding, and I think there are lots of other people out > there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) Yes, i don't like that, too. My system is constantly changing regarding drives, and i don't want to edit /etc/fstab all the times, only because of that funny scheme... -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 12:24:55 1994 From: Duncan McEwan To: "Martin Husemann" Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu It's taken me a while to get around to replying to this since I had to upgrade to a newer current. Now I'm running a current supped on around July 31st... I said: > If you do a "cu -l /dev/tty01" where tty01 has had the COM_SW_CLOCAL bit set > by ttyflags, the open succeeds. But when you try to type anything you get > > cu: write: input/output error ... to which Martin replied: > I don't know what version you are using, but with -current from 26 July > it works fine for me on i386. My /etc/ttys line is: > > # modem under control of mgetty: > tty01 "/usr/libexec/mgetty tty01" vt100 off local rtscts I still have exactly the same problem as before with this newer version of current. Perhaps mgetty is doing something to the state of the line to cause "cu" to not get the error. I'm not sure if the 1.05 version of "cu" fixes this problem. Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 12:27:23 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, martin@euterpe.owl.de Subject: Re: "GenuineIntel" spacing ??? Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...] - but my own computer says "i486-Class CPU". Is this a save way to detect non-Intel CPU's? No. Only fairly recent Intel 486s have the `cpuid' instruction which returns that string. Older ones do not, so the kernel can't print it out. I'm starting to consider removing that altogether. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 12:33:31 1994 From: Duncan McEwan To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Bounce buffers (was: Re: Return of "D'oh") <9408011703.AA02817@alpha.bostic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The generic solution is bounce buffers, but it's not going to get done today. I'm confused about the state of bounce buffers in -current. There seems to be code is i386/isa/dma.c to implement bounce buffers for dma above the 16Mb limit. Is this different than what is required for a bus-mastering scsi drive? Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 12:35:02 1994 Subject: Re: "GenuineIntel" spacing ??? To: bdc@ai.mit.edu (Brian D. Carlstrom) From: "Martin Husemann" Cc: peter@alice.wonderland.org, current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 699 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > from what i hear from mycroft, the cpu returns a 12 byte identification > (manuafacturer) string. intels return (coverted to ascii): > > GenuineIntel > 000000000111 > 123456789012 > > which is the 12 bytes exactly I saw this on one of the computers in the office when I tested my last installation disks - but my own computer says "i486-Class CPU". Is this a save way to detect non-Intel CPU's? I should call my dealer at once... Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 14:15:25 1994 From: mycroft@gnu.ai.mit.edu To: Mark_Weaver@brown.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: GENERICBT won't boot on my system Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'd guess that there's some sort of probe conflict. Since it seems to happen with the board at 0x330 and 0x340, I'd say it's probably not the aic0, ed0, ed1, ed2, ep0, or ie0 probes. It could be the aha0 probe, but that seems unlikely. Could you try removing le0 and/or aha0, and see if it boots? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 14:45:57 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: GENERICBT won't boot on my system <9408030915.AA07735@goldman.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu I bet it has something to do with my ATI GUP, which has ports all over the place. I remember someone a while back complaining about com3 being put in the kernel, because it prevented it from booting. That's because the com3 addresses conflict with the GUP. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 14:48:22 1994 From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt ) Subject: Re: Bounce buffers To: duncan@comp.vuw.ac.nz (Duncan McEwan) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 668 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm confused about the state of bounce buffers in -current. > > There seems to be code is i386/isa/dma.c to implement bounce buffers for > dma above the 16Mb limit. Is this different than what is required for a > bus-mastering scsi drive? Yes. The FreeBSD people supposedly got this working. So I assume that one fine day NetBSD will have it too. -- Volker -- ---------------------------------------------------------------------------- Volker A. Brandt Internet: volker@sfb256.iam.uni-bonn.de Angewandte Mathematik Phone/FAX: +49 228 63 36 84 (Bonn, Germany) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 15:27:38 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: how to concatenate disks From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu [the following should probably be in some sort of FAQ, so people don't have to go to the 'source', as i did.] How To Concatenate Disks --- -- ----------- ----- This document assumes that you're familiar with how to generate kernels, and how to properly set up a system configuration file. This document also assumes that you're using a fairly up to date system, as there are bugs limiting the use of concatenated disks; hopefully these will get fixed. This document also assumes you're using the hp300; your results will vary with other platforms, but this should give you a good idea of how to proceed. First, you need to add the disks that you wish to concatenate to your kernel config. These should probably all have hard coded id numbers and such, since you *really* don't want the autoconfig sequence to move these disks around. Here's a section of my config: master hpib0 at scode7 master hpib1 at scode? master hpib2 at scode? disk rd0 at hpib1 slave 0 disk rd1 at hpib1 slave 1 disk rd2 at hpib1 slave 2 disk rd3 at hpib2 slave 0 disk rd4 at hpib2 slave 1 disk rd5 at hpib2 slave 2 disk rd6 at hpib2 slave 3 tape ct0 at hpib0 slave ? In this example, I'm going to be concatenating the devices rd3, rd4, rd5, and rd6. Contrary to popular belief you really should *not* concatenate the 'c' partition of these disks. Rather, you should use some other partition, which you define in the individual disklabels of each disk to be the entire disk, except the first cylinder. This way, the concatenated filesystem does not write into the disklabel area of the disk. In this example, I will be using the 'h' partition of each disk. The line that actually sets up the ccd is: pseudo-device ccd0 on rd3h and rd4h and rd5h and rd6h interleave 8192 This will set up a ccd using rd3h, rd4h, rd5h, and rd6h, interleaving the access every 8192k blocks. The 'interleave' is important. From my reading of the code, without this specified, the driver will use each full disk in sequence, which really doesn't seem as efficient as interleaving the access. In my system all of the concatenated disks are hp7958s, which are ~120meg drives. I've set the disklabel on each of them up as: # /dev/rrd3c: type: HP-IB disk: label: flags: bytes/sector: 512 sectors/track: 36 tracks/cylinder: 7 sectors/cylinder: 252 cylinders: 1013 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 8 partitions: # size offset fstype [fsize bsize cpg] c: 255276 0 boot 1024 4096 16 # (Cyl. 0 - 1012) h: 255024 252 4.2BSD 1024 4096 16 # (Cyl. 1 - 1012) Of course, this disklabel most likely won't work on any other disk type, so you'll have to roll your own. Simply make partition 'h' (or whatever you gave in the ccd pseudo-device declaration) the size of partition 'c', minus the number of sectors per cylinder, and set the offset to the same sectors/ cylinder. Once the label is set up on each disk, you should reboot with the newly generated ccd kernel. At boot time, it will come up with a message like this, shortly after it autoconfigures all the drives: ccd0: 4 components (rd3h, rd4h, rd5h, rd6h), 1015808 blocks interleaved at 8192 blocks ccd0 configured If you don't get this message, the ccd is NOT configured. You should cd into your /dev, and do a MAKEDEV cd0, if you haven't already. No it's time to write a disktab entry for the ccd, since it doesn't support disklabels in itself. I used the following, based on the standard hp300 7958 entry: rd7958-4:\ :ty=winchester:ns#36:nt#7:nc#4052:\ :pc#1015808:bc#4096:fc#1024: All values are copied from the 'standard' entry, taking into account any differences from your disklabel(s), except: nc#4052 This is the total number of cylinders. This should be the total number of cylinders from all of the partitions you defined your ccd to encompass. pc#1015808 This is the total size, and should be the total size from all of the partitions your configured into your ccd. If your disktab is set up correctly, you can now newfs your ccd: # newfs /dev/rccd0c rd7958-4 Where '/dev/rccd0c' is the raw device, and 'rd7958-4' is the name of your disktab entry. Note that the hp300 MAKEDEV may very will name this 'rcd0c', if it hasn't been fixed yet. You should now have a working concatenated disk, which can be fsck'd, mounted, and used just like any other, normal, disk. Written by Jason Downs, ; inspired by some mail written by Mike Hibler. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 15:41:07 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: uha io size is 16 bytes Sender: owner-current-users@sun-lamp.cs.berkeley.edu When NetBSD reports: uha0 at isa0 port 0x330-0x333 irq 11 It's wrong about the port address range. On the 34f, there are 16 consequtive byte-sized registers. In fact, I'm quite sure the 14f has exactly the same register set. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 15:59:35 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: GENERICBT won't boot on my system Sender: owner-current-users@sun-lamp.cs.berkeley.edu The current (supped today) GENERICBT kernel won't boot on my system. Neither will the GENERICBT kernel packaged in the binary shapshot made around July 15th or so. This is after taking all the hardware out of my system except for my SCSI card and my video card. Here's what I've got: Gateway 2000 i486-DX2/66 vlb, 16mb ram ATI Graphics Ultra Pro, 2mb vram UltraStor 34F vlb Here's what happens. It prints the following: NetBSD 1.0_BETA (GENERICBT) #0: Wed Aug 3 02:17:12 EDT 1994 mhw@cis-ts3-slip5.cis.brown.edu:/usr/src/sys/arch/i386/compile/GENERICBT CPU: i486DX (486-class CPU) real mem = 16121856 avail mem = 14106624 using 222 buffers containing 909312 bytes of memory pc0 at isa0 port 0x60-0x6f irq 1: color com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo lpt2 at isa0 port 0x3bc-0x3c3: polled wdc0 at isa0 port 0x1f0-0x1f7 irq 14 wd0 at wdc0 drive 0: 325MB 1010 cyl, 12 head, 55 sec fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec fd1 at fdc0 drive 1: 1.2MB 80 cyl, 2 head, 15 sec uha0 at isa0 port 0x330-0x333 irq 11 scsibus2 at uha0 uha0 targ 0 lun 0: SCSI1 direct fixed sd0 at scsibus2: 992MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec uha0 targ 1 lun 0: SCSI1 sequential removable st0 at scsibus2: rogue, density code 0x0, 1024-byte blocks, write-protected ie0: unknown AT&T board type code 0 ie0: can't map 3C507 RAM in high memory npx0 at isa0 port 0xf0-0xff: using exception 16 biomask 4840 netmask 3a ttymask 3a changing root device to sd0a and then it just freezes until I hit reset. It fails the same way when I try to boot off my IDE drive with the UltraStor configured at 0x340 (so it doesn't find it). Here's a diff -u between what I see above and what I see when I boot with my custom kernel. The kbd_cmd line is just a random problem that sometimes happens with either kernel. --- genericbt Wed Aug 3 04:44:55 1994 +++ excelsior Wed Aug 3 04:45:17 1994 @@ -1,26 +1,27 @@ -NetBSD 1.0_BETA (GENERICBT) #0: Wed Aug 3 02:17:12 EDT 1994 - mhw@cis-ts3-slip5.cis.brown.edu:/usr/src/sys/arch/i386/compile/GENERICBT +NetBSD 1.0_BETA (EXCELSIOR) #0: Wed Aug 3 01:18:59 EDT 1994 + mhw@cis-ts3-slip5.cis.brown.edu:/usr/src/sys/arch/i386/compile/EXCELSIOR CPU: i486DX (486-class CPU) real mem = 16121856 -avail mem = 14106624 +avail mem = 13774848 using 222 buffers containing 909312 bytes of memory +kbd_cmd: input char 47 lost pc0 at isa0 port 0x60-0x6f irq 1: color +npx0 at isa0 port 0xf0-0xff: using exception 16 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo -lpt2 at isa0 port 0x3bc-0x3c3: polled +com2 at isa0 port 0x3e8-0x3ef irq 9: ns16550a, working fifo +lpt0 at isa0 port 0x3bc-0x3c3: polled wdc0 at isa0 port 0x1f0-0x1f7 irq 14 wd0 at wdc0 drive 0: 325MB 1010 cyl, 12 head, 55 sec fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec fd1 at fdc0 drive 1: 1.2MB 80 cyl, 2 head, 15 sec -uha0 at isa0 port 0x330-0x333 irq 11 -scsibus2 at uha0 +uha0 at isa0 port 0x340-0x343 irq 11 +scsibus0 at uha0 uha0 targ 0 lun 0: SCSI1 direct fixed -sd0 at scsibus2: 992MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec +sd0 at scsibus0: 992MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec uha0 targ 1 lun 0: SCSI1 sequential removable -st0 at scsibus2: rogue, density code 0x0, 1024-byte blocks, write-protected -ie0: unknown AT&T board type code 0 -ie0: can't map 3C507 RAM in high memory -npx0 at isa0 port 0xf0-0xff: using exception 16 -biomask 4840 netmask 3a ttymask 3a -changing root device to sd0a +st0 at scsibus0: rogue, density code 0x0, 1024-byte blocks, write-protected +biomask 4840 netmask 21a ttymask 21a + + Aperture driver for XFree86 version 1.1 Both kernels were just built from scratch by completely deleting the compile/* directory, configuring it, and "make depend;make"'ing it. Here's my excelsior config: # # EXCELSIOR # machine "i386" ident EXCELSIOR cpu "I486_CPU" options "COMPAT_09" options MATH_EMULATE options MACHINE_NONCONTIG timezone 5 dst maxusers 10 options SWAPPAGER,VNODEPAGER,DEVPAGER options KTRACE options FIFO options SYSVMSG options SYSVSEM options SYSVSHM options LKM options SCSI options QUOTA options MFS options FFS options NFSSERVER options NFSCLIENT options MSDOSFS options FDESC options SETUIDSCRIPTS, FDSCRIPTS options KERNFS options INET options NS options ISO options TPIP options EON options MULTICAST options GATEWAY options DDB, DIAGNOSTIC options "USER_LDT" options "COMPAT_NOMID" options "COMPAT_43" options "TCP_COMPAT_42" options XSERVER,UCONSOLE options "PCVT_META_ESC=1" config netbsd root on sd0 swap on sd0 controller isa0 device pc0 at isa? port "IO_KBD" irq 1 device npx0 at isa? port "IO_NPX" irq 13 device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 9 device lpt0 at isa? port "IO_LPT3" controller wdc0 at isa? port "IO_WD1" irq 14 disk wd0 at wdc0 drive ? controller fdc0 at isa? port "IO_FD1" irq 6 drq 2 disk fd0 at fdc0 drive ? disk fd1 at fdc0 drive ? controller uha0 at isa? port 0x340 irq ? drq ? master scsibus0 at uha0 device sd0 at scsibus0 slave ? device st0 at scsibus0 slave ? pseudo-device pty 64 pseudo-device loop pseudo-device ether #XXX pseudo-device log pseudo-device bpfilter 4 pseudo-device sl 2 pseudo-device ppp pseudo-device vn 4 pseudo-device speaker pseudo-device tb I'm going to be away until Sunday. If anyone has any quick ideas to try, I can test them now, but it'll have to be quick. I'm sorry about the rush, but there's not much I can do. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 16:38:45 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Re: sd7-9 To: c9020@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 591 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On Aug 2, 11:42pm, Stephen J. Roznowski wrote: > > What is the point of having the devices /dev/sd7-9? > > > > It appears that nothing in the kernel will be assigned > > to these addresses. Should MAKEDEV be fixed? > > I guess these are the left-overs aftern Chris invented this (IMHO not so > useful) new SCSI-encoding (sd0: first drive, ...). sd7-9 were used for > IDE-drives before, if I got that right. > How about multiple disk controllers with lot's of drives? I realise most of us don't have > 2 disks and most aren't > 1G but we should think about future expansion... -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 16:41:54 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Re: sd7-9 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 663 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On Aug 3, 10:06am, "Hubert Feyrer" wrote: > > I don't like the new encoding, and I think there are lots of other people out > > there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) > > Yes, i don't like that, too. My system is constantly changing regarding > drives, and i don't want to edit /etc/fstab all the times, only because > of that funny scheme... > Since we're all voting I'll cast mine for the new scheme as it is the REAL BSD 4.4 scheme. The older schemes are from a bygone era... I agree with Chris, let's make this port as close to the others as possible and that includes device autoconfig. My $0.02 US, -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 16:58:06 1994 To: "Chris G. Demetriou" Subject: Re: Taylor UUCP 1.05 (patches) Cc: current-users@sun-lamp.cs.berkeley.edu <9408030223.AA08342@alpha.bostic.com> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I have been running this version since it was put up for ftp. > > No problems. There were a couple of hitches in the compile, > > and I changed the version to 1.05 to avoid confusion. The > > patches follow. Patches are relative to top level uucp dir. > > It looks to me like the latter two of those patches were just > completely _wrong_... To quote Charles, "completely rubbish". My appologies. Give these a try. *** Makefile.inc.orig Tue Aug 2 20:19:52 1994 --- Makefile.inc Mon Aug 1 20:43:18 1994 *************** *** 7,13 **** LIBUUCP!=cd $(.CURDIR)/../libuucp; \ printf "xxx:\n\techo \$${.OBJDIR}/libuucp.a\n" | ${MAKE} -r -s -f - xxx ! VERSION= 1.04 owner= uucp bindir= /usr/bin sbindir= /usr/libexec/uucp --- 7,13 ---- LIBUUCP!=cd $(.CURDIR)/../libuucp; \ printf "xxx:\n\techo \$${.OBJDIR}/libuucp.a\n" | ${MAKE} -r -s -f - xxx ! VERSION= 1.05 owner= uucp bindir= /usr/bin sbindir= /usr/libexec/uucp *** uucico/Makefile.orig Tue Aug 2 20:19:17 1994 --- uucico/Makefile Mon Aug 1 20:21:32 1994 *************** *** 12,18 **** LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\" MAN8= uucico.0 --- 12,19 ---- LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\"\ ! -DOWNER=\"$(owner)\" MAN8= uucico.0 *** uuxqt/Makefile.orig Tue Aug 2 20:19:01 1994 --- uuxqt/Makefile Mon Aug 1 20:42:45 1994 *************** *** 10,16 **** LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\" MAN8= uuxqt.0 --- 10,17 ---- LDADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) DPADD+= $(LIBUNIX) $(LIBUUCONF) $(LIBUUCP) CFLAGS+= -I$(.CURDIR)/../common_sources\ ! -DVERSION=\"$(VERSION)\"\ ! -DOWNER=\"$(owner)\" MAN8= uuxqt.0 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:26:43 1994 From: Herb Peyerl Subject: Re: how to concatenate disks To: downsj@CSOS.ORST.EDU (jason downs) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 809 Sender: owner-current-users@sun-lamp.cs.berkeley.edu [README file deleted] Thanx Jason. Maybe that document should go somewhere or something. When I merged the ccd code in; I didn't add any support to any of the other architectures. Currently; only 'config' (as opposed to config.new) architectures are supported... The work to 'config' was somewhat extensive. I can see adding support to the 'i386' port. It would be fairly trivial (a few changes to conf.c should do it). However; I'm not sure of the interaction with the i386 scsi-subsystem.. Anyways; now that I'm back from vacation I might have some time to play with this... hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:28:20 1994 From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt ) Subject: Re: Bounce buffers To: volker@sfb256.iam.uni-bonn.de (Volker A. Brandt) Cc: duncan@comp.vuw.ac.nz, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 590 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > There seems to be code is i386/isa/dma.c to implement bounce buffers for > > dma above the 16Mb limit. Is this different than what is required for a > > bus-mastering scsi drive? > > Yes. ... said the idiot, when he meant "no" :-) It's exactly the same problem. Sorry -- Volker -- ---------------------------------------------------------------------------- Volker A. Brandt Internet: volker@sfb256.iam.uni-bonn.de Angewandte Mathematik Phone/FAX: +49 228 63 36 84 (Bonn, Germany) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:31:11 1994 From: Mike Long To: Mark_Weaver@brown.edu Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: GENERICBT won't boot on my system Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From: Mark_Weaver@brown.edu >Date: Wed, 03 Aug 1994 05:28:19 -0400 > >I bet it has something to do with my ATI GUP, which has ports all over >the place. I remember someone a while back complaining about com3 >being put in the kernel, because it prevented it from booting. That's >because the com3 addresses conflict with the GUP. I haven't tried the 8/1 netbsd-bt kernel yet, but the 7/13 netbsd-bt kernel worked fine on my Gateway2K DX2/66 system with an ATI GUP. The major difference between my hardware and yours is that I don't have any SCSI, just the single IDE drive. I'd point the finger at the UltraStor if I were you. com3 (DOS' COM4:) hasn't been in the GENERIC* configs for a while, since the screams of multiple ATI GUP owners were heard. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:32:07 1994 To: Herb Peyerl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks <199408031420.IAA04380@sidney.novatel.ca> From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199408031420.IAA04380@sidney.novatel.ca>, Herb Peyerl writes: >When I merged the ccd code in; I didn't add any support to any of the >other architectures. Currently; only 'config' (as opposed to config.new) >architectures are supported... The work to 'config' was somewhat >extensive. does config.new even know anything about component pseudo-devices? >I can see adding support to the 'i386' port. It would be fairly trivial >(a few changes to conf.c should do it). However; I'm not sure of the >interaction with the i386 scsi-subsystem.. this would be very nice. ccd works quite well, once you've gotten it set up properly. it would be a boon to the i386 port, as they are probably just as likely to have lots of old, small, disks around as on the hp300. (watching that stack of disks fsck as a single FS is a trip.) -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:40:29 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: "GenuineIntel" spacing ??? <9408030821.AA07605@goldman.gnu.ai.mit.edu> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > No. Only fairly recent Intel 486s have the `cpuid' instruction which > returns that string. Older ones do not, so the kernel can't print it > out. > I'm starting to consider removing that altogether. Or you could append the string "(too bad)". :-) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 17:44:18 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Snapshot Report - July 31st tar_files To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6617 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Snapshot report. ================ Me: agc@uts.amdahl.com (Alistair G. Crooks) Source: tar_files, 31st July 1994, from sun-lamp.cs.berkeley.edu Base version of NetBSD: 0.9. Upgrade from previous -current: yes, 23rd July sources from ftp.iastate.edu Machine specifics: 386DX/40+387, 16MB RAM, 1542CF, 540 MB SCSI (Quantum), VGA Other software: Matthieu Herrb's XFree86 2.1.1, built July 21 1994. Tar files integrity: good. Additional things to do during upgrade: None Any warnings during compilation: None Any problems during make: None Observations: None Changes from previous snapshot report: (This is taken from the CHANGES file on sun-lamp - last update on 27 July 94) add kerberos5 (k5login.c) authentication for login. (brezak) build mount_nfs with kerberos iff kerberos environment. (brezak) build sys/lib/libsa with the rest of the kernel/sa libs. (brezak) add conditional kerberosIV and kerberos5 support to passwd. (brezak) Also the following have been announced: [i386] boot block fixed to run on 386s (mycroft) [i386] disklabel no longer munges device number (mycroft) [i386] autoconf detects SCSI card IRQ/DRQ for aha/ahb/bt/uha (mycroft) Notes: 1. OK, thanks for all the updates. Latest i386-SCSI controller list: aha1542b isa aha1542.c mycroft@gnu.ai.mit.edu aha1542c/cf isa aha1542.c hpeyerl@novatel.ca aha1742 eisa aha1742.c cgd@postgres.berkeley.edu aha1742 eisa aha1742.c mycroft@gnu.ai.mit.edu aic6360 isa aic6360.c mycroft@gnu.ai.mit.edu bt445 vlb bt742a.c dhess@cs.stanford.edu bt542 isa aha1542.c tim@introl.introl.com bt545 isa aha1542.c tim@introl.introl.com bt742 eisa bt742a.c deraadt@fsa.ca bt747 eisa bt742a.c michaelv@iastate.edu ultra34f vlb ultra14f.c jkreska@hpmail2.fwrdc.rtsg.mot.com ultra14f isa ultra14f.c mycroft@gnu.ai.mit.edu [Michael VanLoon tells me that all the BusTek cards should work with bt742a.c - and a cursory glance through the code seems to back this up - can someone confirm this for me, please?] [The AIC-6360 includes Soundblaster Pro 16 SCSI-2, Zeos motherboard SCSI controllers and others. This should include the AIC-6260 and thus the 1510/1520/1522 boards but currently doesn't] [The Adaptec 2xxx is not supported, and may not be in future due to Adaptec's refusal to release "proprietary information" about the board.] General reasoning is that Adaptec support isn't good for non-DOS problems, and re the 2742 issue. The Ultrastore has jumpers for everything, which can be a pain, and I'm not even sure they're in business any more. The Bustek boards have had favourable reports. Please note that I'm just condensing other people's opinions here, all you lawyers out there. 2. Likewise, the i386 Ethernet controller list. (Thanks to tdr for the update - any mistakes are mine). 3c501 isa if_el (kimmel@cs.umass.edu) 3c503 (and probably 3C507, but I can't actually test it) (mycroft) 3c509 isa if_ep bnc/aui/utp. (tdr) 3c579 eisa if_ep (tdr) WD 8390-based cards isa if_ed (mycroft) SMC 8390-based cards isa if_ed (mycroft) NE1000, NE2000 isa if_ed (mycroft) NE2100/BICC Isolan/DEPCA isa if_le (mycroft) AT&T StarLAN (82586-based cards) (mycroft) If anyone has any more to add to this list, please contact me. 3. This week's compilation of everything was peachy again. Absolutely no problems. Remember to change those (i386) config files so that autoconf can probe for the SCSI board, rather than giving the specific IRQ/DRQ numbers. Nice - worked fine for my 1542. 4. There seem to be some msdosfs funnies still. 5. As no-one from any non-i386 groups got in contact, I'll assume that they can put up with tales of woe about i386 motherboards and hardware. Either that or superior smirks whenever someone mentions IRQs. 6. I noticed that the usr.sbin Makefile has catman commented out, wth the comment "not yet done", although it builds and seems to run fine on i386. 7. I got xcdplayer almost running - anyone else interested in this baby? 8. As 1.0 seems to be frozen (except for bug-fixes), can I suggest some things for 1.1? a) we should practice what we preach and remove all occurrences of gets() in the sources. I got the following list from /usr/src usr.sbin/named/tools/nstest/nstest.c usr.sbin/diskpart/diskpart.c games/mille/varpush.c games/backgammon/common_source/backgammon.c gnu/usr.bin/gdb/readline/history.c gnu/usr.bin/gdb/readline/tilde.c gnu/usr.bin/gdb/gdb/regex.c gnu/usr.bin/gas/config/tc-m68k.c gnu/usr.bin/gas/config/tc-vax.c gnu/usr.bin/gas/hash.c gnu/usr.bin/tar/getdate.y gnu/usr.bin/rcs/lib/rcsrev.c gnu/lib/libg++/libg++/regex.cc share/lkm/syscall/test/testsyscall.c share/lkm/misc/test/testmisc.c usr.bin/tn3270/ctlr/api.c (There were also some occurrences in the various kernel boot files, and libsa, but I'm not sure that's the libc gets(3), and if you have access to the console at boot time, then do you really want to check for overrun in the input, and jumping to dubious routines on the stack e.g. what stack?) I've done the diskpart.c ones, and will continue file by file unless I'm told that what I'm doing is worthless. b) has any thought been put into moving towards full ANSI C? 9. My thoughts go to my Amdahl colleagues who have gone on vacation and on training courses, leaving me to look after all problems worldwide between the hours of 08:00 and 16:00 BST, plus my own job, plus my manager's job. I thank you all from the heart of my bottom. 10. The future (by a core-team member) > My guess on when 1.0 will ship is "just before 8/3, or just after 8/9." with support for the following architectures: amiga hp300 i386 pc532 sparc > I actually hope that the next release (1.1) will happen sooner > than six months from now. Some of the goals for it include > complete 4.4-Lite integration, more device support (for all > architectures), more stability, more uniformity across the > architectures, and better install tools. There are obviously > more things that are on the todo list than that, but those > are what pop into my mind immediately. Roll on August 9th Cheers, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 18:34:22 1994 From: John Kohl To: duncan@comp.vuw.ac.nz Cc: martin@euterpe.owl.de, cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I tried my 1.05 cu this morning, on a line configured: tty04 "/usr/libexec/getty tty01" vt100 off rtscts (I have a FlexFAX daemon running on that line, exec'ed from rc.local) and it worked fine for me. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 19:03:00 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Brian Leonard Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: MSDOSFS and resolver <199408030415.XAA19102@foghorn.cc.utexas.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The other problem I'm having is that when my slip link is >down, it takes up to a minute to resolve some names that are in >/etc/hosts. /etc/host.conf has 'order hosts,bind' in it, so I don't >understand why it would do this. I'm assuming it tries the nameserver >first, times out and then goes to /etc/hosts. It goes in /etc/resolv.conf, and it doesn't have a space. It's like this: [root@MindBender]~# cat /etc/resolv.conf lookup file bind search cc.iastate.edu iastate.edu HeadCandy.com nameserver 129.186.140.33 nameserver 129.186.140.200 nameserver 129.186.1.200 Do a ``man resolv.conf'' for more info. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 19:08:23 1994 From: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Subject: NetBSD/i386: any boot floppies available? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1119 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I was about to upgrade my machine from -current of about a month ago to Aug 1 binary snapshot when I blew away my boot partition. I was about to make a boot floppy but type "newfs /dev/rsd0a" not rfd0a. Anyway, I now need a boot floppy to rebuild my system. I thought the standard boot floppies were built currently but Was not able to find them on any archives I searched sun-lamp, iastate, umich. The "standard" boot floppy with aha support would be great. My binaries are on a machine just next to the machine they are to be installed on. The files can be copied by ethernet or serial. Machine: i486 aha1542 (2 scsi drives, no working tape) SMC Ultra Elite (not supported on 0.9) (i cannot use the old floppies). two serial ports (450) What is the current plans for the i386 release for new installs. How does a person who has not yet run NetBSD install on the system? ------------------------------------------------------------------------ Dale Rahn, Languages and Tools drahn@urbana.mcd.mot.com Motorola, MCG, Urbana Design Center 1101 E. University Ave, Urbana, IL 61801 (217) 384-8585 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 19:09:01 1994 To: volker@sfb256.iam.uni-bonn.de Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Bounce buffers <199408031428.QAA22922@sfb256.iam.uni-bonn.de> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> > There seems to be code is i386/isa/dma.c to implement bounce buffers for >> > dma above the 16Mb limit. Is this different than what is required for a >> > bus-mastering scsi drive? >> >> Yes. > >... said the idiot, when he meant "no" :-) It's exactly the same problem. Err, wait ... now you've got _me_ confused :-) Please correct me if I'm wrong, but ... The code in dma.c implements bounce buffering when you use the DMA controller on the motherboard. This works fine for devices that are not bus-mastering (like the floppy drives). If your buffer is at a higher address than 16Mb, it copies it to one in lower memory and copies it back after you call isa_dmadone(). However, since bus-mastering cards to DMA themselves, the way you typically use them is to program the information on the card and have them perform the DMA transfer (ie - you don't use the isa_dma* routines, except maybe isa_dmacascade() ). But the card has no way of knowing if the buffer given it is greater than 16Mb, and even if it did, it wouldn't know what to do. It seems to me you could implement this really cheezily by just implementing bounce buffers in each affected device driver (you could look for the test statements marked "DMA past end of ISA" and go from there). --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 19:17:17 1994 From: Alan Barrett Subject: Re: bind-4.9.3 To: Theo de Raadt Cc: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Paul Vixie has now said that there will be a beta10 for bind-4.9.3, and I expect that to push the bind-4.9.3 release date well past the projected NetBSD-1.0 release date. Oh well. > I guess I'll do it, eventually. If you sit down before I do, send the > diffs to me. But don't bother touching the resolver at all; I'm fairly > sure that our resolver is in better shape than the standard bind one. The standard bind resolver has improved significantly over the past year. --apb (Alan Barrett) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 19:33:17 1994 From: Donn Cave X-Sender: donn@saul2.u.washington.edu Subject: Re: sd7-9 To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 544 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I personally am not inconvenienced by the new scheme, but on the other hand there's nothing wrong with old stuff that works. I assume that it will still be possible to recompile the kernel with fixed units as desired. Maybe someone who's seriously motivated will figure out a way to have loadbsd slip in a table of manufacturer IDs and units, for advisory purposes during configuration. It would have to be pretty slick, but if it were also good for swap and root partition configuration, it might sell. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 19:53:20 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: sd7-9 Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199408031339.IAA25097@kas.helios.mn.org> rhealey@kas.helios.mn.org (Rob Healey) writes: > > On Aug 3, 10:06am, "Hubert Feyrer" wrote: > > > I don't like the new encoding, and I think there are lots of other people out > > > there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) > > > > Yes, i don't like that, too. My system is constantly changing regarding > > drives, and i don't want to edit /etc/fstab all the times, only because > > of that funny scheme... > > > Since we're all voting I'll cast mine for the new scheme as it > is the REAL BSD 4.4 scheme. The older schemes are from a bygone > era... I agree with Chris, let's make this port as close to > the others as possible and that includes device autoconfig. Yes! And if you don't like the new scheme, then the answer is really simple: don't use it! Add the following lines: sd0 at scsibus? target 0 lun 0 sd1 at scsibus? target 1 lun 0 sd2 at scsibus? target 2 lun 0 sd3 at scsibus? target 3 lun 0 sd4 at scsibus? target 4 lun 0 sd5 at scsibus? target 5 lun 0 sd6 at scsibus? target 6 lun 0 sd7 at scsibus? target ? lun 0 Back to your config file before the "sd*" line, build a new kernel, and you're all set. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 20:49:53 1994 From: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld) To: current-users@sun-lamp.cs.berkeley.edu Subject: Looking for clues about nroff -man.. Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am woefully unenlightened about *roff. In writing a man page for a device driver for NetBSD, I discovered that the following: .Nm lt produces no output in the resulting file, while .Nm ell-tee and .Nm LT both Do The Right Thing. Do I need to rename my driver? :-) Clearly the character string "lt" is "magic" in some way, as it appears often in the tmac files in /usr/share/tmac/* How do I "quote" it? - Bill From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 21:01:34 1994 To: jason downs Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks <199408031119.EAA06559@CSOS.ORST.EDU> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > [the following should probably be in some sort of FAQ, so people don't have > to go to the 'source', as i did.] > > How To Concatenate Disks > --- -- ----------- ----- No, it should be a man page. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 21:30:22 1994 To: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Looking for clues about nroff -man.. <199408031640.MAA00268@orchard.medford.ma.us> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I am woefully unenlightened about *roff. and you consider that a bad thing? 8-) > Clearly the character string "lt" is "magic" in some way, as it > appears often in the tmac files in /usr/share/tmac/* right. 'lt' is probably the name of a macro. you should use it as: .Nm \< In general, to be safe, if i'm using _any_ two-letter sequence in as an argument to a macro, i quote it like that. what happens is that the macro being invoked (in this case Nm) can invoke macros in its arguments, so in this case (and several others i've seen, such as ".Nm ex" and ".Op Fl x Ar aw" from the nvi man page) the wrong thing happens to the argument... chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 21:35:01 1994 From: Herb Peyerl Subject: Re: how to concatenate disks To: deraadt@fsa.ca (Theo de Raadt) Cc: downsj@CSOS.ORST.EDU, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 280 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : No, it should be a man page. Oh; good point. Jason? hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 21:39:21 1994 To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Snapshot Report - July 31st tar_files X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > My guess on when 1.0 will ship is "just before 8/3, or just after 8/9." Actually, that was really my guess on when betas of reall installation sets, etc. will ship, but i was probably quoted correctly, and just didn't type what i meant. in any case, the current hope is for beta floppies (for the i386) sometime a bit after 8/9. Other ports should (hopefully) be releasing beta-test binaries will mostly-complete install tools very soon now... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 22:43:24 1994 From: chopps@emunix.emich.edu To: "Hubert Feyrer" Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 <9408031006.ZM9914@rrzc1> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Again: > > I don't like the new encoding, and I think there are lots of other people out > there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) Look I am so tired of arguements like this I am beginning to *hate* reading these lists. You don't like it; WHY? I don't even feel like I need to justify the change. To me, at least, its somewhat obvious. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 22:45:06 1994 From: chopps@emunix.emich.edu To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 <9408030922.AA13617@rabe.techfak.uni-bielefeld.de> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On Aug 3, 10:06am, "Hubert Feyrer" wrote: > > I don't like the new encoding, and I think there are lots of other people out > > there. Maybe we could do together and convince Chris to stop it? ;) Chris? :) > > Yes, i don't like that, too. My system is constantly changing regarding > drives, and i don't want to edit /etc/fstab all the times, only because > of that funny scheme... Be reasonable, changing your fstab as compared with ripping your machine open and adding/removing drives? Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 3 23:03:21 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: I'm getting a currupted freelist To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu When I'm compiling, I have been getting problems with a corrupted freelist. I'm running current as of 040894, and after a while cc1 gets a funny signal (either 4 or 11, it varies). The kernel prints out something like this: Aug 2 04:57:05 foobar /netbsd: Data modified on freelist: word 0 of object 0x503800 size 72 previous type exec (0xeadbeef != 0xdeadbeef) Aug 2 06:34:07 foobar /netbsd: Data modified on freelist: word 0 of object 0x4b8400 size 24 previous type VM pvmap (0xeadbeef != 0xdeadbeef) Aug 2 06:34:18 foobar /netbsd: Data modified on freelist: word 0 of object 0x503480 size 24 previous type VM pvmap (0xeadbeef != 0xdeadbeef) After this happens, I can't exec anything. Whenever I try, it gets a segmentation fault and core dumps. I'm running a custom kernel on a 2500 (A2630+A2091). If any one wants, I can provide my kernel config file. I removed everything I don't need; the only SCSI controller is for the 2091, no Retina code, no ethernet adapter, no NFS server or client, and no ISOFS. I also left the kernel debugger out. Any ideas? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 23:19:10 1994 From: "Hubert Feyrer" "Re: sd7-9" (Aug 3, 4:15pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I Subject: Re: sd7-9 Cc: amiga-dev@sun-lamp.cs.berkeley.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 3, 4:15pm, chopps@emunix.emich.edu wrote: > > I don't like the new encoding, and I think there are lots of other people out ... > You don't like it; WHY? Sorry for being unprecise. I don't like it for the following reason: Whenever I add or remove a drive, I'll have to re-edit fstab, paying special attention not to assign the wrong SCSI-ID to the right device. Changing some drives can happen quite often here, as I occasionaly install it on some friends' harddisk (from my setup, without using tons of disks ;). Regards, Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 3 23:29:37 1994 From: Russel Miranda Subject: Re: sd7-9 To: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Wed, 3 Aug 1994 chopps@emunix.emich.edu wrote: > Be reasonable, changing your fstab as compared with ripping your machine open > and adding/removing drives? I have an external case, unplugging it is SIMPLE. My $0.02 US. )Russ From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 23:42:45 1994 To: Herb Peyerl Cc: deraadt@fsa.ca (Theo de Raadt), current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks <199408031833.MAA05032@sidney.novatel.ca> From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199408031833.MAA05032@sidney.novatel.ca>, Herb Peyerl writes: >: No, it should be a man page. > >Oh; good point. > >Jason? i think an nroff version can be arranged. stay tuned. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 23:55:37 1994 From: gooderum@SCTC.COM (Mark Gooderum) Subject: Adaptec 1742 To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.2 PL13] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone know of a source that still has these, or can any one point me at "current" cards being manufactured that are 1742 comatible? I have a friend that needs to know. -- Mark Gooderum gooderum@sctc.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 3 23:57:08 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: /kernfs mounts To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 299 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I don't know if this is a bug, or a feature... but if I do a mount -a more than once, /kernfs gets mounted again each time. (ok, mount reports it's mounted, may not really be mounted again) Everything still works, but if I do a 'mount' it's irritating to see the multiple listings... :-) -Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 00:06:22 1994 From: bspencer@bassun.cb.att.com (Brad Spencer) To: current-users@sun-lamp.cs.berkeley.edu Subject: Buslogic SCSI cards (was: Snapshot Report - July 31st tar_files) Sender: owner-current-users@sun-lamp.cs.berkeley.edu agc@uts.amdahl.com (Alistair G. Crooks) said: >[Michael VanLoon tells me that all the BusTek cards should work with >bt742a.c - and a cursory glance through the code seems to back this up >- can someone confirm this for me, please?] I have a Pentium 90MHZ with a Buslogic [what BusTek is called now] bt-946c PCI card and it appears to work mostly fine. I have two drives, both were pulled from Sun workstations and both claim to be SUN207s, except that they aren't the same type of drive. One is a SCSI-1 that doesn't do sync. mode, the other is SCSI-2 and is suppose to do sync. mode. Anyway, sometimes when the SCSI-2 drive is accessed, I get: bt0: mbi at [some address] should be found, stat=81..resync messages on the console. They appear to be fairly harmless, i.e. no corrupt data or anything like that. Brad Spencer - bspencer@bassun.cb.att.com [work] brad@anduin.eldar.org [home] From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 00:09:21 1994 Subject: My $0.02 From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have an Insite floptical. If I boot NetBSD without a disk in the floptical drive, then he kernel will not even recognize the device. At the moment, the floptical is sd2, and my hard drives are sd5 and sd6. Under the new assignment scheme, I must either always boot with a floppy inserted, or never do. Since I use the floptical for file transfer, I will always have to have a disk in there. Before upgrading, I will change the floptical to sd6, and my hard drives to sd0 and sd1. That will minimize the problem. However, I plan to test-install the 1.0 release on sd6, keeping my AmigaOS and old BSD stuff on sd5. I have yet to figure out which order things will go in when I do this. Just my $0.02. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@torfree.net for latest Toronto Free-Net information Click me! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 00:11:22 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: sd7-9.. end of thread. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Look, before this turns into some nasty off_t discussion, I would like to point out some things. * - Don't like it? Compile your own kernel. * - Don't like it? Compile your own kernel. I need a way that makes 1st time installation easy. If you already have it running, then you can get the source and compile your own kernel any way you want. We need to concentrate on remaining with the views and directions of the main tree of NetBSD (this obviously caused a problem earlier with doing this type of thing). Also, bitching Chris out about these types of decisions does very little good for his motivation to keep doing this. I suggest that all of us tread lightly, otherwise, we'll lose yet another valuable resource. [soapbox] Finally, let me point out that this is a really trivial complaint... does it make your machine stop working? Green smoke come waifing out? Does booting the kernel format your harddrives by accident? No. So you have to edit an fstab... woooo, that's _hard_. Realize that we are the pioneers.. we already _KNOW_ how to do all of this.. In about a month, this list is going to explode as NetBSD-Amiga proliferates... I don't want 400 messages of "ARGH, I newfs'd my ADOS partitions!". Oops, I'm off on a tangent.. sorry. [rm -r soapbox] -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 00:12:54 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Subject: ps problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is the %CPU and %MEM portion of a ps report working for anyone? When I do this it just shows up as 0.0 for both for every process. This is using -current as of 7/27 with the i386 port. Is this supposed to be like this and I'm just supposed to be using a different command? I didn't really see anything about it in the man page, but maybe I just missed something. Thanks Brian Moore ziff@eecs.umich.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 00:17:07 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 (from Russel Miranda ) (at Wed, 3 Aug 1994 16:46:18 -0400 (EDT)) X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) From: ezy@panix.com (Ezra Story) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I have an external case, unplugging it is SIMPLE. Then it should be equally simple to set the SCSI ID to 6, or hell since you have hard disk space.. recompile the kernel to use fixed id numbers. :-) | Ezra Story | ezy@panix.com | Ezy (IRC) | *********************** | | Penguins! Get yer ice cold penguins here! Free alien monster | | with every purchase! Money back guarantee! | +++++++++++++++++++ | From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 00:18:32 1994 From: jfw@ksr.com (John F. Woods) To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 2.1.1 source available? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a pre-digested copy of the XFree86 2.1.1 source tree available for FTP in the US anywhere? I'd rather not occupy a transoceanic link when a relatively local one will do... From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 00:44:56 1994 From: Marc@xfree86.org To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 2.1.1 source available? <9408031835.AA15731@kaos.ksr.com> X-Mailer: exmh version 1.4.1 7/21/94 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Is there a pre-digested copy of the XFree86 2.1.1 source tree available for > FTP in the US anywhere? I'd rather not occupy a transoceanic link when > a relatively local one will do... The official source tree can be located at: ftp://ftp.XFree86.Org/ There are also numerous binaries. A number of mirror sites (such as tsx11.mit.edu and xfree86.cdrom.com) also carry the binary kits. - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 00:45:13 1994 To: gooderum@SCTC.COM Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408031927.AA12898@SCTC.COM> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Does anyone know of a source that still has these, or can any one point >me at "current" cards being manufactured that are 1742 comatible? When my wife and I got a new machine back in April, we tried very hard to find one of these; no go. Everyone said "nope, sorry, try the 2742". I don't think there are any cards that are 1742 compatible (but hey, if someone knows different, please let us know!) --Ken PS - We ended up getting a BusLogic 742; very happy with it. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 01:00:02 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Ken Hornstein Cc: gooderum@SCTC.COM, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408032106.AA18798@entropic.com> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >Does anyone know of a source that still has these, or can any one point > >me at "current" cards being manufactured that are 1742 comatible? > > When my wife and I got a new machine back in April, we tried very hard to find > one of these; no go. Everyone said "nope, sorry, try the 2742". I don't think > there are any cards that are 1742 compatible (but hey, if someone knows > different, please let us know!) > > --Ken > > PS - We ended up getting a BusLogic 742; very happy with it. You can supposedly get the cards from dec, who sells them for use with their Alpha EISA box. No idea what their markup is..... later, Adam Glass From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 01:02:27 1994 From: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Subject: Re: My $0.02 (floptical) To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1478 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I have an Insite floptical. If I boot NetBSD without a disk in the > floptical drive, then he kernel will not even recognize the device. > This is not right. I have a floptical mounted in my NetBSD/i386 box (next to my NetBSD/amiga) and it always recognizes the floptical and assigns it the next available id (1 for me). I get a couple of errors during boot that it cannot find the size of sd1 (the floptical) but It is still recognized and available. I may try to take the floptical out and put it on my amiga tonight to check this. (i am running -current about 072994 on the amiga) > > At the moment, the floptical is sd2, and my hard drives are sd5 and sd6. > Under the new assignment scheme, I must either always boot with a floppy > inserted, or never do. Since I use the floptical for file transfer, > I will always have to have a disk in there. > Are you able to write to the floptical? I have one of the nasty versions which reset to read-only. I have a program to change it to read-write on the amiga, and used to have something for my NetBSD/i386 box, but recent (last three months or so) changes to the scsi subsystem make my changes unmergeable. Thus I have not been able to write to the floptical for some time. ------------------------------------------------------------------------ Dale Rahn, Languages and Tools drahn@urbana.mcd.mot.com Motorola, MCG, Urbana Design Center 1101 E. University Ave, Urbana, IL 61801 (217) 384-8585 From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 01:32:28 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> [the following should probably be in some sort of FAQ, so people >> don't have to go to the 'source', as i did.] >> How To Concatenate Disks >> --- -- ----------- ----- > No, it should be a man page. Preferably, but I'd take a doc file over nothing. However, I'm curious. What's machine-dependent about this sort of disk trickery? More specifically, why is the ccd stuff everyone is talking about in the hp300 port, rather than over in some machine-independent part of the kernel? I can't see anything conceptually difficult about a disk driver that just parcels out I/O requests to other drivers (set via ioctls, perhaps), and while it may not be easy, I don't see any reason why a machine-specific version of it would be any easier. (I tried to do something very similar once under pre-Reno 4.3, and never got it to work reliably.) Ideally, I'd like to see a disk driver that turns around and reflects I/O requests back to a user process, which can stripe or interleave or whatever else it feels like. (Efficient? Who said anything about it being efficient? I suspect it would be at least usably fast....) I'd even write it myself, but if the concatenated disk driver is machine-dependent, there is clearly magic I don't understand going on somewhere. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 02:17:45 1994 To: Ken Hornstein Cc: gooderum@SCTC.COM, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408032106.AA18798@entropic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3837.775954157.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >Does anyone know of a source that still has these, or can any one point > >me at "current" cards being manufactured that are 1742 comatible? > > When my wife and I got a new machine back in April, we tried very hard to find > one of these; no go. Everyone said "nope, sorry, try the 2742". I don't think > there are any cards that are 1742 compatible (but hey, if someone knows > different, please let us know!) You could try asking DEC; they are selling them for their EISA Alpha machines, as far as I've heard. Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 02:22:52 1994 From: "Charles M. Hannum" To: current-users@sun-lamp.cs.berkeley.edu Subject: Cyrix 486DLC lossage Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've just removed most of this code by default. I've been told that many Cyrix-based machines have broken cache logic and need either explicit cache invalidations or complete disabling of the cache. The former should probably be done, but the latter just doesn't seem reasonable as a default for everyone. So, I've implemented the following compromise: 1) The bit which disables caching of the ISA `hole' area is always set. 2) If caching doesn't work correctly on your machine, you can turn it off using the BIOS setup utility that came with your machine. I'm not going to try to intuit what the right thing is from the limited view I have from the inside of your CPU. 3) Eventually the explicit cache invalidations should be added anyway, but I'm not going to do it today. (Feel free to volunteer!) Anyway, if you've had trouble with a DLC-based machine, you should probably try the updated code after tonight's SUP. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 02:23:15 1994 From: "Alan Bair" "Re: My $0.02 (floptical)" (Aug 3, 5:25pm) X-Mailer: Z-Mail (3.0.0 15dec93) To: drahn@pacific.urbana.mcd.mot.com (Dale Rahn), dej@eecg.toronto.edu (David Jones) Subject: Re: My $0.02 (floptical) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 3, 5:25pm, Dale Rahn wrote: > Subject: Re: My $0.02 (floptical) > > > > I have an Insite floptical. If I boot NetBSD without a disk in the > > floptical drive, then he kernel will not even recognize the device. > > > > This is not right. I have a floptical mounted in my NetBSD/i386 box > (next to my NetBSD/amiga) and it always recognizes the floptical > and assigns it the next available id (1 for me). > I get a couple of errors during boot that it cannot find the size > of sd1 (the floptical) but It is still recognized and available. > I may try to take the floptical out and put it on my amiga tonight to > check this. (i am running -current about 072994 on the amiga) I have a SyQuest connected to my Amiga and if there is no disk inserted, it will recognize it, but as Dale says, it cannot find the size information. So it puts out a message and sets some default values. I have not tried to then insert a cartridge, being afraid it could damage the data with the strange size values it set. > > ------------------------------------------------------------------------ > Dale Rahn, Languages and Tools drahn@urbana.mcd.mot.com > Motorola, MCG, Urbana Design Center > 1101 E. University Ave, Urbana, IL 61801 (217) 384-8585 >-- End of excerpt from Dale Rahn -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 PH (512) 891-2336 abair@amcu-tx.sps.mot.com FAX (512) 891-3348 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 03:03:27 1994 From: "Stephen J. Roznowski" To: c9020@rrzc1.rz.uni-regensburg.de, rhealey@kas.helios.mn.org Subject: Re: sd7-9 Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: rhealey@kas.helios.mn.org (Rob Healey) > > > On Aug 2, 11:42pm, Stephen J. Roznowski wrote: > > > What is the point of having the devices /dev/sd7-9? > > > > > > It appears that nothing in the kernel will be assigned > > > to these addresses. Should MAKEDEV be fixed? > > > > I guess these are the left-overs aftern Chris invented this (IMHO not so > > useful) new SCSI-encoding (sd0: first drive, ...). sd7-9 were used for > > IDE-drives before, if I got that right. > > > How about multiple disk controllers with lot's of drives? I realise > most of us don't have > 2 disks and most aren't > 1G but we should > think about future expansion... Gotta learn to not post so late at night... :-) Okay, now I have another complaint. :-) Why only 10 devices and not 16 being created by default? I'd like to see /dev/MAKEDEV updated to make all 16 when "std" is done, please. -SR From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 03:12:42 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Jason Thorpe Cc: der Mouse , current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks <9408032331.AA07572@research.CS.ORST.EDU> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > i386...Should have it done tonight...at which time I will send the > necessary patches to the 'keeper of the tree'. the "keeper of the tree" is 'core@sun-lamp.cs.berkeley.edu' From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 03:15:36 1994 To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: how to concatenate disks From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Wed, 3 Aug 1994 15:32:39 -0400 der Mouse wrote: > Preferably, but I'd take a doc file over nothing. I just wrote a man page and shipped it off to Charles... > However, I'm curious. What's machine-dependent about this sort of disk > trickery? More specifically, why is the ccd stuff everyone is talking > about in the hp300 port, rather than over in some machine-independent > part of the kernel? I can't see anything conceptually difficult about > a disk driver that just parcels out I/O requests to other drivers (set > via ioctls, perhaps), and while it may not be easy, I don't see any > reason why a machine-specific version of it would be any easier. (I > tried to do something very similar once under pre-Reno 4.3, and never > got it to work reliably.) Well, the ccd stuff is actually in a machine independant portion of the kernel tree, however, it relies *heavily* on config understanding pseudo-devices with components. I'm currently working on ccd for the i386...Should have it done tonight...at which time I will send the necessary patches to the 'keeper of the tree'. >From what I can gather from conversation and code, config.new does not grok pseudo-devices with components, so... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 04:37:27 1994 To: gooderum@SCTC.COM (Mark Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu From: "Louis A. Mamakos" Subject: Re: Adaptec 1742 <9408031927.AA12898@SCTC.COM> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does anyone know of a source that still has these, or can any one point > me at "current" cards being manufactured that are 1742 comatible? > You can still get Adaptec 1740 cards from DEC. They sell them for their Alpha box which has an EISA bus inside. louie From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 04:38:14 1994 From: chopps@emunix.emich.edu To: David Jones Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: My $0.02 <94Aug3.170609edt.19212@picton.eecg.toronto.edu> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu You should be advised: slow devices at high scsi id's fast ones at low scsi id's. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 04:46:44 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: gooderum@sctc.com (Mark Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408031927.AA12898@SCTC.COM> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Does anyone know of a source that still has these, or can any one point >me at "current" cards being manufactured that are 1742 comatible? Buy a BusLogic bt747s. Mine works great. Don't support Adaptec even if you do find a 1742 (that's my policy, anyway). --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-netbsd-users@sun-lamp.cs.berkeley.edu Thu Aug 4 04:46:46 1994 From: Dave Huang To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: NetBSD on a notebook? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I don't currently have an Intel machine, but am thinking of getting a little 486 notebook to keep me from getting bored while out of town :) I'm probably gonna have to run DOS and Windoze on it, but I'd like to run Unix on it too if it'd work well. So... what I'm wondering is will NetBSD run on a notebook? (I'm looking at the Winbook XP, 486DX4-75, 16MB RAM, 340, maybe 520MB hard disk, dual scan color display) I can't think of any reason why it wouldn't, but will I be able to use the internal faxmodem or PCMCIA Ethernet cards? Also, I suppose this is more of an XFree86 question than NetBSD question, but will I be able to run X and use the little ThinkPad-style mini-joystick-ish pointing device? (I can get a built-in trackball instead if it makes a difference) The ads say it uses the Western Digital Rocketchip graphics accelerator. Thanks in advance! I hope I'm not stuck with just MSDOS :) If I can't run Unix, maybe I can run OS/2 or something... :) -- Name: Dave Huang | Mammal, mammal / their names are called / INet: khym@bga.com | they raise a paw / the bat, the cat / ICBM: 30d 27' 36"N 97d 59' 17"W | dolphin and dog / koala bear and hog -- TMBG From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 4 04:54:18 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: netbsd-1.0b Sender: owner-amiga@sun-lamp.cs.berkeley.edu i've installed the release 1.0b (from uni-regensburg.de) on one of my disks(sd5). When i tried to rebeoot from that partition the system locks-up just after 10 views configured, it boots ok from the floppy and i can acces my disks but it locks-up when i tried to reboot from the hard-disk......any ideas???? Bye Michel beausejour mbeausej@qc.bell.ca From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:02:33 1994 To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <199408040059.TAA29078@MindBender.HeadCandy.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >k >>there are any cards that are 1742 compatible (but hey, if someone knows >>different, please let us know!) > >>PS - We ended up getting a BusLogic 742; very happy with it. > >Um... what do you think the bt742a and bt747s are? ;-) I didn't think they were Adaptec 1742 compatible; that's why they have a different driver, right? Or do you mean something else? From owner-netbsd-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:07:53 1994 From: mycroft@gnu.ai.mit.edu To: khym@bga.com, netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD on a notebook? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu One more thing... but will I be able to run X and use the little ThinkPad-style mini-joystick-ish pointing device? My recollection is that it simulates a PS/2 mouse, and so ought to work with the `pms' driver. As far as graphics, I've no idea whether or not X will run on it. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:09:29 1994 From: mycroft@gnu.ai.mit.edu To: khym@bga.com, netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD on a notebook? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu what I'm wondering is will NetBSD run on a notebook? Yes. but will I be able to use the internal faxmodem [...] Is it compatible with anything else? I'd guess it probably uses a standard UART (or clone thereof, anyway) to talk to the CPU, and so it ought to work fine. PCMCIA Ethernet cards? That depends on what card, exactly. There are two PCMCIA ethernet drivers floating around, one of which is part of a more general set of PCMCIA configuration code, and one of which is very specifically a port of the if_ed driver (which at some point should be redone using the generic code). Stefan Grefen is responsible for the PCMCIA code. I forget where to get it offhand; send him mail (grefen@hydra.convex.com) and I'm sure he can be of more assistance. (Sooner or later I'll work on putting it into our tree, but I have a lot of other things on my list too...) From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:21:57 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 2.1.1 source available? <9408031835.AA15731@kaos.ksr.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Is there a pre-digested copy of the XFree86 2.1.1 source tree available for >FTP in the US anywhere? I'd rather not occupy a transoceanic link when >a relatively local one will do... I have the most recent version of the shared stuff on ftp.iastate.edu in /pub/netbsd/XFree86-2.1.1/. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:23:28 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: "Charles M. Hannum" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Cyrix 486DLC lossage <199408032235.SAA27535@duality.gnu.ai.mit.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Incidentally, I contributed most of the Cyrix-specific logic in locore.s and machdep.c, that Theo retuned and put into the tree. So, I'll comment on my viewpoint. >So, I've implemented the following compromise: > >1) The bit which disables caching of the ISA `hole' area is always >set. This is probably good for all machines. However, for non DLC-specific motherboards, we should probably be using the mode where it flushes the cache on each bus hold. We should be moving #0x22 into CCR0 instead of the #0x02 that is default. (Look where it's commented out in locore.s). For people who have DLC-specific motherboards that actually have hardware cache support, it would be nice if there were a kernel option that would simply tell the Cyrix setup code to not touch the caching stuff (just DLC detection), so what they do in their BIOS will stick as NetBSD boots. I don't see why nobody wants to make this a config-time option. There is absolutely no way to detect whether a motherboard is DLC hardware specific -- it must be supplied by the user. I envision something like #DLC_BIOS or #DLC_PARANOID to enable either a) don't touch the cache settings, or b) enable the cache in paranoid mode where it flushes on every bus hold and locks out the 640K-1M region (for use on 386 motherboards without DLC hardware caching support). >2) If caching doesn't work correctly on your machine, you can turn it >off using the BIOS setup utility that came with your machine. I'm not >going to try to intuit what the right thing is from the limited view I >have from the inside of your CPU. You can't if we set it a certain way inside locore.s on every boot. That's why I'm in favor of a config option. (Although, at present, if you don't #define notyet_cyrix, you don't get any DLC caching at all.) >3) Eventually the explicit cache invalidations should be added anyway, >but I'm not going to do it today. (Feel free to volunteer!) I started to do it, and had dma.c and bt742a.c cache-safe (since that's the only DMA hardware I have). I'm not so sure it's such a good idea, unless you can be sure *everyone* who writes a DMA driver knows to put cache invalidations in the right places. I'd volunteer to finish the work if I wasn't working 60 hours a week. --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:23:50 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Ken Hornstein Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408040135.AA23423@entropic.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>there are any cards that are 1742 compatible (but hey, if someone knows >>>different, please let us know!) >>>PS - We ended up getting a BusLogic 742; very happy with it. >> >>Um... what do you think the bt742a and bt747s are? ;-) >I didn't think they were Adaptec 1742 compatible; that's why they have a >different driver, right? Or do you mean something else? OK, point well taken. I believe they started out as 1742 compatible (correct me if I'm wrong) but diverged. However, I believe they still will work with drivers that don't use every extended option of their command language. Also, they are pretty much functionally equivelant, and almost identical to the driver (very small differences). And, the point is moot on NetBSD anway, since they both work equally well with the O/S. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:35:38 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Ken Hornstein Cc: gooderum@SCTC.COM, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 <9408032106.AA18798@entropic.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>Does anyone know of a source that still has these, or can any one point >>me at "current" cards being manufactured that are 1742 comatible? >When my wife and I got a new machine back in April, we tried very hard to find >one of these; no go. Everyone said "nope, sorry, try the 2742". I don't thin k >there are any cards that are 1742 compatible (but hey, if someone knows >different, please let us know!) >PS - We ended up getting a BusLogic 742; very happy with it. Um... what do you think the bt742a and bt747s are? ;-) ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 05:47:55 1994 To: Duncan McEwan Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) <199408030800.UAA15750@bats.comp.vuw.ac.nz> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > If you do a "cu -l /dev/tty01" where tty01 has had the COM_SW_CLOCAL bit set > > by ttyflags, the open succeeds. But when you try to type anything you get > > > > cu: write: input/output error > I still have exactly the same problem as before with this newer version of > current. Perhaps mgetty is doing something to the state of the line to cause > "cu" to not get the error. I'm not sure if the 1.05 version of "cu" fixes > this problem. I also have this same problem with or without 'local' set in my /etc/ttys. This is running 1.05 or 1.04. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 06:20:23 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Adaptec 1742 From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu My take on this whole thing is: why support a company who actively discourages using their products on your favorite OS? I certainly don't want to send them *my* money. I see no good reason to go to great lenghts to buy something from a company who doesn't want me running their product anyway. Especially when there are cards just as good, if not better, for similar money (possibly even less, though I'm not sure what happend to the price of the 1742 since it vanished). BusLogic makes some great SCSI controllers, is genuinely helpful and supportive, and they don't charge as much. If you want to get an EISA SCSI controller, I'd definitely recommend a bt747s, which is pretty much equivelant to a 1742. If you're strapped for cash, a bt742a should do ok, as well. If you want absolute speed, the bt757 (wide) is your ticket. Why do I sound like a commercial? I don't really care what you buy -- it's your business. But every time I see someone throwing more money at Adaptec, even though they actively supress the use of their controllers on free unix, I have to cringe a little. Your money talks, both ways. But, I guess I'm just too much of an idealist sometimes. --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 06:40:18 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: bug in routed; adds incorrect netmasks Sender: owner-current-users@sun-lamp.cs.berkeley.edu I believe there is a bug in routed. It seems to add routes with very odd (and incorrect) netmasks. It looks like a "cut and paste" error. (I found this trying to get gated to work - gated dumped core on the non-contig netmasks) Try running "netstat -rAn" on your machine to see what I mean. Here's the fix: *** inet.c.orig Wed Aug 3 23:06:27 1994 --- inet.c Wed Aug 3 23:06:33 1994 *************** *** 144,152 **** } else if (IN_CLASSA(i)) { mask = IN_CLASSA_NET; } else if (IN_CLASSB(i)) { ! mask = i & IN_CLASSB_NET; } else ! mask = i & IN_CLASSC_NET; /* * Check whether network is a subnet; --- 144,152 ---- } else if (IN_CLASSA(i)) { mask = IN_CLASSA_NET; } else if (IN_CLASSB(i)) { ! mask = IN_CLASSB_NET; } else ! mask = IN_CLASSC_NET; /* * Check whether network is a subnet; -brad From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 06:43:55 1994 From: "John F. Woods" To: current-users@sun-lamp.cs.berkeley.edu Subject: sort is broken + fix Sender: owner-current-users@sun-lamp.cs.berkeley.edu sort doesn't work for multiple files if one of the files is stdin (-). I've just submitted a PR for this, including the following fix: *** sort.c.orig Wed Aug 3 23:02:40 1994 --- sort.c Wed Aug 3 23:02:42 1994 *************** *** 1487,1496 **** if (*s) badfieldspec (argv[i]); } ! else if (argv[i][0] == '-') { - if (!strcmp ("-", argv[i])) - break; s = argv[i] + 1; if (digits[UCHAR (*s)]) { --- 1487,1494 ---- if (*s) badfieldspec (argv[i]); } ! else if (argv[i][0] == '-' && argv[i][1]) { s = argv[i] + 1; if (digits[UCHAR (*s)]) { From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 15:18:38 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/etc/etc.hp300/MAKEDEV U src/share/man/man4/Makefile U src/share/man/man4/ccd.4 U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/include/specialreg.h U src/sys/scsi/cd.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Aug 4 04:25:39 1994 SUP Scan for current completed at Thu Aug 4 04:29:42 1994 SUP Scan for mirror starting at Thu Aug 4 04:29:43 1994 SUP Scan for mirror completed at Thu Aug 4 04:33:28 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 17:56:00 1994 From: jfw@ksr.com (John F. Woods) To: current-users@sun-lamp.cs.berkeley.edu Subject: X troubles Sender: owner-current-users@sun-lamp.cs.berkeley.edu Now that I have XFree86 2.1.1 on my newly-updated 1.0B system (Aug 1 tars from ftp.iastate.edu), I can't get X to work. The X server exits immediately; some fooling around with SuperProbe revealed that it is exiting when it calls ``ioctl(CONS_fd, X_CONSOLE_MODE_ON, ...)''. I have 'options USERVER,XCONSOLE' in my kernel config, is there something else that I'm missing? Why does ioctl hate me? :-) From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 18:54:37 1994 From: matthieu@laas.fr (Matthieu Herrb) To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: X troubles X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 617 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Thu 4) > Now that I have XFree86 2.1.1 on my newly-updated 1.0B system (Aug 1 tars > from ftp.iastate.edu), I can't get X to work. The X server exits immediately; > some fooling around with SuperProbe revealed that it is exiting when it calls > ``ioctl(CONS_fd, X_CONSOLE_MODE_ON, ...)''. I have 'options USERVER,XCONSOLE' > in my kernel config, is there something else that I'm missing? Why does > ioctl hate me? :-) start X with stdout and stderr redirected to a file (eg ``xinit >& xinit.log'') and look at the result. The answer is probably obvious. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 18:57:23 1994 To: Mark_Weaver@brown.edu Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: GENERICBT won't boot on my system <199408030928.FAA00307@localhost> From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199408030928.FAA00307@localhost>, Mark_Weaver@brown.edu writes: >I bet it has something to do with my ATI GUP, which has ports all over >the place. I remember someone a while back complaining about com3 >being put in the kernel, because it prevented it from booting. That's >because the com3 addresses conflict with the GUP. The GUP uses 0x2e0 - 0x2ef. com3 plops somewhere in the middle there. It also doesn't prevent you from booting up, just blanks the screen :-) Just about any further activity on com3 will wake it up. (for example, having a /dev/tty03 entry in /etc/ttys and executing ttyflags, or even sometimes just echoing or cat'ing random things to it, in case you ever get bitten by it) -wps From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 18:58:27 1994 To: Matthieu.Herrb@laas.fr Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: X troubles <9408041448.AA04465@elwood.laas.fr> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Now that I have XFree86 2.1.1 on my newly-updated 1.0B system (Aug 1 tars > > from ftp.iastate.edu), I can't get X to work. The X server exits immediately; > > some fooling around with SuperProbe revealed that it is exiting when it calls > > ``ioctl(CONS_fd, X_CONSOLE_MODE_ON, ...)''. I have 'options USERVER,XCONSOLE' > > in my kernel config, is there something else that I'm missing? Why does > > ioctl hate me? :-) > start X with stdout and stderr redirected to a file > (eg ``xinit >& xinit.log'') and look at the result. The answer is > probably obvious. The screen never blanks, so I get to see all the messages, and none of them seemed obvious: (***) The usual stuff, then: X I/O: fatal I/O error 32 (broken pipe) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining The connection was probably broken by a server shutdown or KillClient. To make what I said first more clear, SuperProbe is exiting (with status 0) when it calls ioctl(CONS_fd, X_CONSOLE_MODE_ON, ...), and I assume the X server itself is doing so, too. I have printf()s in SuperProbe before and after the ioctl(), and the ones after the ioctl() don't print. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 19:12:57 1994 To: gillham@andrews.edu (Andrew Gillham) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: /kernfs mounts <9408032021.AA13401@edmund> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I don't know if this is a bug, or a feature... but if I do a > mount -a more than once, /kernfs gets mounted again each time. yup. > (ok, mount reports it's mounted, may not really be mounted again) > Everything still works, but if I do a 'mount' it's irritating to > see the multiple listings... :-) no, it's definitely being mounted each time you say mount -a. The mount man page doesn't say: -a All the filesystems described in fstab(5) are mounted. Excep- tions are those marked as ``noauto'' or are excluded by the -t flag (see below). though it should... (that's a quote from the 4.4BSD-Lite man page.) the only reason that it doesn't remount things like /usr, is because it gets "Device Busy" on the block partitions of the disk, since they're already in use. Arguably, this is a bug, but it's one of those things that does conform to what should be the documentation. 8-) chris From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 4 19:33:37 1994 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.487:04.07.94.16.27.41] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: forwarded... From: "hamish (h.i.) macdonald" To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: forwarded message from Jukka Forsgren Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Tue Aug 2 18:24:00 1994, >>>>> cherry wrote: cherry> For the record, I have tried this, and I still get lockups. cherry> No changes. Sorry. :) I'd just like to point out that the mechanism NetBSD uses in the A2091 and A3000 DMA drivers (just do DMA as long as transfers are requested) can give big problems if that final bytes of a chunk of memory are read from. In a SCSI write, the DMA chip reads memory, and will continue to read memory until the SCSI FIFO is full. If you write 1K starting at (end-of-chunk-1K), then the DMA controller will attempt to read past (end-of-chunk) in order to fill the FIFO (since the DMA controller was just told to write to the SCSI chip, not told to write 1K). When this happens, you end up with a total lockup, since the resulting bus-error cannot be reported to the DMA controller, only to the CPU. The same problem occurred with Linux/68k for the Amiga, and was fixed by detecting end-of-chunk DMA requests, and using a bounce buffer in those cases. You might want to figure out if this could be the case. When NetBSD only supported one chunk, it was pretty much impossible, since the final page of that chunk was reserved for the kernel message buffer. Perhaps this is happening now. There is multiple memory chunk support in NetBSD now, isn't there? Regards, Hamish. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 4 19:42:27 1994 From: jshardlo@london.micrognosis.com (John Shardlow) Subject: Missing Columns episode 12768 - possible solution ? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2242 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Folks, Here is a possible clue as to why I have every fourth column missing on my console in NetBSD: comp.unix.amiga : >From miclon!uknet!EU.net!sunic!news.uni-c.dk!iesd.auc.dk!news Thu Aug 4 17:35:31 1994 Article: 7474 of comp.unix.amiga Path: miclon!uknet!EU.net!sunic!news.uni-c.dk!iesd.auc.dk!news From: jdso93@kom.auc.dk (jes degn soerensen) Newsgroups: comp.unix.amiga Subject: Re: Linux 0.9 pl 1 Date: 4 Aug 1994 10:39:04 GMT Organization: Aalborg University - Dep. of Communication Technology Lines: 36 Distribution: world Message-ID: <31qgg8$a3j@news.iesd.auc.dk> References: <31lpd6$8mq@redwood.cs.scarolina.edu> Reply-To: jdso93@kom.auc.dk NNTP-Posting-Host: aleko.kom.auc.dk In article 8mq@redwood.cs.scarolina.edu, uytterho@math.scarolina.edu (Geert Uytterhoeven) writes: >jshardlo@london.micrognosis.com (John Shardlow) writes: >> The reason I tried Linux was that I had an annoying problem >> with NetBSD which affected the console. Basically every fourth >> column of characters was missing. I thought that this must be >> a bug in the console code but none of the other NetBSD'ers >> seemed to suffer from it. >> >> To cut a long story short, Linux also suffers from the exact same >> problem on my A3000. >> >> Two questions: >> >> 1) Is it possible to make Linux run the console on the serial >> port ? (I have a VT 220 on the serial port) > >There still is no serial driver, I think. > >> 2) Has any Linux user seen this problem and know of a cure for it ? > >Which video mode are you using? Try some other mode. > >While I was implementing the new AGA modes, I got about the same problem (it >had something to do with Chip memory alignment) and I tuned everything 'till >it worked fine on my A4000. Sounds the like the 'problem' with the AGA chipset, when running burstmode on the bitplanes. Then the bitplanes has to be double longword alligned. Jes --- Jes Sorensen: jdso93@kom.auc.dk | If programming was ment to be fun, jes@leech.adsp.sub.org | why did they come up with Intel? This CHIP mem allignment sounds like it could be the problem. Any one else using burst-mode RAM ? How can I force allignment ? Please help !! I FEEL LIKE I MIGHT BE CLOSE TO SOLVING IT !!!! :) John From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 19:53:18 1994 X-Authentication-Warning: zappa.unna.Ping.DE: Host localhost.Ruhr.DE didn't use HELO protocol To: gooderum@SCTC.COM (Mark Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Re: Adaptec 1742 <9408031927.AA12898@SCTC.COM> Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <9408031927.AA12898@SCTC.COM>you write: ->Does anyone know of a source that still has these, or can any one point ->me at "current" cards being manufactured that are 1742 comatible? I just thought "why don't you try a BusTek?" On the other hand, over here in germany i do have a source for 1742 Cards, they cost ~750 DM +pp. Gruesse Oskar ============================================================================== Jan-Hinrich Fessel , Systemverwaltung Quantum Gesellschaft fuer Software mbH, D-4600 Dortmund, Germany Jan-Hinrich.Fessel@quantum.de oskar@zappa.unna.ping.de ============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 19:58:30 1994 From: Joe Ammond Subject: Has anyone compiled (or bothered to try) SUP on HP/UX? To: current-users@sun-lamp.cs.berkeley.edu X-Phone: (404) 894-7346 X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 322 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I know this is off the NetBSD topic, but has anyone successfully compiled sup for HP/UX? My NetBSD box is currently not on the 'net, and I'd like to keep current, but my local machine here is an HP. Any help would be appreciated. ja. -- Joe Ammond ammond@ee.gatech.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 20:34:37 1994 From: Philippe BRAND Subject: Re: sd7-9.. end of thread. To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 857 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu William J Coldwell writes: [stuff about new scsi id mapping deleted] > Finally, let me point out that this is a really trivial complaint... Well I guess not, at leat for my case. For sure I could compile my own kernel but I don't think it'll be pretty nice to say to newcomers: "just recompile it man!". For people with fancy configurations, like me, that's quite embarassing: SCSI#0 540 Quantum -> usr. SCSI#1 CD-Rom, which I give sometimes to my brother. SCSI#2 330 Micropolis SCSI#3 310 Micropolis SCSI#4 A3070 CP150 tape drive, which I give sometimes to my brother. SCSI#5 Apple CD-300 SCSI#6 Internal 230 Quantum -> root, swap, shared with Gigamem. See what I mean ? Anytime I give my CD or/and my tape, I'll have to change fstab *before* booting NetBSD. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 20:38:07 1994 From: Danny Lepage Subject: What is best, PPP or Slip? To: current-users@sun-lamp.cs.berkeley.edu (current-users mailing list) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 715 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm currently using slip (14400 bps), and I'm looking to improved transfer performance. So, what is best, PPP or Slip ? Is there a way to use CSLIP with NetBSD ? (The man pages for ifconfig mention something about an option for using Compressed Headers, is this CSLIP? If so, somebody figured out what the syntax is ?) Also, is it possible to set MTU with slip ? If so, how ? (If I remember right, MTU seems to be set ~256, but my provider suggest a MTU setting of 1500. If I managed to set it to 1500, will I have better networking performance ?) Sorry if this is a FAQ, I've not been able to find anything to answer these questions. Thanks in advance. Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 4 21:00:53 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: sd7-9.. end of thread. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199408041750.TAA04407@colombo.telesys-innov.fr> Philippe BRAND writes: > > Well I guess not, at leat for my case. For sure I could compile > my own kernel but I don't think it'll be pretty nice to say to > newcomers: "just recompile it man!". EVERYONE should be compiling their own kernel. The generic kernel is far from optimal for anyone, it is only meant to be used as an installation tool. How many people have a dozen different brands of SCSI controller and two different brands of ethernet adaptors in their machines? Nobody. Everyone should be building their own kernel with only the features they need. You'll get better performance that way (kernel will be smaller, so more memory free, so less swapping/paging). The people who designed the BSD config scheme went to a lot of trouble to make it easy for everyone to build their own kernel. Take advantage of it! -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 22:07:22 1994 From: Scott Reynolds Subject: Re: Has anyone compiled (or bothered to try) SUP on HP/UX? To: Joe Ammond Cc: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 4 Aug 1994, Joe Ammond wrote: > I know this is off the NetBSD topic, but has anyone successfully compiled > sup for HP/UX? My NetBSD box is currently not on the 'net, and I'd like to > keep current, but my local machine here is an HP. I have, but I should note that I found the source at CMU to get it running. Since it doesn't look like I saved a copy of the original sources, I'll have to dig them up in order to generate a diff... --scott From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 22:16:39 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Danny Lepage Cc: current-users@sun-lamp.cs.berkeley.edu (current-users mailing list), explorer@vorpal.com Subject: Re: What is best, PPP or Slip? <199408041701.AA12820@M3iSystems.QC.CA> From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Is there a way to use CSLIP with NetBSD ? (The man pages for ifconfig >mention something about an option for using Compressed Headers, >is this CSLIP? If so, somebody figured out what the syntax is ?) For the NetBSD end, ifconfig sl0 link0 will turn on header compression. Also set is link2 (by default I believe) which means if it RECEIVES a compressed header, it starts sending them as well. It's kinda in a ``wait and see'' mode. >Also, is it possible to set MTU with slip ? If so, how ? >(If I remember right, MTU seems to be set ~256, but my provider >suggest a MTU setting of 1500. If I managed to set it to 1500, will >I have better networking performance ?) You may get better overall speed unless you don't care about interactive traffic and you never loose a packet. Assuming no compression and perfect transfer rates, you'll get 1440 char/sec. That means a 1500-packet would be over a second to send. So, if 10 of those are queued up before your small interactive-typing ones, you may wait a while. --Michael -- Michael Graff 1304 Florida #3 (515) 296-2735 Ames, IA 50014 PGP key on a server near YOU! From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 22:37:50 1994 From: Scott Reynolds Subject: Re: Has anyone compiled (or bothered to try) SUP on HP/UX? To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu If anyone wants a diff for HP-UX v9.x from the sup sources (available from CMU as ftp://ftp.cs.cmu.edu/projects/mach/sup/sup.tar.Z), drop me a line. Scott Reynolds Assistant System Administrator Technology Group, Inc. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 22:53:47 1994 From: Scott Reynolds Subject: Re: What is best, PPP or Slip? To: Danny Lepage Cc: current-users mailing list Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 4 Aug 1994, Danny Lepage wrote: > I'm currently using slip (14400 bps), and I'm looking to improved > transfer performance. So, what is best, PPP or Slip ? My personal opinion is that PPP with VJ header compression is superior to CSLIP; either one is significantly better than SLIP. > Also, is it possible to set MTU with slip ? If so, how ? No; that's hard coded into the kernel. [/sys/net/if_sl.c] > (If I remember right, MTU seems to be set ~256, but my provider > suggest a MTU setting of 1500. If I managed to set it to 1500, will > I have better networking performance ?) If the line is "clean", I would expect there to be no significant advantage in using a smaller MTU. However, it doesn't really impact the efficiency of the connection all that much with header compression enabled, so it's not a significant disadvantage, either. As to turning on compression in the NetBSD SLIP code, I won't even guess, since I've never used it. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 23:26:54 1994 From: Joe Ammond Subject: SUMMARY: Has anyone compiled (or bothered to try) SUP on HP/UX? To: current-users@sun-lamp.cs.berkeley.edu X-Phone: (404) 894-7346 X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 359 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Kudos to the 'net for quick response! (Now if only the vendors were listening) John Brezak and Scott Reynolds both responsed with knowledge of patches, and Scott was helpfull enough to send me a copy of his patches. I now have sup working under HP/UX thanks to them ja. -- Joe Ammond, Geek ammond@ee.gatech.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 4 23:36:53 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Danny Lepage Cc: current-users@sun-lamp.cs.berkeley.edu (current-users mailing list) Subject: Re: What is best, PPP or Slip? <199408041701.AA12820@M3iSystems.QC.CA> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I'm currently using slip (14400 bps), and I'm looking to improved >transfer performance. So, what is best, PPP or Slip ? Neither is "best". I would think SLIP would be faster, simply because it's less complex. PPP is more robust, since it can route lots of protocols over it, not just IP like SLIP does. But, how many times are you going to need to route AppleTalk or DEC LAT over your serial connection? I run PPP just because I like the flexibility it has with configuration options, and it just seems a little bit more robust (i.e. recovers quicker from corrupt packets, etc.). On the other hand, my co-worker runs SLIP on his connection and seems real happy with that. My experience is that SLIP "feels" slightly more responsive and quicker, simply because it doesn't have to do as much. Only your use will determine what you like best. Why not just try them both? That's what I did. You have both built in to NetBSD, so just give them both a shot and use the one you like best. >Is there a way to use CSLIP with NetBSD ? (The man pages for ifconfig >mention something about an option for using Compressed Headers, >is this CSLIP? If so, somebody figured out what the syntax is ?) If I'm not mistaken, NetBSD-1.0 SLIP *is* CSLIP by default. Correct me if I'm wrong. >Also, is it possible to set MTU with slip ? If so, how ? >(If I remember right, MTU seems to be set ~256, but my provider >suggest a MTU setting of 1500. If I managed to set it to 1500, will >I have better networking performance ?) Ya know, I would have thought ifconfig would be the command to change an MTU, but it's not in there. Dunno what you'd use, if it's even possible. Try sifting through the source -- it may have to be a compiled-in value. >Sorry if this is a FAQ, I've not been able to find anything to >answer these questions. > >Thanks in advance. > >Danny Lepage >poutine@M3iSystems.QC.CA >dlepage@CAM.ORG > ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 00:17:20 1994 From: "Hubert Feyrer" "Re: sd7-9.. end of thread." (Aug 4, 6:19pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I EVERYONE should be compiling their own kernel. The generic kernel is No, this is simply not possible! People often install a basic system which is enough for compiling and running X, but do not have the disk-space or the knowledge to compile their own kernel. I just installed NetBSD on a friend's A3000 which wants to compile some small programs, possibly using X. As he is limited in disk-space, this is surely *no* option form him. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 01:13:43 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: sd7-9.. end of thread. Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9408042336.ZM17416@rrzc1> "Hubert Feyrer" writes: > On Aug 4, 6:19pm, Ty Sarna wrote: > > EVERYONE should be compiling their own kernel. The generic kernel is > > No, this is simply not possible! People often install a basic system which is > enough for compiling and running X, but do not have the disk-space or the > knowledge to compile their own kernel. It doesn't take much knowledge at all to configure and compile a kernel (if you can't figure it out, you're probably not going to be able to figure out many other vital system file formats anyway). It doesn't take much space either. I figured it out, and it's less than 12M, including kernel sources, objects, and the final linked kernel. You can probably even trim it down some from that if you leave out sources for things you won't use. If after installing the netbsd binaries and generic kernel you can't find 12M of free space, at least temporarily, I would question wether you have enough space to do anything useful with NetBSD anyway. I have an especially hard time beleiving that people who are constantly shuffling SCSI devices around can't find the disk space or figure out how to build their own kernel. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 01:33:43 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: SCSI debugging Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm planning on trying to track down why my Viper150 doesn't work under 1.0 beta, but I need some help. I've compiled a new kernel with SCSIDEBUG defined, but I don't see how to turn on the debugging statements.... Help? -SR From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 01:46:46 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: AIC 6360 driver and AHA-1522's Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just modified the `aic6360' driver so that it works on a loaner 1522 that I have. Could I enlist some people with 152[02]'s *and* 6360's (SoundBlaster or otherwise) to test this new version (soon)? Send me some email if you're interested. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 02:00:06 1994 From: "Hubert Feyrer" "Re: sd7-9.. end of thread." (Aug 4, 10:01pm) <9408042336.ZM17416@rrzc1> X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I shuffling SCSI devices around can't find the disk space or figure out > how to build their own kernel. Ouch. :-) For me this is no problem, but I think of the ones that just want to do some simple things. Take the installation I did today, that guy has just about 40MB of free space... enough to do some programming etc. but I'd have a hard time convincing him to give one quarter of his precious disk-space for this. Of course there will be one good thing out of this: It will require to be the kernel-source bundled into the release. ;) Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 02:44:03 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 4.93) Organization: None From: djjames%djamiga@fsd.com (D.J.James) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9.. end of thread. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In on Aug 4, Ty Sarna wrote: > It doesn't take much knowledge at all to configure and compile a kernel > (if you can't figure it out, you're probably not going to be able to > figure out many other vital system file formats anyway). It doesn't You're right abount the amount of knowledge, but I myself have been unable to compile a kernel since the early days. Each and every time I run into one problem or another whether it's include files with errors, undefined symbols in sources or complete compiles that won't link. I've reinstalled systems from `latest' binaries three times, gotten the latest system sources numerous times and each time encountered a different set of problems. I know that people out there are sucessfully compiling kernels, it's just that I can't seem to do it. I can compile the various GNU utilities and most of the BSD binaries so I know that my basic setup is right. I also switch drives around for various reasons, and while it's not hard to edit the fstab to reflect the new changes, often I'm running ADOS and forget to loadup NetBSD to make the change...it's just one more thing to get in the way. There's my $.02 Djj ================================== djjames@fsd.com djjames@cup.portal.com trud1.fsd.com!djamiga.UUCP!djjames ================================== From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 20:44:10 1994 To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: INTEL ETHERNET COMPATIBILITY qQUESTION? <199408050035.RAA00336@catstest-ws-2.ucsc.edu> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have an Intel Express 16 ethernet card for a PCI machine (Gateway, There isn't a driver for this card at this time. Someone has been working on somewhat, but it is a horrible card. Your best bet would be to buy an alternate card; ethernet cards for PC's are cheap. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 20:54:36 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: INTEL ETHERNET COMPATIBILITY qQUESTION? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have an Intel Express 16 ethernet card for a PCI machine (Gateway, some model). We'd like to load netbsd onto the system, but don't know which ethernet driver will work with this card. The documentation that came with the machine was less than helpful when it came to compatibility If anyone has any ideas if they would drop me a line, I would be very appreciative. -thanks listings. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 21:27:36 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: INTEL ETHERNET COMPATIBILITY qQUESTION? <199408050035.RAA00336@catstest-ws-2.ucsc.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have an Intel Express 16 ethernet card for a PCI machine (Gateway, > some model). We'd like to load netbsd onto the system, but don't know > which ethernet driver will work with this card. The documentation that came > with the machine was less than helpful when it came to compatibility > If anyone has any ideas if they would drop me a line, I would be very appreciative. > -thanks > > listings. Nothing is compatible with the EE16. We don't currently have a driver for the EE16. While one is in development, it is not expected to be available soon. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 21:28:36 1994 From: Dave Cornejo Subject: random EFAULTs To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 675 Sender: owner-current-users@sun-lamp.cs.berkeley.edu For the past couple of weeks, I've been getting random core dumps and "bad address" errors. As of right now, I am using Aug 2nd binaries on a kernel built from sources supped this morning. I am using a 486DLC (I noticed that there have been changes to this lately). I see this mostly happening in cpp. I *am* trying to get a better idea of what's going on before I send in a bug report (provided of course, it's not just me). So, is anyone else seeing this? What exactly is a bad address error? Thanks -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 5 21:30:15 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Viper 150 tape problem data Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Here is what I'm getting with full scsi debugging turned on. I'm hopeful that someone will quickly see the problem and prevent me from digging through the tape code. :-) I can provide more/less details if desired. (And I'm off to call for a technical manual for this drive) Thanks, -SR NetBSD 1.0_BETA (A3000) #4: Wed Aug 3 19:32:26 EDT 1994 sjr@istari:/usr/local/src/NetBSD-current/sys/arch/amiga/compile/A3000 Amiga 3000 (m68030 CPU/MMU m68882 FPU) real mem = 16777216 (2048 pages) avail mem = 14852096 (1813 pages) using 115 buffers containing 942080 bytes of memory memory segment 0 at 07000000 size 01000000 memory segment 1 at 00000000 size 00200000 mainbus0 (root) clock0 at mainbus0: system hz 100 hardware hz 715909 ser0 at mainbus0: input fifo 512 output fifo 32 par0 at mainbus0 kbd0 at mainbus0 grfcc0 at mainbus0 grf0 at grfcc0: width 640 height 400 colors 4 ite0 at grf0: rows 50 cols 79 repeat at (30/100)s next at (10/100)s has keyboard fdc0 at mainbus0: dmabuf pa 0x1e30c0 fd0 at fdc0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec ztwobus0 at mainbus0 ahsc0 at mainbus0 scsibus0 at ahsc0 ahsc0 targ 6 lun 0: SCSI2 direct fixed sd6 at scsibus0: 1003MB, 2448 cyl, 12 head, 69 sec, 512 bytes/sec zthreebus0 at mainbus0 found dostype: 0x42534452 which is deprecated using: 0x4e425207 instead found dostype: 0x42534453 which is deprecated using: 0x4e425301 instead found dostype: 0x42534444 which is deprecated using: 0x4e425507 instead found dostype: 0x42534445 which is deprecated using: 0x4e425507 instead found dostype: 0x42534446 which is deprecated using: 0x4e425507 instead 2 mice configured 10 views configured savecore: can't find device 255/251 lpd[70]: restarted init: kernel security level changed from 0 to 1 loading kernel 499236+33288+48160+0 ee_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): density code 0x0, 512-byte blocks, write-protected, st0(ahsc0:4:0): buffered st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x63)sc_link(0x4ebfe0)retr(0x2)timo(0x186a0)cmd(0x4edfdc)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x1 code70 valid0 seg0 key2 ili0 eom0 fmark0 info: 0 0 0 0 followed by 6 extra bytes extra: 0 0 0 0 0 0 st0(ahsc0:4:0): calling private err_handler() st0(ahsc0:4:0): scsi_interpret_sense (no bp) returned 16 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart drive empty ahsc0 targ 6 lun 0: SCSI2 direct fixed sd6 at scsibus0: 1003MB, 2448 cyl, 12 head, 69 sec, 512 bytes/sec zthreebus0 at mainbus0 found dostype: 0x42534452 which is deprecated using: 0x4e425207 instead found dostype: 0x42534453 which is deprecated using: 0x4e425301 instead found dostype: 0x42534444 which is deprecated using: 0x4e425507 instead found dostype: 0x42534445 which is deprecated using: 0x4e425507 instead found dostype: 0x42534446 which is deprecated using: 0x4e425507 instead 2 mice configured 10 views configured savecore: no core dump lpd[70]: restarted init: kernel security level changed from 0 to 1 st0(ahsc0:4:0): open: dev=0x1400 (unit 0 (of 4)) st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x60)sc_link(0x4ebfe0)retr(0x2)timo(0x186a0)cmd(0x4edfdc)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x20)sc_link(0x4ebfe0)retr(0x2)timo(0x186a0)cmd(0x4edfdc)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): mounting st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x20)sc_link(0x4ebfe0)retr(0x4)timo(0x493e0)cmd(0x4edfdc)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 1b,0,0,0,1,0-[0 bytes] st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 1b,0,0,0,1,0-[0 bytes] st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x60)sc_link(0x4ebfe0)retr(0x2)timo(0x186a0)cmd(0x4edfdc)len(0x6)data(0x0)len(0x0)res(0x0)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 0,0,0,0,0,0-[0 bytes] st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x420)sc_link(0x4ebfe0)retr(0x4)timo(0x1388)cmd(0x4edfdc)len(0x6)data(0xfffffd60)len(0x6)res(0x6)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 5,0,0,0,0,0-[6 bytes] ------------------------------ 000: 00 00 00 00 00 00 ------------------------------ st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 5,0,0,0,0,0-[6 bytes] ------------------------------ 000: ff ff fd 70 00 07 ------------------------------ st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): (0 <= blksiz <= 512) st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x420)sc_link(0x4ebfe0)retr(0x4)timo(0x1388)cmd(0x4edfdc)len(0x6)data(0xfffffd42)len(0x18)res(0x18)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 1a,0,0,0,18,0-[24 bytes] ------------------------------ 000: a8 c0 00 00 00 00 00 00 00 04 00 00 00 00 00 00 016: 00 01 00 00 00 00 00 4e ------------------------------ st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 1a,0,0,0,18,0-[24 bytes] ------------------------------ 000: 0b 00 10 08 00 00 00 00 00 00 02 00 00 00 00 00 016: 00 01 00 00 00 00 00 4e ------------------------------ st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x0 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0(ahsc0:4:0): density code 0x0, 512-byte blocks, write-protected, st0(ahsc0:4:0): buffered st0(ahsc0:4:0): starting block mode decision st0(ahsc0:4:0): Give up and default to variable mode st0(ahsc0:4:0): scsi_cmd st0(ahsc0:4:0): get_xs st0(ahsc0:4:0): returning xs(0x4edf80): flg(0x820)sc_link(0x4ebfe0)retr(0x4)timo(0x1388)cmd(0x4edfdc)len(0x6)data(0xfffffd42)len(0x18)res(0x18)err(0x0)bp(0x0)st0(ahsc0:4:0): command: 15,0,0,0,18,0-[24 bytes] ------------------------------ 000: 00 00 10 08 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 01 00 00 00 00 00 4e ------------------------------ st0(ahsc0:4:0): scsi_done st0(ahsc0:4:0): command: 15,0,0,0,18,0-[24 bytes] ------------------------------ 000: 00 00 10 08 00 00 00 00 00 00 00 00 00 00 00 00 016: 00 01 00 00 00 00 00 4e ------------------------------ st0(ahsc0:4:0): back in cmd() st0(ahsc0:4:0): sc_err1,err = 0x1 code70 valid0 seg0 key5 ili0 eom0 fmark0 info: 0 0 0 0 followed by 6 extra bytes extra: 0 0 0 0 0 0 st0(ahsc0:4:0): calling private err_handler() st0(ahsc0:4:0): illegal request st0(ahsc0:4:0): scsi_interpret_sense (no bp) returned 22 st0(ahsc0:4:0): free_xs st0(ahsc0:4:0): calling private start() st0(ahsc0:4:0): ststart st0: cannot set selected mode st0(ahsc0:4:0): Open complete st0(ahsc0:4:0): [ioctl: get status] st0(ahsc0:4:0): closing END OF FILE From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 5 21:31:50 1994 From: "Hubert Feyrer" "Upload" (Aug 4, 8:55pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Upload Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > I've just finished uploading netbsd.a3000-940726.gz since someone > asked for a 3000 kernel. Thanks for your upload! I`ve moved it to /pub/os/NetBSD/NetBSD-Amiga/kernel. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 5 21:46:23 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- chopps Sat Jul 30 12:27:24 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy added to the repository chopps Sat Jul 30 12:27:44 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/gzip In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/gzip Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/gzip added to the repository chopps Sat Jul 30 12:27:46 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/init In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/init Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/init added to the repository chopps Sat Jul 30 12:27:48 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mkdir In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mkdir Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/mkdir added to the repository chopps Sat Jul 30 12:27:50 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mount In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mount Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/mount added to the repository chopps Sat Jul 30 12:27:52 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mount_ados In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mount_ados Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/mount_ados added to the repository chopps Sat Jul 30 12:27:54 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/newfs In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/newfs Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/newfs added to the repository chopps Sat Jul 30 12:27:56 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/pax In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/pax Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/pax added to the repository chopps Sat Jul 30 12:27:58 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/sh In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/sh Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/sh added to the repository --------------------------------- chopps Sat Jul 30 12:30:32 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy Added Files: Makefile Makefile.inc Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:41 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/gzip In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/gzip Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:43 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/init In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/init Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:45 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mkdir In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mkdir Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:46 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mount In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mount Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:48 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/mount_ados In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/mount_ados Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:49 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/newfs In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/newfs Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/pax In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/pax Added Files: Makefile Log Message: amiga boot floppy binaries chopps Sat Jul 30 12:30:52 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/sh In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/sh Added Files: Makefile Log Message: amiga boot floppy binaries --------------------------------- chopps Sat Jul 30 23:41:02 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/conf Modified Files: GENERIC Log Message: remove hardcoded targets for sd0-7 now use sd*. lkestel Sat Jul 30 23:45:52 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k/dev In directory sun-lamp.cs.berkeley.edu:/e/users/lkestel/src/sys/arch/mac68k/dev Modified Files: ite.c Log Message: Fixed bug with bcopy()'ing more than 65535 bytes; initialize d_ttys and cn_tp on itecnprobe(); other minor bug and warning fixes. --------------------------------- chopps Sun Jul 31 11:42:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: grf_rt.c Log Message: fix default frequency so that normal VGA monitor types don't puke. --------------------------------- chopps Sun Jul 31 12:57:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/conf Modified Files: GENERIC Log Message: GENERIC has AGA, otherwise some people can't run (i.e. monitors do not sync at 15KHz). mycroft Sun Jul 31 12:57:48 PDT 1994 Update of /b/source/CVS/src/lib/csu/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/lib/csu/m68k Modified Files: crt0.c Log Message: Kill historical cruft. --------------------------------- cgd Tue Aug 2 20:12:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/pc532/include Revision/Branch: netbsd-1-0 Modified Files: asm.h profile.h Log Message: from trunk. cgd Tue Aug 2 20:13:12 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/ns32k/sys In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/arch/ns32k/sys Revision/Branch: netbsd-1-0 Modified Files: sigreturn.S Log Message: from trunk. cgd Tue Aug 2 20:14:00 PDT 1994 Update of /b/source/CVS/src/sys/arch/da30/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/da30/conf Revision/Branch: netbsd-1-0 Modified Files: Makefile.da30 Log Message: from trunk. cgd Tue Aug 2 20:16:02 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/conf Revision/Branch: netbsd-1-0 Modified Files: GENERIC Log Message: from trunk. cgd Tue Aug 2 20:18:42 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: grf_rt.c Log Message: from trunk. --------------------------------- chopps Wed Aug 3 08:57:56 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/ld/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/ld/m68k Modified Files: mdprologue.S Log Message: binder_entry() must save all scratch registers to make the process of binding functions completely transparent. pk Wed Aug 3 08:57:58 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/ld/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/pk/ld/i386 Modified Files: mdprologue.S Log Message: Remove some unnecessary code. --------------------------------- cgd Wed Aug 3 09:54:49 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/ld/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/gnu/usr.bin/ld/m68k Revision/Branch: netbsd-1-0 Modified Files: mdprologue.S Log Message: from trunk. --------------------------------- chopps Wed Aug 3 22:00:55 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/gen In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/libc/arch/m68k/gen Modified Files: setjmp.S Log Message: inline call to sigreturn original idea from jason downs we want this to be done for everything including non-PIC code as longjmp() does non-standard things with regs and wouldn't like it if the user replaced the sigreturn() stub. chopps Wed Aug 3 22:02:33 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/libc/arch/m68k Modified Files: SYS.h Log Message: fixed ld.so to properly save all regs when binding PIC functions. We no longer need the special case (PIC) code to push args when calling cerror. chopps Wed Aug 3 22:02:50 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/sys In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/libc/arch/m68k/sys Modified Files: brk.S cerror.S exect.S ptrace.S sbrk.S sigprocmask.S sigreturn.S sigsuspend.S syscall.S Log Message: fixed ld.so to properly save all regs when binding PIC functions. We no longer need the special case (PIC) code to push args when calling cerror. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 22:49:19 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: X troubles (SOLVED) From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu So, when I redirected the error messages that were being destroyed by X_CONSOLE_MODE_ON (duh!), I learned that in order for XF86 2.1.1 to accelerate my video card, it needed to reserve 1K out of the 1Mb on the card, which meant it couldn't QUITE support the 1024x1024 virtual screen in my Xconfig. Now that I have a 1024x1023 virtual screen, it works fine. (Thanks, Matthieu!) Does anyone know offhand if the temptingly empty DIP sockets on my Cirrus Logic GD5426-based AVGA3VL video board can be filled with memory to bring it up to 2Mb? Will they have carefully used a VRAM pinout only available to them? (The "manual"[*] that accompanied the board documents 2MB, and doesn't describe how one gets from 1MB to 2MB.) [*] As if any printed matter accompanying a PC product could possibly be described as a manual... From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 22:50:13 1994 From: Duncan McEwan To: John Kohl Cc: Randy Terbush , "Martin Husemann" , current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (figured out) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu In response to my comment that setting "local" but not "softcar" on for tty01 in the /etc/ttys file causes "cu -l /dev/tty01" to give the error cu: write: input/output error Randy Terbush said: > I also have this same problem with or without 'local' set in my /etc/ttys. > This is running 1.05 or 1.04. But John Kohl said: > > I tried my 1.05 cu this morning, on a line configured: > > tty04 "/usr/libexec/getty tty01" vt100 off rtscts > > (I have a FlexFAX daemon running on that line, exec'ed from rc.local) > > and it worked fine for me. And "Martin Husemann" said: > I don't know what version you are using, but with -current from 26 July > it works fine for me on i386. My /etc/ttys line is: > > # modem under control of mgetty: > tty01 "/usr/libexec/mgetty tty01" vt100 off local rtscts > ... > Note the "off" in above ttys' line; mgetty is definitely not involved here. > (It works with "on" too...) I finally figured out how to make it work for me (with cu 1.04): I needed to create an /etc/uucp/ports file that looked like this: port mymodem type modem device /dev/tty01 speed 19200 Now cu knows that the line is connected to a modem it does the right thing regarding setting CLOCAL on the line. You don't even have to have either of local or softcar set in /etc/ttys. Since cu's behaviour seems to be correct, I'm happy now. All I need to really make my day though is to have John or Martin to tell me that cu 1.04 still works for them even though they don't have an /etc/uucp/ports (or equivelent HDB or V2 uucp config) file ... :-) Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 22:51:31 1994 To: Theo de Raadt Cc: current-users@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: INTEL ETHERNET COMPATIBILITY qQUESTION? <9408050041.AA21519@fsa.ca> From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <9408050041.AA21519@fsa.ca>, Theo de Raadt writes: >> I have an Intel Express 16 ethernet card for a PCI machine (Gateway, > >There isn't a driver for this card at this time. Someone has been >working on somewhat, but it is a horrible card. Your best bet would be >to buy an alternate card; ethernet cards for PC's are cheap. This has probably been beaten to death, but what's a good ISA Ethernet card to buy? ($100-$200 range, BNC) Supposing I were to order one tomorrowish... ;-) -wps From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 23:23:44 1994 From: rhealey@aggregate.com Subject: m68k setjump fixes To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 271 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did all the changes to the m68k .S files related to the setlongjmp register clobbering problem get checked in to the 1.0 tree? I saw them go in to the CVS log but the sup I just did only fetched the changes to ld part of things, not the routines in libc... -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 23:43:51 1994 X-Authentication-Warning: zappa.unna.Ping.DE: Host localhost.Ruhr.DE didn't use HELO protocol To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Re: X troubles <9408041404.AA29204@kaos.ksr.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu ->some fooling around with SuperProbe revealed that it is exiting when it calls ->``ioctl(CONS_fd, X_CONSOLE_MODE_ON, ...)''. I have 'options USERVER,XCONSOLE ' Shouldn't that read XSERVER,UCONSOLE? Gruesse Oskar From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 23:47:57 1994 From: bachesta@angst.tera.com To: current-users@sun-lamp.cs.berkeley.edu Subject: yp under NetBSD 1_0B. & Mysterious disk activiy. Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm running the binary snapshot from July 31, 1994 and I'm trying to get yp to work properly. I'm running my NetBSD machine on our local net. In the past I was able to get yp up and running by copying the /var/yp/binding file from my local sun and rebooting. bachesta:361> ls -l /var/yp/binding/ total 2 -rw-rw-r-- 1 root wheel 14 Jul 29 06:28 tera.com My "domainname is "tera.com" bachesta:362> domainname tera.com I checked for ypbind and it _is_ running: bachesta:360> ps -auxww | grep yp root 49 0.0 0.0 76 248 ?? Ss 7:32AM 2:36.67 ypbind When I do a ypcat hosts I get the following message: No such map hosts.byaddr. Reason: Can't bind to server which \ serves this domain Doing a ypwhich gives me this: can't clnt_call: Can't communicate with ypbind Has anyone else been succesful in getting yp up and running? Am I doing a "bonehead" maneuver? Also on a _possibly_ unrelated topic I have noticed that since NetBSD 1.0A my machine will access the disk every 2-5 seconds when the machine is idle. It's kind of irritating to hear it. I never noticed this before. I'm curious if anyone else has observed this. My machine is an _old_ 20 Mhz 386 with 14 Megs of Ram and two ESDI drives on a Western Digital Controller. Does anyone know whats accessing the disk. How can I find out? Thanks, Jim Bachesta Tera Computer Company bachesta@tera.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 5 23:59:55 1994 To: bachesta@angst.tera.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: yp under NetBSD 1_0B. & Mysterious disk activiy. <9408051423.AA09707@angst.tera.com> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > local net. In the past I was able to get yp up and running by > copying the /var/yp/binding file from my local sun and rebooting. That is the incorrect way to do it. You enable YP by doing mkdir /var/yp reboot I suspect your /var/yp/binding directory is closed to world, and you are running your tests as non-root. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 00:00:46 1994 From: Mike Long To: jfw@ksr.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: X troubles (SOLVED) Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Thu, 04 Aug 94 22:20:37 -0400 >From: "John F. Woods" >Does anyone know offhand if the temptingly empty DIP sockets on my >Cirrus Logic GD5426-based AVGA3VL video board can be filled with memory >to bring it up to 2Mb? Will they have carefully used a VRAM pinout >only available to them? (The "manual"[*] that accompanied the board >documents 2MB, and doesn't describe how one gets from 1MB to 2MB.) All RAM pinouts (except the newest, weirdest ones) are JEDEC standards. What are the part numbers on the VRAMs that are already on the board? Who manufactured them? As far as I know you should only be in trouble if they're parts that are old and have been discontinued. Of course, getting the board to USE the extra memory after you've installed it may be a problem. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 00:01:09 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: dump density bpi = bit/byte ? To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 565 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm trying to use a qic 525 MB tape, which tells me that it is 1020 feet long. I'd like to know whether the density I should be using is to be in Bits/Per/Inch or in Bytes/Per/Inch i.e. 525 * 1024 * 1024 / 1020 / 12 = Value or 525 * 1024 * 1024 * 8 / 1020 / 12 = Value. Cheerio PS. I'm doing the command dump 0udsf 12345 1020 /dev/rst1 /mit -- The cost of living hasn't affected it's popularity. (unknown) current release=doc host=wipux2.wifo.uni-mannheim.de hostbase=/src base=/usr \ prefix=/usr backup delete use-rel-suffix ; updated midday MET NetBSD-current From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 00:05:19 1994 To: "Michael Graff" Cc: Danny Lepage , current-users@sun-lamp.cs.berkeley.edu (current-users mailing list) Subject: Re: What is best, PPP or Slip? <199408041828.NAA06775@packrat.vorpal.com> From: Bill & Sender: owner-current-users@sun-lamp.cs.berkeley.edu > You may get better overall speed unless you don't care about interactive > traffic and you never loose a packet. Assuming no compression and perfect > transfer rates, you'll get 1440 char/sec. That means a 1500-packet would > be over a second to send. So, if 10 of those are queued up before your > small interactive-typing ones, you may wait a while. Actually, No, you won't, because the CSLIP in NetBSD implements priority queueing based on the IP TOS bits. Given header compression (which, on a good day, shrinks the 40 byte IP+TCP header down to 4 bytes) the difference in efficiency between 1500-byte and 250-byte packets is negligable. With 1500 bytes of data, you send 1504 bytes over the serial line with a 1500 byte MTU, vs 1524 with the 250 byte packets; that's about a 1% difference.. The big advantage of the smaller MTU's is that smaller, high priority interactive traffic like telnet can get in ahead of the bigger lower priority stuff like FTP data more quickly.. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 6 01:16:25 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Fri, 5 Aug 1994 18:04:54 -0400 (EDT) Subject: newest kernel To: amiga@sun-lamp.cs.berkeley.edu (netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1014 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Playing with the newest sources can be fun sometimes. :) I got the Aug 3 sources from iastate, compiled the kernel from my own config file, and rebooted with it. It finds all my devices, but when it goes to fsck /dev/sd6a, it's not there. After some discovery, the disk has been changed to /dev/sd2a. I kind of like this logic. No matter what the scsi id of the drive, it gets sdX, where X is the number it is in the chain, relative to the ids. Is this the way it is going to be, or will it reverty back to the old way? Just curious. :) (BTW, with my own tiny kernel, I have 2924555 bytes of memory free on my 4 meg 3000. :) Compiles will be another bit faster now. Later and thanks for the good work! -Chris -- Chris Mattingly | Computer and Technologies Theme Program, NCSU, Raleigh 406-G Wood Hall | Head System Administrator PO Box 21541 | NCSU | Home computer: A3000 - crazytrain.catt.ncsu.edu Raleigh, NC 27607 | (919) 512-0931 | Email: Chris_Mattingly@ncsu.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 01:35:40 1994 From: bachesta@angst.tera.com To: Theo de Raadt Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: yp under NetBSD 1_0B. & Mysterious disk activiy. <9408052006.AA28374@fsa.ca> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >> local net. In the past I was able to get yp up and running by >> copying the /var/yp/binding file from my local sun and rebooting. > >That is the incorrect way to do it. You enable YP by doing > mkdir /var/yp > reboot > >I suspect your /var/yp/binding directory is closed to world, and >you are running your tests as non-root. The permissions are 775 for /var/yp. Just for kicks I did the exact procedure above and it still didn't work :-( Jim Bachesta Tera Computer Company bachesta@tera.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 01:57:30 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rhealey@aggregate.com Subject: Re: m68k setjump fixes Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did all the changes to the m68k .S files related to the setlongjmp register clobbering problem get checked in to the 1.0 tree? No, but the bug fix has been. I'm still deciding whether or not to put the non-critical bits in. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 01:57:45 1994 To: "Michael L. VanLoon -- Iowa State University" Cc: Bill Squier , current-users@sun-lamp.cs.berkeley.edu Subject: Re: INTEL ETHERNET COMPATIBILITY qQUESTION? <199408052205.RAA07727@MindBender.HeadCandy.com> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I've been told that both the 3com 3c5x9 boards, and the SMC/WD 8013x > boards are quite good. There are supposedly PCI versions of both > available, although Theo would probably have to speak authoritatively > on which work well. Regarding the 3COM cards: 3c509 ISA. For some people these work really well, and if you call 1-800-NET-3COM you can get 2/$99. For some people these cards perform *very* badly, and we don't know why yet (I would not recommend this card on an IDE system). 3c579 EISA. Works very well everywhere. I do not know of any PCI cards (but there might be some..) I feel that the extra few bytes of speed fail to warrant the cost. You can get NE2000 clones for about $50 from various places too. Although not the best card, you are pretty much gauranteed it will work. Then there are the SMC/WD 80xx cards. I don't know much about them. They just pretty much work, too. I didn't buy any of the 4 ethernet cards I am using here, so don't take my word for any of this. :-) From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 02:46:18 1994 From: Jim Babb Subject: Re: X troubles (SOLVED) To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Does anyone know offhand if the temptingly empty DIP sockets on my > Cirrus Logic GD5426-based AVGA3VL video board can be filled with memory > to bring it up to 2Mb? Will they have carefully used a VRAM pinout > only available to them? (The "manual"[*] that accompanied the board > documents 2MB, and doesn't describe how one gets from 1MB to 2MB.) > I have a Cirrus card that sounds just like yours, and yes I upgraded it to 2MB. The chips were fairly standard. I think they used the same ones for the 1st MB, only those were small flat-packs instead of DIPs. My recollection was that they were standard 44256's, but I would have to look at the card to be sure. On my board they had the part numbers silk-screened on the card, but then they hid the silk screen with the sockets. Jim From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Aug 6 06:44:23 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Not enough tape devices.... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Since the tape drives appear to support different densities based on their minor numbers, should /dev/MAKEDEV be updated to produce tapes with minor number 0-15 by default? -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 07:36:50 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Bill Squier Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: INTEL ETHERNET COMPATIBILITY qQUESTION? <94Aug5.001422edt.5160@menger.eecs.stevens-tech.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> I have an Intel Express 16 ethernet card for a PCI machine (Gateway, >In message <9408050041.AA21519@fsa.ca>, Theo de Raadt writes: >>There isn't a driver for this card at this time. Someone has been >>working on somewhat, but it is a horrible card. Your best bet would be >>to buy an alternate card; ethernet cards for PC's are cheap. >This has probably been beaten to death, but what's a good ISA Ethernet >card to buy? ($100-$200 range, BNC) Supposing I were to order one >tomorrowish... ;-) I've been told that both the 3com 3c5x9 boards, and the SMC/WD 8013x boards are quite good. There are supposedly PCI versions of both available, although Theo would probably have to speak authoritatively on which work well. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 08:31:39 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: TROUBLE WITH SERIAL PORTS ON 1.0_BETA Cc: buhrow@cats.ucsc.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm attempting to get current from early February and, as some of you may have seen, I have been having trouble getting the serial ports working. My problem is that I have this script that automatically gets the machine's slip internet connection going and, as conditions warrant, keep it going. As the machine boots up under 1.0, this script gets called as it should, but it can never pick up the phone. Per suggestions from this list, I tried setting clocal on the serial port and then tried calling this script. Still no go. Under the system I'm running now, which is not current 1.0, but 0.9a, this script works flawlessly. If anyone can suggest a method of modifying this script so that it will work under 1.0, I'd be much appreciative. I have been scratching my head over this one for a while, and it still baffles me. Because vmstat -i doesn't work, I can't even see if the serial ports are generating interrupts as I try to use them. I'm sure its not a bug, just something I'm missing. -thanks -Brian #!/bin/sh #This shell script will get the slip link running and configure the the routes. # # #Note that this script can call twice, due to a bug at the other end of the #line which causes the other side not to log out on hangup. PATH=/bin:/usr/bin:/sbin:/usr/sbin; export PATH /bin/kill `fstat /dev/com0 |tail +1 |awk '{print $3}'` > /dev/null 2>&1 sleep 10 > /dev/null 2>&1 #give the processes time to die. sleep 180 < /dev/com0& stty clocal 38400 < /dev/com0 chat -v "" atdt5551212 ogin: "\\d\\d\\dfoomoria slip\\d\\d\\d\\n" word: foo\\n < /dev/com0 > /dev/com0 case $? in 0) stty -f /dev/com0 -clocal slattach -h -s 38400 /dev/com0 netstat -rn |fgrep 'sl0' > /dev/null 2>&1 if [ $? -eq 1 ]; then ifconfig sl0 inet 199.4.218.2 199.4.218.1 netmask 0xfffffff8 |logger -i -p daemon.err route add 199.4.218.1 199.4.218.2 |logger -i -p daemon.err fi netstat -rn |fgrep 'default' > /dev/null 2>&1 if [ $? -eq 1 ]; then route add default 199.4.218.1 |logger -i -p daemon.err exit 0 fi echo 'No routes to add' |logger -i -p daemon.err exit 0 ;; 1) /bin/kill `fstat /dev/com0 |tail +1 |awk '{print $3}'` > /dev/null 2>&1 ;\ sleep 10 > /dev/null 2>&1 (sleep 180 < /dev/com0 &) stty clocal 38400 < /dev/com0 ;\ chat -v "" atdt5551212 CONNECT "" < /dev/com0 > /dev/com0 if [ $? -eq 0 ]; then stty -f /dev/com0 -clocal slattach -h -s 38400 /dev/com0 netstat -rn |fgrep 'sl0' > /dev/null 2>&1 if [ $? -eq 1 ]; then ifconfig sl0 inet 199.4.218.2 199.4.218.1 netmask 0xfffffff8 |logger -i -p daemon.err route add 199.4.218.1 199.4.218.2 |logger -i -p daemon.err fi netstat -rn |fgrep 'default' > /dev/null 2>&1 if [ $? -eq 1 ]; then route add default 199.4.218.1 |logger -i -p daemon.err exit 0 fi echo 'No routes to add' |logger -i -p daemon.err exit 0 fi ;; esac echo 'could not't start the network' |logger -i -p daemon.err exit 1 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 08:55:51 1994 To: Jim Babb Cc: jfw@ksr.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: X troubles (SOLVED) <199408052144.OAA05889@sun-lamp.cs.berkeley.edu> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Does anyone know offhand if the temptingly empty DIP sockets on my > > Cirrus Logic GD5426-based AVGA3VL video board can be filled with memory > > to bring it up to 2Mb? (It's actually AVGA3VL1, but I hope the differences would be minor.) > > I have a Cirrus card that sounds just like yours, and yes I upgraded it > to 2MB. The chips were fairly standard. I think they used the same > ones for the 1st MB, only those were small flat-packs instead of DIPs. > My recollection was that they were standard 44256's, but I would have > to look at the card to be sure. The sockets are 20 pin DIP sockets; the first MB is 8 AAA1M304J-06 chips, whatever that is. There are two open surface-mount IC locations, which the manual labels "1M" (the same label given to the actual DRAMs, perhaps they picked the cheaper of 512x8 or 256x4 parts each week?). I pulled out the graphics card to actually look at it up close (skinning three knuckles in the process). I had a devil of a time putting it back apparently because of bending the soft sheet-metal "stiffener" behind the motherboard and flexing the motherboard itself on its inadequate support posts. God I hate the PC architecture. (I could have done the whole thing one-handed in seconds on a modular Mac...) The kernel crashed with a segmentation violation the first time I brought it up, but has run OK since; I hope I didn't fry a chip or hairline-fracture a trace. Blast. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 09:10:13 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Hayes ESP board? From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone running current ever tried using a Hayes ESP board with the com driver? It's "supposed" to be completely 16550-compatible, except that it has a 1024-byte FIFO. Should this thing "just work" with the standard com driver? ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 6 09:25:20 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, michaelv@HeadCandy.com Subject: Re: Hayes ESP board? Sender: owner-current-users@sun-lamp.cs.berkeley.edu In theory, it should `just work', though you'll probably want to modify the output routine to upload more that 16 characters at once. i.e.: if (sc->sc_hwflags & COM_HW_FIFO) { u_char buffer[16], *cp = buffer; int n = q_to_b(&tp->t_outq, cp, sizeof buffer); Change the `16' to maybe `128'. I wouldn't suggest 1024; that's too large to put on the stack, and really too much time to spend in the interrupt handler at once if you have multiple ports. And of course, let me know how it goes. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 6 11:08:28 1994 From: mw@eunet.ch Subject: Re: forwarded message from Jukka Forsgren To: hamish@bnr.ca (hamish) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2348 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Since I think I'm responsible for what's going on in NetBSD 2091/3000 DMA handling (don't think Chris changed it, just moved it over to the new driver), lets reason about this...: > I'd just like to point out that the mechanism NetBSD uses in the A2091 > and A3000 DMA drivers (just do DMA as long as transfers are requested) > can give big problems if that final bytes of a chunk of memory are > read from. Sorry, but I just don't understand what you're trying to say here... To resume how DMA currently works: the request is split into sequences of contigous pages (usually there's just one page to transfer anyway), then the SCSI command to READ or WRITE the *full* amount is issued. In a loop over all prepared DMA slices (the above mentioned sequences), the SBIC xfer register is loaded with the size of the active slice, and DMA is started. After the SBIC has transferred the requested amount of data (there may be further data to be transferred to complete the active SCSI command), it generates an interrupt (important: the SBIC generates the int, *not* the DMA controller. I couldn't get that to work reliably on all boards using the 33c93!). The int-handler stops DMA, reloads the SBIC xfer register, loads new DMA address, and kicks on the whole process again. > If you write 1K starting at (end-of-chunk-1K), then the DMA controller > will attempt to read past (end-of-chunk) in order to fill the FIFO > (since the DMA controller was just told to write to the SCSI chip, not > told to write 1K). If you suspect that this behavior could give you problems (I'd say that's VERY unlikely, because having unvalid pages after valid pages shouldn't be that rare?), set the word-xfer register too in dmago(), and see whether the problem goes away. Problem (I think) is, the GVP DMA controller doesn't have such a register, or nobody found it yet. > Perhaps this is happening now. There is multiple memory chunk support > in NetBSD now, isn't there? Hm, I'm not current with -current, last time I checked there was no multiple-chunk support, but as I said... -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH >Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 7 00:38:28 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: More tape problems..... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu It appears that MAKEDEV sets the permissions too strickly by default. It sets the perms to 640 (root, operator). A better set would be 666 or 660. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 00:44:47 1994 From: "Nathan J. Dohm" To: amiga@sun-lamp.cs.berkeley.edu, mbeausej@qc.bell.ca (michel beausejour) Subject: Re: netbsd-1.0b Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have the exact same problem. Any solutions? Nathan From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 00:56:03 1994 From: etxpihl@etxb.eua.ericsson.se (Tomas Pihl ETX/B/DG) To: amiga@sun-lamp.cs.berkeley.edu Subject: Suggestion for distribution Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I've been on the list for some month and this weekend I finally decided to try out the pre-release of NetBSD. Most of you gurus have nice streamers where you have the distribs so you can easily hook it up to your Amiga an un-tar it, but for me and perhaps others who has to copy everything to floppy (1.44Mb), it's a real pain to re-tar the tar-files to fit a floppy. I would like to suggest to the responsible persons to make the distributionparts no bigger than 1.44Mb. Would that be possible? I'm sure more than just me would like it. I just gave up my attempts to bring home NetBSD after spending 2 hours tar'ing and un-tar'ing... --- Tomas Pihl Ericsson Telecom AB, EO5/ETX/B/DE ATM Broadband From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 01:30:50 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: forwarded message from Jukka Forsgren Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 6, 10:20am, mw@eunet.ch wrote: > Since I think I'm responsible for what's going on in NetBSD 2091/3000 > DMA handling (don't think Chris changed it, just moved it over to the new > driver), lets reason about this...: The basic DMA handling should be the same, as described by Markus. > > Perhaps this is happening now. There is multiple memory chunk support > > in NetBSD now, isn't there? > > Hm, I'm not current with -current, last time I checked there was no > multiple-chunk support, but as I said... No, the current kernel doesn't have multiple-chunk support (except on my system - I've been working on adding it). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:48:35 1994 From: "John F. Woods" To: current-users@sun-lamp.cs.berkeley.edu Subject: tar manual page Sender: owner-current-users@sun-lamp.cs.berkeley.edu I suddenly noticed that no one has yet contributed a tar manual page, so I finally "finished" one. It's a bit rough, but better than nothing. To whom should I mail it? From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:48:44 1994 From: bad@flatlin.ka.sub.org (Christoph Badura) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>Um... what do you think the bt742a and bt747s are? ;-) >>I didn't think they were Adaptec 1742 compatible; that's why they have a >>different driver, right? Or do you mean something else? >OK, point well taken. I believe they started out as 1742 compatible >(correct me if I'm wrong) but diverged. However, I believe they still >will work with drivers that don't use every extended option of their >command language. They are compatible with the 1542B. The BusLogic 32bit "extended" mode is incompatible with the 1742 32bit "extended" mode. -- Christoph Badura bad@flatlin.ka.sub.org Home +49 721 606137 Work +49 228 97024-45 Es genuegt nicht, keine Gedanken zu haben; man muss auch unfaehig sein, sie auszudruecken. - Karl Kraus From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:51:11 1994 To: Duncan McEwan Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (figured out) <199408050734.TAA06808@bats.comp.vuw.ac.nz> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I finally figured out how to make it work for me (with cu 1.04): I needed to > create an /etc/uucp/ports file that looked like this: > > port mymodem > type modem > device /dev/tty01 > speed 19200 > > Now cu knows that the line is connected to a modem it does the right thing > regarding setting CLOCAL on the line. You don't even have to have either of > local or softcar set in /etc/ttys. > > Since cu's behaviour seems to be correct, I'm happy now. All I need to really > make my day though is to have John or Martin to tell me that cu 1.04 still > works for them even though they don't have an /etc/uucp/ports (or equivelent > HDB or V2 uucp config) file ... :-) Thanks for figuring this one out. I spent the morning sorting through the uucp.info files for 1.05 to improve my configuration. However, I think that we have stumbled upon a bug/feature. I *did* have 'port type modem' in my 'sys' file. This would not work until I made a seperate /etc/uucp/port file. Note that by default Taylor wants this file to be named 'port' and not 'ports' as you indicated in your post. The name is configurable though. My previous configuration was attempting to keep all config information in one file. Seperating these files makes things much nicer to maintain. Thanks again -- Randy Terbush INET: randy%sierra%dsndata@sterling.com UUCP: sierra!randy From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:51:18 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet Options (was: INTEL ETHERNET COMPATIBILITY QUESTION?) <199408052205.RAA07727@MindBender.HeadCandy.com> From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >>> I have an Intel Express 16 ethernet card for a PCI machine (Gateway, > > >In message <9408050041.AA21519@fsa.ca>, Theo de Raadt writes: > >>There isn't a driver for this card at this time. Someone has been > >>working on somewhat, but it is a horrible card. Your best bet would be > >>to buy an alternate card; ethernet cards for PC's are cheap. > > >This has probably been beaten to death, but what's a good ISA Ethernet > >card to buy? ($100-$200 range, BNC) Supposing I were to order one > >tomorrowish... ;-) > > I've been told that both the 3com 3c5x9 boards, and the SMC/WD 8013x > boards are quite good. There are supposedly PCI versions of both > available, although Theo would probably have to speak authoritatively > on which work well. My experience is that the SMC cards do not hold a candle to the 3com's for speed. You might also want to consider the TNIC-1500 that is available through South Coast Computing. (I don't have contact information on this machine) This is an ISA solution that is a Lance based card that uses DMA (if I remember the specifics correctly). It has been benchmarked slightly faster on reads than the 3c509, on BSDI. There are drivers available from the supplier last I heard. It may also work with our new Lance drivers? Charles might comment on that specifically. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:51:38 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, randy%sierra%dsndata@sterling.com Subject: Re: Ethernet Options (was: INTEL ETHERNET COMPATIBILITY QUESTION?) Sender: owner-current-users@sun-lamp.cs.berkeley.edu You might also want to consider the TNIC-1500 [...] It may also work with our new Lance drivers? Charles might comment on that specifically. I know very little about the TNIC-1500 card. If it's just a simple LANCE-based card, it should be easy to make it work with the `le' driver. If someone wants to send me programming docs and/or a card, I'll look at it. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:52:04 1994 From: Dave Cornejo Subject: Re: Hayes ESP board? To: michaelv@HeadCandy.com (Michael L. VanLoon -- Iowa State University) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1038 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Has anyone running current ever tried using a Hayes ESP board with the > com driver? It's "supposed" to be completely 16550-compatible, except > that it has a 1024-byte FIFO. Should this thing "just work" with the > standard com driver? I called Hayes about this a while back - Their tech support person told me that the board operates in two modes, one that is 16550 compatible and one that is enhanced with 1024 bytes FIFOs. I don't remember if he said that there was any FIFO difference in 16550 mode or not, but I don't think so. I was told that software support would be necessary to get the full use of the board. The obvious next question was answered with "I don't have that information, try our BBS and see if the engineers there can give out programming info" So you might try posting on their BBS about the programming info if you want to pursue it. -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 01:57:33 1994 From: Wolfgang Solfrank To: bachesta@angst.tera.com Subject: Re: yp under NetBSD 1_0B. & Mysterious disk activiy. Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm running the binary snapshot from July 31, 1994 and I'm trying > to get yp to work properly. I'm running my NetBSD machine on our > local net. In the past I was able to get yp up and running by > copying the /var/yp/binding file from my local sun and rebooting. > > bachesta:361> ls -l /var/yp/binding/ > total 2 > -rw-rw-r-- 1 root wheel 14 Jul 29 06:28 tera.com > > My "domainname is "tera.com" > > bachesta:362> domainname > tera.com > > I checked for ypbind and it _is_ running: > > bachesta:360> ps -auxww | grep yp > root 49 0.0 0.0 76 248 ?? Ss 7:32AM 2:36.67 ypbind > > > When I do a ypcat hosts I get the following message: > > No such map hosts.byaddr. Reason: Can't bind to server which \ > serves this domain > > Doing a ypwhich gives me this: > > can't clnt_call: Can't communicate with ypbind > > Has anyone else been succesful in getting yp up and running? Am I doing > a "bonehead" maneuver? I suspect you are running on a local subnet that doesn't have a ypserver. Your procedure, though more than hacky, worked with the old ypbind due to several deficiencies in the old ypbind. The new versions doesn't support this any more. Now you have to start ypbind with parameter -ypsetme (or -ypset, if you like risks) and then set the ypserver with ypset. Hope this helps, -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 02:13:50 1994 Subject: checking kernel options - checkconf.pl To: current-users@sun-lamp.cs.berkeley.edu From: Luke Mewburn X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 12704 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Here's the latest update of my checkconf perl script, which may be useful to i386 users who want to see what is and isn't correct about their config files (assuming my info is correct of course ;) It should be possible to add information for other ports that use config (not config.new), so if someone wants to mail me changes I'll incorporate them. I've enhanced this over my previous release; for devices you only need an entry for the entire group in the %devices associative array (eg `ed' instead of `ed0', `ed1'), and the % specifier %d is replaced by the number. Similar thing for pseudo devices, except %s is available as well, which = "" if %d == 1, else "s" (a pluralizer) Feel free to send back comments, etc. --- cut here --- file: checkconf #!/usr/bin/perl # # Copyright 1994 Luke Mewburn . All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by Luke Mewburn. # 4. The name of the author may not be used to endorse or promote products # derived from this software without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR # IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES # OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. # IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, # INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, # BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS # OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND # ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR # TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE # USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # # $Id: checkconf,v 1.3 1994/08/06 10:01:04 root Exp root $ # # checkconf -- # check the validity of netbsd kernel config files # # $Log: checkconf,v $ # Revision 1.3 1994/08/06 10:01:04 root # updated %devices entries for more generic definitions # updated %pseudo-devices for the same # cleaned up a couple more options # # Revision 1.2 1994/08/06 08:48:04 root # fixed up a few of the descriptions as suggested by Charles Hannum # # Revision 1.1 1994/08/06 08:33:30 root # Initial revision # # # constants # $MAX_COLS = 80; # # known machine types # %machines = ( 'i386', 'Intel 386 or higher', ); # # known cpu types # %cpus = ( 'I386_CPU', '80386', 'I486_CPU', 'i486', 'I586_CPU', 'pentium', ); # # known options # %options = ( 'MATH_EMULATE', 'floating point emulation', 'DUMMY_NOPS', 'make the kernel a little faster; will break on some machines', 'MACHINE_NONCONTIG','temporary kluge while adding support for non-contiguous physical memory', 'SWAPPAGER', 'paging of processes; REQUIRED', 'VNODEPAGER', 'allow mmap() of vnodes; REQUIRED', 'DEVPAGER', 'allow mmap() of devices; REQUIRED', 'DIAGNOSTIC', 'kernel diagnostics', 'KTRACE', 'system call tracing, a la ktrace(1)', 'FASTLINKS', 'store short symlinks in the inode instead of the filesystem [OBSOLETE]', 'FIFO', 'FIFOs', 'SYSVMSG', 'System V-like message queues', 'SYSVSEM', 'System V-like semaphores', 'SYSVSHM', 'System V-like memory sharing', 'SHMMAXPGS', 'maximum pages for SYSVSHM, default = 1024 pages', 'SCSI', 'generic SCSI system', 'FFS', 'UFS', 'LKM', 'loadable kernel modules', 'XSERVER', 'allows machine to be an X server with PCVT', 'UCONSOLE', 'allow non-root users to aquire console with TIOCCONS', 'QUOTA', 'quotas in UFS', 'MFS', 'memory file system (shares memory and swap space)', 'NFSSERVER', 'Network File System (NFS) server', 'NFSCLIENT', 'Network File System (NFS) client', 'ISOFS', 'ISO 9660 file system, with Rock Ridge [OBSOLETE]', 'CD9660', 'ISO 9660 file system, with Rock Ridge', 'MSDOSFS', 'MS-DOS file system', 'PCFS', 'MS-DOS file system [OBSOLETE]', 'LOFS', 'loopback filesystem [OBSOLETE]', 'NULLFS', 'null filesystem (incorporates lofs)', 'PORTAL', 'portal filesystem', 'PROCFS', 'proc filesystem', 'FDESC', '/dev/fd', 'KERNFS', 'kernel file system', 'IMP', 'host-to-IMP from ARPAnet days [NONEXISTANT]', 'INET', 'internet domain sockets', 'NS', 'xerox ns protocol', 'ISO', 'OSI', 'TPIP', 'connection-based (a la TCP) protocol for ISO', 'EON', 'XXX: CLNP/TPIP tunnelling over IP?', 'CCITT', 'X.25', 'HDLC', 'X.25 hdlc (needed by CCITT)', 'LLC', 'X.25 llc (needed by CCITT)', 'GATEWAY', 'packet forwarding', 'MULTICAST', 'multicast networking - always there [OBSOLETE]', 'MROUTING', 'multicast routing', 'DDB', 'kernel debugger', 'USER_LDT', 'user creatable i386 LDTs (for Wine Windows emulator)', 'COMPAT_NOMID', 'NetBSD 0.8 compatibility (executable format?)', 'COMPAT_09', 'NetBSD 0.9 compatibility', 'COMPAT_43', 'BSD 4.3 compatibility', 'TCP_COMPAT_42', 'BSD 4.2 TCP/IP compatibility', 'SBPRO', 'SoundBlaster Pro', 'DEBUG', 'XXX: unknown debugging option', 'SETUIDSCRIPTS', 'allow Execute only and SetUID scripts via /dev/fd', 'FDSCRIPTS', 'exec Execute only scripts via /dev/fd', ); # # known devices (master, controller, device, disk, and tape entries) # # these entries are matched with the regex '(\D+)(\d)$' for ease. # '%d' in the description matches the actual device number %devices = ( 'isa', 'PC clone ISA bus', 'pc', 'pccons console driver for PC keyboard & monitor', 'vt', 'pcvt virtual multi-console driver PC keyboard & monitor', 'npx', '80x87 numeric co-processor', 'wdc', 'PC ST506/IDE controller %d', 'wd', 'PC ST506/IDE disk %d', 'fdc', 'PC floppy controller %d', 'fd', 'PC floppy drive %d', 'aha', 'Adaptec 154x ISA SCSI controller %d', 'ahb', 'Adaptec 174x EISA SCSI controller %d', 'bt', 'BusLogic 742 SCSI controller %d', 'uha', 'UltraStor 14f SCSI controller %d', 'sea', 'XXX: unknown Seagate SCSI controller %d', 'aic', 'Adaptec 6360-based SCSI controller %d', 'scsibus', 'SCSI bus %d', 'ast', '4 port serial card #%d', 'com', 'serial port %d', 'lpt', 'parallel port %d', 'mms', 'microsoft InPort bus mouse %d', 'lms', 'logitech mouse %d', 'pms', 'PS/2 auxiliary port %d', 'wt', 'non-scsi tape drive %d', 'mcd', 'mitsumi non-scsi CDROM %d', 'sb', 'sound blaster %d', 'ed', 'wd 80x3, 3com 3c503, ne[12]000 ethernet %d', 'hp', 'hp ISA ethernet %d', 'is', 'isolan ethernet %d [OBSOLETE? - use le%d]', 'ie', 'intel 82586 ethernet %d', 'le', 'lance ethernet %d', 'ep', '3com 3c579? ethernet %d', 'sd', 'SCSI disk %d', 'st', 'SCSI tape %d', 'cd', 'SCSI CDROM %d', 'ch', 'SCSI tape changer %d', ); # # pseudo devices # # %d is the actual argument, %s is "" if %d == 1, else "s" %pseudo_devices = ( 'pty', '%d pseudo terminal%s', 'loop', 'loopback inet, %d interface%s', 'ether', 'ethernet; REQUIRED for any ethernet device', 'log', 'kernel gateway into syslogd', 'bpfilter', 'berkeley packet filter (%d FD%s maximum)', 'sl', 'compressed SLIP, %d interface%s', 'ppp', 'point-to-point protocol, %d interface%s', 'vn', '%d vn virtual filesystem device%s', 'speaker', 'speaker queue', 'tb', 'tablet line discipline', 'tun', 'network tunnel line discipline', 'audio', '/dev/audio', ); # # changable entries # %geninfo = (); @cpuinfo = (); %optinfo = (); %devinfo = (); %pseudodevinfo = (); # # slurp in the file # while (<>) { chop; next if $_ eq ""; # skip blank lines next if /^#/; # skip full comment lines s/#.*//; # remove extra comments local($cmd, $arg, @rest) = split; $arg =~ s/"//g; # remove quotes ENTRY: { $cmd eq "machine" && do { print "machine already specified as $geninfo{'machine'}\n" if defined($geninfo{'machine'}); $geninfo{'machine'} = $machines{$arg} || ($arg . " [UNDEFINED]"); last ENTRY; }; $cmd eq "cpu" && do { push(@cpuinfo, $cpus{$arg} || ($arg . " [UNDEFINED]")); last ENTRY; }; $cmd eq "ident" && do { print "ident already specified as $geninfo{'ident'}\n" if defined($geninfo{'ident'}); $geninfo{'ident'} = $arg; last ENTRY; }; $cmd eq "maxusers" && do { print "maxusers already specified as $geninfo{'maxusers'}\n" if defined($geninfo{'maxusers'}); $geninfo{'maxusers'} = $arg; last ENTRY; }; $cmd eq "maxfdescs" && do { print "maxfdescs already specified as $geninfo{'maxfdescs'}\n" if defined($geninfo{'maxfdescs'}); print "maxfdescs has been obsoleted. Please remove it from your config file.\n"; $geninfo{'maxfdescs'} = $arg; last ENTRY; }; $cmd eq "timezone" && do # XXX: improve { $geninfo{'timezone'} = $arg . ' ' . join(' ',@rest); last ENTRY; }; $cmd eq "options" && do { $arg .= join(' ',@rest); # add in any options that had whitespace $arg =~ s/\s+//g; # remove whitespace local(@opts) = split(',', $arg); foreach $option (@opts) { local($argname, $argval) = split('=', $option); $argval = " = " . $argval if (defined($argval)); $optinfo{$argname} = $argval; } last ENTRY; }; $cmd eq "config" && do # XXX: improve { print "config already specified as $geninfo{'config'}\n" if defined($geninfo{'config'}); $geninfo{'config'} = $arg . ' ' . join(' ',@rest); last ENTRY; }; $cmd =~ /^(master|controller|device|disk|tape)$/ && do { $devinfo{$arg} = join(' ', @rest); last ENTRY; }; $cmd eq "pseudo-device" && do { $pseudodevinfo{$arg} = join(' ', @rest); last ENTRY; }; print "Unknown directive: $cmd\n"; } # ENTRY } # while # # print the config file's innermost secrets :) # grep ((do {$geninfo{$_} = "undefined" unless defined($geninfo{$_})} ), ('machine', 'ident', 'maxusers', 'timezone', 'config')); $cpuinfo = join(' ', @cpuinfo); print <>>>> "Michael" == Michael L Hitch writes: Michael> No, the current kernel doesn't have multiple-chunk support Michael> (except on my system - I've been working on adding it). And mine... Tim has had it for quite some time on a #744 kernel, I retrofitted his changes a month ago into current and it works nice. Chris has had Tim's old changes for quite some time I believe, I don't know why he haven't got down to installing them. I suspect lack of time, as he has done miraculosly many other things to NetBSD. Niklas From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 08:45:31 1994 From: John Kohl To: core@sun-lamp.cs.berkeley.edu, i386-port@sun-lamp.cs.berkeley.edu, hm@hcshh.hcs.de Cc: mycroft@ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: bugfix for pcvt-3.00, March 1994 (NetBSD-current, c. Aug 1) X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I think I tracked down the problem I had on NetBSD-current/i386 with pcvt and losing keyboard control to a fresh X server trying to grab the graphics mode on the same virtual console as an existing server. I didn't have problems when I ran 'xinit -- :1' from another virtual console; only when I ran it _from within an xterm_ did I have problems. Here's a patch which seems to fix the immediate problem; it makes the VT_SETMODE fail if something tries to set process mode on the same VT as an active process. However, this doesn't mean that "xinit -- vtY :1" will start an X server on vtY--the context at the time of the VT_PROCESS may still be the current virtual console if the existing X server doesn't yield before the new one tries to set VT_PROCESS mode. Maybe there's some missing handshake on the console switch completing. ==John *** 1.1 1994/08/05 01:39:53 --- pcvt_ext.c 1994/08/07 02:55:52 *************** *** 2297,2302 **** --- 2297,2306 ---- #endif /* PCVT_FAKE_SYSCONS10 */ case VT_SETMODE: + if (vsp->smode.mode == VT_PROCESS && + ((struct vt_mode *)data)->mode == VT_PROCESS && + vsp->proc != p) + return EBUSY; /* already in use on this VT */ vsp->smode = *(struct vt_mode *)data; if(vsp->smode.mode == VT_PROCESS) { vsp->proc = p; From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 09:25:35 1994 Subject: [CORRECTION/REPOST] checking kernel config files - checkconf.pl To: current-users@sun-lamp.cs.berkeley.edu Cc: jhs@regent.e-technik.tu-muenchen.de From: Luke Mewburn X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 13930 Sender: owner-current-users@sun-lamp.cs.berkeley.edu [A repost with the file in 'shar -F' format (-F forces the X escape at the start of each line), so that the line with a single `.' in my source file doesn't stuff up on the confused sendmail between here & sun-lamp. -lm] Here's the latest update of my checkconf perl script, which may be useful to i386 users who want to see what is and isn't correct about their config files (assuming my info is correct of course ;) It should be possible to add information for other ports that use config (not config.new), so if someone wants to mail me changes I'll incorporate them. I've enhanced this over my previous release; for devices you only need an entry for the entire group in the %devices associative array (eg `ed' instead of `ed0', `ed1'), and the % specifier %d is replaced by the number. Similar thing for pseudo devices, except %s is available as well, which = "" if %d == 1, else "s" (a pluralizer) Feel free to send back comments, etc. --- cut here --- file: checkconf.shar #!/bin/sh # This is a shell archive (produced by shar 3.49) # To extract the files from this archive, save it to a file, remove # everything above the "!/bin/sh" line above, and type "sh file_name". # # made 08/07/1994 04:17 UTC by lm@goanna # Source directory /r/staff/lm # # existing files will NOT be overwritten unless -c is specified # # This shar contains: # length mode name # ------ ---------- ------------------------------------------ # 11427 -rwx------ checkconf # # ============= checkconf ============== if test -f 'checkconf' -a X"$1" != X"-c"; then echo 'x - skipping checkconf (File already exists)' else echo 'x - extracting checkconf (Text)' sed 's/^X//' << 'SHAR_EOF' > 'checkconf' && X#!/usr/bin/perl X# X# Copyright 1994 Luke Mewburn . All rights reserved. X# X# Redistribution and use in source and binary forms, with or without X# modification, are permitted provided that the following conditions X# are met: X# 1. Redistributions of source code must retain the above copyright X# notice, this list of conditions and the following disclaimer. X# 2. Redistributions in binary form must reproduce the above copyright X# notice, this list of conditions and the following disclaimer in the X# documentation and/or other materials provided with the distribution. X# 3. All advertising materials mentioning features or use of this software X# must display the following acknowledgement: X# This product includes software developed by Luke Mewburn. X# 4. The name of the author may not be used to endorse or promote products X# derived from this software without specific prior written permission. X# X# THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR X# IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES X# OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. X# IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, X# INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, X# BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS X# OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND X# ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR X# TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE X# USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. X# X# $Id: checkconf,v 1.3 1994/08/06 10:01:04 root Exp root $ X# X# checkconf -- X# check the validity of netbsd kernel config files X# X# $Log: checkconf,v $ X# Revision 1.3 1994/08/06 10:01:04 root X# updated %devices entries for more generic definitions X# updated %pseudo-devices for the same X# cleaned up a couple more options X# X# Revision 1.2 1994/08/06 08:48:04 root X# fixed up a few of the descriptions as suggested by Charles Hannum X# X# Revision 1.1 1994/08/06 08:33:30 root X# Initial revision X# X X# X# constants X# X$MAX_COLS = 80; X X# X# known machine types X# X%machines = ( X 'i386', 'Intel 386 or higher', X); X X# X# known cpu types X# X%cpus = ( X 'I386_CPU', '80386', X 'I486_CPU', 'i486', X 'I586_CPU', 'pentium', X); X X# X# known options X# X%options = ( X 'MATH_EMULATE', 'floating point emulation', X 'DUMMY_NOPS', 'make the kernel a little faster; will break on some machines', X 'MACHINE_NONCONTIG','temporary kluge while adding support for non-contiguous physical memory', X 'SWAPPAGER', 'paging of processes; REQUIRED', X 'VNODEPAGER', 'allow mmap() of vnodes; REQUIRED', X 'DEVPAGER', 'allow mmap() of devices; REQUIRED', X 'DIAGNOSTIC', 'kernel diagnostics', X 'KTRACE', 'system call tracing, a la ktrace(1)', X 'FASTLINKS', 'store short symlinks in the inode instead of the filesystem [OBSOLETE]', X 'FIFO', 'FIFOs', X 'SYSVMSG', 'System V-like message queues', X 'SYSVSEM', 'System V-like semaphores', X 'SYSVSHM', 'System V-like memory sharing', X 'SHMMAXPGS', 'maximum pages for SYSVSHM, default = 1024 pages', X 'SCSI', 'generic SCSI system', X 'FFS', 'UFS', X 'LKM', 'loadable kernel modules', X 'XSERVER', 'allows machine to be an X server with PCVT', X 'UCONSOLE', 'allow non-root users to aquire console with TIOCCONS', X 'QUOTA', 'quotas in UFS', X 'MFS', 'memory file system (shares memory and swap space)', X 'NFSSERVER', 'Network File System (NFS) server', X 'NFSCLIENT', 'Network File System (NFS) client', X 'ISOFS', 'ISO 9660 file system, with Rock Ridge [OBSOLETE]', X 'CD9660', 'ISO 9660 file system, with Rock Ridge', X 'MSDOSFS', 'MS-DOS file system', X 'PCFS', 'MS-DOS file system [OBSOLETE]', X 'LOFS', 'loopback filesystem [OBSOLETE]', X 'NULLFS', 'null filesystem (incorporates lofs)', X 'PORTAL', 'portal filesystem', X 'PROCFS', 'proc filesystem', X 'FDESC', '/dev/fd', X 'KERNFS', 'kernel file system', X 'IMP', 'host-to-IMP from ARPAnet days [NONEXISTANT]', X 'INET', 'internet domain sockets', X 'NS', 'xerox ns protocol', X 'ISO', 'OSI', X 'TPIP', 'connection-based (a la TCP) protocol for ISO', X 'EON', 'XXX: CLNP/TPIP tunnelling over IP?', X 'CCITT', 'X.25', X 'HDLC', 'X.25 hdlc (needed by CCITT)', X 'LLC', 'X.25 llc (needed by CCITT)', X 'GATEWAY', 'packet forwarding', X 'MULTICAST', 'multicast networking - always there [OBSOLETE]', X 'MROUTING', 'multicast routing', X 'DDB', 'kernel debugger', X 'USER_LDT', 'user creatable i386 LDTs (for Wine Windows emulator)', X 'COMPAT_NOMID', 'NetBSD 0.8 compatibility (executable format?)', X 'COMPAT_09', 'NetBSD 0.9 compatibility', X 'COMPAT_43', 'BSD 4.3 compatibility', X 'TCP_COMPAT_42', 'BSD 4.2 TCP/IP compatibility', X 'SBPRO', 'SoundBlaster Pro', X 'DEBUG', 'XXX: unknown debugging option', X 'SETUIDSCRIPTS', 'allow Execute only and SetUID scripts via /dev/fd', X 'FDSCRIPTS', 'exec Execute only scripts via /dev/fd', X); X X# X# known devices (master, controller, device, disk, and tape entries) X# X# these entries are matched with the regex '(\D+)(\d)$' for ease. X# '%d' in the description matches the actual device number X%devices = ( X 'isa', 'PC clone ISA bus', X 'pc', 'pccons console driver for PC keyboard & monitor', X 'vt', 'pcvt virtual multi-console driver PC keyboard & monitor', X 'npx', '80x87 numeric co-processor', X 'wdc', 'PC ST506/IDE controller %d', X 'wd', 'PC ST506/IDE disk %d', X 'fdc', 'PC floppy controller %d', X 'fd', 'PC floppy drive %d', X 'aha', 'Adaptec 154x ISA SCSI controller %d', X 'ahb', 'Adaptec 174x EISA SCSI controller %d', X 'bt', 'BusLogic 742 SCSI controller %d', X 'uha', 'UltraStor 14f SCSI controller %d', X 'sea', 'XXX: unknown Seagate SCSI controller %d', X 'aic', 'Adaptec 6360-based SCSI controller %d', X 'scsibus', 'SCSI bus %d', X 'ast', '4 port serial card #%d', X 'com', 'serial port %d', X 'lpt', 'parallel port %d', X 'mms', 'microsoft InPort bus mouse %d', X 'lms', 'logitech mouse %d', X 'pms', 'PS/2 auxiliary port %d', X 'wt', 'non-scsi tape drive %d', X 'mcd', 'mitsumi non-scsi CDROM %d', X 'sb', 'sound blaster %d', X 'ed', 'wd 80x3, 3com 3c503, ne[12]000 ethernet %d', X 'hp', 'hp ISA ethernet %d', X 'is', 'isolan ethernet %d [OBSOLETE? - use le%d]', X 'ie', 'intel 82586 ethernet %d', X 'le', 'lance ethernet %d', X 'ep', '3com 3c579? ethernet %d', X 'sd', 'SCSI disk %d', X 'st', 'SCSI tape %d', X 'cd', 'SCSI CDROM %d', X 'ch', 'SCSI tape changer %d', X); X X# X# pseudo devices X# X# %d is the actual argument, %s is "" if %d == 1, else "s" X%pseudo_devices = ( X 'pty', '%d pseudo terminal%s', X 'loop', 'loopback inet, %d interface%s', X 'ether', 'ethernet; REQUIRED for any ethernet device', X 'log', 'kernel gateway into syslogd', X 'bpfilter', 'berkeley packet filter (%d FD%s maximum)', X 'sl', 'compressed SLIP, %d interface%s', X 'ppp', 'point-to-point protocol, %d interface%s', X 'vn', '%d vn virtual filesystem device%s', X 'speaker', 'speaker queue', X 'tb', 'tablet line discipline', X 'tun', 'network tunnel line discipline', X 'audio', '/dev/audio', X); X X# X# changable entries X# X X X%geninfo = (); X@cpuinfo = (); X%optinfo = (); X%devinfo = (); X%pseudodevinfo = (); X X X# X# slurp in the file X# Xwhile (<>) X{ X chop; X next if $_ eq ""; # skip blank lines X next if /^#/; # skip full comment lines X s/#.*//; # remove extra comments X local($cmd, $arg, @rest) = split; X $arg =~ s/"//g; # remove quotes X ENTRY: X { X $cmd eq "machine" && do X { X print "machine already specified as $geninfo{'machine'}\n" X if defined($geninfo{'machine'}); X $geninfo{'machine'} = $machines{$arg} || ($arg . " [UNDEFINED]"); X last ENTRY; X }; X $cmd eq "cpu" && do X { X push(@cpuinfo, $cpus{$arg} || ($arg . " [UNDEFINED]")); X last ENTRY; X }; X $cmd eq "ident" && do X { X print "ident already specified as $geninfo{'ident'}\n" X if defined($geninfo{'ident'}); X $geninfo{'ident'} = $arg; X last ENTRY; X }; X $cmd eq "maxusers" && do X { X print "maxusers already specified as $geninfo{'maxusers'}\n" X if defined($geninfo{'maxusers'}); X $geninfo{'maxusers'} = $arg; X last ENTRY; X }; X $cmd eq "maxfdescs" && do X { X print "maxfdescs already specified as $geninfo{'maxfdescs'}\n" X if defined($geninfo{'maxfdescs'}); X print "maxfdescs has been obsoleted. Please remove it from your config file.\n"; X $geninfo{'maxfdescs'} = $arg; X last ENTRY; X }; X $cmd eq "timezone" && do # XXX: improve X { X $geninfo{'timezone'} = $arg . ' ' . join(' ',@rest); X last ENTRY; X }; X $cmd eq "options" && do X { X $arg .= join(' ',@rest); # add in any options that had whitespace X $arg =~ s/\s+//g; # remove whitespace X local(@opts) = split(',', $arg); X foreach $option (@opts) X { X local($argname, $argval) = split('=', $option); X $argval = " = " . $argval if (defined($argval)); X $optinfo{$argname} = $argval; X } X last ENTRY; X }; X $cmd eq "config" && do # XXX: improve X { X print "config already specified as $geninfo{'config'}\n" X if defined($geninfo{'config'}); X $geninfo{'config'} = $arg . ' ' . join(' ',@rest); X last ENTRY; X }; X $cmd =~ /^(master|controller|device|disk|tape)$/ && do X { X $devinfo{$arg} = join(' ', @rest); X last ENTRY; X }; X $cmd eq "pseudo-device" && do X { X $pseudodevinfo{$arg} = join(' ', @rest); X last ENTRY; X }; X print "Unknown directive: $cmd\n"; X } # ENTRY X} # while X X# X# print the config file's innermost secrets :) X# X Xgrep ((do {$geninfo{$_} = "undefined" unless defined($geninfo{$_})} ), X ('machine', 'ident', 'maxusers', 'timezone', 'config')); X$cpuinfo = join(' ', @cpuinfo); X Xprint < the hard part'' -- Coyote, in Kim Stanley Robinson's `Green Mars' From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 10:43:55 1994 From: lburns@cats.ucsc.edu (Len Burns) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: Looking for a bootable current floppy Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a bootable floppy image available yet? My boot blocks gott crunched and I suddenly realized that all I have is a 0.9 boot floppy and a 4.4 file system on the hard disk. Fun stuff. -Len From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 7 14:29:08 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/bin/ps/ps.1 U src/etc/etc.mac68k/MAKEDEV U src/etc/etc.mac68k/ttys U src/gnu/usr.bin/sort/sort.c U src/lib/libc/arch/m68k/SYS.h U src/lib/libc/arch/m68k/gen/setjmp.S U src/lib/libc/arch/m68k/sys/brk.S U src/lib/libc/arch/m68k/sys/cerror.S U src/lib/libc/arch/m68k/sys/exect.S U src/lib/libc/arch/m68k/sys/ptrace.S U src/lib/libc/arch/m68k/sys/sbrk.S U src/lib/libc/arch/m68k/sys/sigprocmask.S U src/lib/libc/arch/m68k/sys/sigreturn.S U src/lib/libc/arch/m68k/sys/sigsuspend.S U src/lib/libc/arch/m68k/sys/syscall.S U src/lib/libcurses/curses.3 U src/lib/libkvm/kvm_nlist.3 U src/libexec/mail.local/mail.local.c U src/sbin/dmesg/dmesg.8 U src/sbin/init/init.c U src/sbin/routed/inet.c U src/share/man/man4/ccd.4 U src/share/termcap/termcap.5 U src/share/termcap/termcap.src U src/sys/arch/amiga/floppy/tar/Makefile U src/sys/arch/hp300/stand/Makefile cvs checkout: installboot.c is no longer in the repository U src/sys/arch/hp300/stand/installboot.sh U src/sys/arch/i386/floppy/umount/umount.c U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_le.c U src/sys/arch/i386/isa/mcd.c U src/sys/arch/mac68k/dev/grf.c U src/sys/arch/mac68k/dev/ser.c U src/sys/arch/mac68k/scsi/cd.c U src/sys/arch/pc532/scsi/cd.c U src/sys/lib/libsa/Makefile U src/sys/lib/libsa/arp.c U src/sys/lib/libsa/net.c U src/sys/lib/libsa/rarp.c U src/sys/lib/libsa/saerrno.h U src/sys/lib/libsa/stand.h U src/sys/lib/libsa/strerror.c U src/sys/msdosfs/msdosfs_fat.c U src/sys/scsi/cd.c U src/sys/sys/cdio.h U src/usr.bin/fstat/fstat.1 U src/usr.bin/netstat/netstat.1 U src/usr.bin/nfsstat/nfsstat.1 U src/usr.bin/w/uptime.1 U src/usr.bin/w/w.1 U doc/CHANGES Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun Aug 7 03:47:13 1994 SUP Scan for current completed at Sun Aug 7 03:52:10 1994 SUP Scan for mirror starting at Sun Aug 7 03:52:10 1994 SUP Scan for mirror completed at Sun Aug 7 03:55:26 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 16:59:48 1994 From: JOCHEN BUEHLER To: amiga@sun-lamp.cs.berkeley.edu Subject: -release and 4000/040 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I updated my NetBSD setup from 940709 snapshot to the 1.0-pre-release one. Now I have some troubles when going multi-user: 1) mount_mfs doesn`t work any more (bus error and core dump) 2) routed also causes a bus error (--> core dump) 3) X11 doesn`t run any longer (June Retina+AGA compilation) Machine-config: A4000/040, 2 meg CHIP, 8 fast, 4 meg Z2 fast, A2091, Retina Z3 Anyone running NetBSD on a A4000 has encountered these problems, too ? thanks Jochen From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 18:05:55 1994 From: tjhayko@io.org Subject: Adding CD9660 FS to kernel To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5091 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've recompiled my own kernel in an attempt to make it smaller and get support for CDROM's. I've tried mounting the cdrom with the following command "mount_cd9660 /dev/cd0a /cdrom" and I get back a message about the cdrom filesystem being read only. However, when I do an ls in the /cdrom directory, I don't see any files. Have I mounted the cdrom correctly? If not, what else could be wrong? Here is the config file I've used to recompile the kernel from the Aug 4 sources: # # My special config # # $Id: GENERIC,v 1.22.2.3 1994/08/03 03:16:01 cgd Exp $ # # include "std.amiga" maxusers 8 options TIMEZONE=300, DST=1 # # processors this kernel should support # options "M68040" # support for 040 options FPSP # MC68040 floating point support #options "M68030" # support for 030 #options "M68020" # support for 020/851 options FPCOPROC # Support for MC6888[12] (Required) options SWAPPAGER # Pager for processes (Required) options VNODEPAGER # Pager for vnodes (Required) options DEVPAGER # Pager for devices (Required) # # Networking options # options INET # IP networking support (Required) #options ISO # ISO Networking support #options TPIP # ARGO TP networking support #options CCITT # CCITT X.25 #options NS # Xerox XNS #options EON # ISO CLNL over IP #options GATEWAY # Packet forwarding #options DIRECTED_BROADCAST # Broadcast across subnets #options NSIP # XNS over IP # # File system related options # options QUOTA # Disk quotas for local disks #options NFSSERVER # Network File System server side code #options NFSCLIENT # Network File System client side code # # File systems # options FFS # Berkeley fast file system options MFS # Memory based filesystem options PROCFS # Process filesystem options KERNFS # Kernel parameter filesystem (Recommended) options FDESC # /dev/fd filesystem options NULLFS # Loopback filesystem options FIFO # FIFO operations on vnodes (Recommended) options ADOSFS # AmigaDOS file system options "CD9660" # ISO 9660 file system, with Rock Ridge #options PORTAL # Portal filesystem #options MSDOSFS # MS-DOS filesystem # # Compatability options for various existing systems # options "COMPAT_09" # compatability with older NetBSD release options "COMPAT_43" # 4.3 BSD compatible system calls options COMPAT_SUNOS # Support to run Sun (m68k) executables options "TCP_COMPAT_42" # Use 4.2 BSD style TCP options "COMPAT_NOMID" # allow nonvalid machine id executables #options COMPAT_HPUX # HP300 compatability # # Support for System V IPC facilities. # options SYSVSHM # System V-like shared memory options SYSVMSG # System V-like messages options SYSVSEM # System V-like semaphores # # Support for various kernel options # options GENERIC # Mini-root boot support options LKM # Loadable kernel modules options KTRACE # Add kernel tracing system call options DIAGNOSTIC # Add additional error checking code options "NKMEMCLUSTERS=256" # Size of kernel malloc area # # Misc. debuging options # options PANICWAIT # Require keystroke to dump/reboot #options DEBUG # Add debugging statements options DDB # Kernel debugger #options SYSCALL_DEBUG # debug all syscalls. #options SCSIDEBUG # Add SCSI debugging statements #options KGDB # Kernel debugger (KGDB) support #options PANICBUTTON # Forced crash via keypress (???) # # Amiga specific options # #options RETINACONSOLE # enable code to allow retina to be console options GRF_ECS # Enhanced Chip Set options GRF_NTSC # NTSC options GRF_PAL # PAL #options "GRF_A2024" # Support for the A2024 options GRF_AGA # AGA Chip Set #options "KFONT_8X11" # 8x11 font grfcc0 at mainbus0 # custom chips #grfrt0 at ztwobus0 # retina II #grfrh0 at zthreebus0 # retina III grf0 at grfcc0 #grf1 at grfrt0 #grf2 at grfrh0 ite0 at grf0 # terminal emulators for grf's #ite1 at grf1 # terminal emulators for grf's #ite2 at grf2 # terminal emulators for grf's #le0 at ztwobus0 # Lance ethernet. #ed0 at ztwobus0 # dp8390 ethernet # scsi stuff, all possible #gvpbus0 at ztwobus0 #gtsc0 at gvpbus0 # GVP series II scsi #ahsc0 at mainbus0 # A3000 scsi #atzsc0 at ztwobus0 #wstsc0 at ztwobus0 # Wordsync II scsi #ivsc0 at ztwobus0 # IVS scsi #mlhsc0 at ztwobus0 # Hacker scsi #otgsc0 at ztwobus0 # 12 gauge scsi #zssc0 at ztwobus0 # Zeus scsi #mgnsc0 at ztwobus0 # Magnum scsi wesc0 at zthreebus0 # Warp Engine scsi idesc0 at mainbus0 # A4000(A1200?) IDE scsibus0 at gtsc0 scsibus1 at ahsc0 scsibus2 at atzsc0 scsibus2 at wstsc0 scsibus3 at ivsc0 scsibus4 at mlhsc0 scsibus5 at otgsc0 scsibus6 at zssc0 scsibus7 at mgnsc0 scsibus8 at wesc0 scsibus9 at idesc0 # each hard drive from low target to high # will configure to the next available sd unit number sd* at scsibus? target ? lun ? # scsi disks st* at scsibus? target ? lun ? # scsi tapes cd* at scsibus? target ? lun ? # scsi cd's pseudo-device sl # slip pseudo-device ppp # ppp pseudo-device view 10 # views pseudo-device pty 16 # pseudo terminals pseudo-device loop # network loopback config netbsd swap on generic From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 18:44:54 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Adding CD9660 FS to kernel To: tjhayko@io.org Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 677 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, tjhayko@io.org wrote: > > I've recompiled my own kernel in an attempt to make it smaller and get > support for CDROM's. I've tried mounting the cdrom with the following > command "mount_cd9660 /dev/cd0a /cdrom" and I get back a message about > the cdrom filesystem being read only. However, when I do an ls in the > /cdrom directory, I don't see any files. Have I mounted the cdrom > correctly? If not, what else could be wrong? Here is the config file > I've used to recompile the kernel from the Aug 4 sources: The same problem appears with an adosfs partition mounted. Aparently only root has permissions to read the directory. Ron From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 7 18:46:57 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Adding CD9660 FS to kernel Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199408071518.LAA08141@nudge.io.org> tjhayko@io.org writes: > I've recompiled my own kernel in an attempt to make it smaller and get > support for CDROM's. I've tried mounting the cdrom with the following > command "mount_cd9660 /dev/cd0a /cdrom" and I get back a message about > the cdrom filesystem being read only. However, when I do an ls in the > /cdrom directory, I don't see any files. Have I mounted the cdrom > correctly? If not, what else could be wrong? Here is the config file The directory is empty because the cdrom hasn't been mounted (df should verify this). The cd9660 filesystem will refuse to mount as read/write, so you have to explicity tell it read-only: mount -t cd9660 -o ro /dev/cd0a /cdrom Even easier is to put a line for the cdrom in your fstab with an options field of "noauto,ro". nauto means the filesystem will not be mounted by "mount -a", so it won't be mounted automaticly durring boot. Once you've done that you can just use: mount /cdrom to mount and umount /cdrom to unmount, which is much more convenient. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 02:46:22 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Revenge of the Install doc Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm running out of time to work on this due to my impending 3 week vacation which starts this coming Friday. I want to have the Install doc finished in the next couple of days, but need help. Please review this and make corrections/changes as necessary. If someone would like to flesh out the Upgrading from 0.9c section, that wouldn't be a "bad thing(tm)". Formatting issues can be ignored, I'm only concerned with raw text at this time. Many thanks to those whom have already sent in changes and suggestions. --- SOF --- Installing NetBSD-Amiga (4.4BSD) August 7th, 1994 Abstract: This document contains the very hastily written instructions for the installation the NetBSD-Amiga 1.0 (4.4BSD) release. NetBSD-Amiga Mailing List: majordomo@sun-lamp.cs.berkeley.edu EMail: billc@icecube.cryogenic.com CryoCafe BBS: 1-503-257-4823 IRC: #NetBSD and #Amiga NetBSD-Amiga Release 1.0 will be available on a QIC-120/150 (DC6120/DC6150) 1/4" tape from this address for US$30. NetBSD-Amiga Port c/o William Coldwell P.O. Box 16924 Portland, Oregon 97216-0924 USA SYSTEM REQUIREMENTS ~~~~~~~~~~~~~~~~~~~ Supported STANDARD Amigas*: A4000/040, A3000, A2500 * These machines are supported right out of the box. Other configurations of Amigas must meet the requirements below. Configuration Requirements: Machine: Amiga CPU/FPU/MMU: MC68020-CPU/MC68881*-FPU/M68851-MMU MC68030%-CPU-MMU/MC68881*-FPU MC68040^-CPU-MMU-FPU * - MC68882-FPU is acceptable % - M68EC030 is not acceptable ^ - M68EC040 and MC68LC040 are not acceptable Memory: 4* Megabytes of contiguous FAST RAM or more *4M would be a bare minumum, with lots of swapping. 1 Megabyte of CHIP RAM or more Disk: HD space: recommended/with X absolutely needed/with X root (/) 15M/15M 10M/10M swap 2M for every M ram user (/usr) 65M/100M 45M/80M local (/local) anysize you want for your stuff. thus recomended size for an 8M system (4M will be less) 15 + 16 + 65 = 96M, which leaves 24M ados partition. Basically, 100 Megabytes of free space or more Tape (not required, but can make installation easier): Most SCSI tape controllers, including Archive Viper, Cipher SCSI-2 ST150. Disk controller: A4000 IDE A3000 SCSI A2500 SCSI A2091 SCSI A4091 SCSI-2 Supra WordSync SCSI GVP Series II SCSI IVS SCSI CSA Twelve Gauge SCSI CSA Magnum SCSI MacroSystem Development WarpEngine SCSI-2 Supported External Filesystems: AmigaDOS ISO-9660 (CDROM) [XXX] MS-DOS? Video controller: AGA-NTSC/PAL (15/31kHz) ECS-NTSC/PAL (15kHz) ECS-NTSC/PAL - A3000 Flickerfixer (31kHz) ECS-A2024-NTSC/PAL (15kHz/10Hz) Noahji (MacroSystem US) Retina Network controller: A2065 Ethernet Hydra Ethernet Input device: 2 button mouse 3 button mouse Joystick Keyboard [XXX] (and how to localize...) Ports: Built-in Parallel (Centronics) Built-in Serial (RS232) Files: ~~~~~~ release/bootfloppy.dms (REQUIRES DMS unarchiver*) release/base.tar.gz (required) release/etc.tar.gz (required) release/netbsd.gz (required) tools/loadbsd.gz (required) release/comp.tar.gz (recommended) release/games.tar.gz (recommended) release/man.tar.gz (recommended) release/misc.tar.gz (recommended) release/text.tar.gz (recommended) * This is available at aminet/util/arc/ Also, the only place I could find gzip for ados was tsx-11.mit.edu:/pub/linux/something (needed to unarchive the kernel) FTP Sites: ~~~~~~~~~~ ftp.uni-regensburg.de pub/NetBSD-Amiga/release/* ftp.iastate.edu wuarchive.wustl.edu (coming soon) sun-lamp.cs.berkeley.edu: pub/NetBSD/arch/amiga/release/* Disk space: ~~~~~~~~~~~ 15M for root (/) (or more) 2 * FAST RAM Megabytes for swap* (i.e., 8M system == 16M swap) 45M for /usr (add 20M for sys-src, add 35M extra for X) (or more) Full source (kernel(sys-src)+binaries) is >80MB. *On a 4M system, you might want more than 8M swap, since you will be swapping all the time. Disclaimer: ~~~~~~~~~~~ The author assumes no responsibility whatsoever for you losing data, time and hair. Full Install: ~~~~~~~~~~~~~ If you have a system that meets the above requirements, and you want to check out NetBSD-Amiga, you will need to create some partitions on your harddrive(s) for it. Use the example below as a loose guide. The main thing is that you want to create a ROOT, SWAP, and USR partition of at _least_ the recommended sizes. You will have to take special note to watch the SCSI UNIT, as it has relevence on the /dev/sdX number. IMPORTANT: READ AND UNDERSTAND THIS, OR YOU WILL BE SORRY LATER ~~~~~~~~~~ Say your system has 3 SCSI devices (note: IDE drives will show up as SCSI devices under NetBSD), IDs 0, 3, and 4. These will now show up as sd0 (ID 0), sd1 (ID 3) and sd2 (ID 4). The higher the ID of the device is, the higher sd will increment. Write the IDs to sd# down! If you NetBSD partitions are on the SCSI drive at ID3, then your NetBSD system will be on /dev/sd1 - replace any references to /dev/sd0x with /dev/sd1x in the examples! [XXX] > /dev/sd6d /usr ufs rw 1 1 I assume from this that the 52M drive is SCSI id 6? Did you have any AmigaDOS partitions on the same drive? NetBSD is now assigning the sd?[defghijklmnop] partitions in the order they are located on the disk. This includes any non-NetBSD partitions. If you had an AmigaDOS partition on that disk, and the partition was located before the NBU\7 NetBSD partition, /dev/sd6d is going to be that AmigaDOS partition. Doing a newfs would then scramble the AmigaDOS partition. [XXX] {{ NetBSD assigns the /dev/sdX numbers by counting up all your attached SCSI {{ devices from SCSI ID 0 in order. For example, say your system has 3 SCSI {{ devices (note: IDE drives will show up as SCSI devices under NetBSD), {{ IDs 0, 3, and 4. These will now show up as sd0 (ID 0), sd1 (ID 3) and {{ sd2 (ID 4). Again, as in the example above, it is not the specific SCSI {{ ID which determines the /dev/sdX mapping, but the ORDER of the device ID's. {{ NetBSD simply maps the first device it finds to sd0, the second to sd1, {{ third to sd2, and so on. {{ {{ Write the ID to sd# mappings for your particular system down! If {{ your NetBSD partitions were on the SCSI drive at ID3 in the above {{ example, then your NetBSD system would be on /dev/sd1 - and you would {{ replace any references to /dev/sd0x with /dev/sd1x in the examples! [XXX] {{ same comments as above for all of these. Plus, there needs to be << a description of how minor device numbers map to partitions on a << device. Frankly, I have no clue as to what is going on there, 'cept << it looks like Xa is root and Xb is swap.. but suddenly the ADOS << partition is Xd and the usr partition becomes Xe? (where's Xc?) << Also, don't root and swap have to be on the same device in the << generic kernels? Some mention of that might be helpful... << [XXX] Example A4000/IDE Installation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ (or How Bill got NetBSD running on a an A4000/single IDE installation) You will need your 3.0 (or above) Commodore Installation diskettes. Backup anything important on your IDE drive, as it will be deleted. You will have 30M available on your IDE to hold the installation files, and your Workbench. Partition your harddrive with HDtoolbox: Select the IDE drive, and click on Partition drive. *WARNING* This is a permanent thing, so please make sure that if you have anything important, that you have backed it up on floppies or tape. Delete all your existing partitions (usually called Workbench and Work) on your IDE harddrive, by selecting a partition, and clicking on Delete Partition. [XXX] **> This seems rather drastic to do, unless you have no other space. I would suggest mentioning that the Work: partition could be broken into ones for NetBSD or an extra drive could be used. This avoids having to reinstall AmigaDOS. [XXX] The above will only work if you create yet another AmigaDOS partition, as the default Workbench partition is too small to hold the tar.gz files. Unless someone else comes up with a better way. - Bill [XXX] You will create 4 partitions. [XXX] Missing in the FAQ-Part of your install-guide is 'Cannot find suitable- rootfs'-error-message and surroundings (sync-flag or hdtoolbox). [XXX] 1st partition (AmigaDOS Boot Partition): Click New Partition. Click in the next free area. size = 30M Partition Device Name = Workbench_x.x (In BSD it will map to /dev/sd0d for this example) Adv. Options, Click on Change... Click File System: until you see Fast File System Turn ON Automount this partition, if it is not checked. Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option *) Click OK. * If you don't, you will not be able to mount the partition under NetBSD. [XXX] This makes it sound like if you don't have the option to set the file system block size, you can't mount the partition. I think you probably mean if you set the block size to something other than 512 you won't be able to mount it. [XXX] 2nd partition (NetBSD ROOT partition): Click New Partition. Click in the next free area. size = 15M Partition Device Name = BSDROOT (In BSD it will map to /dev/sd0a for this example) Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425207 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. 3rd partition (NetBSD SWAP partition): Click New Partition. Click in the next free area. size = (the size of your contigious FAST RAM) * 2 Partition Device Name = BSDSWAP (In BSD it will map to /dev/sd0b for this example) Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425301 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. 4th partition (NetBSD USR partition): Click New Partition. Click in the next free area. size = remaining free space on the IDE. (46 or more Megabytes) Partition Device Name = BSDUSER (In BSD it will map to /dev/sd0e for this example) Adv. Options, Click on Change... Click File System: until you see Custom File System Turn off Automount this partition, if it is checked. Identifier: 0x4e425507 Reserved Blocks, beginning: 0 (same for end) Make sure custom boot code is turned off. Leave File system block size at 512 (if you have this option) Click OK. Double check everything to make sure it's correct, then click on Save Changes to Drive. When you click Exit, your machine will not reboot. You will want to place the Install disk of the Commodore 3.0 (or above) Operating System, into your floppy, and install onto the BSDBOOT partition. You may need to boot off of the Workbench disk and Format the BSDBOOT partition, before Installing. ONCE YOU HAVE YOUR PARTITIONS SET UP ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Now, you need to get the required files on to the root directory of the AmigaDOS partition. Use a terminal program, tape drive, or copy them from another drive. Now you are ready to enter a new world. BOOTING INTO NETBSD ~~~~~~~~~~~~~~~~~~~ AmigaShell> gzip -d loadbsd.gz AmigaShell> gzip -d netbsd.gz AmigaShell> loadbsd -b netbsd It should boot up and ask you which device you wish to boot off of. Make sure the bootfloppy disk is in the drive, and enter: fd0 and press return. This will cause the NetBSD kernel to boot off of the boot floppy in DF0:. newfs /dev/sd0a (erase it, set it up for NetBSD) -- "newfs: ioctl(WDINFO): Invalid argument." This warning is ok, just ignore it. The Amiga doesn't write disk labels (and returns an error to indicate that the attempt to write the label did not suceed). Any changes to the disk "label" still have to be done through an RDB editor. -- newfs /dev/sd0e (erase it, set it up for NetBSD) mount /dev/sd0a /altroot (mount root) mkdir /altroot/usr (make usr dir) mount /dev/sd0e /altroot/usr (mount usr on sd0e or whatever) [XXX] **> The /mnt/xxxx path could be different if you did not put the NetBSD files in the root of the AmigaDOS partition. mount_ados /dev/sd0d /mnt (mount ados partition) cd /altroot (cd to newroot) tar -zxvf /mnt/netbsd.gz (extract kernel) tar --unlink -zxvpf /mnt/base.tar.gz (extract base) tar --unlink -zxvpf /mnt/etc.tar.gz (extract the rest of etc) ==== Optional |tar --unlink -zxvpf /mnt/comp.tar.gz (extract gcc and tools) |tar --unlink -zxvpf /mnt/games.tar.gz (extract games and fun stuff) |tar --unlink -zxvpf /mnt/man.tar.gz (extract man pages) |tar --unlink -zxvpf /mnt/misc.tar.gz (extract miscellaneous stuff) |tar --unlink -zxvpf /mnt/ext.tar.gz (extract text tools and docs) ===== cd /altroot (cd to the new root) tar -cf - /dev | tar -xvpf - (copy device files from floppy) /altroot/bin/sync (sync whatever for safety) /altroot/sbin/reboot (reboot system) You'll end up in AmigaDOS again, this time, type: loadbsd netbsd You'll end up in single-user mode, at which you can: mount -uw / (make root read/writeable) mount /dev/sd0e /usr (give us /usr/bin and /usr/sbin commands) cd /dev (need to clean up devs) MAKEDEV all (rebuild all of the devices) cd /etc (cd /etc) vi fstab (I hope you know how to use vi). [XXX] **> You could have preedited it on the AmigaDOS side and then copied it over. Or use cat like in the original NetBSD install documents. You will want to edit the fstab file to correctly represent your / and /usr devices, as well as uncomment and edit the swap. Once you save this, you should then be able reboot and then enter multiuser mode. /bin/sync /sbin/reboot Back to AmigaDOS loadbsd -a netbsd Back to NetBSD, this time, automatically entering multiuser mode. login: root (no password) You're in (hopefully). If all is well, then you should examine the other NetBSD-Amiga FAQs to set your system up. UPGRADING YOUR EXISTING NETBSD-0.9c SYSTEM ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Get the NetBSD tar.gz files onto a spare area on your system {place}. This also includes a tape drive, if you are going to use one. NO MORE ROOTFS.GZ. That's right. It's history. Just make sure that you have enough space [XXX] **> I have not actually found the RELEASE directory yet, so this question may be moot. What about the root bin and sbin? Where are the /usr bin, sbin and libs? Do NOT unarchive etc.tar.gz, unless you are prepared for system specific files to be nailed in /etc (group, passwd, etc). As root: cd / tar -zxf {place}netbsd.gz (extract kernel) tar --unlink -xvzpf {place}base.tar.gz (extract base) tar --unlink -zxvpf {place}comp.tar.gz (extract gcc and tools) tar --unlink -zxvpf {place}games.tar.gz (extract games and fun stuff) tar --unlink -zxvpf {place}man.tar.gz (extract man pages) tar --unlink -zxvpf {place}misc.tar.gz (extract miscellaneous stuff) tar --unlink -zxvpf {place}ext.tar.gz (extract text tools and docs) You will have to edit your fstab to denote the ID changes (if applicable). Use disklabel to make sure things are where you think they are. REPORTING PROBLEMS ~~~~~~~~~~~~~~~~~~ Basically the kernel diags (things like boot messages and register dumps after panics) are stored in the last page of memory. These messages survive reboot so that if you have to get at them you can. The utility of choice is dmesg. Which prints this memory out. Thus if you get a panic with a register dump, instead of copying it down by hand you can simply reboot and then redirect dmesg to a file. Chris. [send this edited information to the mailing list for help] SOME HELPFUL HINTS THROWN IN. MOST HAVE BEEN CUT FROM THE MAILING LIST ======================================================================= (names have been lost, but thanks to those who gave the answers to us) A few NetBSD-Amiga WWW servers do exist. The Main one is done by Matthias Kirschnick and includes links to other NetBSD information sites. Matthias Kirschnick's NetBSD-Amiga-page > Is there a NetBSD/Amiga Web server out there? If not, then I may be Try http://dusk.rz.uni-regensburg.de/. This is a A2000 running NetBSD, and there's also a section on NetBSD on this machine. ====================================================================== > Right - as distributed, /etc/ttys runs getty on the ite0 Amiga display, > rather than "console" which would go to the configured console device. Yes and this is correct. You should enable getty's on whichever devices you want them on. The console /dev/console should always be marked as *off* however. ====================================================================== >I see when I boot the kernel: >warning found rdb->secpercyl(1098) != rdb->nsectors(74) * rdb->nheads(15) >warning lp->d_sparespercyl(12) not multiple of lp->d_ntracks(15) This is fine, this is telling you that your RDB has some conflicting values. If the partitions mount under NetBSD, then it's safe to ignore them. If they don't, then use dmesg to copy the values down and give us a yell on the mailing list. ====================================================================== > TIMEZONE = 800, DST = 1 is what I > thought it should be for me (Portland, OR, +8 GMT), but it tells me that the > time under netbsd is 7 hours slower than what the Amiga side says... what am > I missing? The TIMEZONE and DST config options set something in the kernel data (at least I think the TIMEZONE does, but I'm not sure about DST - I think when I went looking, it was never referenced anywhere). The kernel doesn't do anything at all with that data. I think there's a something that needs to be set up in /usr/share somewhere that deals with the timezones. I've never done it, so my NetBSD time is the same as AmigDOS - but NetBSD considers that time value GMT, which can cause confusion at times. Also, I don't think the stuff in /usr/share is used until you go to multi-user, so the time would probably be reported differently in single user vs multi user mode. The clock read routine just gets the current time from the Amiga clock and uses that time as-is, with no adjustments. I had thought about adjusting it based on the TIMEZONE, but never got around to trying it. Trying to handle DST in the kernel isn't as easy to do. ====================================================================== From: spcmilo@hydra.spc.uchicago.edu (David Champion) Not knowing of any such utility already existing, I came up with this braindead rexx program to reset system time under ADOS to local so that I can keep the battmem time in GMT for BSD's sake. (Well, I like keeping GMT.) I call it from s:User-Startup, right after loading rexxmast: sys:rexxc/rx rexx:warpdate.rexx Obviously, there's much room for improvement, but it does the job well enough. Even without going into detail, it should probably take the GMT offset on the command line, and my offset should probably be negative, not positive. Oh well. Anyway, thought someone might want it. /* warpdate.rexx */ /* adjust current time so battclock can keep GMT */ /* CONFIGURE HERE */ /* number of minutes short of GMT */ off = 300 /* STOP CONFIGURING */ /* do not change day by default */ changeday = '' /* find minutes after midnight */ mins = time('m') /* adjust minutes */ mins = mins - off /* if we go back a day, adjust minutes and changeday flag */ if mins < 0 then do mins = 1440 + mins changeday = 'yesterday' end /* if we go ahead a day, adjust minutes and changeday flag */ if mins > 1439 then do mins = 1440 - mins changeday = 'tomorrow' end /* extract new hour from minutes; set minutes to minutes since hour */ hour = trunc(mins / 60) mins = mins - (hour * 60) /* update seconds */ tmp = time('m') secs = time('s') secs = secs - (tmp * 60) /* create an amigados 'date' command */ datestr = 'date 'changeday' 'hour':'mins':'secs /* and change the clock */ address command datestr [Hall of Fame deleted.] The Hall of Fame should be a seperate file. --- EOF --- -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 02:56:30 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, billc@iceCuBE.cryogenic.com Subject: Re: Revenge of the Install doc Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: William J Coldwell > Installing NetBSD-Amiga (4.4BSD) > August 7th, 1994 > Disk space: > ~~~~~~~~~~~ > 15M for root (/) (or more) > 2 * FAST RAM Megabytes for swap* (i.e., 8M system == 16M swap) > 45M for /usr (add 20M for sys-src, add 35M extra for X) (or more) > Full source (kernel(sys-src)+binaries) is >80MB. > > *On a 4M system, you might want more than 8M swap, since you will be > swapping all the time. This section is duplicated. The section about with this information has more details. > IMPORTANT: READ AND UNDERSTAND THIS, OR YOU WILL BE SORRY LATER > ~~~~~~~~~~ > Say your system has 3 SCSI devices (note: IDE drives will show up as SCSI > devices under NetBSD), IDs 0, 3, and 4. These will now show up as > sd0 (ID 0), sd1 (ID 3) and sd2 (ID 4). The higher the ID of the device is, > the higher sd will increment. Write the IDs to sd# down! If you NetBSD you => your > It should boot up and ask you which device you wish to boot off of. > Make sure the bootfloppy disk is in the drive, and enter: You should say how to un-DMS the bootfloppy disk.... > and press return. This will cause the NetBSD kernel to boot off of the boot > floppy in DF0:. Ummm, this is wrong. It should read "This will cause the NetBSD kernel to use the floppy disk for the root filesystem, giving you the initial UNIX commands that you will need to get your system up and running." > cd /altroot (cd to newroot) > tar -zxvf /mnt/netbsd.gz (extract kernel) This is still wrong. Just gzip -d the kernel. > As root: > cd / > tar -zxf {place}netbsd.gz (extract kernel) This is wrong also. Looks good other than above problems... -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 03:00:20 1994 Subject: IDE and SCSI From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu why do IDE drives show up as SCSI drives under NetBSD-amiga? Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 05:11:23 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Possible problem in m68k source sup on 8/7? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I don't believe this is Amiga specific, since our source tree hasn't changed since before the 4th (which was the last supscan), which is why I'm crossposting. Ok, so I've been doing this for a while now, and everything has been pretty smooth until today. I did a sup today and got the changes since Aug 4, and did a kernel build, and then started a full binary build. When it started to compile the /src/bin directory (cat, which is the first dir), it did the compile, then puked with a: groff: couldn't exec troff: Unknown error: 34072966 groff: couldn't exec grotty: Unknown error: 34072966 Argh.. now something as simple as pstat -s gives me malloc: Unknown error: 33999238 >From then on, it was downhill. I got complaints that /var/run//dev.tmp: Inappropriate file type or format when I rebooted (yes, with the double slashes)... so, I rebooted, made my altroot my primary, and everything was fine... until I did the make build for full binaries.. then again, the "problem" happened. So, my speculation is that the recent changes to the m68k library routines are causing a problem. I realize that this isn't a proper bug filing report, but I want to be sure that it's not just something _I've_ screwed up. Any suggestions? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 8 06:23:56 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Possible problem in m68k source sup on 8/7? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I don't believe this is Amiga specific, since our source tree hasn't changed since before the 4th (which was the last supscan), which is why I'm crossposting. Ok, so I've been doing this for a while now, and everything has been pretty smooth until today. I did a sup today and got the changes since Aug 4, and did a kernel build, and then started a full binary build. When it started to compile the /src/bin directory (cat, which is the first dir), it did the compile, then puked with a: groff: couldn't exec troff: Unknown error: 34072966 groff: couldn't exec grotty: Unknown error: 34072966 Argh.. now something as simple as pstat -s gives me malloc: Unknown error: 33999238 >From then on, it was downhill. I got complaints that /var/run//dev.tmp: Inappropriate file type or format when I rebooted (yes, with the double slashes)... so, I rebooted, made my altroot my primary, and everything was fine... until I did the make build for full binaries.. then again, the "problem" happened. So, my speculation is that the recent changes to the m68k library routines are causing a problem. I realize that this isn't a proper bug filing report, but I want to be sure that it's not just something _I've_ screwed up. Any suggestions? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 06:51:10 1994 From: John Kohl To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Possible problem in m68k source sup on 8/7? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Do these look like kernel addresses or valid pointers for the Amiga port? Somebody may be returning stack garbage rather than an error code: % printf "%x\n" 33999238 206c986 % printf "%x\n" 34072966 207e986 ==John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 07:42:35 1994 From: chopps@emunix.emich.edu To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Possible problem in m68k source sup on 8/7? <9408080144.AA01536@icecube.cryogenic.com> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu You need to update ld.so before the library. You had to be keeping very close with the sources to get it right. Sorry I didn't mention it. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 8 08:17:32 1994 From: John Kohl To: billc@icecube.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Possible problem in m68k source sup on 8/7? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do these look like kernel addresses or valid pointers for the Amiga port? Somebody may be returning stack garbage rather than an error code: % printf "%x\n" 33999238 206c986 % printf "%x\n" 34072966 207e986 ==John From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 8 09:57:57 1994 From: chopps@emunix.emich.edu To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Possible problem in m68k source sup on 8/7? <199408080407.AAA00263@kolvir.blrc.ma.us> X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu I recently fixed ld.so to preserve all registers (including scratch), as it should have been doing, when binding functions in shared libs This 1) worked around the bug in setjmp/longjmp and 2) removed the need for the extra code in syscalls that push error codes if shared libs. I don't know if this is causing the problems but I imagine it could therefore I suggesst trying to update ld.so before libc. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 22:43:26 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Kernel compilation To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 683 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Last week, I got the complete source tree for NetBSD from Dusk.uni-regensburg.de Sunday evening, I tried to recompile the kernel. So I configured a kernel and compiled it. After an hour or so, I had my own working kernel! And it compiled without any changes to the source tree on a previously installed NetBSD pre-release (from scratch) and did not even give any warnings! GREAT! :-)) Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 22:48:34 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Broken network driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I tried to compile a GENERIC kernel with 'NS' defined, and the if_ed.c code died at line 896. Since the comment above reads "... this is probably wrong...", the author is right. :-) -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 23:03:23 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: ADOSFS To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1022 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu This weekend, I tried to copy large files from an AmigaDOS partition to a NetBSD partition under NetBSD. The speed is very, very, very bad! :-((( The adosfs seems to seek through the whole file whenever a block is read. You can hear the drive stepping around and then there is a short write to the other drive with the NetBSD partition and afterwards the source drive is seeking again and so on... :-((( After half an hour I stopped the copying. To that time just 12MB of a 20MB file were copied. So I rebooted to AmigaDOS, wrote that stuff to my DAT and restored the DAT under NetBSD. This method was many times faster... which IMHO it shouldn't be! Is this about to be fixed? At the moment, the adosfs is barely usable. Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 23:12:38 1994 Subject: Re: Missing Columns episode 12768 - possible solution ? From: David Jones To: jshardlo@london.micrognosis.com (John Shardlow) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu [ Re: missing columns ] > I find it very interesting that the same problem exists on both > NetBSD and Linux yet I experience no problems with the display > when using AmigaOS. > > One of these days I'll get to the bottom of this....... > > John Has anyone done the obvious here? Can a debug msg be put into the kernel giving the physical address of the start of the frame buffer? (More precisely: start of each plane, plus interleave modulo) Then, using some kind of utility (I can provide you a very primitive one), read the relevant portion of /dev/mem. (Clear the screen, put some text in the upper left corner, then use the rest of the display to dump the first 256 bytes or so of memory.) The question: do the bit patterns in chip RAM correspond to what is displayed, or not? If not, is there any pattern to the mis-correspondance? I take it this is a stock 3000? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@torfree.net for latest Toronto Free-Net information Click me! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 8 23:19:16 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Tape drives, again... To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1116 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Today, I tried to access my Sankyo CP150E (QIC, 150MB) again. I tried different minors (0,4,8,12), but I always got something like: "... size must be between 0 and 512" (or so) This was when using 1.0-pre-release (installed from scratch). This tape drive worked perfectly with the old scsi drivers (Jan/Feb). My other tape drive is a WangTek 6200HS 4mm DAT drive. Under AmigaDOS using the BTN-tape-handler and tar, the drive transfers about 10MB/min (read or write), under NetBSD it only gives less than 2MB/min. :-(( It reads very slow and the tape has to start and stop very often... I am not sure now, but I think, under the old drivers, it was as fast as on the Amiga side... To check this, I will have to reinstall an old system. :-( (Or maybe Hubert Feyrer could check this as he has the same DAT, too? :-) Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 8 23:55:14 1994 From: jshardlo@london.micrognosis.com (John Shardlow) Subject: Re: Missing Columns episode 12768 - possible solution ? To: hamish@bnr.ca (hamish) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 998 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > jshardlo> This CHIP mem allignment sounds like it could be the > jshardlo> problem. Any one else using burst-mode RAM ? How can I > jshardlo> force allignment ? > > This is rather odd. On your A3000, there is no AGA hardware, so no > double-longword alignment should be required. > > In addition, under Linux/68k, I believe that all CHIPram allocations > are double-longword aligned, and I believe that the video code also > ensures that all bitplanes are double-longword aligned. > > Also, I don't think that the CHIP ram supports burst. Right, this may have been a red herring as Michael Hitch built me a special kernel for NetBSD which ensured that the chip memory was double-longword aligned in ECS modes and it still happens. We are looking at some other possibilities. I find it very interesting that the same problem exists on both NetBSD and Linux yet I experience no problems with the display when using AmigaOS. One of these days I'll get to the bottom of this....... John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 00:33:49 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Broken network driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 8, 7:30am, "Stephen J. Roznowski" wrote: > > I tried to compile a GENERIC kernel with 'NS' defined, and the > if_ed.c code died at line 896. Since the comment above reads > "... this is probably wrong...", the author is right. :-) Looks to me like "sc->sc_arpcom.sc_enaddr" should be "sc->sc_arpcom.ac_enaddr". Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 00:34:12 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Installation of release To: amiga@sun-lamp.cs.berkeley.edu (NetBSD) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1448 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Friday, I installed the 1.0-pre-release from scratch. Using the advices from the mailing list, it was pretty easy. I have just one simple suggestion. In the installation advice, you are told to newfs, mkdir, untar etc... It would be very nice if this could be put into a script on the boot floppy. Now, there is only one problem: nearly everyone has a different configuration and wants different things to be installed. How could this be solved? I would do it like that: I would format the boot floppy using the old file system which is compatible to BFFS (correct???), supply a mountlist entry for the floppy using BFFS and put that along with BFFS to the distribution. Now, all a user has to do is: mount the floppy under AmigaDOS, edit the installation script according to his/her configuration, "loadbsd -b netbsd", enter fd0 and execute the batch file which will do everything else. So nobody has to remember all the right steps and type everything from hand, which (e.g. in my case) takes longer because of typos... :-) (Avoiding typos is difficult is you are used to another keyboard layout and have to use the american for installation...) Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 00:36:36 1994 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.327:08.07.94.15.44.36] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Missing Co... From: "hamish (h.i.) macdonald" To: jshardlo@london.micrognosis.com Cc: amiga@sun-lamp.cs.berkeley.edu Subject: re:Missing Columns episode 12768 - possible solution ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>> To cut a long story short, Linux also suffers from the exact same >>> problem on my A3000. >>> >>> Two questions: >>> >>> 1) Is it possible to make Linux run the console on the serial >>> port ? (I have a VT 220 on the serial port) >> >> There still is no serial driver, I think. >> >>> 2) Has any Linux user seen this problem and know of a cure for it ? >> >> Which video mode are you using? Try some other mode. >> >> While I was implementing the new AGA modes, I got about the same problem (it >> had something to do with Chip memory alignment) and I tuned everything 'till >> it worked fine on my A4000. > Sounds the like the 'problem' with the AGA chipset, when running > burstmode on the bitplanes. Then the bitplanes has to be double > longword alligned. >>>>> On Thu Aug 4 13:08:00 1994, >>>>> John Shardlow wrote: jshardlo> This CHIP mem allignment sounds like it could be the jshardlo> problem. Any one else using burst-mode RAM ? How can I jshardlo> force allignment ? This is rather odd. On your A3000, there is no AGA hardware, so no double-longword alignment should be required. In addition, under Linux/68k, I believe that all CHIPram allocations are double-longword aligned, and I believe that the video code also ensures that all bitplanes are double-longword aligned. Also, I don't think that the CHIP ram supports burst. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 00:45:45 1994 From: Paul Kranenburg To: current-users@sun-lamp.cs.berkeley.edu, thomas@mathematik.uni-Bremen.de Subject: Re: Subtle problem with ld -r option and pic object files Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The problems seems to be that during the "ld -x -r" > some relocations in the object file are turned from "global" to "local" > relocations Do you have an example of an object file that is maltreated? -pk From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 01:04:33 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: 1.0-pre-release To: amiga@sun-lamp.cs.berkeley.edu (NetBSD) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1259 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Having installed the pre-release this weekend, I now have some questions. After login you are prompted for terminal emulation [vt200]. When choosing vt200, the cursor jumps to beginning of the line in the middle of the screen and doesn't clear the display... What can be done to avoid this? If you choose vt100, the cursor goes to the next line and everything seems to be ok. But scrolling is much slower (using e.g. vi). I suppose, this is the nature of the emulation (vt100 does not offer fast display options). I have added a new group to /etc/group and also added a new user with vipw who belongs to that group ("users"), but also to wheel. When I log in using this user, I get a message "don't login as root, use su instead." What has to be changed here? Last question: has anyone successfully compiled bash for the new release? If so, could the whole archive be uploaded to NetBSD-Amiga? Thank you for your work --- and your patience with me! :-)) Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 01:13:57 1994 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.458:08.07.94.20.02.23] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Missing C... From: "hamish (h.i.) macdonald" To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Missing Columns episode 12768 - possible solution ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Mon Aug 8 15:26:00 1994, >>>>> John wrote: jshardlo> I find it very interesting that the same problem exists on jshardlo> both NetBSD and Linux yet I experience no problems with the jshardlo> display when using AmigaOS. Datapoint: No-one other than John has complained about this problem in Linux/68k. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 01:14:31 1994 From: rhealey@aggregate.com Subject: NetBSD and Solaris/AIX NFS mounting To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 524 Sender: owner-current-users@sun-lamp.cs.berkeley.edu How do you get a NetBSD system to be able to mount a Solaris or AIX server? I've tried using the -P option and a few other combinations on both m68k NetBSD and x86 NetBSD with now luck. On both NetBSD arch's I get a: nfs: can't access /export/home: Address already in use I thought the -P option would take care of this but it doesn't. Strangely enough NetBSD DOES mount UNIXware NFS filesystems even though UNIXware and Solaris are both SVR4 systems. What gives? What's the magic incantation needed? -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 01:25:41 1994 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.529:08.07.94.14.32.52] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: forwarded... From: "hamish (h.i.) macdonald" To: mw@eunet.ch Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: forwarded message from Jukka Forsgren Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> I wrote: hamish> If you write 1K starting at (end-of-chunk-1K), then the DMA hamish> controller will attempt to read past (end-of-chunk) in order hamish> to fill the FIFO (since the DMA controller was just told to hamish> write to the SCSI chip, not told to write 1K). >>>>> On Sat Aug 6 04:18:00 1994, >>>>> Markus wrote: mw> If you suspect that this behavior could give you problems (I'd say mw> that's VERY unlikely, because having unvalid pages after valid mw> pages shouldn't be that rare?), set the word-xfer register too in mw> dmago(), and see whether the problem goes away. Problem (I think) mw> is, the GVP DMA controller doesn't have such a register, or nobody mw> found it yet. I *know* that this sort of scenario caused a problem with Linux/68k, when it was using the NetBSD WD33C93 driver. Someone had debugging on, and showed that when a 1K DMA request was made on the last 1K of physical fast ram, the whole machine locked up. As I pointed out, I don't think that this will be a problem with NetBSD as long as it uses only the one physical memory chunk, but it *could* be a problem in future. My explanation was just my guess as to why it is happening, and it seems reasonable to me. I'll reiterate it here: If you don't set the terminal count register of the DMA controller, then during DMA-out, the DMA controller will continue feeding data to the SCSI controller as long as the SCSI controller asks for it. The WD33C93 SCSI controller will ask for data until its FIFO is full. During a DMA-out of the last N bytes of physical memory, this filing of the FIFO (over and above the N bytes that the SCSI controller writes out) will result in the DMA controller attempting to read *past* the end of physical memory. This results in a bus lockup. Your suggestion to set the word-xfer register to see whether the problem goes away is a good one, but I don't need this in Linux/68k, as it already detects and avoids this situation. I was just pointing out a possible problem with NetBSD, when I saw a number of people reporting random lockups. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 01:52:41 1994 From: bad@flatlin.ka.sub.org (Christoph Badura) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet Options (was: INTEL ETHERNET COMPATIBILITY QUESTION?) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Randy Terbush writes: >You might also want to consider the TNIC-1500 that is available through >South Coast Computing. (I don't have contact information on this machine) >This is an ISA solution that is a Lance based card that uses DMA (if I >remember the specifics correctly). It has been benchmarked slightly faster >on reads than the 3c509, on BSDI. There are drivers available from the >supplier last I heard. It may also work with our new Lance drivers? The TNIC-1500 is based on an enhanced version of the Lance chip. The enhancement is that the card does _busmaster_ DMA. Apparently the card works well with a 1542 busmaster but doesn't work equally well with a second TNIC as busmaster--there's some performance loss. I don't expect it to work with a normal Lance driver as the card as no local RAM to buffer packets. Steve Nuchia has been very helpfull in answering questions. I believe he also mentioned NetBSD drivers a year ago or so. -- Christoph Badura bad@flatlin.ka.sub.org Home +49 721 606137 Work +49 228 97024-45 Es genuegt nicht, keine Gedanken zu haben; man muss auch unfaehig sein, sie auszudruecken. - Karl Kraus From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 02:21:54 1994 From: Thomas Eberhardt Subject: Subtle problem with ld -r option and pic object files To: current-users@sun-lamp.cs.berkeley.edu (netbsd-current-users) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1237 Sender: owner-current-users@sun-lamp.cs.berkeley.edu There seems to be a subtle problem with the -r option of ld(1) and pic object files: I had some fun this weekend with an X application which uses the Xt library (which I had built, as all my other shared libraries, with first compiling, then "ld -x -r" on the object files and finally "ld -x -Bshareable ..."). The problems seems to be that during the "ld -x -r" some relocations in the object file are turned from "global" to "local" relocations and this is asking for trouble when a program that uses a shared library built this way causes some of the shared library data items to be flagged for "run-time copy" since references to these items from inside of the shared library (i.e. in the same object file that also defines the item) point to the shared library copy and not the run-time copy after run-time linking! Running the same application with a shared Xt library built without "ld -x -r" works just fine. -- / Thomas Eberhardt \ Moo! (__) | Center for Complex Systems and Visualization (CeVis) |_________/--------(oo) | University of Bremen, FB 3, Bibliothekstr. 1 | * |______||\/ \_o_ D-28359 Bremen, Germany, FAX: +49 421 218-4236 _o_/ ^^ ^^ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 02:22:33 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Mon, 8 Aug 1994 18:51:00 -0400 (EDT) Subject: Re: 1.0-pre-release To: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Cc: amiga@sun-lamp.cs.berkeley.edu (netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1070 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Previously, Tobias Abt wrote: > > I have added a new group to /etc/group and also added a new user with > vipw who belongs to that group ("users"), but also to wheel. When I > log in using this user, I get a message "don't login as root, use su > instead." What has to be changed here? That message is in root's .login, so check there. > Last question: has anyone successfully compiled bash for the new > release? If so, could the whole archive be uploaded to NetBSD-Amiga? Yes .. 1.14.1 It has fixed the setjmp bug that 1.14 had in it. You can get the source from crazytrain.catt.ncsu.edu:/pub/src/bash-1.14.1.tar.gz > Thank you for your work --- and your patience with me! :-)) Well, I don't do any work, except compile the hell out of some stuff. :) later, Chris -- Chris Mattingly | Computer and Technologies Theme Program, NCSU, Raleigh 406-G Wood Hall | Head System Administrator PO Box 21541 | NCSU | Home computer: A3000 - crazytrain.catt.ncsu.edu Raleigh, NC 27607 | (919) 512-0931 | Email: Chris_Mattingly@ncsu.edu From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 03:36:22 1994 From: "Manfred Bathelt (CIP 92)" Subject: Screen trouble installing BSD To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 794 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Today I tried to install NetBSD-Amiga 1.0b on my A4000/40 (on slave IDE-drive) and can`t decrypt the screenoutput. I`ve an NEC 4FG (VGA) and an old PAL monitor, both unable to display the NTSC installation Screen :-( I tried loadbsd-2.9 -bA netbsd to get an AGA mode, but nothing changed. Is there anyone, who could compile/upload an VGA/AGA or PAL kernel, or who can describe me how to create it by myself ??? I know I schould buy me a Scandoubler, but money... Manfred -- *===========================================================================* * Manfred Bathelt, student at FAU Erlangen * * Internet: mdbathel@cip.informatik.uni-erlangen.de * * WWW: http://wwwcip.informatik.uni-erlangen.de/user/mdbathel * From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 04:56:39 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: PCI support Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've added generic PCI autoconfiguration support to the i386 port. This leverages many things off the existing code, including the simple high-level autoconfig scheme, and the simple method of IRQ sharing. I'll be adding the NCR 53c8XX driver as soon as I check out the latest version. Unlike previous versions, it's supposed to have redistribution conditions (as well as my work to port it and clean up a couple of things.) I've tested this code, and it works, but your milage may of course vary. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 05:47:12 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Broken network driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) > > On Aug 8, 7:30am, "Stephen J. Roznowski" wrote: > > > > I tried to compile a GENERIC kernel with 'NS' defined, and the > > if_ed.c code died at line 896. Since the comment above reads > > "... this is probably wrong...", the author is right. :-) > > Looks to me like "sc->sc_arpcom.sc_enaddr" should be > "sc->sc_arpcom.ac_enaddr". We have a winner.... This fixes the first problem, and now the following remains: ld -x -n -T 0 -o netbsd -e start ${SYSTEM_OBJ} vers.o if_x25subr.o: Undefined symbol `_setsoftnet' referenced from text segment if_eon.o: Undefined symbol `_setsoftnet' referenced from text segment ns_ip.o: Undefined symbol `_setsoftnet' referenced from text seg setsoftnet() is defined (virtually identically) in the following files: /sys/net/netisr.h /sys/arch/amiga/include/mtpr.h /sys/arch/amiga/include/cpu.h -SR From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 07:32:33 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: crash dump on i386 wd0? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does crash dumping work on the i386 current bits on an IDE disk? I tried forcing a dump last night, and after it slooooowly wrote out the image, savecore claimed the image was bogus (no matching magic number). Has anybody gotten a good dump recently? ==John From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 08:11:34 1994 Subject: upgrade to 1.0 From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I'm getting ready to upgrade to 1.0 (finally) and will have things installed this week if things go well. I checked out the boot floppy to see how things are being done now. I noticed that you can only choose fd0 but not fd1. The startup messages dont even show fd1 as a device. I also noticed that my fd0 is no longer working :) so I had to rip open my machine and switch drives to get the boot floppy working. Why not just have both floppies compiled in the kernel? Ok.. so I get the boot floppy running and try to mount my old partitions. I realize that NetBSD still only looks at the first SCSI controller. Argh.. so I had to patch my loadbsd to switch config devices 0 and 1 which are my two SCSI cards so that the second card is used by NetBSD. Why cant NetBSD use all the SCSI cards? Well those were the only problems I've had.... looks like a nice way to install NetBSD... congrats and thanks all... Tim N. (btw.. can I get diffs for non-contig memory handling with the new kernels from someone who has already got it up and running?) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 10:09:09 1994 From: mycroft@gnu.ai.mit.edu To: bad@flatlin.ka.sub.org, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet Options (was: INTEL ETHERNET COMPATIBILITY QUESTION?) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm told that the TNIC-1500 is based on the PCnet-ISA chip. Before the PCnet-ISA chips, many boards already did bus-mastering DMA. The main difference is that the newer chip is highly integrated. It sounds like it should be really easy to make it work with the `le' driver. Again, if someone sends me docs and/or a board I'll look at it. Alternatively, someone else can do it and ask me questions as needed. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 12:20:03 1994 From: jshardlo@london.micrognosis.com (John Shardlow) Subject: Re: Missing Columns episode 12768 - possible solution ? To: dej@eecg.toronto.edu (David Jones) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 980 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > [ Re: missing columns ] >Has anyone done the obvious here? > >Can a debug msg be put into the kernel giving the physical address of the start >of the frame buffer? (More precisely: start of each plane, plus interleave >modulo) Then, using some kind of utility (I can provide >you a very primitive one), read the relevant portion of /dev/mem. >(Clear the screen, put some text in the upper left corner, then use the rest >of the display to dump the first 256 bytes or so of memory.) > >The question: do the bit patterns in chip RAM correspond to what is displayed, >or not? If not, is there any pattern to the mis-correspondance? > >I take it this is a stock 3000? Yes, its a stock A3000 (Soft-Kickstart) with 16M FAST RAM and 2M CHIP. It had the same problem before I expanded the FAST mem though. I'm not really up to the kernel hacking mentioned above but if someone can provided me with the test program then I will run it and post the results back to you. John From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 14:47:30 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: libexec/ftpd/Makefile patch for Kerberos compile Sender: owner-current-users@sun-lamp.cs.berkeley.edu *** Makefile.orig Tue Aug 9 05:22:56 1994 --- Makefile Tue Aug 9 05:23:19 1994 *************** *** 15,20 **** --- 15,21 ---- CFLAGS+= -DKERBEROS LDADD+= -lkrb -ldes DPADD+= ${LIBKRB} ${LIBDES} + SRCS+= klogin.c .endif .include From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 15:30:05 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/gnu/usr.bin/ld/rtld/rtld.c U src/gnu/usr.bin/tar/Makefile U src/gnu/usr.bin/tar/tar.1 U src/share/man/man4/man4.i386/rtfps.4 U src/sys/arch/hp300/hp300/conf.c U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/isa/aha1742.c U src/sys/arch/i386/isa/aic6360.c U src/sys/arch/i386/isa/com.c U src/sys/arch/i386/isa/rtfps.c U src/sys/arch/i386/pci/README U src/sys/arch/i386/pci/pci.c U src/sys/arch/i386/pci/pci_machdep.c U src/sys/arch/i386/pci/pci_machdep.h U src/sys/arch/i386/pci/pcireg.h U src/sys/arch/i386/pci/pcivar.h U src/usr.bin/ipcrm/ipcrm.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Aug 9 03:39:10 1994 SUP Scan for current completed at Tue Aug 9 03:42:01 1994 SUP Scan for mirror starting at Tue Aug 9 03:42:02 1994 SUP Scan for mirror completed at Tue Aug 9 03:44:32 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 16:23:14 1994 From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: upgrade to 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Tim" == Tim Newsham writes: Tim> (btw.. can I get diffs for non-contig memory handling with the Tim> new kernels from someone who has already got it up and running?) I'll send it to you this evening, or maybe even the list as it's not that large. Niklas From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Aug 9 17:02:29 1994 From: "Alan Bair" X-Mailer: Z-Mail (3.0.0 15dec93) To: amiga-x@sun-lamp.cs.berkeley.edu (Amiga NetBSD - X) Subject: Retina Z3 support status Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I know the Retina Z2 is supported by the current X servers and seem to remember that work was under way for the Z3. However, before I buy the Z3 I wanted to determine if there was or will be support for it. So, will the current Z2 server work on the Z3? Has a Z3 server been released? Does either of them work with the 1.0 release? Thanks, -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 PH (512) 891-2336 abair@amcu-tx.sps.mot.com FAX (512) 891-3348 From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 18:04:08 1994 From: niklas@appli.se (Niklas Hallqvist) To: current-users@sun-lamp.cs.berkeley.edu Subject: Handshaking on input overflow Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm having problems with input overflows generating all sorts of peculiarities, so I took a look at the source. There were some strange things in there I'd like to ask about: /* * Send stop character on input overflow. */ static void ttyblock(tp) register struct tty *tp; { register int total; total = tp->t_rawq.c_cc + tp->t_canq.c_cc; if (tp->t_rawq.c_cc > TTYHOG) { ttyflush(tp, FREAD | FWRITE); CLR(tp->t_state, TS_TBLOCK); } /* * Block further input iff: current input > threshold * AND input is available to user program. */ if (total >= TTYHOG / 2 && !ISSET(tp->t_state, TS_TBLOCK) && !ISSET(tp->t_lflag, ICANON) || tp->t_canq.c_cc > 0 && # Shouldn't the disjunction above be parenthesized? tp->t_cc[VSTOP] != _POSIX_VDISABLE) { # This test ought to be combined with ISSET(tp->t_iflag, IXOFF), no? # It would also seem it ought to be moved into the conditional below # as the test is irrelevant for CHWFLOW cases if (putc(tp->t_cc[VSTOP], &tp->t_outq) == 0) { SET(tp->t_state, TS_TBLOCK); ttstart(tp); } /* try to block remote output via hardware flow control */ if (ISSET(tp->t_cflag, CHWFLOW) && tp->t_hwiflow && (*tp->t_hwiflow)(tp, 1) != 0) # Is it correct that t_hwiflow() should return non-zero on success? SET(tp->t_state, TS_TBLOCK); } } I haven't seen any serial devices supporting t_hwiflow, so I suspect the code for controlling input via hw is untested, which makes the possible bugs above understandable. 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 From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue Aug 9 19:06:03 1994 From: Donn Cave X-Sender: donn@saul2.u.washington.edu Subject: Re: Retina Z3 support status To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1938 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Alan Bair asks: | I know the Retina Z2 is supported by the current X servers and seem to | remember that work was under way for the Z3. However, before I buy the | Z3 I wanted to determine if there was or will be support for it. So, will | the current Z2 server work on the Z3? Has a Z3 server been released? Does | either of them work with the 1.0 release? The current kernel support for the Z3 went in back in June. A month or two before, Markus Wild had put some server code out on eunet, in the ``experimental'' directory. (And kernel modifications, including the driver code from Lutz Vieweg that is the basis for the current driver.) That experimental server code compiled for me without any serious modifications. I compiled it with X11R6. It's not perfect, but the flaws are not serious, at least not so serious that I was motivated to fix them. The only two that come to mind are a square black rectangle that appears on the screen when the mouse runs into the edge of the screen, and it consistently core dumps on exit. It's reasonably fast, and Lutz apparently has ideas about how it could be speeded up, although at present I don't think he's working on it. It pans across some rather large region, so it's kind of weird to use with fvwm (I use twm). The source has a 16 bit mode, but I built only the 8 bit. Since then, a little disk adventure took that stuff off-line, and I haven't gotten around to restoring it from tape. Nor have I gotten around to trying out the much-heralded 1.0. I'm pretty sure that the two would get along OK, certainly if recompiled. It may be a while before anyone ``releases'' a server, but there's source. I haven't seen the Z2 Retina in action, so I can't say whether there's much difference in speed. I can sure testify that the Retina (probably either one) is an big step up from the current Amiga custom chips display, especially with X. Donn Cave, donn@cac.washington.edu From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 20:22:56 1994 From: Paternostro Ugo To: amiga@sun-lamp.cs.berkeley.edu Subject: Novice questions on NetBSD X-Sun-Charset: US-ASCII Content-Length: 4970 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! First of all, thanks for all the work you are doing, it's simply great! After four successful installations of NetBSD (744, 0.9, 0.9C and this one), it seems that my system is starting to work... :-) I'm running 1.0 BETA (GENERIC), and had the pleasure to see the CD-ROM mounted and the tape working... well, almost... :-) I have a few questions for you gurus out there, and I hope someone can help me: 1) in 1.0 BETA distribution there is no man page for tar. Is this a bug or a feature ? 2) where can I find current sources to build my kernel ? How updates are distributed ? (Yep, a FAQ... :-) 3) how can I monitor console messages under X ? "xconsole -f /dev/ttye0" is not working here, nor "xterm -C". 4) is there a man page or a readme or something like that that explains loadbsd 2.9 options ? 5) tar+st0+Viper 150 = kaboooom... (read on please, that's important) The first points do not need more words, but the last does: it seems that tar has problems when reading from rst0 (or nrst0 or every raw tape device). It's writing perfectly, in fact everything works if I write under NetBSD and read under AmigaOS, via BTN-Tape; indeed, when reading from rst0, it misses two characters at the end of each block, but it reads right datas from st0. You know, this is driving me mad... Here is my config: ----------------------------------------------------------------------------- NetBSD 1.0_BETA (GENERIC) #1: Thu Jul 28 00:22:40 EDT 1994 chopps@tea.gnu.ai.mit.edu:/local/src/sys/arch/amiga/compile/GENERIC Amiga 4000 (m68040 CPU/MMU/FPU) real mem = 8388608 (1024 pages) avail mem = 6512640 (795 pages) using 64 buffers containing 524288 bytes of memory memory segment 0 at 07800000 size 00800000 memory segment 1 at 00200000 size 00200000 memory segment 2 at 00000000 size 00200000 mainbus0 (root) clock0 at mainbus0: system hz 100 hardware hz 709379 ser0 at mainbus0: input fifo 512 output fifo 32 par0 at mainbus0 kbd0 at mainbus0 grfcc0 at mainbus0 grf0 at grfcc0: width 661 height 460 colors 4 ite0 at grf0: rows 57 cols 82 repeat at (30/100)s next at (5/100)s has keyboard fdc0 at mainbus0: dmabuf pa 0x1ccf88 fd0 at fdc0: 3.5dd 80 cyl, 2 head, 11 sec [9 sec], 512 bytes/sec idesc0 at mainbus0 scsibus9 at idesc0 idesc0 targ 0 lun 0: SCSI2 direct fixed sd0 at scsibus9: 124MB, 1001 cyl, 15 head, 17 sec, 512 bytes/sec idesc0 targ 1 lun 0: SCSI2 direct fixed sd1 at scsibus9: 406MB, 826 cyl, 16 head, 63 sec, 512 bytes/sec ztwobus0 at mainbus0: mem 0x02bfc000-0x02dfbfff atzsc0 at ztwobus0 rom 0xe90000 man/pro 514/3 bounce pa 0xd6c000: dmamask 0xffffff scsibus2 at atzsc0 atzsc0 targ 0 lun 0: SCSI2 direct fixed sd7 at scsibus2: 100MB, 1219 cyl, 4 head, 42 sec, 512 bytes/sec atzsc0 targ 4 lun 0: SCSI1 sequential removable st0 at scsibus2: rogue, density code 0x0, 512-byte blocks, write-enabled atzsc0 targ 5 lun 0: SCSI2 readonly removable cd0 at scsibus2: cd present, 302882 x 2048 byte records zthreebus0 at mainbus0 2 mice configured 10 views configured ----------------------------------------------------------------------------- and here're my nodes: ----------------------------------------------------------------------------- crw-rw-rw- 1 root operator 20, 7 Aug 8 10:55 /dev/enrst0 brw-rw-rw- 1 root operator 5, 7 Aug 8 10:55 /dev/enst0 crw-rw-rw- 1 root operator 20, 6 Aug 8 10:55 /dev/erst0 brw-rw-rw- 1 root operator 5, 6 Aug 8 10:55 /dev/est0 crw-rw-rw- 1 root operator 20, 5 Aug 8 12:53 /dev/nrst0 brw-rw-rw- 1 root operator 5, 5 Aug 8 10:55 /dev/nst0 crw-rw-rw- 1 root operator 20, 4 Aug 8 12:52 /dev/rst0 brw-rw-rw- 1 root operator 5, 4 Aug 8 10:55 /dev/st0 ----------------------------------------------------------------------------- Thanks for reading this message, and sorry for my English! Bye, UP -- +-------------------------------+---------------------------------------------+ | Ugo Paternostro | | +-------------------------------+ Work: Dipartimento di Sistemi e Informatica | | Home : P.zza Cannicci, 2 | Via di Santa Marta, 3 | | 50018 SCANDICCI (FI) | 50139 FIRENZE (FI) | | Italy | Italy | | Voice: +39-55-252115 | Voice: +39-55-4796365 | | Fax : +39-55-254042 | | | EMail: ugo@glub.adsp.sub.org | EMail: paterno@aguirre.ing.unifi.it | | 2:332/112.3@fidonet.org +---------------------------------------------+ | 39:102/503.3@amiganet.ftn | All opinions are mine, mine, only mine! :-) | +-------------------------------+---------------------------------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 20:57:31 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Duplicated packets To: trainini@inf.ufrgs.br (Paulo Ricardo Silveira Trainini) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 362 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Paulo Ricardo Silveira Trainini wrote: > I have installed netbsd and connect him with a net. The problem is the packets that send > to router are duplicated. Who can help me? ( I already tried FAQ and news without sucess ) What line corresponds to the ifconfig for the command? Make sure the destination is set correctly. Ron From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 20:58:28 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: sd7-9" (Aug 3, 8:29pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 3, 8:29pm, "Stephen J. Roznowski" wrote: > Okay, now I have another complaint. :-) Why only 10 devices and > not 16 being created by default? > > I'd like to see /dev/MAKEDEV updated to make all 16 when "std" is done, > please. While the makers of the release version are at it, please add /dev/reboot to the /dev/MAKEDEV - in my 21.7-release this one was missing. Another 'bug' was, that /etc/ttys has an entry for Retina-Console - i don't have a Retina, which yields into annoying error messages on the console. Took a time for me to realize it was the entry in ttys. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 21:01:21 1994 To: etxpihl@etxb.eua.ericsson.se (Tomas Pihl ETX/B/DG) Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Suggestion for distribution From: Guenther Grau Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, > Hi, > > I've been on the list for some month and this weekend I finally > decided to try out the pre-release of NetBSD. Most of you gurus > have nice streamers where you have the distribs so you can easily > hook it up to your Amiga an un-tar it, but for me and perhaps > others who has to copy everything to floppy (1.44Mb), it's a > real pain to re-tar the tar-files to fit a floppy. There is no need to gunzip/untar/re-tar/gzip -9 things. Just use split or even better gsplit from gnu. Get the file, split it into parts (e.g. give the size -b 1450000). Reading the man page should make it clear how to work with it. Write the parts on the Floppies using the mtools (ms-dos file-utils under unix). Merge the files together again (of course in the correct order) with cat (or with join on the ADos-side. What I do suggest though, is a floppy-distribution for the complete system, including the most frequently used goodies, like tex, emacs, X ... I would have done it already, if I hadn't had these exams coming nearer and nearer :-( I tested the installation of Linux and I liked this very much. This helps to keep things simple (installing AND uninstalling). I think we can do at least the same thing with NetBSD. Guenther From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 22:00:05 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: markus@techfak.uni-bielefeld.de (Markus Illenseer), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sd7-9 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 9, 7:09pm, Markus Illenseer wrote: > While the makers of the release version are at it, please add /dev/reboot > to the /dev/MAKEDEV - in my 21.7-release this one was missing. That's because there isn't a /dev/reboot - it's /dev/reload, and it looks like that is in MAKEDEV. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 9 22:18:02 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Broken network driver" (Aug 8, 10:46pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Broken network driver Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 8, 10:46pm, "Stephen J. Roznowski" wrote: > We have a winner.... This fixes the first problem, and now the > following remains: > > ld -x -n -T 0 -o netbsd -e start ${SYSTEM_OBJ} vers.o > if_x25subr.o: Undefined symbol `_setsoftnet' referenced from text segment > if_eon.o: Undefined symbol `_setsoftnet' referenced from text segment > ns_ip.o: Undefined symbol `_setsoftnet' referenced from text seg > > setsoftnet() is defined (virtually identically) in the following files: > > /sys/net/netisr.h Most important place. > /sys/arch/amiga/include/mtpr.h > /sys/arch/amiga/include/cpu.h I had the same problem. I believe the cause is ISO-networking. If i disable the option in the config-file, the above errors are gone. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 9 22:38:13 1994 From: slotta@viper.ELP.CWRU.Edu (Douglas Slotta) Subject: XServer for the Picasso. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 221 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am about to pick my PicassoII up from the store tonight, and I was really hoping to see X in 256 colors. What's the latest word on the project? Could you use a beta tester? Thanks, Douglas slotta@viper.elp.cwru.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 9 23:04:15 1994 From: vdlinden@fwi.uva.nl (Frank van der Linden) X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: current-users@sun-lamp.cs.berkeley.edu Subject: bug in msdosfs Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I think there's a bug in the msdosfs handling of rename(). See the script below for an example. I'll try to come up with a fix myself, time permitting. Onno van der Linden c/o vdlinden@fwi.uva.nl (Frank van der Linden) Script started on Tue Aug 9 19:45:51 1994 sheep# cd /dos/dl sheep# ls aix* -rwxr-xr-x 1 root wheel 6008 May 22 14:24 aix.bug -rwxr-xr-x 1 root wheel 1742 May 21 18:56 aix.fix sheep# mv aix.fix aix.ok sheep# ls -al aix* -rwxr-xr-x 1 root wheel 6008 May 22 14:24 aix.bug -rwxr-xr-x 1 root wheel 1742 May 21 18:56 aix.fix -rwxr-xr-x 1 root wheel 13209 Aug 9 20:04 aix.ok sheep# ls -al | egrep 13209 -rwxr-xr-x 1 root wheel 13209 Aug 9 20:04 aix.ok Script done on Tue Aug 9 19:47:08 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 10 00:10:31 1994 From: James Melin Subject: Re: XServer for the retina and Novice stuff To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Tue, 9 Aug 1994, Douglas Slotta wrote: > I am about to pick my PicassoII up from the store tonight, and I was > really hoping to see X in 256 colors. What's the latest word on the > project? Could you use a beta tester? This made me think of the retina board I have in my A2K. Will there be device support for the Retina? Also, since I don't have an MMU on my machine (yet) I cannot alas, run NetBSD (if my understanding is correct), so I am looking for the linux port to see if that will get me by until such time as I can get a better CPU card. (anyone with an 030/882 w MMU and some RAM wanting to sell let me know (: ) What I am wondering specifically is, will linux/NetBSD support the Retina gfx card so that I can run Xwindows et al? And secondly, is the Linux 1.0 beta available to test? If so, where can I find it (have not been able to latch onto it. Archie is broken over here at the moment) and how do I grab it if I find it? Thanks for indulging me a bit. James Melin (sunrise@winternet.com) From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 10 00:38:27 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: hamish@bnr.ca Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Missing Columns episode 12768 - possible solution ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Datapoint: No-one other than John has complained about this problem > in Linux/68k. Yes. I'm also the only person who has seen it in NetBSD. This may point to a hardware problem but there is no problem with AmigaOS (1.3/2.0/3.1) and some older NetBSD kernels also did not suffer from it. The investigation is continuing with much appreciated help from Michael Hitch. John +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAi3utxYAAAEEAK7VSevj5fswEy8Ooz7BoMgR5AwOUUrR5yWZvCiE7dB7ds/K Y7zMDvU7qDpInWeJouMJkP5G3zD6x+3Uv4s62RmDOBskled4UZbsLYwOtQn2aZxA 6tNDPy7NnuJDJdnuwJnncmJASED8ttz6G9y01tYUe/JCbhhh/ujrAAF+E35dAAUR tCtKb2huIEouIFNoYXJkbG93IDxqb2huQGljZWJlcmcuZGVtb24uY28udWs+ =Qz1o -----END PGP PUBLIC KEY BLOCK----- From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 10 00:48:32 1994 From: "Alan Bair" "Re: XServer for the retina and Novice stuff" (Aug 9, 4:19pm) X-Mailer: Z-Mail (3.0.0 15dec93) To: James Melin , amiga@sun-lamp.cs.berkeley.edu Subject: Re: XServer for the retina and Novice stuff Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 9, 4:19pm, James Melin wrote: > Subject: Re: XServer for the retina and Novice stuff > > > On Tue, 9 Aug 1994, Douglas Slotta wrote: > > > I am about to pick my PicassoII up from the store tonight, and I was > > really hoping to see X in 256 colors. What's the latest word on the > > project? Could you use a beta tester? > > This made me think of the retina board I have in my A2K. Will there be > device support for the Retina? Yes, the Retina Z2 has been supported for some time now, though I am not exactly sure of its status with the 1.0 release. There is also some support for the Retina Z3. Both have source code available according to the latest reports. > > Also, since I don't have an MMU on my machine (yet) I cannot alas, run > NetBSD (if my understanding is correct), so I am looking for the linux Yes, the MMU is required. I think Linux may also require this, but I have not followed it that much. > port to see if that will get me by until such time as I can get a better > CPU card. (anyone with an 030/882 w MMU and some RAM wanting to sell let > me know (: ) > What I am wondering specifically is, will linux/NetBSD support the > Retina gfx card so that I can run Xwindows et al? And secondly, is the > Linux 1.0 beta available to test? If so, where can I find it (have not > been able to latch onto it. Archie is broken over here at the moment) and > how do I grab it if I find it? As far as I know, there is no support in Linux for any graphics other than the native Amiga. I also think X Windows is still in the future, but then as I said above, I have not followed it that closely. > Thanks for indulging me a bit. > > James Melin (sunrise@winternet.com) > >-- End of excerpt from James Melin -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 PH (512) 891-2336 abair@amcu-tx.sps.mot.com FAX (512) 891-3348 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 01:00:50 1994 From: Brian Moore To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: PCI support Sender: owner-current-users@sun-lamp.cs.berkeley.edu Speaking of device support, somebody here asked me if NetBSD supported Enhanced IDE, and for the life of me I couldn't remember that ever being discussed. Anybody know for sure? Thanks, --Brian From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 01:02:32 1994 From: Brian Moore To: mycroft@duality.gnu.ai.mit.edu Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: PCI support Sender: owner-current-users@sun-lamp.cs.berkeley.edu Thanks for the response, one question though. What extra features are used yet? The only one that I think the people asking me care about is using the higher number of drive cylinders. Thanks again, --Brian From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 01:03:09 1994 From: "Charles M. Hannum" To: mycroft@gnu.ai.mit.edu, ziff@eecs.umich.edu Subject: Re: PCI support Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu `Enhanced IDE' controllers should work fine, though the extra features over regular IDE controllers will not (yet) be used. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 01:04:26 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Cc: ziff@eecs.umich.edu Subject: SUP service from ftp.eecs.umich.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu After some great help from Luke Mewburn and Roland McGrath, I finally got ftp.ecs.umich.edu up and running as a sup file server for NetBSD-current. I've had it up and running for about a week, and it seems to be working fine and dandy. There is only one cavat, what happens when during a sup update between sun-lamp and ftp.eecs, sun-lamp goes down? Now ftp.eecs has an incomplete version of the -current sources which most likely won't compile. Well, to get around this, Roland McGrath suggested that I allow the latest sup log for ftp.eecs to be supped down to your local machine. Then you can just check the log to see if the latest sup completed successfully ( A simple script to check the last line of the log for the word completed would work nicely ) Please remember that the chance of a sup update aborting midway through a source only update is very rare ( Today's update took about 2-3 minutes ), it is the transferring of the huge tar files where the problem could happen ( right now it's a transfer of about 22 MB ). If you have any suggestions or comments about ftp.eecs.umich.edu, please don't hestitate to send me mail. Also if you have some NetBSD specific files that you would like put up there ( i.e. the latest XFree86/UUCP/top patches ) I'm in the process of bringing up some more space, so I'll keep you posted. Brian Moore Admin for NetBSD mirror on ftp.eecs.umich.edu ziff@eecs.umich.edu ------------------- log supfile ----------------------------------- latest release=logs host=ftp.eecs.umich.edu hostbase=/f/BSD/NetBSD base=/usr prefix=/usr backup use-rel-suffix delete ------------------- standard supfile ------------------------------ current release=allsrc host=ftp.eecs.umich.edu hostbase=/f/BSD/NetBSD base=/usr prefix=/usr backup use-rel-suffix delete current release=security host=ftp.eecs.umich.edu hostbase=/f/BSD/NetBSD base=/usr prefix=/usr backup use-rel-suffix delete current release=doc host=ftp.eecs.umich.edu hostbase=/f/BSD/NetBSD base=/usr prefix=/usr backup use-rel-suffix delete current release=othersrc host=ftp.eecs.umich.edu hostbase=/f/BSD/NetBSD base=/usr prefix=/usr backup use-rel-suffix delete From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 03:23:47 1994 X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Brian Moore Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SUP service from ftp.eecs.umich.edu <199408092137.RAA17132@zip.eecs.umich.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Brian Moore writes: > After some great help from Luke Mewburn and Roland McGrath, I finally got > ftp.ecs.umich.edu up and running as a sup file server for NetBSD-current. I' > ve > had it up and running for about a week, and it seems to be working fine and > dandy. There is only one cavat, what happens when during a sup update betwee > n > sun-lamp and ftp.eecs, sun-lamp goes down? Now ftp.eecs has an incomplete > version of the -current sources which most likely won't compile. Just sup again, and it will fix up your tree. I sup over a slow slip link and it has taken several hours for a fresh sup in the past. I've had sun-lamp crash before, and re-supping always works perfectly. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 03:31:50 1994 X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Dave Cornejo Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: random EFAULTs <199408050004.RAA28071@white.dogwood.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Dave Cornejo writes: > For the past couple of weeks, I've been getting random core dumps and > "bad address" errors. As of right now, I am using Aug 2nd binaries on > a kernel built from sources supped this morning. I am using a 486DLC > (I noticed that there have been changes to this lately). I see this > mostly happening in cpp. Have you tried turning off your external cache? Many systems have broken external caches, or have cards that interact badly with the cache. My system, for instance, has all kinds of problems with the cache on, yet can stay up for weeks at a time with it off. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 03:44:13 1994 From: Brian Moore To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SUP service from ftp.eecs.umich.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >Just sup again, and it will fix up your tree. I sup over a slow >slip link and it has taken several hours for a fresh sup in the >past. I've had sun-lamp crash before, and re-supping always works >perfectly. > I hope it didn't sound like I was implying that an incomplete source tree would be a permanemt thing. The next time that ftp.eecs sups from sun-lamp will successfully will fix it. My only thought on bringing it up, was that just because you successfully suped from ftp.eecs doesn't mean you are current with sun-lamp. It just means you are current with whatever ftp.eecs was able to sup from sun-lamp that morning. So just make sure you sup and check the latest_sup_log. I'm just doing this to do cut down on the inevitable mail message: "Hey, foo.c is including foo.h, which is missing." "Did you sup from ftp.eecs?" "Yes." "Well, the log says that the sup wasn't successful from sun-lamp, so check it tomorrow and see if it did a successful sup, and then re-sup." Once again, this shouldn't be a problem and might happen once or twice a year. I'm just trying to forsee some problems and take care of them now. --Brian From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 03:49:22 1994 From: Brian Moore To: ziff@eecs.umich.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SUP service from ftp.eecs.umich.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Oh yes, a few more things that I forgot to mention it my e-mail message. First, the name of the log file is called latest_sup_log. ftp.eecs runs a sup update every day at 7:00AM EST, and does a supscan immediately after. And finally, if you do use ftp.eecs to sup the sources, please send me an email message. I want to make sure it's running correctly, and the only way to know is if I hear from people. But don't send me mail after this Friday, I should have enough 'feedback' by then to make sure it's working. --Brian From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 04:05:01 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Brian Moore Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: PCI support <199408092149.RAA17329@zip.eecs.umich.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu RE: Enhanced IDE controllers: >Thanks for the response, one question though. What extra features are used >yet? The only one that I think the people asking me care about is using the >higher number of drive cylinders. I think the point is that *none* of the extra features are used. NetBSD sees it as just a regular IDE controller. It works -- but none of the advanced features are recognized. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc. Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532 In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 04:17:02 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Crash with Aug 7th 1.0_BETA Sender: owner-current-users@sun-lamp.cs.berkeley.edu My machine just randomly crashed for a first time in quite a while, and it's up 24 hours a day normally. Although I have DDB and DIAGNOSTIC enabled, the screen just suddenly blanked and rebooted. I'll do my best to describe everything that was happening on the machine. Although I have an IDE drive configured in my kernel, the drive hadn't been accessed a single time since my last reboot. Everything is on one SCSI-1 drive, connected via my UltraStor 34F. The system crashed after being up for at least a day. It was connected via SLIP, as it is 24 hours a day, and a user was telnetted in, although they were idle at the time. I was running XFree86 3.0Ce, and wasn't doing anything unusual with X, not to mention I've been running this version for well over a week without any problems. In one xterm I was compiling a new kernel, from newly supped sources from sun-lamp on Aug 9 (today). As far as I remember it was just compiling one of the source files. In another xterm I was reading man pages. I believe I had just typed a "man" command when it rebooted. My system is a Gateway 2000 486-DX2/66 VLB with 16mb of RAM, UltraStor 34F VLB SCSI controller, one SCSI-1 drive (which has everything on it), one SCSI-1 tape, which I hadn't accessed since the last reboot, an IDE drive which I hadn't accessed since reboot, an ATI Graphics Ultra Pro VLB with 2mb of VRAM. I am running with the external cache completely disabled. All of my filesystems are level-2, and have been for at least a week. I hadn't mounted or unmounted anything manually; only what's in the fstab was mounted. I was running a system compiled from scratch, supped from sun-lamp on Aug 7th with the following fstab, dmesg and config. The dmesg is from after the reboot, but it's the same kernel: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - /dev/sd0a / ufs rw 1 1 /dev/sd0e /usr ufs rw 1 2 /dev/sd0b none swap sw /dev/sd0b /tmp mfs rw,-s=16384 kernfs /kern kernfs rw 1 0 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NetBSD 1.0_BETA (EXCELSIOR) #0: Sun Aug 7 18:56:57 EDT 1994 mhw@cis-ts3-slip4.cis.brown.edu:/usr/src/sys/arch/i386/compile/EXCELSIOR CPU: i486DX (486-class CPU) real mem = 16121856 avail mem = 13774848 using 222 buffers containing 909312 bytes of memory kbd_cmd: input char 47 lost pcprobe: reset error 4 pc0 at isa0 port 0x60-0x6f irq 1: color npx0 at isa0 port 0xf0-0xff: using exception 16 com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo com2 at isa0 port 0x3e8-0x3ef irq 9: ns16550a, working fifo lpt0 at isa0 port 0x3bc-0x3c3: polled wdc0 at isa0 port 0x1f0-0x1f7 irq 14 wd0 at wdc0 drive 0: 325MB 1010 cyl, 12 head, 55 sec fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec fd1 at fdc0 drive 1: 1.2MB 80 cyl, 2 head, 15 sec uha0 at isa0 port 0x340-0x34f irq 11 scsibus0 at uha0 uha0 targ 0 lun 0: SCSI1 direct fixed sd0 at scsibus0: 992MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec uha0 targ 1 lun 0: SCSI1 sequential removable st0 at scsibus0: rogue, density code 0x0, 1024-byte blocks, write-protected biomask 4840 netmask 21a ttymask 21a Aperture driver for XFree86 version 1.1 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - # # EXCELSIOR # machine "i386" ident EXCELSIOR cpu "I486_CPU" options "COMPAT_09" options MATH_EMULATE options MACHINE_NONCONTIG timezone 5 dst maxusers 10 options SWAPPAGER,VNODEPAGER,DEVPAGER options KTRACE options FIFO options SYSVMSG options SYSVSEM options SYSVSHM options LKM options SCSI options QUOTA options MFS options FFS options NFSSERVER options NFSCLIENT options MSDOSFS options FDESC options SETUIDSCRIPTS, FDSCRIPTS options KERNFS options INET options NS options ISO options TPIP options EON options MULTICAST options GATEWAY options DDB, DIAGNOSTIC options "USER_LDT" options "COMPAT_NOMID" options "COMPAT_43" options "TCP_COMPAT_42" options XSERVER,UCONSOLE options "PCVT_META_ESC=1" config netbsd root on sd0 swap on sd0 controller isa0 device pc0 at isa? port "IO_KBD" irq 1 device npx0 at isa? port "IO_NPX" irq 13 device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 9 device lpt0 at isa? port "IO_LPT3" controller wdc0 at isa? port "IO_WD1" irq 14 disk wd0 at wdc0 drive ? controller fdc0 at isa? port "IO_FD1" irq 6 drq 2 disk fd0 at fdc0 drive ? disk fd1 at fdc0 drive ? controller uha0 at isa? port 0x340 irq ? drq ? master scsibus0 at uha0 device sd0 at scsibus0 slave ? device st0 at scsibus0 slave ? pseudo-device pty 64 pseudo-device loop pseudo-device ether #XXX pseudo-device log pseudo-device bpfilter 4 pseudo-device sl 2 pseudo-device ppp pseudo-device vn 4 pseudo-device speaker pseudo-device tb Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 10 05:13:30 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 4.93) Organization: None From: djjames%djamiga@fsd.com (D.J.James) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Using ESDI drive with NetBSD-Amiga Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Just FYI, I'm sucessfully using a 330 Meg Micropolis ESDI disk drive and Emulex MD21/S2 ESDI to SCSI adapter board with NetBSD-Amiga V1.0 The drive type comes up as `unknown' type during the initial scsi poll, but the size and relevant parameters are fine. I have the whole works - root, swap, usr, and home - on the one drive. Djj ================================== djjames@fsd.com djjames@cup.portal.com trud1.fsd.com!djamiga.UUCP!djjames ================================== From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 05:35:13 1994 To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: dump density bpi = bit/byte ? <199408050946.LAA00395@wipux2.wifo.uni-mannheim.de> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm trying to use a qic 525 MB tape, which tells me > that it is 1020 feet long. I'd like to know whether > the density I should be using is to be in Bits/Per/Inch > or in Bytes/Per/Inch > i.e. > 525 * 1024 * 1024 / 1020 / 12 = Value or > 525 * 1024 * 1024 * 8 / 1020 / 12 = Value. > Cheerio > > PS. I'm doing the command dump 0udsf 12345 1020 /dev/rst1 /mit Umm, i don't know the answer to this, but i do know that using the 'B' option to dump may save you a big headache... 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 06:17:13 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: SCSI driver doesn't wait enough for CD ROM to become ready X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Some CD-ROM drives (like mine) take a while to become ready after a bus reset. The CD driver ought to delay a bit to let them finish if they aren't initially ready. Here's a patch. ==John =================================================================== RCS file: RCS/cd.c,v retrieving revision 1.1 diff -c -r1.1 cd.c *** 1.1 1994/08/10 01:41:15 --- cd.c 1994/08/10 02:20:32 *************** *** 141,146 **** --- 141,147 ---- struct cd_data *cd = (void *)self; struct cd_parms *dp = &cd->params; struct scsi_link *sc_link = aux; + int error; SC_DEBUG(sc_link, SDEV_DB2, ("cdattach: ")); *************** *** 172,178 **** * the drive. We cannot use interrupts yet, so the * request must specify this. */ ! cd_get_parms(cd, SCSI_NOSLEEP | SCSI_NOMASK | SCSI_SILENT); if (dp->disksize) printf(": cd present, %d x %d byte records\n", cd->params.disksize, cd->params.blksize); --- 173,184 ---- * the drive. We cannot use interrupts yet, so the * request must specify this. */ ! error = cd_get_parms(cd, SCSI_NOSLEEP | SCSI_NOMASK | SCSI_SILENT); ! if (error) { ! /* The device may take time to settle after a SCSI bus reset. */ ! delay(/*TWO_SECS*/2000000); ! error = cd_get_parms(cd, SCSI_NOSLEEP | SCSI_NOMASK | SCSI_SILENT); ! } if (dp->disksize) printf(": cd present, %d x %d byte records\n", cd->params.disksize, cd->params.blksize); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 06:17:19 1994 From: mh@chemie.uni-hamburg.de (Michael Havemester) Subject: Taylor-UUCP i-protocol failure To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3696 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've encountered a problem using Taylor-UUCP's i-protocol on my NetBSD-1.0 ALPHA and now 1.0 BETA system on serial lines (tcp connections not fully tested). Everything seems OK, if there are queued jobs only on one side. If there are jobs waiting on both sides (I'll need only a 50 kb uucp job on both sides), then I get a lot of errors. Sometimes the opposite side (Taylor-UUCP 1.04) isn't able to recover, if there are more queued jobs waiting on both sides. I've tried Taylor-UUCP 1.04 (NetBSD-current) and 1.05 on my system running NetBSD-current (1.0 ALPHA and BETA, latest tested version from Aug. 4.). Both Taylor-UUCP versions were configured with several different options enabled/disabled in policy.h (HAVE_UNBLOCKED_WRITE, USE_STDIO, SINGLE_WRITE=[1,16,64,100], ...). I checked this on two different systems and used different hardware (one 16550 based card and the another multiport card with onboard CPU and vendor-specific driver) and different baudrates (9600, 19200 and 57600, got NO silo overflows). While using 64 byte packets, everything seems to work without a problem. With a packetsize of 256 bytes and above I see a lot of errors (the first after sending only 6 packets). With a packet-size above 256 byte the error-rate increases. On the sending-side I see messages like the following: "fsysdep_conn_io: Blocking write of 100" The SAME block will be resend later, after the uucico got a NAK for this packet. NetBSD-System: DEBUG: fisenddata: Sending packet 5 size 256 local 1 remote 0 DEBUG: fconn_io: Writing 266 "..." DEBUG: fconn_io: Wrote 266 of 266, read 0 of 16349 DEBUG: fisenddata: Sending packet 6 size 256 local 1 remote 0 DEBUG: fconn_io: Writing 266 "..." DEBUG: fsysdep_conn_io: Blocking write of 100 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG: fconn_io: Wrote 266 of 266, read 816 of 16349 DEBUG: fconn_io: Read 816 "..." DEBUG: fiprocess_packet: Got DATA packet 1 size 79 local 0 remote 1 [...] DEBUG: fiprocess_packet: Got DATA packet 16 size 256 local 0 remote 1 DEBUG: fiprocess_packet: Got NAK 6; resending packet ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ DEBUG: fconn_io: Writing 266 "..." DEBUG: fconn_io: Wrote 266 of 266, read 0 of 13009 DEBUG: fiprocess_packet: Got NAK 12; resending packet Other non NetBSD-System, no problems with Taylor-UUCP 1.04/1.05 and i-protocol for over a year: [...] DEBUG: fisenddata: Sending packet 16 size 256 local 1 remote 0 DEBUG: fconn_io: Writing 266 "..." DEBUG: fconn_io: Wrote 266 of 266, read 40 of 15141 DEBUG: fconn_io: Read 40 "..." DEBUG: fiwindow_wait: Waiting for ACK DEBUG: fiwait_for_packet: Need 35 bytes DEBUG: fconn_read: Read 72 "..." DEBUG: fiprocess_packet: Got DATA packet 5 size 256 local 0 remote 1 DEBUG: fiwindow_wait: Waiting for ACK DEBUG: fiwait_for_packet: Need 229 bytes DEBUG: fconn_read: Read 232 "..." DEBUG: fiprocess_data: Bad checksum; data 4112989840, frame 182404709 DEBUG: finak: Sending NAK 6 DEBUG: fconn_io: Writing 6 "..." DEBUG: fconn_io: Wrote 6 of 6, read 0 of 14797 DEBUG: fiwait_for_packet: Need 5 bytes DEBUG: fconn_read: Read 40 "..." DEBUG: fiprocess_data: Saving unexpected packet 7 (recseq 5) DEBUG: fiprocess_data: Saving unexpected packet 8 (recseq 5) I've a lot more output from debug (more then 200 kb from both sides), but I think these two short examples should show the problem. What am I doing wrong or has anyone else seen this behavior ? Any help would be greatly appreciated. Thanks. -- Michael Havemester VOICE: +49 40/29 33 56 Weidestrasse 41 Fax : +49 40/29 45 17 D-22083 Hamburg, Germany EMail: mh@abqhh.Hanse.DE From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 06:25:16 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Another crash Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, the same thing just happened again, while compiling the kernel. The situation was exactly the same, except that instead of reading man pages I was "write"ing messages to the other telnetted person (who was writing to me also). I'd also like to add some more info. The last kernel I used was supped on Aug 2nd, and I didn't have any such problems with that. Also, nothing significant other than the code has changed in the last several weeks. The fstab, config, hardware configuration, etc, has not been changed. The two times it has crashed has been while compiling the Aug 9th kernel with the Aug 7th kernel and userland. Actually, I've got a few Aug 9th userland executables (ipcrm, tar, and ld.so). I'm compiling my new kernel with a slightly different config, but I saved a copy of my old one and that's what I posted in my last message. It seems I have at least a semi-reproducable problem here, so if anyone has ideas, let me know. Unfortunately my kernel source is now the Aug 9th system, but I have diffs from Aug 2 to Aug 7 and from Aug 7 to Aug 9. I guess this is a bug that was introduced between the 2nd and the 7th, so here are my diffs between those two days. For now I've removed most of the diffs of files that are not in my kernel, and diffs of files that are in arch/{non-i386}. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science --- src/gnu/usr.bin/ld/i386/BACKUP/mdprologue.S Sun Aug 7 17:24:32 1994 +++ src/gnu/usr.bin/ld/i386/mdprologue.S Wed Aug 3 13:59:02 1994 @@ -27,7 +27,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $Id: mdprologue.S,v 1.3 1994/01/29 02:03:27 jtc Exp $ + * $Id: mdprologue.S,v 1.3.2.1 1994/08/03 17:00:12 cgd Exp $ */ /* @@ -43,13 +43,10 @@ /* * _rtl(int version, struct crt_ldso *crtp) */ -#define FRAME 12 /* Size of stack frame */ - _rtl: # crt0 calls us here pushl %ebp # Allocate stack frame movl %esp, %ebp - subl $FRAME, %esp pushl %ebx call 1f # PIC function prologue 1: @@ -68,7 +65,7 @@ call %eax # _rtld(version, crtp, DYNAMIC) addl $12,%esp # pop arguments - movl (-FRAME-4)(%ebp), %ebx # restore %ebx + movl -4(%ebp), %ebx # restore %ebx leave # remove stack frame, ret # let's rock --- src/sys/arch/i386/i386/BACKUP/locore.s Sun Aug 7 17:28:57 1994 +++ src/sys/arch/i386/i386/locore.s Thu Aug 4 07:11:33 1994 @@ -37,7 +37,7 @@ * SUCH DAMAGE. * * from: @(#)locore.s 7.3 (Berkeley) 5/13/91 - * $Id: locore.s,v 1.77 1994/07/04 23:20:44 mycroft Exp $ + * $Id: locore.s,v 1.77.2.2 1994/08/03 23:38:23 mycroft Exp $ */ /* @@ -243,46 +243,57 @@ movl $0x69727943,_cpu_vendor-KERNBASE # store vendor string movw $0x0078,_cpu_vendor-KERNBASE+4 - /* Set cache parameters */ - invd # Start with guaranteed clean cache - movb $0xc0,%al # Configuration Register index (CCR0) +#ifndef notdef + /* Disable caching of the ISA hole only. */ + invd + movb $CCR0,%al # Configuration Register index (CCR0) outb %al,$0x22 - # movb $0x22,%al # Configuration Register CCR0 data - movb $0x02,%al # Configuration Register CCR0 data + inb $0x23,%al + orb $CCR0_NC1,%al outb %al,$0x23 - movb $0xc1,%al # CCR1 + invd +#else + /* Set cache parameters */ + invd # Start with guaranteed clean cache +#ifdef CYRIX_CACHE_WORKS + movb $CCR0,%al # Configuration Register index (CCR0) outb %al,$0x22 - xorb %al,%al + inb $0x23,%al + andb $~CCR0_NC0,%al + orb $CCR0_NC1,%al outb %al,$0x23 /* clear non-cacheable region 1 */ - movb $0xc6,%al + movb $(NCR1+2),%al outb %al,$0x22 - xorb %al,%al + movb $NCR_SIZE_0K,%al outb %al,$0x23 /* clear non-cacheable region 2 */ - movb $0xc9,%al + movb $(NCR2+2),%al outb %al,$0x22 - xorb %al,%al + movb $NCR_SIZE_0K,%al outb %al,$0x23 /* clear non-cacheable region 3 */ - movb $0xcc,%al + movb $(NCR3+2),%al outb %al,$0x22 - xorb %al,%al + movb $NCR_SIZE_0K,%al outb %al,$0x23 /* clear non-cacheable region 4 */ - movb $0xcf,%al + movb $(NCR4+2),%al outb %al,$0x22 - xorb %al,%al + movb $NCR_SIZE_0K,%al outb %al,$0x23 /* enable caching in CR0 */ movl %cr0,%eax -#ifdef notyet_cyrix andl $~(CR0_CD|CR0_NW),%eax + movl %eax,%cr0 #else + /* disable caching in CR0 */ + movl %cr0,%eax orl $CR0_CD,%eax - invd -#endif movl %eax,%cr0 +#endif + invd +#endif /* notdef */ jmp 2f @@ -530,7 +541,7 @@ movl __udatasel,%ecx pushl %ecx # user ss pushl $0xdeadbeef # user esp (set by execve) - pushl $(PSL_USERSET | PSL_IOPL) # user eflags + pushl $PSL_USERSET # user eflags pushl %eax # user cs pushl $0xdeadbeef # user eip (set by execve) subl $40,%esp # error code, trap number, registers @@ -559,16 +570,20 @@ 1: #endif -#ifndef notyet_cyrix +#ifdef notdef cmp $CPU_486DLC,_cpu jne 1f pushl $2f call _printf addl $4,%esp jmp 1f -2: .asciz "WARNING: CYRIX 486DLC DETECTED; CACHE DISABLED.\n" -1: +#ifdef CYRIX_CACHE_WORKS +2: .asciz "WARNING: CYRIX 486DLC CACHE ENABLED.\n" +#else +2: .asciz "WARNING: CYRIX 486DLC CACHE DISABLED BY DEFAULT.\n" #endif +1: +#endif /* notdef */ INTRFASTEXIT /* NOTREACHED */ --- src/sys/arch/i386/include/BACKUP/specialreg.h Sun Aug 7 17:29:15 1994 +++ src/sys/arch/i386/include/specialreg.h Thu Aug 4 07:11:38 1994 @@ -31,7 +31,7 @@ * SUCH DAMAGE. * * from: @(#)specialreg.h 7.1 (Berkeley) 5/9/91 - * $Id: specialreg.h,v 1.5 1994/05/24 11:54:24 mycroft Exp $ + * $Id: specialreg.h,v 1.5.2.1 1994/08/03 23:36:36 mycroft Exp $ */ /* @@ -52,3 +52,54 @@ #define CR0_AM 0x00040000 /* Alignment Mask (set to enable AC flag) */ #define CR0_NW 0x20000000 /* Not Write-through */ #define CR0_CD 0x40000000 /* Cache Disable */ + +/* + * Cyrix 486 DLC special registers, accessable as IO ports. + */ +#define CCR0 0xc0 /* configuration control register 0 */ +#define CCR0_NC0 0x01 /* first 64K of each 1M memory region is non-cacheable */ +#define CCR0_NC1 0x02 /* 640K-1M region is non-cacheable */ +#define CCR0_A20M 0x04 /* enables A20M# input pin */ +#define CCR0_KEN 0x08 /* enables KEN# input pin */ +#define CCR0_FLUSH 0x10 /* enables FLUSH# input pin */ +#define CCR0_BARB 0x20 /* flushes internal cache when entering hold state */ +#define CCR0_CO 0x40 /* cache org: 1=direct mapped, 0=2x set assoc */ +#define CCR0_SUSPEND 0x80 /* enables SUSP# and SUSPA# pins */ + +#define CCR1 0xc1 /* configuration control register 1 */ +#define CCR1_RPL 0x01 /* enables RPLSET and RPLVAL# pins */ +/* the remaining 7 bits of this register are reserved */ + +/* + * the following four 3-byte registers control the non-cacheable regions. + * These registers must be written as three seperate bytes. + * + * NCRx+0: A31-A24 of starting address + * NCRx+1: A23-A16 of starting address + * NCRx+2: A15-A12 of starting address | NCR_SIZE_xx. + * + * The non-cacheable region's starting address must be aligned to the + * size indicated by the NCR_SIZE_xx field. + */ +#define NCR1 0xc4 +#define NCR2 0xc7 +#define NCR3 0xca +#define NCR4 0xcd + +#define NCR_SIZE_0K 0 +#define NCR_SIZE_4K 1 +#define NCR_SIZE_8K 2 +#define NCR_SIZE_16K 3 +#define NCR_SIZE_32K 4 +#define NCR_SIZE_64K 5 +#define NCR_SIZE_128K 6 +#define NCR_SIZE_256K 7 +#define NCR_SIZE_512K 8 +#define NCR_SIZE_1M 9 +#define NCR_SIZE_2M 10 +#define NCR_SIZE_4M 11 +#define NCR_SIZE_8M 12 +#define NCR_SIZE_16M 13 +#define NCR_SIZE_32M 14 +#define NCR_SIZE_4G 15 + --- src/sys/arch/i386/isa/BACKUP/ultra14f.c Sun Aug 7 17:30:03 1994 +++ src/sys/arch/i386/isa/ultra14f.c Wed Aug 3 15:22:07 1994 @@ -26,7 +26,7 @@ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * - * $Id: ultra14f.c,v 1.30.2.3 1994/08/01 17:13:53 cgd Exp $ + * $Id: ultra14f.c,v 1.30.2.4 1994/08/03 17:12:45 cgd Exp $ */ /* @@ -606,7 +606,7 @@ ia->ia_drq = uha->uha_dma; ia->ia_msize = 0; - ia->ia_iosize = 4; + ia->ia_iosize = 16; return 1; } --- src/sys/isofs/cd9660/BACKUP/TODO.hibler Sun Aug 7 17:32:03 1994 +++ src/sys/isofs/cd9660/TODO.hibler Wed Aug 3 15:25:12 1994 @@ -1,4 +1,4 @@ -# $NetBSD: TODO.hibler,v 1.3.2.1 1994/07/20 03:17:39 cgd Exp $ +# $NetBSD: TODO.hibler,v 1.3.2.2 1994/08/03 06:16:20 cgd Exp $ 1. Investiate making ISOFS another UFS shared filesystem (ala FFS/MFS/LFS). Since it was modelled after the inode code, we might be able to merge @@ -13,5 +13,4 @@ cluster). 5. Seems like there should be a "notrans" or some such mount option to show - filenames as they really are without lower-casing, stripping of version - numbers, etc. Does this make sense? + filenames as they really are without lower-casing. Does this make sense? --- src/sys/isofs/cd9660/BACKUP/cd9660_vnops.c Sun Aug 7 17:32:04 1994 +++ src/sys/isofs/cd9660/cd9660_vnops.c Wed Aug 3 15:25:13 1994 @@ -1,4 +1,4 @@ -/* $NetBSD: cd9660_vnops.c,v 1.5.2.3 1994/07/20 06:17:17 cgd Exp $ */ +/* $NetBSD: cd9660_vnops.c,v 1.5.2.4 1994/08/03 06:16:26 cgd Exp $ */ /*- * Copyright (c) 1994 @@ -946,7 +946,7 @@ if (VTOI(ap->a_vp)->i_mnt->iso_ftype == ISO_FTYPE_RRIP) *ap->a_retval = NAME_MAX; else - *ap->a_retval = 23; /* XXX 8.8;5 */ + *ap->a_retval = 37; return (0); case _PC_PATH_MAX: *ap->a_retval = PATH_MAX; --- src/sys/kern/BACKUP/tty.c Sun Aug 7 17:32:21 1994 +++ src/sys/kern/tty.c Wed Aug 3 15:25:16 1994 @@ -1,4 +1,4 @@ -/* $NetBSD: tty.c,v 1.49 1994/06/29 06:33:20 cgd Exp $ */ +/* $NetBSD: tty.c,v 1.49.2.1 1994/08/03 03:51:00 cgd Exp $ */ /*- * Copyright (c) 1982, 1986, 1990, 1991, 1993 @@ -167,6 +167,9 @@ if (!ISSET(tp->t_state, TS_ISOPEN)) { SET(tp->t_state, TS_ISOPEN); bzero(&tp->t_winsize, sizeof(tp->t_winsize)); +#if defined(COMPAT_43) || defined(COMPAT_SUNOS) + tp->t_flags = 0; +#endif } CLR(tp->t_state, TS_WOPEN); splx(s); --- src/sys/kern/BACKUP/tty_compat.c Sun Aug 7 17:32:48 1994 +++ src/sys/kern/tty_compat.c Wed Aug 3 15:25:17 1994 @@ -1,4 +1,4 @@ -/* $NetBSD: tty_compat.c,v 1.14 1994/06/29 06:33:24 cgd Exp $ */ +/* $NetBSD: tty_compat.c,v 1.14.2.1 1994/08/03 03:51:06 cgd Exp $ */ /*- * Copyright (c) 1982, 1986, 1991, 1993 @@ -126,7 +126,7 @@ term.c_ospeed = compatspcodes[speed]; term.c_cc[VERASE] = sg->sg_erase; term.c_cc[VKILL] = sg->sg_kill; - tp->t_flags = tp->t_flags&0xffff0000 | sg->sg_flags&0xffff; + tp->t_flags = (ttcompatgetflags(tp)&0xffff0000) | (sg->sg_flags&0xffff); ttcompatsetflags(tp, &term); return (ttioctl(tp, com == TIOCSETP ? TIOCSETAF : TIOCSETA, &term, flag, p)); @@ -186,17 +186,20 @@ case TIOCLBIC: case TIOCLSET: { struct termios term; + long flags; term = tp->t_termios; - if (com == TIOCLSET) - tp->t_flags = (tp->t_flags&0xffff) | *(int *)data<<16; - else { - tp->t_flags = - (ttcompatgetflags(tp)&0xffff0000)|(tp->t_flags&0xffff); - if (com == TIOCLBIS) - tp->t_flags |= *(int *)data<<16; - else - tp->t_flags &= ~(*(int *)data<<16); + flags = ttcompatgetflags(tp); + switch (com) { + case TIOCLSET: + tp->t_flags = (flags&0xffff) | (*(int *)data<<16); + break; + case TIOCLBIS: + tp->t_flags = flags | (*(int *)data<<16); + break; + case TIOCLBIC: + tp->t_flags = flags & ~(*(int *)data<<16); + break; } ttcompatsetlflags(tp, &term); return (ttioctl(tp, TIOCSETA, &term, flag, p)); @@ -242,49 +245,49 @@ register long cflag = tp->t_cflag; register flags = 0; - if (iflag&IXOFF) + if (iflag & IXOFF) flags |= TANDEM; - if (iflag&ICRNL || oflag&ONLCR) + if (iflag & ICRNL || oflag & ONLCR) flags |= CRMOD; - if (cflag&PARENB) { - if (iflag&INPCK) { - if (cflag&PARODD) + if (cflag & PARENB) { + if (iflag & INPCK) { + if (cflag & PARODD) flags |= ODDP; else flags |= EVENP; } else flags |= EVENP | ODDP; } else { - if ((tp->t_flags&LITOUT) && !(oflag&OPOST)) + if ((tp->t_flags & LITOUT) && !(oflag & OPOST)) flags |= LITOUT; - if (tp->t_flags&PASS8) + if (tp->t_flags & PASS8) flags |= PASS8; } - if ((lflag&ICANON) == 0) { + if ((lflag & ICANON) == 0) { /* fudge */ if (iflag&IXON || lflag&ISIG || lflag&IEXTEN || cflag&PARENB) flags |= CBREAK; else flags |= RAW; } - if (cflag&MDMBUF) + if (cflag & MDMBUF) flags |= MDMBUF; - if ((cflag&HUPCL) == 0) + if ((cflag & HUPCL) == 0) flags |= NOHANG; - if (oflag&OXTABS) + if (oflag & OXTABS) flags |= XTABS; - if (lflag&ECHOE) + if (lflag & ECHOE) flags |= CRTERA|CRTBS; - if (lflag&ECHOKE) + if (lflag & ECHOKE) flags |= CRTKIL|CRTBS; - if (lflag&ECHOPRT) + if (lflag & ECHOPRT) flags |= PRTERA; - if (lflag&ECHOCTL) + if (lflag & ECHOCTL) flags |= CTLECH; - if ((iflag&IXANY) == 0) + if ((iflag & IXANY) == 0) flags |= DECCTQ; - flags |= lflag&(ECHO|TOSTOP|FLUSHO|PENDIN|NOFLSH); + flags |= lflag & (ECHO|TOSTOP|FLUSHO|PENDIN|NOFLSH); if (ttydebug) printf("getflags: %x\n", flags); return (flags); @@ -300,61 +303,71 @@ register long lflag = t->c_lflag; register long cflag = t->c_cflag; + if (flags & TANDEM) + iflag |= IXOFF; + else + iflag &= ~IXOFF; + if (flags & ECHO) + lflag |= ECHO; + else + lflag &= ~ECHO; + if (flags & CRMOD) { + iflag |= ICRNL; + oflag |= ONLCR; + } else { + iflag &= ~ICRNL; + oflag &= ~ONLCR; + } + if (flags & XTABS) + oflag |= OXTABS; + else + oflag &= ~OXTABS; + + if (flags & RAW) { iflag &= IXOFF; - oflag &= ~OPOST; - lflag &= ~(ECHOCTL|ISIG|ICANON|IEXTEN); + lflag &= ~(ISIG|ICANON|IEXTEN); } else { iflag |= BRKINT|IXON|IMAXBEL; - oflag |= OPOST; - lflag |= ISIG|IEXTEN|ECHOCTL; /* XXX was echoctl on ? */ - if (flags & XTABS) - oflag |= OXTABS; - else - oflag &= ~OXTABS; + lflag |= ISIG|IEXTEN; if (flags & CBREAK) lflag &= ~ICANON; else lflag |= ICANON; - if (flags&CRMOD) { - iflag |= ICRNL; - oflag |= ONLCR; - } else { - iflag &= ~ICRNL; - oflag &= ~ONLCR; - } } - if (flags&ECHO) - lflag |= ECHO; - else - lflag &= ~ECHO; - if (flags&(RAW|LITOUT|PASS8)) { + switch (flags & ANYP) { + case EVENP: + iflag |= INPCK; + cflag &= ~PARODD; + break; + case ODDP: + iflag |= INPCK; + cflag |= PARODD; + break; + default: + iflag &= ~INPCK; + break; + } + + if (flags & (RAW|LITOUT|PASS8)) { cflag &= ~(CSIZE|PARENB); cflag |= CS8; - if ((flags&(RAW|PASS8)) == 0) + if ((flags & (RAW|PASS8)) == 0) iflag |= ISTRIP; else iflag &= ~ISTRIP; + if ((flags & (RAW|LITOUT)) == 0) + oflag |= OPOST; + else + oflag &= ~OPOST; } else { cflag &= ~CSIZE; cflag |= CS7|PARENB; iflag |= ISTRIP; + oflag |= OPOST; } - if ((flags&(EVENP|ODDP)) == EVENP) { - iflag |= INPCK; - cflag &= ~PARODD; - } else if ((flags&(EVENP|ODDP)) == ODDP) { - iflag |= INPCK; - cflag |= PARODD; - } else - iflag &= ~INPCK; - if (flags&LITOUT) - oflag &= ~OPOST; /* move earlier ? */ - if (flags&TANDEM) - iflag |= IXOFF; - else - iflag &= ~IXOFF; + t->c_iflag = iflag; t->c_oflag = oflag; t->c_lflag = lflag; @@ -371,49 +384,57 @@ register long lflag = t->c_lflag; register long cflag = t->c_cflag; - if (flags&CRTERA) + /* Nothing we can do with CRTBS. */ + if (flags & PRTERA) + lflag |= ECHOPRT; + else + lflag &= ~ECHOPRT; + if (flags & CRTERA) lflag |= ECHOE; else lflag &= ~ECHOE; - if (flags&CRTKIL) + /* Nothing we can do with TILDE. */ + if (flags & MDMBUF) + cflag |= MDMBUF; + else + cflag &= ~MDMBUF; + if (flags & NOHANG) + cflag &= ~HUPCL; + else + cflag |= HUPCL; + if (flags & CRTKIL) lflag |= ECHOKE; else lflag &= ~ECHOKE; - if (flags&PRTERA) - lflag |= ECHOPRT; - else - lflag &= ~ECHOPRT; - if (flags&CTLECH) + if (flags & CTLECH) lflag |= ECHOCTL; else lflag &= ~ECHOCTL; - if ((flags&DECCTQ) == 0) + if ((flags & DECCTQ) == 0) iflag |= IXANY; else iflag &= ~IXANY; - if (flags & MDMBUF) - cflag |= MDMBUF; - else - cflag &= ~MDMBUF; - if (flags&NOHANG) - cflag &= ~HUPCL; - else - cflag |= HUPCL; lflag &= ~(TOSTOP|FLUSHO|PENDIN|NOFLSH); lflag |= flags&(TOSTOP|FLUSHO|PENDIN|NOFLSH); - if (flags&(LITOUT|PASS8)) { - iflag &= ~ISTRIP; + + if (flags & (RAW|LITOUT|PASS8)) { cflag &= ~(CSIZE|PARENB); cflag |= CS8; - if (flags&LITOUT) - oflag &= ~OPOST; - if ((flags&(PASS8|RAW)) == 0) + if ((flags & (RAW|PASS8)) == 0) iflag |= ISTRIP; - } else if ((flags&RAW) == 0) { + else + iflag &= ~ISTRIP; + if ((flags & (RAW|LITOUT)) == 0) + oflag |= OPOST; + else + oflag &= ~OPOST; + } else { cflag &= ~CSIZE; cflag |= CS7|PARENB; + iflag |= ISTRIP; oflag |= OPOST; } + t->c_iflag = iflag; t->c_oflag = oflag; t->c_lflag = lflag; --- src/sys/msdosfs/BACKUP/msdosfs_fat.c Sun Aug 7 17:33:29 1994 +++ src/sys/msdosfs/msdosfs_fat.c Sun Aug 7 06:36:50 1994 @@ -1,4 +1,4 @@ -/* $NetBSD: msdosfs_fat.c,v 1.7.2.2 1994/07/19 17:06:45 cgd Exp $ */ +/* $NetBSD: msdosfs_fat.c,v 1.7.2.3 1994/08/04 19:15:13 mycroft Exp $ */ /*- * Copyright (C) 1994 Wolfgang Solfrank. @@ -664,7 +664,7 @@ u_long *got; { int error; - u_long idx, max_idx; + u_long idx; u_long len, newst, foundcn, foundl, cn, l; u_int map; @@ -692,11 +692,10 @@ foundcn = newst = (start * 1103515245 + 12345) % (pmp->pm_maxcluster - 1); foundl = 0; - max_idx = (pmp->pm_maxcluster - 1) / N_INUSEBITS; - idx = newst / N_INUSEBITS; - map = pmp->pm_inusemap[idx]; - map |= (1 << (newst % N_INUSEBITS)) - 1; - while (1) { + for (cn = newst; cn <= pmp->pm_maxcluster;) { + idx = cn / N_INUSEBITS; + map = pmp->pm_inusemap[idx]; + map |= (1 << (cn % N_INUSEBITS)) - 1; if (map != (u_int)-1) { cn = idx * N_INUSEBITS + ffs(map^(u_int)-1) - 1; if ((l = chainlength(pmp, cn, count)) >= count) @@ -706,19 +705,14 @@ foundl = l; } cn += l + 1; - if (cn > pmp->pm_maxcluster) - break; - idx = cn / N_INUSEBITS; - map = pmp->pm_inusemap[idx]; - map |= (1 << (cn % N_INUSEBITS)) - 1; continue; } - if (++idx > max_idx) - break; - map = pmp->pm_inusemap[idx]; + cn += N_INUSEBITS - cn % N_INUSEBITS; } - for (idx = 0;;) { + for (cn = 0; cn < newst;) { + idx = cn / N_INUSEBITS; map = pmp->pm_inusemap[idx]; + map |= (1 << (cn % N_INUSEBITS)) - 1; if (map != (u_int)-1) { cn = idx * N_INUSEBITS + ffs(map^(u_int)-1) - 1; if ((l = chainlength(pmp, cn, count)) >= count) @@ -728,15 +722,9 @@ foundl = l; } cn += l + 1; - if (cn >= newst) - break; - idx = cn / N_INUSEBITS; - map = pmp->pm_inusemap[idx]; - map |= (1 << (cn % N_INUSEBITS)) - 1; continue; } - if (++idx * N_INUSEBITS >= newst) - break; + cn += N_INUSEBITS - cn % N_INUSEBITS; } if (!foundl) --- src/usr.sbin/config/BACKUP/mkioconf.c Sun Aug 7 17:34:20 1994 +++ src/usr.sbin/config/mkioconf.c Wed Aug 3 15:32:17 1994 @@ -33,7 +33,7 @@ #ifndef lint /*static char sccsid[] = "from: @(#)mkioconf.c 5.18 (Berkeley) 5/10/91";*/ -static char rcsid[] = "$Id: mkioconf.c,v 1.32 1994/06/24 14:22:08 hpeyerl Exp $"; +static char rcsid[] = "$Id: mkioconf.c,v 1.32.2.1 1994/08/03 13:26:45 hpeyerl Exp $"; #endif /* not lint */ #include @@ -135,7 +135,7 @@ fprintf(fp, "\t%d,\t%d,\t%d,\t%d,\t{", dp->d_unit, dp->d_pri < 0 ? 0 : dp->d_pri, dp->d_flags, 1); - for (fl = fl->f_next; fl->f_type == COMPSPEC && fl->f_next; fl = fl->f_next) + for (fl = fl->f_next; fl->f_type == COMPSPEC && fl; fl = fl->f_next) fprintf(fp, " 0x%x,", fl->f_compdev); fprintf(fp, " NODEV },\n"); } From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 10 22:42:12 1994 From: niklas@appli.se (Niklas Hallqvist) To: niklas@appli.se Cc: newsham@uhunix.uhcc.Hawaii.Edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: upgrade to 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Niklas" == Niklas Hallqvist writes: >>>>> "Tim" == Tim Newsham writes: Tim> (btw.. can I get diffs for non-contig memory handling with the Tim> new kernels from someone who has already got it up and running?) Niklas> I'll send it to you this evening, or maybe even the list as Niklas> it's not that large. I must've screwed up my last command before I left home, which was to set my home modem to dialin in order to fetch the patch here from the office. Well, it won't answer. This means you won't see the patch just yet. I'll try to *really* send it tonight. Sorry for the inconvenience. Niklas From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:11:48 1994 From: klee@rdcclink.rd.qms.com To: netbsd-users@sun-lamp.cs.berkeley.edu, netbsd-current@sun-lamp.cs.berkeley.edu Subject: init:kernel security level changed from 0 to 1 Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi! I have tried to upgrade the NetBSD 0.9 to NetBSD 1.0-BETA. When I boot the machine, it displays message something like "init: kernel security level changed from 0 to 1", and hangs. I had security code(decription) installed before. Will that has to do with this error? If so, how can I remove this? Or any other solution(other than re-installing whole thing)? Thanks in advance. Kang From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:15:36 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: 2 simple questions followup... To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu BTW, one additional thing I might have missed concerning problem #2 was that I have not configured the correct /dev files for dial out ports (i.e. wrong major/minor numbers, etc.) Being the forgetful one I am, how would/could I change my MAKEDEV file to correctly "mknod" me some dial out ports (if this is actually the cause of my problem, but still would be helpful info!). Thanks again for any replies. ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:19:22 1994 Subject: Notebook for NetBSD: which arch? To: current-users@sun-lamp.cs.berkeley.edu From: "Martin Husemann" Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 609 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm going to by a notebook, as the powers above me have decided I will be traveling by train two hours a day for more than a year soon. Since NetBSD runs on various platforms, is there anything that could beat a pentium with local-bus graphics/tft on a price/performance basis? Could I even run NetBSD and X on other architectures notebook variants? Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:22:58 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: 2 simple questions... To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu I only have two (hopefully) simple questions for the pros out there. BTW, I'm using the binary snapshots as of August 1 (NetBSD 1.0_BETA). 1. I get this annoying message every time I boot up: Aug 10 02:06:24 melissa init: kernel security level changed from 0 to 1 How do I stop this message from reappearing all the time every time I reboot?? I suspect it has something to do with the way I extracted the binary shots, as I recall some error rolling by as it extracted init. Anyway, is there a way to fix it? 2. Every time I try to type in commands to my modem, using "cu", I get the error: cu: write: Input/output error Yes, I did sleep 1000 < /dev/tty01 &, and stty -f /dev/tty01 clocal and invoked "cu" correctly. (I used it extensively under FreeBSD) Yet, I still get this error. I also noticed in the new /dev directory, that there is a /dev/io. I happen to have a DigiComm SoftModem 144+ modem in which a DSP chip holds the info for the modem to be used, which is usually downloaded to the modem DSP when I boot up in DOS. This sucks, cause anytime I wanted to use my modem in *BSD, I had to boot up in DOS, and then warm-boot into *BSD, since the info should still be in the chip unless I do a hard reset. However, the somewone ported this downloading program for Linux, and I thought all was saved as Mike Long had hacked a port that should have worked for NetBSD, yet it did not work since at that time there was no working /dev/io for NetBSD. Does it work now?? Anyway, what does anyone think would be the cause of the error message when I try to type commands into my modem?? BTW, the "cu" automatically disconnects after the error message. Can anyone help me?? Any tips would be greatly appreciated! Sincerely, ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 10 23:23:01 1994 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.903:10.07.94.12.39.52] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: XServer f... From: "hamish (h.i.) macdonald" To: sunrise@winternet.mpls.mn.us Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: XServer for the retina and Novice stuff Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Tue Aug 9 17:37:00 1994, >>>>> James Melin wrote: sunrise> Also, since I don't have an MMU on my machine (yet) I cannot sunrise> alas, run NetBSD (if my understanding is correct), so I am sunrise> looking for the linux port to see if that will get me by sunrise> until such time as I can get a better CPU card. Linux/68k absolutely requires an MMU as well. sunrise> What I am wondering specifically is, will linux/NetBSD sunrise> support the Retina gfx card so that I can run Xwindows et al? Linux/68k will not support the Retina until someone adds support to it. The kernel already has support for different frame buffer types. If someone sends me a Retina and documentation, I will write the support. Linux/68k currently has no support for X-windows. sunrise> And secondly, is the Linux 1.0 beta available to test? If so, sunrise> where can I find it (have not been able to latch onto it. Linux/68k 0.9pl1 is currently available from tsx-11.mit.edu:/pub/linux/680x0. It is "compatible" with Linux/PC 1.0.9. Read all the ANNOUNCE-* files you find there. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:23:30 1994 To: Mark Steven de Sagun-Tamola Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions... From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 1. I get this annoying message every time I boot up: > Aug 10 02:06:24 melissa init: kernel security level changed from 0 to 1 > How do I stop this message from reappearing all the time every time I > reboot?? I suspect it has something to do with the way I extracted the > binary shots, as I recall some error rolling by as it extracted init. > Anyway, is there a way to fix it? You "fix" this by getting the source to init and removing either the printf (if you just value an empty console screen) or the code that changes the kernel security level (if you want to passively encourage hackers on your system). The message is not related to any error, it is deliberate. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:37:51 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu, port-sparc@sun-lamp.cs.berkeley.edu Subject: NetBSD/sparc diskless problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've got a SPARC here running NetBSD. The hope is to run NetBSD on our diskless SPARCs, so I've been working with the diskless support. And of course I have a problem. (Details of code currency and machine environment at the end of this note.) Essentially, it hangs at a random time. Sometimes this is as soon as a couple of lines of output after the fsck finishes (there's disk on it, and I have it set to mount some of it even when it boots diskless); once it got far enough to print a login prompt on the console before going catatonic. Usually it's somewhere in between - but not at a repeatable place. I've tried investigating some, but learning enough about the diskless support to direct the investigations intelligently would take quite a lot of time, hence this note. I have ddb in the kernel, but it does not appear to know about the kernel's symbol table, which makes stack traces less than wonderful. (On looking at the ddb code, it appears to know how to deal with symbol tables, but for whatever reason it isn't recognizing or printing any symbol names.) The hang is fairly soft; L1-A breaks to ddb (or the ROM monitor, before I started building ddb into the kernel). I used another Sun on that same Ethernet segment to watch the network traffic, and nothing sticks out as significant. The boot server (a 4.1.2 SunOS machine) keeps asking the NetBSD machine for its mount RPC port, which the NetBSD machine keeps returning failures for, but that starts well before the point of the hang. Would anyone care to point me at useful place to start investigating? My inclination at this point is to either look at ddb's symbol table code in more detail (and perhaps add a way for user-land to spoon-feed it the kernel symbol table - an LKM containing nothing but a symbol table maybe), or else resort to writing down the stack trace in hex and working out symbol offsets myself, and hope the stack trace points me in a useful direction. The machine is a SPARCstation IPC. The kernel is built from sources up-to-date as of a day or two ago; user-land is from the SPARC binary tars of August 1st. The diskless root area was created by cloning the diskful root+usr tree and tweaking things like /etc/fstab. Machine configuration as indicated by boot messages (from a diskful boot; diskless boot is identical except for the boot command used): note: lost 33 pages in translation Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. NetBSD 1.0_BETA (CALLISTO) #0: Mon Aug 8 13:30:18 EDT 1994 mouse@Callisto.McRCIM.McGill.EDU:/sources/working-usr-src/sys/arch/sparc/compile/CALLISTO real mem = 11993088 avail mem = 10194944 using 146 buffers containing 598016 bytes of memory mainbus0 (root) cpu0 at mainbus0: SUNW,Sun 4/40 (MB86900/1A or L64801 @ 25 MHz, WTL3170/2 FPU) cpu0: 65536 byte write-through, 16 bytes/line, sw flush cache enabled memreg0 at mainbus0 ioaddr 0xf4000000 clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom) timer0 at mainbus0 ioaddr 0xf3000000 zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6 zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6 audio0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4 auxreg0 at mainbus0 ioaddr 0xf7400003 sbus0 at mainbus0 ioaddr 0xf8000000: clock = 25 MHz dma0 at sbus0 slot 0 offset 0x400000: rev 1 esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100A, clock = 25 MHz, ID = 7 tg0 at esp0 target 3 sd0 at tg0 unit 0: SEAGATE ST41600N 0030, 2676846 512 byte blocks sd0: le0 at sbus0 slot 0 offset 0xc00000 pri 5: hardware address 08:00:20:10:44:eb bwtwo0 at sbus0 slot 3 offset 0x0: SUNW,501-1561, 1152 x 900 (console) fd at mainbus0 ioaddr 0xf7200000 not configured Found boot device sd0 More details gladly supplied on request. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:43:16 1994 To: Mark Steven de Sagun-Tamola Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu > BTW, one additional thing I might have missed concerning problem #2 was > that I have not configured the correct /dev files for dial out ports > (i.e. wrong major/minor numbers, etc.) Being the forgetful one I am, how > would/could I change my MAKEDEV file to correctly "mknod" me some dial > out ports (if this is actually the cause of my problem, but still would > be helpful info!). I don't think the `wrong' minor number hack works with the current com.c (of course, Theo will now say it was fixed two days back:). Hacking this in would be easy. Speaking of com.c is anyone working on a rewrite. I am tempted.... What kind of things people want in it? Bakul From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 10 23:47:11 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: mountd and netgroups From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is anyone exporting a filesystem to one (or more) netgroups? Here is my system: (an HP 380) NetBSD 1.0_BETA (SANTIAM) #2: Mon Aug 8 23:20:19 PDT 1994 thorpej@nemesis:/usr/src/sys/arch/hp300/compile/SANTIAM Here is the filesystem I'm tring to export: /dev/ccd0c 1079950 168318 857634 16% /info Here is /etc/exports: /info -maproot=root INST-HPS Here is the netgroup entry: (All one line...Works on our 700s just fine) INST-HPS (xanth.CS.ORST.EDU,,) (xanth,,) (mundania.CS.ORST.EDU,,) (mundania,,) ( prism.CS.ORST.EDU,,) (prism,,) (santiam.CS.ORST.EDU,,) (santiam,,) (typhoon.CS.O RST.EDU,,) (typhoon,,) (fender.CS.ORST.EDU,,) (fender,,) (strat.CS.ORST.EDU,,) ( strat,,) (gibson.CS.ORST.EDU,,) (gibson,,) (lespaul.CS.ORST.EDU,,) (lespaul,,) ...produces the following error: Aug 10 11:12:16 santiam mountd[29799]: Can't change attributes for /info. Aug 10 11:12:16 santiam mountd[29799]: Bad exports list line /info -maproot ...Ok...Remove the -maproot=root... Aug 10 11:19:26 santiam mountd[29799]: Can't change attributes for /info. Aug 10 11:19:26 santiam mountd[29799]: Bad exports list line /info INST-HPS Well, putting -maproot back and specifying either hostnames or network and mask works just A-OK... My application more or less requires the use of netgroups, as there are roughly several-hundred hosts on about 10 networks that will have access to this filesystem...Lots of typing :-) So, did I miss something? Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 11 00:01:15 1994 Subject: A2232 driver To: amiga@sun-lamp.cs.berkeley.edu From: Jukka Marin 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: 1090 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Dear All, I am going to set up a public access UNIX system using NetBSD and A3000. The problem is that I need several serial ports (one for the SLIP connection, two or more for modem lines). I have A2232 boards which I would like to use for this purpose. I ask - no, I _beg_ the person who has written a NetBSD driver for the A2232 board to please contact me. I know that the 6502 code he is using is copyrighted by Commodore - but I'd like to write my own, freely distributable code to replace the copyrighted part. It's just that I need more serial ports as soon as possible. Any help greatly appreciated, Jukka Marin -- | Mail: Jukka Marin | E-Mail: jmarin@messi.uku.fi | | Metsurintie 17 B 8 | FAX/voice: +358 71 283 2793 | | 70150 Kuopio | There's God above computers - | | FINLAND | Love beyond the hate | \ / \ If a train station is where the train stops, what is a workstation? / From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 00:28:35 1994 From: Mike Long To: buckwild@u.washington.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions... Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Wed, 10 Aug 1994 02:21:34 -0700 (PDT) >From: Mark Steven de Sagun-Tamola >Aug 10 02:06:24 melissa init: kernel security level changed from 0 to 1 > >How do I stop this message from reappearing all the time every time I >reboot?? I suspect it has something to do with the way I extracted the >binary shots, as I recall some error rolling by as it extracted init. >Anyway, is there a way to fix it? It's an informational message from /sbin/init. AFAIK, you can't get rid of it unless you want to hack it out of the source. BTW, The usual way I deal with binary snapshots is to unpack them somewhere else in my tree (e.g. /usr/new), shutdown to single-user mode, and then update /bin and /sbin with: mv /bin/mv /bin/sh /sbin/init /tmp /tmp/mv /usr/new/bin/* /bin /tmp/mv /usr/new/sbin/* /sbin reboot >2. Every time I try to type in commands to my modem, using "cu", I get >the error: > >cu: write: Input/output error I recall reading something to the effect that you could fix this by creating an /etc/uucp/ports file (see Taylor UUCP docs). >.... However, the somewone ported this downloading >program for Linux, and I thought all was saved as Mike Long had hacked a >port that should have worked for NetBSD, yet it did not work since at >that time there was no working /dev/io for NetBSD. Does it work now?? I don't know, the code I ported is still lingering somewhere on my machine at home. I'll check it out. Kermit, BTW, works fine for me. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 01:00:46 1994 To: Bakul Shah Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <199408102005.NAA17495@netcom9.netcom.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I don't think the `wrong' minor number hack works with the current >com.c (of course, Theo will now say it was fixed two days back:). >Hacking this in would be easy. Speaking of com.c is anyone working >on a rewrite. I am tempted.... What kind of things people want >in it? I think the current version of com.c works pretty well; if it had call-out devices, that would excellent, but it hasn't proved to be a major stumbling block yet. --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 11 01:02:36 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Tim's multiple chunk changes for -current Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu OK, here's the diff I promised. Note however it isn't absolutely current as I'm not currently tracking current. I believe it's quite easy to merge anyway as not much has happened in these parts from what I can remember. Niklas =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/include/pmap.h,v retrieving revision 1.1.1.6 diff -c -r1.1.1.6 pmap.h *** 1.1.1.6 1994/06/12 21:19:57 --- pmap.h 1994/07/11 12:44:00 *************** *** 36,42 **** * SUCH DAMAGE. * * @(#)pmap.h 7.6 (Berkeley) 5/10/91 ! * $Id: pmap.h,v 1.1.1.6 1994/06/12 21:19:57 root Exp $ */ #ifndef _MACHINE_PMAP_H_ #define _MACHINE_PMAP_H_ --- 36,42 ---- * SUCH DAMAGE. * * @(#)pmap.h 7.6 (Berkeley) 5/10/91 ! * $Id: pmap.h,v 1.1.1.1.2.6 1994/07/11 12:44:00 root Exp $ */ #ifndef _MACHINE_PMAP_H_ #define _MACHINE_PMAP_H_ *************** *** 95,101 **** --- 95,105 ---- u_int *Sysmap; char *vmmap; /* map for mem, dumps, etc. */ + #ifdef MACHINE_NONCONTIG + #define pa_index pmap_page_index + #else #define pa_index(pa) atop(pa - vm_first_phys) + #endif #define pa_to_pvh(pa) (&pv_table[pa_index(pa)]) #define pmap_resident_count(pmap) ((pmap)->pm_stats.resident_count) #endif KERNEL =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/amiga/pmap.c,v retrieving revision 1.1.1.10 diff -c -r1.1.1.10 pmap.c *** 1.1.1.10 1994/06/21 23:56:03 --- pmap.c 1994/07/11 12:43:13 *************** *** 35,41 **** * SUCH DAMAGE. * * @(#)pmap.c 7.5 (Berkeley) 5/10/91 ! * $Id: pmap.c,v 1.1.1.10 1994/06/21 23:56:03 root Exp $ */ /* --- 35,41 ---- * SUCH DAMAGE. * * @(#)pmap.c 7.5 (Berkeley) 5/10/91 ! * $Id: pmap.c,v 1.1.1.1.2.10 1994/07/11 12:43:13 root Exp $ */ /* *************** *** 144,149 **** --- 144,165 ---- int pmapdebug = PDB_PARANOIA; #endif + #ifdef MACHINE_NONCONTIG + #include "memlist.h" + + /* + * contiguous chunk management + */ + #define MAX_CHUNKS 16 /* max supported chunks of contiguous memory */ + struct { + vm_offset_t start, end; + unsigned int first_page, pages; + } chunk[MAX_CHUNKS]; + int current_chunk = 0; + int num_chunks; + vm_offset_t chunk_pos; + #endif /* MACHINE_NONCONTIG */ + /* * Get STEs and PTEs for user/kernel address space */ *************** *** 250,255 **** --- 266,276 ---- extern vm_offset_t maxmem, physmem; vm_offset_t va; u_int *pte; + #ifdef MACHINE_NONCONTIG + extern struct boot_memlist *memlist; + extern z2mem_start, z2mem_end; + int i, page; + #endif avail_start = firstaddr; avail_end = maxmem << PGSHIFT; *************** *** 257,262 **** --- 278,318 ---- /* XXX: allow for msgbuf */ avail_end -= amiga_round_page(sizeof(struct msgbuf)); + #ifdef MACHINE_NONCONTIG + for(i=0, num_chunks=0, page=0; + im_nseg && im_seg[i].ms_attrib & MEMF_CHIP) != MEMF_CHIP) { + chunk[num_chunks].start = memlist->m_seg[i].ms_start; + chunk[num_chunks].end = chunk[num_chunks].start + + memlist->m_seg[i].ms_size; + chunk[num_chunks].first_page = page; + + /* + * check for special chunks + * like boot chunk and zorroII mem + * and account for any stolen memory + */ + if(avail_start >= chunk[num_chunks].start && + avail_start < chunk[num_chunks].end) { + chunk[num_chunks].start = avail_start; + chunk[num_chunks].end = avail_end; + } + if(z2mem_end && z2mem_end >= chunk[num_chunks].start && + z2mem_end < chunk[num_chunks].end) { + chunk[num_chunks].start = z2mem_start; + chunk[num_chunks].end = z2mem_end; + } + chunk[num_chunks].pages = + atop(chunk[num_chunks].end - chunk[num_chunks].start); + page += chunk[num_chunks].pages; + num_chunks++; + } + } + chunk_pos = chunk[0].start; + current_chunk = 0; + physmem = page; + #endif + mem_size = physmem << PGSHIFT; virtual_avail = VM_MIN_KERNEL_ADDRESS + (firstaddr - loadaddr); virtual_end = VM_MAX_KERNEL_ADDRESS; *************** *** 338,343 **** --- 394,449 ---- return((void *) val); } + #ifdef MACHINE_NONCONTIG + /* + * number of pages left (unallocated) + */ + unsigned int + pmap_free_pages() + { + int i, x; + + if(current_chunk >= num_chunks) + return(0); + + /* pages in current chunk */ + x = atop(chunk[current_chunk].end - chunk_pos); + + /* pages in remaining chunks */ + for(i=current_chunk+1; i= num_chunks) + return(FALSE); + *addrp = chunk_pos; + chunk_pos += PAGE_SIZE; + if(chunk_pos >= chunk[current_chunk].end) { + current_chunk++; + if(current_chunk < num_chunks) + chunk_pos = chunk[current_chunk].start; + } + return(TRUE); + } + + void + pmap_virtual_space(startp, endp) + vm_offset_t *startp; + vm_offset_t *endp; + { + *startp = virtual_avail; + *endp = virtual_end; + } + #endif /* * Initialize the pmap module. *************** *** 345,352 **** --- 451,462 ---- * system needs to map virtual memory. */ void + #ifdef MACHINE_NONCONTIG + pmap_init() + #else pmap_init(phys_start, phys_end) vm_offset_t phys_start, phys_end; + #endif { extern vm_offset_t amigahwaddr; extern u_int namigahwpg; *************** *** 354,364 **** --- 464,489 ---- vm_offset_t addr, addr2; vm_size_t npg, s; int rv; + #ifdef MACHINE_NONCONTIG + int i, size; + + for(i=0, size=0; i= chunk[i].start && pa < chunk[i].end) + return(1); + return(0); + } + + /* + * page index of a physical address + */ + unsigned int + pmap_page_index(pa) + vm_offset_t pa; + { + int i; + + for(i=0; i= chunk[i].start & pa < chunk[i].end) + return( atop(pa - chunk[i].start) + chunk[i].first_page); + /* this should never happen */ + panic("pmap_page_index: physical address is not in any chunk."); + } + #else + #define is_phys(pa) ((pa) >= vm_first_phys && (pa) < vm_last_phys) + #endif + /* * Used to map a range of physical addresses into kernel * virtual address space. *************** *** 767,773 **** * Remove from the PV table (raise IPL since we * may be called at interrupt time). */ ! if (pa < vm_first_phys || pa >= vm_last_phys) continue; pv = pa_to_pvh(pa); ste = (int *)0; --- 937,943 ---- * Remove from the PV table (raise IPL since we * may be called at interrupt time). */ ! if (!is_phys(pa)) continue; pv = pa_to_pvh(pa); ste = (int *)0; *************** *** 938,944 **** prot == VM_PROT_NONE && (pmapdebug & PDB_REMOVE)) printf("pmap_page_protect(%x, %x)\n", pa, prot); #endif ! if (pa < vm_first_phys || pa >= vm_last_phys) return; switch (prot) { --- 1108,1114 ---- prot == VM_PROT_NONE && (pmapdebug & PDB_REMOVE)) printf("pmap_page_protect(%x, %x)\n", pa, prot); #endif ! if (!is_phys(pa)) return; switch (prot) { *************** *** 1164,1170 **** * Note that we raise IPL while manipulating pv_table * since pmap_enter can be called at interrupt time. */ ! if (pa >= vm_first_phys && pa < vm_last_phys) { register pv_entry_t pv, npv; int s; --- 1334,1340 ---- * Note that we raise IPL while manipulating pv_table * since pmap_enter can be called at interrupt time. */ ! if (is_phys(pa)) { register pv_entry_t pv, npv; int s; *************** *** 1426,1431 **** --- 1596,1604 ---- register int *pte; vm_offset_t kpa; int s; + #ifdef MACHINE_NONCONTIG + int i; + #endif #ifdef DEBUG int *ste; *************** *** 1440,1446 **** --- 1613,1624 ---- kpt_stats.collectscans++; #endif s = splimp(); + #ifdef MACHINE_NONCONTIG + for(i=0; i= vm_last_phys) return; pv = pa_to_pvh(pa); if (pv->pv_ptste == NULL) --- 1803,1809 ---- if (!pmap_ste_v(pmap_ste(pmap, sva))) return; pa = pmap_pte_pa(pmap_pte(pmap, sva)); ! if (!is_phys(pa)) return; pv = pa_to_pvh(pa); if (pv->pv_ptste == NULL) *************** *** 1768,1774 **** register int *pte; int s; ! if (pa < vm_first_phys || pa >= vm_last_phys) return(FALSE); pv = pa_to_pvh(pa); --- 1949,1955 ---- register int *pte; int s; ! if (!is_phys(pa)) return(FALSE); pv = pa_to_pvh(pa); *************** *** 1816,1822 **** printf("pmap_changebit(%x, %x, %s)\n", pa, bit, setem ? "set" : "clear"); #endif ! if (pa < vm_first_phys || pa >= vm_last_phys) return; pv = pa_to_pvh(pa); --- 1997,2003 ---- printf("pmap_changebit(%x, %x, %s)\n", pa, bit, setem ? "set" : "clear"); #endif ! if (!is_phys(pa)) return; pv = pa_to_pvh(pa); =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/amiga/amiga_init.c,v retrieving revision 1.1.1.13 diff -c -r1.1.1.13 amiga_init.c *** 1.1.1.13 1994/07/02 15:58:03 --- amiga_init.c 1994/07/11 12:42:54 *************** *** 1,7 **** /* Authors: Markus Wild, Bryan Ford, Niklas Hallqvist * Michael L. Hitch - initial 68040 support * ! * $Id: amiga_init.c,v 1.1.1.13 1994/07/02 15:58:03 root Exp $ */ #include #include --- 1,7 ---- /* Authors: Markus Wild, Bryan Ford, Niklas Hallqvist * Michael L. Hitch - initial 68040 support * ! * $Id: amiga_init.c,v 1.1.1.1.2.14 1994/07/11 12:42:54 root Exp $ */ #include #include *************** *** 56,63 **** vm_offset_t amigahwaddr; u_int namigahwpg; ! static vm_offset_t z2mem_start; /* XXX */ ! static vm_offset_t z2mem_end; /* XXX */ int use_z2_mem = 1; /* XXX */ u_long boot_fphystart, boot_fphysize, boot_cphysize; --- 56,63 ---- vm_offset_t amigahwaddr; u_int namigahwpg; ! vm_offset_t z2mem_start; /* XXX */ ! vm_offset_t z2mem_end; /* XXX */ int use_z2_mem = 1; /* XXX */ u_long boot_fphystart, boot_fphysize, boot_cphysize; *************** *** 530,536 **** --- 530,538 ---- */ maxmem = pend >> PGSHIFT; lowram = fphystart >> PGSHIFT; + #ifndef MACHINE_NONCONTIG physmem = fphysize >> PGSHIFT; + #endif /* * get the pmap module in sync with reality. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 01:51:19 1994 To: Ken Hornstein Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <9408102128.AA18630@entropic.com> From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I think the current version of com.c works pretty well; if it had call-out > devices, that would excellent, but it hasn't proved to be a major stumbling > block yet. Even though I said `rewrite' I didn't _mean_ to say start from scratch. I would certainly steal all the good parts; most of com.c actually. For me not having callout devices *is* a stumbling block. Other than callout devices and perhaps using one bit of the minor for modem control, it also needs some low level support for improved performance. I have seen and helped make a V7 Unix running on a 5.5Mhz 68000 simulteneously handle four 19.2K lines (using 2Mhz Zilog DARTs) doing inputs and outputs at close to full bandwidth without dropping chars. Surely we can do better than that 12 years later! From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 11 01:51:35 1994 From: "Guru" Subject: XServers for Linux & NetBSD To: "amiga" Sender: owner-amiga@sun-lamp.cs.berkeley.edu Date sent: 10-AUG-1994 I have an Amiga 3000 with 10 megs of Ram. I also have an EGS Spectrum gfx card. I am very interested in getting a unix system up on my Amiga. My main concern, however, is that I will be unable to run X-Windows except on my standard ECS display. I know that for NetBSD, the current XServers are for the Retina and Picasso boards. Now my question is... With the further development of Linux/68k will an EGS Spectrum XServer be developed (i.e. Are there any plans for one in the near future?). I also ask the same question regarding NetBSD... I would be more than willing to beta test any Xservers that come along for either operating system. And more than likely, my choice of operating system will be determined by which one (Linux/68k or NetBSD) an EGS Spectrum X-Server is developed for. I am sure many of the other Spectrum owners looking to run unix will also tend to do the same. Any comments or help would be appreciated greatly.. --- Gene Ruebsamen + Computer Dept. Chair, ERA Champion Realty. + Email: gdruebsamen@vmsa.is.csupomona.edu The views that I express are not necessarily those of my employer. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 11 02:27:45 1994 From: Eric Augustine Subject: Boot Requestor To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Developer's news-list Amiga-Dev) X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 983 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm sure something simlar exists out there but, I didn't find it and it was simple to write - it should work no matter what your setup. For those of you who'd like to have a requestor that comes up to allow you to select either NetBSD or AmigaDOS - I wrote a small prog using ReqTools (reqtools.library version 38.810) - I put it out at AmiNet today (called breq.lha) it'll probably take about a week to show up - if you are interested - Just send me a message and I'll send you back a uuencoded archive with the source and the binary (And a miserable little readme :) I have it in the Startup-Sequence right after C:SetPatch so I don't go through everything to boot NetBSD right away. The newer versions of NetBSD might obsolete such a thing (I'm still using #744 with the #720 binaries). I'm posting this initially to the developer's group so that if you guys have any objections to it I won't post to the owner's group. Thanks - - Eric. uairk@mcl.mcl.ucsb.edu From owner-tech-kern@sun-lamp.cs.berkeley.edu Thu Aug 11 02:46:23 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Cc: tech-kern@sun-lamp.cs.berkeley.edu, buhrow@cats.ucsc.edu Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu I'm writing to ask if anyone knows about the technical behavior of the AST 4-port serial card and, if so, if they'd be willing to answer a few questions I have concerning the card. First, let me say that this explanation will be somewhat long, so please bear with me. I have an AST 4-port card which I am running on my NetBSD-09a system. Since the system I'm running predates the actual official release of the ast driver, I decided to back-port it to my system. After about a week of not getting it to work, I decided to try bringing my system to current. When I did, I still couldn't get it to work. There seemed to be some weird interrupt thing going on, but since vmstat -i didn't work on the current system, I couldn't really see what it was. Finally, I went back to the old system and tweaked my back-port into enough of a functional state so that I could use the system with its serial ports. I noticed that if I used the traditional ports as well as the ports on the ast card, the machine would lock up very quickly, and, just before doing so, the serial ports would freeze. If I used only the ports on the card, they would work, but vmstat -i would show that interrupts were getting generated for com0 and com1 as well as for the ast card. Since there was no usage on the regular ports, I noticed that, if I used port 0 on the ast card, the interrupt count for com0 matched the interrupt count for the ast card. If I used the second port on the ast card, the interrupt count for com1 would match the interrupt count for the ast card. All this when the ast card is configured to run in enhanced mode. So, my first question is: 1. If the ast card is configured to run in enhanced mode, are its first two uarts supposed to generate irq requests on irq 4 and 3 respectively in addition to the multiplexed interrupt? If they are, is there some setting of the switches, or some magic register I need to poke to get them to stop? (See the end of this message for a transcript of sample vmstat figures.) Then I noticed that the ast card is generating a huge number of interrupts per second. This might be due to the fact that I'm not doing some reset properly in the interrupt handler, but that's my second question. 2. Is there some specific register I need to reset, when servicing an ast interrupt, which resets the master interrupt state so that it will actually stop interrupting until the next port on the board really needs servicing? I've looked at the ast driver for later versions of NetBSD, but don't quite see where it resets the interrupt. From what I can tell, it just calls the normal service handler for the com ports as they're needed. Since I'm still using the old com code (ported to a separate ast driver, rather than the com code for the current version of NetBSD), is there some impllicit resetthat takes place in the newer driver that did not get done in the old one? It might be that these two questions are related, but I'm not sure. If anyone can provide any helpful insights to these questions, I would be most appreciative. Thanks very much for any help in advance. ===technical information=== sources: February 2, 1994. system: 486dx/2 66 with 16MB RAM, 32MB swap. Technical info: Here is the specific information on vmstat. The machine has been up for about 15 hours and here is how the interrupts shake out. %uptime 4:52pm up 16:38, 1 user, load average: 0.02, 0.03, 0.00 %vmstat -i interrupt count rate stray irq 399 0 clk irq0 5990291 100 fdc0 irq6 1 0 bt0 irq11 35401 0 npx0 irq13 399 0 com0 irq4 222848363 3720 com1 irq3 864966 14 ast0 irq5 116723346 1948 is0 irq9 1 0 Total 346463167 5783 The stray interrupt is the result of me taking out the lpt driver to see if I could isolate the problem with my own ast driver. I don't know if the interrupt is actually being generated by the parallel port itself, but since the number of interrupts are so few, I could believe that they are actually coming from the parallel card. P.S. If anyone needs more technical information, please let me know. I'd love to dialogue with someone on this. -thanks -Brian From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 11 03:11:36 1994 From: Zik Saleeba Subject: Re: A2232 driver To: jmarin@messi.uku.fi (Jukka Marin) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1524 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Jukka Marin said: > > I ask - no, I _beg_ the person who has written a NetBSD driver for the > A2232 board to please contact me. I know that the 6502 code he is > using is copyrighted by Commodore - but I'd like to write my own, > freely distributable code to replace the copyrighted part. I've been meaning to get around to finishing this stuff sometime, but the impending end of my scholarship has made thesis work suddenly seem very important :-( What I currently have is a complete, commented, working source for the 65c02 driver, and a development environment with an assembler etc.. The sources are mostly the same as the Amiga UNIX ones, with various changes that I've made. The 68k part of the driver has evolved separately from Rob Healey's, and has the disadvantage that it's still set up for the 744 kernel I'm running on that machine. The advantage it has is that it works with the new 65c02 code, which Rob's won't. There are also some semantic tweaks which make it work more reliably with fallible modems (the bane of public access sites...) I'm not going to have time to do any work on this stuff for a couple of months at least, so I'm more than happy to hand it over to someone else. +-----------------------------------+----------------------------------------+ | zik@zikzak.apana.org.au | "A man with one watch knows the time; | | Zik Saleeba | but a man with two is never sure." | +-----------------------------------+----------------------------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 03:32:31 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: Ken Hornstein Cc: Bakul Shah , current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <9408102128.AA18630@entropic.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Bakul Shah writes: >>I don't think the `wrong' minor number hack works with the current >>com.c (of course, Theo will now say it was fixed two days back:). >>Hacking this in would be easy. Speaking of com.c is anyone working >>on a rewrite. I am tempted.... What kind of things people want >>in it? Ken Hornstein writes: >I think the current version of com.c works pretty well; if it had call-out >devices, that would excellent, but it hasn't proved to be a major stumbling >block yet. > >--Ken I would agree -- the current com ports seem to work just fine. I would seriously like calling units added, though. This would make life significantly easier for people who'd like to have incoming and outgoing things happening on their ports, without having to go through the /etc/ttys / kill -HUP 1 contortions currently required (not to mention the sleep < /dev/ttyxx stuff. In general, however, I have no complaints with the performance and reliability of the com.c drivers. On another note, I'm contemplating writing, or helping someone else write, a driver for the Hayes ESP cards using the full enhanced DMA mode. If anyone knows what they're doing WRT unix device drivers and kernel-mode code and would like to help, feel free to drop me a line. As I'm somewhat of a novice at this, please don't volunteer unless you know more than me... ;-) --Michael ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc. Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532 In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 03:34:19 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Cc: tech-kern@sun-lamp.cs.berkeley.edu, buhrow@cats.ucsc.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm writing to ask if anyone knows about the technical behavior of the AST 4-port serial card and, if so, if they'd be willing to answer a few questions I have concerning the card. First, let me say that this explanation will be somewhat long, so please bear with me. I have an AST 4-port card which I am running on my NetBSD-09a system. Since the system I'm running predates the actual official release of the ast driver, I decided to back-port it to my system. After about a week of not getting it to work, I decided to try bringing my system to current. When I did, I still couldn't get it to work. There seemed to be some weird interrupt thing going on, but since vmstat -i didn't work on the current system, I couldn't really see what it was. Finally, I went back to the old system and tweaked my back-port into enough of a functional state so that I could use the system with its serial ports. I noticed that if I used the traditional ports as well as the ports on the ast card, the machine would lock up very quickly, and, just before doing so, the serial ports would freeze. If I used only the ports on the card, they would work, but vmstat -i would show that interrupts were getting generated for com0 and com1 as well as for the ast card. Since there was no usage on the regular ports, I noticed that, if I used port 0 on the ast card, the interrupt count for com0 matched the interrupt count for the ast card. If I used the second port on the ast card, the interrupt count for com1 would match the interrupt count for the ast card. All this when the ast card is configured to run in enhanced mode. So, my first question is: 1. If the ast card is configured to run in enhanced mode, are its first two uarts supposed to generate irq requests on irq 4 and 3 respectively in addition to the multiplexed interrupt? If they are, is there some setting of the switches, or some magic register I need to poke to get them to stop? (See the end of this message for a transcript of sample vmstat figures.) Then I noticed that the ast card is generating a huge number of interrupts per second. This might be due to the fact that I'm not doing some reset properly in the interrupt handler, but that's my second question. 2. Is there some specific register I need to reset, when servicing an ast interrupt, which resets the master interrupt state so that it will actually stop interrupting until the next port on the board really needs servicing? I've looked at the ast driver for later versions of NetBSD, but don't quite see where it resets the interrupt. From what I can tell, it just calls the normal service handler for the com ports as they're needed. Since I'm still using the old com code (ported to a separate ast driver, rather than the com code for the current version of NetBSD), is there some impllicit resetthat takes place in the newer driver that did not get done in the old one? It might be that these two questions are related, but I'm not sure. If anyone can provide any helpful insights to these questions, I would be most appreciative. Thanks very much for any help in advance. ===technical information=== sources: February 2, 1994. system: 486dx/2 66 with 16MB RAM, 32MB swap. Technical info: Here is the specific information on vmstat. The machine has been up for about 15 hours and here is how the interrupts shake out. %uptime 4:52pm up 16:38, 1 user, load average: 0.02, 0.03, 0.00 %vmstat -i interrupt count rate stray irq 399 0 clk irq0 5990291 100 fdc0 irq6 1 0 bt0 irq11 35401 0 npx0 irq13 399 0 com0 irq4 222848363 3720 com1 irq3 864966 14 ast0 irq5 116723346 1948 is0 irq9 1 0 Total 346463167 5783 The stray interrupt is the result of me taking out the lpt driver to see if I could isolate the problem with my own ast driver. I don't know if the interrupt is actually being generated by the parallel port itself, but since the number of interrupts are so few, I could believe that they are actually coming from the parallel card. P.S. If anyone needs more technical information, please let me know. I'd love to dialogue with someone on this. -thanks -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 04:52:30 1994 From: John Kohl To: michaelv@HeadCandy.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> "Michael" == Michael L VanLoon <-- Iowa State University" > writes: Michael> life significantly easier for people who'd like to have incoming and Michael> outgoing things happening on their ports, without having to go through Michael> the /etc/ttys / kill -HUP 1 contortions currently required (not to Michael> mention the sleep < /dev/ttyxx stuff. ??? I don't require any of that stuff. I guess the stick in the mud must be getty. I use FlexFAX to answer the phone for FAX or to exec a getty. It sits on the line just fine, passively, and yields whenever I crank up UUCP or PPP or Kermit, all of which just create a lock file in the appropriate place. Seems like a getty which camps out waiting for input, and then takes the lock before reading input (waiting and resetting if the lock is held), would do the trick. No need for kernel hackery at all! ==John From owner-tech-kern@sun-lamp.cs.berkeley.edu Thu Aug 11 04:58:34 1994 To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED <199408110011.RAA12352@baloo.ucsc.edu> From: Bill Sommerfeld Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu Do you have "flags 1" on the com? devices which are on the AST card? This causes the com driver to *not* assert MCR_IENABLE, which is necessary in order for the devices to interrupt properly in enhanced mode. I made the mistake once of off the flags and saw failures similar to what you were seeing (I think caused by interrupt conflicts..) Perhaps the ast driver should force `flags 1' for it's slaves... Here's the relevant section out of my config file.. device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 master ast0 at isa? port 0x1a0 irq 5 device com2 at ast0 slave 0 flags 1 device com3 at ast0 slave 1 flags 1 device com4 at ast0 slave 2 flags 1 device com5 at ast0 slave 3 flags 1 - Bill From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 11 05:45:00 1994 From: Howard Dobson Subject: binpatch and 1.0 To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have been running a kernel from back around the april time frame. In order to get it or any previous kernels to work I have had to binpatch _scsi_no_dma and muck around with _inhibit_sync as well. Well I downloaded all the stuff for 1.0, when I try to boot it stops while scanning for my disks. (In the past this was the same behavior I got when I did not binpatch the kernel). So I try to binpatch -l -s _scsi_no_dma netbsd and I get Symbol not found. same way with _inhibit_sync same results with netbsd-almostgeneric.940721 and netbsd.a3000-940726 Are these symbols obselete? I scanned through the mailing list and did not see any discussion about them going away. My binpatch is probably the original binpatch (is there a new one?) Did I miss something? Howard W. Dobson hwdobso@afterlife.ncsc.mil From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 05:57:29 1994 To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED <199408110011.RAA12352@baloo.ucsc.edu> From: Bill Sommerfeld Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do you have "flags 1" on the com? devices which are on the AST card? This causes the com driver to *not* assert MCR_IENABLE, which is necessary in order for the devices to interrupt properly in enhanced mode. I made the mistake once of off the flags and saw failures similar to what you were seeing (I think caused by interrupt conflicts..) Perhaps the ast driver should force `flags 1' for it's slaves... Here's the relevant section out of my config file.. device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 master ast0 at isa? port 0x1a0 irq 5 device com2 at ast0 slave 0 flags 1 device com3 at ast0 slave 1 flags 1 device com4 at ast0 slave 2 flags 1 device com5 at ast0 slave 3 flags 1 - Bill From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 11 06:01:04 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Tim Newsham , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: upgrade to 1.0 [non-contiguous memory diffs] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 8, 7:16pm, Tim Newsham wrote: > > (btw.. can I get diffs for non-contig memory handling with the new > kernels from someone who has already got it up and running?) > Here's a set of diffs for the non-contiguous memory support I'm working with. It's based on Tim's original changes, but I've done some things differently. Non-contiguous memory support is enabled with the config option MEMORY_NONCONTIG. The Zorro II memory usage has been modified so that DMA bounce buffers can still be used. The flag use_z2_mem now specifies the number of MAXPHYS segments of Zorro II memory to reserve for DMA bounce buffers. The rest of the Zorro II memory is then available to be used as pageable memory. The first memory segment is the memory segment that NetBSD was loaded into, irregardless of it's position in the memory list. [At least that's the way it should work. On all my systems, the largest segment is also the highest priority and the first entry in the memory list, so I haven't verified that this works the way I intended it to.] A few comments about these diffs: The machdep.c changes also include some initial support for the A4091 SCSI board. These will need to be removed after applying the diffs [I was too lazy to make a diff from a file without these changes]. The code that sets up the segments currently only allocates two segments, and it will skip the A4000 motherboard memory. [That's so the second segment is allocated from the Zorro II memory, which has a nasty little problem]. I've had some trouble getting the Zorro II memory to work on my A4000. I get various panics in the pmap routines. It works fine if the second segment is the A4000 motherboard memory, and the Zorro II memory works fine on my A2000/Zeus system. I haven't had the time to try and figure out what is going on. [This is why the code currently allocates two segments and skips the motherboard segment - the diffs reflect the configuration that fails on my system.] Michael diff -cr /mnt/src/sys/arch/amiga/amiga/amiga_init.c /sys/arch/amiga/amiga/amiga_init.c *** /mnt/src/sys/arch/amiga/amiga/amiga_init.c Thu Jun 30 10:34:03 1994 --- /sys/arch/amiga/amiga/amiga_init.c Sun Jul 31 11:38:34 1994 *************** *** 168,174 **** * Get ZorroII (16-bit) memory if there is any and it's not where the * kernel is loaded. */ ! if (memlist->m_nseg > 0 && memlist->m_nseg < 16) { struct boot_memseg *sp, *esp; sp = memlist->m_seg; --- 168,174 ---- * Get ZorroII (16-bit) memory if there is any and it's not where the * kernel is loaded. */ ! if (memlist->m_nseg > 0 && memlist->m_nseg < 16 && use_z2_mem) { struct boot_memseg *sp, *esp; sp = memlist->m_seg; *************** *** 179,187 **** continue; if (sp->ms_start == fphystart) continue; ! z2mem_start = sp->ms_start; ! NZTWOMEMPG = sp->ms_size / NBPG; ! z2mem_end = z2mem_start + sp->ms_size; break; } } --- 179,191 ---- continue; if (sp->ms_start == fphystart) continue; ! z2mem_end = sp->ms_start + sp->ms_size; ! z2mem_start = z2mem_end - MAXPHYS * use_z2_mem; ! NZTWOMEMPG = (z2mem_end - z2mem_start) / NBPG; ! if ((z2mem_end - z2mem_start) > sp->ms_size) { ! NZTWOMEMPG = sp->ms_size / NBPG; ! z2mem_start = z2mem_end - sp->ms_size; ! } break; } } diff -cr /mnt/src/sys/arch/amiga/amiga/machdep.c /sys/arch/amiga/amiga/machdep.c *** /mnt/src/sys/arch/amiga/amiga/machdep.c Mon Jul 18 10:49:13 1994 --- /sys/arch/amiga/amiga/machdep.c Tue Aug 2 21:15:44 1994 *************** *** 109,117 **** --- 109,119 ---- #include "ser.h" #include "idesc.h" #include "ether.h" + #include "afsc.h" /* vm_map_t buffer_map; */ extern vm_offset_t avail_end; + extern vm_offset_t avail_start; /* * Declare these as initialized data so we can patch them. *************** *** 143,149 **** /* the following is used externally (sysctl_hw) */ char machine[] = "amiga"; - #ifdef COMPAT_SUNOS void sun_sendsig (); #endif --- 145,150 ---- *************** *** 200,205 **** --- 201,213 ---- #endif vm_offset_t minaddr, maxaddr; vm_size_t size; + #ifdef MACHINE_NONCONTIG + extern struct { + vm_offset_t start; + vm_offset_t end; + int first_page; + } phys_segs[16]; + #endif /* * Initialize error message buffer (at end of core). *************** *** 383,388 **** --- 391,404 ---- printf("memory segment %d at %08lx size %08lx\n", i, memlist->m_seg[i].ms_start, memlist->m_seg[i].ms_size); + #ifdef MACHINE_NONCONTIG + printf ("Physical memory segments:\n"); + for (i = 0; phys_segs[i].start; ++i) + printf ("Physical segment %d at %08lx size %d pages %d\n", i, + phys_segs[i].start, + (phys_segs[i].end - phys_segs[i].start) / NBPG, + phys_segs[i].first_page); + #endif /* * Set up CPU-specific registers, cache, etc. */ *************** *** 1182,1187 **** --- 1198,1204 ---- { printf("unexpected trap (vector offset %x) from %x\n", evec & 0xFFF, pc); + /*XXX*/ panic("straytrap"); } int *nofault; *************** *** 1418,1423 **** --- 1435,1444 ---- if (wesc_dmaintr()) goto intports_done; #endif + #if NAFSC > 0 + if (afsc_dmaintr()) + goto intports_done; + #endif #if NWSTSC > 0 if (wstsc_intr()) goto intports_done; *************** *** 1648,1651 **** #endif return(error); } - --- 1669,1671 ---- diff -cr /mnt/src/sys/arch/amiga/amiga/pmap.c /sys/arch/amiga/amiga/pmap.c *** /mnt/src/sys/arch/amiga/amiga/pmap.c Tue Jun 21 10:20:50 1994 --- /sys/arch/amiga/amiga/pmap.c Mon Aug 1 22:10:00 1994 *************** *** 85,90 **** --- 85,91 ---- #include #include #include + #include /* * Allocate various and sundry SYSMAPs used in the days of old VM * and not yet converted. XXX. *************** *** 220,228 **** --- 221,241 ---- char *pmap_attributes; /* reference and modify bits */ static int pmap_ishift; /* segment table index shift */ + #ifdef MACHINE_NONCONTIG + struct physeg { + vm_offset_t start; + vm_offset_t end; + int first_page; + } phys_segs[16]; + + static vm_offset_t avail_next; + static vm_size_t avail_remaining; + #endif + boolean_t pmap_testbit(); void pmap_enter_ptpage(); + #define pmap_valid_page(pa) (pmap_initialized && pmap_page_index(pa) >= 0) /* * All those kernel PT submaps that BSD is so fond of *************** *** 250,255 **** --- 263,272 ---- extern vm_offset_t maxmem, physmem; vm_offset_t va; u_int *pte; + #ifdef MACHINE_NONCONTIG + int i; + struct boot_memseg *sp, *esp; + #endif avail_start = firstaddr; avail_end = maxmem << PGSHIFT; *************** *** 256,261 **** --- 273,307 ---- /* XXX: allow for msgbuf */ avail_end -= amiga_round_page(sizeof(struct msgbuf)); + #ifdef MACHINE_NONCONTIG + avail_next = avail_start; + avail_remaining = (avail_end - avail_start) >> PGSHIFT; + phys_segs[0].start = avail_start; + phys_segs[0].end = avail_end; + sp = memlist->m_seg; + esp = sp + memlist->m_nseg; + i = 1; + for (; sp < esp; sp++) { + if ((sp->ms_attrib & MEMF_FAST) == 0) + continue; + if (avail_start >= sp->ms_start && avail_start < + sp->ms_start + sp->ms_size) + continue; + /* deal with Zorro II memory stolen for DMA bounce buffers */ + phys_segs[i].start = sp->ms_start; + phys_segs[i].end = sp->ms_start + sp->ms_size; + #if 1 + if (phys_segs[i].end == 0x08000000) continue; /* skip A4000 motherboard mem */ + if (phys_segs[i].start == 0x00200000) phys_segs[i].end -= MAXPHYS; + #endif + phys_segs[i].first_page = phys_segs[i - 1].first_page + + (phys_segs[i - 1].end - phys_segs[i - 1].start) / NBPG; + avail_remaining += (phys_segs[i].end - phys_segs[i].start) / NBPG; + physmem += (phys_segs[i].end - phys_segs[i].start) / NBPG; + ++i; + break; /* XXX only two segments for now */ + } + #endif mem_size = physmem << PGSHIFT; virtual_avail = VM_MIN_KERNEL_ADDRESS + (firstaddr - loadaddr); *************** *** 345,352 **** --- 391,402 ---- * system needs to map virtual memory. */ void + #ifdef MACHINE_NONCONTIG + pmap_init() + #else pmap_init(phys_start, phys_end) vm_offset_t phys_start, phys_end; + #endif { extern vm_offset_t amigahwaddr; extern u_int namigahwpg; *************** *** 357,364 **** --- 407,418 ---- #ifdef DEBUG if (pmapdebug & PDB_FOLLOW) + #ifdef MACHINE_NONCONTIG + printf("pmap_init(%x, %x)\n", avail_start, avail_end); + #else printf("pmap_init(%x, %x)\n", phys_start, phys_end); #endif + #endif /* * Now that kernel map has been allocated, we can mark as * unavailable regions which we have mapped in locore. *************** *** 401,407 **** --- 455,471 ---- * Allocate memory for random pmap data structures. Includes the * initial segment table, pv_head_table and pmap_attributes. */ + #ifdef MACHINE_NONCONTIG + { + int i; + for (npg = 0, i = 0; phys_segs[i].start; ++i) + npg += atop(phys_segs[i].end - phys_segs[i].start); + } + printf ("pmap_init: avail_start %08x phys_segs[0].start %08x npg %d\n", + avail_start, phys_segs[0].start, npg); + #else npg = atop(phys_end - phys_start); + #endif #ifdef M68040 if (cpu040) s = (vm_size_t)AMIGA_040STSIZE * 128 + *************** *** 496,506 **** --- 560,631 ---- /* * Now it is safe to enable pv_table recording. */ + #ifdef MACHINE_NONCONTIG + vm_first_phys = avail_start; + vm_last_phys = avail_end; + #else vm_first_phys = phys_start; vm_last_phys = phys_end; + #endif pmap_initialized = TRUE; } + #ifdef MACHINE_NONCONTIG + unsigned int + pmap_free_pages() + { + + return avail_remaining; + } + + int + pmap_next_page(addrp) + vm_offset_t *addrp; + { + static int cur_seg = 0; + + if (phys_segs[cur_seg].start == 0) + return FALSE; + if (avail_next == phys_segs[cur_seg].end) { + avail_next = phys_segs[++cur_seg].start; + printf ("pmap_next_page: next %08x remain %d\n", avail_next, avail_remaining); + } + + if (avail_next == 0) + return FALSE; + *addrp = avail_next; + avail_next += NBPG; + avail_remaining--; + return TRUE; + } + + int + pmap_page_index(pa) + vm_offset_t pa; + { + + struct physeg *sep = &phys_segs[0]; + + while (sep->start) { + if (pa >= sep->start && pa < sep->end) + return (amiga_btop(pa - sep->start) + sep->first_page); + ++sep; + } + return -1; + } + + void + pmap_virtual_space(startp, endp) + vm_offset_t *startp; + vm_offset_t *endp; + { + *startp = virtual_avail; + *endp = virtual_end; + } + #else + #define pmap_page_index(pa) ((pa) >= avail_start && (pa) < avail_end) + #endif /* MACHINE_NONCONTIG */ + /* * Used to map a range of physical addresses into kernel * virtual address space. *************** *** 767,773 **** * Remove from the PV table (raise IPL since we * may be called at interrupt time). */ ! if (pa < vm_first_phys || pa >= vm_last_phys) continue; pv = pa_to_pvh(pa); ste = (int *)0; --- 892,898 ---- * Remove from the PV table (raise IPL since we * may be called at interrupt time). */ ! if (!pmap_valid_page(pa)) continue; pv = pa_to_pvh(pa); ste = (int *)0; *************** *** 800,807 **** pv = npv; } #ifdef DEBUG ! if (npv == NULL) panic("pmap_remove: PA not in pv_tab"); #endif ste = (int *)npv->pv_ptste; ptpmap = npv->pv_ptpmap; --- 925,934 ---- pv = npv; } #ifdef DEBUG ! if (npv == NULL) { ! printf ("pmap_remove: PA %08x index %d\n", pa, pa_index(pa)); panic("pmap_remove: PA not in pv_tab"); + } #endif ste = (int *)npv->pv_ptste; ptpmap = npv->pv_ptpmap; *************** *** 938,944 **** prot == VM_PROT_NONE && (pmapdebug & PDB_REMOVE)) printf("pmap_page_protect(%x, %x)\n", pa, prot); #endif ! if (pa < vm_first_phys || pa >= vm_last_phys) return; switch (prot) { --- 1065,1071 ---- prot == VM_PROT_NONE && (pmapdebug & PDB_REMOVE)) printf("pmap_page_protect(%x, %x)\n", pa, prot); #endif ! if (!pmap_valid_page(pa)) return; switch (prot) { *************** *** 957,963 **** --- 1084,1096 ---- #ifdef DEBUG if (!pmap_ste_v(pmap_ste(pv->pv_pmap,pv->pv_va)) || pmap_pte_pa(pmap_pte(pv->pv_pmap,pv->pv_va)) != pa) + { + printf ("pmap_page_protect: va %08x, pmap_ste_v %d pmap_pte_pa %08x/%08x\n", + pv->pv_va, pmap_ste_v(pmap_ste(pv->pv_pmap,pv->pv_va)), + pmap_pte_pa(pmap_pte(pv->pv_pmap,pv->pv_va)),pa); + printf (" pvh %08x pv %08x pv_next %08x\n", pa_to_pvh(pa), pv, pv->pv_next); panic("pmap_page_protect: bad mapping"); + } #endif pmap_remove(pv->pv_pmap, pv->pv_va, pv->pv_va + PAGE_SIZE); *************** *** 1164,1170 **** * Note that we raise IPL while manipulating pv_table * since pmap_enter can be called at interrupt time. */ ! if (pa >= vm_first_phys && pa < vm_last_phys) { register pv_entry_t pv, npv; int s; --- 1297,1303 ---- * Note that we raise IPL while manipulating pv_table * since pmap_enter can be called at interrupt time. */ ! if (pmap_valid_page(pa)) { register pv_entry_t pv, npv; int s; *************** *** 1622,1628 **** if (!pmap_ste_v(pmap_ste(pmap, sva))) return; pa = pmap_pte_pa(pmap_pte(pmap, sva)); ! if (pa < vm_first_phys || pa >= vm_last_phys) return; pv = pa_to_pvh(pa); if (pv->pv_ptste == NULL) --- 1755,1761 ---- if (!pmap_ste_v(pmap_ste(pmap, sva))) return; pa = pmap_pte_pa(pmap_pte(pmap, sva)); ! if (!pmap_valid_page(pa)) return; pv = pa_to_pvh(pa); if (pv->pv_ptste == NULL) *************** *** 1768,1774 **** register int *pte; int s; ! if (pa < vm_first_phys || pa >= vm_last_phys) return(FALSE); pv = pa_to_pvh(pa); --- 1901,1907 ---- register int *pte; int s; ! if (!pmap_valid_page(pa)) return(FALSE); pv = pa_to_pvh(pa); *************** *** 1816,1822 **** printf("pmap_changebit(%x, %x, %s)\n", pa, bit, setem ? "set" : "clear"); #endif ! if (pa < vm_first_phys || pa >= vm_last_phys) return; pv = pa_to_pvh(pa); --- 1949,1955 ---- printf("pmap_changebit(%x, %x, %s)\n", pa, bit, setem ? "set" : "clear"); #endif ! if (!pmap_valid_page(pa)) return; pv = pa_to_pvh(pa); diff -cr /mnt/src/sys/arch/amiga/include/pmap.h /sys/arch/amiga/include/pmap.h *** /mnt/src/sys/arch/amiga/include/pmap.h Sun Jun 5 10:15:23 1994 --- /sys/arch/amiga/include/pmap.h Sun Jul 31 11:38:40 1994 *************** *** 95,101 **** --- 95,105 ---- u_int *Sysmap; char *vmmap; /* map for mem, dumps, etc. */ + #ifdef MACHINE_NONCONTIG + #define pa_index(pa) pmap_page_index(pa) + #else #define pa_index(pa) atop(pa - vm_first_phys) + #endif #define pa_to_pvh(pa) (&pv_table[pa_index(pa)]) #define pmap_resident_count(pmap) ((pmap)->pm_stats.resident_count) #endif KERNEL -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 11 06:30:29 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Eeeek! ld.so complains about C lib after rtld change! To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 260 Sender: owner-current-users@sun-lamp.cs.berkeley.edu After the most recent rtld.c change every dynamically loaded program that use the C library complains about unpure text in the dynamic library. This is the C library for m68k. What's the deal? Is ld.so messed up or is the C library messed up? -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Aug 11 23:58:23 1994 Subject: installing 1.0 From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Some things I ran across when installing the 1.0 stuff... black bar down the middle of the screen at times. I thought this was already fixed. cant do mount -t adosfs, have to run mount_ados manually. It reports that there is no /usr/sbin/mount_ados .. I thought this stuff resides in /sbin not /usr/sbin (??) something happened to my root partition at somepoint that made the system panic whenever I made a directory on that partition. I dont know how it happened but it would panic when I made /altroot/altroot from tar or manually with: mode = 40755, inum = 512, fs = /altroot panic: ffs_valloc: dup alloc I didnt investigate this any further. Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 00:14:41 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: multiple chunk info Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu If you want to use the multiple chunk supportyou have to add an option: MACHINE_NONCONTIG to your config file. New info to my slow kernel problem. Removing 2MB of 16bit RAM helped somewhat. It may just be that Z2 memory is too slow for NetBSD to keep up 38400 baud input on a 33MHz 030. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 00:16:09 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: slow kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I don't really know when my kernel started getting slow. Possibly it was the fact that I put in 8MB of slow 16-bit RAM when I got multiple-chunk working on top of my 4MB fast 60ns 32-bit RAM (I have a GVP combo running at 33MHz). How do I notice it? Well it's only at fast serial rates like 19200 or 38400. As NetBSDs input flow control is somewhat buggy (hey, I do not even know of a serial driver that supports RTS) ordinary dialout on my Retina console is unusable. A full screen refresh requires about 7.5KB of chars to be received on the serial port which the Amiga ser.c driver just can't handle if the user-level process don't keep up. So I fixed tty.c and added RTS handling to ser.c. Now, input is received in chunks of about TTYHOG (= 1K) sized chunks. This means that during ordinary 19200 receive with Retina console output my CPU is totally used up. First half-a-seconds worth of chars is received by the modem, I can see the RXD lamp blink during that time, then RTS is dropped and my user-process (kermit) gets this chunk of chars and diverts them to the Retina, this process takes also about half-a- second, during this time the RXD lamp is out, as it should be. Then the process starts over again. Does this sound reasonable? Who is to blame, the serial driver's interrupt routines (I don't think so, I find them close to optimal), the tty code, the multichunk spport or the Retina console? Or is this speed really to be expected when using 8MB of 16bit RAM? Is it maybe the chipmem bandwidth that is too low. No, it's not the GVP maxdma, it's lowered to 512 already and on top of that *no* disk activity is going on at this time. Have somebody else seen this? Have somebody counted cycles for serial and vbl interrupts? If it's chipmem bandwith that's to blame, how should I go on to measure it or calculate the optimal 16-bit mem population. Of course, there's always empiric ways to do it, but I prefer theory. A propos chipmem BW, my CC console is configured but not used, does it take up BW then? It's maximally overscanned. Niklas From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 00:17:22 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) "Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED" (Aug 11, 2:35am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Roland McGrath , sommerfeld@orchard.medford.ma.us Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu I don't know what the original driver you wrote looked like, but the one which is in the NetBSD distribution relies on the com driver itself to set all the bits on the individual uarts. Thus, flags = 1 is a necessary addition to the configuration file that wants to take advantage of the ast driver. I believe we could add something to the ast multiplexer that puts the appropriate values on the softc structure before control is ever passed to the com driver. This would obviate the need for the flags stuff in the configuration file and would make the use of the card, virtually "dummy proof". Quite frankly, until I could actually see what sort of interrupt activity was going on on my system, I had no idea what the problem was. There were no hints about the problem in the documentation for the card, which assumes you'll be running in enhanced mode under SCO Xenix. Thanks to Bill for pointing out the problem, I'm a happy ast user, but I do have a few more gray hairs because of the confusion going on. -Brian On Aug 11, 2:35am, Roland McGrath wrote: } Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED } When I wrote the ast driver originally, it disabled MCR_IENABLE for } the multiplexed ports. I can't see a reason why it was changed not } to. >-- End of excerpt from Roland McGrath . From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 00:20:42 1994 From: "Hubert Feyrer" "Re: sd7-9" (Aug 9, 7:09pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I While the makers of the release version are at it, please add /dev/reboot > to the /dev/MAKEDEV - in my 21.7-release this one was missing. This is called /dev/reload now... Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri Aug 12 00:21:02 1994 From: Keith Moore To: Dave Huang Cc: netbsd-users@sun-lamp.cs.berkeley.edu, moore@cs.utk.edu Subject: Re: NetBSD on a notebook? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > So... what I'm wondering is will NetBSD run on a notebook? (I'm > looking at the Winbook XP, 486DX4-75, 16MB RAM, 340, maybe 520MB hard > disk, dual scan color display) I can't think of any reason why it > wouldn't, but will I be able to use the internal faxmodem or PCMCIA > Ethernet cards? Also, I suppose this is more of an XFree86 question > than NetBSD question, but will I be able to run X and use the little > ThinkPad-style mini-joystick-ish pointing device? (I can get a > built-in trackball instead if it makes a difference) The ads say it > uses the Western Digital Rocketchip graphics accelerator. I'm running NetBSD 0.9 on my ThinkPad 750 monochrome. It required patches to boot from the 2.88 mb floppy, the keyboard, pcmcia ethernet (my patches just work with one or two specific cards), and to support the trackpoint pseudo-mouse. Patches are available for anon ftp from cs.utk.edu, directory pub/moore/netbsd. I don't yet know what changes will be necessary for 1.0. Keith Moore From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:21:25 1994 From: tjhayko@io.org (Tom Hayko) Subject: Re: NetBSD Kernelk (fwd) To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1478 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've compiled a kernel for Manfred Bathelt with AGA support from the Aug 4 sources, and now he is having the following problem. I same kernel runs fine on my Warp Engine equipped A4000, so I'm wondering if there is some problem with the IDE driver. He doesn't have any card in his machine, it's just a stock A4000/040 with 2 IDE drives. Forwarded message: (header and misc quoting deleted) > Now AGA is possible ! Great ! > But I have trouble now to boot BSD from my slave HD. > I fdollowed the Installation-doc (from the mailing list) and untared all > archives, but the command /altroot/sbinmount -u -r /altroot failed with an > error. but thats not bad I think. > Later I`ve seen that there is only a /etc/fstab.tmp , no fstab, so I > created one. I have all partitions of BSD on my slave-IDE, like described > in the doc, so I made fstab as follows: > /dev/sd1a / ufs rw 1 1 > /dev/sd1d /usr ufs rw 1 2 > > if I loadbsd -Ab netbsd and give sd1a as root-device > the kernel outputs: > 2 mice > 20 views (or 10 views ?) > and then freezes > > Do you know why ? > > feel free to forward it to the mailinglist ;) > > Manfred > > -- > *===========================================================================* > * Manfred Bathelt, Computer Science Student at FAU Erlangen * > * Internet: mdbathel@cip.informatik.uni-erlangen.de * > * WWW: http://wwwcip.informatik.uni-erlangen.de/user/mdbathel * From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:21:47 1994 From: Constantin Gonzalez Subject: Kernel sources To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1270 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! After successfully installing and having much fun with NetBSD I want to customize my kernel now. I took a look at some mirrors of sun-lamp here in Germany, but I'm a bit confused: I think I need the entire sys/ tree with the arch/amiga-part in it, correct me if I'm wrong. But on the other hand I don't want to compile the whole binaries in /bin, /sbin and so on. Most mirrors here om Germany either are not up to date or don't support tar-ing and gzipping on the fly, so it seems to be a bit complicated to get the sources. Is there a kernel-compiling kit like an entire kernel-source-tree tared and gzipped? Could someone point me into the right direction? I really need a more compact kernel with A2024 support... Bye, Gonz -- -------------------------------------------------------------------------- Constantin Gonzalez | EMAIL: gonzalez@rz.tu-clausthal.de Student at the | SNAIL: Muehlenstrasse 120 Technical University of | 38678 Clausthal-Zellerfeld (Germany) Clausthal | PHONE: +49 5323 1516 -------------------------------------------------------------------------- - PGP-Public-Key: type 'finger incg@sun.rz.tu-clausthal.de' - Check out http://www.rz.tu-clausthal.de/~incg/ for more info on me. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:28:42 1994 From: "Timothy F. Lee" Subject: Re: A2232 driver To: Jukka Marin Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Yes... If and when you get this information about the serial drivers, please forward them over to me too. I am also looking into setting up my NetBSD Amiga for modem dialins. Thanks... --tim --------------------------------------- Timothy F. Lee Lead ACC Lab Assistant, Client Services University of Washington E-mail: koolkid@cac.washington.edu timlee@u.washington.edu Consulting: (206)543-5227 On Thu, 11 Aug 1994, Jukka Marin wrote: > Dear All, > > I am going to set up a public access UNIX system using NetBSD and A3000. > The problem is that I need several serial ports (one for the SLIP > connection, two or more for modem lines). I have A2232 boards which > I would like to use for this purpose. > > I ask - no, I _beg_ the person who has written a NetBSD driver for the > A2232 board to please contact me. I know that the 6502 code he is > using is copyrighted by Commodore - but I'd like to write my own, > freely distributable code to replace the copyrighted part. > > It's just that I need more serial ports as soon as possible. > > Any help greatly appreciated, > > Jukka Marin > > > -- > > | Mail: Jukka Marin | E-Mail: jmarin@messi.uku.fi | > | Metsurintie 17 B 8 | FAX/voice: +358 71 283 2793 | > | 70150 Kuopio | There's God above computers - | > | FINLAND | Love beyond the hate | > \ / > \ If a train station is where the train stops, what is a workstation? / > > From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:32:10 1994 From: "Hubert Feyrer" "Re: Suggestion for distribution" (Aug 9, 7:59pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, etxpihl@etxb.eua.ericsson.se (Tomas Pihl ETX/B/DG) Subject: Re: Suggestion for distribution Cc: amiga@sun-lamp.cs.berkeley.edu Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 9, 7:59pm, Guenther Grau wrote: > system, including the most frequently used goodies, like tex, emacs, ^^^ I've checked most of the files under the "contrib"-directory and TeX is one of the few that still works. My problem was that the archive contains just the binaries, so: It probably wouldn't be a bad idea to make a package which contains everything necessary to do some basic things with TeX. This should include format-file, some style-files, fonts and of course the binaries. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:36:02 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Aug 12 00:37:21 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Path: hotb.RoBIN.de!batman.RoBIN.de!mania.robin.de!mania.robin.de!lkv From: lkv@mania.robin.de (Lutz Vieweg) Newsgroups: robin.lists.comp.amiga.x Subject: Re: Retina Z3 support status Organization: none Lines: 52 Distribution: robin Nntp-Posting-Host: mania.robin.de Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In article <9408091621.AA26777@saul2.u.washington.edu>, donn@u.washington.edu (Donn Cave) writes: > The current kernel support for the Z3 went in back in June. A month or > two before, Markus Wild had put some server code out on eunet, in the > ``experimental'' directory. (And kernel modifications, including the > driver code from Lutz Vieweg that is the basis for the current driver.) > > That experimental server code compiled for me without any serious > modifications. I compiled it with X11R6. It's not perfect, but the > flaws are not serious, at least not so serious that I was motivated to > fix them. The only two that come to mind are a square black rectangle > that appears on the screen when the mouse runs into the edge of the screen, This certainly results from the usage of a 64-pixel-wide hardware-cursor. When I wrote the low-level sources, I trusted the NCR-77C32BLT manual which decribed the 64-pixel HWC feature, meanwhile, NCR has stated that this feature is broken in some chip revisions. We should switch back to use only 32-pixel wide cursor sprite... > It's reasonably fast, and Lutz > apparently has ideas about how it could be speeded up Yes, there are really great chances for speedups: - The blitter is used very seldom, yet. There are a lot of drawing primitives which could be done by the blitter, if someone implements the appropriate call-back functions. - The blitter supports "text-blits", which could speed up the text rendering by magnitudes. > , although at present > I don't think he's working on it. Yes, that's unluckily correct. The reasons: My NetBSD installation was kind of corrupted, so the ordinary X11R5 sources didn't compile, nothing but trouble with missing/erraenous includes etc. I wanted to wait for NetBSD 1.0 to come out which could give me a good chance for a clean re-installation from scratch. But now I've got a second problem: I need to have both my A3000 and my new HP-workstation on the same SCSI-bus, as I need to access my MO-drive from both computers. This works well with AmigaDOS, but NetBSD instantly crashes in this configuration. Maybe someday I'll be able to disconnect the A3000 from the SCSI bus, thus allowing me to run NetBSD on it again, but I cannot say when this may happen. If anyone wants to work on the RZ3 server code, I'll gladly support him with new low-level routines and information. cu, Lutz Vieweg From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 12 00:37:53 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 00:48:24 1994 Subject: Re: 2 simple questions followup... To: jtk@kolvir.blrc.ma.us (John Kohl) From: "Martin Husemann" Cc: michaelv@HeadCandy.com, current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 704 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ??? I don't require any of that stuff. I guess the stick in the mud > must be getty. I use FlexFAX to answer the phone for FAX or to exec a > getty. It sits on the line just fine, passively, and yields whenever I > crank up UUCP or PPP or Kermit, all of which just create a lock file in > the appropriate place. mgetty works the other way around, but it works dito. No need for kernel support; in- and outdials on the same modem work fine. Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 00:48:26 1994 From: jbrown@umi.com (Jim Brown) Subject: NetBSD 1.0 ? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 92 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did I miss it? Is it officially available? Jim "Still Salivating" Brown jbrown@umi.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 00:50:29 1994 From: "Burgess, David (TSgt) ~U" To: current-users Subject: Enabling the UTP port on a wd8013ept card.... Encoding: 20 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a 16bit UTP card that I am trying to get working with NetBSD-1.0.Today.... When I plug a null UTP cable into my 8003 cards, I get a Carrier Sense light on both cards and communicate back and forth reasonably reliably. I recently purchased a 8013 card (I ran out of low end IRQs) and have been trying to get the card to work ever since. When the card is enabled during boot, it claims that I am using the 'aui' port. I looked at the if_ed.c code last night, and found ouut where this is happening. I am, nonetheless, completely unelightened by that information. Does anyone have a good idea about how to enable the UTP port instead of the aui and bmc ports? I have tried every possible choice for [-]link[0123] that I can, and none of them seem to do anything for me. Pointer to an FM world work as well. Please E-Mail me at burgess@cynjut.infonet.net if you have any additional insight. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 00:50:47 1994 To: "Michael L. VanLoon -- Iowa State University" Cc: John Kohl , current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <199408110333.WAA15399@MindBender.HeadCandy.com> From: "Simon J. Gerraty" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Michael L. VanLoon wrote: > John Kohl writes: > >Seems like a getty which camps out waiting for input, and then takes the > >lock before reading input (waiting and resetting if the lock is held), > >would do the trick. No need for kernel hackery at all! > Did I just hear someone volunteer to write some software? ;-) No. You just read a description of what uugetty does :-) Actually I've been using the mgetty from sendfax+mgetty for months (Feb 27 was last change to /etc/ttys), ever since I reverted to the standard com.c in fact. It works fine. And if my modem worked properly, I could send/receive faxes too! Don't flame me, I'm not saying uugetty is cool, but in the absence of cua devices, its better than nothing. Mind you, my mgetty is based on a rather old version and has a number of mods to work with NetBSD (I did it before VMIN etc were implemented in termios), and to support a modemcap file (ala termcap) rather than requiring all your modems to be identical. When I upgrade to NetBSD-1.0, I'll re-port the latest version. --sjg From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 00:56:24 1994 To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: Roland McGrath , sommerfeld@orchard.medford.ma.us, current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED <199408111553.IAA13049@baloo.ucsc.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu > I don't know what the original driver you wrote looked like, but the > one which is in the NetBSD distribution relies on the com driver itself to > set all the bits on the individual uarts. Thus, flags = 1 is a necessary > addition to the configuration file that wants to take advantage of the ast > driver. I believe we could add something to the ast multiplexer that puts > the appropriate values on the softc structure before control is ever passed > to the com driver. That's a bad idea, because there are some ("broken") AST-like multiport boards that require different interrupt-enable-bit settings, e.g. they need the flags to _not_ be specified... yeah, there are other ways to get around that, but things would get a bit harier... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 01:00:11 1994 From: emiles@netcom.com (Earl Miles) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Hm. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I realize this sort of message is frowned upon, but I'm not quite sure where to look at this point. What's the current AmigaBSD ftp site? From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:01:46 1994 From: rhealey@aggregate.com Subject: POSIX signal macros broken/shakey on 1.0 beta To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1836 Sender: owner-current-users@sun-lamp.cs.berkeley.edu While getting CVS compiled on x86 1.0 beta yesterday I ran in to a hang when I tried to run it. After mucking around in gdb for a bit I found a piece of code in the cvs support library that was initializing the signal set. First the defines from /usr/include/signal.h: /* List definitions after function declarations, or Reiser cpp gets upset. */ #define sigaddset(set, signo) (*(set) |= 1 << ((signo) - 1), 0) #define sigdelset(set, signo) (*(set) &= ~(1 << ((signo) - 1)), 0) #define sigemptyset(set) (*(set) = 0, 0) #define sigfillset(set) (*(set) = ~(sigset_t)0, 0) #define sigismember(set, signo) ((*(set) & (1 << ((signo) - 1))) != 0) I'm not sure if it's a x86 gcc bug or not but the whole signal setup macro set looks kinda shakey to me. Specifically, it depends on sigismember to return a 0 when the signal number goes over the number of bits in the datatype of set. i.e. 32 bits in our case. The CVS code was using a loop with sigismember that went from 1 to whenever sigismember returned 0. sigismember never returned 0 on x86 1.0 beta and kept going and going like the Energizer bunny... I fixed cvs up by just setting the key variable to SIGMAX but the assumptions in the above macros make me nervious something like this is going to jump up and bite me later in a situation that won't be so trivial to fix... B^(. Other OS's appear to implement these as actual functions rather than macros, maybe NetBSD should too? Or at least make the macros more robust. i.e. sigfillset is assuming there are 31 signals and will never be any more. sigismember assumes 1<<33 on a 32 bit int would do the right(?) thing and return 0; it don't on x86 1.0beta... Anyways, it looks like a weak point that should be addressed in the future and at least warned about in the present. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:02:06 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <199408110107.VAA04989@kolvir.blrc.ma.us> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Michael> life significantly easier for people who'd like to have incoming and >Michael> outgoing things happening on their ports, without having to go throug >h >Michael> the /etc/ttys / kill -HUP 1 contortions currently required (not to >Michael> mention the sleep < /dev/ttyxx stuff. > >??? I don't require any of that stuff. I guess the stick in the mud >must be getty. I use FlexFAX to answer the phone for FAX or to exec a >getty. It sits on the line just fine, passively, and yields whenever I >crank up UUCP or PPP or Kermit, all of which just create a lock file in >the appropriate place. FlexFAX frobs all the right bits on the serial port so programs that want to open the tty don't hang (the PPP daemon is one that definately _will_ hang unless you hack the source. I believe the others open the line in non-blocking mode). While FlexFAX is a great package (I use it myself at both home and work), it's rather unreasonable to have to use it as a general solution for getting your serial ports working for callout :-) >Seems like a getty which camps out waiting for input, and then takes the >lock before reading input (waiting and resetting if the lock is held), >would do the trick. No need for kernel hackery at all! Doesn't solve the problem about using PPP, or any other application that doesn't open the serial port in non-blocking mode (unless you write your getty so it frobs all the right bits as well ... but then you'd have to run that getty all the time, and you wouldn't drop DTR unless your application did that specifically before it closed). Call-out devices are the right solution; if I wasn't so busy, I'd try to get them working myself. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:02:37 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) "Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED" (Aug 11, 2:35am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Roland McGrath , sommerfeld@orchard.medford.ma.us Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I don't know what the original driver you wrote looked like, but the one which is in the NetBSD distribution relies on the com driver itself to set all the bits on the individual uarts. Thus, flags = 1 is a necessary addition to the configuration file that wants to take advantage of the ast driver. I believe we could add something to the ast multiplexer that puts the appropriate values on the softc structure before control is ever passed to the com driver. This would obviate the need for the flags stuff in the configuration file and would make the use of the card, virtually "dummy proof". Quite frankly, until I could actually see what sort of interrupt activity was going on on my system, I had no idea what the problem was. There were no hints about the problem in the documentation for the card, which assumes you'll be running in enhanced mode under SCO Xenix. Thanks to Bill for pointing out the problem, I'm a happy ast user, but I do have a few more gray hairs because of the confusion going on. -Brian On Aug 11, 2:35am, Roland McGrath wrote: } Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED } When I wrote the ast driver originally, it disabled MCR_IENABLE for } the multiplexed ports. I can't see a reason why it was changed not } to. >-- End of excerpt from Roland McGrath . From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 01:03:47 1994 From: Roland McGrath To: sommerfeld@orchard.medford.ma.us Cc: buhrow@cats.ucsc.edu, current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu When I wrote the ast driver originally, it disabled MCR_IENABLE for the multiplexed ports. I can't see a reason why it was changed not to. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:05:55 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 2 simple questions followup... <199408110107.VAA04989@kolvir.blrc.ma.us> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>>> "Michael" == Michael L VanLoon writes: >Michael> life significantly easier for people who'd like to have incoming and >Michael> outgoing things happening on their ports, without having to go throug h >Michael> the /etc/ttys / kill -HUP 1 contortions currently required (not to >Michael> mention the sleep < /dev/ttyxx stuff. John Kohl writes: >Seems like a getty which camps out waiting for input, and then takes the >lock before reading input (waiting and resetting if the lock is held), >would do the trick. No need for kernel hackery at all! > >==John Did I just hear someone volunteer to write some software? ;-) ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc. Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532 In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:13:11 1994 From: mycroft@gnu.ai.mit.edu To: ziff@eecs.umich.edu Subject: Re: PCI support Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu What extra features are [not] used yet? My impression was that `Enhanced IDE' had options to do multi-sector I/O without an interrupt for each sector, and to do DMA. I haven't actually seen technical specs for it, however. If someone would like to look into this more, that would be dandy. B-) From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:14:35 1994 From: Mark Gooderum To: michaelv@HeadCandy.com, jtk@kolvir.blrc.ma.us Subject: Re: 2 simple questions followup... Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ??? I don't require any of that stuff. I guess the stick in the mud > must be getty. I use FlexFAX to answer the phone for FAX or to exec a > getty. It sits on the line just fine, passively, and yields whenever I > crank up UUCP or PPP or Kermit, all of which just create a lock file in > the appropriate place. You hit the nail on the head. NetBSD getty doesn't honor uucp locks, FlexFax and Kermit 1.90 do properly. > Seems like a getty which camps out waiting for input, and then takes the > lock before reading input (waiting and resetting if the lock is held), > would do the trick. No need for kernel hackery at all! Get mgetty. It hides on many linux ftp sites with sendfax. You don't have to use sendfax. Mgetty just has the advantage of being able to recognize and incoming fax if desired and honoring UUCP locks on the side. I use FlexFax 2.2.2 BTW, very happy. One bummer is my nice Zoom V.fast modem just 1/2 died. It won't see incoming calls (no "RING", no increment of the S1 reg, and it won't answer a call even if I force ATA. Outgoing still works...bummer. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:31:48 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Snapshot Report - 04 August tar_files To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2678 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Snapshot report. ================ Me: agc@uts.amdahl.com (Alistair G. Crooks) Source: tar_files, 4th August 1994, from ftp.iastate.edu Base version of NetBSD: 0.9. Upgrade from previous -current: yes, 31st July sources from sun-lamp.cs.berkeley.edu Machine specifics: 386DX/40+387, 16MB RAM, 1542CF, 540 MB SCSI (Quantum), VGA Other software: Matthieu Herrb's XFree86 2.1.1, built July 21 1994. (from ftp.laas.fr) Tar files integrity: good. Additional things to do during upgrade: None Any warnings during compilation: None Any problems during make: None Observations: None Changes from previous snapshot report: (This is taken from the CHANGES file on sun-lamp - last update on 7th August 94) vax: initial uploads of VAX architecture code. (ragge) make sys/lib/libsa build. (brezak) hp300: use installboot.sh in stand - no more installboot.c. (brezak) [And I also saw... i386: disable caching on some Cyrix 486 DLCs (mycroft) - agc] Notes: 1. Very little to report this week, which is good news. Everything built OK, and seems to run well, too. I've bitten the bullet and gone to 1.21.2.2 bootblocks, and also to level 2 inodes, and everything seems fine in these departments. 2. Sorry to be so late about this thing - hopefully, it's better late than never. Next week's may not happen until Thursday/Friday, as I'm going to be away on business from Monday to Wednesday inclusive. 3. The usr.sbin Makefile has catman commented out, wth the comment "not yet done", although it builds and seems to run fine on i386. Can anyone tell me why this is, because /usr/libexec/makewhatis seems to exist in that directory for the sole use of catman. 4. If you're using the i386 port, and running on a Cyrix 486DLC, (which could be showing funnies due to screwy caches, so you should use the BIOS setup routines to disable caching either selectively or en masse). 5. Brad Spencer tells me that the BusLogic bt-946c PCI card seems to work fine in a 90MHz Pentium box, modulo a few funnies from discs salvaged from a Sun, with the standard buslogic driver. 6. The ccd driver appears to be getting there on a hp300s, and could well move (or have moved) to the i386 platform. Nice... 7. Charles Hannum has modified the aic6360 driver so that it works on a 1522. Volunteers needed who possess 1520/1522s and Soundblasters. 8. I see that FreeBSD have a beta iBCS2-compatibility module working. Anyone else interested in this for NetBSD? If so, please drop me a line. Cheers, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:33:02 1994 To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: POSIX signal macros broken/shakey on 1.0 beta <9408111559.AA05061@sirius.aggregate.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Specifically, it depends on sigismember to return a 0 when the signal > number goes over the number of bits in the datatype of set. i.e. 32 > bits in our case. The CVS code was using a loop with sigismember > that went from 1 to whenever sigismember returned 0. sigismember never > returned 0 on x86 1.0 beta and kept going and going like the > Energizer bunny... This argument has happened several times before, see the mailing list archives... Basically, the output of sigismember() is only defined if the signal number is valid, and an error has to be returned only if an error is detected. So if the number is invalid, and that's not detected (and nothing says that it has to be), the result returned may not be what's expected. CVS isn't behaving in a POSIX-friendly manner, given its usage of sigismember(). (of course, our sigismember() could be considered a bit strange, too, but it's not strictly a _bug_.) chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 01:38:21 1994 To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: Roland McGrath , sommerfeld@orchard.medford.ma.us, current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED <199408111553.IAA13049@baloo.ucsc.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I don't know what the original driver you wrote looked like, but the > one which is in the NetBSD distribution relies on the com driver itself to > set all the bits on the individual uarts. Thus, flags = 1 is a necessary > addition to the configuration file that wants to take advantage of the ast > driver. I believe we could add something to the ast multiplexer that puts > the appropriate values on the softc structure before control is ever passed > to the com driver. That's a bad idea, because there are some ("broken") AST-like multiport boards that require different interrupt-enable-bit settings, e.g. they need the flags to _not_ be specified... yeah, there are other ways to get around that, but things would get a bit harier... chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 02:06:29 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: POSIX signal macros broken/shakey on 1.0 beta Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From: rhealey@aggregate.com > Date: Thu, 11 Aug 1994 10:59:24 -0500 (CDT) [ sigset manipulation macro problems ] > Other OS's appear to implement these as actual functions rather than > macros, maybe NetBSD should too? Probably yes. These are generally not in any critical path. Gordon Ross From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 02:06:59 1994 From: "J.T. Conklin" To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: POSIX signal macros broken/shakey on 1.0 beta Sender: owner-current-users@sun-lamp.cs.berkeley.edu Specifically, it depends on sigismember to return a 0 when the signal number goes over the number of bits in the datatype of set. i.e. 32 bits in our case. The CVS code was using a loop with sigismember that went from 1 to whenever sigismember returned 0. sigismember never returned 0 on x86 1.0 beta and kept going and going like the Energizer bunny... Although there is an open PR for this issue, It's actually a bug in CVS -- POSIX.1 gives the implementor the option of not "detecting" the error of an invalid or unsupported signals. We choose not to. Send mail query-pr@sun-lamp.cs.berkeley.edu with subject "--full 279" for details. In the words of the rationale: "...is not necessary to require implementations of these functions to determine wheter an optional signal is actually supported, as that could have a significant performance impact for very little value." Fortunately the CVS 1.3.91 snapshot I've been working with works out of the box on NetBSD. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:03:45 1994 From: "J.T. Conklin" To: gwr@mc.com (Gordon W. Ross) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: POSIX signal macros broken/shakey on 1.0 beta Sender: owner-current-users@sun-lamp.cs.berkeley.edu > [ sigset manipulation macro problems ] > > > Other OS's appear to implement these as actual functions rather than > > macros, maybe NetBSD should too? > > Probably yes. These are generally not in any critical path. The sigsetops are already implemented as functions. POSIX.1 and ANSI C allow almost every function to have a macro implementation in addition to a function implementation. In fact, the function implementations _do_ detect the invalid signal error. At one time we had the sigsetops macros commented out of , but that was lost when was imported from 4.4lite. At one time I thought that invalid signal errors should always be detected, since it is easy to do and not _too_ expensive. I no longer think so, because as an application programmer, I can't write code that relys on the fact that errors will be detected. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:05:10 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Chris G. Demetriou" Cc: rhealey@aggregate.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: POSIX signal macros broken/shakey on 1.0 beta <9408112213.AA11226@alpha.bostic.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu I seem to recall that some core team member said that the POSIX wording was a bit ambiguous, and it was hard to tell for sure what they meant. Given this, isn't it better to be safe than sorry? I quote most of page 292 from "Advanced Programming in the UNIX Environment" by W. Richard Stevens, which claims to describe POSIX among other things. Note the paragraph after the sample implementation: - - - - - - - - - - - - - BEGIN QUOTE - - - - - - - - - - - - - - - - #include #include #define SIGBAD(signo) ((signo) <= 0 || (signo) >= NSIG) /* usually defines NSIG to include signal number 0 */ int sigaddset(sigset_t *set, int signo) { if (SIGBAD(signo)) { errno = EINVAL; return(-1); } *set |= 1 << (signo - 1); /* turn bit on */ return(0); } int sigdelset(sigset_t *set, int signo) { if (SIGBAD(signo)) { errno = EINVAL; return(-1); } *set &= ~(1 << (signo - 1)); /* turn bit on */ return(0); } int sigismember(const sigset_t *set, int signo) { if (SIGBAD(signo)) { errno = EINVAL; return(-1); } return( (*set & (1 << (signo - 1))) != 0 ); } Program 10.9 An implementation of sigaddset, sigdelset, and sigismember We might be tempted to implement these three functions as one-line macros in the header, but POSIX.1 requires us to check the signal number argument for validity and set errno if it is invalid. This is harder to do in a macro than a function. - - - - - - - - - - - - - END QUOTE - - - - - - - - - - - - - - - - - Again, isn't it better to be safe than sorry? Whether Stevens' interpretation of the POSIX.1 spec is right or wrong, many programmers will be following his interpretation because of this excellent book. Incidentally, the book does define sigemptyset and sigfillset as macros in on the previous page: #define sigemptyset(ptr) ( *(ptr) = 0 ) #define sigfillset(ptr) ( *(ptr) = ~(sigset_t)0, 0 ) "Chris G. Demetriou" writes: > This argument has happened several times before, see the mailing list > archives... > > Basically, the output of sigismember() is only defined if the signal > number is valid, and an error has to be returned only if an error > is detected. So if the number is invalid, and that's not detected > (and nothing says that it has to be), the result returned may not > be what's expected. > > CVS isn't behaving in a POSIX-friendly manner, given its usage > of sigismember(). (of course, our sigismember() could be considered > a bit strange, too, but it's not strictly a _bug_.) Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:05:59 1994 Subject: Re: POSIX signal macros broken/shakey on 1.0 beta To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu From: noses@oink.rhein.de (Noses) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 607 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm not sure if it's a x86 gcc bug or not but the whole signal > setup macro set looks kinda shakey to me. > > Specifically, it depends on sigismember to return a 0 when the signal > number goes over the number of bits in the datatype of set. i.e. 32 > bits in our case. Even if it is *reaching* the limit you're in trouble; try the following program: void main (void) { unsigned long i, j; i = 0x80000000L; j = i >> 32; printf ("i = %lx (>> 32) j = %lx\n",i, j); } /* main */ And it isn't the compiler's fault either as the generated code is looking ok. Achim From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:06:44 1994 From: Roland McGrath To: sommerfeld@orchard.medford.ma.us Cc: buhrow@cats.ucsc.edu, current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED Sender: owner-current-users@sun-lamp.cs.berkeley.edu When I wrote the ast driver originally, it disabled MCR_IENABLE for the multiplexed ports. I can't see a reason why it was changed not to. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:09:22 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, jtk@kolvir.blrc.ma.us Subject: Re: SCSI driver doesn't wait enough for CD ROM to become ready Sender: owner-current-users@sun-lamp.cs.berkeley.edu Two things: 1) This is a more general problem that may also affect other types of devices. 2) The same thing can happen on open. For the moment, I haven't dealt with #1. I've dealt with #2 by moving the change into cd_size(), and only retrying if scsi_scsi_cmd() reports EBUSY (which means the device returned NOT READY). From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 03:22:54 1994 Subject: Re: installing 1.0 From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > black bar down the middle of the screen at times. I thought this > was already fixed. No. This is a simple problem: when you turn off sprite DMA, you must also zero out the data register. In the meantime: #include #include char zero[4] = { 0,0,0,0 }; main() { int fd; fd = open("/dev/mem", O_RDWR); lseek(fd, 0xDFF144, 0); write(fd, zero, 4); close(fd); } This must be compiled setuid root (or otherwise to have access to /dev/mem). This problem was present from day one, was fixed (by me) and then crept in again when chopps cut over to views. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@torfree.net for latest Toronto Free-Net information Click me! From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 03:46:14 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rhealey@aggregate.com Subject: Re: POSIX signal macros broken/shakey on 1.0 beta Sender: owner-current-users@sun-lamp.cs.berkeley.edu And it isn't the compiler's fault either as the generated code is looking ok. That depends on what you consider to be the `correct' thing. The i386 chip itself chops off all but the lower 5 bits of any shift count. According to ANSI, the semantics of shifting by a value greater than the size of the object being shifted are unspecified, so the compiler does not need to account for this. (Note that the i286 and below did not truncate shift counts. This was done when the barrel shifter was added, and it became too much of an annoyance to do otherwise.) From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 04:39:46 1994 From: "J.T. Conklin" To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: POSIX signal macros broken/shakey on 1.0 beta Sender: owner-current-users@sun-lamp.cs.berkeley.edu Again, isn't it better to be safe than sorry? Whether Stevens' interpretation of the POSIX.1 spec is right or wrong, many programmers will be following his interpretation because of this excellent book. I think Stevens is wrong. But because his book is widely read and used as a reference; and the fact that all of the assorted OS's I just checked detect invalid signal errors; and the fact that the masses may not see CVS 1.4 for some time has caused me to change my mind one more time. I've decided that it's better to be pragmatic than pedantic in this matter. Since I may have been the only opposition to changing the behavior to detect errors, I think this opens the window to the change. Since the function implementation already detects errors, all that is needed is for the sigaddset, sigdelset and sigismember macros to be removed from signal.h and for the manpage to be updated. If anyone has any objections, raise them now. Otherwise the change will go into the development tree tonight. Someone from core can pull them into the 1.0 tree if they feel it's important enough. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 04:45:44 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: lfs... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Anybody dinked with lfs? I really want to check it out, and have a 620meg SCSI drive on an hp433 at my disposal. My main questions, I guess are: 1) anybody *really* badly lost data on it? I'm probably going to deposit a local binary base there. 2) does one fsck it as you would an ffs? 3) does dump(8) work on it normally? Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 12 05:01:30 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Tim Newsham , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: installing 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 11, 9:21am, Tim Newsham wrote: > cant do mount -t adosfs, have to run mount_ados manually. It reports > that there is no /usr/sbin/mount_ados .. I thought this stuff resides > in /sbin not /usr/sbin (??) Well, of course it can't find it: mount -t adosfs wants to run mount_adosfs, not mount_ados. Try mount -t ados... > something happened to my root partition at somepoint that made the > system panic whenever I made a directory on that partition. I dont know > how it happened but it would panic when I made /altroot/altroot from > tar or manually with: > > mode = 40755, inum = 512, fs = /altroot > panic: ffs_valloc: dup alloc This usually indicates that your file system was not unmounted cleanly at some point, so the file system is confused. You probably need to run fsck on it ASAP. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 08:12:49 1994 To: Jason Thorpe Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: lfs... <9408120129.AA25681@research.CS.ORST.EDU> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Anybody dinked with lfs? I really want to check it out, and have a > 620meg SCSI drive on an hp433 at my disposal. My main questions, I guess > are: For the Nth time: IT IS NOT EVEN CLOSE TO BEING READY FOR REAL USE!!! > 1) anybody *really* badly lost data on it? I'm probably going > to deposit a local binary base there. I don't think anybody's successfully _put_ data on it! > 2) does one fsck it as you would an ffs? one should, with either an extension to fsck, or with a new fsck program. In any case, the support for doing so has not yet been written. > 3) does dump(8) work on it normally? No, you'd need to add support to dump (or an external program) to dump lfs's. > Later... That's what you should say to any thought of using LFS for 'real work.' from every indication i've seen, LFS has been used to run benchmarks on _only_, and in between it's been newlfs'd. There's also the fact that (unless the code has changed significantly since i last looked at it -- over a year ago, when i was being paid to hack on a related file system) you can only have one LFS active on a system at a time. It needs serious work. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 08:26:27 1994 To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFTECHNICAL INFO ON THE AST CARD WANTED <9408112217.AA11451@alpha.bostic.com> From: Bill Sommerfeld Sender: owner-current-users@sun-lamp.cs.berkeley.edu > That's a bad idea, because there are some ("broken") AST-like > multiport boards that require different interrupt-enable-bit settings, > e.g. they need the flags to _not_ be specified... Just a suggestion: Maybe those "broken" boards should require a "flags 1" on the ast0 config line, rather than a "flags 0" on the com? slaves. - Bill From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 09:29:41 1994 From: John Nemeth "Re: PCI support" (Aug 11, 3:45am) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: mycroft@gnu.ai.mit.edu, ziff@eecs.umich.edu Subject: Re: PCI support Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Aug 11, 3:45am, mycroft@gnu.ai.mit.edu wrote: } Subject: Re: PCI support } } What extra features are [not] used yet? } } My impression was that `Enhanced IDE' had options to do multi-sector I/O } without an interrupt for each sector, and to do DMA. I haven't actually } seen technical specs for it, however. } } If someone would like to look into this more, that would be dandy. B-) These are in the current spec, but they are optional. You have to query the drive to see if it supports them. There are draft copies of the spec floating around the net. I can't remember where I got mine, but somebody else might know where to find it. }-- End of excerpt from mycroft@gnu.ai.mit.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 10:37:49 1994 From: mycroft@gnu.ai.mit.edu To: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: lfs... Sender: owner-current-users@sun-lamp.cs.berkeley.edu No, you'd need to add support to dump (or an external program) to dump lfs's. There is a `dumplfs' program that's supposed to do that. I believe it's in the tree. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 13:26:43 1994 To: mycroft@gnu.ai.mit.edu Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: lfs... <9408120646.AA14601@goldman.gnu.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11128.776680635.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > No, you'd need to add support to dump (or an external program) to > dump lfs's. > > There is a `dumplfs' program that's supposed to do that. I believe it's > in the tree. Not quite; dumplfs(8) is to LFS what dumpfs(8) is to FFS, and does not do the work of dump(8)... Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 13:51:41 1994 From: blymn@awadi.com.AU (Brett Lymn) Subject: Whoa, hang on a minute.... To: tech-kern@sun-lamp.cs.berkeley.edu (Technical Kernel Mailing List) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 2336 Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu This may be a bit contraversial (and may have already been discussed but I missed it...) but I am a bit perturbed by the way some, no let's not be coy - just one, of the kernel drivers is going. My beef is with the much hacked upon wd.c driver. For my particular case it does not work. Charles Hannum has told be that "your card does not meet the spec, get one that does". His reasoning for this, and I can see his point, is that my card does not meet the interface spec and causes the driver to lose interrupts. The problem that I have with this is that not only is there a fix for the "lost interrupt" problem but the controller card I have has been working fine in my machine under Interactive, 386BSD 0.1 (with a patch) and NetBSD 0.9 (with a patch). Now suddenly it does not work with NetBSD-current and there is no way for me to make it work as I cannot get `current onto the system. Personally, I would go and buy a new ESDI controller card if it would make my machine work. The problem is that I have people that have asked me to help them setup NetBSD on their machines. I can imagine their reactions if I tell them "yeah your controller is broke, you need to get a new one". They will probably stick with what they have. My alternative is to point them to FreeBSD which I do not have any direct experience with as I firmly believe in the multi-architecture approach taken by the NetBSD team so support that. Why is there this insistence on ignoring marginal PC hardware? Why is this done even when there is an acceptable (IMHO) fix for the problem? Really the driver should not have been written with infinite waits on hardware state changes - any coding I have done has always had timeouts on this sort of polling to prevent things locking up as they do in this case. Need I remind peoples that a lot of PC hardware is cheap and nasty (mainly because that's what we buy) and does not necessarily work to spec all the time. -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 14:01:09 1994 From: mycroft@gnu.ai.mit.edu To: blymn@awadi.com.AU, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: Whoa, hang on a minute.... Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu Why is there this insistence on ignoring marginal PC hardware? That's an awfully rash generalization. If I were to `ignore marginal PC hardware', then a lot of things would be much simpler. In fact, I could get rid of just about everything except EISA and PCI drivers. I know I would be much happier. But you're ignoring the point. I have already stated *several times* why the proposed `solution' of changing `wd_altsts' to `wd_status' is not correct. It is *not* acceptable for it to cause a timeout (no matter how infrequently) on correctly functioning hardware. End of story. That's why I changed it in the first place. If you can propose a real solution, that does not break the driver for hardware that's built to spec, then I'll use it. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 14:30:48 1994 From: root@sun-lamp.cs.berkeley.edu To: source@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Updating src and othersrc trees: U src/etc/etc.sparc/Makefile.inc U src/etc/etc.sparc/README U src/etc/etc.sparc/install.sh U src/gnu/usr.bin/ld/rtld/rtld.c U src/include/signal.h U src/lib/libc/gen/sigsetops.3 U src/libexec/comsat/Makefile U src/libexec/comsat/comsat.8 U src/libexec/comsat/comsat.c U src/sbin/mountd/mountd.8 U src/sbin/mountd/mountd.c U src/share/man/man4/man4.i386/Makefile U src/share/man/man4/man4.i386/ast.4 U src/share/man/man4/man4.i386/com.4 U src/share/man/man4/man4.i386/ep.4 U src/share/man/man4/man4.i386/rtfps.4 U src/sys/arch/i386/conf/GENERICAHA U src/sys/arch/i386/conf/GENERICBT U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/isa/pcvt/pcvt_kbd.c U src/sys/arch/i386/pci/ncr.c U src/sys/arch/i386/pci/ncr_reg.h U src/sys/arch/i386/pci/ncrstat.c U src/sys/arch/i386/pci/pci.c U src/sys/arch/i386/pci/pci_machdep.c U src/sys/arch/mac68k/conf/GENERIC U src/sys/arch/mac68k/dev/adbsys.c U src/sys/arch/mac68k/dev/grf_gb.c cvs checkout: grfioctl.h is no longer in the repository U src/sys/arch/mac68k/dev/ite.c cvs checkout: keyboard.h is no longer in the repository U src/sys/arch/mac68k/include/adbsys.h U src/sys/arch/mac68k/include/cpu.h U src/sys/arch/mac68k/include/grfioctl.h U src/sys/arch/mac68k/include/keyboard.h U src/sys/arch/mac68k/include/pmap.h U src/sys/arch/mac68k/mac68k/clock.c U src/sys/arch/mac68k/mac68k/conf.c U src/sys/arch/mac68k/mac68k/locore.s U src/sys/arch/mac68k/mac68k/machdep.c U src/sys/arch/mac68k/mac68k/pmap.c U src/sys/arch/pc532/stand/scsi_hi.c U src/sys/arch/pc532/stand/scsi_low.c U src/sys/arch/sparc/conf/GENERIC.sparc U src/sys/arch/sparc/conf/SPARC U src/sys/arch/sparc/conf/SPARC_SCSI3 U src/sys/arch/sparc/conf/SS5 U src/sys/arch/sparc/conf/TDR U src/sys/arch/sparc/sparc/pmap.c U src/sys/kern/vnode_if.sh U src/sys/msdosfs/msdosfs_fat.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/nfs/krpc_subr.c U src/sys/nfs/nfs_boot.c U src/sys/nfs/nfs_vfsops.c U src/sys/nfs/nfs_vnops.c U src/sys/scsi/st.c U src/usr.bin/ipcrm/Makefile U src/usr.bin/ipcrm/ipcrm.1 U doc/CHANGES Killing core files: Running the SUP scanner: SUP Scan for current starting at Fri Aug 12 03:18:51 1994 SUP Scan for current completed at Fri Aug 12 03:21:25 1994 SUP Scan for mirror starting at Fri Aug 12 03:21:25 1994 SUP Scan for mirror completed at Fri Aug 12 03:23:40 1994 From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 22:25:38 1994 To: mycroft@gnu.ai.mit.edu Cc: blymn@awadi.com.au, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: Whoa, hang on a minute.... <9408121125.AA15460@goldman.gnu.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <11645.776693691.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu > But you're ignoring the point. I have already stated *several times* > why the proposed `solution' of changing `wd_altsts' to `wd_status' is > not correct. It is *not* acceptable for it to cause a timeout (no > matter how infrequently) on correctly functioning hardware. End of > story. That's why I changed it in the first place. > > If you can propose a real solution, that does not break the driver for > hardware that's built to spec, then I'll use it. How about a config option, "BROKEN_WD" or something? :) Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:00:00 1994 From: root@sun-lamp.cs.berkeley.edu To: source@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Updating src and othersrc trees: U src/etc/etc.sparc/Makefile.inc U src/etc/etc.sparc/README U src/etc/etc.sparc/install.sh U src/gnu/usr.bin/ld/rtld/rtld.c U src/include/signal.h U src/lib/libc/gen/sigsetops.3 U src/libexec/comsat/Makefile U src/libexec/comsat/comsat.8 U src/libexec/comsat/comsat.c U src/sbin/mountd/mountd.8 U src/sbin/mountd/mountd.c U src/share/man/man4/man4.i386/Makefile U src/share/man/man4/man4.i386/ast.4 U src/share/man/man4/man4.i386/com.4 U src/share/man/man4/man4.i386/ep.4 U src/share/man/man4/man4.i386/rtfps.4 U src/sys/arch/i386/conf/GENERICAHA U src/sys/arch/i386/conf/GENERICBT U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/isa/pcvt/pcvt_kbd.c U src/sys/arch/i386/pci/ncr.c U src/sys/arch/i386/pci/ncr_reg.h U src/sys/arch/i386/pci/ncrstat.c U src/sys/arch/i386/pci/pci.c U src/sys/arch/i386/pci/pci_machdep.c U src/sys/arch/mac68k/conf/GENERIC U src/sys/arch/mac68k/dev/adbsys.c U src/sys/arch/mac68k/dev/grf_gb.c cvs checkout: grfioctl.h is no longer in the repository U src/sys/arch/mac68k/dev/ite.c cvs checkout: keyboard.h is no longer in the repository U src/sys/arch/mac68k/include/adbsys.h U src/sys/arch/mac68k/include/cpu.h U src/sys/arch/mac68k/include/grfioctl.h U src/sys/arch/mac68k/include/keyboard.h U src/sys/arch/mac68k/include/pmap.h U src/sys/arch/mac68k/mac68k/clock.c U src/sys/arch/mac68k/mac68k/conf.c U src/sys/arch/mac68k/mac68k/locore.s U src/sys/arch/mac68k/mac68k/machdep.c U src/sys/arch/mac68k/mac68k/pmap.c U src/sys/arch/pc532/stand/scsi_hi.c U src/sys/arch/pc532/stand/scsi_low.c U src/sys/arch/sparc/conf/GENERIC.sparc U src/sys/arch/sparc/conf/SPARC U src/sys/arch/sparc/conf/SPARC_SCSI3 U src/sys/arch/sparc/conf/SS5 U src/sys/arch/sparc/conf/TDR U src/sys/arch/sparc/sparc/pmap.c U src/sys/kern/vnode_if.sh U src/sys/msdosfs/msdosfs_fat.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/nfs/krpc_subr.c U src/sys/nfs/nfs_boot.c U src/sys/nfs/nfs_vfsops.c U src/sys/nfs/nfs_vnops.c U src/sys/scsi/st.c U src/usr.bin/ipcrm/Makefile U src/usr.bin/ipcrm/ipcrm.1 U doc/CHANGES Killing core files: Running the SUP scanner: SUP Scan for current starting at Fri Aug 12 03:18:51 1994 SUP Scan for current completed at Fri Aug 12 03:21:25 1994 SUP Scan for mirror starting at Fri Aug 12 03:21:25 1994 SUP Scan for mirror completed at Fri Aug 12 03:23:40 1994 From owner-tech-kern@sun-lamp.cs.berkeley.edu Fri Aug 12 23:16:11 1994 From: Scott Reynolds Subject: Re: Whoa, hang on a minute.... To: mycroft@gnu.ai.mit.edu Cc: tech-kern@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu As it turns out, someone I've been "advising" on installing the Aug 4 snapshot has a Microscience IDE disk that refuses to work with either the stock or a modified (status -> altsts) kernel. Not only does it get lost interrupts but the disk totally disappears following a series of them when attempting to put a disklabel on. This same drive works fine under QNX and MS-DOS. Oh, and the machine happens to compare to another that someone else had problems with here -- a 486DX2-66 VLB system. He "solved" the problem by swapping out his disk, but did it rather reluctantly. I'm not pointing fingers here; I'm just trying to point out that there *must* be a solution somewhere. Hopefully someone with more knowledge of the hardware will be encouraged enough to track down this "bug" (quotes intentional) and resolve it. I'll pursue it as far as I'm able, but please, don't anyone hold their breath. ;-) --scott From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:45:00 1994 From: Paul Kranenburg To: current-users@sun-lamp.cs.berkeley.edu, rhealey@kas.helios.mn.org Subject: Re: Eeeek! ld.so complains about C lib after rtld change! Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > After the most recent rtld.c change every dynamically loaded program > that use the C library complains about unpure text in the dynamic > library. > > This is the C library for m68k. > > What's the deal? Is ld.so messed up or is the C library messed > up? > The C library probably. ld.so now inspects the env. var. LD_SUPPRESS_WARNINGS; if set no warning messages are produced. For the "non-pure" warnings to appear, LD_WARN_NON_PURE_CODE must be set in addition to LD_SUPPRESS_WARNINGS not being set. -pk From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:49:50 1994 Subject: Re: 2 simple questions followup... To: sjg@zen.void.oz.au (Simon J. Gerraty) From: "Martin Husemann" Cc: michaelv@HeadCandy.com, jtk@kolvir.blrc.ma.us, current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 450 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > identical. When I upgrade to NetBSD-1.0, I'll re-port the latest > version. Current mgetty version run on current NetBSD versions out of the box. Gert Doering has integrated my patches... Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:51:34 1994 From: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Subject: Re: POSIX signal macros broken/shakey on 1.0 beta To: jconklin@netcom.com Cc: Mark_Weaver@brown.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1964 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Again, isn't it better to be safe than sorry? Whether Stevens' > interpretation of the POSIX.1 spec is right or wrong, many > programmers will be following his interpretation because of this > excellent book. > > I think Stevens is wrong. > > But because his book is widely read and used as a reference; and the > fact that all of the assorted OS's I just checked detect invalid > signal errors; and the fact that the masses may not see CVS 1.4 for > some time has caused me to change my mind one more time. > > I've decided that it's better to be pragmatic than pedantic in this > matter. Since I may have been the only opposition to changing the > behavior to detect errors, I think this opens the window to the > change. > > Since the function implementation already detects errors, all that is > needed is for the sigaddset, sigdelset and sigismember macros to be > removed from signal.h and for the manpage to be updated. > > If anyone has any objections, raise them now. Otherwise the change > will go into the development tree tonight. Someone from core can pull > them into the 1.0 tree if they feel it's important enough. > > --jtc > > I agree with the removal of the functions. When in doubt, RTFM. >From the IEEE Std 1003.1 First Edition 1990-12-07 (POSIX) -- 3.3.3.1 Synopsis . int sigaddset(sigset_t *set, int signo); int sigdelset(sigset_t *set, int signo); int sigismember(const sigset_t *set, int signo); . 3.3.3.4 Errors For each of the following conditions, if the condition is detected, the sigaddset(), sigdelset(), and sigismember() functions shall return -1 and set errno to be the corresponding value. [EINVAL] The value of the signo argument is invalid or unsupported signal number. -- It would seem that the current macro implementation is wrong. The functions probably could be implemented as macros, but only if they are done correctly, or just use the correct function version. Dale Rahn From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:52:57 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: POSIX signal macros broken/shakey on 1.0 beta To: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Cc: jconklin@netcom.com, Mark_Weaver@brown.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1357 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I agree with the removal of the functions. > When in doubt, RTFM. Please don't think we haven't. Computer Literacy Bookshops thanks me for all the money I've spent on various standards documents. The debate is over which of two POSIX compliant behaviors NetBSD should adopt. Specifically the "if the condition is detected" clause gives us the option not to check for invalid signal errors. If we don't check the condition won't be detected, thus an error return is unnecessary. I think this is the only set of routines where POSIX allows us to not check for errors. The non-normative rationale gives the history of this decision: In earlier drafts of POSIX.1 there was no distinction between invalid and unsupported signals... The {EINVAL} error was thus specified as a required error for invalid signals. With that distinction, it is not necessary to require implementations of these functions to determine whether an optional signal is actually supported, as that could have a significant performance impact for little value. The error could have been required for invalid signals and optional for unsupported signals, but this seemed unnecessarily complex. Thus, the error is optional in both cases. In any case, the case for pedantry has lost. I removed the sigaddset, sigdelset, and sigismember macros last night. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:52:58 1994 To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: TECHNICAL INFO ON THE AST CARD WANTED <9408120438.AA17151@alpha.bostic.com> From: Bill Sommerfeld Sender: owner-current-users@sun-lamp.cs.berkeley.edu Try the following (tested) patch to ast.c; if you set "flags 1" on ast0 you get the current behavior, while with "flags 0" it forces "flags 1" on all the subdevices. (I tested it with my card to make sure things still worked, and I also tested the "ast0 ... flags 1" case to verify that the subdevices did *not* get the flags set). - Bill *** 1.1.1.2 1994/04/10 01:18:39 --- ast.c 1994/08/12 14:01:25 *************** *** 54,60 **** --- 54,62 ---- struct ast_attach_args { u_short aa_iobase; int aa_slave; + int aa_subflags; }; + #define AST_NEEDS_IEN 1 int astsubmatch(parent, self, aux) *************** *** 66,72 **** struct cfdata *cf = self->dv_cfdata; int found, frobbed = 0; #ifdef NEWCONFIG - #define cf_slave cf_loc[6] if (cf->cf_slave != -1 && cf->cf_slave != aa->aa_slave) return 0; --- 68,73 ---- *************** *** 85,90 **** --- 86,92 ---- id->id_iobase = aa->aa_iobase; } #endif + cf->cf_flags |= aa->aa_subflags; found = isasubmatch(parent, self, aux); if (found) { sc->sc_slaves[aa->aa_slave] = self; *************** *** 113,118 **** --- 115,121 ---- struct ast_softc *sc = (void *)self; struct isa_attach_args *ia = aux; struct ast_attach_args aa; + struct cfdata *cf = sc->sc_dev.dv_cfdata; /* * Enable the master interrupt. *************** *** 120,125 **** --- 123,132 ---- sc->sc_iobase = ia->ia_iobase; outb(sc->sc_iobase | 0x1f, 0x80); printf("\n"); + + aa.aa_subflags = 1; + if (cf->cf_flags & AST_NEEDS_IEN) + aa.aa_subflags &= ~1; for (aa.aa_slave = 0, aa.aa_iobase = sc->sc_iobase; aa.aa_slave < 4; From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 12 23:53:15 1994 From: "Ask Dr. Stupid" X-Disclaimer: No way are these anyone else's opinions but mine. X-Real-Name: James Graham (*NOT* "Jim" -- that's my dad) X-Extension: 4219 X-Room-Number: 3308 X-Window-System: Release 5 X-No-Relation-To: greywolf@netcom.com, greywolf@blkhole.resun.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Jim Brown , current-users@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD 1.0 ? Sender: owner-current-users@sun-lamp.cs.berkeley.edu #define AUTHOR "jbrown@umi.com (Jim Brown)" /* * * Did I miss it? Is it officially available? ...will anyone put it on a CD? * * Jim "Still Salivating" Brown * * jbrown@umi.com * * * * * * */ #undef AUTHOR /* "jbrown@umi.com (Jim Brown)" */ -- _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so) / ___\ _ \ __\ V / \ / /__ \| | __/WHAT: UNIX System Mangler...er, Admin \ \| | < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc. 3 Harbor Dr. \___|_|\_\__\|_| \/\/ \__/___/_| Sausalito, CA 94965 (415) 332-2344 x4219 see also: gandalf@netcom.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 00:17:51 1994 From: dtc@stan.xx.swin.oz.au (Douglas Crosher) Subject: Printer speedup To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1371 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I found that I had been getting poor printer transfer performance particularly when using ghostscript. My setup is a 486DX33 with an HP LaserJet 4L, using the /dev/lpa0 device, and with NetBSD-current. After looking into it I found that the driver was tsleeping excessively. I was able to overcome this by setting a minimum value on spinmax, patch below: -=-=-=-=-=-=-=- *** lpt.c Wed Aug 10 02:59:54 1994 --- lpt.c.orig Wed Aug 10 00:58:39 1994 *************** *** 438,444 **** outb(iobase + lpt_control, control); /* adapt busy-wait algorithm */ ! if (spin*2 + 2*16 < sc->sc_spinmax) sc->sc_spinmax--; } } else { --- 438,444 ---- outb(iobase + lpt_control, control); /* adapt busy-wait algorithm */ ! if (spin*2 < sc->sc_spinmax) sc->sc_spinmax--; } } else { -=-=-=-=-=-=- The value of 2*16 was chosen because I found that 16 was the average value of spin and I double this to implement what I feel was the intention in the driver. This value will vary for different setups. The speed improvement was useful, from more then 60 second at times to just a few seconds :). Regards Douglas Crosher From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 00:18:52 1994 To: drahn@pacific.urbana.mcd.mot.com (Dale Rahn) Cc: jconklin@netcom.com, Mark_Weaver@brown.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: POSIX signal macros broken/shakey on 1.0 beta <9408121510.AA22775@pacific.urbana.mcd.mot.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > It would seem that the current macro implementation is wrong. Actually, according to a strict reading of the POSIX document, they were incontestably correct. However, that doesn't mean they weren't annoying. cgd From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 00:24:52 1994 X400-Originator: Knappe@tu-harburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=tu-harburg/ADMD=d400-gw/C=de/;<199408122140.XAA27064@indi2.cip] X400-Content-Type: P2-1984 (2) Content-Identifier: Installationp... Alternate-Recipient: Allowed From: Frank Knappe To: amiga@sun-lamp.cs.berkeley.edu Subject: Installationproblem with 1.0 X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1031 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hallo ! I have a great problem with the Installation of NetBSD 1.0 at my A3000 with a 170 MB HD at scsi.device adress 6. I used the binaries from ftp.uni-regensburg and the Installationdoc from the mailinglist , but my harddisk is not shown sd0 it's sd6. Okay , I replaced all references to /dev/sd0X with /dev/sd6X . I unpacked all Archives , reboot and start NetBSD with loadbsd netbsd but it comes only to sd6 at scsibus0 : ............... zthreebus0 at mainbus0 2 mice configured 10 views configured Thats all nothing more. If I boot from the bootdisk , the systems starts but I cant sd6a mount I can't mount sd6a as / In the HDToolbox is everything okay , I checked it twice. Can anybody help ? Thanks for everything Frank ! -- ************************************************************************** " The world is coming to an end . Please log off . " Anonymous Frank Knappe E-Mail : Knappe@tu-harburg.d400.de *************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 01:46:15 1994 X400-Originator: Knappe@tu-harburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=tu-harburg/ADMD=d400-gw/C=de/;<199408122140.XAA27064@indi2.cip] X400-Content-Type: P2-1984 (2) Content-Identifier: Installationp... Alternate-Recipient: Allowed From: Frank Knappe To: amiga@sun-lamp.cs.berkeley.edu Subject: Installationproblem with 1.0 X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1031 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hallo ! I have a great problem with the Installation of NetBSD 1.0 at my A3000 with a 170 MB HD at scsi.device adress 6. I used the binaries from ftp.uni-regensburg and the Installationdoc from the mailinglist , but my harddisk is not shown sd0 it's sd6. Okay , I replaced all references to /dev/sd0X with /dev/sd6X . I unpacked all Archives , reboot and start NetBSD with loadbsd netbsd but it comes only to sd6 at scsibus0 : ............... zthreebus0 at mainbus0 2 mice configured 10 views configured Thats all nothing more. If I boot from the bootdisk , the systems starts but I cant sd6a mount I can't mount sd6a as / In the HDToolbox is everything okay , I checked it twice. Can anybody help ? Thanks for everything Frank ! -- ************************************************************************** " The world is coming to an end . Please log off . " Anonymous Frank Knappe E-Mail : Knappe@tu-harburg.d400.de *************************************************************************** From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 04:38:16 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: sup server on sun-lamp down X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a reason that the sup server on sun-lamp is down (refusing connections)? Just curious. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 06:45:21 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: sup server on sun-lamp down X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a reason that the sup server on sun-lamp is down (refusing connections)? Just curious. --Ken From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 07:58:06 1994 Subject: 1.0beta From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Ok.. I got the full 1.0beta dist set up now (hurray!) some more problems that have come up: once when compiling I got a "kernel jump to zero" panic. on alternative boots I get an MMU panic when init starts up. I'm not handy with the kdb yet so I havent done any investigating yet. I guess I'll do a manual backtrace of the MMU thing next time I come across it. I've also had the console lock up once when I was in more and I hit too many spaces and then several ^C's rapidly. When using PPP I've had some problems. TCP sessions that sent lots of data all at once would freeze up. The modem lights showed that no retransmissions where happening.. pings still got through fine. I'll investigate this more to see if its a simple setup problem. I've used pppd before (on an old kernel with no problems) but I just got a faster modem. Is there a recent binary snapshot of X11R5 around? I checked on ftp site and it had a mid-june date. Will this work fine under 1.0beta? iteconfig doesnt work. It just quits as soon as you run it without doing anything. I tried to do 'iteconfig --info'. I ran it both as root and as the user owning /dev/ttye0 while I was logged into ttye0. The games seem to be messed up. It appears that most programs in /usr/games/* just run programs in /usr/games/hide/*. Tetris complains about not finding the termcap when /usr/games/tetris is run but when /usr/games/hide/tetris is run it works fine. I imagine the /usr/games version strips the environment for security or something along those lines. /usr/games/chess dumped core when run but ran fine from /usr/games/hide/chess. Well not entirely fine.. the terminal handling seemed bad... erases wouldnt work, etc... (like it was in ISIG mode). ... probably more stuff that I forgot to write down and forgot ... Tim N. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 08:21:16 1994 Subject: From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu From: buhrow@cats.ucsc.edu Newsgroups: comp.os.386bsd.questions,comp.os.linux,comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.soundcards Subject: ARE THERE ANY DRIVERS AVAILABLE FOR THE NEWVOICE NV400 VOICE CARDS OR ANY CARDS THAT PROVIDE THE SAME FUNCTIONALITY UNDER NETBSD OR LINUX? References: Sender: Followup-To: Distribution: world Organization: University of California, Santa Cruz Keywords: voice,telephone,Newvoice,Dialogic Hello net world. I was recently asked if I could make a telephone digital interface card for a PC card work under NetBSD or FreeBSD or Linux. Since I don't know the technical name for the card, let me describe what kind of card I mean. The card allows you to play analog matterial over the phone line. In addition, it performs dtmf decoding, allowing the caller at the other end to pass messages to the software controlling the card. An example card is the Newvoice NV400. Another example is a line of dialogic cards. Is there a driver for any cards of this type available for the free unix-like operating systems? The driver can be encumbered, as long as one can purchase a license for the source. If no such driver is available, can anyone suggest a good company that is willing to give out technical documentation sufficient to construct a driver? If you could mail me responses, I would be most appreciative. Also, I will summarize my findings when I finish the inquiry. many thanks. -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 08:48:51 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: sup server on sun-lamp down X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a reason that the sup server on sun-lamp is down (refusing connections)? Just curious. --Ken From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 08:52:18 1994 Subject: 1.0beta From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Ok.. I got the full 1.0beta dist set up now (hurray!) some more problems that have come up: once when compiling I got a "kernel jump to zero" panic. on alternative boots I get an MMU panic when init starts up. I'm not handy with the kdb yet so I havent done any investigating yet. I guess I'll do a manual backtrace of the MMU thing next time I come across it. I've also had the console lock up once when I was in more and I hit too many spaces and then several ^C's rapidly. When using PPP I've had some problems. TCP sessions that sent lots of data all at once would freeze up. The modem lights showed that no retransmissions where happening.. pings still got through fine. I'll investigate this more to see if its a simple setup problem. I've used pppd before (on an old kernel with no problems) but I just got a faster modem. Is there a recent binary snapshot of X11R5 around? I checked on ftp site and it had a mid-june date. Will this work fine under 1.0beta? iteconfig doesnt work. It just quits as soon as you run it without doing anything. I tried to do 'iteconfig --info'. I ran it both as root and as the user owning /dev/ttye0 while I was logged into ttye0. The games seem to be messed up. It appears that most programs in /usr/games/* just run programs in /usr/games/hide/*. Tetris complains about not finding the termcap when /usr/games/tetris is run but when /usr/games/hide/tetris is run it works fine. I imagine the /usr/games version strips the environment for security or something along those lines. /usr/games/chess dumped core when run but ran fine from /usr/games/hide/chess. Well not entirely fine.. the terminal handling seemed bad... erases wouldnt work, etc... (like it was in ISIG mode). ... probably more stuff that I forgot to write down and forgot ... Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 10:47:53 1994 Subject: 1.0beta From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Ok.. I got the full 1.0beta dist set up now (hurray!) some more problems that have come up: once when compiling I got a "kernel jump to zero" panic. on alternative boots I get an MMU panic when init starts up. I'm not handy with the kdb yet so I havent done any investigating yet. I guess I'll do a manual backtrace of the MMU thing next time I come across it. I've also had the console lock up once when I was in more and I hit too many spaces and then several ^C's rapidly. When using PPP I've had some problems. TCP sessions that sent lots of data all at once would freeze up. The modem lights showed that no retransmissions where happening.. pings still got through fine. I'll investigate this more to see if its a simple setup problem. I've used pppd before (on an old kernel with no problems) but I just got a faster modem. Is there a recent binary snapshot of X11R5 around? I checked on ftp site and it had a mid-june date. Will this work fine under 1.0beta? iteconfig doesnt work. It just quits as soon as you run it without doing anything. I tried to do 'iteconfig --info'. I ran it both as root and as the user owning /dev/ttye0 while I was logged into ttye0. The games seem to be messed up. It appears that most programs in /usr/games/* just run programs in /usr/games/hide/*. Tetris complains about not finding the termcap when /usr/games/tetris is run but when /usr/games/hide/tetris is run it works fine. I imagine the /usr/games version strips the environment for security or something along those lines. /usr/games/chess dumped core when run but ran fine from /usr/games/hide/chess. Well not entirely fine.. the terminal handling seemed bad... erases wouldnt work, etc... (like it was in ISIG mode). ... probably more stuff that I forgot to write down and forgot ... Tim N. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 11:25:17 1994 Subject: From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu From: buhrow@cats.ucsc.edu Newsgroups: comp.os.386bsd.questions,comp.os.linux,comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.soundcards Subject: ARE THERE ANY DRIVERS AVAILABLE FOR THE NEWVOICE NV400 VOICE CARDS OR ANY CARDS THAT PROVIDE THE SAME FUNCTIONALITY UNDER NETBSD OR LINUX? References: Sender: Followup-To: Distribution: world Organization: University of California, Santa Cruz Keywords: voice,telephone,Newvoice,Dialogic Hello net world. I was recently asked if I could make a telephone digital interface card for a PC card work under NetBSD or FreeBSD or Linux. Since I don't know the technical name for the card, let me describe what kind of card I mean. The card allows you to play analog matterial over the phone line. In addition, it performs dtmf decoding, allowing the caller at the other end to pass messages to the software controlling the card. An example card is the Newvoice NV400. Another example is a line of dialogic cards. Is there a driver for any cards of this type available for the free unix-like operating systems? The driver can be encumbered, as long as one can purchase a license for the source. If no such driver is available, can anyone suggest a good company that is willing to give out technical documentation sufficient to construct a driver? If you could mail me responses, I would be most appreciative. Also, I will summarize my findings when I finish the inquiry. many thanks. -Brian From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Aug 13 11:45:50 1994 From: chopps@emunix.emich.edu To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: slow kernel <9408102257.AA00283@della.appli.se> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Adding 8M of 16 bit ram will slow your system down considerably I would think. Chris. (who will have a way to not configure 16bit z2 mem when he adds non contig memory support for just this reason.) P.s. the rts source would be nice to look at. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 11:53:01 1994 From: chopps@emunix.emich.edu To: Frank Knappe Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 <199408122140.XAA27064@indi2.cip3s.tu-harburg.de> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu It sounds like you forgot to copy the dev dir from the floppy. (i.e. you don't have a dev/console on the boot disk) Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 11:55:28 1994 Subject: 1.0beta From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Ok.. I got the full 1.0beta dist set up now (hurray!) some more problems that have come up: once when compiling I got a "kernel jump to zero" panic. on alternative boots I get an MMU panic when init starts up. I'm not handy with the kdb yet so I havent done any investigating yet. I guess I'll do a manual backtrace of the MMU thing next time I come across it. I've also had the console lock up once when I was in more and I hit too many spaces and then several ^C's rapidly. When using PPP I've had some problems. TCP sessions that sent lots of data all at once would freeze up. The modem lights showed that no retransmissions where happening.. pings still got through fine. I'll investigate this more to see if its a simple setup problem. I've used pppd before (on an old kernel with no problems) but I just got a faster modem. Is there a recent binary snapshot of X11R5 around? I checked on ftp site and it had a mid-june date. Will this work fine under 1.0beta? iteconfig doesnt work. It just quits as soon as you run it without doing anything. I tried to do 'iteconfig --info'. I ran it both as root and as the user owning /dev/ttye0 while I was logged into ttye0. The games seem to be messed up. It appears that most programs in /usr/games/* just run programs in /usr/games/hide/*. Tetris complains about not finding the termcap when /usr/games/tetris is run but when /usr/games/hide/tetris is run it works fine. I imagine the /usr/games version strips the environment for security or something along those lines. /usr/games/chess dumped core when run but ran fine from /usr/games/hide/chess. Well not entirely fine.. the terminal handling seemed bad... erases wouldnt work, etc... (like it was in ISIG mode). ... probably more stuff that I forgot to write down and forgot ... Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 13 11:57:47 1994 From: chopps@emunix.emich.edu To: tjhayko@io.org (Tom Hayko) Cc: amiga@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: NetBSD Kernelk (fwd) X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sounds like you forgot to copy the dev dir from the floppy. (you need /dev/console or it will hang as described) Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 13 12:06:48 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: sup server on sun-lamp down X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a reason that the sup server on sun-lamp is down (refusing connections)? Just curious. --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Aug 13 12:32:46 1994 From: chopps@emunix.emich.edu To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: slow kernel <9408102257.AA00283@della.appli.se> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Adding 8M of 16 bit ram will slow your system down considerably I would think. Chris. (who will have a way to not configure 16bit z2 mem when he adds non contig memory support for just this reason.) P.s. the rts source would be nice to look at. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 02:26:31 1994 Subject: X install From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu a few problems with the X FAQ /usr/lib/X11 should point to /usr/X11/lib/X11 not /usr/X11/lib /usr/X11R5 and /usr/X11 must both point to the spot you installed the X dist at. The FAQ tells you to make a /usr/X11 symlink but doesnt mention that /usr/X11R5 sym link. The Xserver ends up using /usr/X11R5/lib/X11/fonts to find fonts and will fail if you dont have X11R5. Tim N. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Aug 14 02:35:54 1994 From: chopps@emunix.emich.edu To: amiga-x@sun-lamp.cs.berkeley.edu Subject: xload diffs. X-Mts: smtp Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Here is what I think is a better diff to xload for NetBSD. (I pasted from x so watchout for spaces where tabs should be) Chris. *** get_load.c.orig Thu Jul 25 14:21:17 1991 --- get_load.c Sat Aug 13 15:07:01 1994 *************** *** 121,126 **** --- 121,141 ---- static xload_error(); + #ifdef __NetBSD__ + #include + #include + + void InitLoadPoint() {} + + /* ARGSUSED */ + void GetLoadPoint( w, closure, call_data ) + Widget w; /* unused */ + caddr_t closure; /* unused */ + caddr_t call_data; /* pointer to (double) return value */ + { + getloadavg((double *)call_data, 1); + } + #else /* not __NetBSD__ */ #ifdef apollo #include *************** *** 719,724 **** (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* apollo else */ --- 734,739 ---- (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* __NetBSD__ else */ #endif /* apollo else */ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 02:48:59 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 02:49:29 1994 From: chopps@emunix.emich.edu To: Frank Knappe Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 <199408122140.XAA27064@indi2.cip3s.tu-harburg.de> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu It sounds like you forgot to copy the dev dir from the floppy. (i.e. you don't have a dev/console on the boot disk) Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 02:54:44 1994 X400-Originator: Knappe@tu-harburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=tu-harburg/ADMD=d400-gw/C=de/;<199408140004.CAA28640@indi2.cip] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Installat... Alternate-Recipient: Allowed From: Frank Knappe To: msanders@osiris.usi.utah.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1252 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I'm having the same problem on my A3000, 8M Fast/2M Chip, 240M HD. > I also noticed, contrary to what the install doc says, that my hd > (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. > > I'm also experience another little oddity. When booting from fd0, after > the '10 views configured' I get a message something like 'WARNING: No Swap > Space Found'. I triple checked the partition in HDToolBox, and it looks > right to me. When trying to boot from sd3a (after newfs'ing and installing > all the files from release/) it just hangs after the '10 views config' > message. > > Help? :) > > - Mike > I found the mistake , which is the reason for your and my Problem. In the Installationdoc standa after untar all .tar.gz Files cd /altroot/dev tar -cf - /dev | tar -xvpf - And then you have all dev-Files in /altroo/dev/dev ! Therefor I only change to /altroot and untar the dev-Files and boot and everything is fine Frank ! -- ************************************************************************** " The world is coming to an end . Please log off . " Anonymous Frank Knappe E-Mail : Knappe@tu-harburg.d400.de *************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:04:01 1994 From: chopps@emunix.emich.edu To: tjhayko@io.org (Tom Hayko) Cc: amiga@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: NetBSD Kernelk (fwd) X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sounds like you forgot to copy the dev dir from the floppy. (you need /dev/console or it will hang as described) Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 03:07:28 1994 From: vdlinden@fwi.uva.nl (Frank van der Linden) X-Organisation: Faculty of Mathematics & Computer Science University of Amsterdam Kruislaan 403 NL-1098 SJ Amsterdam The Netherlands X-Phone: +31 20 525 7463 X-Telex: 10262 hef nl X-Fax: +31 20 525 7490 To: current-users@sun-lamp.cs.berkeley.edu Subject: console drivers bugs ? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, When I gave the latest version of the editor joe a try (you can find it at ftp.std.com:src/editors/joe1.0.11.tar.Z), I stumbled across the following two oddities: 1. Using either one of the console drivers, joe seems to behave incorrect. Try the following: a. Ctrl-K h b. Choose any help screen you want c. Hit PGDN a couple of times. This results in the dissapearance of the help screen, something that did not happen when I tried it on my computer at work which was connected to a pyramid and ran kermit as the vt220 emulator. Two questions: a. Can anybody out there duplicate my results ? b. Is this a bug in joe or in NetBSD ? 2. I use pcvt as my console driver. This means that my /etc/ttys contains the following fragment: console "/usr/libexec/getty Pc" pcvt off secure #vga "/usr/libexec/getty Pc" pcvt on secure ttyv0 "/usr/libexec/getty Pc" pcvt on secure ttyv1 "/usr/libexec/getty Pc" pcvt on secure ttyv2 "/usr/libexec/getty Pc" pcvt on secure If I try to run a kernel with the pccons console driver using the /etc/ttys that has ttyv[0-7] in it I get the following panic when ttyflags is started from /etc/rc: vm_fault (f8664b00, 0, 3, 0) -> 1 fatal page fault in supervisor mode trap type 6 code 2 eip f818690b cs f8660088 eflags 10202 cr2 bs cpl 0 Everything will work fine when I comment out ttyv[1-7] in /etc/ttys. Onno van der Linden c/o vdlinden@fwi.uva.nl (Frank van der Linden) From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 03:07:40 1994 From: Scott Reynolds Subject: Digiboard PC/x driver To: port-i386 , current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm working on a driver for the Digiboard PC/x multiport cards, and I'm wondering if anybody out there has programming info on the card. I'm not having a particularly easy time getting info from Digi, unfortunately. I've got a card here and the time to work on it... if anyone can help, please let me know. Scott Reynolds Assistant System Administrator Technology Group, Inc. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 03:17:54 1994 From: chopps@emunix.emich.edu To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: slow kernel <9408102257.AA00283@della.appli.se> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Adding 8M of 16 bit ram will slow your system down considerably I would think. Chris. (who will have a way to not configure 16bit z2 mem when he adds non contig memory support for just this reason.) P.s. the rts source would be nice to look at. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 03:20:28 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: hang during reboot if using NQNFS X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a dataless machine here (only local root and swap partition) that I'm mounting /usr via NFS from another machine. Both machines are running NetBSD 1.0_BETA from August 11th. I was trying to use the 4.4 NQNFS stuff to mount /usr, since it has very nice cache leasing support another other features. It works fine, but when I try to reboot the machine, it hangs. I've tracked it down to where the machine hangs whenever you kill the nqnfs client helper daemon. If you don't use nqnfs, then it works fine. I'm assuming this has something to with the fact that /usr is busy when the machine is rebooted. Before I dive in and attempt to figure this all out, anyone else got any ideas? Is anyone else trying to do what I'm doing? --Ken From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:20:41 1994 From: "Hubert Feyrer" "1.0beta" (Aug 12, 7:21pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: 1.0beta Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Is there a recent binary snapshot of X11R5 around? I checked on > ftp site and it had a mid-june date. Will this work fine under > 1.0beta? The one in /pub/NetBSD-Amiga/contrib/X11 on ftp.uni-regensburg.de works fine for me. > iteconfig doesnt work. It just quits as soon as you run it without > doing anything. I tried to do 'iteconfig --info'. I ran it both > as root and as the user owning /dev/ttye0 while I was logged into > ttye0. You've to be in multiuser-mode or have at least /usr/libexec mounte to use iteconfig. Works fine here. Have you tried ktracing it? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Aug 14 03:21:50 1994 From: chopps@emunix.emich.edu To: amiga-x@sun-lamp.cs.berkeley.edu Subject: xload diffs. X-Mts: smtp Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Here is what I think is a better diff to xload for NetBSD. (I pasted from x so watchout for spaces where tabs should be) Chris. *** get_load.c.orig Thu Jul 25 14:21:17 1991 --- get_load.c Sat Aug 13 15:07:01 1994 *************** *** 121,126 **** --- 121,141 ---- static xload_error(); + #ifdef __NetBSD__ + #include + #include + + void InitLoadPoint() {} + + /* ARGSUSED */ + void GetLoadPoint( w, closure, call_data ) + Widget w; /* unused */ + caddr_t closure; /* unused */ + caddr_t call_data; /* pointer to (double) return value */ + { + getloadavg((double *)call_data, 1); + } + #else /* not __NetBSD__ */ #ifdef apollo #include *************** *** 719,724 **** (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* apollo else */ --- 734,739 ---- (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* __NetBSD__ else */ #endif /* apollo else */ From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:23:10 1994 Subject: X install From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu a few problems with the X FAQ /usr/lib/X11 should point to /usr/X11/lib/X11 not /usr/X11/lib /usr/X11R5 and /usr/X11 must both point to the spot you installed the X dist at. The FAQ tells you to make a /usr/X11 symlink but doesnt mention that /usr/X11R5 sym link. The Xserver ends up using /usr/X11R5/lib/X11/fonts to find fonts and will fail if you dont have X11R5. Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 03:30:41 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:40:46 1994 From: chopps@emunix.emich.edu To: Frank Knappe Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 <199408122140.XAA27064@indi2.cip3s.tu-harburg.de> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu It sounds like you forgot to copy the dev dir from the floppy. (i.e. you don't have a dev/console on the boot disk) Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:52:14 1994 X400-Originator: Knappe@tu-harburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=tu-harburg/ADMD=d400-gw/C=de/;<199408140004.CAA28640@indi2.cip] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Installat... Alternate-Recipient: Allowed From: Frank Knappe To: msanders@osiris.usi.utah.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1252 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I'm having the same problem on my A3000, 8M Fast/2M Chip, 240M HD. > I also noticed, contrary to what the install doc says, that my hd > (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. > > I'm also experience another little oddity. When booting from fd0, after > the '10 views configured' I get a message something like 'WARNING: No Swap > Space Found'. I triple checked the partition in HDToolBox, and it looks > right to me. When trying to boot from sd3a (after newfs'ing and installing > all the files from release/) it just hangs after the '10 views config' > message. > > Help? :) > > - Mike > I found the mistake , which is the reason for your and my Problem. In the Installationdoc standa after untar all .tar.gz Files cd /altroot/dev tar -cf - /dev | tar -xvpf - And then you have all dev-Files in /altroo/dev/dev ! Therefor I only change to /altroot and untar the dev-Files and boot and everything is fine Frank ! -- ************************************************************************** " The world is coming to an end . Please log off . " Anonymous Frank Knappe E-Mail : Knappe@tu-harburg.d400.de *************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 03:55:37 1994 From: chopps@emunix.emich.edu To: tjhayko@io.org (Tom Hayko) Cc: amiga@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: NetBSD Kernelk (fwd) X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sounds like you forgot to copy the dev dir from the floppy. (you need /dev/console or it will hang as described) Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 04:01:56 1994 From: hvozda@netcom.com (Eric S. Hvozda) Subject: PCMCIA SCSI host adapaters To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 74 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do we support them? Are there any others out there other than Adaptec's? From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 04:05:43 1994 From: chopps@emunix.emich.edu To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: slow kernel <9408102257.AA00283@della.appli.se> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Adding 8M of 16 bit ram will slow your system down considerably I would think. Chris. (who will have a way to not configure 16bit z2 mem when he adds non contig memory support for just this reason.) P.s. the rts source would be nice to look at. From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Aug 14 04:09:49 1994 From: chopps@emunix.emich.edu To: amiga-x@sun-lamp.cs.berkeley.edu Subject: xload diffs. X-Mts: smtp Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Here is what I think is a better diff to xload for NetBSD. (I pasted from x so watchout for spaces where tabs should be) Chris. *** get_load.c.orig Thu Jul 25 14:21:17 1991 --- get_load.c Sat Aug 13 15:07:01 1994 *************** *** 121,126 **** --- 121,141 ---- static xload_error(); + #ifdef __NetBSD__ + #include + #include + + void InitLoadPoint() {} + + /* ARGSUSED */ + void GetLoadPoint( w, closure, call_data ) + Widget w; /* unused */ + caddr_t closure; /* unused */ + caddr_t call_data; /* pointer to (double) return value */ + { + getloadavg((double *)call_data, 1); + } + #else /* not __NetBSD__ */ #ifdef apollo #include *************** *** 719,724 **** (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* apollo else */ --- 734,739 ---- (void) fprintf(stderr,"xload: %s %s\n", str1, str2); exit(-1); } ! #endif /* __NetBSD__ else */ #endif /* apollo else */ From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 04:11:11 1994 Subject: From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu From: buhrow@cats.ucsc.edu Newsgroups: comp.os.386bsd.questions,comp.os.linux,comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.soundcards Subject: ARE THERE ANY DRIVERS AVAILABLE FOR THE NEWVOICE NV400 VOICE CARDS OR ANY CARDS THAT PROVIDE THE SAME FUNCTIONALITY UNDER NETBSD OR LINUX? References: Sender: Followup-To: Distribution: world Organization: University of California, Santa Cruz Keywords: voice,telephone,Newvoice,Dialogic Hello net world. I was recently asked if I could make a telephone digital interface card for a PC card work under NetBSD or FreeBSD or Linux. Since I don't know the technical name for the card, let me describe what kind of card I mean. The card allows you to play analog matterial over the phone line. In addition, it performs dtmf decoding, allowing the caller at the other end to pass messages to the software controlling the card. An example card is the Newvoice NV400. Another example is a line of dialogic cards. Is there a driver for any cards of this type available for the free unix-like operating systems? The driver can be encumbered, as long as one can purchase a license for the source. If no such driver is available, can anyone suggest a good company that is willing to give out technical documentation sufficient to construct a driver? If you could mail me responses, I would be most appreciative. Also, I will summarize my findings when I finish the inquiry. many thanks. -Brian From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 04:16:41 1994 Subject: X install From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu a few problems with the X FAQ /usr/lib/X11 should point to /usr/X11/lib/X11 not /usr/X11/lib /usr/X11R5 and /usr/X11 must both point to the spot you installed the X dist at. The FAQ tells you to make a /usr/X11 symlink but doesnt mention that /usr/X11R5 sym link. The Xserver ends up using /usr/X11R5/lib/X11/fonts to find fonts and will fail if you dont have X11R5. Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 04:17:19 1994 From: "Hubert Feyrer" "1.0beta" (Aug 12, 7:21pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I Subject: Re: 1.0beta Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Is there a recent binary snapshot of X11R5 around? I checked on > ftp site and it had a mid-june date. Will this work fine under > 1.0beta? The one in /pub/NetBSD-Amiga/contrib/X11 on ftp.uni-regensburg.de works fine for me. > iteconfig doesnt work. It just quits as soon as you run it without > doing anything. I tried to do 'iteconfig --info'. I ran it both > as root and as the user owning /dev/ttye0 while I was logged into > ttye0. You've to be in multiuser-mode or have at least /usr/libexec mounte to use iteconfig. Works fine here. Have you tried ktracing it? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 04:48:52 1994 Subject: From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I found out what my PPP problems where. It appears the serial line cant keep up with large packets at 14.4 on my computer. I noticed this while downloading files with rz. I would get errors very periodically. I lowered the speed to 9.6 and everything worked ok. In ppp I tried ping -s pearl where pearl is my gateway. The biggest packet that I could get through is 890 bytes (counting the IP/ICMP header). After 890 bytes all packets are dropped. When I set the MRU to 890 everything works fine but slow. I am using hardware flow-control btw... Someone else mentioned problems with the serial line but I dont remember the exact details. Is anyong currently going through the serial code? Tim N. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 05:18:58 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: hang during reboot if using NQNFS X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a dataless machine here (only local root and swap partition) that I'm mounting /usr via NFS from another machine. Both machines are running NetBSD 1.0_BETA from August 11th. I was trying to use the 4.4 NQNFS stuff to mount /usr, since it has very nice cache leasing support another other features. It works fine, but when I try to reboot the machine, it hangs. I've tracked it down to where the machine hangs whenever you kill the nqnfs client helper daemon. If you don't use nqnfs, then it works fine. I'm assuming this has something to with the fact that /usr is busy when the machine is rebooted. Before I dive in and attempt to figure this all out, anyone else got any ideas? Is anyone else trying to do what I'm doing? --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 05:28:45 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: sigsetjmp/siglongjmp, anybody have code for 'em? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 210 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anybody have some emulation code for sigsetjmp and siglongjmp? The newest FlexFax needs them and they are "to be implemented" still on NetBSD. B^(. Would the 4.4 source have the code for them? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 05:55:39 1994 From: hvozda@netcom.com (Eric S. Hvozda) Subject: PCMCIA SCSI host adapaters To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 74 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do we support them? Are there any others out there other than Adaptec's? From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 06:17:27 1994 Subject: From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu From: buhrow@cats.ucsc.edu Newsgroups: comp.os.386bsd.questions,comp.os.linux,comp.sys.ibm.pc.hardware.misc,comp.sys.ibm.pc.soundcards Subject: ARE THERE ANY DRIVERS AVAILABLE FOR THE NEWVOICE NV400 VOICE CARDS OR ANY CARDS THAT PROVIDE THE SAME FUNCTIONALITY UNDER NETBSD OR LINUX? References: Sender: Followup-To: Distribution: world Organization: University of California, Santa Cruz Keywords: voice,telephone,Newvoice,Dialogic Hello net world. I was recently asked if I could make a telephone digital interface card for a PC card work under NetBSD or FreeBSD or Linux. Since I don't know the technical name for the card, let me describe what kind of card I mean. The card allows you to play analog matterial over the phone line. In addition, it performs dtmf decoding, allowing the caller at the other end to pass messages to the software controlling the card. An example card is the Newvoice NV400. Another example is a line of dialogic cards. Is there a driver for any cards of this type available for the free unix-like operating systems? The driver can be encumbered, as long as one can purchase a license for the source. If no such driver is available, can anyone suggest a good company that is willing to give out technical documentation sufficient to construct a driver? If you could mail me responses, I would be most appreciative. Also, I will summarize my findings when I finish the inquiry. many thanks. -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 06:41:54 1994 From: hvozda@apache.raynet.com (Eric Hvozda - API) Subject: Duplicated postings to current-users? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu am I the only on seeing these? I've seen about 4 copies of both Ken Hornstein's and Scott Reynold's mail now... -- Ack! Creek, not creek; Pop not soda; Car needs washed... From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 07:18:36 1994 From: Steven Butler Subject: Duplicate messages To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anyone else on this list keep getting massive amounts of duplicate messages sent to them. I have received a number of messages about 5 to 10 times in the last few days. Steve. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 07:18:55 1994 To: hvozda@apache.raynet.com (Eric Hvozda - API) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Duplicated postings to current-users? <9408140324.AA16834@ops.menlo> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > am I the only on seeing these? I've seen about 4 copies of both Ken > Hornstein's and Scott Reynold's mail now... Somebody managed to create a mail loop. it's been taken care of. chris From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 07:20:47 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: hang during reboot if using NQNFS X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a dataless machine here (only local root and swap partition) that I'm mounting /usr via NFS from another machine. Both machines are running NetBSD 1.0_BETA from August 11th. I was trying to use the 4.4 NQNFS stuff to mount /usr, since it has very nice cache leasing support another other features. It works fine, but when I try to reboot the machine, it hangs. I've tracked it down to where the machine hangs whenever you kill the nqnfs client helper daemon. If you don't use nqnfs, then it works fine. I'm assuming this has something to with the fact that /usr is busy when the machine is rebooted. Before I dive in and attempt to figure this all out, anyone else got any ideas? Is anyone else trying to do what I'm doing? --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 07:29:46 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: sigsetjmp/siglongjmp, anybody have code for 'em? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 210 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anybody have some emulation code for sigsetjmp and siglongjmp? The newest FlexFax needs them and they are "to be implemented" still on NetBSD. B^(. Would the 4.4 source have the code for them? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 07:57:55 1994 From: hvozda@netcom.com (Eric S. Hvozda) Subject: PCMCIA SCSI host adapaters To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 74 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do we support them? Are there any others out there other than Adaptec's? From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 08:02:54 1994 To: hvozda@apache.raynet.com (Eric Hvozda - API) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Duplicated postings to current-users? <9408140324.AA16834@ops.menlo> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3146.776839345.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > am I the only on seeing these? I've seen about 4 copies of both Ken > Hornstein's and Scott Reynold's mail now... You are not; some local mailing list on a host (amy.engr.wisc.edu) seems to be reflecting messages back to sun-lamp... I've mailed the postmaster there; no reply yet. Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 08:18:07 1994 From: Alan Bair Subject: Re: Duplicate messages To: seb@cs.uq.oz.au (Steven Butler) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Does anyone else on this list keep getting massive amounts of duplicate > messages sent to them. I have received a number of messages about 5 to > 10 times in the last few days. Yep, I first thought it was just posting the same article to different lists, but each message seems to be duplicated within each list. It seemd to have started several days ago. > > Steve. > > -- 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 owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 08:24:26 1994 From: Steven Butler Subject: Re: Duplicate messages To: Alan Bair Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Sun, 14 Aug 1994, Alan Bair wrote: > > > > > > Does anyone else on this list keep getting massive amounts of duplicate > > messages sent to them. I have received a number of messages about 5 to > > 10 times in the last few days. > > Yep, I first thought it was just posting the same article to different > lists, but each message seems to be duplicated within each list. It > seemd to have started several days ago. Well, in that case, if the maintainers of the list see this message, I guess it would be much appreciated by everyone if it were fixed soon. Thanks, Steve. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 09:05:26 1994 From: "L. Todd Masco" To: amiga@sun-lamp.cs.berkeley.edu Subject: Ethernet cards? Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm about to buy an Ethernet card for my A3000... I was wondering what would be best for NetBSD. I'd prefer ZIII, of course, but price is also an issue. I've heard discussion of the Hydra card: is any other known to work with NetBSD? Thanks, -- Todd -- L. Todd Masco | Bibliobytes books on computer, on any UNIX host with e-mail cactus@bb.com | "Information wants to be free, but authors want to be paid." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 09:56:02 1994 From: Danny Lepage Subject: Re: Slow PPP To: newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1249 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > I found out what my PPP problems where. It appears the serial > line cant keep up with large packets at 14.4 on my computer. > I noticed this while downloading files with rz. I would get > errors very periodically. I lowered the speed to 9.6 and > everything worked ok. In ppp I tried ping -s pearl > where pearl is my gateway. The biggest packet that I could get > through is 890 bytes (counting the IP/ICMP header). After > 890 bytes all packets are dropped. When I set the MRU > to 890 everything works fine but slow. I am using hardware > flow-control btw... > > Someone else mentioned problems with the serial line but > I dont remember the exact details. Is anyong currently > going through the serial code? > > Tim N. > I also experienced bad transfert rate (SLIP) since I installed the 1.0beta pre-release distribution. I was planning to do some test in ADOS with AmiTCP, just to make sure that the problem is not on my internet provider site. (I've got a real problem here, something that took about 1/2 an hour to transfert, now would take between 3 to 4 hours [14.4k]). Does everybody running 1.0beta noticed such behavior? Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-tech-kern@sun-lamp.cs.berkeley.edu Sun Aug 14 11:30:25 1994 From: blymn@awadi.com.AU (Brett Lymn) Subject: Re: Whoa, hang on a minute.... To: tech-kern@sun-lamp.cs.berkeley.edu (Technical Kernel Mailing List) X-Mailer: ELM [version 2.4 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 2657 Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu According to mycroft@gnu.ai.mit.edu: > >I said, *quite clearly*, that the proposed `fix' will cause occasional >timeouts on *correctly functioning hardware*. *That* is what bothers >me. > Ummm I this I must have always missed the last part of your first sentence. OK fine, if it breaks functioning hardware it is not unreasonable to be bothered about it. How about a bit of a recraft of wd.c (bear with me ....) so that when the controller is first probed the altsts is checked first, if this works it is always used, if not then try status instead if that works it is always used otherwise give up on the controller. If the code is done so the check is only done in the probe then there should be little overhead in the driver and would mean that the driver would automatically use the correct register. >I am *not* going to repeat myself again. I'm getting really pissed off >at being harassed about this. > I can understand that but please see my side of it. I have about 480Meg of disk on ESDI controller, I want that space. I have spent countless hours stuffing around trying to get 'current onto my machine - watching heaps of reboots just to piece together the message that the kernel could not mount /, then thinking that my /dev directory was not right so whilst running from floppy managed (finally) to bash MAKEDEV into a shape that would run from floppy only to find that it was not the problem.... and so the story goes. I would prefer spending my time putting vm86() into the 'current kernel not just trying to get the thing working on my system. If you are willing I could make the changes I suggested to the driver. I did think about this quite a bit before starting this up, I am really worried that we will paint ourselves into a corner regarding the hardware supported. I have had a couple of people ask me about NetBSD, they are scrounging up a system out of old hardware because their bosses are tight with the money (aren't they all?). The last thing that I want to happen is to tell them "you gotta buy a new disk controller/whatever". If what we can make a driver work right for good hardware _and_ cope with dud stuff without penalty then let's do it! BTW you kept referring to "the spec" which spec is this? Is it one for IDE drives? -- Brett Lymn, Computer Systems Administrator, AWA Defence Industries =============================================================================== "Where a calculator on the ENIAC is equipped with 18,000 vacuum tubes and weighs 30 tons, computers in the future may have only 1,000 vacuum tubes and perhaps weigh 1 1/2 tons." -- Popular Mechanics, March 1949 From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 11:48:21 1994 From: msanders@osiris.usi.utah.edu To: Knappe@tu-harburg.d400.de, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm having the same problem on my A3000, 8M Fast/2M Chip, 240M HD. I also noticed, contrary to what the install doc says, that my hd (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. I'm also experience another little oddity. When booting from fd0, after the '10 views configured' I get a message something like 'WARNING: No Swap Space Found'. I triple checked the partition in HDToolBox, and it looks right to me. When trying to boot from sd3a (after newfs'ing and installing all the files from release/) it just hangs after the '10 views config' message. Help? :) - Mike From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 12:27:51 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, hvozda@netcom.com Subject: Re: PCMCIA SCSI host adapaters Sender: owner-current-users@sun-lamp.cs.berkeley.edu Do we support them? `Not yet', but it's being worked on. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 12:36:21 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, hvozda@apache.raynet.com Subject: Re: Duplicated postings to current-users? Sender: owner-current-users@sun-lamp.cs.berkeley.edu am I the only on seeing these? No. There was a losing AmigaDOS mailer apparently resending things to the `To:' line rather than the SMTP `RCPT TO:' address. It appears to have been nuked. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 13:01:13 1994 From: "Hubert Feyrer" "Ethernet cards?" (Aug 14, 2:34am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet cards? Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 14, 2:34am, L. Todd Masco wrote: > I've heard discussion of the Hydra card: is any other known to work with > NetBSD? A2065 works fine here. :-) Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 13:37:21 1994 From: "Hubert Feyrer" "Duplicated postings to current-users?" (Aug 13, 8:24pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I am I the only on seeing these? I've seen about 4 copies of both Ken > Hornstein's and Scott Reynold's mail now... No, you're not! And this doesn't only happen on the current-list, but also on some others. Is Majordomo screwed? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 14:43:06 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/etc/etc.sparc/install.sh U src/etc/namedb/root.cache U src/gnu/usr.bin/gas/config/obj-aout.h U src/gnu/usr.bin/gcc2/cpp/usr.bin.cpp.sh U src/gnu/usr.bin/ld/ld.c U src/gnu/usr.bin/ld/ldd/ldd.c U src/include/rpc/xdr.h U src/lib/libc/gen/fstab.c U src/lib/libc/rpc/xdr.c U src/lib/libkvm/kvm_proc.c U src/sbin/slattach/slattach.8 U src/share/man/man5/a.out.5 U src/sys/arch/hp300/hp300/vm_machdep.c U src/sys/arch/hp300/include/proc.h U src/sys/arch/i386/conf/PATEK U src/sys/arch/i386/conf/TDR U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/include/psl.h U src/sys/arch/i386/isa/icu.s U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_ie.c U src/sys/arch/m68k/m68k/db_disasm.h U src/sys/arch/sparc/include/cgtworeg.h U src/sys/arch/sparc/sbus/esp.c U src/sys/arch/vax/README U src/sys/arch/vax/conf/GENERIC U src/sys/arch/vax/conf/Makefile.vax U src/sys/arch/vax/conf/files.vax.newconf U src/sys/arch/vax/conf/std.vax U src/sys/arch/vax/if/if_de.c U src/sys/arch/vax/if/if_dereg.h U src/sys/arch/vax/if/if_uba.c U src/sys/arch/vax/if/if_uba.h U src/sys/arch/vax/include/ansi.h U src/sys/arch/vax/include/asm.h U src/sys/arch/vax/include/cpu.h U src/sys/arch/vax/include/endian.h U src/sys/arch/vax/include/exec.h U src/sys/arch/vax/include/float.h U src/sys/arch/vax/include/ioa.h U src/sys/arch/vax/include/ka750.h U src/sys/arch/vax/include/kg.h U src/sys/arch/vax/include/limits.h U src/sys/arch/vax/include/loconf.h U src/sys/arch/vax/include/macros.h U src/sys/arch/vax/include/mtpr.h U src/sys/arch/vax/include/nexus.h U src/sys/arch/vax/include/param.h U src/sys/arch/vax/include/pcb.h U src/sys/arch/vax/include/pmap.h U src/sys/arch/vax/include/proc.h U src/sys/arch/vax/include/psl.h U src/sys/arch/vax/include/pte.h U src/sys/arch/vax/include/ptrace.h U src/sys/arch/vax/include/reg.h U src/sys/arch/vax/include/scb.h U src/sys/arch/vax/include/sid.h U src/sys/arch/vax/include/signal.h U src/sys/arch/vax/include/stdarg.h U src/sys/arch/vax/include/trap.h U src/sys/arch/vax/include/types.h U src/sys/arch/vax/include/varargs.h U src/sys/arch/vax/include/vmparam.h U src/sys/arch/vax/uba/uba.c U src/sys/arch/vax/uba/ubareg.h U src/sys/arch/vax/uba/ubavar.h U src/sys/arch/vax/uba/uda.c U src/sys/arch/vax/uba/udareg.h U src/sys/arch/vax/vax/bcopy.s U src/sys/arch/vax/vax/conf.c U src/sys/arch/vax/vax/disksubr.c U src/sys/arch/vax/vax/glue.c U src/sys/arch/vax/vax/in_cksum.c U src/sys/arch/vax/vax/intvec.s U src/sys/arch/vax/vax/ka750.c U src/sys/arch/vax/vax/locon.s U src/sys/arch/vax/vax/locore.s U src/sys/arch/vax/vax/machdep.c U src/sys/arch/vax/vax/mscp.c U src/sys/arch/vax/vax/mscp.h U src/sys/arch/vax/vax/mscpvar.h U src/sys/arch/vax/vax/pmap.c U src/sys/arch/vax/vax/random.s U src/sys/arch/vax/vax/rootfil.c U src/sys/arch/vax/vax/skit.c U src/sys/arch/vax/vax/swapgeneric.c U src/sys/arch/vax/vax/trap.c U src/sys/arch/vax/vax/udiv.s U src/sys/arch/vax/vax/urem.s U src/sys/arch/vax/vax/vm_machdep.c U src/sys/dev/ccd.c U src/sys/kern/vfs_syscalls.c U src/sys/lib/Makefile U src/sys/lib/libsa/gets.c U src/sys/net/if.c U src/sys/net/if.h U src/sys/net/netisr.h U src/sys/nfs/nfs_vfsops.c U src/sys/sys/exec_aout.h U src/sys/sys/proc.h U src/usr.bin/mail/Makefile Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun Aug 14 04:12:54 1994 SUP Scan for current completed at Sun Aug 14 04:15:23 1994 SUP Scan for mirror starting at Sun Aug 14 04:15:24 1994 SUP Scan for mirror completed at Sun Aug 14 04:17:52 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 18:11:44 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Ken Hornstein Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: sup server on sun-lamp down <9408130059.AA14998@entropic.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ken Hornstein writes: > Is there a reason that the sup server on sun-lamp is down (refusing > connections)? Just curious. I just checked and it's refusing connections today as well. What's up? Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 19:18:41 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: msanders@osiris.usi.utah.edu, Knappe@tu-harburg.d400.de, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 13, 1:12pm, msanders@osiris.usi.utah.edu wrote: > I also noticed, contrary to what the install doc says, that my hd > (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. The release install doc is for the release kernel configuration. I would suspect the kernel you are running was made before the scsi disk device config changes. [I haven't kept up with the release kernel since I'm always building my own and haven't taken the time to try out the provided kernels.] > I'm also experience another little oddity. When booting from fd0, after > the '10 views configured' I get a message something like 'WARNING: No Swap > Space Found'. I triple checked the partition in HDToolBox, and it looks The GENERIC and A3000 kernels use a generic swap - the swap partition is expected to exist on the same device as the root file system. (Do you really want the kernel to use the floppy as a swap device? :-)) Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 19:25:14 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: msanders@osiris.usi.utah.edu, Knappe@tu-harburg.d400.de, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 13, 1:12pm, msanders@osiris.usi.utah.edu wrote: > I also noticed, contrary to what the install doc says, that my hd > (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. The release install doc is for the release kernel configuration. I would suspect the kernel you are running was made before the scsi disk device config changes. [I haven't kept up with the release kernel since I'm always building my own and haven't taken the time to try out the provided kernels.] > I'm also experience another little oddity. When booting from fd0, after > the '10 views configured' I get a message something like 'WARNING: No Swap > Space Found'. I triple checked the partition in HDToolBox, and it looks The GENERIC and A3000 kernels use a generic swap - the swap partition is expected to exist on the same device as the root file system. (Do you really want the kernel to use the floppy as a swap device? :-)) Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 19:30:37 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "L. Todd Masco" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet cards? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 14, 2:34am, "L. Todd Masco" wrote: > I'm about to buy an Ethernet card for my A3000... I was wondering what > would be best for NetBSD. I'd prefer ZIII, of course, but price is also an issue. Are there any Zorro III Ethernet boards available yet? > I've heard discussion of the Hydra card: is any other known to work with > NetBSD? The Hydra and the Commodore/Ameristar 2065 boards are the only ones supported at this time. Someone was working on the ASDB LanRover, but I haven't heard the status on that driver lately. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 14 19:47:08 1994 From: mycroft@gnu.ai.mit.edu To: Mark_Weaver@brown.edu Subject: Re: sup server on sun-lamp down Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just checked and it's refusing connections today as well. I turned the SUP server off for a little while this morning to do some maintenance on lamp. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 21:25:54 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installationproblem with 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 12, 11:40pm, Frank Knappe wrote: > I have a great problem with the Installation of NetBSD 1.0 at my A3000 > with a 170 MB HD at scsi.device adress 6. > I used the binaries from ftp.uni-regensburg and the Installationdoc > from the mailinglist , but my harddisk is not shown sd0 it's sd6. Which kernel where you using? [Check the date the kernel was created; it should be printed out after the copyright notice.] The kernel that was just compiled on August 13 uses the new scsi device assignment algorithm. The kernel compiled on July 28 doesn't. > sd6 at scsibus0 : ............... > zthreebus0 at mainbus0 > 2 mice configured > 10 views configured > > Thats all nothing more. I just booted the August 13 kernel and it booted just fine on my A4000. I also booted the July 28 kernel, which appeared to boot up fine except that the display was messed up since that kernel didn't have the AGA support. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 14 21:28:51 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch), Tim Newsham , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: upgrade to 1.0 [non-contiguous memory diffs] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 10, 9:32pm, Michael L. Hitch wrote: > On Aug 8, 7:16pm, Tim Newsham wrote: > > > > (btw.. can I get diffs for non-contig memory handling with the new > > kernels from someone who has already got it up and running?) > > > > Here's a set of diffs for the non-contiguous memory support I'm > working with. It's based on Tim's original changes, but I've done And I have a small goof in my changes: > --- 1669,1671 ---- > diff -cr /mnt/src/sys/arch/amiga/amiga/pmap.c /sys/arch/amiga/amiga/pmap.c > *** /mnt/src/sys/arch/amiga/amiga/pmap.c Tue Jun 21 10:20:50 1994 > --- /sys/arch/amiga/amiga/pmap.c Mon Aug 1 22:10:00 1994 > *************** > *** 496,506 **** > --- 560,631 ---- ... > + #else > + #define pmap_page_index(pa) ((pa) >= avail_start && (pa) < avail_end) > + #endif /* MACHINE_NONCONTIG */ This should have been: #define pmap_page_index(pa) (pa_index(pa)) This only affects kernel without the MACHINE_NONCONTIG option. It also seems to crash smaller memory configurations - I hadn't seen any problems using it while running with 20M, but as soon as I restricted the memory to 3.5M, it crashed when starting up mult-user. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 22:52:11 1994 From: BNISWONG@smith.smith.edu Subject: Re: Duplicate messages To: seb@cs.uq.oz.au Cc: amiga@sun-lamp.cs.berkeley.edu X-Envelope-To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"seb@cs.uq.oz.au" X-Vms-Cc: IN%"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu >On Sun, 14 Aug 1994, Alan Bair wrote: > > > > > > > > > > Does anyone else on this list keep getting massive amounts of duplicate > > > messages sent to them. I have received a number of messages about 5 to > > > 10 times in the last few days. > > > > Yep, I first thought it was just posting the same article to different > > lists, but each message seems to be duplicated within each list. It > > seemd to have started several days ago. > Well, in that case, if the maintainers of the list see this message, I > guess it would be much appreciated by everyone if it were fixed soon. > Thanks, > Steve. yep.. i too am getting dupes.. i also get the msgs in a random order, sometimes the replys come after the original msg, but usual they come before ah well bart niswonger From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 23:03:30 1994 From: msanders@eng.utah.edu Subject: panic: ffs_valloc: dup alloc To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 507 Sender: owner-amiga@sun-lamp.cs.berkeley.edu After getting past the lack of the /dev files, I'm running into yet another problem. :( As soon as I tried to use vi to edit /etc/fstab, I got the following: mode = 020640, inum = 1291, fs = / panic: ffs_valloc: dup alloc Stopped at 0x81048: unlk a6 The same thing has happened when using cp as well. I'm running on an A3000 (no ROM) w/ 8M Fast, 2M Chip, 240M HD. I have a 20M root partition, 32M swap, and 180M for user. I'm not sure what other info you might need, so feel free to ask. - Mike From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 23:40:10 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "X install" (Aug 13, 10:56am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Tim Newsham , amiga@sun-lamp.cs.berkeley.edu Subject: Re: X install Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 13, 10:56am, Tim Newsham wrote: > Subject: X install > > a few problems with the X FAQ > > /usr/lib/X11 should point to /usr/X11/lib/X11 not > /usr/X11/lib > > /usr/X11R5 and /usr/X11 must both point to the spot > you installed the X dist at. The FAQ tells you to make No, should not. Standard MIT installation does point to /usr/lib/X11, if you install X-libs in i.e. /opt/X11/lib, it must of course point there. But you are right, the FAQ needs refurbishing. Will be done, once Release 1.0 of NetBSd has been settled. I tend to use ldconfig for the libs... -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 14 23:52:35 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Ethernet cards?" (Aug 14, 2:34am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "L. Todd Masco" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet cards? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 14, 2:34am, "L. Todd Masco" wrote: > I'm about to buy an Ethernet card for my A3000... I was wondering what > would be best for NetBSD. I'd prefer ZIII, of course, but price is also an issue. ZIII ? You must be joking. ZII is way too fast for Ethernet :-) The A2065 currently is best choice. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 00:10:39 1994 Subject: Re: Installationproblem with 1.0 From: Tim Newsham To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: msanders@osiris.usi.utah.edu, Knappe@tu-harburg.d400.de, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > On Aug 13, 1:12pm, msanders@osiris.usi.utah.edu wrote: > > I also noticed, contrary to what the install doc says, that my hd > > (at id 3) is sd3X, NOT sd0X even though it IS the first scsi device. > > The release install doc is for the release kernel configuration. I > would suspect the kernel you are running was made before the scsi > disk device config changes. [I haven't kept up with the release > kernel since I'm always building my own and haven't taken the time > to try out the provided kernels.] I installed the kernel under release/* (1.0_Beta) and observed the same thing. My scsi 6 is at sd6. I just built a -current kernel today however and scsi 6 appears at sd1 as it should (I have another drive at scsi 0). > Michael L. Hitch INTERNET: osymh@montana.edu From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 00:10:47 1994 Subject: Re: panic: ffs_valloc: dup alloc From: Tim Newsham To: msanders@eng.utah.edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > After getting past the lack of the /dev files, I'm running into yet > another problem. :( As soon as I tried to use vi to edit /etc/fstab, > I got the following: > > mode = 020640, inum = 1291, fs = / > panic: ffs_valloc: dup alloc > Stopped at 0x81048: unlk a6 > > The same thing has happened when using cp as well. I'm running on an > A3000 (no ROM) w/ 8M Fast, 2M Chip, 240M HD. > > I have a 20M root partition, 32M swap, and 180M for user. > > I'm not sure what other info you might need, so feel free to ask. > > - Mike when this happened to me I just reformatted the partition and started over. Fsck might do the trick though. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 01:25:57 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu (Amiga) Subject: Re: panic: ffs_valloc: dup alloc Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 14, 2:31pm, msanders@eng.utah.edu wrote: > mode = 020640, inum = 1291, fs = / > panic: ffs_valloc: dup alloc > Stopped at 0x81048: unlk a6 ... > > I'm not sure what other info you might need, so feel free to ask. It sounds like your disk structure is not clean. Try running fsck on your partitions before mounting them writeable. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 02:21:44 1994 From: Julian H Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: cd /usr/src/lib/libc ; make depend because line length> 1024 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Bug Report: cd /usr/src/lib/libc ; make depend fails because line length > 1024 This is on a PC532 running NetBSD current ... (well as current as I can get, 'cos I cant recompile the system yet) It produces this: files=" /usr/src/lib/libc/arch/ns32k/gen/_setjmp.S /usr/src/lib/libc/arch/ns32k/gen/alloca.S /usr/src/lib/libc/arch/ns32k/gen/fabs.S /usr/src/lib/libc/arch/ns32k/gen/frexp.S /usr/src/lib/libc/arch/ns32k/gen/ldexp.S /usr/src/lib/libc/arch/ns32k/gen/modf.S /usr/src/lib/libc/arch/ns32k/gen/setjmp.S /usr/src/lib/libc/arch/ns32k/net/htonl.S /usr/src/lib/libc/arch/ns32k/net/htons.S /usr/src/lib/libc/arch/ns32k/net/ntohl.S /usr/src/lib/libc/arch/ns32k/net/ntohs.S /usr/src/lib/libc/arch/ns32k/stdlib/abs.S /usr/src/lib/libc/arch/ns32k/sys/Ovfork.S /usr/src/lib/libc/arch/ns32k/sys/brk.S /usr/src/lib/libc/arch/ns32k/sys/cerror.S /usr/src/lib/libc/arch/ns32k/sys/exect.S /usr/src/lib/libc/arch/ns32k/sys/fork.S /usr/src/lib/libc/arch/ns32k/sys/pipe.S /usr/src/lib/libc/arch/ns32k/sys/ptrace.S /usr/src/lib/libc/arch/ns32k/sys/reboot.S /usr/src/lib/libc/arch/ns32k/sys/sbrk.S /usr/src/lib/libc/arch/ns32k/sys/setlogin.S /usr/src/lib/libc/arch/ns32k/sys/sigpending.S /usr/src/lib/libc/arch/ns32k! /sys/sigprocmask.S /usr/src/lib/libc/arch/ns32k/sys/sigreturn.S /usr/src/lib/libc/arch/ns32k/sys/sigsuspend.S /usr/src/lib/libc/arch/ns32k/sys/syscall.S"; if ..... I see lots of nasty 1024s lurking in src/bin/sh/* (mirrored 94 08 12) that should probably be #defined (same 1024s lurk in FreeBSD-1.1.5 too, dunno' about 4.4 BSD & derivatives) :- memalloc.c: if (herefd >= 0 && len >= 1024) { mkinit.c: char line[1024]; mkinit.c: char line[1024]; mkinit.c: char line[1024]; mknodes.c:char line[1024]; mknodes.c: if (fgets(line, 1024, infp) == NULL) -- Julian Stacey Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 02:21:53 1994 From: Julian H Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: cpp -idirafter /usr/include hangs forever Sender: owner-current-users@sun-lamp.cs.berkeley.edu Bug Report: cd /usr/src/lib/libc ; make depend results in cpp -E -DYP -DLIBC_SCCS -DSYSLIBC_SCCS -DPOSIX_MISTAKE \ -I/usr/src/lib/libc/arch/ns32k -nostdinc -idirafter \ //usr/include /usr/src/lib/libc/arch/ns32k/gen/_setjmp.S \ | as -o _setjmp.o which hangs forever, running by hand it's the -idirafter /usr/include that causes no data to be emitted, & the pipe to hang. This is on a PC532 running NetBSD current ... (well as current as I can get, 'cos I cant recompile the system yet) -- Julian Stacey Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 02:28:53 1994 From: Julian H Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: cd /usr/src/lib/libc ; make depend because line length> 1024 Sender: owner-current-users@sun-lamp.cs.berkeley.edu cd /usr/src/lib/libc ; make depend fails because line length > 1024 This is on a PC532 running NetBSD current ... (well as current as I can get, 'cos I cant recompile the system) It produces this: files=" /usr/src/lib/libc/arch/ns32k/gen/_setjmp.S /usr/src/lib/libc/arch/ns32k/gen/alloca.S /usr/src/lib/libc/arch/ns32k/gen/fabs.S /usr/src/lib/libc/arch/ns32k/gen/frexp.S /usr/src/lib/libc/arch/ns32k/gen/ldexp.S /usr/src/lib/libc/arch/ns32k/gen/modf.S /usr/src/lib/libc/arch/ns32k/gen/setjmp.S /usr/src/lib/libc/arch/ns32k/net/htonl.S /usr/src/lib/libc/arch/ns32k/net/htons.S /usr/src/lib/libc/arch/ns32k/net/ntohl.S /usr/src/lib/libc/arch/ns32k/net/ntohs.S /usr/src/lib/libc/arch/ns32k/stdlib/abs.S /usr/src/lib/libc/arch/ns32k/sys/Ovfork.S /usr/src/lib/libc/arch/ns32k/sys/brk.S /usr/src/lib/libc/arch/ns32k/sys/cerror.S /usr/src/lib/libc/arch/ns32k/sys/exect.S /usr/src/lib/libc/arch/ns32k/sys/fork.S /usr/src/lib/libc/arch/ns32k/sys/pipe.S /usr/src/lib/libc/arch/ns32k/sys/ptrace.S /usr/src/lib/libc/arch/ns32k/sys/reboot.S /usr/src/lib/libc/arch/ns32k/sys/sbrk.S /usr/src/lib/libc/arch/ns32k/sys/setlogin.S /usr/src/lib/libc/arch/ns32k/sys/sigpending.S /usr/src/lib/libc/arch/ns32k! /sys/sigprocmask.S /usr/src/lib/libc/arch/ns32k/sys/sigreturn.S /usr/src/lib/libc/arch/ns32k/sys/sigsuspend.S /usr/src/lib/libc/arch/ns32k/sys/syscall.S"; if ..... I see lots of nasty 1024s lurking in src/bin/sh/* (mirrored 94 08 12) that should probably be #defined (same 1024s lurk in FreeBSD-1.1.5 too, dunno' about 4.4 BSD & derivatives) :- memalloc.c: if (herefd >= 0 && len >= 1024) { mkinit.c: char line[1024]; mkinit.c: char line[1024]; mkinit.c: char line[1024]; mknodes.c:char line[1024]; mknodes.c: if (fgets(line, 1024, infp) == NULL) -- Julian Stacey Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 02:55:49 1994 Subject: What SCSI controller? To: current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 778 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm about to purchase a SCSI-II controller for my PC and plan to use it under NetBSD 1.0. I'd like to get a Vesa LocalBus model so that I can reap the rewards of both higher transfer rates/disk performance, and the memory in my system above 16M. Are there any that seem to work particularly well, or particularly poorly? I'd like to know before I buy so that I don't end up having to toss 4M ram, and so that I can get the most performance out of the 2.1G drive I'm about to buy. Thanks for any advice you can offer! -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 06:26:54 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: mmead@vt.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: What SCSI controller? <199408142324.TAA11742@thumbtack.bevc.blacksburg.va.us> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm about to purchase a SCSI-II controller for my PC and plan to use it >under NetBSD 1.0. I'd like to get a Vesa LocalBus model so that I can reap >the rewards of both higher transfer rates/disk performance, and the memory in >my system above 16M. Are there any that seem to work particularly well, or >particularly poorly? I'd like to know before I buy so that I don't end up >having to toss 4M ram, and so that I can get the most performance out of the >2.1G drive I'm about to buy. Thanks for any advice you can offer! I think your only viable option is the BusLogic bt445s. If you have an EISA or PCI bus, use a model for those instead (bt747s, bt946c, or a NCR810 controller). But if you only have ISA+VLB, go for the bt445s. ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc. Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532 In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 06:29:31 1994 From: kedzie@amy.engr.wisc.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: amy.engr.wisc.edu mail loop X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sorry for the headaches I caused. I have been removed from the list. -- ____ / / / Michael A. Kedzie kedzie@engr.wisc.edu \ \ \/ / / University of Wisconsin-Madison Only \ \ \/ / College of Engineering, AV Services (608)263-3163 Amiga \_\_\/ School of Nursing, TV Studio (608)263-5331 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 06:51:50 1994 Subject: Re: What SCSI controller? To: michaelv@HeadCandy.com (Michael L. VanLoon -- Iowa State University) Cc: current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 685 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I think your only viable option is the BusLogic bt445s. If you have > an EISA or PCI bus, use a model for those instead (bt747s, bt946c, or > a NCR810 controller). But if you only have ISA+VLB, go for the > bt445s. So that's a BusLogic 445s. Is that board going to work ok? I administrate a machine which has problems with a BusLogic (I think) controller, and am hoping it will start working with 1.0 :-) Thanks again... -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 15 08:02:46 1994 Subject: From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm having problems building a kernel. I built a GENERIC with sources supped 2 days ago and it works fine. I then took GENERIC and commented out a few things that I dont think I need and the resulting kernel doesnt boot properly. The screen gets cleared and goes grey but no text is ever printed. Anyone see something critical that I commented out? System: A2000 - ECS old gvp accelerator (030/23mhz + 5 megs ram + scsi (scsi not used)) gvp series II scsi + ram (2 hard drives + 4megs/16 ram) Thanx, Tim N. ------- my config -------- # # Tim's AMIGA # include "std.amiga" maxusers 8 options TIMEZONE=300, DST=1 # # processors this kernel should support # #options "M68040" # support for 040 #options FPSP # MC68040 floating point support options "M68030" # support for 030 #options "M68020" # support for 020/851 options FPCOPROC # Support for MC6888[12] (Required) options SWAPPAGER # Pager for processes (Required) options VNODEPAGER # Pager for vnodes (Required) options DEVPAGER # Pager for devices (Required) # # Networking options # options INET # IP networking support (Required) #options ISO # ISO Networking support #options TPIP # ARGO TP networking support #options CCITT # CCITT X.25 #options NS # Xerox XNS #options EON # ISO CLNL over IP #options GATEWAY # Packet forwarding #options DIRECTED_BROADCAST # Broadcast across subnets #options NSIP # XNS over IP # # File system related options # #options QUOTA # Disk quotas for local disks options NFSSERVER # Network File System server side code options NFSCLIENT # Network File System client side code # # File systems # options FFS # Berkeley fast file system options MFS # Memory based filesystem options PROCFS # Process filesystem options KERNFS # Kernel parameter filesystem (Recommended) options FDESC # /dev/fd filesystem options NULLFS # Loopback filesystem options FIFO # FIFO operations on vnodes (Recommended) options ADOSFS # AmigaDOS file system #options "CD9660" # ISO 9660 file system, with Rock Ridge #options PORTAL # Portal filesystem #options MSDOSFS # MS-DOS filesystem # # Compatability options for various existing systems # #options "COMPAT_09" # compatability with older NetBSD release #options "COMPAT_43" # 4.3 BSD compatible system calls #options COMPAT_SUNOS # Support to run Sun (m68k) executables #options "TCP_COMPAT_42" # Use 4.2 BSD style TCP options "COMPAT_NOMID" # allow nonvalid machine id executables #options COMPAT_HPUX # HP300 compatability # # Support for System V IPC facilities. # options SYSVSHM # System V-like shared memory options SYSVMSG # System V-like messages options SYSVSEM # System V-like semaphores # # Support for various kernel options # options GENERIC # Mini-root boot support options LKM # Loadable kernel modules options KTRACE # Add kernel tracing system call options DIAGNOSTIC # Add additional error checking code options "NKMEMCLUSTERS=256" # Size of kernel malloc area # # Misc. debuging options # options PANICWAIT # Require keystroke to dump/reboot #options DEBUG # Add debugging statements options DDB # Kernel debugger #options SYSCALL_DEBUG # debug all syscalls. #options SCSIDEBUG # Add SCSI debugging statements #options KGDB # Kernel debugger (KGDB) support #options PANICBUTTON # Forced crash via keypress (???) # # Amiga specific options # #options RETINACONSOLE # enable code to allow retina to be console options GRF_ECS # Enhanced Chip Set options GRF_NTSC # NTSC options GRF_PAL # PAL #options "GRF_A2024" # Support for the A2024 #options GRF_AGA # AGA Chip Set #options "KFONT_8X11" # 8x11 font grfcc0 at mainbus0 # custom chips #grfrt0 at ztwobus0 # retina II #grfrh0 at zthreebus0 # retina III grf0 at grfcc0 #grf1 at grfrt0 #grf2 at grfrh0 ite0 at grf0 # terminal emulators for grf's #ite1 at grf1 # terminal emulators for grf's #ite2 at grf2 # terminal emulators for grf's #le0 at ztwobus0 # Lance ethernet. #ed0 at ztwobus0 # dp8390 ethernet # scsi stuff, all possible gvpbus0 at ztwobus0 gtsc0 at gvpbus0 # GVP series II scsi #ahsc0 at mainbus0 # A3000 scsi #atzsc0 at ztwobus0 #wstsc0 at ztwobus0 # Wordsync II scsi #ivsc0 at ztwobus0 # IVS scsi #mlhsc0 at ztwobus0 # Hacker scsi #otgsc0 at ztwobus0 # 12 gauge scsi #zssc0 at ztwobus0 # Zeus scsi #mgnsc0 at ztwobus0 # Magnum scsi #wesc0 at zthreebus0 # Warp Engine scsi #idesc0 at mainbus0 # A4000(A1200?) IDE scsibus0 at gtsc0 #scsibus1 at ahsc0 #scsibus2 at atzsc0 #scsibus2 at wstsc0 #scsibus3 at ivsc0 #scsibus4 at mlhsc0 #scsibus5 at otgsc0 #scsibus6 at zssc0 #scsibus7 at mgnsc0 #scsibus8 at wesc0 #scsibus9 at idesc0 # each hard drive from low target to high # will configure to the next available sd unit number sd* at scsibus? target ? lun ? # scsi disks st* at scsibus? target ? lun ? # scsi tapes cd* at scsibus? target ? lun ? # scsi cd's pseudo-device sl # slip pseudo-device ppp # ppp pseudo-device view 10 # views pseudo-device pty 16 # pseudo terminals pseudo-device loop # network loopback pseudo-device bpfilter # packet filter config netbsd swap on generic From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 10:17:11 1994 X-Authentication-Warning: artificial.hip.berkeley.edu: Host localhost.Berkeley.EDU didn't use HELO protocol To: mmead@vt.edu Cc: michaelv@HeadCandy.com (Michael L. VanLoon -- Iowa State University), current-users@sun-lamp.cs.berkeley.edu Subject: Re: What SCSI controller? <199408150300.XAA12109@thumbtack.bevc.blacksburg.va.us> From: David G Paschich Sender: owner-current-users@sun-lamp.cs.berkeley.edu > So that's a BusLogic 445s. Is that board going to work ok? I > administrate a machine which has problems with a BusLogic (I think) > controller, and am hoping it will start working with 1.0 :-) Thanks again... I have one. Works great. David Paschich From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 10:26:49 1994 From: mycroft@gnu.ai.mit.edu To: Julian.H.Stacey@regent.e-technik.tu-muenchen.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: cd /usr/src/lib/libc ; make depend because line length> 1024 Sender: owner-current-users@sun-lamp.cs.berkeley.edu This works fine on other ports. Furthermore, the first `1024' you pointed out is not a bug, and the other five, while they could in some random circumstance lose, are only used while building sh(1). This looks like a problem specific to the pc532. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 10:29:14 1994 X-Authentication-Warning: MindBender.HeadCandy.com: Host localhost didn't use HELO protocol To: mmead@vt.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: What SCSI controller? <199408150300.XAA12109@thumbtack.bevc.blacksburg.va.us> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> I think your only viable option is the BusLogic bt445s. If you have >> an EISA or PCI bus, use a model for those instead (bt747s, bt946c, or >> a NCR810 controller). But if you only have ISA+VLB, go for the >> bt445s. > So that's a BusLogic 445s. Is that board going to work ok? I >administrate a machine which has problems with a BusLogic (I think) >controller, and am hoping it will start working with 1.0 :-) Thanks again... There are tons of people using them, sucessfully. I don't know why it wouldn't work. Of course, they might act flakey under 0.9. Also, VLB is a *very* loose "standard", and it may be your motherboard, also. (Try moving it to a different slot, for one possible solution.) ----------------------------------------------------------------------------- Michael L. VanLoon michaelv@HeadCandy.com Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc. Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532 In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m ----------------------------------------------------------------------------- From owner-tech-kern@sun-lamp.cs.berkeley.edu Mon Aug 15 11:08:39 1994 From: "Charles M. Hannum" To: port-i386@sun-lamp.cs.berkeley.edu Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: wd driver vs. ancient hardware Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu Well, it turns out that while the ESDI spec I have talks about the `alternate status register', the ST506 spec I have does not. As far as I know, nobody who has reported problems with the wd driver recently is using a MFM or RLL controller, but I've attempted to fix it anyway. To anyone using the wd driver currently, or who has had trouble with it before: PLEASE TRY THE UPDATED VERSION (1.84.2.3) ASAP AND LET ME KNOW WHETHER OR NOT IT WORKS. It works here, but as we all know, that doesn't mean a damned thing in the PC world. Also, if you see any messages of the form `wdcN: warning: busy-wait ...', you should let me know. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 12:07:38 1994 From: "Charles M. Hannum" To: port-i386@sun-lamp.cs.berkeley.edu Cc: current-users@sun-lamp.cs.berkeley.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: wd driver vs. ancient hardware Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, it turns out that while the ESDI spec I have talks about the `alternate status register', the ST506 spec I have does not. As far as I know, nobody who has reported problems with the wd driver recently is using a MFM or RLL controller, but I've attempted to fix it anyway. To anyone using the wd driver currently, or who has had trouble with it before: PLEASE TRY THE UPDATED VERSION (1.84.2.3) ASAP AND LET ME KNOW WHETHER OR NOT IT WORKS. It works here, but as we all know, that doesn't mean a damned thing in the PC world. Also, if you see any messages of the form `wdcN: warning: busy-wait ...', you should let me know. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 12:33:54 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: A minor question on upgrading to -current from a novice... To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm sorry if this is an FAQ, but this is the first time that I am upgrading to -current via the source code, and I want my best to make it right the first time. So far, I have followed Ken Horstein's general guideline to upgrading to -current via the sources. I first copied my /usr/include files to a temporary directory, and then cleaned out the whole /usr/include tree. I then did a make install in /usr/src/include. Then I recompiled myself a new kernel (I did not use the new config, was I supposed too?? My kernel seems to run just fine), and rebooted. Now, I am currently compiling /usr/src/lib and /usr/src/libexec at the same time. I guess my question is, do I have to clean out my whole /usr/lib and /usr/libexec trees as well before mv'ing the newly compiled ones? Or can I just leave my old ones there and overwrite them with the new ones? The only problem is, don't my present /usr/bin binaries depend on those libraries in /usr/lib? how can I execute a mv if there is nothing in /usr/lib? Sorry for my ignorance, but could someone answer my question before I unnecessarily hose my system??? (I'd HATE to have to reinstall the whole binary distribution, then have to download the source again, etc., etc.) Thanks for the help!!! ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 15 12:39:23 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Automatic interactive Installation _ I am working on one but I need help. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi all Amiga Netizens, At least for once, I might be able to contribute to the Amiga NetBSD community but I still need a bit of help .... Since a few days, I am working on creating a set of floppies and scripts that would allow automatic installation (well, you still have to answer a few questions ;-) ). The general principle is: - Boot from floppy on which I replaced 'init' by a bourne shell script - New init will walk thru every (0-15) disk to find a valid swap partition. - You will be asked (for each 'b' partitions found) if it can be used to load a miniroot. At the first positive answer, the loop will exit an we go further. - newfs the accepted 'b' partition and mount it - Copy the boot floppy to there - Read the rest of the miniroot off floppy tar (multiple volumes, probably two in the final version) This contains all possible devices + a bunch of usefull commands such as various mount commands, dump, restore, rmt, fsck, etc ... and another /sbin/init to perform the second stage of installation. - Then see all the questions below ! - Then run the new '/sbin/init' which came from the miniroot tar to perform the rest of the interactive installation. This as result of a reboot or by another way (see all the questions below !). - rebbot the newly (or update) NetBSD !!! well here is my problem: I wanted then, to make the 'b' partition look as '/'. I have tried different solutions which all failed remount /dev/sdxb on / chokes with 'does not match mounted device' mount_null /xxx/bin /bin, etc ... does not work The basic problem I encounter in all these case is the following: at boot, /dev/fd0a is on / then I mount /dev/sdxb on /mfs to untar miniroot, I have to take the diskette away and then tar from /dev/rfd0a (fd0a is busy). Then, I tell the user to make sure to put the boot diskette back in the drive and try 'mount -u -r /dev/fd0a /' in an attempt to resync with the floppy (all commands after the tar are taken from /mfs/... to avoid using the floppy) This always (and other trial I did) end up in a "I/O error" and most of the time trips to the kernel debugger. The questions I have are: 1. Would there be any way of reusing fd0a after having removed the floppy, used /dev/rfd0a for somethging else and then reinserted the floppy ? 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); mount_null seemed a good idea ? I would really like to avoid booting a second time if possible ! 3. If the above is not possible, I could just ask the user to use 'sdxb' as the the boot device and halt the system but that is not accepted by the kernel (only 'sdx' allowed). For this, I want to try the following trick in amiga/swapgeneric.c: ----------- in setconf(): ( '|' on left for changes) ------------- setconf() { struct dkdevice *dkp; struct partition *pp; struct genericconf *gc; struct bdevsw *bdp; | int unit, swaponroot, rootonswap; char name[128]; char *cp; swaponroot = 0; | rootonswap = 0; if (rootdev != NODEV) goto justdoswap; unit = 0; if (boothowto & RB_ASKNAME) { gc = getgenconf(name); cp = name + 2; while (*cp >= '0' && *cp <= '9') unit = 10 * unit + *cp++ - '0'; if (*cp == '*') swaponroot = 1; | else if ( *cp >= 'a' && *cp <= 'p' ) | rootonswap = *cp - 'a'; unit &= 0x7; goto found; } And a bit further: found: gc->gc_root = MAKEDISKDEV(major(gc->gc_root), unit, rootonswap); rootdev = gc->gc_root; ----------- This would allow trying to boot from ANY partition possible and permit to boot the miniroot I just created. Kernel gurus out there ? Would that work? And if yes, should it integrated in the kernel as such ? Oh, another note: I am going on vacation on the 21st of august for three weeks and the work load is such before leaving that I think I can have something ready before end of september. I hope you do not mind waiting ??? Any help very much appreciated, please send Email directtly to me, I cant read the list due to work load, especially with ALL the duplicates ! Cu, Francis ----------------------------------------------------------------------- Francis Demierre SMTP : francis@hasler.ascom.ch Ascom Hasler AG, UUCP: ...!mcsun!chsun!hslrswi!francis Abt. NVEI2, X.400: S=francis/O=ascom/P=eunet/A=arcom/C=ch Belpstrasse 37,, Tel. : +41 31 999 3503 CH-3000 Bern 14 Fax : +41 31 999 3735 ----------------------------------------------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 13:31:21 1994 From: Charles Ewen MacMillan Subject: Re: panic: ffs_valloc: dup alloc To: msanders@eng.utah.edu Cc: Amiga Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Sun, 14 Aug 1994 msanders@eng.utah.edu wrote: > Date: Sun, 14 Aug 1994 14:31:57 -0600 (MDT) > From:msanders@eng.utah.edu > To: Amiga > Subject: panic: ffs_valloc: dup alloc > > After getting past the lack of the /dev files, I'm running into yet > another problem. :( As soon as I tried to use vi to edit /etc/fstab, > I got the following: > > mode = 020640, inum = 1291, fs = / > panic: ffs_valloc: dup alloc > Stopped at 0x81048: unlk a6 I had the same panic as well. I did a manual fsck and the problem went away. The filing system and vi both seem perversely more stable under multi-user mode. Charles Ewen MacMillan | Tezcat.COM - Wicker Park | Offering Internet Access Modem: 312-850-0112/0117| Via Interactive UNIX to Voice: 312-850-0181 | the Chicago Area. WWW: http://tezcat.com/ | Mail: info@tezcat.com From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 13:40:54 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Automatic interactive Installation _ I am working on one but I need help. Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all Amiga Netizens, At least for once, I might be able to contribute to the Amiga NetBSD community but I still need a bit of help .... Since a few days, I am working on creating a set of floppies and scripts that would allow automatic installation (well, you still have to answer a few questions ;-) ). The general principle is: - Boot from floppy on which I replaced 'init' by a bourne shell script - New init will walk thru every (0-15) disk to find a valid swap partition. - You will be asked (for each 'b' partitions found) if it can be used to load a miniroot. At the first positive answer, the loop will exit an we go further. - newfs the accepted 'b' partition and mount it - Copy the boot floppy to there - Read the rest of the miniroot off floppy tar (multiple volumes, probably two in the final version) This contains all possible devices + a bunch of usefull commands such as various mount commands, dump, restore, rmt, fsck, etc ... and another /sbin/init to perform the second stage of installation. - Then see all the questions below ! - Then run the new '/sbin/init' which came from the miniroot tar to perform the rest of the interactive installation. This as result of a reboot or by another way (see all the questions below !). - rebbot the newly (or update) NetBSD !!! well here is my problem: I wanted then, to make the 'b' partition look as '/'. I have tried different solutions which all failed remount /dev/sdxb on / chokes with 'does not match mounted device' mount_null /xxx/bin /bin, etc ... does not work The basic problem I encounter in all these case is the following: at boot, /dev/fd0a is on / then I mount /dev/sdxb on /mfs to untar miniroot, I have to take the diskette away and then tar from /dev/rfd0a (fd0a is busy). Then, I tell the user to make sure to put the boot diskette back in the drive and try 'mount -u -r /dev/fd0a /' in an attempt to resync with the floppy (all commands after the tar are taken from /mfs/... to avoid using the floppy) This always (and other trial I did) end up in a "I/O error" and most of the time trips to the kernel debugger. The questions I have are: 1. Would there be any way of reusing fd0a after having removed the floppy, used /dev/rfd0a for somethging else and then reinserted the floppy ? 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); mount_null seemed a good idea ? I would really like to avoid booting a second time if possible ! 3. If the above is not possible, I could just ask the user to use 'sdxb' as the the boot device and halt the system but that is not accepted by the kernel (only 'sdx' allowed). For this, I want to try the following trick in amiga/swapgeneric.c: ----------- in setconf(): ( '|' on left for changes) ------------- setconf() { struct dkdevice *dkp; struct partition *pp; struct genericconf *gc; struct bdevsw *bdp; | int unit, swaponroot, rootonswap; char name[128]; char *cp; swaponroot = 0; | rootonswap = 0; if (rootdev != NODEV) goto justdoswap; unit = 0; if (boothowto & RB_ASKNAME) { gc = getgenconf(name); cp = name + 2; while (*cp >= '0' && *cp <= '9') unit = 10 * unit + *cp++ - '0'; if (*cp == '*') swaponroot = 1; | else if ( *cp >= 'a' && *cp <= 'p' ) | rootonswap = *cp - 'a'; unit &= 0x7; goto found; } And a bit further: found: gc->gc_root = MAKEDISKDEV(major(gc->gc_root), unit, rootonswap); rootdev = gc->gc_root; ----------- This would allow trying to boot from ANY partition possible and permit to boot the miniroot I just created. Kernel gurus out there ? Would that work? And if yes, should it integrated in the kernel as such ? Oh, another note: I am going on vacation on the 21st of august for three weeks and the work load is such before leaving that I think I can have something ready before end of september. I hope you do not mind waiting ??? Any help very much appreciated, please send Email directtly to me, I cant read the list due to work load, especially with ALL the duplicates ! Cu, Francis ----------------------------------------------------------------------- Francis Demierre SMTP : francis@hasler.ascom.ch Ascom Hasler AG, UUCP: ...!mcsun!chsun!hslrswi!francis Abt. NVEI2, X.400: S=francis/O=ascom/P=eunet/A=arcom/C=ch Belpstrasse 37,, Tel. : +41 31 999 3503 CH-3000 Bern 14 Fax : +41 31 999 3735 ----------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 16:01:13 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/lib/libcurses/tty.c U src/sys/arch/hp300/stand/Makefile U src/sys/arch/i386/conf/DISKLESS U src/sys/arch/i386/i386/autoconf.c U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/isa/ast.c U src/sys/arch/i386/isa/wd.c Segmentation fault - core dumped Killing core files: ./src/sys/arch/sparc/include/cvs.core Running the SUP scanner: SUP Scan for current starting at Mon Aug 15 04:04:26 1994 SUP Scan for current completed at Mon Aug 15 04:07:13 1994 SUP Scan for mirror starting at Mon Aug 15 04:07:13 1994 SUP Scan for mirror completed at Mon Aug 15 04:12:30 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 16:04:10 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: cvs [checkout aborted]: cannot open etc.sun3/CVS/Tag: Permission denied From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 15 16:56:30 1994 From: jshardlo@london.micrognosis.com (John Shardlow) To: amiga-x@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Missing columns on NetBSD console - solution - comp.unix.amiga #7599 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <32nt9u$ihd@zeus.london.micrognosis.com>, jshardlo@london.micrognosis.com (John Shardlow) writes: |> I have finally discovered the cause of the missing columns on my |> A3000 console (under NetBSD 0.9/1.0_beta). |> |> Michael Hitch provided me with a test program which I hacked around |> with and I now know why I get those missing columns. |> |> If you write to the display memory one byte at a time then the second |> byte in each longword does not get successfully written and you end |> up with a missing column. If you write to the display memory using |> short or long words then everything is written OK. |> |> Examples: |> |> XbsdCC2 and XbsdCC4 X-servers must use byte writes as they suffer |> from the problem. |> |> XamigaMono and Xamiga+retina must use short or long writes as they |> do not suffer from it. |> |> The kernel itself must use byte writes to the ite console as this |> does suffer from missing columns. |> |> I'm not sure if this helps me but at least I'm getting somewhere now. |> |> BTW, does anyone know how to switch between different views under NetBSD ? |> |> When I was testing with the views example program I got into the situation |> where I had console (view00) X-servers (view01) and test program (view02) |> but when I quit from the test program I had console on top which would |> not respond to keyboard so I guess the X-server still has the keyboard |> input but it was behind the console ! :( |> |> John |> -- |> +----------------------------------+ |> | John Shardlow | |> | jshardlow@london.micrognosis.com | |> | john@iceberg.demon.co.uk | |> +----------------------------------+ |> -----BEGIN PGP PUBLIC KEY BLOCK----- |> Version: 2.3a |> |> mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY |> +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 |> do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR |> tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz |> LmNvbT4= |> =1R1I |> -----END PGP PUBLIC KEY BLOCK----- -- +----------------------------------+ | John Shardlow | | jshardlow@london.micrognosis.com | | john@iceberg.demon.co.uk | +----------------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz LmNvbT4= =1R1I -----END PGP PUBLIC KEY BLOCK----- From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 16:59:11 1994 From: jshardlo@london.micrognosis.com (John Shardlow) To: amiga-x@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Missing columns on NetBSD console - solution - comp.unix.amiga #7599 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <32nt9u$ihd@zeus.london.micrognosis.com>, jshardlo@london.micrognosis.com (John Shardlow) writes: |> I have finally discovered the cause of the missing columns on my |> A3000 console (under NetBSD 0.9/1.0_beta). |> |> Michael Hitch provided me with a test program which I hacked around |> with and I now know why I get those missing columns. |> |> If you write to the display memory one byte at a time then the second |> byte in each longword does not get successfully written and you end |> up with a missing column. If you write to the display memory using |> short or long words then everything is written OK. |> |> Examples: |> |> XbsdCC2 and XbsdCC4 X-servers must use byte writes as they suffer |> from the problem. |> |> XamigaMono and Xamiga+retina must use short or long writes as they |> do not suffer from it. |> |> The kernel itself must use byte writes to the ite console as this |> does suffer from missing columns. |> |> I'm not sure if this helps me but at least I'm getting somewhere now. |> |> BTW, does anyone know how to switch between different views under NetBSD ? |> |> When I was testing with the views example program I got into the situation |> where I had console (view00) X-servers (view01) and test program (view02) |> but when I quit from the test program I had console on top which would |> not respond to keyboard so I guess the X-server still has the keyboard |> input but it was behind the console ! :( |> |> John |> -- |> +----------------------------------+ |> | John Shardlow | |> | jshardlow@london.micrognosis.com | |> | john@iceberg.demon.co.uk | |> +----------------------------------+ |> -----BEGIN PGP PUBLIC KEY BLOCK----- |> Version: 2.3a |> |> mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY |> +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 |> do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR |> tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz |> LmNvbT4= |> =1R1I |> -----END PGP PUBLIC KEY BLOCK----- -- +----------------------------------+ | John Shardlow | | jshardlow@london.micrognosis.com | | john@iceberg.demon.co.uk | +----------------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz LmNvbT4= =1R1I -----END PGP PUBLIC KEY BLOCK----- From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 17:04:45 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Aug 15 06:20:03 1994 SUP Scan for current completed at Mon Aug 15 06:22:52 1994 SUP Scan for mirror starting at Mon Aug 15 06:22:52 1994 SUP Scan for mirror completed at Mon Aug 15 06:25:35 1994 From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Aug 15 17:06:14 1994 From: jshardlo@london.micrognosis.com (John Shardlow) To: amiga-x@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Missing columns on NetBSD console - solution - comp.unix.amiga #7599 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In article <32nt9u$ihd@zeus.london.micrognosis.com>, jshardlo@london.micrognosis.com (John Shardlow) writes: |> I have finally discovered the cause of the missing columns on my |> A3000 console (under NetBSD 0.9/1.0_beta). |> |> Michael Hitch provided me with a test program which I hacked around |> with and I now know why I get those missing columns. |> |> If you write to the display memory one byte at a time then the second |> byte in each longword does not get successfully written and you end |> up with a missing column. If you write to the display memory using |> short or long words then everything is written OK. |> |> Examples: |> |> XbsdCC2 and XbsdCC4 X-servers must use byte writes as they suffer |> from the problem. |> |> XamigaMono and Xamiga+retina must use short or long writes as they |> do not suffer from it. |> |> The kernel itself must use byte writes to the ite console as this |> does suffer from missing columns. |> |> I'm not sure if this helps me but at least I'm getting somewhere now. |> |> BTW, does anyone know how to switch between different views under NetBSD ? |> |> When I was testing with the views example program I got into the situation |> where I had console (view00) X-servers (view01) and test program (view02) |> but when I quit from the test program I had console on top which would |> not respond to keyboard so I guess the X-server still has the keyboard |> input but it was behind the console ! :( |> |> John |> -- |> +----------------------------------+ |> | John Shardlow | |> | jshardlow@london.micrognosis.com | |> | john@iceberg.demon.co.uk | |> +----------------------------------+ |> -----BEGIN PGP PUBLIC KEY BLOCK----- |> Version: 2.3a |> |> mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY |> +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 |> do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR |> tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz |> LmNvbT4= |> =1R1I |> -----END PGP PUBLIC KEY BLOCK----- -- +----------------------------------+ | John Shardlow | | jshardlow@london.micrognosis.com | | john@iceberg.demon.co.uk | +----------------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.3a mQCNAi3vWtsAAAEEAKJ0em25+3pxU8h700vmlqMlKJMc8nsy3hBZq87bONHLCDzY +O+tBmSI9bj+sUFS/Y/hmHer1QTlISg6w/ao8E+aHqXEn5c1JmPM0CvlKr0NjxD2 do+z6jQcNBey08njDEYG950IyZkE8m8wd9UumIx10fObDRvaDOOVRBJD8x49AAUR tDNKb2huIEouIFNoYXJkbG93IDxqc2hhcmRsb3dAbG9uZG9uLm1pY3JvZ25vc2lz LmNvbT4= =1R1I -----END PGP PUBLIC KEY BLOCK----- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 15 18:14:25 1994 From: Russel Miranda Subject: Re: slow kernel To: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Sat, 13 Aug 1994 chopps@emunix.emich.edu wrote: > Adding 8M of 16 bit ram will slow your system down considerably I would > think. > > Chris. > > (who will have a way to not configure 16bit z2 mem when he adds non contig > memory support for just> Would it be practical and/or desirable for 8M of 16-bit RAM to be used as a swap RAM disk? It might be slow compared to 32-bit RAM, but I would think it would be better than swapping to disk, if there was enough room. I ask because I too have 8Mb of 16-bit RAM, and I'd rather it enhanced my NetBSD system instead of encumbering it. Russ From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 15 20:04:01 1994 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.158:15.07.94.15.16.14] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Missing co... From: "hamish (h.i.) macdonald" To: jshardlo@london.micrognosis.com Cc: amiga@sun-lamp.cs.berkeley.edu Subject: re:Missing columns on NetBSD console - solution - comp.unix.amiga #7599 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> On Mon Aug 15 10:32:00 1994, >>>>> John Shardlow wrote: jshardlo> If you write to the display memory one byte at a time then jshardlo> the second byte in each longword does not get successfully jshardlo> written and you end up with a missing column. If you write jshardlo> to the display memory using short or long words then jshardlo> everything is written OK. jshardlo> The kernel itself must use byte writes to the ite console as jshardlo> this does suffer from missing columns. This implies to me that something is screwy with your hardware, because I and others have been writing bytes to display memory for eons, with no problems. As for AmigaDOS having no problems; hard to say. It probably uses the blitter for a lot of stuff (16 bit reads/writes), and when it doesn't, it probably writes 16 bit words, since that *is* faster. Regards, Hamish. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 20:47:12 1994 X-Authentication-Warning: westar.symtec.com: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Console screen explodes on top line when dd'ing with vi on cg6 From: "Sam C. Nicholson !!" Sender: owner-current-users@sun-lamp.cs.berkeley.edu (I think that this is the proper list. Let me know if I am wrong.) I am using the 4 Aug snapshot of NetBSD/SPARC. When deleting a line at the top of the screen on a cg6 console, the screen is garbaged as if a pointer went off into never-never land. A redraw ^L clears the problem. There is no real damage; just the brief anxiety attack. I have Sun's ROM rev 2.9 ( Behaves like an IPX/Sun2). -sam From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon Aug 15 20:53:37 1994 From: matthew@scruz.net (Matthew Kaufman) To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: recurring filesystem problem with NetBSD 0.9 Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I'm using a NetBSD 0.9 system (with a small handful of patches) as a news server. It had been hanging about every day or so because it was running out of swap space. When I added another large drive, I gave it a lot more swap space to play with, in order to have a system that would stay up longer. But now I'm experiencing a new problem with filesystem corruption. Specifically, I find that after a day or two, a small number of directories in the news filesystem get converted into plain files, and (less often) a small number of plain files get converted into directories. The only solution is to take down the system, run a find to locate things that are suspicious (like files that start with [a-z] and aren't directories) use clri to eradicate them and fsck the drive back into shape. The first time it happened, I wasn't so concerned, but now it has happened 4 seperate times, so the system that I thought I was going to be able to leave up for longer, can't be. For all I know, this problem has been going for some time, and the nightly hang followed by rebooting in the morning gets the drives fsck'd often enough to hide it, or alternatively, its a problem with having the additional SCSI drive or additional swap space or something. The system is a TI 486DLC processor, 16 MB of RAM, Ultrastor 14F controller, Quantum 270M SCSI, Seagate 1.9G SCSI, Seagate 2.1G SCSI. Is there perhaps a known filesystem bug that I can get a patch for, or something common I might have inadvertantly done? -matthew kaufman matthew@scruz.net From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon Aug 15 21:06:22 1994 To: matthew@scruz.net (Matthew Kaufman) Cc: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: recurring filesystem problem with NetBSD 0.9 <199408151717.KAA03255@scruz.net> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > Specifically, I find that after a day or two, a small number > of directories in the news filesystem get converted into plain > files, and (less often) a small number of plain files get > converted into directories. The only solution is to take down > the system, run a find to locate things that are suspicious > (like files that start with [a-z] and aren't directories) > use clri to eradicate them and fsck the drive back into shape. > [ ... ] > The system is a TI 486DLC processor, 16 MB of RAM, Ultrastor 14F > controller, Quantum 270M SCSI, Seagate 1.9G SCSI, Seagate 2.1G SCSI. This sounds like the exact same syptom i was having when i first bought a 486DLC box. The cause was that the f*cking chip's cache wasn't being invalidated correctly. are its caches turned on? does the problem persist when all (i.e. internal, and possibly external) caches are turned off? chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 21:10:40 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/lib/libkvm/kvm_i386.c U src/sys/arch/i386/i386/db_interface.c U src/sys/arch/i386/i386/pmap.c U src/sys/arch/i386/i386/process_machdep.c U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/i386/include/param.h U src/sys/arch/i386/include/pmap.h U src/sys/arch/i386/include/pte.h U src/sys/arch/i386/isa/wd.c U src/sys/arch/m68k/m68k/process_machdep.c U src/sys/arch/pc532/pc532/process_machdep.c U src/sys/arch/pmax/pmax/process_machdep.c U src/sys/arch/sparc/sparc/process_machdep.c U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/kern/sys_process.c U src/sys/sys/ptrace.h Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Aug 15 10:35:05 1994 SUP Scan for current completed at Mon Aug 15 10:38:26 1994 SUP Scan for mirror starting at Mon Aug 15 10:38:26 1994 SUP Scan for mirror completed at Mon Aug 15 10:41:03 1994 From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon Aug 15 21:33:14 1994 From: matthew@scruz.net (Matthew Kaufman) To: cgd@alpha.bostic.com, matthew@scruz.net Subject: Re: recurring filesystem problem with NetBSD 0.9 Cc: admin@scruz.net, netbsd-users@sun-lamp.cs.berkeley.edu Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu >From cgd@alpha.bostic.com Mon Aug 15 10:35:33 1994: > This sounds like the exact same syptom i was having when i first > bought a 486DLC box. The cause was that the f*cking chip's cache > wasn't being invalidated correctly. > are its caches turned on? does the problem persist when all > (i.e. internal, and possibly external) caches are turned off? interesting... we've got at least 4 systems, all TI 486DLC chips with their internal cache on and the motherboard cache (64K or 128K) turned on, and not a single one of them was having any sort of problem like this until this machine got yet another disk drive... perhaps its just that its so much more busy now that it isn't out of swap space all the time. we'll try turning the caches off and see if that works... and "upgrade" to Intel chips if that's what it takes (sigh) -matthew From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 21:43:28 1994 X-Authentication-Warning: cis-ts3-slip5.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: buhrow@cats.ucsc.edu (Brian Buhrow) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: TROUBLE WITH SERIAL PORTS ON 1.0_BETA <199408060047.RAA08046@baloo.ucsc.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu buhrow@cats.ucsc.edu (Brian Buhrow) writes: > I'm attempting to get current from early February and, as some of you m > ay > have seen, I have been having trouble getting the serial ports working. > My problem is that I have this script that automatically gets the machine's > slip internet connection going and, as conditions warrant, keep it going. > As the machine boots up under 1.0, this script gets called as it should, > but it can never pick up the phone. Per suggestions from this list, I > tried setting clocal on the serial port and then tried calling this script. > Still no go. > Under the system I'm running now, which is not current 1.0, but 0.9a, this > script works flawlessly. If anyone can suggest a method of modifying this > script so that it will work under 1.0, I'd be much appreciative. I have > been scratching my head over this one for a while, and it still baffles me. I have a C program that I've been using for quite some time now which maintains a SLIP connection, detecting hangups and redialing when necessary. It can also be run from rc.local, which I do. It works perfectly with NetBSD-current. I wrote it because I'm often away from my machine, but need to access my machine reliably. This allows my machine to slip right back in automatically even in the event of a crash, power failure, or disconnection. It is quite robust and never gets "stuck". Unfortunately, it is not general-- it is specifically coded to call the system here at brown, which dynamically assigns IP addresses. However, the code is fairly well organized, and should be easy to modify for whatever system you use. It also keeps a log of everything that happens, and can be configured to log various amounts of information; even the entire session, which is useful for debugging. In any case, anyone who wants the source can have it. Someone else might even have the patience to carve it into a more general tool. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 21:53:08 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: wuftpd From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu I seem to remember someone posting patches to wuftpd a while back...Can someone ship them to me? I have it compiling without warnings, errors, etc., but I'm getting this wierd seg fault in `retrieve' that is caused by yyparse incorrectly setting a pointer to `almost null'...A very low address, but not quite 0x0, which it should be. This is on an hp380 running -current of about 1 weeks vintage. Oh yes, this is remarkably similar to the X-server bug that Carrel is having...as the problems involves a union here, too... thanx, folks... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-tech-kern@sun-lamp.cs.berkeley.edu Mon Aug 15 22:19:53 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: tech-kern@sun-lamp.cs.berkeley.edu Subject: Virtual address of UPAGES Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu Is there any reason to map the UPAGES for each process at the same virtual address? (Change mappings in cpu_switch) I see that Adam did this in for Sun3 and I'm not sure why. As far as I can tell, no other ports do this. (right?) Gordon From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Aug 15 22:41:34 1994 Subject: From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Tim" == Tim Newsham writes: Tim> I found out what my PPP problems where. It appears the serial Tim> line cant keep up with large packets at 14.4 on my computer. I Tim> noticed this while downloading files with rz. I would get errors Tim> very periodically. I lowered the speed to 9.6 and everything Tim> worked ok. In ppp I tried ping -s pearl where pearl is my Tim> gateway. The biggest packet that I could get through is 890 Tim> bytes (counting the IP/ICMP header). After 890 bytes all packets Tim> are dropped. When I set the MRU to 890 everything works fine but Tim> slow. I am using hardware flow-control btw... You think you're using hw flowcontrol, I'd say. The only thing that works are outgoing flocontrol i.e. CTS, RTS is *never* dealt with. We discover it due to slow processors and the ridiculously cheap designed UART Amiga is equipped with. Other archs have the problem as well but 16550's *do* make a difference. Tim> Someone else mentioned problems with the serial line but I dont Tim> remember the exact details. Is anyong currently going through Tim> the serial code? I'll mail some patches to the list later this evening. Niklas From owner-tech-kern@sun-lamp.cs.berkeley.edu Mon Aug 15 22:48:00 1994 To: gwr@mc.com (Gordon W. Ross) Cc: tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: Virtual address of UPAGES <9408151928.AA06985@walnut> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu > Is there any reason to map the UPAGES for each process at the > same virtual address? (Change mappings in cpu_switch) Well, it makes fork() a lot easier if the kernel stack is in the same place in each process. If not, you have to re-thread the frames, etc. > I see that Adam did this in for Sun3 and I'm not sure why. > As far as I can tell, no other ports do this. (right?) actually, i think _all_ of the ports do it... chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 15 23:22:58 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: wuftpd From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu I seem to remember someone posting patches to wuftpd a while back...Can someone ship them to me? I have it compiling without warnings, errors, etc., but I'm getting this wierd seg fault in `retrieve' that is caused by yyparse incorrectly setting a pointer to `almost null'...A very low address, but not quite 0x0, which it should be. This is on an hp380 running -current of about 1 weeks vintage. Oh yes, this is remarkably similar to the X-server bug that Carrel is having...as the problems involves a union here, too... thanx, folks... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 00:14:08 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Crashes under Aug 14th system Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, just in case anyone thought it was X that was letting me down, my system just crashed three times in a row while trying to compile the C library. The first time was while running X, the second was while running window(1), and the last time was run directly from pccons. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 00:17:21 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Another crash with Aug 14th system Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, my system crashed again, in exactly the same way as before. This time, I was compiling the C library instead of the kernel, and running an Aug 14 kernel/userland, and my CONFIG was slightly different. A bug was almost definitely introduced somewhere, probably between Aug 2 and Aug 9. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 00:17:23 1994 From: Drew Hess Subject: Re: Crashes under Aug 14th system To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 587 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mark_Weaver@brown.edu writes: > > Well, just in case anyone thought it was X that was letting me > down, my system just crashed three times in a row while trying to > compile the C library. The first time was while running X, the > second was while running window(1), and the last time was run > directly from pccons. > I just finished compiling the entire August 14 source tree and had no problems at all. I'm supping Aug 15 right now. Anyway, it sounds like something specific to your configuration and not in the libc source or gcc or gas itself. -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 00:27:04 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: My slip connection maintaining program Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, there were a lot of requests for this, so I figured I'd just post it to the list. Again, this code is currently specifically written to slip to the brown system, although you won't be able to because it requires a password that I took out of the source. Hopefully it will be fairly easy to modify, and maybe someone can even generalize it and post a better version. I'm not motivated to do so. Enjoy, Mark begin 644 brownslip-0.1.tar.gz M'XL(`````````^1;;7?;-K+N5_M7(&KK2(DL2[*=%SO.'D6B8YZ5)5])3IKM MYGAIDK)84Z0.7^QHV_[W^\P`)$&]I-E[VOUR?9)8`@:#P8QR%I'+UY^ M)X[_&G'*/VF<6)$0W\UGCW]`YT;Q?T.@_^[/;&_2?.T6HV7QP=;;/_ MX+8KGHENN%A&WMTL$56[)EJO M7Q^)2RNZ%Q]=Z\&-B*+C^X(I8A&Y4,6#ZS303ETCU_'B)/)NT\0+`V$%CH"R MA!>(.$PCV^666R^PHJ68AM$\KHM'+YF),.+?89H0EWGH>%//MHA'75B1*Q9N M-/>2Q'7$(@H?/`/1H)BXT+BYFYS0YU9C1;18 MA--,)CMT0`GC8SF)!5F)JW4;/E"74@8QP4\0)I[MUD'AQ<('/V)33,O+*\N$ M26W?\N9N1#H2[75!,*&FD4P0K--)(=Q?(XN0JU2*9X,18WT9O+C#!ON&Y=.Y?XGJ@10DR(C]1=@D7:?NJX M!6/AN`^N'RZPBMNE[M8L_E$#PUT16',E$C2?PBE)"TM2M[AU25ZH-11NX(01 MR1[1=/,P<;-IXTRK6#BVAIBBN[R^S-=%O'!M\G0,]6@+1.3C@?3V.(:VU+:: M7)AC,1Z>3SYV1H;`YZO1\(/9,WKBW2=T&J)S/;D8CL2__M49H_OI4]$9]/#W MDS!^NAH9X[$8CHB/>7G5-S$*;$:=P<0TQG5A#KK]ZYXY>%\7[ZXG8C"7QJA[@9;..[-O3C[QK.?F9$`SGD.>CKCJC"9F][K? M&8FKZ]'5<`Q9L82>.>[V.^:ET6/-FP/,*XP/QF`BQA>=?E]?U#L#`G7>]0W) M$HOJF2.C.R'1U2?)HPN-0)9^78ROC*Y)'XR?#,C>&7VJ0P.B.QR,C?^Y!A$Z M1:]SV7EOC$6UK`'BM:H$J+M[/3(N23XL>WS];CPQ)]<30[P?#GND73$V1A_, MKC$^%?TAZ?M<7(\-%JS7F71X>G"!FZPF:UDV$@&SZN M.6:=+2C,<]'I?3!)?D4/LX]-Y2*LONZ%TGX6-WXPG1.A91SU!T#V,4>?@^:K M@]:1:+TX:39/CEX*!&=A?%F('[*A_?!N=>P/,A8]>+2'F)/.JN!%S(C4"*Q; MWQ4S*W)X?\Z`@?',N@?4Z-VNA3T-B)TO`%[:]M1F.LIFPA_P;[9/6J].CIKY M3)\62D$\F5,(\1"R&PO/4=-Y09Q@301V*=.MS]->FZ?9.FD7 MZ^F&`8&]7,?1?KRP*&99M_$ZJ]8*JQ+`40#+C7D.A#DWW]\,&:W&N]\CQDVA M_"W]HE+9_1YQTION[AX\$]\KXI[Q[OK]#AI^^NDGMB^IG6:!#BAJD[H?X`>7 MRPD^(4R>[NYF75)U(DF6I[M>@``*27O(:L29&/?-*PHK=>I5;9/))VH"`R)> M0,-79D^.=.U9>$F)WQD$.K\QNA?#RV$/&.:'=UI[?_@^;^XD?<@_1HV02!Z\ MC<][=69VWL.0-A/*CY+&QY"^&]!F4[^N0F2]U&P$SNFN#=#A;^_2Z<_MXQ>? MB:3X'-N1E=@S_J:(`_=+TL4'R=^V4J2$%^E"]3Y;6''\F#%^YL1)QW&BLTI% MB;RDKS\?@=EN9I!A_UQ4_AE5\@:3&P(XP$,(L.B2!-V9[U1KXE=!7))3\6AY M274OJ9T*;RJJB3@[R_1;RSY`"1H&H6N(--?Q-6`)@3T-XA/7E*R/>KHR0@O20X]NS,1RG2M]K4B\C%#)L MWJR1:2^LX"[-Z79E@=3W[BG7PZAIM587R'\Y<4.:"=0&"E+>""?0(!WA8H%] M@)2I$F([!AECN\O&T*84[$,4Y&@#@`32HOGJ9]X"P0>1+AJ+:9F MG@AL*+?V.4\FUZGS2*2?MXA32_$8!D\3<>="+JJ1J._1"A+.M#@AX7XU$2\$ MGAQ1J6$!IYOM(T&^`R=%[`E2WX_SD<,`['D$+Q:6SW;+VS/A/_B,U\2/)&;O M?_#K0GKB=)[41:/1J.W^NKL34ZUARYY;.#O-"I?<>;!NN)(!4L7X2BP0:J$' M[!@W0`O:X&[9K&]H@MKNSHXR>E.RH#(^J1*/NL"T,!TFC.S%LHJYZN3:!!8G MHD(]DC\<\2%61@61>$YHA"GI2XVYU%DH&H%FD&O]8G\-'EA,ME:5`8'\A+B6 MZ7A5-5H&?F$92/RC,*I6Y$!@3XU%+`_B/6Y6FC)F-$I9G)WNW MH-ES*P%R=RE:4@<$=D(1HE"@MR5+;2XBFB3O/]A(6&_,>0IXUI]UCQ>+1 M]0O?ZH7=N5.2A&8_Q.QH/Q$_QI@/P*DI14T0ZS./9!=/E$81BDCAH%;E8$]3 M6D*&9)Y63M9-HQY(*"I)2*"YE1SLFC3VA@\EB`9VHH;JX+K?9Q=$@\TM>XJ" M6W\F$&O6,W^*R9M:M<\,GL4*"C,PD$X0"*OYVDGS7894,3;?HYZXQ*;S0R[` M.?VSPR!P;5G=)YF&].742!0-&>EK`8GT34&A;FP#YDRX&M_.4QF]N:[Z&!5U ML/]O-PH)1]@.,^&1X@/WD5"-T<&R$?/)'K&+74>E-'$@:@Z^N5-X\:`O?<)F MM2B]V127GOXS>"I^^RW[$CW59!F[@+)DD>%VY@KL!0L_C9&NR23D+<*3#VQR MZ80EYGG9'&"@TI1JGK"(9\E"1B0UF$4B1``H<]/4L995(F+G```T:?O3#JOH M)+QODL7^V^3A!A'!%L_/,I;B1T`U"H1G_*L@6Z$ZD%3/AB&^-?H%&E-*[1LTD/?G:ZHA+50M`3A8P[H);WLH>>;-).%>FWI M^\2V(;_4E'(P_GE.E):H4B8[4#K,UWR.1<5YHD7^&:!4IZG/\;5%;9YTE%A`+8U< MB>_=9``FU74_JG(223&7DTHH",V:9BG^[*QDT\F"&J<.%).(J4.`M1)>ISP, M?S27WD-/-C>/!^"?GI)%:,8=&@2@4@B66QUI(5/#N90I0,2TF:;SOE3K7/7H MG9WSWLT_C-&PN@>!:UG+V)A4\\R[Z,GC>.SZP+J,!*[?DF32I;)_]^"//([< M3XU]*YUM9^>'(F#',P&4E*=EXI5:66 MDW,7M@T0-'6I%=Y')NES=@$!G&*57!$@1'C_AO=7^9O4,$TIA[S)!./9:+B< M2[J*#"8[:D11^Z!,X4$RX9!E3#Z=="Z,^WUW)]\+9ZH\8;Z?BTVH;Q^U->(2 MI.9HKF&GVD)Y,)7+(8'?E%Q[\^S/GW\^W;"BEMC;*_;N$PGYNJ%I/+4%*3QE+*I[B34=18EZJT4VE:9NM?,U]3W=(U5'5(.R`?U3S5 M2:D7+@R%*.NK6K%6,""%*%*H!!R*"G&=(DLL:`5ENVZT8&ZU6*1P59\@C6"? MVH$3%+"G81KP!5`.=!R>*4WA2QGB+IW$=1CSFILPC^DR`/,4CQ`X"\)'P#$7 MG.+631XI$2@*E'U&4-0X\M3=X=K&MB*7F28A\M%-7#G`EUC32=N:X`4:?P0- M*4HEGFK],LIKHJNPKTV[$O425=8HO)4^KZ]=13R]Z:S$$*-6$5J?#MV/,Y2> MHEI5\%S"98H:3=HA3[+X0F5W:04TK,;^I1BM;DGIS-LA07IOWH_)J/R:2=VQ MULH[)L.0DM_F&)D'6N6U7P,<]@O-4]4UC@IA,;D`H-&>R1O+,@QU?+_Z;=;, M?:%2J9?)5RR1"T@CI/>I*Q\7=-JH>)@'ESR.^^#9KJIL*:5"WN'=S:WXOJI*L)HZ!$#S(@KMK.N&EXO( MPW/NT:3E+#>GJ608/JSU.=,T':J=*!Y>5-SZ#[J+H8WHQZ'T?B M-WP8](Q^YU.M/!\-J6P3%KG696?\=R7HIJ1$/HPED&^?#_'5&]L\?+LW!9WFN MF?TU.NF..[U1QQQL5G"L*7B;<7O(?->MBM:OCC(FRJ9T>+]A M//HK?XKG5$"5!9)#M0X%XI7GSY]OZM=.2>3IM;RWS`_F\/>1`YOT391(BS"( M9>9%P*`8@Y/0OI MU)F/J[53P3"PW<8:[D-Q=R&4)U#R0E,\5QX!:!5=.3S+XN;.AO2LT`.,KJF) MJ->3K[;2I?6FC MLN.SP8=1YU*H&!FOFZ<(RXUR7*;M,]?J0#K1JXM?M@1?W:7)]:J>1$X/>[Y] M*IX_]Y2:N?,7V?D+.@^I\Y=:EJ$^T3VBTIE4R/EJG!RO]/Q#=I6R539(^9!4 M/R7=V;,UJ MI5DE?KJZ2W__^DY]=SW^M('KNS1>*J>6$NWO%_K/CZ8`;Z$T0KE*TH^C_F!^ M#2E*`AAT;9-+H.W+OUZDP5!T.Z.1:6R2"Z&R:T68MQ#N/V/=&8P_;N/<">+' M[8Q_+QP]VQO`14<^4Y$Q30W=N*.A*M[3\OKE@.]B%%3R4X8`?/@!+;V#5(^- M!-T26U'BV:F/#:H#P+#^)#[_&[G7C^$ACMDHG>S*75":6CZ]^C$49E^I"#92>70*\')-;TD8[.2J3 MC^:1:NTNH)49=>?;T589;$4`6;DNY$5Z&7BA#*@(89CI=N+8MH)I=4'`ZS2R M/UCGGGK,TOQP MCC]KAJ?_,$#/BC>!;D`/I"E55S0Y%&TST?78&-T,.I=&;J5OD(!?!861\S4) M,IHM$J"RI\+^JC,>?QR.>II$69,2Z/O,<[/`SB^22FO("&5]SPO0W6,#[/KA MW1T)&09*/"W5^@;LW0:[>4;KQHEUZWOQC&[^RW?F_Q?8U0Z9M*@.EO"F<(.I1\\H8/@`-8\&0<#;"BFT@G8Z M,1/MX^-&]K>)SKK0$*H,4!HRY<"4`W9]RX-*?J3!KU^4A%)LV52)L$U<,?73 M>+9U/9(&)J27FQ9=:.;K:55TP4^ M6Z:MZE_?O!&O:G`2-;='-PME\AE"O:^/H?G)$=&'JI8^W2ZIO:I2H-J>Q>I5 M5VD\I"XZYS?FP)AD3O2$.?SVF^`/^V]G-P3+*B7)WKZ4V!>/CI)(/HKB(VYY M1;ORJF:E-E\W$;'E_X+"#E0288/NB]JI%[T3%OB=:[6:NP<*KBE>D<)_[:FZ>[)FI-,C:B?C& M(_'*@>,^'-!CQDIV(EX<@TLL*"B8B^3;U#ZWM,]M_NRDBW:!-LT-;:T-;7*L M^\6U_46U0JLAS,]^[WL53H&:A3+4.;DS:YVM7%(4IFLJ$A05W[CWD7.I[76A7)_H; MXASB2G#LA(\R$]B"?ZHYWQ05<=GI7F"G<_)4RV/>)0K7?A@N_N!>2*$8OW[1 MD<#($@?U/Q"_X:$=O<-0Z;-V?D20HQ?=NS*)1>M*:L&46J2689VP8/TF"I&6 M,'3#W=1_>CFUZ78J6\63O!9D2M)?&M.3YZKDP;)E"NL3O'ZCHLK@N47HKUY2 M;;REPN[)WIQ;V:/SZ,[.SL2>X\*YV3?$L_]MY]IVTP:":%_CKUBY*,42 M!@.Q:6E5-7)H(B4*$41*^X2(P0VJ`Q'@7M2?[\SLVMZUH(DJ%%IIS@O&N[9W M?9F=ZXGQ\2OU]S@,>\/A*#SKA>=Y[EHZP]SXPT,QIB^PJG>JB<&H?P[/X`9^ MLF%EUJT,A8(]TJ-#@)=\!M?+)>%=TA+I2VT_WRR"^BUPF?P5I\K MCA<3O;&(8X1/4H5+LPH-6AF,#K@VW`SZEQ>?*5Z*2NNUI:Q)W'%\==6[/*'- MWB?YJ7A!$&R(J%9M\])P-VD.VE*BK22T0*@\\69Y1ZLPJ7#XU#2\/ND-!G3F MR[ZJ.3$'@=VT)ZCN'2VF/E%\3_!&TYL7RRG$ M:CTBP0FV%7Z4X=D%##VO'*$H>=X(0JF6%X2833)Y.<]Q-C09_8/X'YG]@ M_@?F?V#^AWWP/Z0Z^4-;)PN0]`;^T1;RAW0[\\-&G@0X$?,D,$_"[G@2]-)8 M\4L4E;$BL].Q_/S)O@9)5C#YU[P.?^5SV(^K@!S%3S-WE[93G"(VLJ%C&7F6 MYB\&G.$0!Q/7F\4!U$5FHFG6L/1R3L1[T<('I+R,7\2!2#M$NXD7#OQ9'?]+#[<@&*N/N%DK#`0%&]!4F/9!&-$Y0A5I1,Q_-N MUSIPP:1RX_RD=1!+,`'V"&W`-O[/NQU>XY'OO]GJ')7]/YV`O_]G06,#%9N[ M&M\_)*#6&4KYZT;3%RVOVPJZ[3>&4MXH:(7T:)NPIS\B4!C`RJU'LU6=SE^? M3M*"=*A(:[+1,!])P]PFZBC%C2.+.U7_+(A1R\LXT0Y_D%4VL`N&\K+454N# M,D[[)Q*KFO@R(XM`C`7(E`EQ:I#VKEU@&_\5IN)]];;/H11\F*U?P320.PA+ M04@)TZ]2"BB02@.=*:T4?C?-R50)UW?3.;629^46'4L)E9U@N;A,A1**8HC< M+3/5FLZE_P+&HO%XZ>>&T4S74>/^9[28KQ;)U#;?!*T@37\%B<,Q@,!H/!8#`8#`:#P6`P&`P&@\%@,!@,AH[? (;L2=#0!X``!+ ` end -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 00:45:32 1994 From: mycroft@gnu.ai.mit.edu To: Mark_Weaver@brown.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Crashes under Aug 14th system Sender: owner-current-users@sun-lamp.cs.berkeley.edu Don't you have a 486DLC? I think there is a common thread here... From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 16 05:22:53 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Crashes under Aug 14th system <9408152110.AA01498@goldman.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu mycroft@gnu.ai.mit.edu writes: > Don't you have a 486DLC? I think there is a common thread here... Nope. A Gateway 2000 486-DX2/66 vlb. A little while back I posted a long description including all that stuff. If you've lost it, I can send it again. Mark From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 16 06:04:08 1994 From: Arthur Hoffmann Subject: floppy problems To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1693 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi I have an A3000 with a HD floppy as standard. When I faormat a disk under ADOS format drive df0: name bsd noicons ffs I can mount it on netbsd mount -t ados /dev/fd0a /a but it is only readable, not writeable. If I try to mount it mount -rw -t ados /dev/fd0a /a I get the following error: Aug 16 12:24:05 atze /netbsd: fd0: corrupted track (160) data. then ps -aux shows the following: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND root 2191 0.0 0.0 128 40 p3 D 12:24PM 0:02.35 ados /dev/fd0a /a (mount_ados) ^--->this then causes the floppy to be unaccessible. I also tried to newfs the disk rather than mounting it ados newfs -m0 -c80 -i8192 /dev/rfd0a but this came up with corrupted track (or something) messages. Also taring a file to the raw drive didn't work. tar -cvpf /dev/rfd0a /netbsd resulted in errors about parts of the disk being bad. If I keep trying to work with the disk the system eventually freezes, only the mouse pointer and window manager will work, but no new processes can be started anymore. If I click on a gadged eg manual page from xman, then the window manager dies as well. Only a reboot Crtl-A-A helps here. The floppy itself is good, I formatted it on the Amiga with no errors, and to make sure I scanned it with disksalv which chouldn't find anything wrong with it. btw disklabel doesn't seem to work either. I forgot the error message right now, but I'll try again if anyone wants to know. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 16 08:50:51 1994 Subject: ppp problem From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The problem I reported using the 1.0beta kernel and PPPd does not occur when I run a -current kernel (right now using fridays kernel). The 1.0beta release kernel must have the PPP bug that was recently removed. Tim N. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Aug 16 23:30:31 1994 From: niklas@appli.se (Niklas Hallqvist) To: amigaman@esu.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: slow kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Russel" == Russel Miranda writes: Russel> On Sat, 13 Aug 1994 chopps@emunix.emich.edu wrote: >> Adding 8M of 16 bit ram will slow your system down considerably I >> would think. >> >> Chris. >> >> (who will have a way to not configure 16bit z2 mem when he adds non >> contig memory support for just> Russel> Would it be practical and/or desirable for 8M of 16-bit RAM to Russel> be used as a swap RAM disk? It might be slow compared to Russel> 32-bit RAM, but I would think it would be better than swapping Russel> to disk, if there was enough room. I ask because I too have Russel> 8Mb of 16-bit RAM, and I'd rather it enhanced my NetBSD system Russel> instead of encumbering it. I like this, swapping to disk is the primary reason I want to use my 16-bit mem, i.e. I want to lower the swap rate. However running programs from 16-bit mem is slower, maybe this proposal would be a nice compromise. Anyone want to learn how to write a pager? Here's a nice oppurtunity! Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 00:39:41 1994 From: "Hubert Feyrer" "Automatic interactive Installation _ I am working on one but I need help." (Aug 15, 11:53am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I wanted then, to make the 'b' partition look as '/'. I have tried different > solutions which all failed > > remount /dev/sdxb on / chokes with 'does not match mounted device' > mount_null /xxx/bin /bin, etc ... does not work How about "chroot /newroot /bin/sh"? Hou must have /newroot/bin/sh for this. > The questions I have are: > > 1. Would there be any way of reusing fd0a after having removed the floppy, How about doing a reboot with a special kernel that seeks the root on sd*b? This might be hardcoded into the kernel then, though. (Or better: binpatch some kernel before copying it ro /dev/reload. > 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); > mount_null seemed a good idea ? Forget it. As long as nothings starts paging during the installation, everything will be happy. > Any help very much appreciated, please send Email directtly to me, I cant > read the list due to work load, especially with ALL the duplicates ! Bill's bootfloppy is a fine thing for the first steps, it only forgot about two things: There's no support for installing from CD-ROM or tape! Have you spent some thoughts on supporting multiple installation medias? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 00:43:20 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, c9020@rrzc1.rz.uni-regensburg.de Subject: Re: Automatic interactive Installation _ I am working on one but I need help. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: "Hubert Feyrer" > Message-Id: <9408162112.ZM2976@rrzc1> > Date: Tue, 16 Aug 1994 21:12:32 +0200 > In-Reply-To: francis@hasler.ascom.ch (Francis Demierre) > "Automatic interactive Installation _ I am working on one but I need help." (Aug 15, 11:53am) > References: <9408150953.AA13633@gamma.hasler.ascom.ch> > X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I To: francis@hslrswi.hasler.ascom.ch (Francis Demierre), > amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu > Subject: Re: Automatic interactive Installation _ I am working on one but I need help. > > > I wanted then, to make the 'b' partition look as '/'. I have tried > different > > solutions which all failed > > > > remount /dev/sdxb on / chokes with 'does not match mounted device' > > mount_null /xxx/bin /bin, etc ... does not work > > How about "chroot /newroot /bin/sh"? Hou must have /newroot/bin/sh for this. > > > The questions I have are: > > > > 1. Would there be any way of reusing fd0a after having removed the > floppy, > > How about doing a reboot with a special kernel that seeks the root on sd*b? > This might be hardcoded into the kernel then, though. (Or better: binpatch some > kernel before copying it ro /dev/reload. > Hi Hubert, thanks for replying ... As shown at the end of my previous mail, I am trying to look at the kernel but as far as I went, it does not work, I get some trap error. Of course, I forgot a few things like rerurning from the routine before the "justdoswap:" label.. But it still does not work... > > > 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); > > mount_null seemed a good idea ? > > Forget it. As long as nothings starts paging during the installation, > everything will be happy. > Well, that is not the problem, If I run some commands, these commands try to run other things with hard coded paths to /usr/bin and /bin. That is why I want my mounted file system to look as root. > > > Any help very much appreciated, please send Email directtly to me, I cant > > read the list due to work load, especially with ALL the duplicates ! > > Bill's bootfloppy is a fine thing for the first steps, it only forgot about two > things: There's no support for installing from CD-ROM or tape! Have you spent > some thoughts on supporting multiple installation medias? > On the multiple diskette that I get onto the miniroot are ALL devices as well as the rquired mount commands, also tar is available, so it should be possible. What I do not know is what a CD rom distribution lookS Like ... I assume they also have the release/xxxx.tar files on them, If not, I dont know what to do. I thought to ask if the user want to load from CD and then ask the pathe to the release tar files ... > > Hubert > -- > =============== Hubert Feyrer ============================================ > Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 > Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 > Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf > ========================================================================== > Click here. > ----------------------------------------------------------------------- Francis Demierre SMTP : francis@hasler.ascom.ch Ascom Hasler AG, UUCP: ...!mcsun!chsun!hslrswi!francis Abt. NVEI2, X.400: S=francis/O=ascom/P=eunet/A=arcom/C=ch Belpstrasse 37,, Tel. : +41 31 999 3503 CH-3000 Bern 14 Fax : +41 31 999 3735 ----------------------------------------------------------------------- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 00:54:42 1994 Subject: From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu, amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Here's the fix for RTS as well as as a fix for the case when your serial port gets a ctrl-S in ixon mode without a corresponding ctrl-Q. Normally you can't force the port to anything in those cases, not even close it. I solved it the FAS/SAS driver way. An open with O_TRUNC releases the blocked condition, easiest done in Bourne shell with ">/dev/tty00" or in C shell with 'echo "\c">/dev/tty00'! Enjoy, niklas PS Chris, do you feel like reviewing the device-independent part and bring it forward to the core team. Seemingly noone else uses RTS for handshaking, therfore this bug has gone unresolved for a long time. =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/kern/tty.c,v retrieving revision 1.1.1.12 diff -c -r1.1.1.12 tty.c *** 1.1.1.12 1994/08/15 14:43:22 --- tty.c 1994/08/15 20:18:41 *************** *** 1044,1053 **** */ if (total >= TTYHOG / 2 && !ISSET(tp->t_state, TS_TBLOCK) && ! !ISSET(tp->t_lflag, ICANON) || tp->t_canq.c_cc > 0 && ! tp->t_cc[VSTOP] != _POSIX_VDISABLE) { ! if (putc(tp->t_cc[VSTOP], &tp->t_outq) == 0) { ! SET(tp->t_state, TS_TBLOCK); ttstart(tp); } /* try to block remote output via hardware flow control */ --- 1044,1053 ---- */ if (total >= TTYHOG / 2 && !ISSET(tp->t_state, TS_TBLOCK) && ! (!ISSET(tp->t_lflag, ICANON) || tp->t_canq.c_cc > 0)) { ! if (ISSET(tp->t_iflag, IXOFF) && tp->t_cc[VSTOP] != _POSIX_VDISABLE && ! putc(tp->t_cc[VSTOP], &tp->t_outq) == 0) { ! SET(tp->t_state, TS_TBLOCK); ttstart(tp); } /* try to block remote output via hardware flow control */ *************** *** 1378,1384 **** */ s = spltty(); if (ISSET(tp->t_state, TS_TBLOCK) && tp->t_rawq.c_cc < TTYHOG/5) { ! if (cc[VSTART] != _POSIX_VDISABLE && putc(cc[VSTART], &tp->t_outq) == 0) { CLR(tp->t_state, TS_TBLOCK); ttstart(tp); --- 1378,1384 ---- */ s = spltty(); if (ISSET(tp->t_state, TS_TBLOCK) && tp->t_rawq.c_cc < TTYHOG/5) { ! if (ISSET(tp->t_iflag, IXOFF) && cc[VSTART] != _POSIX_VDISABLE && putc(cc[VSTART], &tp->t_outq) == 0) { CLR(tp->t_state, TS_TBLOCK); ttstart(tp); =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/ser.c,v retrieving revision 1.1.1.9 diff -c -r1.1.1.9 ser.c *** 1.1.1.9 1994/06/18 10:55:24 --- ser.c 1994/08/15 22:49:57 *************** *** 31,40 **** * SUCH DAMAGE. * * @(#)ser.c 7.12 (Berkeley) 6/27/91 ! * $Id: ser.c,v 1.1.1.9 1994/06/18 10:55:24 root Exp $ */ /* ! * XXX This file needs major cleanup it will never ervice more than one * XXX unit. */ --- 31,40 ---- * SUCH DAMAGE. * * @(#)ser.c 7.12 (Berkeley) 6/27/91 ! * $Id: ser.c,v 1.1.1.1.2.13 1994/08/14 23:19:24 root Exp $ */ /* ! * XXX This file needs major cleanup it will never service more than one * XXX unit. */ *************** *** 73,79 **** #define SEROBUF_SIZE 32 #define SERIBUF_SIZE 512 ! int serstart(), serparam(), serintr(); int ser_active; int ser_hasfifo; int nser = NSER; --- 73,79 ---- #define SEROBUF_SIZE 32 #define SERIBUF_SIZE 512 ! int serstart(), serparam(), serintr(), serhwiflow(); int ser_active; int ser_hasfifo; int nser = NSER; *************** *** 245,250 **** --- 245,251 ---- tp->t_oproc = (void (*) (struct tty *)) serstart; tp->t_param = serparam; tp->t_dev = dev; + tp->t_hwiflow = serhwiflow; if ((tp->t_state & TS_ISOPEN) == 0) { tp->t_state |= TS_WOPEN; *************** *** 301,306 **** --- 302,313 ---- } } done: + /* This is a way to handle lost XON characters */ + if ((flag & O_TRUNC) && (tp->t_state & TS_TTSTOP)) { + tp->t_state &= ~TS_TTSTOP; + ttstart (tp); + } + splx(s); /* * Reset the tty pointer, as there could have been a dialout *************** *** 699,704 **** --- 706,724 ---- return(0); } + int serhwiflow(tp, flag) + struct tty *tp; + int flag; + { + #if 0 + printf ("serhwiflow %d\n", flag); + #endif + if (flag) + CLRRTS(ciab.pra); + else + SETRTS(ciab.pra); + return 1; + } static void ser_putchar(tp, c) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 00:58:16 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Arthur Hoffmann , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: floppy problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 16, 1:05pm, Arthur Hoffmann wrote: > If I try to mount it > > mount -rw -t ados /dev/fd0a /a I thought the ados file system was read-only. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 01:13:35 1994 From: Paternostro Ugo To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: NetBSD 1.0 beta in DBLPAL available Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello everybody! Last week I got the sources of kernel 1.0 beta, and I compiled them. It worked at the first try, phew... :-) In this week I did a little modify to the kernel: I implemented (well, the most of it was just cut and paste...) DBLPAL, and now I'm running NetBSD in 720x550 pixels, gaining 120 pixels vs DBLNTSC. I would be glad to submiss the patches for the use of the community of NetBSD-ers. Here is the problem: how do I submit a change, like this ? Thanks for your attention. P.S.: please don't send mail to my home e-mail address during summer. Tnx. Bye, UP -- +-------------------------------+---------------------------------------------+ | Ugo Paternostro | | +-------------------------------+ Work: Dipartimento di Sistemi e Informatica | | Home : P.zza Cannicci, 2 | Via di Santa Marta, 3 | | 50018 SCANDICCI (FI) | 50139 FIRENZE (FI) | | Italy | Italy | | Voice: +39-55-252115 | Voice: +39-55-4796365 | | Fax : +39-55-254042 | | | EMail: ugo@glub.adsp.sub.org | EMail: paterno@aguirre.ing.unifi.it | | 2:332/112.3@fidonet.org +---------------------------------------------+ | 39:102/503.3@amiganet.ftn | All opinions are mine, mine, only mine! :-) | +-------------------------------+---------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 01:20:27 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 01:32:27 1994 From: "Hubert Feyrer" "panic: ffs_valloc: dup alloc" (Aug 14, 2:31pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I After getting past the lack of the /dev files, I'm running into yet > another problem. :( As soon as I tried to use vi to edit /etc/fstab, > I got the following: > > mode = 020640, inum = 1291, fs = / > panic: ffs_valloc: dup alloc > Stopped at 0x81048: unlk a6 > > The same thing has happened when using cp as well. I'm running on an > A3000 (no ROM) w/ 8M Fast, 2M Chip, 240M HD. I can imagine this happens every time you try to write to your disk? try fsck'ing your rootfs. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 01:34:55 1994 From: "Hubert Feyrer" X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I tools!) binpatch.tar.gz: obsoleted bwbasic-2.10.tar.z: demands libm.so.1.0 cat1234578.tar.gz: obsoleted config.tgz: obsoleted cvs-1.3.tar.gz: seems to work (I've never ever used this!) diff-2.3.tgz: obsolete, source only elvis.gz: demands libc.so.4.0 emacs-19.22.netbsd.tar.gz: works, requires additional files. See REMARKS! gcc-2.5.8.tar.gz: demands libc.so.1.1 gdb-4.11-amigabsd-diffs.gz: obsoleted gdb-4.11.gz: obsoleted gdb-4.9-README: obsoleted gdb-4.9-amigabsd-diffs.gz: obsoleted gdb-4.9.gz: obsoleted gdb411bu23.tar.gz: obsoleted gnumake-3.71.exe.gz: demands libutil.so.1.0 grofflibg++bin.tar.gz: obsoleted gs.bin.tar.z: demands libXt.so.5.0 id.tar.Z: source only ircII-2.2.9.tar.gz: demands libc.so.1.1 joe-1.0.8.tar.gz: demands libc.so.1.1 kermit.gz: demands libc.so.4.0 lha-1.00.tar.gz: demands libc.so.1.1 manpages.readme: obsoleted manpages.tar.z: obsoleted ncftp-1.7.2.tar.gz: demands libcurses.so.1.0 ncftp-175.gz: demands libc.so.4.0 new-aterm108.tar.gz: sorry, not tried (no modem here) oleo.gz: demands libcurses.so.1.1 perl-4.036.tar.gz: broken! :-( pico.tar.gz: works. Try this if you hate vi! :-) ppp-1.3.tar.Z: obsoleted rcs-5.6.0.1.tgz: source-only, obsoleted rzszbin2.tar.gz: sorry, not tried (no modem here) term-1.1.1.patch: source-only (sorta ;) term107.tar.z: sorry, not tried (no modem here) tex.tar.z: seems to work (no TeX-distrib here!) uzap.gz: demands libcurses.so.1.1 views-try2.tar.gz: works, don't start under X! :-) xarchie_2.0.8.tar.gz: demands libX11.so.5.0 xlock.tar: demands libX11.so.5.0 contrib/X11: ~~~~~~~~~~~~ Mosaic-2.1-pre.gz: demands libc.so.1.1 X11R5.bin-19Jun94.tar.gz: works. X11R5.fonts-01May94.tar.gz: works. X11R5.include-01May94.tar.gz: works. X11R5.lib-19Jun94.tar.gz: works. X11R5.man-01May94.tar.gz: works. X11R5.patches-19Jun94.tar.gz: works. XamigaMono-19Jun94.gz: works. xview32-26Jun94.tar.gz: works. XbsdCC2.gz: works. XbsdCC4.gz: works, slight display-bug. Who recompiles? mit.tar.gz: has anyone succeeded with this? contrib/X11/OLD: ~~~~~~~~~~~~~~~~ Xami_rev0.tar.gz: obsoleted, screws overscanned screens. Xamiga.src.tar.gz: Is this R4 or R5? Anyone compiled for 1.0? Xamiga.tar.gz: demands libc.so.1.0 aXe_6.1.tar.gz: demands libXaw.so.5.0 afvwm.tar.gz: works if DISPLAY includes hostname x11_dist.tar.gz: 50% of this crash. :-( xmas.tar.gz: works. xretina.tar.gz: sorry, not tried (no retina here) xretinaZ2.tar.gz: sorry, not tried (no retina here) xretinaZ2_src.tar.gz: sorry, not tried (no retina here) xxgdb-bin-src.tar.gz: obsoleted. REMARKS: ~~~~~~~~ - Programs marked with 'demands lib*.so.*' should be recompiled to match recent changes in libs - please re-upload. I'll remove the ones here soon. - Programs marked "obsoleted" will be removed too due to newer versions, incorporation into NetBSD, etc. - To compile tcsh-6.05, don't use imake but the bsd4.4 file from the config-directory. - Emacs-19.25 compiles fine if you use m68k-hp-netbsd as architecture. 2.) Suggestions for uploads and uploaders - to be discussed *********************************************************** - Please to *not* upload modified sources of freely distributable programs here! Send them to the authors instead so the changes will be incorporated in the next release. - To make it easier to remove or replace packages, it would be good if packs would fit in a single directory each, indicating package and version by its name. Again, all those package-directories should be put in one single directory, I prefer "/opt" for this. (Yes, SVR4, I know... ;). This would mean to shuffle some things around in the tree: /usr/X11R5 -> /opt/X11R5 /usr/local/emacs -> /opt/emacs-19.25 /usr/local/lib/perl, /usr/local/bin/perl -> /opt/perl-4.036 ... - Packages consisting of just a binary should place them into a public directory (/opt/bin) where all such binaries are collected. Candidates are e.g. bash, tcsh, ... Corresponding manpages to into /opt/man. - Packages that have only one or a few binaries but many other files should be placed in a subdirectory below /opt, with links in /opt/bin pointing to those binaries. This way, users have to include only /opt/bin into their search path. - Additional thoughts could be spent on a pkg-system as under SVR4 or Lin*x, which automates and simplifies the installation process (I think of wu-ftpd-2.4, where it would be necessary to modify /etc/inetd.conf). So much for now. Hubert P.S.: I'll upload some programs that have been compiled for 1.0beta that follow these guidelines. -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 01:35:01 1994 From: "Hubert Feyrer" "Automatic interactive Installation _ I am working on one but I need help." (Aug 15, 11:53am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I wanted then, to make the 'b' partition look as '/'. I have tried different > solutions which all failed > > remount /dev/sdxb on / chokes with 'does not match mounted device' > mount_null /xxx/bin /bin, etc ... does not work How about "chroot /newroot /bin/sh"? Hou must have /newroot/bin/sh for this. > The questions I have are: > > 1. Would there be any way of reusing fd0a after having removed the floppy, How about doing a reboot with a special kernel that seeks the root on sd*b? This might be hardcoded into the kernel then, though. (Or better: binpatch some kernel before copying it ro /dev/reload. > 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); > mount_null seemed a good idea ? Forget it. As long as nothings starts paging during the installation, everything will be happy. > Any help very much appreciated, please send Email directtly to me, I cant > read the list due to work load, especially with ALL the duplicates ! Bill's bootfloppy is a fine thing for the first steps, it only forgot about two things: There's no support for installing from CD-ROM or tape! Have you spent some thoughts on supporting multiple installation medias? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 01:39:54 1994 From: francis@hasler.ascom.ch (Francis Demierre) To: amiga-dev@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, c9020@rrzc1.rz.uni-regensburg.de Subject: Re: Automatic interactive Installation _ I am working on one but I need help. Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: "Hubert Feyrer" > Message-Id: <9408162112.ZM2976@rrzc1> > Date: Tue, 16 Aug 1994 21:12:32 +0200 > In-Reply-To: francis@hasler.ascom.ch (Francis Demierre) > "Automatic interactive Installation _ I am working on one but I need help." (Aug 15, 11:53am) > References: <9408150953.AA13633@gamma.hasler.ascom.ch> > X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I To: francis@hslrswi.hasler.ascom.ch (Francis Demierre), > amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu > Subject: Re: Automatic interactive Installation _ I am working on one but I need help. > > > I wanted then, to make the 'b' partition look as '/'. I have tried > different > > solutions which all failed > > > > remount /dev/sdxb on / chokes with 'does not match mounted device' > > mount_null /xxx/bin /bin, etc ... does not work > > How about "chroot /newroot /bin/sh"? Hou must have /newroot/bin/sh for this. > > > The questions I have are: > > > > 1. Would there be any way of reusing fd0a after having removed the > floppy, > > How about doing a reboot with a special kernel that seeks the root on sd*b? > This might be hardcoded into the kernel then, though. (Or better: binpatch some > kernel before copying it ro /dev/reload. > Hi Hubert, thanks for replying ... As shown at the end of my previous mail, I am trying to look at the kernel but as far as I went, it does not work, I get some trap error. Of course, I forgot a few things like rerurning from the routine before the "justdoswap:" label.. But it still does not work... > > > 2. If yes, what should I use to make my /mfs (/dev/sdxb to look as /); > > mount_null seemed a good idea ? > > Forget it. As long as nothings starts paging during the installation, > everything will be happy. > Well, that is not the problem, If I run some commands, these commands try to run other things with hard coded paths to /usr/bin and /bin. That is why I want my mounted file system to look as root. > > > Any help very much appreciated, please send Email directtly to me, I cant > > read the list due to work load, especially with ALL the duplicates ! > > Bill's bootfloppy is a fine thing for the first steps, it only forgot about two > things: There's no support for installing from CD-ROM or tape! Have you spent > some thoughts on supporting multiple installation medias? > On the multiple diskette that I get onto the miniroot are ALL devices as well as the rquired mount commands, also tar is available, so it should be possible. What I do not know is what a CD rom distribution lookS Like ... I assume they also have the release/xxxx.tar files on them, If not, I dont know what to do. I thought to ask if the user want to load from CD and then ask the pathe to the release tar files ... > > Hubert > -- > =============== Hubert Feyrer ============================================ > Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 > Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 > Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf > ========================================================================== > Click here. > ----------------------------------------------------------------------- Francis Demierre SMTP : francis@hasler.ascom.ch Ascom Hasler AG, UUCP: ...!mcsun!chsun!hslrswi!francis Abt. NVEI2, X.400: S=francis/O=ascom/P=eunet/A=arcom/C=ch Belpstrasse 37,, Tel. : +41 31 999 3503 CH-3000 Bern 14 Fax : +41 31 999 3735 ----------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 17 02:37:35 1994 From: Peter Galbavy Subject: building lex To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 545 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I dunno whether this is pr-fodder or just a SUP issue, but the shell script src/usr.bin/lex/mkskel.sh is not (by default) executable, so it will produce a zero length skel.c file. To fix this I changed the make line to read "/bin/sh ..." and all was happy. I am only starting on a clean tree, so there may be others like this. Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 17 02:54:48 1994 To: netbsd-current-users From: Keith Meurer Subject: Compaq SystemPros and >16MB memory Mime-Version: 1.0 Content-Type: Text/Plain Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone used this configuration successfully? We have a SystemPro with 104MB (yeah, I know, it's a real sob story here :-)) that reports this at boot: NetBSD 1.0_BETA (BSGAHA) #0: Sun Jul 31 18:15:51 CDT 1994 root@news:/usr/src/sys/arch/i386/compile/BSGAHA CPU: i486DX (486-class CPU) real mem = 16252928 avail mem = 14184448 According to the EISA configuration, memory is running in "Compaq Compatible mode", whatever that means. There is also a choice for linear mode, but the EISA configuration changes it back to Compaq Compatible mode when I change it. Anyone seen this before? I want to run INN on this beast, and that memory would certainly be helpful. It's also seriously proprietary memory, so if I can't use it, it's not even useful in other machines around here. Thanks for any thoughts, !!kmm From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 17 02:58:27 1994 From: Julian H Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: cd /usr/src/lib/libc ; make install Sender: owner-current-users@sun-lamp.cs.berkeley.edu cd /usr/src/lib/libc ; make install (with a PC532 current) results in ===> libc install -c -o bin -g bin -m 444 libc.a /usr/lib ranlib -t /usr/lib/libc.a ranlib: /usr/lib/libc.a: no symbol table. Error code 1 Yet I can still compile a new src/bin/ls/ls after, that works, Comments ? Explanations ? (OK it's late, I should be asleep, could it really be the Makefile isnt just adding a __.SYMDEF file & if not why not ? I don't like using make -i to punch my way onward. -- Julian Stacey Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 17 03:00:01 1994 From: Rolf Grossmann To: current-users@sun-lamp.cs.berkeley.edu Subject: netgroups and YP Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I have expanded the netgroup support to use a YP map named netgroup, if the file /etc/netgroup cannot be found/opened. Is anybody interested to get the patches, maybe to integrate them into the distribution and update the manpage(s)? Bye, Rolf From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 17 03:05:17 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: (1) getty/login, (2) NFS options Sender: owner-current-users@sun-lamp.cs.berkeley.edu As people who recognize my From:-line will know, I'm running NetBSD/sparc on a SPARC IPC. And I've got a couple of questions. (1) I have been unable to get logins working on /dev/ttya. I turn it on in /etc/ttys, HUP init, and the login prompt shows up fine. Then I type a username and RETURN (which echo correctly), and it says, instead of the Password: prompt I would expect, @8@@@@9w (with no newline after it). Nothing I type at this point has any effect I can discern, until some timeout expires, at which point it utters the cryptic string @@@@@@]@@PW@P8@@@(@@@@9\@@^@~ and prints another prompt from getty. I would assume this is a baud-rate problem, except that stty insists that the baud rate is the same both when getty is reading a username and when login is reading a password. When getty is in control: speed 9600 baud; 0 rows; 0 columns; lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -ignbrk -brkint -inpck -ignpar -parmrk oflags: -opost -onlcr -oxtabs cflags: cread cs8 -parenb -parodd -hupcl -clocal -cstopb -crtscts -mdmbuf discard dsusp eof eol eol2 erase intr kill lnext ^O ^Y ^D ^? ^C ^U ^V min quit reprint start status stop susp time werase 1 ^\ ^R ^Q ^S ^Z 0 ^W and when login is in control, presumably trying to read a password: speed 9600 baud; 0 rows; 0 columns; lflags: icanon isig iexten -echo -echoe -echok -echoke -echonl echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin -nokerninfo -extproc iflags: istrip icrnl -inlcr -igncr ixon -ixoff ixany imaxbel -ignbrk brkint -inpck ignpar -parmrk oflags: opost onlcr oxtabs cflags: cread cs7 -parenb -parodd hupcl -clocal -cstopb -crtscts -mdmbuf discard dsusp eof eol eol2 erase intr kill lnext ^O ^Y ^D ^? ^C ^U ^V min quit reprint start status stop susp time werase 1 ^\ ^R ^Q ^S ^Z 0 ^W Some differences are obvious...but nothing that explains the weird gibberish I'm seeing. Are serial line logins just not working yet on the SPARC, or what? I haven't seen anything else misbehave when talking to that serial line. /dev/ttyb behaves the same, at least up to the @8@@@@9w point; I didn't feel like waiting for the timeout to see if the other string was the same. (2) Under the first SPARC tarballs I fetched, quite a while ago, there was an NFS mount option "spongy", which provided hard-mount semantics for read and write operations and a few others (readlink, I think, for example), and soft-mount semantics for all others. It struck me as an excellent idea...and it seems to have disappeared. Is this because the NFS code was replaced with some other code (4.4Lite?), or was it actively removed? I suppose what I'm really asking is twofold: (a) are there any plans to add it back, and (b) would it be worth my time to look at adding it back myself (that is, would such work have a reasonable chance of making it into the tree, or would I be wasting the time and effort?). der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 03:22:31 1994 Subject: here's a fun one From: Tim Newsham To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu My system doesnt seem to boot on alternate boots. (ie. when I 'shutdown' the system and then restart from amigados or when I cat a kernel to /dev/reload). It always comes up with MMU faults. I havent done a trace for when booting from amigados but I did a trace for when booting through /dev/reload. I did two traces and it seems to be dieing the same way each time. The process states and stack backtrace are shown below. This happens with both fridays -current kernel and the 1.0_Beta release kernel (with no mods). My system is an A2000 with an old GVP 030/23mhz accelarator + scsi and a GVP series II scsi+ram board (the second board is my scsi bus and I swap the first two configured devices in loadbsd before starting up bsd). BSD is using 5 megs of 32 bit ram on the accelerator board. Process States: pid uid ppid pgrp flag stat comm whcan 3 0 1 1 0004 1 init 2 0 0 0 0204 3 pagedaemon thred_sleep 1 0 0 1 4004 2 init 0 0 0 0 0204 3 swapper scheduler Stack Backtrace: 00020136 _panic 000a6f22 _panictrap 000a71ec _trapmmufault 000a752c _trap 00000522 _addrerr 000a5b08 _pmap_remove 000a5f90 _pmap_enter 0007559a _vm_fault 00075682 _vm_fault_wire 000773c6 _vm_map_pageable 00075a7a _vm_fork 000186e6 _fork 000183a9 _vfork 000a769c _syscall 00000674 _trap0 From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 07:02:11 1994 From: Steve Parkinson Subject: Book recommendations To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 446 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Can anyone recommend a good book about BSD kernels? I've been taking a look at 'Magic Garden' which looked very good, but is for SVR4. I'd like a book which explains memory management, file systems, device drivers, ttys, networking. There seems to be sooo many books for unix shell beginners these days. If anyone is familiar with the magic garden book, how would you rate it? Is BSD and SVR4 really that different these days? Thanks Steve From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Aug 17 07:19:30 1994 To: Paternostro Ugo Cc: amiga-dev@sun-lamp.cs.berkeley.edu, mehlhaff@crl.com Subject: Re: NetBSD 1.0 beta in DBLPAL available of Tue, 16 Aug 1994 15:06:16 +0200 <9408161306.AA12335@aguirre.ing.unifi.it> From: "'Most Excellent' Eric Mehlhaff" Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Paternostro Ugo recently wrote: >Hello everybody! > >Last week I got the sources of kernel 1.0 beta, and I compiled them. It >worked at the first try, phew... :-) > >In this week I did a little modify to the kernel: I implemented (well, the >most of it was just cut and paste...) DBLPAL, and now I'm running NetBSD >in 720x550 pixels, gaining 120 pixels vs DBLNTSC. I would be glad to >submiss the patches for the use of the community of NetBSD-ers. Here is the >problem: how do I submit a change, like this ? Did you, by any chance, do anything that using iteconfig or binpatch (to set the ite_default_height and ite_default_width) to those dimensions doesn't do? Those have worked as far back as the 720 kernel, I believe. Eric Mehlhaff, mehlhaff@crl.com From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 21:05:45 1994 From: "L. Todd Masco" To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Book recommendations Newsgroups: hks.lists.netbsd-amiga Organization: Bibliobytes books on computers, info@bb.com Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199408170428.VAA01192@aludra.usc.edu> you write: >I'd like a book which explains memory management, file systems, >device drivers, ttys, networking. There seems to be sooo many >books for unix shell beginners these days. I don't know of any book on how to implement these features (kernel hacking is still a Black Art, AFAIK), but I can highly recommend the Stevens books for using said systems. The two I have are UNIX Network Programming, for, well, sockets, shared memory, and other network-style stuff, and Advanced Programming in the UNIX Environment. Both deal with both BSD and SVR4, as well as the latter book discussing what standards mandate what features. Both are excellent... and the code examples in them are up for anonymous ftp on uunet. Any UNIX professional should have them, if only to understand WTF is going on under that code. [Of course, it also shows how much UNIX internals suck compared to real OSs like VMS, but that's a lost battle] -- L. Todd Masco | "Cowboy politicians sucking up to the aristocracy, not cactus@bb.com | even sure if they like democracy..." - TR-I From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 17 21:39:03 1994 From: Russel Miranda Subject: Re: Book recommendations To: "L. Todd Masco" Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Wed, 17 Aug 1994, L. Todd Masco wrote: > I don't know of any book on how to implement these features (kernel > hacking is still a Black Art, AFAIK), but I can highly recommend the > Stevens books for using said systems. > The two I have are UNIX Network Programming, for, well, sockets, > shared memory, and other network-style stuff, and Advanced Programming > in the UNIX Environment. Both deal with both BSD and SVR4, as well > as the latter book discussing what standards mandate what features. These books may be good for using them, but I would think what is called for here is the so-called "Demon" book - _The_Design_and_Implementation_ of_the_4.3BSD_Operating_System_ (well, that's close to the title, anyway) which is available in all your finer bookstores with a cute little demon on the cover. (Warning, flamebait approaching...) > [Of course, it also shows how much UNIX internals suck compared to real > OSs like VMS, but that's a lost battle] Please let me know when openvms-amiga is available for anonymous ftp. I had no idea it was even being developed. Will it be POSIX? ;-) I can get the ISBN for the Demon book if anyone needs it - although I'm sure someone else has it, too. )Russ From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 18 00:17:29 1994 Subject: config From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu are any of these required? #options "COMPAT_09" # compatability with older NetBSD release #options "COMPAT_43" # 4.3 BSD compatible system calls #options COMPAT_SUNOS # Support to run Sun (m68k) executables #options "TCP_COMPAT_42" # Use 4.2 BSD style TCP options "COMPAT_NOMID" # allow nonvalid machine id executables #options COMPAT_HPUX # HP300 compatability Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 18 22:51:47 1994 From: chopps@emunix.emich.edu To: Russel Miranda Cc: "L. Todd Masco" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Book recommendations X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu Close, its called `the daemon book'. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 19 06:17:04 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: HW question & sbic sync patch Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi all! First of all, I have a question on how to best handle an amiga hardware problem: On the A2000 the Z2 space will get cached by the CPU from what I've heard. Now if one have volatile registers somewhere in that space, one can lose severly. I'm writing support for a bridgecard which autoconfigs 1M of the Z2 space where such registers exist. Is it possible to, in a CPU- independent way, to ensure data cacheing is off in at least the autoconfigured region during device driver execution. How about cachectl? Is it an expensive operation to toggle data cacheing on a region? Is it possible on 020s and 030s? I rather control this as fine-grained as possible, both in time and in space, as I don't want to turn off cacheing entirely. Second, I've missed fine-grained sync-control ever since it was removed. Here's my stab to reintroduce it for the sbic controllers. What I do, is to enumerate all your sbic controllers starting with zero. If you want to enable sync on controller CTLR target TGT then binpatch your kernel with: binpatch -b -s _sbic_enable_sync -o OFFSET -r 1 netbsd where OFFSET = 8 * CTLR + TGT. To make it clear which controller is which in the enumeration, I print it out during the autoconfig phase of booting. Enjoy! Niklas =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/ahsc.c,v retrieving revision 1.1.1.1 diff -c -r1.1.1.1 ahsc.c *** 1.1.1.1 1994/06/12 21:09:54 --- ahsc.c 1994/08/19 01:55:46 *************** *** 112,121 **** volatile struct sdmac *rp; struct sbic_softc *sc; - printf("\n"); - sc = (struct sbic_softc *)dp; sc->sc_cregs = rp = ztwomap(0xdd0000); /* * disable ints and reset bank register */ --- 112,122 ---- volatile struct sdmac *rp; struct sbic_softc *sc; sc = (struct sbic_softc *)dp; sc->sc_cregs = rp = ztwomap(0xdd0000); + printf (": sbic ctlr %d\n", sbic_cnt); + sc->sc_no = sbic_cnt++; + /* * disable ints and reset bank register */ =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/atzsc.c,v retrieving revision 1.1.1.4 diff -c -r1.1.1.4 atzsc.c *** 1.1.1.4 1994/08/15 15:10:40 --- atzsc.c 1994/08/19 01:56:31 *************** *** 32,38 **** * SUCH DAMAGE. * * @(#)dma.c ! * $Id: atzsc.c,v 1.1.1.4 1994/08/15 15:10:40 root Exp $ */ #include #include --- 32,38 ---- * SUCH DAMAGE. * * @(#)dma.c ! * $Id: atzsc.c,v 1.1.1.1.2.3 1994/08/15 20:13:32 root Exp $ */ #include #include *************** *** 123,128 **** --- 123,131 ---- sc = (struct sbic_softc *)dp; sc->sc_cregs = rp = zap->va; + printf (": sbic ctlr %d", sbic_cnt); + sc->sc_no = sbic_cnt++; + /* * disable ints and reset bank register */ *************** *** 158,164 **** sc->sc_sbicp = (sbic_regmap_p) ((int)rp + 0x91); sc->sc_clkfreq = sbic_clock_override ? sbic_clock_override : 77; ! printf(": dmamask 0x%x\n", ~sc->sc_dmamask); sbicreset(sc); --- 161,167 ---- sc->sc_sbicp = (sbic_regmap_p) ((int)rp + 0x91); sc->sc_clkfreq = sbic_clock_override ? sbic_clock_override : 77; ! printf(" dmamask 0x%x\n", ~sc->sc_dmamask); sbicreset(sc); =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/gtsc.c,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 gtsc.c *** 1.1.1.2 1994/06/18 10:50:37 --- gtsc.c 1994/08/19 01:55:19 *************** *** 32,38 **** * SUCH DAMAGE. * * @(#)dma.c ! * $Id: gtsc.c,v 1.1.1.2 1994/06/18 10:50:37 root Exp $ */ #include #include --- 32,38 ---- * SUCH DAMAGE. * * @(#)dma.c ! * $Id: gtsc.c,v 1.1.1.1.2.1 1994/06/18 21:30:13 root Exp $ */ #include #include *************** *** 120,125 **** --- 120,127 ---- gap = auxp; sc = (struct sbic_softc *)dp; sc->sc_cregs = rp = gap->zargs.va; + printf (": sbic ctlr %d", sbic_cnt); + sc->sc_no = sbic_cnt++; /* * disable ints and reset bank register *************** *** 148,154 **** sc->sc_dmamask = ~0x01ffffff; else sc->sc_dmamask = ~0x07ffffff; ! printf(": dmamask 0x%x", ~sc->sc_dmamask); if ((gap->flags & GVP_NOBANK) == 0) sc->gtsc_bankmask = (~sc->sc_dmamask >> 18) & 0x01c0; --- 150,156 ---- sc->sc_dmamask = ~0x01ffffff; else sc->sc_dmamask = ~0x07ffffff; ! printf(" dmamask 0x%x", ~sc->sc_dmamask); if ((gap->flags & GVP_NOBANK) == 0) sc->gtsc_bankmask = (~sc->sc_dmamask >> 18) & 0x01c0; =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/sbic.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 sbic.c *** 1.1.1.3 1994/06/22 00:02:52 --- sbic.c 1994/08/19 02:19:39 *************** *** 35,41 **** * SUCH DAMAGE. * * @(#)scsi.c 7.5 (Berkeley) 5/4/91 ! * $Id: sbic.c,v 1.1.1.3 1994/06/22 00:02:52 root Exp $ */ /* --- 35,41 ---- * SUCH DAMAGE. * * @(#)scsi.c 7.5 (Berkeley) 5/4/91 ! * $Id: sbic.c,v 1.1.1.1.2.2 1994/06/22 10:08:26 root Exp $ */ /* *************** *** 45,50 **** --- 45,59 ---- /* need to know if any tapes have been configured */ #include "st.h" + /* + * Count the number of controllers using this driver, we need to build + * a sync enable array large enough for all of them. + */ + #include "ahsc.h" + #include "atzsc.h" + #include "gtsc.h" + #define NSBIC (NAHSC + NATZSC + NGTSC) + #include #include #include *************** *** 107,117 **** int sbic_data_wait = SBIC_DATA_WAIT; int sbic_init_wait = SBIC_INIT_WAIT; /* ! * was broken before.. now if you want this you get it for all drives ! * on sbic controllers. */ ! int sbic_inhibit_sync = 1; int sbic_clock_override = 0; int sbic_no_dma = 0; --- 116,127 ---- int sbic_data_wait = SBIC_DATA_WAIT; int sbic_init_wait = SBIC_INIT_WAIT; + int sbic_cnt = 0; /* ! * Another try on individual sync setting. Trust uninitialized data ! * is zero on startup. */ ! char sbic_enable_sync[NSBIC * 8] = { 0 }; int sbic_clock_override = 0; int sbic_no_dma = 0; *************** *** 593,599 **** * handle drives that don't want to be asked * whether to go sync at all. */ ! if (sbic_inhibit_sync && dev->sc_sync[id].state == SYNC_START) { #ifdef DEBUG if (sync_debug) printf("Forcing target %d asynchronous.\n", id); --- 603,610 ---- * handle drives that don't want to be asked * whether to go sync at all. */ ! if (!sbic_enable_sync[id + dev->sc_no] ! && dev->sc_sync[id].state == SYNC_START) { #ifdef DEBUG if (sync_debug) printf("Forcing target %d asynchronous.\n", id); =================================================================== RCS file: /home2/CVSROOT/NetBSD/sys/arch/amiga/dev/sbicvar.h,v retrieving revision 1.1.1.2 diff -c -r1.1.1.2 sbicvar.h *** 1.1.1.2 1994/06/18 10:54:42 --- sbicvar.h 1994/08/19 01:00:57 *************** *** 34,40 **** * SUCH DAMAGE. * * @(#)scsivar.h 7.1 (Berkeley) 5/8/90 ! * $Id: sbicvar.h,v 1.1.1.2 1994/06/18 10:54:42 root Exp $ */ #ifndef _SBICVAR_H_ #define _SBICVAR_H_ --- 34,40 ---- * SUCH DAMAGE. * * @(#)scsivar.h 7.1 (Berkeley) 5/8/90 ! * $Id: sbicvar.h,v 1.1.1.1.2.1 1994/06/18 21:39:01 root Exp $ */ #ifndef _SBICVAR_H_ #define _SBICVAR_H_ *************** *** 90,95 **** --- 90,96 ---- void (*sc_dmafree) __P((struct sbic_softc *)); void (*sc_dmastop) __P((struct sbic_softc *)); u_short gtsc_bankmask; /* GVP specific bank selected */ + int sc_no; }; /* sc_flags */ *************** *** 110,116 **** #define DDB_FOLLOW 0x04 #define DDB_IO 0x08 #endif ! extern int sbic_inhibit_sync; extern int sbic_no_dma; extern int sbic_clock_override; --- 111,118 ---- #define DDB_FOLLOW 0x04 #define DDB_IO 0x08 #endif ! extern int sbic_cnt; ! extern char sbic_enable_sync[]; extern int sbic_no_dma; extern int sbic_clock_override; From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Aug 19 17:23:18 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: niklas@appli.se (Niklas Hallqvist), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: HW question & sbic sync patch Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Aug 19, 5:25am, Niklas Hallqvist wrote: > First of all, I have a question on how to best handle an amiga > hardware problem: On the A2000 the Z2 space will get cached by > the CPU from what I've heard. Now if one have volatile registers Not quite - the only Z2 space that is cached is Z2 memory. Any non-memory devices that autoconfigure into the Z2 memory area are not going to be in the Memlist structures. And since they are not in the Z2 I/O expansion area, they will never be mapped at all by the kernel. It will require modification to amiga_init.c and the configuration routines to be able to handle this. > How about cachectl? Is it an expensive operation to toggle Cachectl only deals with pushing the data cache and invalidating the caches. Enabling/disabling the cache done by manipulating the CACR to control whether caching is enabled or not, or by manipulating the cache control bit(s) in the MMU pages for a finer control (at a page leve). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 20 00:37:11 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- mycroft Fri Aug 5 15:35:21 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/gen In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/lib/libc/arch/m68k/gen Modified Files: setjmp.S Log Message: Revert this. --------------------------------- mycroft Fri Aug 5 15:40:32 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/arch/m68k Revision/Branch: netbsd-1-0 Modified Files: SYS.h Log Message: update from trunk mycroft Fri Aug 5 15:40:42 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/gen In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/arch/m68k/gen Revision/Branch: netbsd-1-0 Modified Files: setjmp.S Log Message: update from trunk mycroft Fri Aug 5 15:40:59 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/sys In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/arch/m68k/sys Revision/Branch: netbsd-1-0 Modified Files: brk.S cerror.S exect.S ptrace.S sbrk.S sigprocmask.S sigreturn.S sigsuspend.S syscall.S Log Message: update from trunk mycroft Fri Aug 5 15:47:18 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/isa In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/isa Revision/Branch: netbsd-1-0 Modified Files: if_ep.c Log Message: update from trunk mycroft Fri Aug 5 15:48:10 PDT 1994 Update of /b/source/CVS/src/etc/etc.mac68k In directory sun-lamp.cs.berkeley.edu:/usr/src/etc/etc.mac68k Revision/Branch: netbsd-1-0 Modified Files: MAKEDEV ttys Log Message: update from trunk --------------------------------- chopps Fri Aug 5 16:21:37 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/m68k/m68k Modified Files: db_disasm.h Log Message: mama always said to protect those macro args.. --------------------------------- chopps Fri Aug 5 16:34:32 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/tar In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/tar Log Message: Directory /b/source/CVS/src/sys/arch/amiga/floppy/tar added to the repository chopps Fri Aug 5 16:35:00 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/floppy/tar In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/floppy/tar Added Files: Makefile Log Message: use tar for now until problem with pax can be solved. mycroft Fri Aug 5 16:35:50 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/floppy/umount In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/floppy/umount Revision/Branch: netbsd-1-0 Modified Files: umount.c Log Message: update from trunk --------------------------------- mycroft Sun Aug 14 02:24:58 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/isa In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/isa Modified Files: if_ie.c Log Message: Clean up a little. mycroft Sun Aug 14 02:26:16 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/isa In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/isa Revision/Branch: netbsd-1-0 Modified Files: icu.s Log Message: update from trunk (minor) mycroft Sun Aug 14 02:26:47 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/isa In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/isa Revision/Branch: netbsd-1-0 Modified Files: if_ie.c Log Message: update from trunk mycroft Sun Aug 14 02:27:57 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/m68k Revision/Branch: netbsd-1-0 Modified Files: db_disasm.h Log Message: update from trunk (minor) --------------------------------- cgd Mon Aug 15 09:32:43 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/kern Modified Files: sys_process.c Log Message: replace with a completely rewritten version, based around the 4.4BSD procfs. Now the author of the old version will stop complaining that we're using his code. cgd Mon Aug 15 09:37:07 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/i386/i386 Modified Files: process_machdep.c Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:18 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/m68k/m68k Modified Files: process_machdep.c Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/pc532 In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/pc532/pc532 Modified Files: process_machdep.c Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/pmax/pmax In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/pmax/pmax Modified Files: process_machdep.c Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:34 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/sparc In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/sparc/sparc Modified Files: process_machdep.c Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:40 PDT 1994 Update of /b/source/CVS/src/sys/conf In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/conf Modified Files: files files.newconf Log Message: changes for the new sys_process.c, and some cleanup cgd Mon Aug 15 09:37:53 PDT 1994 Update of /b/source/CVS/src/sys/sys In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/sys Modified Files: ptrace.h Log Message: changes for the new sys_process.c, and some cleanup --------------------------------- mycroft Mon Aug 15 09:53:27 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/kern Revision/Branch: netbsd-1-0 Modified Files: sys_process.c Log Message: update from trunk mycroft Mon Aug 15 09:55:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/i386 Revision/Branch: netbsd-1-0 Modified Files: process_machdep.c Log Message: update from trunk mycroft Mon Aug 15 09:55:18 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/m68k Revision/Branch: netbsd-1-0 Modified Files: process_machdep.c Log Message: update from trunk mycroft Mon Aug 15 09:55:23 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/pc532 In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/pc532/pc532 Revision/Branch: netbsd-1-0 Modified Files: process_machdep.c Log Message: update from trunk mycroft Mon Aug 15 09:55:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/pmax/pmax In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/pmax/pmax Revision/Branch: netbsd-1-0 Modified Files: process_machdep.c Log Message: update from trunk mycroft Mon Aug 15 09:55:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/sparc In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/sparc/sparc Revision/Branch: netbsd-1-0 Modified Files: process_machdep.c Log Message: update from trunk mycroft Mon Aug 15 09:56:36 PDT 1994 Update of /b/source/CVS/src/sys/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/conf Revision/Branch: netbsd-1-0 Modified Files: files files.newconf Log Message: update from trunk mycroft Mon Aug 15 09:56:55 PDT 1994 Update of /b/source/CVS/src/sys/sys In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/sys Revision/Branch: netbsd-1-0 Modified Files: ptrace.h Log Message: update from trunk --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 01:16:13 1994 To: jfw@ksr.com (John F. Woods) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: current build process? <9408192024.AA29340@kaos.ksr.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I seem to recall a recent comment that obj/ directories are now passe; is > this correct? Having just ftp'd a recent source tree, should I do "make obj" > before building or not? Actually, i think i'd mentioned that they were annoying, and in the future they'd be completely gone... However, for now, they're they're still around and their use is still encouraged. chris From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 01:22:46 1994 From: mycroft@gnu.ai.mit.edu To: jtc@cygnus.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Profiling weirdness? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone experienced wierdness in gprof output? In the call graph section, it looks like a functions grandchildren are being used as if they were children. If you compile with a high optimization level, GCC will try to turn calls from the end of a function into jumps, thus producing strange profiler output. Are you sure this isn't what you're seeing? From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 01:23:14 1994 From: mycroft@gnu.ai.mit.edu To: jfw@ksr.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: current build process? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I seem to recall a recent comment that obj/ directories are now passe; [...] That is definitely not true. They are not required, but they are recommended. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 01:49:32 1994 From: mycroft@gnu.ai.mit.edu To: vdlinden@fwi.uva.nl, current-users@sun-lamp.cs.berkeley.edu Subject: Re: problem with the joe editor (Solved) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I looks to me like BSD termcap thinks that `cb' is symmetric with `ce', whereas GNU termcap has defined it as something else. The wonderful thing about standards... From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Aug 20 02:02:32 1994 From: Olaf Seibert To: mehlhaff@crl.com, paterno@aguirre.ing.unifi.it Subject: Re: NetBSD 1.0 beta in DBLPAL available Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu "'Most Excellent' Eric Mehlhaff" wrote: > Paternostro Ugo recently wrote: > > >In this week I did a little modify to the kernel: I implemented (well, the > >most of it was just cut and paste...) DBLPAL, and now I'm running NetBSD > >in 720x550 pixels, gaining 120 pixels vs DBLNTSC. I would be glad to > >submiss the patches for the use of the community of NetBSD-ers. Here is the > >problem: how do I submit a change, like this ? > > Did you, by any chance, do anything that using iteconfig or binpatch > (to set the ite_default_height and ite_default_width) to those dimensions > doesn't do? There is rather a difference between the old version of such a display (an interlaced 15 kHz screen) and a DBLPAL one (a noninterlaced 31 kHz screen). I would call the latter a definite improvement. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl Ooey-Gooey-Fluffy-Barfie \X/ I'm not weird, I'm differently percepted. D787B44DFC896063 4CBB95A5BD1DAA96 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 02:03:13 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: majordomo problem Sender: owner-current-users@sun-lamp.cs.berkeley.edu Part of the recent majordomo lossage was that a significant number of people on the current-users list disappeared. I think I've fixed this, but it's possible that some people were added or removed by mistake. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Aug 20 02:08:55 1994 From: "L. Todd Masco" To: amiga@sun-lamp.cs.berkeley.edu Subject: Semaphors Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anybody know why the semaphors are #ifdef KERNEL'd out in ? The shared memory defines are just fine in , but are pretty useless without semaphores. At the moment, I'm simply #define'ing KERNEL before including the files, and the semaphore mechanisms seem to work just fine, at least as reported by ipcs (and ipcrm). I know this isn't the best list for this, but I'm not subscribed to the netbsd proper list, since I'm not doing netbsd kernel development. Thanks, -- Todd, cactus@bb.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 02:21:06 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu [This is a repeat, since some people didn't received the first copy.] sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/bin/sh/main.c U src/gnu/usr.bin/ld/Makefile U src/gnu/usr.bin/tar/tar.1 U src/lib/libm/arch/i387/s_log1p.S U src/libexec/ftpd/Makefile U src/sbin/quotacheck/quotacheck.c U src/sys/arch/hp300/conf/DUALITY U src/sys/arch/hp300/conf/devices.hp300 U src/sys/arch/i386/conf/devices.i386 U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/i386/include/proc.h U src/sys/arch/i386/isa/pccons.c U src/sys/arch/pmax/dev/if_le.c U src/sys/arch/pmax/pmax/machdep.c U src/sys/arch/sparc/conf/GENERIC.sparc U src/sys/arch/sparc/include/pmap.h U src/sys/arch/vax/README U src/sys/arch/vax/conf/Makefile.vax U src/sys/arch/vax/conf/files.vax.newconf U src/sys/arch/vax/include/exec.h U src/sys/arch/vax/include/param.h U src/sys/arch/vax/include/pmap.h U src/sys/arch/vax/include/vmparam.h U src/sys/arch/vax/vax/conf.c U src/sys/arch/vax/vax/gencons.c U src/sys/arch/vax/vax/intvec.s U src/sys/arch/vax/vax/locon.s U src/sys/arch/vax/vax/locore.s U src/sys/arch/vax/vax/machdep.c U src/sys/arch/vax/vax/pmap.c U src/sys/arch/vax/vax/skit.c U src/sys/arch/vax/vax/trap.c U src/sys/arch/vax/vax/vm_machdep.c cvs checkout: exec.h is no longer in the repository U src/sys/compat/svr4/makesyscalls.sh U src/sys/compat/svr4/svr4_exec.c U src/sys/compat/svr4/svr4_exec.h U src/sys/compat/svr4/svr4_syscalls.c U src/sys/isofs/cd9660/cd9660_util.c U src/sys/isofs/cd9660/cd9660_vnops.c U src/sys/kern/exec_conf.c U src/sys/kern/exec_ecoff.c U src/sys/kern/kern_descrip.c U src/sys/kern/vfs_syscalls.c U src/sys/miscfs/fdesc/fdesc.h U src/sys/miscfs/fdesc/fdesc_vnops.c U src/sys/miscfs/nullfs/null.h U src/sys/miscfs/nullfs/null_subr.c U src/sys/miscfs/nullfs/null_vnops.c U src/sys/miscfs/umapfs/umap.h U src/sys/miscfs/umapfs/umap_subr.c U src/sys/miscfs/umapfs/umap_vnops.c U src/sys/nfs/nfs.h U src/sys/nfs/nfs_node.c U src/sys/nfs/nfs_nqlease.c U src/sys/nfs/nfs_socket.c U src/sys/nfs/nfs_srvcache.c U src/sys/nfs/nfs_subs.c U src/sys/nfs/nfs_syscalls.c U src/sys/nfs/nfs_vfsops.c U src/sys/nfs/nfsmount.h U src/sys/nfs/nfsnode.h U src/sys/nfs/nfsrvcache.h U src/sys/nfs/nqnfs.h U src/sys/sys/exec.h U src/sys/sys/proc.h U src/usr.bin/passwd/yp_passwd.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Fri Aug 19 05:45:12 1994 SUP Scan for current completed at Fri Aug 19 05:47:34 1994 SUP Scan for mirror starting at Fri Aug 19 05:47:34 1994 SUP Scan for mirror completed at Fri Aug 19 05:49:41 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 02:36:12 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Profiling weirdness? From: "J.T. Conklin" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone experienced wierdness in gprof output? In the call graph section, it looks like a functions grandchildren are being used as if they were children. For example, the CVS function find_dirs calls opendir, readdir and closedir as it iterates through a directory. But the profile call graph also shows entries for "open", "getdirents", and "close" which aren't called by find_dirs at all. Unfortunately I forgot to upload sample profile output from my machine at home before I left for work. But here's a CVS profile I did on SunOS that I've doctored so it is clear exactly what I mean. 0.00 0.70 86/86 Find_Dirs [24] [25] 8.1 0.00 0.70 86 find_dirs [25] 0.01 0.44 964/1291 isdir [33] 0.00 0.11 86/251 opendir [40] X.XX X.XX XX/XXX getdirents [XX] X.XX X.XX X/XXX open [XX] 0.01 0.03 42/1460 freenode [111] 0.00 0.04 1758/4886 readdir [60] 0.00 0.02 964/2280 sprintf [80] 0.01 0.00 1467/2980 fnmatch [99] 0.00 0.01 86/251 closedir [101] X.XX X.XX XX/XXX close [XXX] ... I'm running an intel box, but the problem may be generic. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 02:40:16 1994 From: jfw@ksr.com (John F. Woods) To: current-users@sun-lamp.cs.berkeley.edu Subject: current build process? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I seem to recall a recent comment that obj/ directories are now passe; is this correct? Having just ftp'd a recent source tree, should I do "make obj" before building or not? From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 20 10:26:55 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: sz/rz From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu has anyone ported the old sz/rz programs to NetBSD? i've got sz partially working, but rz is very confused. zmodem does not quite comprehend of quad off_t in general, it seems. if anyone has a working port, let me know. if noone does, then i will keep working on what i have. (i'm using version 3.14, the latest i could find.) -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 02:49:08 1994 From: niklas@appli.se (Niklas Hallqvist) To: osymh@gemini.oscs.montana.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: HW question & sbic sync patch Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Michael" == Michael L Hitch writes: Michael> On Aug 19, 5:25am, Niklas Hallqvist wrote: >> First of all, I have a question on how to best handle an amiga >> hardware problem: On the A2000 the Z2 space will get cached by the >> CPU from what I've heard. Now if one have volatile registers Michael> Not quite - the only Z2 space that is cached is Z2 memory. Michael> Any non-memory devices that autoconfigure into the Z2 memory Michael> area are not going to be in the Memlist structures. And Michael> since they are not in the Z2 I/O expansion area, they will Michael> never be mapped at all by the kernel. It will require Michael> modification to amiga_init.c and the configuration routines Michael> to be able to handle this. I've already done this. My GoldenGate II now gets mapped by the NetBSD autoconfig much like the Zorro 3 cards or I/O-space Zorro 2 dittos. >> How about cachectl? Is it an expensive operation to toggle Michael> Cachectl only deals with pushing the data cache and Michael> invalidating the caches. Enabling/disabling the cache done Michael> by manipulating the CACR to control whether caching is Michael> enabled or not, or by manipulating the cache control bit(s) Michael> in the MMU pages for a finer control (at a page leve). I have no reference on any m68k MMU. Could you help me out, describing what needs to be done for 68551, 68030 & 68040, respectively. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 02:53:17 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Problems 1.0b and Ethernet Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Have problems with NetbSd and Ethernet with recent kernel... Can anyone send me correct options for Kernel-Config-File to implement IP and TCP/IP correctly. The problems seems to be that instead of using IP-NUmbers in the network stack, the kernel uses Hardware Number of the Ethernet-Card. Config currently is A2000, A2065, A2630. My own kernel does recognize the A2000 as A1200 but the system is coming up fine, le0 is found and configured - but TCP/IP does not work at all. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 21 02:56:27 1994 X-Mailer: DUUCPv1.17b X-Reader: GRn2.0k From: barnhill@zinder.do.open.de (Larry Barnhill) To: owner-amiga@sun-lamp.cs.berkeley.edu Cc: hikita@trl.mei.co.jp, osymh@gemini.oscs.montana.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Solved: netbsd-940620 panics on A3000... Sender: owner-amiga@sun-lamp.cs.berkeley.edu :On Tue, 5 Jul 1994, Markus Illenseer wrote: : :> Date: Tue, 5 Jul 1994 23:10:10 EDT :> From: Markus Illenseer :> To: Hiroyuki Hikita , :> "Michael L. Hitch" , :> amiga@sun-lamp.cs.berkeley.edu :> Subject: Re: Solved: netbsd-940620 panics on A3000... :> :> On Jul 5, 8:42pm, Hiroyuki Hikita wrote: :> > Subject: Solved: netbsd-940620 panics on A3000... :> > :> > Thank's for all the replies. I checked out everything again today. :> > I took out the A2065 board and netbsd-940620 booted like a charm. \(^-^)/ :> > My apologies for all the trouble I stirred up. :> :> Don't remove it, just don't initialise (ifconfig) it on the ADos-Side :> before booting. : : Aghhhhh! : : Can we not just establish the A2065 as a fact! : : I will be more than happy to take and to count a vote here, as I am :certain that it is at least %30 of the people that I have seen on this ----------much deleted----- : : As for the vote on ethernet support in the kernel, just send a message :stating "yes" or "no" and I will be glad to tabulate the outcome. : --------YES-------- : : : TEZCAT.COM (pronounced: Tezzzz Cat Dot Com) : Offering low cost dial-up internet connectivity in Chicago. : For information about our service, mail or finger info@tezcat.com : Data: 312-850-0112 (located in Wicker Park) Vox: 312-850-0181 : Free Access to our BBS system via Telnet to "smirror.tezcat.com" : ---- barnhill@zinder.do.open.de ( L. Barnhill ) From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 03:49:04 1994 Subject: Re: sz/rz To: downsj@CSOS.ORST.EDU (jason downs) From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1123 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > has anyone ported the old sz/rz programs to NetBSD? > > i've got sz partially working, but rz is very confused. zmodem does not > quite comprehend of quad off_t in general, it seems. I have rz 3.10 and sz 3.16 working. "make bsd" worked out of the box as far as I remember. The off_t changes don't affect it, because all file io is done with fopen() and friends. A slightly hacked version which supports "make posix" is on ftp.owl.de:/pub/unix-connect. This version gives nice status display when called as "rz -vv" from Seyon [or cu], but I somehow broke it: it doesn't work when you dial in via modem and try to download a file from the NetBSD box. I didn't care to fix this (yet), because my NetBSD box doesn't have dial up access. If you diff it against the original version, you could easily separate the posix hacks from the [broken] cosmetic changes. Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 04:54:37 1994 From: "L. Todd Masco" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: NetBSD inconsistencies and odditites Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Okay, now that sun-lamp seems to be okay... I've been hacking around a lot these last few days, using various IPC techniques... and NetBSD is not pretty from this perspective, especially on the man page/functionality synchronization level. Got a list: - First of all, as I've mentioned before, there's the System V-style ipc (semaphores, shared memory via shmat()) that seems to be somewhat supported (IE, my programs run properly when I #define KERNEL) are #ifdef KERNEL'd out. ipcs and ipcrm work properly. - MAP_FILE is referenced in the man page for mmap(2), but is not defined anywhere (certainly not in the headers referred to by the man page). The man page says an EINVAL will be delivered if this parameter is not set, but luckily that doesn't seem to be the case. The man page for mmap is the only place I've ever seen this parameter specified. - F_SETLK, etc, (the record-locking features of fcntl(2)) appear in the header but not in the man page. Is record-locking supported or not? According to Stevens[1], everything after the initial release of BSD4.3 (Reno and later) is supposed to support this. [1] Stevens, W. Richard: Advanced Programming in the UNIX(r) Environment, 5th printing, p. 367, Addison Wesley. -- L. Todd Masco | "Cowboy politicians sucking up to the aristocracy, not cactus@bb.com | even sure if they like democracy..." - TR-I From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 04:59:22 1994 Subject: Re: NetBSD inconsistencies and odditites From: Tim Newsham To: cactus@bibliob.slip.netcom.com (L. Todd Masco) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > - MAP_FILE is referenced in the man page for mmap(2), but is not defined > anywhere (certainly not in the headers referred to by the man page). > The man page says an EINVAL will be delivered if this parameter > is not set, but luckily that doesn't seem to be the case. The man > page for mmap is the only place I've ever seen this parameter > specified. > > -- > L. Todd Masco | "Cowboy politicians sucking up to the aristocracy, not > cactus@bb.com | even sure if they like democracy..." - TR-I glad you brought this up. I forgot about this one. The MAP_FILE define was in my last system (#744) but seems to have disapeared by 1.0beta. Is there a reason for this? I have a program that mmap's /dev/viewXX and I'm not sure what I should be doing now that MAP_FILE is gone. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 05:14:44 1994 From: Andrew Cherry To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Newer kernels and system lockups Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu A while back, I reported having problems with random system lockups, seemingly related to disk activity. I still have such problems; I'm using the current kernel compiled from sun-lamp sources. I have some more information that may (or may not!) be useful. I found that the lockups, though mostly occurring at random times, occur more frequently while accessing my adosfs partitions. More specifically, I have been able to consistently get the lockups to happen by running zip (an Infocom interpreter) on an infocom data file on an ados partition. (Just because I'm using NetBSD doesn't mean I have to give up Infocom games :) ). Anyway, I usually work in X, but I tried it once from the console instead, and got a kernel panic. (Apparently, this appears as a simple lockup when working within X, since the console is not directly accessible). The panic was caused by: trap: bad kernel access at 10 trap type 8, code 485, v=10 pid=214, etc etc etc.. Here is the result from a trace: db> trace _Debugger(20cec,b3c6d,fffffe98,8,fffffc9c) + 6 _panic(b3c6d,0,fffffe98,8,fffffc96) + 6 _panictrap(8,485,10,fffffd3c,b3f57,10) + 60 _trapmmufault(8,485,10,fffffd3c,b3f57,10) + 60 _trap(8,485,10) + 350 _addrerr(?) _brelse(0,0,200,200,0) + e0 _adosfs_bmap(fffffe1c) + 18e _adosfs_strategy(fffffe48) + 78 _bread(563300,0,200,ffffffff,fffffe94) + 7a _adosfs_read(fffffecc,3,1,dc,206dd4a) + e0 _vn_read(5bed80,ffffff24,5c8b80) + 98 _read(5cae00,ffffff84,ffffff7c) + a2 _syscall(3) + 138 _trap0() + e Hope I read my handwriting correctly. :) Sorry that I haven't given a more standard way of reproducing the error, but the Infocom interpreter is the only thing I have tried that consistently causes a panic (but only when accessing the ados partitions; if I copy the data file over to a BSD partition and work from there, things work fine. Much faster too, of course.) I don't know if this is related to the other crashes I've reported; most of them have occurred when working on NetBSD partitions, primarily when writing (most of those crashes seem to occur when emacs is autosaving). At any rate, it's certainly something that ought to be looked into. The other system lockups I've had during disk accesses are probably also producing kernel panics that are not visible due to the X server running. But aside from the above, I have had no success at forcing crashes at the console. They never happen when you *want* them to, of course. My setup: A2000, 1MB CHIP G-Force 68040, 12MB 32-bit RAM, Series II SCSI Seagate ST31200N 1 gig SCSI-2 drive Archive Viper 2525S Oh, and the Viper is a recent addition; I've had the crashes before I got the Viper. (In fact, the crashes were the motivation to buy a tape drive :) ). -Andrew Cherry (crunk@planet.net) From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 05:53:58 1994 To: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: sz/rz From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message , "Martin Husemann" writes: >> has anyone ported the old sz/rz programs to NetBSD? >> >> i've got sz partially working, but rz is very confused. zmodem does not >> quite comprehend of quad off_t in general, it seems. > >I have rz 3.10 and sz 3.16 working. "make bsd" worked out of the >box as far as I remember. The off_t changes don't affect it, because >all file io is done with fopen() and friends. only on the i386. there are more problems for big endian machines. i will post diffs when i have some reliable software running. i also took the approach of porting it to termios. the problems i'm seeing are off_t related. the zmodem protocol itself cannot deal with 64bit offsets, and i don't know enough about it to repair the software, in order to 'talk' 32bit offsets and handle 64bit ones interally. the NetBSD box is an hp300. the test case i've been using for talking to it is an Amiga running AmigaDOS and JR-Comm. (you'll find no intel boxen anywhere near me, no.) >A slightly hacked version which supports "make posix" is on >ftp.owl.de:/pub/unix-connect. This version gives nice status >display when called as "rz -vv" from Seyon [or cu], but I somehow broke >it: it doesn't work when you dial in via modem and try to download a file >from the NetBSD box. > >I didn't care to fix this (yet), because my NetBSD box doesn't have dial up >access. If you diff it against the original version, you could easily separate >the posix hacks from the [broken] cosmetic changes. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 10:12:23 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Changes to com.c for bidirectional use From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu Changes to com.c (from Aug 1) for bidirectional use are appended at the end of this message. Here is a quick sketch of why, what and how. One caveat: the code has been tested only on one machine. Use at your own risk etc. If you find any bugs please let me know. --Bakul Shah WHY: The goal is to allow the use of a serial line for outgoing calls (for cu, kermit etc.) as well as for incoming calls (i.e. for logging in). In such a use typically the init blocks in open() of an incoming device. When an incoming call raises the carrier, open() completes and getty is execed. We would like to callout over the same line if there is no incoming call. While our outgoing call is active, we do not want getty to get activated and while getty/login/shell are active we do not want an outgoing call to succeed. The bidirectional use changes make this possible. The advantage of a kernel based solution is that the window in which incoming calls are not recognized is much smaller; in fact someone is *always* `tending' the line. The disadvantage is that every serial driver has to be changed to affect this functionality. This and some other bits from many serial drivers are good candidates for factoring out. WHAT: Outgoing lines are named /dev/cua00, /dev/cua01... Incoming lines are named /dev/tty00, /dev/tty01... If minor number of /dev/ttyXX is M, minor number of the correspoding /dev/cuaXX is M+128. First, note that the new behavior can be completely disregarded if you don't plan to use /dev/cuaXX. In fact, *while a cuaXX line is not in use*, behavior of the new driver is identical to that of the old driver. New behavior: 1. ttyXX and cuaXX are mutually exclusive devices. 2. cuaXX may also be opened while a ttyXX open() call is blocked, waiting for a carrier detect. 3. When cuaXX is opened, the CLOCAL flag is set. This prevents a carrier drop from sending the process a SIGUP signal. 4. While cuaXX is active, any ttyXX open() remains blocked. 5. ttyXX open() goes back to waiting on carrier detect once the last cuaXX close is done. 6. The last close on either cuaXX or ttyXX drops DTR if the SOFTCARR flag is not set. 7. The last close on cuaXX raises DTR after a second if there is a blocked ttyXX open. Dropping DTR for a second allows a connected modem to hangup and reset to defaults and then go back to answering calls. The effect is as if the intervening use of cuaXX had never happened. 8. Any number of concurrent open()s may succeed on either ttyXX (as before) or cuaXX provided the TS_XCLUDE flag is not set and subject to # 1 above. HOW: *** com.c-save Mon Aug 1 13:13:56 1994 --- com.c Sat Aug 20 16:52:52 1994 *************** *** 77,82 **** --- 77,85 ---- #define COM_SW_CLOCAL 0x02 #define COM_SW_CRTSCTS 0x04 #define COM_SW_MDMBUF 0x08 + #define COM_SW_OUTGOING 0x10 + #define COM_SW_INCOMING 0x20 + #define COM_SW_WAIT 0x40 u_char sc_msr, sc_mcr; }; /* XXXX should be in com_softc, but not ready for that yet */ *************** *** 110,116 **** extern int kgdb_debug_init; #endif ! #define COMUNIT(x) (minor(x)) #define bis(c, b) do { const register u_short com_ad = (c); \ outb(com_ad, inb(com_ad) | (b)); } while(0) --- 113,122 ---- extern int kgdb_debug_init; #endif ! #define COMUNIT(x) (minor(x) & ~0x80) ! #define OUTGOING(x) ((x) & 0x80) ! #define IS_OUTGOING(sc) ((sc)->sc_swflags & COM_SW_OUTGOING) ! #define IS_INCOMING(sc) ((sc)->sc_swflags & COM_SW_INCOMING) #define bis(c, b) do { const register u_short com_ad = (c); \ outb(com_ad, inb(com_ad) | (b)); } while(0) *************** *** 320,339 **** return EBUSY; } ! /* wait for carrier if necessary */ ! if ((flag & O_NONBLOCK) == 0) ! while ((tp->t_cflag & CLOCAL) == 0 && ! (tp->t_state & TS_CARR_ON) == 0) { ! tp->t_state |= TS_WOPEN; ! error = ttysleep(tp, (caddr_t)&tp->t_rawq, ! TTIPRI | PCATCH, ttopen, 0); ! if (error) { ! /* XXX should turn off chip if we're the ! only waiter */ ! splx(s); ! return error; ! } } splx(s); return (*linesw[tp->t_line].l_open)(dev, tp); --- 326,373 ---- return EBUSY; } ! if (OUTGOING(dev)) { ! /* outgoing open may succeed only if incoming open has not */ ! if (IS_INCOMING(sc)) { ! splx(s); ! return EBUSY; ! } ! tp->t_cflag |= CLOCAL; ! sc->sc_swflags |= COM_SW_OUTGOING; ! ! /* wakeup the blocked incoming open to go sleep elsewhere */ ! if (sc->sc_swflags & COM_SW_WAIT && tp->t_state & TS_WOPEN) ! wakeup((caddr_t)&tp->t_rawq); ! } else { ! /* incoming open may succeed only if outgoing open has not */ ! if (IS_OUTGOING(sc)) { ! splx(s); ! return EBUSY; } + + /* wait for carrier if necessary */ + if ((flag & O_NONBLOCK) == 0) + while ((tp->t_cflag & CLOCAL) == 0 && + (tp->t_state & TS_CARR_ON) == 0) { + tp->t_state |= TS_WOPEN; + sc->sc_swflags |= COM_SW_WAIT; + error = ttysleep(tp, (caddr_t)&tp->t_rawq, + TTIPRI | PCATCH, ttopen, 0); + if (error) { + /* XXX should turn off chip if we're the + only waiter */ + splx(s); + return error; + } + /* wait elsewhere if outgoing open is active */ + while (IS_OUTGOING(sc)) { + (void)ttysleep(tp, + (caddr_t)&sc->sc_swflags, + TTIPRI | PCATCH, ttopen, 0); + } + } + sc->sc_swflags |= COM_SW_INCOMING; + } splx(s); return (*linesw[tp->t_line].l_open)(dev, tp); *************** *** 358,367 **** { bic(iobase + com_cfcr, CFCR_SBREAK); outb(iobase + com_ier, 0); if (tp->t_cflag & HUPCL && ! (sc->sc_swflags & COM_SW_SOFTCAR) == 0) /* XXX perhaps only clear DTR */ outb(iobase + com_mcr, 0); } ttyclose(tp); #ifdef notyet /* XXXX */ --- 392,420 ---- { bic(iobase + com_cfcr, CFCR_SBREAK); outb(iobase + com_ier, 0); + if (tp->t_cflag & HUPCL && ! (sc->sc_swflags & COM_SW_SOFTCAR) == 0) /* XXX perhaps only clear DTR */ outb(iobase + com_mcr, 0); + + if (OUTGOING(dev)) { + /* drop DTR regardless of other flags */ + outb(iobase + com_mcr, sc->sc_mcr &~ MCR_DTR); + sc->sc_swflags &= ~COM_SW_OUTGOING; + if (sc->sc_swflags & COM_SW_WAIT) { + /* wait a while before allowing incoming open */ + (void)tsleep((caddr_t)&sc->sc_swflags+1, + TTIPRI | PCATCH, "comclose", hz); + /* setup for the waiting incoming open...*/ + tp->t_cflag &= ~(MDMBUF|CLOCAL); + tp->t_state &= ~TS_ISOPEN; + sc->sc_mcr = MCR_DTR | MCR_RTS; + outb(iobase + com_mcr, sc->sc_mcr); + return 0; + } + } else + sc->sc_swflags &= ~COM_SW_INCOMING; } ttyclose(tp); #ifdef notyet /* XXXX */ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 14:33:50 1994 From: niklas@appli.se (Niklas Hallqvist) To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: HW question & sbic sync patch Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Tim" == Tim Newsham writes: >> >> How about cachectl? Is it an expensive operation to toggle >> Michael> Cachectl only deals with pushing the data cache and Michael> invalidating the caches. Enabling/disabling the cache done Michael> by manipulating the CACR to control whether caching is Michael> enabled or not, or by manipulating the cache control bit(s) Michael> in the MMU pages for a finer control (at a page leve). >> I have no reference on any m68k MMU. Could you help me out, >> describing what needs to be done for 68551, 68030 & 68040, >> respectively. >> >> Niklas Tim> on the 030 (which is supposed to be a subset of the 68551 I Tim> think) you just set the "Cache Inhibit" bit in page table entry Tim> for the page in question. You can also set the Cache Inhibit in Tim> any higher level tables to refer to all the pages under that Tim> entry. The bit is PG_CI in the amiga/include/pte.h file. Tim> (hmm.. the include only has defines for PG_CI and not SG_CI so Tim> maybe the segment tables dont have a CI bit). Great, now I just go to my code and add that bit... Hmm, it's already there, has someone cracked into my NetBSD system and added this code or is my subconsious mind much smarter than me? Nah, as always it was MLH who beat me to the punch, by using that bit in the Z3 support that I copied. Thanks Michael & Tim. I'm now close to having a bridgecard framework together with a GoldenGateII lower layer as well as the isa com driver ready. In order for you to taste how it's used in a config file, look at this: ggbus0 at ztwobus0 isabus0 at ggbus0 com0 at isabus0 port 0x3f8 irq 4 com1 at isabus0 port 0x2f8 irq 3 Neat, no? If we are lucky other bridgecards will have drivers written to this framework, imagine the CrossLink: clbus0 at ztwobus0 isabus0 at clbus0 then use the same device drivers as you would use for the GoldenGate. For those of you with intelligent bridges like the A2386 and such, you ought to be able to write some communication protocol in a likewise bridge independent way, so it would work as an intelligent isa-bus adapter fitting this framework. However, you have to do that yourself, I'm not up to it for the moment. I have good hopes to have the ed ethernet driver ported soon as well as there is already a volunteer willing to help out. Are there other volunteers for beta-testing and device driver porting? Contact me. Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 19:30:18 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Re: NetBSD inconsistencies and odditites To: cactus@bibliob.slip.netcom.com (L. Todd Masco) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 453 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > - MAP_FILE is referenced in the man page for mmap(2), but is not defined > anywhere (certainly not in the headers referred to by the man page). > The man page says an EINVAL will be delivered if this parameter > is not set, but luckily that doesn't seem to be the case. The man > page for mmap is the only place I've ever seen this parameter > specified. > This IS in my /usr/include/sys/mman.h file, update to a newer source tree... -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 21:03:42 1994 From: niklas@appli.se (Niklas Hallqvist) To: current-users@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: comprobe and a GoldeGateII attached ISA bus Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm porting the i386/isa/com.c driver t owork with a GoldenGateII (which is a card for Amigas wich connect the Zorro2 bus with the ISA bus also found in some amigas). In the comprobe1 routine, there is a inb() call reading the com_iir ioport. Evidently, if there isn't a com port there, that inb() should return non-zero. My problem is that such uses of inb() to non-existant ports returns just that, ZERO. Now, I know nothing of the 8250/16450/16550 ICs at all. Considering I can't change my HW: are there any other good ways to probe for these UARTs? For the moment I just check if I get a non-zero value and if so I say it's a COM port there. I get 0x01 returned from the inb() call if there *is* a COM port there and 0x00 otherwise. General question: Does the ISA spec (if there is such a spec) require the data lines to float to ones if there isn't HW available responding to these inb requests? 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 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 21:11:31 1994 From: mycroft@gnu.ai.mit.edu To: niklas@appli.se Cc: current-users@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: comprobe and a GoldeGateII attached ISA bus Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Actually, the com probe sequence is a bit braindead. It would be better to tickle the chip and see if it interrupts. I'm not sure if there's a general way to do that without outputting a byte, though. (Loopback mode doesn't work on some clones.) From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 21 21:49:04 1994 From: jkoob@wish.swb.de (Jochen Koob) To: amiga@sun-lamp.cs.berkeley.edu Subject: NetBSD & Retina Bootproblem Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all, my problem is, that each time I want to boot into multiuser mode I get the error message 'getty: /dev/ttye1: Device not configured' instead of the normal login prompt. If I remove my Retina Z3 from the system, so that ECS is used everything works fine. I can even boot into single user mode (with the Retina installed) and start the getty program manually (with /usr/libexec/getty Pc) and I end up at the login prompt ! That means I only have problems if I try to boot directly into multiuser mode with the '-a' option of loadbsd. But why ?? Here's the output NetBSD generates during multiuser boot: NetBSD 1.0 BETA (Generic) #0: Sat Aug 13 .... 10 views configured Automatic boot in progress: starting file system checks. /dev/rsd0a: 721 files, 7090 used, 8661 free (21 frags, 1030 blocks, 0.1% fragmentation) /dev/rsd0h: 2881 files, 40355 used, 95260 free (1316 frags, 11743 blocks, 0.0% fragmentation) ados: stat /amiga: No such file or directory setting tty flags ttyflags: open /dev/ttye1: Device not configured starting network add host myname.my.domain: gateway localhost starting rpc daemons: portmap. starting system logger, time daemontimed: no network usable checking for core dump ... savecore: no core dump checking quotas: done. building databases ... clearing /tmp standard daemons: update cron. starting network daemons: routed printed inetd. starting local daemons: . runtime link editor directory cache Fri Aug 19 17:39:34 PDT 1994 Aug 19 17:39:34 myname init: kernel security level changed from 0 to 1 Aug 19 17:39:34 myname getty: /dev/ttye1: Device not configured My configuration: A3000/25 8F/2C MB RAM Retina Z3 1.0 pre_release binaries (installed with bootdisk, no update) netbsd 1.0 beta kernel (Aug 13) Bye, Jochen -- Jochen Koob | | A seminar on time travel Bensheim, Germany | UUCP:jkoob@wish.swb.de | will be held two weeks ago From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 21:51:14 1994 Subject: Diskless booting from SMC boot ROM To: current-users@sun-lamp.cs.berkeley.edu From: "Martin Husemann" Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 516 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm going to setup a diskless box. This seems to be easy when I boot the kernel from floppy, but I would prefer to get it via tftp straight from the SMC 8013 EP boot rom. This box doesn't even have a floppy... Does such a ROM exist and where can I find it? Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 22:05:33 1994 From: niklas@appli.se (Niklas Hallqvist) To: current-users@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: comprobe and a GoldeGateII attached ISA bus Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm porting the i386/isa/com.c driver t owork with a GoldenGateII (which is a card for Amigas wich connect the Zorro2 bus with the ISA bus also found in some amigas). In the comprobe1 routine, there is a inb() call reading the com_iir ioport. Evidently, if there isn't a com port there, that inb() should return non-zero. My problem is that such uses of inb() to non-existant ports returns just that, ZERO. Now, I know nothing of the 8250/16450/16550 ICs at all. Considering I can't change my HW: are there any other good ways to probe for these UARTs? For the moment I just check if I get a non-zero value and if so I say it's a COM port there. I get 0x01 returned from the inb() call if there *is* a COM port there and 0x00 otherwise. General question: Does the ISA spec (if there is such a spec) require the data lines to float to ones if there isn't HW available responding to these inb requests? 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 From owner-current-users@sun-lamp.cs.berkeley.edu Sun Aug 21 22:21:32 1994 From: mycroft@gnu.ai.mit.edu To: niklas@appli.se Cc: current-users@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: comprobe and a GoldeGateII attached ISA bus Sender: owner-current-users@sun-lamp.cs.berkeley.edu Actually, the com probe sequence is a bit braindead. It would be better to tickle the chip and see if it interrupts. I'm not sure if there's a general way to do that without outputting a byte, though. (Loopback mode doesn't work on some clones.) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Aug 21 23:12:13 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: NetBSD inconsistencies and odditites Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <199408210223.WAA03561@bb.com> "L. Todd Masco" writes: > > - MAP_FILE is referenced in the man page for mmap(2), but is not defined > anywhere (certainly not in the headers referred to by the man page). > The man page says an EINVAL will be delivered if this parameter > is not set, but luckily that doesn't seem to be the case. The man > page for mmap is the only place I've ever seen this parameter > specified. It was removed (except from the man page) and made the default if no other value is specified, but has since been added back for backwards compatibility (#defined to 0). It was added back some time ago, so it sounds like you're running an old system. > - F_SETLK, etc, (the record-locking features of fcntl(2)) appear in > the header but not in the man page. Is record-locking > supported or not? According to Stevens[1], everything after the initial > release of BSD4.3 (Reno and later) is supposed to support this. If you check the source, it's implemented. It's just not documented in the man page. -- Ty Sarna "You can lead a gift horse to water but tsarna@endicor.com you can't make him look you in the mouth" From owner-amiga@sun-lamp.cs.berkeley.edu Sun Aug 21 23:33:14 1994 From: Jason Ozolins To: amiga@sun-lamp.cs.berkeley.edu Subject: request for A2065 jumper info Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all, Sorry to clog this list up with something that would be better off posted to news, but our posting software seems to be too flakey. Anyway, I have obtained an A2065 Ethernet board without any kind of manual. As lack of info is the only thing preventing me from getting my Amiga networking under NetBSD, I was wondering if some kind soul could mail me some info about the jumper blocks and their default settings. Any suggestions as to obtaining a manual would also be welcomed. Thanks in advance, Jason jasonoz@cairo.anu.edu.au From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 00:34:14 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: client YP development From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu we've been working on developing some of the missing pieces of the YP client code, here at ORST. from some of the recent patches that have flown across some of the NetBSD mailing lists, it would appear that others are doing likewise. since it would be beneficial to all if we didn't reinvent each others wheels (in addition to Suns), and didn't implement things in incompatible ways, we think that everyone should pool their resources and at least communicate with one another on a direct basis. if this seems like a good idea, and you're working on YP client code, please reply to this email directly. it would also be good to hear from who, exactly, is working on server code. thanks. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 04:04:06 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: 3c509/Ultrastor 14f performance issues? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1119 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a 486DX/33 with a Ultrastor 14f and a 3com 3c509. There seems to be a performance problem if they are both 'active.' i.e. iozone says ~310K to the local drive (a Micropolis 1588) which seems kind of slow, but is better than the ~20K I get via nfs/ftp/etc.. The other machine is a 486DX2/66 with IDE and a 3c509. It seems to be fine. >From the 66 (to the 33) a 'get' transfers at ~320K/s, while a 'put' transfers at ~16K/s. >From the 66, a 'get junk /dev/null' transfers at ~342K, while a 'get junk' transfers at ~25K. I noticed that when doing the ftp get from the 66, the drive light on the 33 is pretty much solid, while during the ftp put the light hardly flashes, is this a problem, or is the data simply being cached? Anyway, this is a friend's controller and drive that I've installed NetBSD v1.0beta on. If this is typical, I need to know! Otherwise does anyone have any ideas why it would be so slow? I thought somebody (mycroft?) had mentioned not running a 3c509 with an IDE, but that seems to work fine.. it's the Ultrastor that's a problem. (I think!) Any help would be appreciated! -Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 04:14:05 1994 From: Steven Mastandrea To: current-users@sun-lamp.cs.berkeley.edu, darrenr@vitruvius.arbld.unimelb.EDU.AU Subject: Re: current/sparc: problems with disk. Sender: owner-current-users@sun-lamp.cs.berkeley.edu could somebody please tell me how to get off this mailing list please? thank-you .r .sig smastand@uiuc.edu From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 04:53:09 1994 To: gillham@andrews.edu (Andrew Gillham) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 3c509/Ultrastor 14f performance issues? <9408220040.AA20049@edmund> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu [ warning, i'm not a statistician, i just play one on the net... ] > I have a 486DX/33 with a Ultrastor 14f and a 3com 3c509. > There seems to be a performance problem if they are both > 'active.' i.e. iozone says ~310K to the local drive > (a Micropolis 1588) which seems kind of slow, but is better > than the ~20K I get via nfs/ftp/etc.. The other machine is > a 486DX2/66 with IDE and a 3c509. It seems to be fine. OK, i seem to have a grasp of your hardware. host X Y speed 33 66 enet 509 509 disk 14f IDE however, i'm unclear what you mean: > >From the 66 (to the 33) a 'get' transfers at ~320K/s, while > a 'put' transfers at ~16K/s. how are these measured? Y % ftp X then 'get file'? 'get file /dev/null'? Y % ftp X then 'put file'? 'put file /dev/null'? did you try them one immediately following the other? or perhaps multiple times each? > >From the 66, a 'get junk /dev/null' transfers at ~342K, while > a 'get junk' transfers at ~25K. i.e. 'B % ftp A' then 'get junk /dev/null' and 'get junk'? If that's what you mean, it would seem that writing the file to the (IDE) disk is cutting your throughput by a factor of 10... unfortunately, for either, i'm not sure what you mean by "from the/to the". > I noticed that when doing the ftp get from the 66, the drive > light on the 33 is pretty much solid, while during the ftp put > the light hardly flashes, is this a problem, or is the data > simply being cached? it could be the buffer cache. could you do the following: on X: cat /*bin/* > /dev/null ftp Y then 'put file_to_put' (A) ftp Y then 'put file_to_put' (B) cat /*bin/* > /dev/null ftp Y then 'put file_to_put /dev/null' (C) ftp Y then 'put file_to_put /dev/null' (D) rsh Y cat /*bin/* > /dev/null ftp Y then 'get file_to_get' (E) ftp Y then 'get file_to_get' (F) rsh Y cat /*bin/* > /dev/null ftp Y then 'get file_to_get /dev/null' (G) ftp Y then 'get file_to_get /dev/null' (H) do the mirror set of steps on B, after running 'cat /*bin/* > /dev/null' on each box, to clean out the buffer cache. you should pick file_to_get and file_to_put such that: (1) both fit into the buffer cache completely, and (2) neither are in /bin or /sbin of either machine. That set of tests should give you some indication of what's up. more or less: if throughput increases dramatically from (C) to (D), then the machine you're ftp'ing from is having problems when using the disk and ethernet simultaneously. if throughput increases dramatically from (G) to (H), then the machine you're ftp'ing _to_ is having problems when using the disk and ethernet simultaneously. if only one of the machines is having problems A/B (i.e. the ratio of the throughput from test (A) to the ratio of throughput from test (B)) should be approximately equal (or at least comparable to) to C/D, and E/F should be approximately equal to (or at least comparable to) G/H. What i mean is that if A = 20k/s and B = 200k/s, C and D might be, say, 20-40k/s and 200-400k/s, give or take. basically, check the 'sanity' of the results... To make it a more realistic test, you might want to use an MFS file rather than /dev/null in C, D, G, and H, because then the normal buffer cache actions will be taken when writing the file. note that in a perfect world, A should be <= B, C should be <= D, E should be <= F, and G should be <= H for each test. (the reason is that the first of each pair has to do the extra work of reading the data off of the disk.) Unfortunately, since the files should be small so that they fit in the buffer cache, their transfer times are smaller, and thus the % error in reporting of both time to transfer and throughput will be larger, so you can't guarantee that this'll be true... in general, though, if you've got disk/ethernet access problems, they're most likely to show up in the (C) vs (D) and (G) vs (H) numbers. chris From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 22 22:08:38 1994 From: mw@eunet.ch Subject: Re: NetBSD & Retina Bootproblem To: jkoob@wish.swb.de (Jochen Koob) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 817 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > my problem is, that each time I want to boot into multiuser mode I > get the error message 'getty: /dev/ttye1: Device not configured' > instead of the normal login prompt. (If the world hasn't changed...:-)) then you have to 1/ make sure you have a /dev/ttye2. If you don't, either MAKEDEV might be able to generate one, or just look at /dev/ttye1, and make a similar node with minor incremented once. 2/ add a line like: ttye2 "/usr/libexec/getty std.9600" vt320 on secure # ITE console to your /etc/ttytab file. -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH >Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 22 22:36:07 1994 From: Russel Miranda Subject: Hydra board To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, Some time ago, I heard there was support for the Hydra ethernet board - and then I heard of problems causing people to recompile their kernels without it. I happen to be the proud(?) owner of one of these boards, which I was beginning to think useless. My question is this: Is the Hydra support working correctly now? I would very much like to hook my computer up to my brother's when I get back home in three weeks! Also, I've been away from my Amiga for over 2.5 months... and away from NetBSD except for reading this list. Can anyone tell me if I can use multiple GVP SCSI controllers, and if so, how? I have a group of relatively small hard drives, attached to two SCSI controllers, one is part of my accelerator board, the other is a Series II/HC+8. I would like to be able to use both, because my tape drive is on one (in an external case with 6 other devices) and my removable cartridge drive is on the other. Trust me, it's an annoying setup, and I should try to sell all the small drives and get a big one, but noone wants drives smaller than 200M these days. Russ From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 23:06:50 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: martin@euterpe.owl.de Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Diskless booting from SMC boot ROM Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Date: Sun, 21 Aug 1994 20:06:01 +0200 (MET DST) > From: "Martin Husemann" > I'm going to setup a diskless box. This seems to be easy when I boot the > kernel from floppy, but I would prefer to get it via tftp straight from > the SMC 8013 EP boot rom. This box doesn't even have a floppy... > > Does such a ROM exist and where can I find it? This fellow sells ROMs that boot PCs with no disk/diskette: dirk@lisa.incom.de (Dirk Koeppen) From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 23:10:53 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Changes to com.c for bidirectional use -- bug fix From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu I had missed adding a wrapper around ttselect. This also entails a change in conf.c in i386 dir. Context diffs against i386/conf.c and isa/com.c from the lastest tarballs (i.e. Aug 21) follow. My thanks to Hannes Deeken for pointing this out. Apply by: uudecode =VG]VC5JM!T.J> M'I,XFAZ10^9]H,9[ZL,/603."31:_6:[WVR!T^NUGQT>'FY*&R,4NLAFT'3` MZ?3;O;[C*,%:^2/>4:)E.YTNR`%A20YT3P"?#Y\!&*9//[A\E5`WI8QRTZQ9 ME@51%H9Q8H.#VC&JO/#I-(BH0;0/S;43 M\!'7KH,A9O)!6]BWE,?%F%QM>U"L;=D5%J0[V]+2N>U!X6INXJL!+%N26.[: MV@-F'1#/:C!S%*5!`2&4(5S$&:-;&,+?QK`JYEJG';O5::F8PR5("83KF_'/ M=L*991NXD9,^)(QF?GPH#IZ%F`G*=Z65<%+2(DKKM*2U\!BGZ:9:&,^4FF/C M(^H(I4X?CG'R^!Z'A/#S'<\&PW-2_A2K M^@&[UY8N7]E37Z_;Z\,48R%9@1"@G.L=OL@B-*=MR=QL==IVJ]LH4B/BYQ+QQF5%`D]R:7=?L/9X-)<=I-)FTZ_>=(_:>]GTD[7[K;6 M/"I>3_.3RG>',+BC]^[@[7!P\=9H/#2:%9.WX]%@/!*S[=W9=Z_>O;R[%)/= M#0[4D\.[\9OAU?4;G'8:N]-7XAC4=+-B^OW%U1BGV@T!>^:2N9<"(^Z"I;;\ M)>D9SCR>*8;Y"3_`YG$6^C"A$$2`F+DLGG)BPR3C$,5<,L\*IG$*?.YQ6%%Y MVI5UR&G:CM/-.8$^8.!%:)7#_#^=@$NM, M<:!A@/C$&9^8:AKI-,J?+?@$YL1"X4=8SH.0F@U+E5+GQ'::[3P(_ID]P0%\ M;CQT<8FU7'[N4E#);(M*UM.0V_&4&F@;H7S"% MB!+*F)>N-,7AD&F*O>/6A^[U\/HE9O6/%IR?@T3>,*0_*,23P^^X2[2L2GXE M!P<'4E)L4(LQ[B&-'5SRNQ"6H94+F[40(XPM?U&[$R^_'86N;%9,V1KQ!'5D M!6UVL?58=[?[HT#LN,@8-&+E.Q?=5<9G<1#-9)N%51+K:T8(Q09=;A%5@PC# MLY"8>TS2H=ZT,+V54`6L93C*WCV7,(COS8C"&%`AI008*:6EF"VGM1#+-[+T M[FF6B%."21B3>]Q!V7,>PRP&&4E`0T:7P@"@F&-VP$]0R6%5^ M&&IYLRH\%0*/!(]U/5B^_FA+O?_ M)(*H%QSX))*0XOM90DWOC1)Q;KG0UW")TC",OZ02)53B$JWW9#+1\KMLHB>* M8]3O93Y1@X_Z-S_)=6#O!%#`P",\4+VSTM*'5A%'>DGS0QSXUB9H!3IK\,H' M8'\-?MI]];/W('-VD5I_GSRK[W$-NW7:*TKJ1YDHDX"803SQ,&_KLIZ3*<$. M!MJ63N8Y_1\'*,B9$G MF^PB=(@E-)U["5/A0T**3>ZK\:V^XU0YM2!KIR2.>++RSFM*8+##":;8XPB> M$?UMWAJC05EP>FV[W6P6!>>?PTA>];\(D_&OPZ1ILK)^UO4*?AHGTAXV@%[J MA\B8X]^BN>\/*:2WWQY(H%-14USC:93=7^+QWHFN:^.CVK**W7:-N]1F=]C>^= M=.S>:;?(7]17V>!%*W&5P\*2)9S!C$8T1<#P,KS"P\"ZP5,O8HN`L2".=-X( M2!$Q<7LIYW20JGS?J%ZZW\!I]8^=R*&`B'_SEC8D5O[G)` NetBSD 0.9a) that compiles 'some' Ada programs that run happyly on NetBSD. But I have problems when I try to build the 'native' compiler itself. GNAT is build using GCC 2.5.8 and some Ada files. Problems arise when I try to build gnat1, the Ada driver for GCC. It seems to build o.k., but dies from segmentation fault when I run it. With gdb, I get the following (post-mortem): % gdb gnat1 gnat1.core Core was generated by `gnat1'. Program terminated with signal 11, Segmentation fault. Cannot access memory at address 0x102c6040. #0 0x1416f5 in stand__create_standard () at stand.adb:452 452 Set_Char_Literal_Value (B_Node, 16#FF#); Function "abort" not defined. (gdb) Anybody out there can help me with this? I'm using NetBSD 0.9a, GCC 2.5.8 and GNAT 1.81. Specially, I'd like to hear from patches to GCC to build clean on NetBSD, or from somebody with GDB knowdledge than can help with what the debbuging means, or... Wel, or anybody willing to help. I'm really out of ideas now... Thanks in advance, Jesus. -- Jesus M. Gonzalez Barahona | Universidad Carlos III (Madrid, Spain) tel: +34 1 624 94 58 | e-mail: jgb@inf.uc3m.es fax: +34 1 624 94 30 | jgb@ordago.uc3m.es (Sometimes our headers are not o.k., please reply to any of this addresses) .From within Universidad Carlos III, you can better use jgb@ordago.uc3m.es From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 23:34:04 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Re: majordomo problem <199408191435.KAA28412@duality.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199408191435.KAA28412@duality.gnu.ai.mit.edu>you write: -> ->Part of the recent majordomo lossage was that a significant number of ->people on the current-users list disappeared. I think I've fixed ->this, but it's possible that some people were added or removed by ->mistake. I am now double registered with the list. Please remove and retain only oskar@zappa.unna.ping.de Gruesse Oskar ============================================================================== Jan-Hinrich Fessel , Systemverwaltung Quantum Gesellschaft fuer Software mbH, D-4600 Dortmund, Germany Jan-Hinrich.Fessel@quantum.de oskar@un.maus.ruhr.de ============================================================================== From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon Aug 22 23:39:03 1994 From: jes%ganza%cp1@cs.umd.edu To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: trying to confgigure SMC ethernet card Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I used to have a 3COM 3c503TP ethernet board which worked fine with NetBSD, but swapped in an SMC card that I can't seem to configure. The board says "8216T", while the ASIC says "SMC UltraChip 83C790QF P." I've tried various combinations of settings using the 'ezstart' dos program that seems to reset the soft jumpers, but the only recognition of the board was a message telling me the interrupt was not per the kernel (I'm at NetBSD 0.9). The ezstart program won't let me pick IRQ 9, for some reason; the hard jumper choices are 3 and 10. Any suggestions? /je spath From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 22 23:55:38 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 3.99) Organization: None X-Charset: ISO_8859-1 Content-Length: 1381 From: ghost@macbeth.in-berlin.de (Hartmut Kuehn) To: jkoob@wish.swb.de Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD & Retina Bootproblem Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi Jochen (Jochen Koob), on Aug 21 you wrote: > my problem is, that each time I want to boot into multiuser mode I > get the error message 'getty: /dev/ttye1: Device not configured' > instead of the normal login prompt. In /etc/ttys you find all the ttys, that will get a getty, when you get into multiuser mode. You said, you have the Retina Z3 (like me), then comment out the line ttye1 .... and uncomment the line ttye2 ... in /etc/ttys, then NetBSD wont try any longer to give you a login prompt on /dev/ttye1 (which is the Retina Z2 interface) but on ttye2 (which is the Retina Z3 interface). First look into /dev, if you have /dev/ttye2. If not, do a mknod /dev/ttye2 c 13 2 and it should work (it did for me, I had the same problem :-). Bye -- ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@macbeth.in-berlin.de * * (or ghost@cs.tu-berlin.de, * * 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 owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 22 23:56:41 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu, port-sparc@sun-lamp.cs.berkeley.edu Subject: kernel addresses: how? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since ddb is less than wonderful without symbol tables, I've been looking at ways to teach ddb about the kernel's symbol table. Unfortunately I can't do it the proper way, via the bootblock, because NetBSD/sparc doesn't have network bootblocks, and this is for the diskless work I'm doing. So I read over ddb/db_aout.c and thought of using the SYMTAB_SPACE facility. I built a kernel with "option DDB, SYMTAB_SPACE=70000" and then planned to build a small patch program to scribble on the appropriate piece of the resulting kernel to fill in the symbol table. But then I ran into a problem. According to hexdump, the resulting kernel's struct exec header (the first 32 bytes) is 0000000 008a0107 000abfe0 00023cf0 00012778 0000010 00007ecc f8004000 00000000 00000000 which unpacks to a_midmag = htonl(0x008a0107) = magic=0407[OMAGIC], mid=138[MID_SPARC], flags=0 a_text = 704480 = 0xabfe0 a_data = 146672 = 0x23cf0 a_bss = 75640 = 0x12778 a_syms = 32460 a_entry = 0xf8004000 a_trsize = 0 a_drsize = 0 string size = 33563 N_TXTADDR = 0x2000 N_DATADDR = 0xadfe0 N_BSSADDR = 0xd1cd0 N_TXTOFF = 32 N_DATOFF = 704512 N_TRELOFF = 851184 N_DRELOFF = 851184 N_SYMOFF = 851184 N_STROFF = 883644 All the addresses are down in user-land, in spite of the -T f8004000 when the kernel was linked (this taken from SYSTEM_LD in the kernel build Makefile). I would expect this to mean that the a.out is a normal a.out, except that the header does not record that its effective N_TXTADDR is 0xf8004000 instead of the 0x2000 that is normal for an OMAGIC executable - and this appears to be so; when I compute file addresses based on an address offset of 0xf8004000-0x2000, everything looks normal. (The ld run that links the kernel also specifies -p, which does not appear in the ld man page, so it may well be weirded out.) What's really baffling me is gdb. When I sic gdb on the file, it finds things at their kernel-space addresses! Script started on Mon Aug 22 10:51:37 1994 [Callisto] 1> gdb netbsd (no debugging symbols found)...(gdb) (gdb) x/d 0xf80b9128 0xf80b9128 : 70000 (gdb) x/d 0xb5128 0xb5128: Cannot access memory at address 0xb5128. (gdb) x/d 0xb7128 0xb7128: Cannot access memory at address 0xb7128. (gdb) x/d 0xb9128 0xb9128: Cannot access memory at address 0xb9128. (gdb) quit [Callisto] 2> exit Script done on Mon Aug 22 10:59:34 1994 Can some kind soul explain what it is about this file that is telling gdb how to locate things at their proper addresses? Provided I'm willing to hardwire 0xf8004000 as the effective N_TXTADDR, I can proceed with my patching plan...but (a) I don't like to charge ahead when there's something I don't understand hovering nearby, and (b) I shouldn't need to, as the file obviously contains this information _somewhere_, or gdb wouldn't be able to figure it out. (The file name appears to be irrelevant; gdb behaves the same even when I mv the file to "a.out".) I could even imagine gdb having 0xf8004000 wired into it somewhere, but then I can't see what's making it decide to use it. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 00:36:58 1994 From: Paul Kranenburg To: current-users@sun-lamp.cs.berkeley.edu, port-sparc@sun-lamp.cs.berkeley.edu, mouse@cim.mcgill.ca Subject: Re: kernel addresses: how? Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Can some kind soul explain what it is about this file that is telling > gdb how to locate things at their proper addresses? Provided I'm > willing to hardwire 0xf8004000 as the effective N_TXTADDR, I can > proceed with my patching plan...but (a) I don't like to charge ahead > when there's something I don't understand hovering nearby, and (b) I > shouldn't need to, as the file obviously contains this information > _somewhere_, or gdb wouldn't be able to figure it out. The information in a.out is not complete, but one can guess. If the entry point is far enough beyond its "normal" location, gdb will assume that this file is actually going to be loaded at a different address than the standard N_TXTADDR(). In fact it assumes that the entry point rounded down to a page address is the loading address. A similar hack applies to shared libraries. Any other non-conformant image will currently not be handled properly by gdb. -pk From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 23 01:35:12 1994 From: Quetzalcoatl Bradley Subject: getty and a modem, how to set up To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am using NetBSD 1.0 pre-release on an A3000T I created a line in ttys that looks like: tty00 "/usr/libexec/getty std.38400" vt100 on secure rtscts But as soon as I go to multi-user getty starts talking to the modem a lot, it tries to run login, fails to get a user, and tries again. I would like getty to not try and get the login name until carrier goes high but I have been unable to determine how to do this. Is it an option in ttys, gettytab? Do I need some other getty program? Any help appreciated! Also, has anyone succesffully built the GNU texinfo-3.1 package? It builds makeinfo, but makeinfo program doesn't work (it exits with "unkown error" when loading in a .texi file). I traced through it with gdb and discovered that it was exiting because an "read" call was returning 0 (EOF) when it should have. I guess I should give a better explanation, I think I will when I get home. I was just wondering if I was the only one to experience this problem. +-----------------------------------------------------------------------------+ | Quetzalcoatl Bradley qbradley@csc.uvic.ca | | "Alcohol - cunning, baffling, powerful. We cannot stand alone against it." | +-----------------------------------------------------------------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 23 03:35:46 1994 From: "Hubert Feyrer" "getty and a modem, how to set up" (Aug 22, 3:49pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: getty and a modem, how to set up Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > tty00 "/usr/libexec/getty std.38400" vt100 on secure rtscts Try using /dev/ttym0 for use with a modem. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 04:51:30 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: THIS LIST QUIET, OR DID I GET REMOVED FOR SOME REASON? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I noticed a lack of mail from this quarter over the last week. When I tried subscribing, it happily subscribed me again. Was I removed for some reason or is everyone so content with NetBSD that they don't need to comment on anything? Just wondering. -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 07:17:38 1994 From: Dave Burgess Subject: Bug in fortune ;_0 To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 214 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I found a mistake in my daily fortune today. In the quote about Unix being 500000 seconds old, the attribution is for Andy Tannenbaum. It is supposed to be spelled 'Tanenbaum'. "Those who can't code, nit-pick" From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 09:08:16 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: I did something stupid! Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu I tried to bring my filesystems up-to-date with fsck -c2, and I managed to hose my root partition. Now, whenever I boot, it flashes a message and reboots. All I've been able to see of the message are the last lines, which are: i/o error rebooting... I forgot to update the boot blocks (they're 1.19s from late April), which I think is the root of my problem. I need one of two things: 1) Disk images for a 1.0B kernel-copy and filesystem floppies (desperate beta tester with nothing to lose! That's me!). I can boot either i386 GENERIC kernel; the only thing I really need is wd0, although MSDOSFS and mount_msdos would be helpful. The only thing that *must* be missing is com3 (I have 8514A compatible VGA). 2) Alternatively, does anyone know of a dd-like utility that runs on DOS? I just went trolling through the /pub/msdos/{gnuish,diskutil} directories on oak.oakland.edu, but I didn't see anything that might be helpful. If I had something dd-like, then I could try to write some up-to-date bootblocks directly to my root partition. I hope someone can help me, since I'd rather NOT have to reinstall 0.9 and upgrade again. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-amiga@sun-lamp.cs.berkeley.edu Tue Aug 23 10:48:27 1994 From: Julian H Stacey To: ABotelho@symantec.com Subject: Loooking for BSD for Amiga 3000 with 14meg Ram & 400 megs of HD Cc: current-users@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, rgrimes@agora.rain.com, gclarkii@radon.gbdata.com, jkh@al.org, khe@pcsbst.pcs.com Sender: owner-amiga@sun-lamp.cs.berkeley.edu To Andr? Botelho (Symantec Australia Tech Support) ABotelho@Symantec.com Re. your: > Could someone please help me locate a copy of BSD for the Amiga..... > I Have a Amiga 3000 with 14meg Ram & 400 megs of HD & would love to > run Bsd on my Amy... NetBSD has the following amiga groups (dont know for which amiga hardware though: amiga amiga-dev amiga-x For info about mail lists, mail: To: Majordomo@sun-lamp.cs.berkeley.edu info amiga info amiga-dev info amiga-x lists end Note I have copied this to NetBSD lists: current-users@sun-lamp.cs.berkeley.edu,amiga@sun-lamp.cs.berkeley.edu and to original recipients: rgrimes@agora.rain.com,gclarkii@radon.gbdata.com,jkh@al.org and to a Unix friend with an Amiga khe@pcsbst.pcs.com I don't know of any other BSD amiga ports in progress (but then I don't have an amiga ) Good luck. -- Julian Stacey, Vector Systems Ltd, Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 13:25:58 1994 From: Julian H Stacey To: ABotelho@symantec.com Subject: Loooking for BSD for Amiga 3000 with 14meg Ram & 400 megs of HD Cc: current-users@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu, rgrimes@agora.rain.com, gclarkii@radon.gbdata.com, jkh@al.org, khe@pcsbst.pcs.com Sender: owner-current-users@sun-lamp.cs.berkeley.edu To Andr? Botelho (Symantec Australia Tech Support) ABotelho@Symantec.com Re. your: > Could someone please help me locate a copy of BSD for the Amiga..... > I Have a Amiga 3000 with 14meg Ram & 400 megs of HD & would love to > run Bsd on my Amy... NetBSD has the following amiga groups (dont know for which amiga hardware though: amiga amiga-dev amiga-x For info about mail lists, mail: To: Majordomo@sun-lamp.cs.berkeley.edu info amiga info amiga-dev info amiga-x lists end Note I have copied this to NetBSD lists: current-users@sun-lamp.cs.berkeley.edu,amiga@sun-lamp.cs.berkeley.edu and to original recipients: rgrimes@agora.rain.com,gclarkii@radon.gbdata.com,jkh@al.org and to a Unix friend with an Amiga khe@pcsbst.pcs.com I don't know of any other BSD amiga ports in progress (but then I don't have an amiga ) Good luck. -- Julian Stacey, Vector Systems Ltd, Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 14:52:44 1994 From: Julian H Stacey To: xbugs@x.org, xfree86-beta@xfree86.org, freebsd-hackers@freefall.cdrom.com, current-users@sun-lamp.cs.berkeley.edu Cc: Mike.Long@analog.com, leo@marco.de Subject: Fix for X11R6-pl3 xterm +ut and XTerm*utmpInhibit for FreeBSD & NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu Patch For: X11R6-pl3/xc/programs/xterm Why: To get `+ut' and `XTerm*utmpInhibit' to work, Without it xterm tries to create an entry in /etc/utmp. Tested with: FreeBSD 1.1.5-Current. Also for: NetBSD-current 94 08 12 sources, Background: Before fixing this FreeBSD `talk` couldn't find a utmp entry for my xterms, so users couldn't initiate `talk` to me. #if BSD_NET2: Can't be used instead of (__FreeBSD__ || __NetBSD__) as: cpp -dM < /dev/null defines for FreeBSD: __FreeBSD__ __386BSD__ ____386BSD____ i386 BSD_NET2 __GNUC__ unix cpp -dM < /dev/null defines for NetBSD: ns32k __NetBSD__ ns32532 pc532 __GNUC__ unix Don't know if FreeBSD-2 will define BSD_NET2 or need this patch. I left #if BSD_NET2 in, in case it helps BSD/386. xfree86-beta@xfree86.org: My apologies, I don't know if this is necessary for latest test version of XFree86, I've temporarily lost my site details for src ftp-mail & ftp, so haven't read that source yet. Copyright: I grant this to the public domain, I disclaim liability :-) Replies: You may want to prune `To:' & `Cc:' lines which include: xbugs@x.org xfree86-beta@xfree86.org freebsd-hackers@freefall.cdrom.com current-users@sun-lamp.cs.berkeley.edu -- Julian Stacey, Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) Alternates: , Cut {========= *** old/X11R6.pl3.xc/programs/xterm/main.c Mon Aug 22 10:52:35 1994 --- new/X11R6.pl3.xc/programs/xterm/main.c Mon Aug 22 13:39:57 1994 *************** *** 263,268 **** --- 263,273 ---- #define USE_GET_PSEUDOTTY #endif + #if BSD_NET2 || __FreeBSD__ || __NetBSD__ + /* For FreeBSD 1.1.5(RELEASE) & NetBSD-current@94.08.12: /var/run/utmp */ + #define UTMP_FILENAME _PATH_UTMP + #endif + #ifndef UTMP_FILENAME #ifdef UTMP_FILE #define UTMP_FILENAME UTMP_FILE Cut ========} From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 14:52:47 1994 From: "Hubert Feyrer" "Loooking for BSD for Amiga 3000 with 14meg Ram & 400 megs of HD" (Aug 23, 9:58am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, ABotelho@symantec.com Subject: Re: Loooking for BSD for Amiga 3000 with 14meg Ram & 400 megs of HD Cc: current-users@sun-lamp.cs.berkeley.edu, rgrimes@agora.rain.com, gclarkii@radon.gbdata.com, jkh@al.org, khe@pcsbst.pcs.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Could someone please help me locate a copy of BSD for the Amiga..... > > > I Have a Amiga 3000 with 14meg Ram & 400 megs of HD & would love to > > run Bsd on my Amy... I don't know who of you sent that question, but NetBSD for the Amiga van be found on ftp.uni-regensburg.de in /pub/NetBSD-Amiga. Please note the docs-subdir. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 19:40:40 1994 From: rich@id.slip.bcm.tmc.edu (Rich Murphey) To: Julian.H.Stacey@regent.e-technik.tu-muenchen.de Cc: xbugs@x.org, xfree86-beta@xfree86.org, freebsd-hackers@freefall.cdrom.com, current-users@sun-lamp.cs.berkeley.edu, Mike.Long@analog.com, leo@marco.de Subject: Re: Fix for X11R6-pl3 xterm +ut and XTerm*utmpInhibit for FreeBSD & NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu :From: Julian H Stacey : :Patch For: X11R6-pl3/xc/programs/xterm :Why: To get `+ut' and `XTerm*utmpInhibit' to work, : Without it xterm tries to create an entry in /etc/utmp. ... This is fixed in our latest beta, XFree86 3.0D. For FreeBSD 1.1.5 we get utmp from the system header file: /usr/include/utmp.h:#define _PATH_UTMP "/var/run/utmp" % strings /usr/X11R6/bin/xterm |grep /utmp /var/run/utmp In priciple NetBSD can do the same. Rich From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 21:19:19 1994 To: Julian H Stacey Cc: freebsd-hackers@freefall.cdrom.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Fix for X11R6-pl3 xterm +ut and XTerm*utmpInhibit for FreeBSD & NetBSD From: Mark Treacy Sender: owner-current-users@sun-lamp.cs.berkeley.edu > + #if BSD_NET2 || __FreeBSD__ || __NetBSD__ #if defined(BSD) && BSD > 43 would be preferable here (i.e. the utmp location change came after tahoe and was present in reno and later bsd releases). > + /* For FreeBSD 1.1.5(RELEASE) & NetBSD-current@94.08.12: /var/run/utmp */ > + #define UTMP_FILENAME _PATH_UTMP > + #endif > + > #ifndef UTMP_FILENAME > #ifdef UTMP_FILE > #define UTMP_FILENAME UTMP_FILE But, since the patch relies on _PATH_UTMP anyway, it is best to omit the BSD_NET2 || ... patch entirely and add after the above section something like #else + #ifdef _PATH_UTMP + #define UTMP_FILENAME _PATH_UTMP + #endif #define UTMP_FILENAME "/etc/utmp" - Mark. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 21:56:36 1994 From: Scott Reynolds Subject: Re: Mounting dos partition and disklabel To: klee@rdcclink.rd.qms.com Cc: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 23 Aug 1994 klee@rdcclink.rd.qms.com wrote: > I now have NetBSD 1.0 Beta installed, but I have not mounted DOS > partition yet because I am afraid of screwing up again. I am in the > process of setting up my second drive so that I can try mounting and > disklabel on second drive. I followed the FAQ and set up a disklabel and mounted my ms-dog partition in about 5 minutes. "Works for me" ...but your mileage may vary. Backing up before doing this sort of thing is always a good practice. --scott From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 23:26:54 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Accessing your MS-DOS parition from NetBSD X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu There was some discussion on netbsd-help on the right way to access a MS-DOS parition from NetBSD. Here's the instructions I posted there, with some improvements suggested by Mike Long. I figure this might help someone who's having problems doing this. As always, corrections and suggestions are welcome. ACCESSING MS-DOS PARTITIONS FROM NetBSD-i386 First off, it's important to understand BSD disklabels. The disklabel is a description of the Unix parition layout and other disk parameters stored on-disk, usually somewhere in the first couple of sectors. There is a maximum of 8 partitions, labelled "a" thru "h". Typically partition "a" is assigned to the root partition, partition "b" is configured as a swap area, and partition "c" is defined as the whole disk. You can change these, but it's a good idea to stick with this scheme, as many programs assume that's the way things are going to be. If you're whole disk is dedicated to Unix, then that's all you need to know. But if you're sharing your disk with DOS, then there are a few magical things happening. DOS has it's own partitioning scheme. The way NetBSD co-exists with this is to fit all of the Unix partitions into one DOS partition. So partitions a-h all fit inside one DOS partition, which has a partition type of 165 (each MS-DOS partition has a "partition type" associated with it. The BSD partition type is 165). In this setup, partition "c" refers to the entire BSD partition. But in this scheme, partition "d" refers to the ENTIRE disk, MS-DOS partitions and all. So, if you want to access your MS-DOS partition from NetBSD, first you'll have to create a partition that points to the MS-DOS partition. You'll want to run the command: disklabel -e -r /dev/r??0d (fill in with your disk type). You'll get popped into an editor with all the disklabel stuff in it. Go down to the bottom. You should see something like: 6 partitions: # size offset fstype [fsize bsize cpg] a: 30720 409600 4.2BSD 1024 8192 16 # (Cyl. 200 - 214) b: 129024 440320 swap # (Cyl. 215 - 277) c: 1617920 409600 unused 0 0 # (Cyl. 200 - 989) d: 2029568 0 unused 0 0 # (Cyl. 0 - 990) e: 61440 569344 4.2BSD 1024 8192 16 # (Cyl. 278 - 307) f: 1396736 630784 4.2BSD 1024 8192 16 # (Cyl. 308 - 989) (or whatever it appropriate for your disk). Note how partition "a" starts on cylinder 200? That's where my BSD partition starts on my disk. Also note that partition "c" starts at 200 as well and goes to the end of the disk. You'll also note that partition "d" goes from sector 0 all the way to the end of the disk. Add a new line that looks something like: g: 409568 32 MS-DOS # (Cyl. 0*- 199*) (The comment on the end isn't necessary. Only the partition letter, size, offset, and parition type are needed. You can put unused if you want). *NOTE* Be sure to change the line that says "6 partitions" to the new number of paritions that you have!!! Otherwise you'll get an obscure error. In my case I'd change that line to be "7 partitions". If you aren't sure what your MS-DOS partition size and offsets are, you can use the NetBSD fdisk to find them out. Don't forget that there's a maximum of 8 partitions. Once you do that and you have MSDOSFS configured into your kernel, you can just do something like "mount -t msdos /dev/sd0g /msdos". Or you can put a line like this in your fstab: /dev/sd0g /msdos msdos rw 0 0 If you want to access a DOS-only HD from NetBSD, here are some instructions posted by Charles Hannum a while back. I haven't tried them myself, but they seem like they would work. Date: Fri, 4 Mar 1994 07:50:08 -0800 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: Mounting an all-DOS disk in NetBSD Assuming you don't have something (like OS-BS) which uses the extra sectors in the boot track, you can do the following: 1) Use the NetBSD `fdisk' or DOS `pfdisk' to create a NetBSD partition in the MBR which spans the entire disk. 2) Save a copy of the MBR: dd if=/dev/rsd0d of=my-mbr bs=1b count=1 3) Use `disklabel' to create a NetBSD label with the DOS partition and whatnot. Answer `y' when it asks you if you want to `overwrite [a] disk with [a] DOS partition table'. 4) Put back the saved copy of the MBR: dd if=my-mbr of=/dev/rsd0d bs=1b count=1 This works for me. Your milage may vary. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 23:42:47 1994 From: matthieu@laas.fr (Matthieu Herrb) To: rich@sun-lamp.cs.berkeley.edu Cc: Julian.H.Stacey@regent.e-technik.tu-muenchen.de, xbugs@x.org, xfree86-beta@xfree86.org, freebsd-hackers@freefall.cdrom.com, current-users@sun-lamp.cs.berkeley.edu, Mike.Long@analog.com, leo@marco.de Subject: Re: Fix for X11R6-pl3 xterm +ut and XTerm*utmpInhibit for FreeBSD & NetBSD <199408231536.KAA06699@id.slip.bcm.tmc.edu> X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 370 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Tue 23) > > This is fixed in our latest beta, XFree86 3.0D. For FreeBSD 1.1.5 we > get utmp from the system header file: > > /usr/include/utmp.h:#define _PATH_UTMP "/var/run/utmp" > > % strings /usr/X11R6/bin/xterm |grep /utmp > /var/run/utmp > > In priciple NetBSD can do the same. Rich It already does. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 23:44:35 1994 From: Mark Gooderum To: current-users@sun-lamp.cs.berkeley.edu Subject: 1024 Byte Sectors X-Sun-Charset: US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there anything funky with using a disk w/1024 byte sectors? I can label it, but newfs bails on the charecter device - it always complains about writing the last sector right away, like: wtfs: Invalid argument write error: 299909 Where the problem number is always the last sector of the partition. If I newfs with the block device it completes okay but fsck barfs badly, unable to find any superblock (it always complains about bad magic number). This is a PC BTW...the drive is an older (SCSI-1) drive of about 600M. The drive appears to read/write okay. I can dd on and off the disk over the sectors that complain without any errors. Suggestions on where to look? -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Aug 23 23:57:10 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: xfree86-beta@xfree86.org Cc: freebsd-hackers@freefall.cdrom.com, current-users@sun-lamp.cs.berkeley.edu, Mike.Long@analog.com, leo@marco.de Subject: Re: Fix for X11R6-pl3 xterm +ut and XTerm*utmpInhibit for FreeBSD & NetBSD <94Aug23.104928met_dst.43010@eikon.regent.e-technik.tu-muenchen.de> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Julian H Stacey writes: > Patch For: X11R6-pl3/xc/programs/xterm > Why: To get `+ut' and `XTerm*utmpInhibit' to work, > Without it xterm tries to create an entry in /etc/utmp. > Tested with: FreeBSD 1.1.5-Current. > Also for: NetBSD-current 94 08 12 sources, > > [...] > > *** old/X11R6.pl3.xc/programs/xterm/main.c Mon Aug 22 10:52:35 1994 > --- new/X11R6.pl3.xc/programs/xterm/main.c Mon Aug 22 13:39:57 1994 > *************** > *** 263,268 **** > --- 263,273 ---- > #define USE_GET_PSEUDOTTY > #endif > > + #if BSD_NET2 || __FreeBSD__ || __NetBSD__ > + /* For FreeBSD 1.1.5(RELEASE) & NetBSD-current@94.08.12: /var/run/utmp */ > + #define UTMP_FILENAME _PATH_UTMP > + #endif > + > #ifndef UTMP_FILENAME > #ifdef UTMP_FILE > #define UTMP_FILENAME UTMP_FILE > Cut ========} A more general fix for this is in XFree86 3.0A. In fact, I believe it was in the first patches we sent the X Consortium, but they weren't able to incorporate all of our patches before release. The #ifndef UTMP_FILENAME section below what you inserted was extended: #ifndef UTMP_FILENAME #ifdef UTMP_FILE #define UTMP_FILENAME UTMP_FILE #else #if defined(_PATH_UTMP) #define UTMP_FILENAME _PATH_UTMP #else #define UTMP_FILENAME "/etc/utmp" #endif #endif #endif This has the advantage of not being BSD specific. There was a section below that regarding the wtmp which was similarly extended. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 24 00:37:40 1994 From: Sam Noonan Subject: NetBSD & Picasso II To: BSD Amiga Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anyone know the status of getting NetBSD working with the Picasso II Graphics Card? ================================================================ Sam Noonan -- snoonan@netcom.com finger for PGP Public key. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 04:59:27 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: umount error status wrong? <199407190505.BAA26953@kolvir.blrc.ma.us> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > umount(8) currently exits with status 1 if it was successful unmounting > a filesystem. Shouldn't it exit with status 0? "Now, since when has exit status zero indicated success?" 8-) fixed. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 05:32:59 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Subject: Ethernet cards for the i386 platform Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could anybody tell me which is the best Ethernet card for the Intel x86 platform? I basically mean 'best' towards most compatible, less amount of problems ( I remember some people complaining about one brand of Ethernet board, but can't find the article ) Does NetBSD support PCI/VLB bus Ethernet boards? ( If they even exist... ) Would that really buy anything? Thanks, Brian Moore ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 05:56:31 1994 From: Julian H Stacey To: Mike.Long@analog.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: I did something stupid! Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just went trolling through the /pub/msdos/{gnuish,diskutil} > directories on oak.oakland.edu, but I didn't see anything that might > be helpful. If I had something dd-like, then I could try to write > some up-to-date bootblocks directly to my root partition. I have valid.exe, I wrote it, I'll send you the .exe & man by private mail. (no point flooding this list) -- Julian Stacey, Vector Systems Ltd, Holz Str 27d, Munich, D-80469 Germany. Tel. +49 89 268616 ( TZ=GMT+1 ) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 07:02:50 1994 Subject: Australian SUP server closing down (or moving) To: current-users@sun-lamp.cs.berkeley.edu From: Luke Mewburn X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1891 Sender: owner-current-users@sun-lamp.cs.berkeley.edu As of September 2, I won't be working as a system admin at the Department of Computer Science, RMIT University, as I'm moving on to greener pastures (although I'll still be an undergraduate within the department.) This leaves a minor dilemma - I probably won't retain root access on the support staff machine that is currently acting as the sup server for about 10 people in Australia (jacana.cs.rmit.oz.au.) The service will probably cease a few days after that time, as my new employer (I'm contracting to Telecom Australia) has firewall restrictions so I probably won't be able to run the supserver there. If someone is willing to take over as the netbsd-current sup server for down-under, I'm sure there'd be a few people grateful (including me because I would use such a service in preference to sun-lamp if it was available.) What you need to become a -current mirror: - good connectivity (those who sup off me at Melbourne Uni would be good candidates :) - about 100MB of free space on TOP of your normal source tree. - mail me and I'll send you the scripts and control files, and advise you if necessary If anyone is willing, please mail me, and I'll send you the scripts and control files I've got, so that you can start the service. The way I ran it was: - run supfilesrv on your server (`sup-mirror') - each night, sup from sun-lamp to sup-mirror. run supscan if the sup was successful. - allow people access to sup-mirror. I actually supped from my mirror to another local machine, so you really need about 300MB if you want to mirror and maintain your own source tree: 100MB sup-mirror:/wherever 200MB netbsd-current-box:/usr/src Any volunteers? -- Luke Mewburn UNIX Systems Programmer, Technical Services Group Department of Computer Science, RMIT. [till September 2] From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 24 19:21:47 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "NetBSD & Picasso II" (Aug 23, 2:36pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Sam Noonan , BSD Amiga Subject: Re: NetBSD & Picasso II Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Aug 23, 2:36pm, Sam Noonan wrote: > Subject: NetBSD & Picasso II > > Does anyone know the status of getting NetBSD working with > the Picasso II Graphics Card? Yes, i do. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 24 19:39:23 1994 From: Sam Noonan Subject: Re: NetBSD & Picasso II To: Markus Illenseer Cc: BSD Amiga Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Wed, 24 Aug 1994, Markus Illenseer wrote: > On Aug 23, 2:36pm, Sam Noonan wrote: > > Subject: NetBSD & Picasso II > > > > Does anyone know the status of getting NetBSD working with > > the Picasso II Graphics Card? > > > Yes, i do. > > > -- > Markus Illenseer > Ok. Sure am glad that someone knows. I feel better now. Ohhhh. BTW what is the status of the Picasso II working with NetBSD. When will it be ready for testing? When will it be available? ================================================================ Sam Noonan -- snoonan@netcom.com finger for PGP Public key. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Aug 24 19:57:22 1994 From: JOCHEN BUEHLER To: amiga@sun-lamp.cs.berkeley.edu Subject: A2091 & DMA - Help needed ! Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi everyone ! I'd like to know if someone with a similar setup than mine (A4000, A2091) might wan't to have a look on the atzsc.c driver to get DMA (via bounce buffers) working correct. (I have to admit that my efforts to help (trying out what he suggested to me) Michael Hitch have led to no success :( ) ... would be nice to receive your mail :) Jochen (buehler@chclu.chemie.uni-konstanz.de) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 21:39:30 1994 Subject: Can you boot with the aic driver with a SoundBlaster-SCSI-2? From: Brian de Alwis To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 191 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Can you boot from a disk attached to a SoundBlaster SCSI-2? -- Brian de Alwis - University of Waterloo: bsdealwis@math.uwaterloo.ca "Ignorance is the Mother of Devotion" -- Richard Burton From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 21:40:48 1994 From: Scott Reynolds Subject: SUP update To: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is it safe to ask for a SUP update to be run? I have seen one for a few days now... or is it just me? --scott From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 21:48:36 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Snapsot Report - August 21st tar_files To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3124 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Snapshot report. ================ Subtitled: A golf-cart, three penguins, and a pick-axe. Me: agc@uts.amdahl.com (Alistair G. Crooks) Source: tar_files, 21st August 1994, from ftp.iastate.edu Base version of NetBSD: 0.9. Upgrade from previous -current: yes, 4th August 94 sources from ftp.iastate.edu Machine specifics: 386DX/40+387, 16MB RAM, 1542CF, 540 MB SCSI (Quantum), VGA Other software: Matthieu Herrb's XFree86 2.1.1, built July 21 1994. (from ftp.laas.fr) Tar files integrity: good. Additional things to do during upgrade: None Any warnings during compilation: None Any problems during make: None Observations: None Changes from previous snapshot report: (This is taken from the CHANGES file on sun-lamp - last update on 12th Aug 94) sparc bootblocks; integration with disklabel needed (pk) rtld: issue warning if required minor revision can't be found (pk) (although some other changes have taken place - see below) Notes: 1. Once again, everything compiled first time, and my system seems to run fine too. The only funny was : ps, top, and (I suppose) things that grab stuff via kvm had to be recompiled so that they'd run - simply relinking top wasn't enough, and I had to generate object files again before it could grab the correct values. 2. The i386 GENERICAHA kernel config file now has PCI support, specifically for the NCR chip. 3. The way of specifying the configuration in the i386 kernel config file has changed as well - it's now config netbsd swap generic rather than config netbsd root on wd0 swap on wd0 and sd0 which I must say is neater. You'll also need an "options GENERIC" in your config file. 4. catman is still "not yet done" in usr.sbin/Makefile. 5. I modified the Berkeley mpeg_play stuff to work on the NeXT (16-bit colour), and on the 4-bit XFree86 VGA server (XF86_VGA16). Not exactly quick, but it works. Anyone wanting a copy, drop me a line. 6. The Betas of the Sather 1.0 compiler compile fine under NetBSD 1.0_BETA, straight out of the box. Unfortunately, it's not prime time, yet. 7. There wasn't really much point in a Snapshot Report last week, as there weren't any new tar_files on ftp.iastate.edu until 21st August. 8. Ken Hornstein and Mark Weaver have posted some instructions to netbsd-help for those of you i386 massochists who are trying to read MSDOS filesystems. For more info, read the mailing list archives. 9. I've almost got my Magneto-Optical running under VSTa 1.3.1. When it does fly, I'll see about doing something for NetBSD. 10. I thought I saw something some time ago about changing one source-file commands (using the share/mk files) to compile the binary directly, without creating an intermediate object file. Does anyone know what happenned to that? 11. On a more personal note, my wife has now managed to dislocate her shoulder, and so I'm now more pressed for time than I was. All sympathy to mandy.hockley@bra0125.wins.icl.co.uk Cheers, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 21:54:22 1994 To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Snapsot Report - August 21st tar_files X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Subtitled: A golf-cart, three penguins, and a pick-axe. *smirk* > 10. I thought I saw something some time ago about changing one > source-file commands (using the share/mk files) to compile the binary > directly, without creating an intermediate object file. Does anyone > know what happenned to that? umm, for a while the .mk files would generate the programs directly without the intermediate .o file. However, that has the distinct disadvantage that, while it saves you a little bit of disk space, it significantly increases the re-link time when you install a new libc and want to re-link the world. if the .o's for single-source binaries (a large portion of the tree) aren't built, you have to recompile them from source, which takes time... there are also other nice reasons to keep the .o files around (e.g. 'crunch'). so the .mk files were actually converted _back_ to building the .o's, then linking. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Aug 24 22:06:00 1994 Subject: What is the UltraStore 14n? From: Brian de Alwis - MFCF co-op To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 213 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is the UltraStore 14n different from the 14f? Will it work with -current? Thanks. -- Brian de Alwis - University of Waterloo: bsdealwis@math.uwaterloo.ca "Ignorance is the Mother of Devotion" -- Richard Burton From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 00:02:01 1994 From: "Charles M. Hannum" To: agc@uts.amdahl.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Snapsot Report - August 21st tar_files Sender: owner-current-users@sun-lamp.cs.berkeley.edu 2. The i386 GENERICAHA kernel config file now has PCI support, specifically for the NCR chip. That is misleading. The PCI autoconfiguration support is generic. However, there is currently only one PCI device driver, for the NCR 53c8XX chips. 3. The way of specifying the configuration in the i386 kernel config file has changed as well - it's now config netbsd swap generic [and: options GENERIC] rather than config netbsd root on wd0 swap on wd0 and sd0 The old method continues to work fine. `swap generic' is just the preferred way of dealing with generic boot floppies. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 00:26:40 1994 From: Steven Mastandrea Subject: None To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: LeeMail 2.0.4 Sender: owner-current-users@sun-lamp.cs.berkeley.edu how does one unsubscribe from this list? please email replies to lifesaver@uiuc.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 00:33:06 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Sup scanner? Sender: owner-current-users@sun-lamp.cs.berkeley.edu The sup scanner hasn't been run for a few days. What's up? Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 00:49:00 1994 From: Mark Gooderum To: bsdealwi@math.uwaterloo.ca Subject: Re: Can you boot with the aic driver with a SoundBlaster-SCSI-2? Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Can you boot from a disk attached to a SoundBlaster SCSI-2? > > -- > Brian de Alwis - University of Waterloo: bsdealwis@math.uwaterloo.ca > "Ignorance is the Mother of Devotion" -- Richard Burton In a word, no. The Soundblaster SCSI-2 has no BIOS and is non-bus mastering (and in fact doesn't use DMA in the current driver). However, it makes a fine secondary controller and performs about as well (slightly better) than an ISA bus non-buffered IDE controller (my personal experience). -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 00:54:16 1994 From: Jim Babb Subject: Re: Can you boot with the aic driver with a SoundBlaster-SCSI-2? To: bsdealwi@math.uwaterloo.ca (Brian de Alwis) Cc: current-users@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Can you boot from a disk attached to a SoundBlaster SCSI-2? > No, The SoundBlaster SCSI-2 doesn't have a BIOS on it, so you need some other meathod of booting. I use an IDE to boot from, then have a 1 MB scsi disk and CDROM drive attached to the SoundBlaster card. Jim From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 01:14:34 1994 From: "Charles M. Hannum" To: current-users@sun-lamp.cs.berkeley.edu Subject: iBCS2 emulation Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've added a snapshot of Scott Bartram's iBCS2 emulation code to our source tree. This code is incomplete; read the TODO file for more specifics. Scott indicated that he's run (most of?) Informix and a shell, at least, which demonstrates that much of the code (including signals) is at least somewhat functional. If you have SCO or ISC executables, please give it a whirl, find bugs, send diffs, work on the incomplete sections, etc., etc. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 03:42:02 1994 From: Charles Hannum To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu sh: warning: running as root with dot in PATH Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/bin/sh/eval.c U src/bin/sh/parser.c U src/etc/rc.local U src/lib/libc/gen/Makefile.inc U src/libexec/getty/Makefile U src/libexec/getty/extern.h U src/libexec/getty/getty.8 U src/libexec/getty/gettytab.5 U src/libexec/getty/gettytab.h U src/libexec/getty/init.c U src/libexec/getty/main.c U src/libexec/getty/pathnames.h U src/libexec/getty/subr.c U src/libexec/getty/ttys.5 U src/sbin/umount/umount.c U src/share/mk/bsd.lib.mk U src/share/mk/bsd.prog.mk U src/sys/arch/hp300/stand/Makefile U src/sys/arch/hp300/stand/prf.c U src/sys/arch/hp300/stand/tgets.c U src/sys/arch/i386/conf/PAIN U src/sys/arch/i386/conf/TRINITY U src/sys/arch/i386/isa/aha1742.c U src/sys/arch/i386/isa/com.c U src/sys/arch/i386/isa/if_eg.c U src/sys/arch/i386/isa/if_egreg.h U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/ultra14f.c U src/sys/arch/i386/isa/wdreg.h U src/sys/arch/i386/isa/pcvt/Etc/Termcap U src/sys/compat/ibcs2/TODO U src/sys/compat/ibcs2/ibcs2_dirent.h U src/sys/compat/ibcs2/ibcs2_exec.c U src/sys/compat/ibcs2/ibcs2_exec.h U src/sys/compat/ibcs2/ibcs2_fcntl.h U src/sys/compat/ibcs2/ibcs2_grp.h U src/sys/compat/ibcs2/ibcs2_ioctl.c U src/sys/compat/ibcs2/ibcs2_misc.c U src/sys/compat/ibcs2/ibcs2_mount.h U src/sys/compat/ibcs2/ibcs2_pwd.h U src/sys/compat/ibcs2/ibcs2_signal.h U src/sys/compat/ibcs2/ibcs2_stat.h U src/sys/compat/ibcs2/ibcs2_statfs.h U src/sys/compat/ibcs2/ibcs2_syscall.h U src/sys/compat/ibcs2/ibcs2_syscalls.c U src/sys/compat/ibcs2/ibcs2_sysent.c U src/sys/compat/ibcs2/ibcs2_termios.h U src/sys/compat/ibcs2/ibcs2_time.h U src/sys/compat/ibcs2/ibcs2_types.h U src/sys/compat/ibcs2/ibcs2_unistd.h U src/sys/compat/ibcs2/ibcs2_ustat.h U src/sys/compat/ibcs2/ibcs2_utsname.h U src/sys/compat/ibcs2/ibcs2_wait.h U src/sys/compat/ibcs2/makesyscalls.sh U src/sys/compat/ibcs2/syscalls.master U src/sys/dev/vn.c U src/sys/kern/vfs_cluster.c U src/sys/lib/libsa/Makefile U src/sys/lib/libsa/alloc.c U src/sys/lib/libsa/arp.c U src/sys/lib/libsa/bcopy.c U src/sys/lib/libsa/close.c U src/sys/lib/libsa/dev.c U src/sys/lib/libsa/disklabel.c U src/sys/lib/libsa/exec.c U src/sys/lib/libsa/exit.c U src/sys/lib/libsa/getfile.c U src/sys/lib/libsa/gets.c U src/sys/lib/libsa/net.c U src/sys/lib/libsa/nfs.c U src/sys/lib/libsa/open.c U src/sys/lib/libsa/printf.c U src/sys/lib/libsa/rarp.c U src/sys/lib/libsa/read.c U src/sys/lib/libsa/saerrno.h U src/sys/lib/libsa/stand.h U src/sys/lib/libsa/stat.c U src/sys/lib/libsa/strerror.c U src/sys/lib/libsa/ufs.c U src/sys/lib/libsa/write.c U src/sys/nfs/nfs_vnops.c U src/usr.bin/chpass/chpass.c U src/usr.bin/chpass/edit.c U src/usr.bin/chpass/pw_yp.c U src/usr.bin/lex/VERSION U src/usr.bin/lex/flex.skl U src/usr.bin/lex/gen.c U src/usr.bin/lex/initscan.c U src/usr.bin/lex/nfa.c U src/usr.bin/lex/version.h U src/usr.bin/passwd/Makefile U src/usr.bin/passwd/kpasswd_proto.h U src/usr.bin/passwd/krb5_passwd.c U src/usr.bin/passwd/krb_passwd.c U src/usr.bin/passwd/passwd.c U src/usr.bin/passwd/yp_passwd.c U src/usr.bin/vi/USD.doc/edit/Makefile U src/usr.bin/vi/USD.doc/edit/edit.vindex U src/usr.bin/vi/USD.doc/edit/edittut.ms U src/usr.bin/vi/USD.doc/exref/Makefile U src/usr.bin/vi/USD.doc/exref/ex.rm U src/usr.bin/vi/USD.doc/exref/ex.summary U src/usr.bin/vi/USD.doc/vi.man/Makefile U src/usr.bin/vi/USD.doc/vi.man/vi.1 U src/usr.bin/vi/USD.doc/vi.ref/Makefile U src/usr.bin/vi/USD.doc/vi.ref/ex.cmd.roff U src/usr.bin/vi/USD.doc/vi.ref/merge.awk U src/usr.bin/vi/USD.doc/vi.ref/ref.so U src/usr.bin/vi/USD.doc/vi.ref/set.opt.roff U src/usr.bin/vi/USD.doc/vi.ref/spell.ok U src/usr.bin/vi/USD.doc/vi.ref/vi.cmd.roff U src/usr.bin/vi/USD.doc/vi.ref/vi.ref U src/usr.bin/vi/USD.doc/vitut/Makefile U src/usr.bin/vi/USD.doc/vitut/vi.apwh.ms U src/usr.bin/vi/USD.doc/vitut/vi.chars U src/usr.bin/vi/USD.doc/vitut/vi.in U src/usr.bin/vi/USD.doc/vitut/vi.summary U src/usr.bin/vi/common/Makefile U src/usr.bin/vi/common/args.h U src/usr.bin/vi/common/cut.c U src/usr.bin/vi/common/cut.h U src/usr.bin/vi/common/delete.c U src/usr.bin/vi/common/exf.c U src/usr.bin/vi/common/exf.h U src/usr.bin/vi/common/gs.h U src/usr.bin/vi/common/line.c U src/usr.bin/vi/common/log.c U src/usr.bin/vi/common/log.h U src/usr.bin/vi/common/main.c U src/usr.bin/vi/common/mark.c U src/usr.bin/vi/common/mark.h U src/usr.bin/vi/common/mem.h U src/usr.bin/vi/common/msg.c U src/usr.bin/vi/common/msg.h U src/usr.bin/vi/common/options.awk U src/usr.bin/vi/common/options.c U src/usr.bin/vi/common/options.h.stub U src/usr.bin/vi/common/options_f.c U src/usr.bin/vi/common/pathnames.h U src/usr.bin/vi/common/put.c U src/usr.bin/vi/common/recover.c U src/usr.bin/vi/common/screen.c U src/usr.bin/vi/common/screen.h U src/usr.bin/vi/common/search.c U src/usr.bin/vi/common/search.h U src/usr.bin/vi/common/seq.c U src/usr.bin/vi/common/seq.h U src/usr.bin/vi/common/signal.c U src/usr.bin/vi/common/term.c U src/usr.bin/vi/common/term.h U src/usr.bin/vi/common/trace.c U src/usr.bin/vi/common/util.c U src/usr.bin/vi/common/vi.h U src/usr.bin/vi/install/recover.script U src/usr.sbin/bootpd/Announce U src/usr.sbin/bootpd/Announce.old U src/usr.sbin/bootpd/Changes U src/usr.sbin/bootpd/Makefile.UNIX U src/usr.sbin/bootpd/README U src/usr.sbin/bootpd/bootp.h U src/usr.sbin/bootpd/bootpd.8 U src/usr.sbin/bootpd/bootpd.c U src/usr.sbin/bootpd/bootpd.h U src/usr.sbin/bootpd/bootpef.c U src/usr.sbin/bootpd/bootpgw.c U src/usr.sbin/bootpd/bootptab.5 U src/usr.sbin/bootpd/bootptab.mcs U src/usr.sbin/bootpd/bootptest.8 U src/usr.sbin/bootpd/bootptest.c U src/usr.sbin/bootpd/dumptab.c U src/usr.sbin/bootpd/hash.c U src/usr.sbin/bootpd/patchlevel.h U src/usr.sbin/bootpd/print-bootp.c U src/usr.sbin/bootpd/readfile.c U src/usr.sbin/bootptest/Makefile U doc/CHANGES Killing core files: Running the SUP scanner: SUP Scan for current starting at Wed Aug 24 14:48:03 1994 SUP Scan for current completed at Wed Aug 24 14:51:31 1994 SUP Scan for mirror starting at Wed Aug 24 14:51:31 1994 SUP Scan for mirror completed at Wed Aug 24 14:54:19 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 03:48:13 1994 Subject: NFS over TCP From: Tim Newsham To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I am developing code that, amoung other things, makes RPCs to nfsd. I recently noticed that the performance of NFS over TCP is very poor compared to the performance of NFS over UDP. How much poorer? Well there are noticeable delays when performing simple actions such as creating a file or getting the status of a file. Some of the RPC's even failed after the specified timeout (30 seconds). Over UDP these actions appear to be instantaneous. This was observed when using localhost. I didnt notice any swap activity. Is NFS-TCP buggy? Has anyone else noticed this? Tim N. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 08:03:12 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: Filesystem block/device block size discrepancy Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone been running (or attempted to run) an ffs file system on a disk with other than 512 byte sectors? I have been involved in attempting to use Magneto Optical drives on NetBSD running on an Amiga. When using a cartridge with 1024 byte sectors, I have run into what appears to be a nasty little discrepancy in how the b_blkno value passed to the disk drivers is being interpreted. Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno field as the block number of a 512-byte (DEV_BSIZE) block and convert it to the actual block number of the physical block of the disk. The character special devices are accessed through physio() which converts the device offset (in bytes) to a 512-byte block number, which the drivers expect. The block special devices convert the offset to the actual block number on the device based on the sector size in the disk label. As far as I can tell, the ffs routines are also using the actual device block numbers, and are thus accessing the incorrect blocks on a device with 1024 byte blocks. [The cd9660 file system appears to be setting b_blkno to the proper 512-byte block numbers, which the cd driver converts to the proper 2048-byte block number of the CDROM.] I can see two different ways to correct this: changing the ffs and block special device access to use a 512-byte b_blkno, or change the character special device access and the cd9660 file system to use actual device block numbers. I'm not certain which would be the most "correct" way to go. The msdosfs and adosfs file systems could also be potentially affected, but at the moment, the adosfs file system will only work with 512 byte blocks, and I think the msdosfs file system only works with 512 byte blocks as well. I would be nice to have this fixed in the 1.0 release, but I suspect making the changes and fully testing them would not be feasible prior to the release [when ever that might be]. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-tech-kern@sun-lamp.cs.berkeley.edu Thu Aug 25 22:48:17 1994 To: tech-kern@sun-lamp.cs.berkeley.edu Xref: twwells local.sun-lamp.tech-kern:17 From: bill@twwells.com (T. William Wells) Subject: Fast interrupts and serial drivers Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu No serial driver that doesn't use some sort of fast interrupt mechanism is adequate with any of the *BSD kernels. Interrupts are left off far too often and for far too long. The problem is that NetBSD has no fast interrupt support. There are stubs for it, the fast vectors, and a few bits of code here and there, but that's about it. Is anyone working on fast interrupts for NetBSD? Or will I have to do this myself before I can port my serial driver? From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 25 23:05:39 1994 From: chopps@emunix.emich.edu To: slotta@viper.ELP.CWRU.Edu (Douglas Slotta) Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Viking Moniter <9408251524.AA12160@viper.cwru.edu> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu Doesn't this use the same hardware as the A2024 monitor? If so then yes it will work. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Aug 25 23:10:08 1994 From: slotta@viper.ELP.CWRU.Edu (Douglas Slotta) Subject: Viking Moniterm To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 106 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anyone know if NetBSD works with the Viking Moniterm? Err...if so, could you tell me? :) Douglas From owner-current-users@sun-lamp.cs.berkeley.edu Thu Aug 25 23:57:03 1994 To: current-users@sun-lamp.cs.berkeley.edu Xref: twwells local.sun-lamp.current-users:652 From: bill@twwells.com (T. William Wells) Subject: experience installing and using NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu I recently switched from FreeBSD to NetBSD. The switch itself was relatively painless: snarf the binaries and put them into place, update the boot blocks, and go. (Well, more or less.) I'm running the August 1 binary snapshot right at the moment. Of course, getting my previous operating environment running again was a bitch. This was not helped by several problems in NetBSD. Here they are, along with some random observations, in no particular order: Pppd is in /usr/sbin and it uses stuff in /var. This makes it unsuitable for running out of /etc/netstart. Which is a pain, since my net connection is a 56K serial line. The serial driver is an exercise in absurdity. You cannot reliably use it, not at 9600 with a 486/33 and a 16450, nor at 57.6K and a 16550A. The only reason I can tolerate it is that all my communications have end-to-end error checking. Never mind the lack of bidirectional support, which is only insult added to injury. Examining the kernel code suggests that one can share interrupts for the serial driver. Don't believe it. Attempting this merely locked the UARTs up solid. You might want to check out mount -a's response to a missing fstab, to correct the error message. The initial rc.local doesn't include /usr/local/lib. Neither pccons nor pcvt are adequately documented. Let me put that more positively: I won't speak for pccons, because I stopped using it as soon as I could config a new kernel (I like virtual consoles), but the pcvt documentation might as well not exist, for all the good it did me. I had to read the !@#$ code to figure out how to switch screens! Pcvt doesn't interlock something somewhere. If you switch screens while they're being updated, both the original and the destination screen can be garbled. It's irritating that pcvt reinitializes the screen controller whenever you change screens. The getty initial configuration makes things 7 bits. Not 7 bits no parity or anything reasonable, 7 bits. I've worked around it by adding np's where appropriate but this is truly a brain-dead configuration. I have been getting random system crashes. The most frequent are simple hangs, which I suspect are hardware problems. On the other hand, I have been getting some sbdrop panics, and one remrq panic. It's annoying that scsi doesn't allow crash dumps.... There was a bug discovered in FreeBSD, where setting your controlling terminal twice would result in losing a vnode. This bug appears to exist in NetBSD, though I have no idea if it has caused any of my problems. There is a simple patch.... The change in the lseek return value broke about every other package I attempted to install, most of which have a `long lseek' somewhere in them. I couldn't get top to compile, though I'll admit that I only tried standard configurations, rather than code hacking. (Is there a repository for ported software somewhere?) From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 26 00:06:49 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@alpha.bostic.com X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: READ THIS! It's that time again... From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, you can tell that i'm serious about getting the release out the door RSN, becausing i'm writing the release documents. Traditionally, this is done the night before the release, but this time i'm getting a little bit of a head start, so that the documentation is reasonable. Anyway, following the usual pattern, i've done the intro, am skipping the meat (for now), and am now doing the conclusion. The conclusion, as some of you might well be aware, is where the 'credits' section lives. Right now, the 'supporting cast' section, for those people who have put a fair amount of work into NetBSD (bug fixes, software development, etc.) and are actively supporting the project looks like: Supporting cast: John Brezak J.T. Conklin Paul Kranenburg Chris Provenzano Wolfgang Solfrank I know there are a lot more of you that should be mentioned. 8-) I've already got the core team and the people in charge of ports taken care of seperately. However, I wasn't sure who, of the various people that i know deserve mention, would _want_ to be on the list, and I _know_ that I'll forget at least one person, so i'm leaving it in your hands. If you think you deserve a spot, by all means, tell me about it, and i'll add you. Please also include your preferred e-mail address. thanks, chris From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Aug 26 00:11:17 1994 Subject: X11R6 is on ftp.uni-regensburg.de To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 172 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hello, I uploaded X11R6 with an Xamigamono server to ftp.uni-regensburg.de in pub/NetBSD-Amiga/contrib/X11 Please read the X11R6.readme file for more information. Bernd From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 26 00:12:08 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: mpeg_play To: Jan-Hinrich.Fessel@quantum.de (Jan-Hinrich Fessel) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1403 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > In message you write: > ->5. I modified the Berkeley mpeg_play stuff to work on the NeXT > ->(16-bit colour), and on the 4-bit XFree86 VGA server (XF86_VGA16). > ->Not exactly quick, but it works. Anyone wanting a copy, drop me a > ->line. > > What did it need, aside from the obvious "conflicting type" > thingies? I just pulled over mpeg_play 2.0.1 and all I nneded was to > recompile the Motif-1.1.3 shared lib which I haven't been using > quite a long time (but after the off_t). Well, obviously I'm talking about different sources to you, (mine are from s2k-ftp.cs.berkeley.edu:pub/multimedia/mpeg, and the VERSION file says VERSION 2.0, and the README says (Version 2.0; Jan 27 1993)) because there were no conflicting-type thingies, no calls to Motif, and, most specifically, no support for any displays other than 24-bit (TrueColor) or 8-bit (like Suns etc). [There's also monochrome support, but monochrome mpegs are a bit ...uhhm... minimalist for me] The MouseX (Hi!) server which I use on the NeXT has 16-bit colour, and the LCD display on pumpy can only do 4-bit colour, and so I added support for them. Tschuess, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation] From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 00:14:43 1994 Subject: X11R6 is on ftp.uni-regensburg.de To: amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 172 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello, I uploaded X11R6 with an Xamigamono server to ftp.uni-regensburg.de in pub/NetBSD-Amiga/contrib/X11 Please read the X11R6.readme file for more information. Bernd From owner-current-users@sun-lamp.cs.berkeley.edu Fri Aug 26 00:24:44 1994 To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Re: Snapsot Report - August 21st tar_files Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message you write: ->5. I modified the Berkeley mpeg_play stuff to work on the NeXT ->(16-bit colour), and on the 4-bit XFree86 VGA server (XF86_VGA16). ->Not exactly quick, but it works. Anyone wanting a copy, drop me a ->line. What did it need, aside from the obvious "conflicting type" thingies? I just pulled over mpeg_play 2.0.1 and all I nneded was to recompile the Motif-1.1.3 shared lib which I haven't been using quite a long time (but after the off_t). Gruesse Oskar From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 06:34:32 1994 From: SULEWSKIJ@delphi.com Subject: NetBSD 1.0 and install To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: INTERNET"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu I just got the files for netbsd 1.0 and I am using the install from august 1st. How do you get it to install so that you don't need an install disk. And when I do boot up, I have a root directory and the altroot directory off of there. All the files for /bin /etc and /sbin are in /altroot. I need these to go into the root. But I don't know how. I can't use vi because it doesnt recocnize my term=vt200. Can anybody give me some advice as what to do? I have a stock A3000 with 8megs fast 2megs chip. Joe Sulewski Unix-wanta-be From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 13:50:47 1994 From: umpaul11@cc.umanitoba.ca Subject: Re: NetBSD 1.0 and install To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3322 Sender: owner-amiga@sun-lamp.cs.berkeley.edu SULEWSKIJ@delphi.com writes: > > I just got the files for netbsd 1.0 and I am using the install from > august 1st. How do you get it to install so that you don't need an > install disk. And when I do boot up, I have a root directory and the > altroot directory off of there. All the files for /bin /etc and /sbin are in > /altroot. I need these to go into the root. But I don't know how. I can't > use vi because it doesnt recocnize my term=vt200. Can anybody give me > some advice as what to do? > I have a stock A3000 with 8megs fast 2megs chip. > > Joe Sulewski Unix-wanta-be > I'm a complete newbie as far as NetBSD is concerned, so take anything I say with a huge economy sized grain of salt :) The install doc I found on colombo.telesys-innov.fr wasn't very clear and had a few errors in it (yes I know it's a prerelease, but it's cruel to unleash it on helpless newbies like me without explicit instructions :) I assume you managed to boot from the install disk, newfs your partitions and untar everything to /altroot? The /altroot you use to mount your root partition is just a mountpoint on the bootdisk which allows you to reference the partition you are going to be using as root, when you actually boot off the partition it will will be seen as / and the usr partition will be in /usr (another mountpoint on the root partition). You should boot in single user mode in order to to use vi, I don't think the required files are present on the floppy (hell it doesn't even have cp, you have to use some unholy tar hack :) Edit the fstab.tmp file to reflect the way you have your system set up and save it as fstab. It might be easier to edit it under Amigados and just copy it over if you are having trouble with the editor. I've found a few flaws in the install doc, I don't know if they have been listed before since I just joined the list, but I'll post them in case they haven't been mentioned. 1) one of the lines says to tar -zxvf /mnt/netbsd.gz in order to extract the kernel onto the root partition, but this does not work. netbsd.gz will probably be uncompressed at this point because you needed it to boot and it is also not a tarfile. You can just use cp once you have booted from your hard drive since it is not required in order to boot netbsd (at least on the BSD side). 2) tar -cf - /dev | tar -xvpf - is a neat copy hack, but it doesn't do what was intended. the previous line tells you to cd to /altroot/dev and then tar creates an archive with /dev/* in it and pipes it to tar which extracts /dev/* INSIDE /dev so you end up with all your devices in /dev/dev :) You should cd to /altroot instead and it will work. If you don't catch this NetBSD will boot fine up to the point where it configures the consoles/mice then hang with no apparent cause. It took me a week to figure out that it wasn't some SCSI sync problem or something else since I wasn't looking for simple mistakes :) 3) /etc/fstab.tmp has /dev/sd0d mounted as /usr which is the Amigados partition, not sd0e or whatever you used for /usr. You should be very careful when editing this file anyway, but it would be nice to have to have the default set as the most common device. I hope that helps a bit, it was sufficient to get my system running, but maybe I was just lucky :) Kerry From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 13:54:25 1994 From: jshardlo@london.micrognosis.com (John Shardlow) Subject: Solution: NetBSD/Linux missing columns on console To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1417 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Dear Net Folks, In case anyone is interested I have finally solved my missing columns problem with NetBSD and Linux. After some recent testing (which Michael Hitch helped me with) I found that the problem only occurred when writing to CHIP memory using byte writes. Short and long word writes worked OK. This pretty much convinced me that it was a hardware problem so yesterday I opened up the A3000 and found the CHIP RAM slots. The first meg of CHIP RAM is surface mounted so if that was causing the problem I would have been stuffed ! The other meg was socketted so I ripped it out and rebooted and the problem was gone. I also tried re-inserting the chips in a different order to see if it was just one dodgy chip but the problem was the same. (Same byte missing out of each long word). This makes me think that it could be a problem in the memory interface not actually with the chips. I also tried putting half a meg back but the half meg did not get configured into the system so I guess this is not supported. Presumably I could put the memory back for use under AmigaOS and then hack loadbsd so that it only uses the first meg under NetBSD ? (AmigaOS doesn't suffer from this problem, presumably because it always accesses the CHIP RAM using short or long word writes ? ) Anyway, I'm pleased that its finally sorted out and thanks to everyone who helped me (especially Michael Hitch). John :-) From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 14:20:12 1994 From: chopps@emunix.emich.edu To: amiga@sun-lamp.cs.berkeley.edu Subject: ASDG LAN Rover X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I added the aditional code to make the LAN Rover work I think. I even have one here. However I think mine is an early revision as it doesn't support interrupt level 2 (which a readme indicates it should) Basically I would appreciate it if everyone who has this board would send me a copy of either their netbsd initial boot diagnostics (see dmesg(8)) or output from showconfig (ados). I can then generate a generic kernel for you to try and see if your board works. One thing I noticed is that the manufacturer ID is 1023 on mine and the product id is 254 this conflicts with what I saw someone post so perhaps when (and if) they changed the board they also changed these. Anyway I haven't felt like hacking the if_ed.c driver to work with the NIC interrupting at level 6 yet but I figured I could test it for people who had the other type boards.. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Aug 26 15:27:36 1994 From: Hubert Feyrer "NetBSD 1.0 and install" (Aug 25, 11:32pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I just got the files for netbsd 1.0 and I am using the install from > august 1st. How do you get it to install so that you don't need an > install disk. And when I do boot up, I have a root directory and the You can't, because there will no longer be any rootfs. What's wrong with installing from disk? > altroot directory off of there. All the files for /bin /etc and /sbin are in > /altroot. I need these to go into the root. But I don't know how. I can't > use vi because it doesnt recocnize my term=vt200. Can anybody give me > some advice as what to do? Hu? /bin etc. are in / on the floppy... and there's no vi at all on it. :) Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-tech-kern@sun-lamp.cs.berkeley.edu Sat Aug 27 04:39:48 1994 To: bill@twwells.com (T. William Wells) Cc: tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: Fast interrupts and serial drivers From: Bakul Shah Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu > Is anyone working on fast interrupts for NetBSD? Or will I have > to do this myself before I can port my serial driver? I have started working on it but don't let that stop you. You'll probably get done before me. In an earlier message you had complained about the lack of bidirectional support. I have posted the diffs to com.c to do just that a few days ago. I hope you picked them up. As for sharing interrupts with the serial driver, that works for me; I have com1..com4 at the usual IO addresses and irq3/4. The change in lseek & friends comes with 4.4bsd. You just have to bite the bullet. No use complaining. If pppd in /usr/sbin causes you grief, may be because you have /usr on a separate filesystem, just copy it to /usr/sbin on the root filesystem. This pppd will get hidden when you mount /usr but atleast it will let you run it from /etc/netstart. Since you wrestled with pcvt and won, how about writing something up to help others? Sorry about mixing up responses to two separate messages in one. Bakul Shah From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 27 05:15:04 1994 Subject: Re: Couple of questions.. To: gillham@andrews.edu (Andrew Gillham) From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 480 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > connection at 19.2k, the other has a mouse on it. Even > without X running I get 'silo overflow' errors quite often > on my ppp link. Is this related to my PIO IDE drive? No, I have them too (with an Adaptec 1742, one NS16550AFN on a 38400/14400 PPP link). Martin -- Unix is a lot more complicated of course - the typical Unix hacker never can remember what the PRINT command is called this week. -- Ed Post, Real Programmers Don't Use PASCAL From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 27 05:26:21 1994 From: Thor Lancelot Simon To: port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Context switch times for NetBSD 2x those of 386BSD 0.1? Sender: owner-current-users@sun-lamp.cs.berkeley.edu A recent thread in comp.arch discusses context switch times for various operating systems on modern hardware. Someone who works at QNX just posted a list of measurements he's taken; it shows context switch times of 210ms and 380ms for 386BSD 0.1 and NetBSD on the same hardware. This seems potentially indicative of a disturbing trend. Is any attempt being made to keep the kernel in line so far as code bloat goes? Is anyone profiling the kernel, or otherwise actively working on this issue? I can go spend a few weeks taking measurements if someone's not already. Thor P.S. I've attached a comp.arch article below. Newsgroups: comp.arch,comp.benchmarks,comp.sys.super Path: panix!MathWorks.Com!europa.eng.gtefsd.com!howland.reston.ans.net!torn!nott!cunews!revcan!quantum!danh From: danh@qnx.com (Dan Hildebrand) Subject: Re: Overheads of Parallel Systems (Summary) Message-ID: Date: Thu, 25 Aug 94 12:23:24 GMT Organization: QNX Software Systems References: <33gfr2$atr@monalisa.usc.edu> Lines: 67 Xref: panix comp.arch:34185 comp.benchmarks:6377 comp.sys.super:3562 In article <33gfr2$atr@monalisa.usc.edu>, Zhiwei Xu wrote: > >(3) Context-switching times in microseconds > >Platform, Operating System Context Switching Time >Processor Speed (Mhz) > >HP-735, 99 HP-UX 9.01 68 >486DX, 33 QNX 4.2 80 >DEC 4000/610, 160 OSF/1 v1.3 87 >486DX2, 66 Linux 0.99.10 98 >IBM RS6000/580, 62 AIX 3.2 102 >Sun SS10, 40 SunOS 4.1.3 128 >Sun SS10, 40 SunOS 5.2 225 >Sun SS2, 40 SunOS 5.2 454 Note that these times are the measured result of a pair of processes signalling each other, which includes the additional kernel call overhead for the signalling calls. A benefit of this approach is that the source is portable to a wide range of UNIX systems, howver, a more correct result, but currently less portable, can be obtained by using the sched_yield() call in a POSIX 1003.1b (previously 1003.4) OS. Since this approach executes only one kernel call per context switch, with no signal processing being done, it is a more accurate indication of the actual context switch time. Without the signal processing, the intervals are also much shorter. For example, the Pentium/90 number for QNX drops from 23 usec to 2 usecs, the 486/66 number drops from 44 to 5 usecs. Here's a more complete listing of numbers collected from various responses on the net: Platform, Operating System Context Switching Time Processor Speed (Mhz) in microseconds 90 MHz PCI Pentium QNX 4.21 23 60 MHz ALR Pentium QNX 4.2 28 100 MHz HP-747x HP-RT 1.1 34 66 MHz 486DX2 QNX 4.2 44 100 Mhz HP-735 HP-UX 9.01 68 50 MHz HP-742 HP-RT 1.1 71 33 MHz 486DX QNX 4.2 80 150 MHz 21064 DEC OSF/1 v1.3 93 80 MHz HP-712/80 HP-UX 9.05 96 40 MHz DEC 5000/240 Ultrix 4.2 98 66 MHz 486DX2 Linux 0.99.10 98 150 MHz DEC 3000/500 ? 100 62 MHz IBM-RS6000/580 AIX 3.2 102 66 Mhz Snake HP-UX 9.x 106 150 MHz DEC 3000/400 ? 127 40 Mhz Viking SunOS 4.1.3 128 25 MHz DEC 5000/200 ? 154 50 MHz R4000 SGI ? 158 33 MHz Sparc SunOS 4.1.1 198 40 MHz MIPS R3000 Ultrix 4.3 198 33 Mhz 486 386BSD 0.1 210 85 MHz Sparcstation-5 SunOS 4.1.3_U1 210 50 Mhz RIOS AIX 3.2 212 20 MHz DEC 5000/120 ? 281 33 MHz R3000/3010 SGI Irix 4.0.5 345 33 MHz 486 NetBSD 380 50 MHz Sparcstation-LX Solaris 2.3 620 50 MHz 486DX2 Solaris 636 16 MHz 386SX NetBSD 2603 -- Dan Hildebrand email: danh@qnx.com QNX Software Systems, Ltd. QUICS: danh (613) 591-0934 (data) (613) 591-0931 x204 (voice) mail: 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Aug 27 05:28:45 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mark@good.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Block Mail Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Aug 26, 2:45pm, Mark Gooderum wrote: > > From: "Michael L. Hitch" > > Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno > > field as the block number of a 512-byte (DEV_BSIZE) block and convert it > > to the actual block number of the physical block of the disk.... > > This jives with the behavior I've seen. Disklabel writes the label > and reads it, okay, but fsck and newfs barf using the raw device about > 1/2 way through the disk (because block #'s are doubled...it runs off > the end of the disk). If this is on the i386 port, I think this behaviour may be because the bounds_check_with_label() routine doesn't take into account the physical block size. At the point that sd.c calls bounds_check_with_label(), the partition size is in physical sector units, but the block number and size are in DEV_BSIZE units. The check is not being done correctly. [I'm not certain how the disk label would be set up for the i386. I found that the partition size and partition offset had to be in units of the device physical sector size in order for newfs to work correctly.] Hmmm - an incorrect or inconsistent partition offset could be rather dangerous. It could easily cause newfs to write at the wrong spot on the disk. > I would love to help make this work (I've got a couple of older but very > big 1024 block SCSI drives I scrounged that otherwise work). > > I've played a bit with having physio() stuff the block value into both > b_lblkno and b_blkno. I don't think will work - the getblk() routine in kern/vfs_bio.c is already setting b_lblkno and b_blkno to the specified block. It might work better if physio() ensured that b_lbkno was zeroed. > So far it doesn't quite work yet. I still get the symptom that > I can label the disk, but fsck barfs, and the kernel complains about > no disk label when first booting. If fsck is still having problems thinking it's going off the end of the partition, that problem is probably because bounds_check_with_label() doesn't take into account the difference in the units between the partition size and the block number + I/O length. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 29 01:52:13 1994 From: Hartmut Kuehn Subject: Re: NetBSD 1.0 and install To: umpaul11@cc.umanitoba.ca Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1017 Sender: owner-amiga@sun-lamp.cs.berkeley.edu umpaul11@CC.UManitoba.CA: > > SULEWSKIJ@delphi.com writes: > > > > /altroot. I need these to go into the root. But I don't know how. I can't > > use vi because it doesnt recocnize my term=vt200. Can anybody give me > > some advice as what to do? For bash or sh use export TERM=vt200 Be sure, after you booted from your new partition, that the file /etc/termcap is there or at least a link (ln -s) to /usr/share/.../termcap.(something) (sorry, I'm at work, but you'll find it :-) Then it should work. Bye ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@{cs.tu|macbeth.in}-berlin.de * * (or kuehaaaf@zrz.tu-berlin.de) * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Aug 29 02:13:36 1994 From: Hubert Feyrer X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 29 03:32:44 1994 From: Alain Chofardet Subject: Re: getty and a modem, how to set up To: qbradley@sol.UVic.CA (Quetzalcoatl Bradley) Cc: amiga@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 72.14] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi. > > I created a line in ttys that looks like: > > tty00 "/usr/libexec/getty std.38400" vt100 on secure rtscts > > But as soon as I go to multi-user getty starts talking to the modem a > lot, it tries to run login, fails to get a user, and tries again. > I had exactly the same problem a few months ago. I solved it using the slattach command. In that case, only dial-in calls are possible (if dial-out are, tell me...). Alain Chofardet E-mail : Alain.Chofardet@ramses.fdn.org From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 29 03:38:26 1994 From: "Michael K. Sanders" Subject: Ethernet, ignore... To: amiga@sun-lamp.cs.berkeley.edu (amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 322 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sorry, ignore that last message. I didn't realize that I had to change a jumper on the A2065 in order for it to use the external transceiver. Now that I've finally got my system up and (mostly) running, I'd just like to take a minute to thank all of you that have made it possible. You're doing a great job, keep it up. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Aug 29 03:48:36 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mark@good.com Subject: Re: Block Mail Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Aug 26, 2:45pm, Mark Gooderum wrote: > I would love to help make this work (I've got a couple of older but very > big 1024 block SCSI drives I scrounged that otherwise work). > > I've played a bit with having physio() stuff the block value into both > b_lblkno and b_blkno. Here's a solution I'm trying right now. I've been running in on my 512-byte sector disks with no problems. It also seems to be working on an M-O disk using 1024-sectors. Newfs and fsck work fine, and the filesystem can be mounted. The physio() routine sets the B_RAW flag, and my change uses that flag to decide how to handle the b_blkno field. [I.e. if B_RAW is set, then the b_blkno value is in DEV_BSIZE blocks, otherwise the b_blkno value is in real blocks.] There are two changes - one to the SCSI disk driver (sd.c) and the other to the bounds_check_with_label() routine, since the meaning of b_blkno is different. Note that the partition size must be in real blocks, not in DEV_BSIZE blocks; newfs uses the real block size when calculating the file system size. The change to sd.c is fairly simple: *** /mnt/src/sys/scsi/sd.c Wed Jul 27 08:24:59 1994 --- /sys/scsi/sd.c Fri Aug 26 21:02:46 1994 *************** *** 491,499 **** * We have a buf, now we know we are going to go through * With this thing.. * ! * First, translate the block to absolute */ ! blkno = bp->b_blkno / (sd->params.blksize / DEV_BSIZE); if (SDPART(bp->b_dev) != RAW_PART) { p = &sd->sc_dk.dk_label.d_partitions[SDPART(bp->b_dev)]; blkno += p->p_offset; --- 491,501 ---- * We have a buf, now we know we are going to go through * With this thing.. * ! * First, translate the block to absolute if B_RAW */ ! blkno = bp->b_blkno; ! if (bp->b_flags & B_RAW) ! blkno /= sd->params.blksize / DEV_BSIZE; if (SDPART(bp->b_dev) != RAW_PART) { p = &sd->sc_dk.dk_label.d_partitions[SDPART(bp->b_dev)]; blkno += p->p_offset; *************** *** 645,655 **** */ sd->sc_dk.dk_label.d_partitions[0].p_offset = 0; sd->sc_dk.dk_label.d_partitions[0].p_size = ! sd->params.disksize * (sd->params.blksize / DEV_BSIZE); sd->sc_dk.dk_label.d_partitions[0].p_fstype = 9; /* XXXX */ sd->sc_dk.dk_label.d_partitions[RAW_PART].p_offset = 0; sd->sc_dk.dk_label.d_partitions[RAW_PART].p_size = ! sd->params.disksize * (sd->params.blksize / DEV_BSIZE); sd->sc_dk.dk_label.d_npartitions = MAXPARTITIONS; sd->sc_dk.dk_label.d_secsize = sd->params.blksize; --- 647,657 ---- */ sd->sc_dk.dk_label.d_partitions[0].p_offset = 0; sd->sc_dk.dk_label.d_partitions[0].p_size = ! sd->params.disksize; sd->sc_dk.dk_label.d_partitions[0].p_fstype = 9; /* XXXX */ sd->sc_dk.dk_label.d_partitions[RAW_PART].p_offset = 0; sd->sc_dk.dk_label.d_partitions[RAW_PART].p_size = ! sd->params.disksize; sd->sc_dk.dk_label.d_npartitions = MAXPARTITIONS; sd->sc_dk.dk_label.d_secsize = sd->params.blksize; This also requires some changes to the bounds_check_with_label() routine in disksubr.c. Not being very familiar with real disk labels and the i386 stuff, I'm not certain what would need to be changed for the i386 port. This is what I currently have for the Amiga routine: pp = &lp->d_partitions[DISKPART(bp->b_dev)]; if (bp->b_flags & B_RAW) { maxsz = pp->p_size * (lp->d_secsize / DEV_BSIZE); sz = (bp->b_bcount + DEV_BSIZE) / DEV_BSIZE; } else { maxsz = pp->p_size; sz = (bp->b_bcount + lp->d_secsize - 1) / lp->d_secsize; } if (bp->b_blkno < 0 || bp->b_blkno + sz > maxsz) { if (bp->b_blkno == maxsz) { /* * trying to get one block beyond return EOF. */ bp->b_resid = bp->b_bcount; return(0); } sz = maxsz - bp->b_blkno; if (sz <= 0 || bp->b_blkno < 0) { bp->b_error = EINVAL; bp->b_flags |= B_ERROR; return(-1); } /* * adjust count down */ if (bp->b_flags & B_RAW) bp->b_bcount = sz << DEV_BSHIFT; else bp->b_bcount = sz * lp->d_secsize; } > I also haven't made the physio() like changes to the CD code, > I have no CD drive to test with. The CD code shouldn't require any changes. The SCSI CD driver is separate from the SCSI disk driver. At least for the current time, the cd9660 file system is using DEV_BSIZE logical blocks, which is the same as physio(), so nothing different is required in cd.c. However, thinking about it reminded me that access to /dev/cd0 won't work correctly because it uses the real sector size to calculate the block number. That's probably nothing to worry too much about at this time. Because the cd driver is also calling bounds_check_with_label(), the check isn't going to be entirely correct for block accesses, but I don't think it will break CDROM access. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 29 03:52:01 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- pk Wed Aug 24 13:00:59 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gas/config In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gas/config Modified Files: tc-sparc.c Log Message: Locate source line of relocation errors; currently this only works when one of the listing options is on. pk Wed Aug 24 13:04:54 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gas/config In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gas/config Modified Files: obj-aout.c tc-i386.h tc-m68k.c tc-m68k.h tc-sparc.h Log Message: Enable listings. pk Wed Aug 24 13:05:57 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gas/config In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gas/config Modified Files: tc-ns32k.h Log Message: Enable listings --------------------------------- chopps Wed Aug 24 13:50:40 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/include Modified Files: param.h Log Message: add USPACE --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Mon Aug 29 04:04:31 1994 From: Hubert Feyrer X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga@netbsd.org Mon Aug 29 06:24:21 1994 From: "Michael K. Sanders" Subject: Ethernet... To: amiga@sun-lamp.cs.berkeley.edu (amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 253 Sender: owner-amiga@netbsd.org Okay... I've followed the directions in the Networking FAQ to the letter and I have had no success getting my A2065 to work with NetBSD-Amiga 1.0 Beta. What kind of information is needed from me to get some insight? Thanks in advance for any help... From owner-current-users@netbsd.org Mon Aug 29 07:03:09 1994 From: "John C. Hayward" Subject: Is there a problem with mprotect? To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@netbsd.org Dear NetBSDers, I am attempting to report Modula-3 from NetBSD-09 to NetBSD-1.0_BETA. I have picked up the binary tar files of NetBSD from ftp.iastate.edu dated Aug 1. I then picked up the source tar files from ftp.iastate.edu dated Aug 21. I have built a new vmunix along with most of the other programs. I have two problems: 1) ps seems not to work reporting: ps: proc size mismatch (18676 total, 640 chunks) Has anyone else seen this problem? I tried remaking the libraries and remaking ps but I still get this error message. 2) The runtime system of Modula-3 supports threads and for the stack for each thread it makes one page of the stack readonly with mprotect to detect stack overflows. The problem seems to be that the area of memory protected by mprotect is different than what was asked for. It seems to protect after about byte 2400 and stop protecting after 4670. This causes problems because the pagesize reported back is 4096. Attempting to write to memory locations just above the asked for protected area results in signal causing the program to halt. The manual entry for mprotect indicates that not all implementations guarentee protection on a page basis. Does NetBSD-1.0_Beta for I386 support protection on a page basis? The manual entry for malloc indicates that if the size of the object asked for is pagesize or larger the memory will be paged aligned. The addresses I seem to get from malloc independent of size seem to be multiples of 8192. Does NetBSD-1.0_Beta for I386 have pagesize of 4096 (like reported from getpagesize) or 8192? I have written short C programs in which mprotect seems to be doing it's stuff correctly. In the Modula-3 stuff I am porting I have gone down to the level to make sure the parameters were correct for calls to mprotect and the assignment. I am not sure if there is a problem with mprotect or not. Is anyone else seeing any problems with mprotect? Any suggestions would be appreciated. johnh... johnh@david.wheaton.edu From owner-amiga@netbsd.org Mon Aug 29 11:39:37 1994 Subject: elm 2.4 PL23 + emacs -> no go! :-( To: amiga@sun-lamp.cs.berkeley.edu From: Jukka Marin 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: 1127 Sender: owner-amiga@netbsd.org Dear All, I installed elm 2.4 PL23, but can't make it work with emacs. First of all, I'm running a customized kernel #744 (what? update? :-) and other oooold stuff. elm works fine by itself. However, when I try to send mail, elm says it's starting the editor - and after a short time, it asks whether I want to e)dit message, edit h)eaders, s)end it, or f)orget it. It's just like emacs exitted immediately. :-( What am I doing wrong (does elm work with new kernels?)? Please help. Jukka Marin P.S. I'm still looking for the missing files of the A2232 driver; I haven't found any docs for the 6502 code and the ql.h file is missing as well :( - | Mail: Jukka Marin | E-Mail: jmarin@messi.uku.fi | | Metsurintie 17 B 8 | FAX/voice: +358 71 283 2793 | | 70150 Kuopio | There's God above computers - | | FINLAND | Love beyond the hate | \ / \ If a train station is where the train stops, what is a workstation? / From owner-netbsd-users@netbsd.org Mon Aug 29 12:04:41 1994 From: Forrest Aldrich Subject: WD7000 SCSI controller support (help request) To: netbsd-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-netbsd-users@netbsd.org I'm looking for a copy of whatever is the current code for supporting the WD7000. I understand this is still in 'development,' however I may have someone who is willing (and experienced) to help out. Thank you (please respond to me directly, via email) Forrest From owner-current-users@netbsd.org Mon Aug 29 12:33:46 1994 To: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: SIO[CG]ARP Sender: owner-current-users@netbsd.org Has anyone a workaround for the missing SIO[CG]ARP ioctls handy, or, to be moreprecisely, has anyone gotten isode-7.0 snmp to run on NetBSD-1.0C ? Gruesse Oskar ============================================================================== Tragbar ist, was nicht herunterfaellt. oskar@zappa.unna.ping.de ============================================================================== From owner-current-users@netbsd.org Mon Aug 29 12:38:38 1994 From: Mark Gooderum To: mark@good.com, current-users@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Block Mail X-Sun-Charset: US-ASCII Sender: owner-current-users@netbsd.org One other point worth noting... The write() from newfs that fails fails before it gets to sdstart(), so I'm really having a hard time figuring out where the EINVAL is coming from. -Mark From owner-current-users@netbsd.org Mon Aug 29 12:43:25 1994 From: cagney@highland.oz.au (Andrew Cagney) To: current-users@sun-lamp.cs.berkeley.edu Subject: VI in dumb mode? Sender: owner-current-users@netbsd.org Hi, I've noticed that the new VI(1) (to 0.9) no longer works in dumb mode. i.e.: $ touch test $ TERM=unknown vi test test: new file: line 1 Error: Initscr failed: No such file or directory No TERM environment variable set, or TERM set to "unknown" $ or $ TERM=dumb vi test test: new file: line 1 Error: Initscr failed: No such file or directory dumb: terminal type lacks necessary features $ now fail. I think of this as a *serious* loss of functionality. Any history to this? (Could someone please feed this into the gnats system) regards Andrew (1) I'm refering to the vi found in the early august 1.0 beta snap shot From owner-current-users@netbsd.org Mon Aug 29 12:56:30 1994 From: Mark Gooderum To: osymh@gemini.oscs.montana.edu Subject: Re: Block Mail Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Sender: owner-current-users@netbsd.org You gave me the clue I needed... > That's probably because the bounds_check_with_label() is being called > in sdstrategy() and being errored out before the I/O is even queued up. Exactly... I think I've got it, but I'll have to wait until this evening to play... I added my block number massageing to sdstart(), however, the I/O first calls sdstrategy() which calls bounds_with_check() *if* the disk isn't the whole disk partition. So dd's on and off /dev/rsdXd work... but a newfs then goes to /dev/rsdXa or whatever, and goes though the bounds check. In this case the request is still in logical block numbers, about 1,200,000 in my case, the disk is in physical sectors, no more an 600,000...so it shows as off the end of the partition and returns EINVAL. I'll look at what the lblkno and blkno actually look like when they get down to sd.c (and wd so I don't break anything) and adjust the hack as appropriate (maybe add a flag instead...there's a few still available in the buf flags field)...and move the fix up into sdstrategy(). So that should fix two of the three problems...now to get the disklabel code to work (the disklabel gets updated okay in the kernel, but it doesn't get out to the disk correctly because on boot the kernel again complains it's gone). I may actually get this working...scary... -Mark From owner-amiga@netbsd.org Mon Aug 29 12:58:18 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Contributions for 1.0" (Aug 16, 10:16pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Hubert Feyrer" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Contributions for 1.0 Sender: owner-amiga@netbsd.org On Aug 16, 10:16pm, "Hubert Feyrer" wrote: > x11_dist.tar.gz: 50% of this crash. :-( Works fine here... Requires old libs though :-) -- Markus Illenseer From owner-current-users@netbsd.org Mon Aug 29 13:00:04 1994 From: Peter Galbavy Subject: Re: READ THIS! It's that time again... To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 647 Sender: owner-current-users@netbsd.org > Right now, the 'supporting cast' section, for those people who have > put a fair amount of work into NetBSD (bug fixes, software > development, etc.) and are actively supporting the project looks like: How 'bout a "Reference Site" list. Like we use the i386 and sparc ports for our core routers... I think that's a pretty critical usage of them. I am sure others will be happy to say publicly that they are happy with NetBSD ? Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@netbsd.org Mon Aug 29 13:07:52 1994 From: Andrew Cagney To: current-users@sun-lamp.cs.berkeley.edu Subject: LPT0 causing RESET? Sender: owner-current-users@netbsd.org Hi, I'm trying to get a printer to correctly work on an x86 computer's parallel port. To test it I was using: # cp post-script-file /dev/lpt0 Depending on how the remote printer is configured, the computer would reset (no core dump and no panic message). Is this normal? Andrew More info .... Printer: Lexmark 4039 10R Config: Parallel Protocol/Honor Init: STANDARD/ON RESET Parallel Protocol/Honor Init: STANDARD/OFF RESET Parallel Protocol/Honor Init: FASTBYTES/ON cp: /dev/lpt0: Operation not permitted Parallel Protocol/Honor Init: FASTBYTES/OFF Prints ok! LPT Card: GMIO-470 (An all singing all dancing video+fd+com+lpt+isa + .... ) Dmesg output: NetBSD 1.0_BETA (GENERICAHA) #3: Mon Aug 1 16:48:16 PDT 1994 cgd@sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/compile/GENERICAHA CPU: i486DX (486-class CPU) real mem = 16384000 avail mem = 14352384 using 225 buffers containing 921600 bytes of memory pc0 at isa0 port 0x60-0x6f irq 1: color com0 at isa0 port 0x3f8-0x3ff irq 4: ns82450 or ns16450, no fifo com1 at isa0 port 0x2f8-0x2ff irq 3: ns82450 or ns16450, no fifo lpt0 at isa0 port 0x378-0x37f irq 7 fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2 fd0 at fdc0 drive 0: 1.2MB 80 cyl, 2 head, 15 sec fd1 at fdc0 drive 1: 1.44MB 80 cyl, 2 head, 18 sec aha0 at isa0 port 0x330-0x333 irq 11 drq 5 scsibus0 at aha0 aha0 targ 0 lun 0: SCSI2 direct fixed sd0 at scsibus0: 520MB, 2493 cyl, 5 head, 85 sec, 512 bytes/sec ed2 at isa0 port 0x300-0x31f irq 10: address 00:40:c7:21:b2:f2, type NE2000 (16-bit) ie0: unknown AT&T board type code 0 ie0: can't map 3C507 RAM in high memory npx0 at isa0 port 0xf0-0xff: using exception 16 biomask 840 netmask 41a ttymask 1a changing root device to sd0a From owner-current-users@netbsd.org Mon Aug 29 13:12:35 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Subject: Bringing up NetBSD on a PCI based machine. Sender: owner-current-users@netbsd.org Is it possible to bring up NetBSD-current on a PCI based 486? I just purchased a new computer from Gateway2K, their 4D66 package which has a PCI based ATI Ultra AXO video board, and a 740MB Enhanced IDE drive hanging on a PCI controller. I tried to install NetBSD-0.9 on it to bring it up to NetBSD-current, but the disklabel keeps on failing. pfdisk says that the drive has 708 cyls with 32 heads, while the probe during boot lists the drive as having 1416 cyls with 16 heads. When I try to do the disklabel with the params during the boot, it acts like it worked and the inst-01 floppy copies the files to the disk. I even run a few programs from /mnt and they work fine ( drive light even flashes ). But when I reboot to copy over the kernel to the disk it complains that it can't mount the drive because the disk label is bad. When I check the drive with disklabel, all the parameters look fine except the number of heads is not 16 but 32, and disklabel complains that the partition map is overflowing the drive. Next I I tried to use the disk params that pfdisk reported, and now disklabel complains about wdctrlreset( -1 ) [some other error ] (-4) which causes a kernel panic. Now admittedly, I haven't brought up a machine with 0.9 since about 3 months after it came out, so I'm probably forgetting things about the drive params and other little things ( like when the install program asks for the mount point, should you type /usr or just usr? I thought one caused problems but I can't remember which. ) Would it be easier to just bring NetBSD 0.9 up on a SCSI drive hanging off of a 1542 and then just disklabel and transfer the files over to the internal Enhanced IDE? More importantly, has anyone else done this? ( PCI w/ Enhanced IDE ) or am I just wasting my time on something that isn't ready yet. Thanks for any info, Brian Moore Bewildered NetBSD Installer From owner-current-users@netbsd.org Mon Aug 29 13:55:59 1994 To: "Chris G. Demetriou" Cc: Thor Lancelot Simon , port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Context switch times for NetBSD 2x those of 386BSD 0.1? From: Havard Eidnes Sender: owner-current-users@netbsd.org > > A recent thread in comp.arch discusses context switch times for various > > operating systems on modern hardware. Someone who works at QNX just > > posted a list of measurements he's taken; it shows context switch times > > of 210ms and 380ms for 386BSD 0.1 and NetBSD on the same hardware. > ... > (3) our switch does a fair amount more, in terms of keeping more > careful process accounting information, than the 386BSD > switch() did. In particular, mi_switch() calls microtime() > twice, and that's not a cheap function. Well, as it turns out, there's really no need to be defensive about it. :-) First, note that the NetBSD entries in the results list did not have a version number attached to them. I just went through my mailbox and dug out some results run with the ctxsig.c program posted by lm@sun.com (?) on comp.arch about a year ago. At that time we ran the test on a i486dx/2-66 with NetBSD 0.8, and got the reported 380ms context switch time. I just reran the test program on *identical* hardware with NetBSD 1.0_BETA (as of a few days ago), and the context switch time on this platform has gone down to 110ms. Well done! - Havard From owner-current-users@netbsd.org Mon Aug 29 13:58:25 1994 From: Mark Gooderum To: mark@good.com, current-users@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Block Mail X-Sun-Charset: US-ASCII Sender: owner-current-users@netbsd.org > > This jives with the behavior I've seen. Disklabel writes the label > > and reads it, okay, but fsck and newfs barf using the raw device about > > 1/2 way through the disk (because block #'s are doubled...it runs off > > the end of the disk). > > If this is on the i386 port, I think this behaviour may be because the > bounds_check_with_label() routine doesn't take into account the physical > block size. At the point that sd.c calls bounds_check_with_label(), > the partition size is in physical sector units, but the block number > and size are in DEV_BSIZE units. The check is not being done correctly. > [I'm not certain how the disk label would be set up for the i386. I > found that the partition size and partition offset had to be in units > of the device physical sector size in order for newfs to work correctly.] > Hmmm - an incorrect or inconsistent partition offset could be rather > dangerous. It could easily cause newfs to write at the wrong spot on > the disk. I played a little more. My fix makes raw reads and writes work okay, at least at the beginning of the disk. I can mix and match block sizes and it works okay. It also causes no problems for raw and block access to 512 byte p/sector drives. The disklabel stuff still futzes, I've done some browsing through .../i386/disk_subr.c, that seems to be the source of the disk labeling problems. I still haven't completely figured out the code, but there is a lot of stuff hard coded to DEV_BSIZE dealing with the DOS partition table. I'm willing to concede you have to make a 1024 byte/sec disk Unix only since DOS and it's partition tables assume 512 byte sectors, but there's definitely some problems still. > > I would love to help make this work (I've got a couple of older but very > > big 1024 block SCSI drives I scrounged that otherwise work). > > > > I've played a bit with having physio() stuff the block value into both > > b_lblkno and b_blkno. > > I don't think will work - the getblk() routine in kern/vfs_bio.c is > already setting b_lblkno and b_blkno to the specified block. It might > work better if physio() ensured that b_lbkno was zeroed. Hmmm. I'll have to look at that code path...l_blkno seems to be largely unreferenced elsewhere (sd.c *never* looked at it). > If fsck is still having problems thinking it's going off the end of > the partition, that problem is probably because bounds_check_with_label() > doesn't take into account the difference in the units between the > partition size and the block number + I/O length. I'll look at that as well... I still can't newfs with the raw device...it seeks (successfully) to the last block of the partition (which isn't on the end of the disk, there's still 32M of swap), but then gets EINVAL on trying to write it. I'll have to play around more. Newfsing with the block device works, but fsck still bounces. One other (unrelated?) bit...if I dd from /dev/zero to a raw SCSI disk device with other than a 512 byte block size, it locks the machine...hard. I'll try to narrow down the limits of this one using a 512 byte drive so someone can look at it or give more pointers. -Mark From owner-current-users@netbsd.org Mon Aug 29 14:10:39 1994 From: Yeng-Chee Su Subject: sun-lamp down? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 550 Sender: owner-current-users@netbsd.org I can't connect to sun-lamp for over 48 hours. Is it crashed? or network problem? -- ________________________________________________________________________ / / \ | Name: Yeng-Chee Su E-mail: yenchee@csie.nctu.edu.tw |__/ | Phone: +886-35-333367 | | Address: (undetermined) |___ \______________________________________________________________________\__/ From owner-amiga-dev@netbsd.org Mon Aug 29 14:20:22 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: NetBSD 1.0b SCSI problem To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Amiga development) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@netbsd.org Hello all.. I have some problems with the NetBSD 1.0 beta from ftp.uni-regensburg.de I get a lot of coredumps from various commands and almost every other fails with a Segmentation fault.. My setup as NetBSD see it: NetBSD 1.0 BETA (GENERIC) #0: Sat Aug 13 05:39:41 EDT 1994 chopps@coffee.gnu.ai.mit.edu:/local/src/sys/arch/amiga/compile/GENERIC Amiga 4000 (m68040 CPU/MMU/FPU) real mem = 8388608 (1024 pages) avail mem = 6610944 (807 pages) using 64 buffers containing 524288 bytes of memory memory segment 0 at 07800000 size 00800000 memory segment 1 at 00200000 size 00080000 memory segment 2 at 00000000 size 00200000 idesc0 targ 0 lun: SCSI2 direct fixed sd0 at scsibus9: 124MB, 1001 cyl, 15 head, 17 sec, 512 bytes/sec atzsc0 targ 0 lun 0: SCSI2 direct fixed sd1 at scsibus2: 116MB, 1818 cyl, 2 head, 65 sec, 512 bytes/sec atzsc0 targ 6 lun 0: SCSI2 direct removable sd2 at scsibus2: 105MB, 2060 cyl, 2 head, 52 sec, 512 bytes/sec The scsibus2 is A2091 with the mem segment 1 on-board, I've logged the error output from some commands: df: Segmentation fault vi /etc/fstab: Segmentation fault - core dumped ktrace vi /etc/fstab: Segmentation fault - core dumped fsck /dev/sd1a: ** /dev/rsd1a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes Segmentation fault - core dumped ls -l *: ls: *: No such file or directory tar -cf /tmp/test.tar /etc: Illegal instruction - core dumped passwd: ld.so: Undefined symbol "__null_auth" in passwd:/usr/lib/libc.so.12.0 mail: ld.so: Undefined symbol "__null_auth" in mail:/usr/lib/libc.so.12.0 csh: Segmentation fault - core dumped And some occasionally Bus error messages.. I've also tried a NetBSD-A4091 kernel from Michael L. Hitch which gave the same errors plus a few new ones with dmesg: dmesg: magic number incorrect dmesg: Segmentation fault All of these problems only occurs when I boot BSD from my SCSI drives from the IDE everything works fine.. Hope someone can help me out, as I would prefer to run from the SCSI bus.. Please contact me if you need more info (I have some coredumps) either through email or on irc where I normally go by the alias Ezekiel.. Thanks in advance :-) /Michael From owner-current-users@netbsd.org Mon Aug 29 14:37:19 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mark Gooderum , mark@good.com, current-users@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Block Mail Sender: owner-current-users@netbsd.org On Aug 27, 2:55pm, Mark Gooderum wrote: > > One other point worth noting... > > The write() from newfs that fails fails before it gets to sdstart(), so > I'm really having a hard time figuring out where the EINVAL is coming > from. That's probably because the bounds_check_with_label() is being called in sdstrategy and being errored out before the I/O is even queued up. If the disk label is keeping the partition size in real block units (which it what it needs to do so that newfs computes things correctly), then the bounds_check is going to fail on raw I/O: the block number is going to be in 512-byte sectors and the partition size is going to be in 1024-byte sectors. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@netbsd.org Mon Aug 29 14:40:58 1994 From: Arne H Juul To: current-users@sun-lamp.cs.berkeley.edu Subject: PS man pages Sender: owner-current-users@netbsd.org Here's a hack to make preformatted (PostScript) man pages possible. You need to set FMTMANPAGES to activate it, and you should have lots of disk space and time to use it. Actually I would like some better way (maybe installing the unformatted troff source, and troffing whole manuals could be done?) -arnej diff -ru /usr/share/mk/bsd.man.mk ./bsd.man.mk --- /usr/share/mk/bsd.man.mk Sat Jul 30 20:42:58 1994 +++ ./bsd.man.mk Thu Aug 25 23:54:13 1994 @@ -9,69 +9,109 @@ .MAIN: all .endif -.SUFFIXES: .0 .1 .2 .3 .4 .5 .6 .7 .8 +.SUFFIXES: .0 .1 .2 .3 .4 .5 .6 .7 .8 .PS .8.0 .7.0 .6.0 .5.0 .4.0 .3.0 .2.0 .1.0: @echo "nroff -mandoc ${.IMPSRC} > ${.TARGET}" @nroff -mandoc ${.IMPSRC} > ${.TARGET} || ( rm -f ${.TARGET} ; false ) +.8.PS .7.PS .6.PS .5.PS .4.PS .3.PS .2.PS .1.PS: + @echo "groff -mandoc ${.IMPSRC} > ${.TARGET}" + @groff -mandoc ${.IMPSRC} > ${.TARGET} || ( rm -f ${.TARGET} ; false ) + MINSTALL= install ${COPY} -o ${MANOWN} -g ${MANGRP} -m ${MANMODE} maninstall: .if defined(MAN1) && !empty(MAN1) MANALL+=${MAN1} +FMT1=${MAN1:.0=.PS} maninstall: man1install man1install: ${MINSTALL} ${MAN1} ${DESTDIR}${MANDIR}1${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT1} ${DESTDIR}${FMTDIR}1${MANSUBDIR} +.endif .endif .if defined(MAN2) && !empty(MAN2) MANALL+=${MAN2} +FMT2=${MAN2:.0=.PS} maninstall: man2install man2install: ${MINSTALL} ${MAN2} ${DESTDIR}${MANDIR}2${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT2} ${DESTDIR}${FMTDIR}2${MANSUBDIR} +.endif .endif .if defined(MAN3) && !empty(MAN3) MANALL+=${MAN3} +FMT3=${MAN3:.0=.PS} maninstall: man3install man3install: ${MINSTALL} ${MAN3} ${DESTDIR}${MANDIR}3${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT3} ${DESTDIR}${FMTDIR}3${MANSUBDIR} +.endif .endif .if defined(MAN3F) && !empty(MAN3F) MANALL+=${MAN3F} +FMT3F=${MAN3F:.0=.PS} maninstall: man3finstall man3finstall: ${MINSTALL} ${MAN3F} ${DESTDIR}${MANDIR}3f${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT3F} ${DESTDIR}${FMTDIR}3f${MANSUBDIR} +.endif .endif .if defined(MAN4) && !empty(MAN4) MANALL+=${MAN4} +FMT4=${MAN4:.0=.PS} maninstall: man4install man4install: ${MINSTALL} ${MAN4} ${DESTDIR}${MANDIR}4${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT4} ${DESTDIR}${FMTDIR}4${MANSUBDIR} +.endif .endif .if defined(MAN5) && !empty(MAN5) MANALL+=${MAN5} +FMT5=${MAN5:.0=.PS} maninstall: man5install man5install: ${MINSTALL} ${MAN5} ${DESTDIR}${MANDIR}5${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT5} ${DESTDIR}${FMTDIR}5${MANSUBDIR} +.endif .endif .if defined(MAN6) && !empty(MAN6) MANALL+=${MAN6} +FMT6=${MAN6:.0=.PS} maninstall: man6install man6install: ${MINSTALL} ${MAN6} ${DESTDIR}${MANDIR}6${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT6} ${DESTDIR}${FMTDIR}6${MANSUBDIR} +.endif .endif .if defined(MAN7) && !empty(MAN7) MANALL+=${MAN7} +FMT7=${MAN7:.0=.PS} maninstall: man7install man7install: ${MINSTALL} ${MAN7} ${DESTDIR}${MANDIR}7${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT7} ${DESTDIR}${FMTDIR}7${MANSUBDIR} +.endif .endif .if defined(MAN8) && !empty(MAN8) MANALL+=${MAN8} +FMT8=${MAN8:.0=.PS} maninstall: man8install man8install: ${MINSTALL} ${MAN8} ${DESTDIR}${MANDIR}8${MANSUBDIR} +.if defined(FMTMANPAGES) + ${MINSTALL} ${FMT8} ${DESTDIR}${FMTDIR}8${MANSUBDIR} +.endif .endif .if defined(MLINKS) && !empty(MLINKS) maninstall: manlinkinstall @@ -98,4 +138,10 @@ cleandir: cleanman cleanman: rm -f ${MANALL} +.if defined(FMTMANPAGES) +FMTALL=${MANALL:.0=.PS} +all: ${FMTALL} +cleanman: + rm -f ${FMTALL} +.endif .endif diff -ru /usr/share/mk/bsd.own.mk ./bsd.own.mk --- /usr/share/mk/bsd.own.mk Sat Jul 30 20:42:58 1994 +++ ./bsd.own.mk Thu Aug 25 23:54:13 1994 @@ -11,6 +11,7 @@ NONBINMODE?= 444 MANDIR?= /usr/share/man/cat +FMTDIR?= /usr/share/man/fmt MANGRP?= bin MANOWN?= bin MANMODE?= ${NONBINMODE} From owner-current-users@netbsd.org Mon Aug 29 14:46:51 1994 From: Andrew Cagney To: current-users@sun-lamp.cs.berkeley.edu Subject: Should usr appear in tarballs Sender: owner-current-users@netbsd.org Hi, At present the bin tar-balls for sub directories of `/usr' do not contain the directory `/usr' its self. This means that when the usr directory is created it gets its protection and ownership from the process running tar and *not* from the tar archive. Should, `/usr' instead be explictly included in the bin tar-balls? Eg: ( echo usr ; find usr/bin -print ) | tar cfT - - | gzip . . . Andrew -- PS: If root's umask is 0, root having the above is a real woopsie :-) From owner-amiga@netbsd.org Mon Aug 29 14:49:35 1994 From: Ron Roskens Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( To: jmarin@messi.uku.fi (Jukka Marin) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 881 Sender: owner-amiga@netbsd.org The immortal words of Jukka Marin: > Dear All, > > I installed elm 2.4 PL23, but can't make it work with emacs. First of all, > I'm running a customized kernel #744 (what? update? :-) and other oooold > stuff. > > elm works fine by itself. However, when I try to send mail, elm says > it's starting the editor - and after a short time, it asks whether I > want to e)dit message, edit h)eaders, s)end it, or f)orget it. It's > just like emacs exitted immediately. :-( > > What am I doing wrong (does elm work with new kernels?)? First, I have the exact same setup for elm as you. Elm will work with the new kernels, I recompiled it for my system. I've had no problems using emacs as the editor of choice. Second, upgrade, upgrade, upgrade. #744 is very out of date. What old stuff are you running? I can and will help with getting those programs to compile and run. Ron From owner-current-users@netbsd.org Mon Aug 29 14:51:26 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Mark Gooderum , mark@good.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Block Mail Sender: owner-current-users@netbsd.org On Aug 27, 2:51pm, Mark Gooderum wrote: > Hmmm. I'll have to look at that code path...l_blkno seems to be largely > unreferenced elsewhere (sd.c *never* looked at it). It's referenced in kern/vfs_cluster.c and kern/vfs_subr.c. It's also referenced in adosfs and msdosfs as well. I don't understand things well enough to know how it's being used though. I also see a couple of references in ufs/ffs/ffs_alloc.c. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@netbsd.org Mon Aug 29 14:54:36 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: panic: pmap_enter: malloc returned NULL (i386) X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@netbsd.org I think I'm seeing a panic tickled by AFS. I can't tell for sure, for a variety of reasons, but I believe I'm getting the panic: pmap_enter: malloc returned NULL Now, this occurs inside arch/i386/i386/pmap.c in pmap_enter() if malloc(M_NOWAIT) for a pv_entry_t fails to find any memory. I suspect this is just somebody stealing all the kernel memory, and leaking it somewhere, but I figured I'd ask if anybody here has seen it before and knows of some other diagnosis? ==John From owner-current-users@netbsd.org Mon Aug 29 15:13:31 1994 From: Arne H Juul To: current-users@sun-lamp.cs.berkeley.edu Subject: Ugly code in /usr/src/include/Makefile Sender: owner-current-users@netbsd.org Just a random suggestion: If it really is just netiso/xebec that is the cause of the ugly code, then why not do: find ${LDIRS} -type f -name '*.h' | \ grep -v netiso/xebec | \ cpio -pdvum ${DESTDIR}/usr/include this also looks much more aestethically pleasing, at least to me. Feel free to convert cpio to pax if you want to, personally I mostly use tar but also know cpio and don't really feel a pressing need to learn the options for pax... Yours, -arnej From owner-current-users@netbsd.org Mon Aug 29 15:18:33 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: mount bug? From: bryan collins Sender: owner-current-users@netbsd.org I am running 1.0 Beta with binaries compiled myself from source of about 1-2 months ago.. I have filesystems mounted as shown.. /dev/wd0a on / kernfs on /kern /dev/wd0e on /usr but when I issue 'mount -a' again to mount the rest.. it mounts /kern again anybody else noticed this? bry --- Bryan Collins Coombs Computing Unit Australian National University Canberra, Australia, 0200 Tel: (06) 249 3102 From owner-amiga-dev@netbsd.org Mon Aug 29 15:20:50 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: RE: NetBSD 1.0b SCSI problem To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Amiga development) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@netbsd.org > Hi Michael ! > I'm running NetBSD on an similar setup than yours - with the same > experiences. > This problem is related to the non-functional atzsc.c (the driver > for the A2091). > The default setup tries to allocate a DMA bounce buffer in Z2 memory > (if available) or Chip mem, but there must be something wrong > with the DMA routines. Hmm.. Is anybody working on fixing this? > If you do a binpatch -s _sbic_no_dma=1 netbsd.xxx your kernel > should work (it does on my machine). Thanks I'll try that, just a same DMA will not work.. It worked fine in my old 0.9a #744 kernel.. > The disk accesses will eat up all CPU time but it'll work. > (My setup: A4000/040, A2091, RetinaZ3). Hmm.. Maybe I should have a look at some source files.. /Michael From owner-current-users@netbsd.org Mon Aug 29 15:22:15 1994 From: niklas@appli.se (Niklas Hallqvist) To: martin@euterpe.owl.de Cc: gillham@andrews.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Couple of questions.. Sender: owner-current-users@netbsd.org >>>>> "Martin" == Martin Husemann writes: >> connection at 19.2k, the other has a mouse on it. Even without X >> running I get 'silo overflow' errors quite often on my ppp link. >> Is this related to my PIO IDE drive? Martin> No, I have them too (with an Adaptec 1742, one NS16550AFN on a Martin> 38400/14400 PPP link). Maybe RTS support in the com-driver together with fixing the generic HW flow control on input code will help. It definitely has for me on an amiga which is both slower than a 486 and doesn't have a FIFO in the UART. If someone wants a patch to tty.c, contact me. You have to fix com.c yourself though. 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 From owner-current-users@netbsd.org Mon Aug 29 15:25:56 1994 To: Thor Lancelot Simon Cc: port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Context switch times for NetBSD 2x those of 386BSD 0.1? X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@netbsd.org > A recent thread in comp.arch discusses context switch times for various > operating systems on modern hardware. Someone who works at QNX just posted a > list of measurements he's taken; it shows context switch times of 210ms and > 380ms for 386BSD 0.1 and NetBSD on the same hardware. (1) 380/210 != 2. (it's 1.809) (2) "on the same hardware" is probably not the case. Note that the results were "collected from various responses on the net," i.e. the CPU type may be the same, but the motherboard, et al. may be completely unrelated. This can make a significant difference. (3) our switch does a fair amount more, in terms of keeping more careful process accounting information, than the 386BSD switch() did. In particular, mi_switch() calls microtime() twice, and that's not a cheap function. I don't actively measure our kernel, though i probably should. If you want to, go for it. 8-) As it is, though, i wouldn't take that message as any cause for alarm. I'd want to run NetBSD on _exactly_ the same hardware as the other "same hardware" systems before i would believe it. cgd who shouldn't be writing e-mail this late at night... 8-) From owner-current-users@netbsd.org Mon Aug 29 15:28:03 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: Couple of questions.. To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 913 Sender: owner-current-users@netbsd.org Just wondering: 1. Are there any plans to add support for the Boca multiport serial cards like FreeBSD has? I'd like to get one, but couldn't write my own driver... :-( Would I need to buy 2? (one for me, one for mycroft? :-) ) 2. Does anyone have a Pro Audio Spectrum 16 working with the soundblaster driver? I've already got 2.. :-) 3. (ok, several questions..) Am I doing something wrong with my serial ports? I have 2 16550AFN's and run one on a ppp connection at 19.2k, the other has a mouse on it. Even without X running I get 'silo overflow' errors quite often on my ppp link. Is this related to my PIO IDE drive? I thought that my fifo's would run Really Fast (tm) without overflowing? Oh, but the overflows only happen when I'm actively telnetting, ftping, etc.. not when it's just sitting there. Thanks for any help! -Andrew From owner-amiga-x@netbsd.org Mon Aug 29 15:30:16 1994 From: Hubert Feyrer "Re: Contributions for 1.0" (Aug 29, 10:58am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I > x11_dist.tar.gz: 50% of this crash. :-( > > Works fine here... Requires old libs though :-) You can't expect people to have several releases installed. Please recompile. :) Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@netbsd.org Mon Aug 29 15:32:35 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Solved: netbsd-940620 panics on A3000..." (Jul 30, 12:28pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: barnhill@zinder.do.open.de, owner-amiga@sun-lamp.cs.berkeley.edu Subject: Re: Solved: netbsd-940620 panics on A3000... Cc: hikita@trl.mei.co.jp, osymh@gemini.oscs.montana.edu, amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@netbsd.org > : As for the vote on ethernet support in the kernel, just send a message > :stating "yes" or "no" and I will be glad to tabulate the outcome. > : > > --------YES-------- --------YES-------- -- Markus Illenseer From owner-current-users@netbsd.org Mon Aug 29 15:37:20 1994 To: Peter Galbavy Cc: cgd@alpha.bostic.com (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: READ THIS! It's that time again... <199408260915.KAA01116@alice.wonderland.org> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@netbsd.org > > Right now, the 'supporting cast' section, for those people who have > > put a fair amount of work into NetBSD (bug fixes, software > > development, etc.) and are actively supporting the project looks like: > > How 'bout a "Reference Site" list. Like we use the i386 and sparc > ports for our core routers... I think that's a pretty critical > usage of them. I am sure others will be happy to say publicly that > they are happy with NetBSD ? I would actually object to such a list, and would sincerely advise you to _not_ advertise that you're using NetBSD for mission-critical applications. Actually, i'll go one step further, and say that you probably shouldn't advertise what hardware/software your using for mission-critical applications, in general... It's publicizing information that _some_ people are likely to use the wrong way; the Internet is _not_ a friendly place. I dunno if it ever was, but it definitely isn't now. ("once a sysadmin, always a sysadmin..." 8-) cgd From owner-current-users@netbsd.org Mon Aug 29 15:44:31 1994 From: Mark Gooderum To: current-users@sun-lamp.cs.berkeley.edu Subject: Block Mail Cc: osymh@gemini.oscs.montana.edu, mark@good.com Sender: owner-current-users@netbsd.org > From: "Michael L. Hitch" > Date: Wed, 24 Aug 1994 20:01:03 -0600 > To: current-users@sun-lamp.cs.berkeley.edu > Subject: Filesystem block/device block size discrepancy > > Has anyone been running (or attempted to run) an ffs file system on a > disk with other than 512 byte sectors? ... I've had this problem, I posted mail earlier about problems with a SCSI hard drive with 1024 byte blocks. > Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno > field as the block number of a 512-byte (DEV_BSIZE) block and convert it > to the actual block number of the physical block of the disk.... This jives with the behavior I've seen. Disklabel writes the label and reads it, okay, but fsck and newfs barf using the raw device about 1/2 way through the disk (because block #'s are doubled...it runs off the end of the disk). > I can see two different ways to correct this: changing the ffs and > block special device access to use a 512-byte b_blkno, or change the > character special device access and the cd9660 file system to use actual > device block numbers. I'm not certain which would be the most "correct" > way to go. It's interesting. The buf struct has both a bblkno field and an lblkno field. The sd driver and physio() don't seem to reference lblkno. I first played with just making physio() and sd() use real blocks, but physio() doesn't have immediate access to this info (it could get it though, but it would be a duplicate of later effort). Also the wd driver assumes 512 byte blocks as well (I run a mixed IDE and SCSI system, call me sick). So my first change made the fsck of the IDE drive barf (I don't know if it worked for SCSI, I boot off of IDE..) > The msdosfs and adosfs file systems could also be potentially > affected, but at the moment, the adosfs file system will only work with > 512 byte blocks, and I think the msdosfs file system only works with 512 > byte blocks as well. No, MS-DOS doesn't deal with non-512 byte blocks. Some very newer drivers support >512 byte blocks but only at a device driver level by faking out DOS. Older drivers just don't support non-512 byte block devices. > I would be nice to have this fixed in the 1.0 release, but I suspect > making the changes and fully testing them would not be feasible prior to > the release [when ever that might be]. > character special device access and the cd9660 file system to use actual > device block numbers. I'm not certain which would be the most "correct" > way to go. It's interesting. The buf struct has both a bblkno field and an lblkno field. The sd driver and physio() don't seem to reference lblkno. I first played with just making physio() and sd() use real blocks, but physio() doesn't have immediate access to this info (it could get it though, but it would be a duplicate of later effort). Also the wd driver assumes 512 byte blocks as well (I run a mixed IDE and SCSI system, call me sick). So my first change made the fsck of the IDE drive barf (I don't know if it worked for SCSI, I boot off of IDE..) > The msdosfs and adosfs file systems could also be potentially > affected, but at the moment, the adosfs file system will only work with > 512 byte blocks, and I think the msdosfs file system only works with 512 > byte blocks as well. No, MS-DOS doesn't deal with non-512 byte blocks. Some very newer drivers support >512 byte blocks but only at a device driver level by faking out DOS. Older drivers just don't support non-512 byte block devices. > I would be nice to have this fixed in the 1.0 release, but I suspect > making the changes and fully testing them would not be feasible prior to > the release [when ever that might be]. I would love to help make this work (I've got a couple of older but very big 1024 block SCSI drives I scrounged that otherwise work). I've played a bit with having physio() stuff the block value into both b_lblkno and b_blkno. --- kern_physio.c.orig Fri Aug 26 11:35:59 1994 +++ kern_physio.c Fri Aug 26 11:36:05 1994 @@ -141,6 +141,7 @@ splx(s); /* [set up the buffer for a maximum-sized transfer] */ + bp->b_lblkno = btodb(uio->uio_offset); bp->b_blkno = btodb(uio->uio_offset); bp->b_bcount = iovp->iov_len; bp->b_data = iovp->iov_base; The sd driver then says... --- sd.c.orig Fri Aug 26 11:36:53 1994 +++ sd.c Fri Aug 26 11:37:08 1994 @@ -493,7 +493,20 @@ * * First, translate the block to absolute */ - blkno = bp->b_blkno / (sd->params.blksize / DEV_BSIZE); + + /* + * The FFS and block device callers get this right. + * Some callers don't have easy access to the + * device info, so they pass down a DEV_BSIZE value in lblkno + * as a clue that these are DEV_BSIZE blocks. + */ + + if (bp->b_lblkno && (sd->params.blksize != DEV_BSIZE)) { + blkno = bp->b_blkno = bp->b_lblkno / + (sd->params.blksize / DEV_BSIZE); + } else { + blkno = bp->b_blkno; + } So far it doesn't quite work yet. I still get the symptom that I can label the disk, but fsck barfs, and the kernel complains about no disk label when first booting. I also haven't made the physio() like changes to the CD code, I have no CD drive to test with. An example of how this can show itself...reading in one chunk from block 0 works because there is no block/offset calculation. Reading it in 512 byte chunks gives an different result... Does anyone more in the know want to comment on this approach? Is there a better way? nirvana::mark-109> root dd if=/dev/rsd1d bs=32768 count=1 of=/tmp/dd1 1+0 records in 1+0 records out 32768 bytes transferred in 1 secs (32768 bytes/sec) nirvana::mark-112> root dd if=/dev/rsd1d bs=512 count=64 of=/tmp/dd2 64+0 records in 64+0 records out 32768 bytes transferred in 1 secs (32768 bytes/sec) nirvana::mark-113> cmp /tmp/dd1 /tmp/dd2 /tmp/dd1 /tmp/dd2 differ: char 513, line 3 P.S. For those of you who've got my Email address and have sent to me personally in the last few weeks @Good.com it finally is really working again. I've got my new provider mostly straightened out, mail is 100%, now if I could just get them to route my Class C net... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark P. Gooderum USSnail: Good Creations Senior Consultant - Operating Systems Group 3029 Blackstone Ave. So. "Working hard to be hardly working..." St. Louis Park, MN 55416 EMail: mark@Good.com Voice: (612) 922-3953 Interactive: mark@nirvana.Good.com Fax: (612) 922-2676 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-current-users@netbsd.org Mon Aug 29 16:03:37 1994 From: Mark Gooderum To: current-users@sun-lamp.cs.berkeley.edu Subject: Block Mail Cc: osymh@gemini.oscs.montana.edu, mark@good.com Sender: owner-current-users@netbsd.org > From: "Michael L. Hitch" > Date: Wed, 24 Aug 1994 20:01:03 -0600 > To: current-users@sun-lamp.cs.berkeley.edu > Subject: Filesystem block/device block size discrepancy > > Has anyone been running (or attempted to run) an ffs file system on a > disk with other than 512 byte sectors? ... I've had this problem, I posted mail earlier about problems with a SCSI hard drive with 1024 byte blocks. > Both the SCSI hard disk (sd*) and CDROM (cd*) drivers take the b_blkno > field as the block number of a 512-byte (DEV_BSIZE) block and convert it > to the actual block number of the physical block of the disk.... This jives with the behavior I've seen. Disklabel writes the label and reads it, okay, but fsck and newfs barf using the raw device about 1/2 way through the disk (because block #'s are doubled...it runs off the end of the disk). > I can see two different ways to correct this: changing the ffs and > block special device access to use a 512-byte b_blkno, or change the > character special device access and the cd9660 file system to use actual > device block numbers. I'm not certain which would be the most "correct" > way to go. It's interesting. The buf struct has both a bblkno field and an lblkno field. The sd driver and physio() don't seem to reference lblkno. I first played with just making physio() and sd() use real blocks, but physio() doesn't have immediate access to this info (it could get it though, but it would be a duplicate of later effort). Also the wd driver assumes 512 byte blocks as well (I run a mixed IDE and SCSI system, call me sick). So my first change made the fsck of the IDE drive barf (I don't know if it worked for SCSI, I boot off of IDE..) > The msdosfs and adosfs file systems could also be potentially > affected, but at the moment, the adosfs file system will only work with > 512 byte blocks, and I think the msdosfs file system only works with 512 > byte blocks as well. No, MS-DOS doesn't deal with non-512 byte blocks. Some very newer drivers support >512 byte blocks but only at a device driver level by faking out DOS. Older drivers just don't support non-512 byte block devices. > I would be nice to have this fixed in the 1.0 release, but I suspect > making the changes and fully testing them would not be feasible prior to > the release [when ever that might be]. > character special device access and the cd9660 file system to use actual > device block numbers. I'm not certain which would be the most "correct" > way to go. It's interesting. The buf struct has both a bblkno field and an lblkno field. The sd driver and physio() don't seem to reference lblkno. I first played with just making physio() and sd() use real blocks, but physio() doesn't have immediate access to this info (it could get it though, but it would be a duplicate of later effort). Also the wd driver assumes 512 byte blocks as well (I run a mixed IDE and SCSI system, call me sick). So my first change made the fsck of the IDE drive barf (I don't know if it worked for SCSI, I boot off of IDE..) > The msdosfs and adosfs file systems could also be potentially > affected, but at the moment, the adosfs file system will only work with > 512 byte blocks, and I think the msdosfs file system only works with 512 > byte blocks as well. No, MS-DOS doesn't deal with non-512 byte blocks. Some very newer drivers support >512 byte blocks but only at a device driver level by faking out DOS. Older drivers just don't support non-512 byte block devices. > I would be nice to have this fixed in the 1.0 release, but I suspect > making the changes and fully testing them would not be feasible prior to > the release [when ever that might be]. I would love to help make this work (I've got a couple of older but very big 1024 block SCSI drives I scrounged that otherwise work). I've played a bit with having physio() stuff the block value into both b_lblkno and b_blkno. --- kern_physio.c.orig Fri Aug 26 11:35:59 1994 +++ kern_physio.c Fri Aug 26 11:36:05 1994 @@ -141,6 +141,7 @@ splx(s); /* [set up the buffer for a maximum-sized transfer] */ + bp->b_lblkno = btodb(uio->uio_offset); bp->b_blkno = btodb(uio->uio_offset); bp->b_bcount = iovp->iov_len; bp->b_data = iovp->iov_base; The sd driver then says... --- sd.c.orig Fri Aug 26 11:36:53 1994 +++ sd.c Fri Aug 26 11:37:08 1994 @@ -493,7 +493,17 @@ * * First, translate the block to absolute */ - blkno = bp->b_blkno / (sd->params.blksize / DEV_BSIZE); + + /* + * The FFS and block device callers get this right. + * Some callers don't have easy access to the + * device info, so they pass down a DEV_BSIZE value in lblkno + * as a clue that these are DEV_BSIZE blocks. + */ + + if (bp->b_lblkno && (sd->params.blksize != DEV_BSIZE)) { + blkno = bp->b_blkno = bp->b_lblkno / + (sd->params.blksize / DEV_BSIZE); + } else { + blkno = bp->b_blkno; + } So far it doesn't quite work yet. I still get the symptom that I can label the disk, but fsck barfs, and the kernel complains about no disk label when first booting. I also haven't made the physio() like changes to the CD code, I have no CD drive to test with. An example of how this can show itself...reading in one chunk from block 0 works because there is no block/offset calculation. Reading it in 512 byte chunks gives an different result... Does anyone more in the know want to comment on this approach? Is there a better way? nirvana::mark-109> root dd if=/dev/rsd1d bs=32768 count=1 of=/tmp/dd1 1+0 records in 1+0 records out 32768 bytes transferred in 1 secs (32768 bytes/sec) nirvana::mark-112> root dd if=/dev/rsd1d bs=512 count=64 of=/tmp/dd2 64+0 records in 64+0 records out 32768 bytes transferred in 1 secs (32768 bytes/sec) nirvana::mark-113> cmp /tmp/dd1 /tmp/dd2 /tmp/dd1 /tmp/dd2 differ: char 513, line 3 P.S. For those of you who've got my Email address and have sent to me personally in the last few weeks @Good.com it finally is really working again. I've got my new provider mostly straightened out, mail is 100%, now if I could just get them to route my Class C net... -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark P. Gooderum USSnail: Good Creations Senior Consultant - Operating Systems Group 3029 Blackstone Ave. So. "Working hard to be hardly working..." St. Louis Park, MN 55416 EMail: mark@Good.com Voice: (612) 922-3953 Interactive: mark@nirvana.Good.com Fax: (612) 922-2676 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From owner-current-users@netbsd.org Mon Aug 29 16:16:22 1994 From: "Charles M. Hannum" To: arnej@dsl.unit.no Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Ugly code in /usr/src/include/Makefile Sender: owner-current-users@netbsd.org Just a random suggestion: If it really is just netiso/xebec that is the cause of the ugly code, then why not do: find ${LDIRS} -type f -name '*.h' | \ grep -v netiso/xebec | \ cpio -pdvum ${DESTDIR}/usr/include That's a good idea, though I decided to do it a little differently: ! pax -rw -pa -L \ ! `find ${LDIRS} -type f -name '*.h' '!' -path 'netiso/xebec/*' \ ! -print` ${DESTDIR}/usr/include From owner-amiga@netbsd.org Mon Aug 29 17:18:18 1994 From: nix@stekt16.oulu.fi (Tero Manninen) Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( To: garion@reality.cs.umn.edu (Ron Roskens) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 695 Sender: owner-amiga@netbsd.org > > Second, upgrade, upgrade, upgrade. #744 is very out of date. What old stuff are > you running? I can and will help with getting those programs to compile and > run. Well, at least #744 works! I have heard people having a lot of trouble with the new 1.0 pre-releases. This is the main reason why I too am still using #744. I can't think any good reason why to upgrade right now while things seem to be so unstable. What I really need is a stable software development environment. (OK.. g++ 2.6.x might be one good reason :-)) ++Tero P.S. The A2232 driver stuff that was uploaded to NetBSD-Amiga contrib directory seems to be done only for #744? Anyone trying to port it to -current? From owner-amiga-dev@netbsd.org Mon Aug 29 17:43:39 1994 From: chopps@emunix.emich.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Problem reports? X-Mts: smtp Sender: owner-amiga-dev@netbsd.org Can I see a show of hands from people that are having problems with the current release? I recall seeing posts about system hangs with heavy disk activety. Can people seeing this please report your system configuration (i.e. dmesg) Also is it possible that you are running out of swap? If so can you run `pstat -s' as a background task while doing whatever it is (this would be good to know too) that hangs your system. Regarding the A2091 in a A4000 problems. Is anyone out there using an A2091 in a A2000? If so are you seeing problems? I haven't made changes to these subsystems in a while that would cause any of these problems so its hard to figure out what the problem is. I need more info. Chris. From owner-amiga-dev@netbsd.org Mon Aug 29 20:54:56 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Problem reports? Sender: owner-amiga-dev@netbsd.org On Aug 29, 10:56am, chopps@emunix.emich.edu wrote: > Regarding the A2091 in a A4000 problems. Is anyone out there > using an A2091 in a A2000? If so are you seeing problems? > > I haven't made changes to these subsystems in a while that > would cause any of these problems so its hard to figure > out what the problem is. I have been attempting to track down this problem with Jochen Buehler without much luck. Not having an A2091 on my machine is a very severe handicap in trying to troubleshoot a problem like this. I've verified that the GVP Series II card I do have does indeed work with DMA using the Zorro II memory on the GVP card, so I know the A4000 is capable of doing DMA to Zorro II memory. I've also looked through the A2091 driver several times, and compared it with old versions of the driver (prior to the config.new changes). I had found a few of things that weren't correct, but they've been fixed now. [One of the errors was causing the driver to never do DMA - which meant the driver worked fine up to that point.] At this point, I've run out of things to try and don't know what else to do to try and fix this. I also suspect that the #744 kernel may not have had the bounce buffer DMA enabled by default for the A2091 card, so it wouldn't have shown any problems. I'll have to dig through the 744 sources to verify that though. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-x@netbsd.org Mon Aug 29 21:18:26 1994 From: Markus Landgraf To: amiga-x@sun-lamp.cs.berkeley.edu Subject: problems with the X11R6 server Sender: owner-amiga-x@netbsd.org Hi, I have two problems with the new X-server (R6). I start it with X :0 -W 1024 -H 1024 in A2024 mode. 1. Sometimes the Xserver comes up with all colours black. When I retry to start it, it works after three retries or so. 2. After some time working, the server spontaniously breaks down with a core dump. Is there anybody who had this problems, too ? -- ------------------------------------------------------------------------------ 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 owner-amiga@netbsd.org Mon Aug 29 21:40:08 1994 From: chopps@emunix.emich.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Problem reports? X-Mts: smtp Sender: owner-amiga@netbsd.org Can I see a show of hands from people that are having problems with the current release? I recall seeing posts about system hangs with heavy disk activety. Can people seeing this please report your system configuration (i.e. dmesg) Also is it possible that you are running out of swap? If so can you run `pstat -s' as a background task while doing whatever it is (this would be good to know too) that hangs your system. Regarding the A2091 in a A4000 problems. Is anyone out there using an A2091 in a A2000? If so are you seeing problems? I haven't made changes to these subsystems in a while that would cause any of these problems so its hard to figure out what the problem is. I need more info. Chris. From owner-amiga@netbsd.org Mon Aug 29 21:41:03 1994 From: chopps@emunix.emich.edu To: nix@stekt16.oulu.fi (Tero Manninen) Cc: garion@reality.cs.umn.edu (Ron Roskens), amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( <9408291424.AA00652@stekt16.ee.university.oulu.fi> X-Mts: smtp Sender: owner-amiga@netbsd.org > > > > Second, upgrade, upgrade, upgrade. #744 is very out of date. What old stuff are > > you running? I can and will help with getting those programs to compile and > > run. > > Well, at least #744 works! I have heard people having a lot of trouble > with the new 1.0 pre-releases. This is the main reason why I too am still > using #744. I can't think any good reason why to upgrade right now while > things seem to be so unstable. What I really need is a stable software > development environment. (OK.. g++ 2.6.x might be one good reason :-)) There seem to be problems with a few setups, however I must ask you: "How do you expect a system to become stable?" Do you think that if we all wait around it will get fixed? No we need people testing it. As far as 744 being more stable, I don't think this is true. Currently we have alot more people running the kernels simply becuase they couldn't run 744 (lack of correct hardware). If your running 744 I don't think you have anything to worry about with newer kernels. It is very rare that people just pop up and say `Hey everything is going good here.' Chris. From owner-amiga@netbsd.org Mon Aug 29 21:50:26 1994 From: mw@eunet.ch Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( To: jmarin@messi.uku.fi (Jukka Marin) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 973 Sender: owner-amiga@netbsd.org > I installed elm 2.4 PL23, but can't make it work with emacs. First of all, I'm running [ELM 2.4 PL23alpha2], works fine with my emacs. > I'm running a customized kernel #744 (what? update? :-) and other oooold > stuff. Way cool system :-)) > elm works fine by itself. However, when I try to send mail, elm says > it's starting the editor - and after a short time, it asks whether I > want to e)dit message, edit h)eaders, s)end it, or f)orget it. It's > just like emacs exitted immediately. :-( Have you entered the full path to emacs (just as a test) in the options screen? > What am I doing wrong (does elm work with new kernels?)? Why do you care? Works fine with REAL bsd :-)) -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH >Solaris 2 is not an upgrade from Solaris 1. They just want you to THINK it is. From owner-amiga@netbsd.org Mon Aug 29 22:22:27 1994 From: Ron Roskens Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( To: nix@stekt16.oulu.fi (Tero Manninen) Cc: garion@reality.cs.umn.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 537 Sender: owner-amiga@netbsd.org The immortal words of Tero Manninen: > Well, at least #744 works! I have heard people having a lot of trouble > with the new 1.0 pre-releases. This is the main reason why I too am still > using #744. I can't think any good reason why to upgrade right now while > things seem to be so unstable. What I really need is a stable software > development environment. (OK.. g++ 2.6.x might be one good reason :-)) That's one of the options that I've installed onto my system. I haven't done any c++ compiling to know what's in it though. Ron From owner-current-users@netbsd.org Mon Aug 29 22:27:08 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Profiling Weirdness Solved. From: "J.T. Conklin" Sender: owner-current-users@netbsd.org About two weeks ago, I posted some observations of unusal call graph profile output. To summarize, the "grandchildren" of some functions were being counted as if they were children. Charles and Bill Paulsen mentioned tail call optimization as a possible cause, but that wasn't it. Since I didn't need new CVS profiles at the time, I put the problem aside. But investigating some CVS bogosities (CVS's hash function isn't appropriate for the data it's hashing) required some more profiling, so I looked into it a bit more. I discovered that mcount() walks up the stack frame to determine it's caller, but the ENTRY() macro used by assembly language functions (like syscalls, string & memory ops, etc.) doesn't set up a stack frame before calling mcount(). Thus a function will always report that it's being called by its grandparent. The enclosed change to asm.h seems to have fixed the problem for me. The change simply sets up a stack frame, calls mcount(), and tears down the stack frame. It adds three instructions/cycles, but it is a given that performance instrumentation and measurment is going to effect the code being analyzed anyway. I don't understand the "movl $1b,%eax" that I removed, or the .long 0 in the data segement. %eax is likely to be clobbered by mcount(), and the .long 0 doesn't look like it is ever referenced. --jtc *** /usr/src/sys/arch/i386/include/asm.h Sat Mar 12 03:04:51 1994 --- asm.h Sat Aug 27 21:08:36 1994 *************** *** 65,71 **** * XXX assumes that arguments are not passed in %eax */ # define _BEGIN_ENTRY .data; 1:; .long 0; .text; .align 2 ! # define _END_ENTRY movl $1b,%eax; call PIC_PLT(mcount) #else # define _BEGIN_ENTRY .text; .align 2 # define _END_ENTRY --- 65,71 ---- * XXX assumes that arguments are not passed in %eax */ # define _BEGIN_ENTRY .data; 1:; .long 0; .text; .align 2 ! # define _END_ENTRY pushl %ebp; movl %esp,%ebp; call PIC_PLT(mcount); popl %ebp #else # define _BEGIN_ENTRY .text; .align 2 # define _END_ENTRY From owner-current-users@netbsd.org Mon Aug 29 22:40:36 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: mount bug? Sender: owner-current-users@netbsd.org > I am running 1.0 Beta with binaries compiled myself from source of > about 1-2 months ago.. > I have filesystems mounted as shown.. > /dev/wd0a on / > kernfs on /kern > /dev/wd0e on /usr > but when I issue 'mount -a' again to mount the rest.. it mounts /kern > again > anybody else noticed this? Yes; a message flew by on the lists a while ago about something similar. When you "mount -a", it mounts _all_ the filesystems again; the only reason it doesn't mount / and /usr twice is that you can't mount a given block device more than once. You'll get similar multiple mounts with NFS, for example...which is a problem for me, setting up a diskless environment. I'm probably about to hack something into mount to work around it.... der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@netbsd.org Mon Aug 29 23:07:24 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@alpha.bostic.com X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: Mirrors for 1.0 From: "Chris G. Demetriou" Sender: owner-current-users@netbsd.org As you all know, the NetBSD 1.0 release process is grinding along. Anyway, i'd like to: (1) set up a bunch of mirror sites before it's announced to the public (for obvious reasons), and (2) set up a mailing list of people running mirror sites, so that i can get in contact with you all easily. If you're interested in mirroring the FULL 1.0 release, i.e. source distributions, and binary distributions for ALL architectures, please send me mail. chris From owner-current-users@netbsd.org Mon Aug 29 23:15:29 1994 From: Mark Gooderum To: mark@good.com, osymh@gemini.oscs.montana.edu Subject: Re: Block Mail Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Sender: owner-current-users@netbsd.org > > I would love to help make this work (I've got a couple of older but very > > big 1024 block SCSI drives I scrounged that otherwise work). > > > > I've played a bit with having physio() stuff the block value into both > > b_lblkno and b_blkno. > > Here's a solution I'm trying right now. I've been running in on my > 512-byte sector disks with no problems. It also seems to be working > on an M-O disk using 1024-sectors. Newfs and fsck work fine, and the > filesystem can be mounted. > > The physio() routine sets the B_RAW flag, and my change uses that flag > to decide how to handle the b_blkno field. [I.e. if B_RAW is set, then > the b_blkno value is in DEV_BSIZE blocks, otherwise the b_blkno value is > in real blocks.] There are two changes - one to the SCSI disk driver > (sd.c) and the other to the bounds_check_with_label() routine, since the > meaning of b_blkno is different. Note that the partition size must be > in real blocks, not in DEV_BSIZE blocks; newfs uses the real block size > when calculating the file system size. > Michael I've made these changes. The patch to sd.c and have similarly modified bounds_check_with_label(). With this done I can disklabel when running and can newfs and fsck using the raw devices and then successfully mount and use the filesystem. On reboot the label "goes away". If I relabel the disk in with the same setup, the filesystems are there and unaffected, fsck okay and can be mounted and used. (I'm fudging slightly to be safe though, the first filesystem doesn't start until the second cylinder). I've played a little bit with writedisklabel() and readdisklabel() but really haven't had much luck. If I write the label, disklabel -r shows its okay "on the disk", but after boot...it fails to read it. I'm going to look at the first few blocks in the raw but some clues as to what it should look like would be nice from someone more in the know. -Mark From owner-amiga@netbsd.org Tue Aug 30 01:08:41 1994 From: Steve Parkinson Subject: Keymaps, Views, Docs. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 553 Sender: owner-amiga@netbsd.org 1) How do I change the keymaps without recompiling. Hubert mentioned that this was possible. 2) Is it possible to have different 'views' or 'screens' .. with a different login in each? 3) Where is the rest of /usr/share/doc. there looks to be some really good info in there, if it wasn't missing. I cant find it in sun-lamp 4) Is the ados filesystem r/w or just read? Is it safe? 5) - finally - are the answers to these questions written up anywhere? Is there an Amiga FAQ? Is there going to be one? Thanks of rall the great work guys. Steve From owner-amiga-dev@netbsd.org Tue Aug 30 01:16:08 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@netbsd.org Chris Hopps wrote: > Regarding the A2091 in a A4000 problems. Is anyone out there > using an A2091 in a A2000? If so are you seeing problems? The problem with 2091s in 4000s under AmigOS is two things: the driver is run from the ROM on the card and that ROM is not cached, and many times it gets to do polled I/O because it cannot do DMA outside th eZ2 address space. DMA to chip mem should normally work okay, and marking the ROM as cachable together increase the speed considerably (but still not as fast as on a 2000). I have however read about other people having problems with DMA from a 2091 to their 4000's chip memory. It might be a problem that happens in more 4000s than just mine. (As I noted before, a 2091 in my 4000 hangs badly, but the same 2091 works perfectly in my 2000). -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl Ooey-Gooey-Fluffy-Barfie \X/ I'm not weird, I'm differently percepted. D787B44DFC896063 4CBB95A5BD1DAA96 From owner-amiga-dev@netbsd.org Tue Aug 30 01:20:55 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@netbsd.org > From: chopps@emunix.emich.edu > Can I see a show of hands from people that are having problems > with the current release? I recall seeing posts about > system hangs with heavy disk activety. Can people seeing > this please report your system configuration (i.e. dmesg) I'm still having occasional hangs under heavy floppy driver activity (for example, running the mkfloppy script that I sent you). This is on a stock A3000. Other than that, the current release has been pretty solid for me. -SR From owner-amiga@netbsd.org Tue Aug 30 01:25:10 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@netbsd.org > From: chopps@emunix.emich.edu > Can I see a show of hands from people that are having problems > with the current release? I recall seeing posts about > system hangs with heavy disk activety. Can people seeing > this please report your system configuration (i.e. dmesg) I'm still having occasional hangs under heavy floppy driver activity (for example, running the mkfloppy script that I sent you). This is on a stock A3000. Other than that, the current release has been pretty solid for me. -SR From owner-amiga@netbsd.org Tue Aug 30 01:31:18 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@netbsd.org Chris Hopps wrote: > Regarding the A2091 in a A4000 problems. Is anyone out there > using an A2091 in a A2000? If so are you seeing problems? The problem with 2091s in 4000s under AmigOS is two things: the driver is run from the ROM on the card and that ROM is not cached, and many times it gets to do polled I/O because it cannot do DMA outside th eZ2 address space. DMA to chip mem should normally work okay, and marking the ROM as cachable together increase the speed considerably (but still not as fast as on a 2000). I have however read about other people having problems with DMA from a 2091 to their 4000's chip memory. It might be a problem that happens in more 4000s than just mine. (As I noted before, a 2091 in my 4000 hangs badly, but the same 2091 works perfectly in my 2000). -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl Ooey-Gooey-Fluffy-Barfie \X/ I'm not weird, I'm differently percepted. D787B44DFC896063 4CBB95A5BD1DAA96 From owner-netbsd-users@netbsd.org Tue Aug 30 01:39:01 1994 From: Jason Ozolins Subject: Invisible cursor problem - any suggestions? To: netbsd-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 723 Sender: owner-netbsd-users@netbsd.org Hi all, I have installed the 1.0 beta NetBSD release and apart from getting a whole lot of messages about missing files in /etc when I boot, the system appears to come up OK. When I log in as root at the console and accept the default pc3 terminal type, I find that I only get a flashing block cursor when the cursor is on the top line of the screen, and it is invisible on every other line. This is a little inconvenient when trying to edit files - has anyone else encountered this? Is there a solution? Enquiring minds want to know. 8^) My system is an OPTI chipset 486DX40 w/5 megs RAM, and a no-name Trident 512K 8900 chipset ISA video board. All suggestions welcome; cheers, Jason jasonoz@cairo.anu.edu.au From owner-current-users@netbsd.org Tue Aug 30 02:49:58 1994 X-Notice: The site "wrl.epi.com" is now known as "entropic.com" To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: mount bug? <199408291444.KAA00810@Collatz.McRCIM.McGill.EDU> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@netbsd.org >Yes; a message flew by on the lists a while ago about something >similar. When you "mount -a", it mounts _all_ the filesystems again; >the only reason it doesn't mount / and /usr twice is that you can't >mount a given block device more than once. You'll get similar multiple >mounts with NFS, for example...which is a problem for me, setting up a >diskless environment. I'm probably about to hack something into mount >to work around it.... It seems like other OS's check to see what's currently mounted when doing a "mount -a" and refuse to mount the same filesystems that way. That seems like it wouldn't be that hard to put in .... From owner-netbsd-users@netbsd.org Tue Aug 30 03:02:13 1994 From: matthew@scruz.net (Matthew Kaufman) To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: re: Invisible cursor problem - any suggestions? Cc: jasonoz@cairo.anu.edu.au Sender: owner-netbsd-users@netbsd.org I get the same problem under NetBSD 0.9 on my no-name Trident VGA card, but it works fine with an Orchid card. [just another datapoint -- if there's a solution, i'd like to hear it too] -matthew From owner-current-users@netbsd.org Tue Aug 30 03:31:41 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu, port-i386@sun-lamp.cs.berkeley.edu Subject: Am I an idiot, or is the BT946C support flaky? Sender: owner-current-users@netbsd.org (the answer to the above question is "yes".) Since I've been pretty happy with the performance of the two BT445S controllers I use in my VESA machines, when we bought a pile of new PCI machines for Panix I spec'ed BusLogic PCI controllers for them. I've had approximately zero luck making them work. For starters, the BT946C just seems to not like the Dell that sits on my desk. Not A Big Deal; the Dell's a pretty early PCI machine and I never really expected to use the PCI bus on it for much. The symptoms of this are a plain old failure to boot either the IDE or the SCSI disk, even though the BusLogic is recognized and can go into auto-test mode. Not a very serious problem. But the failure of the four 946C cards I bought to run in the brand-new PCI 486/66 machines I bought for them to run in is much more serious. The symptoms are as follows: [I'm using a kernel built from GENERICBT of approximately one-week-old sources] I boot from my IDE disk. The BusLogic correctly recognizes whatever SCSI disk I have hooked up to it and installs it as the second hard disk. The kernel goes through the motions of autoconfiguring all the relevant devices. When it gets to bt0, I get the following: bt0 at isa0 port 0x330-0x333 irq 11: version 4.2, sync, parity, 32 mbxs [whatever disks I have hooked up to the scsibus] pci 0 at isa 0 port 0x0-0x665: configuration mode 1 pci 0 bus 0 device 0: identifier 05051106 class 00000000 not configured pci 0 bus 0 device 8: identifier 0140104b class 01000000 not configured [! uh oh !] The machine comes up, and everything works fine *except* the SCSI disks. Any attempt to access them leaves a process hanging in disk wait, and eventually messages about sd0: timed out sd0: timed out AGAIN start to scroll down the screen. After quite a long time, the machine decides sd0 isn't a configured device anymore. This happens whether I have my PCI caches turned on or off. It happens no matter what IRQ I set the PCI slot for the BT946C to and no matter what IRQ I set the card itself to. It happens whether or not parity, fast transfers, and sync mode negotiation are turned on in the card settings. It happens if I select ISA DMA channel emulation, and it happens if I don't. I just don't get it. Didn't people say this card worked with the BT driver? I'm going to go give it a spin with the GENERICAHA kernel, but I'm not exactly thrilled by that prospect, either. I know Rob Kolstad said at Usenix that the original BT946 cards had a bug in the mailbox protocol that made them extraordinarily slow, if workable at all, under BSDI, but that BusLogic had fixed the problem. This was months and months ago; I doubt I've got four such broken cards, from two different suppliers. My motherboards are PCI/VL/ISA, using the VIA VT82C505 chipset. Does anyone know of bugs in this chipset? It's possible that if nobody has any idea what's going on, I could arrange to lend one of these machines to an appropriate core team member -- Charles, I guess? I'm pretty confused right about now, and we're about to roll out a whole new set of news, mail, uucp, web, ftp, gopher, etc. servers here on NetBSD /i386 machines; I really want to make this work. Anyone who can give me a clue would be very, very welcome to. I feel pretty foolish right now. Thor From owner-amiga@netbsd.org Tue Aug 30 03:36:52 1994 Subject: weird behavior of console From: Tim Newsham To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@netbsd.org I've been noticing some weird behavior on the console when using curses applications that use reverse-video. Sometimes things that should be in reverse-video are not. This usually happens at the beginning of a new line. Has anyone else observed this? Is this the console's fault or is curses or termcap to blame here? Tim N. From owner-amiga@netbsd.org Tue Aug 30 05:30:07 1994 Subject: Re: weird behavior of console From: Tim Newsham To: newsham@uhunix.uhcc.Hawaii.Edu (Tim Newsham) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@netbsd.org > > > I've been noticing some weird behavior on the console when > using curses applications that use reverse-video. Sometimes > things that should be in reverse-video are not. This usually > happens at the beginning of a new line. Has anyone else observed > this? Is this the console's fault or is curses or termcap to > blame here? > > Tim N. I did some more investigation... the problem happens when I run screen with TERM=vt220 and when I run screen with TERM=vt200 but when I run screen with TERM=vt100 everything works properly. When I run programs directly on the console without screen the problem doesnt show up with either term setting and when I run from xterm the problem doesnt show up either, even when I run screen within an xterm. I made the following test: main() { printf("\033[3mFoo\n"); printf(" \033[3mFoo\n"); printf("\033[23mFoo\n"); } This prints out either the first Foo in reverse or the first 2 Foos in reverse or none in reverse: TERM=vt220, run screen, a.out - 1 reverse TERM=vt200, run screen, a.out - 1 reverse TERM=vt100, run screen, a.out - 2 reverse TERM=vt100, a.out - none in reverse TERM=vt200, a.out - none in reverse TERM=vt220, a.out - none in reverse I dont know what the cause of this is but at least I know how to get a working terminal under screen now (use vt100 prior to running screen). Tim N. From owner-current-users@netbsd.org Tue Aug 30 05:54:15 1994 From: "Charles M. Hannum" To: tls@panix.com Cc: port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: BT946C support -- maybe I _am_ an idiot? Sender: owner-current-users@netbsd.org Many motherboards seem to ship with all the PCI interrupts switched off. `Oh joy.' To make it work correctly, the "PIN" setting in the "Auto-SCSI" adapter BIOS has to be set to the letter of the PCI INterrupt (ever wonder what PIN stood for? Nice that the BT946 manual documents it, huh?) Actually, in the PCI spec it corresponds to one of four real pins. However, the spec specifically says that a single-function board should only use INTA#. I can only guess that the slot itself is supposed to wire the interrupt lines to whatever IRQs on the ISA-compatible interrupt controllers. (If anyone knows more about this, speak up!) Currently, the PCI autoconfiguration code relies on the PCI BIOS to have stored the number of the ISA interrupt line onto the board. This is really all I can do without getting into horrible chipset dependencies that I really don't want to think about. Could the kernel autodetect some of this stuff? There is currently no specific PCI support for the BusLogic controllers; they are just used as if they were EISA or VLB boards. If you'd like to add some PCI autoconfiguration support for them, I'd probably recommend that you wait until I switch the i386 port to using config.new (shortly after the 1.0 release), since it's likely that code would end up being significantly different. Where do I get a copy of the PCI spec? The number I have for Intel's PCI group seems to be no longer in service... 1-800-433-5177 is the current number, as far as I know. From owner-amiga-dev@netbsd.org Tue Aug 30 06:04:41 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Problem reports? To: chopps@emunix.emich.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@netbsd.org On Mon, 29 Aug 1994 chopps@emunix.emich.edu wrote: > > Can I see a show of hands from people that are having problems > with the current release? I recall seeing posts about > system hangs with heavy disk activety. Can people seeing > this please report your system configuration (i.e. dmesg) > > Also is it possible that you are running out of swap? If > so can you run `pstat -s' as a background task while doing > whatever it is (this would be good to know too) that hangs > your system. > > Regarding the A2091 in a A4000 problems. Is anyone out there > using an A2091 in a A2000? If so are you seeing problems? > > I haven't made changes to these subsystems in a while that > would cause any of these problems so its hard to figure > out what the problem is. > > I need more info. > > Chris. I'm running with an A2019 in a 2500 (A2630). I am getting some spontaneous system hangs, reboots, and all around flaky behavior, but only while doing heavy compiles. I have seen no evidence tat I'm running out of swap. I have ~40MB swap and 4MB RAM, and even under the heaviest usage I have not seen any more than about 10MB swap in use. I think there's something flakey in there, but I can't find anything repeatable. Eduardo From owner-current-users@netbsd.org Tue Aug 30 06:30:36 1994 From: Andrew Cagney To: current-users@sun-lamp.cs.berkeley.edu Subject: Self contained, dynamically linked binaries? Sender: owner-current-users@netbsd.org Hello, (For want of a better title) I'm interested in a bit of the story behind NetBSD's implementation of dynamically linked binaries. I understand that it was based (loosly?) on SunOS-4's implementation. The current implementation, dynamic binaries do not include a default LD_LIBRARY_PATH value. I'm interested in learning why this is the case and if there is any plan to integrate this feature(?) in a future version of the dynamic library code. Off hand, possible reasons for leaving it out would include security, simplicity or even `things-to-do-one-day' :-) I'm asking as I'd like a method of building packages that, when installed, do not require the configuration of either LD_LIBRARY_PATH or ldconfig. (Specifying the full path to each library, when linking, sort of acheives this, but takes away some of the flexability). any history welcome, regards Andrew From owner-amiga@netbsd.org Tue Aug 30 06:55:21 1994 From: SULEWSKIJ@delphi.com Subject: X11 and me To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: INTERNET"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@netbsd.org Well I finally got most of netbsd working. I didn't get multi-user working but I haven't gotten all the files. But what files do I need to get x11 working on my a3000. And is anybody working on a spectrum driver? I really need X11 soon, and regensburg has X11R6. I got the bin and the fonts what else do I need? Thanks. From owner-current-users@netbsd.org Tue Aug 30 07:05:13 1994 From: "Charles M. Hannum" To: tls@panix.com Cc: port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: BT946C support -- maybe I _am_ an idiot? Sender: owner-current-users@netbsd.org Many motherboards seem to ship with all the PCI interrupts switched off. `Oh joy.' To make it work correctly, the "PIN" setting in the "Auto-SCSI" adapter BIOS has to be set to the letter of the PCI INterrupt (ever wonder what PIN stood for? Nice that the BT946 manual documents it, huh?) Actually, in the PCI spec it corresponds to one of four real pins. However, the spec specifically says that a single-function board should only use INTA#. I can only guess that the slot itself is supposed to wire the interrupt lines to whatever IRQs on the ISA-compatible interrupt controllers. (If anyone knows more about this, speak up!) Currently, the PCI autoconfiguration code relies on the PCI BIOS to have stored the number of the ISA interrupt line onto the board. This is really all I can do without getting into horrible chipset dependencies that I really don't want to think about. Could the kernel autodetect some of this stuff? There is currently no specific PCI support for the BusLogic controllers; they are just used as if they were EISA or VLB boards. If you'd like to add some PCI autoconfiguration support for them, I'd probably recommend that you wait until I switch the i386 port to using config.new (shortly after the 1.0 release), since it's likely that code would end up being significantly different. Where do I get a copy of the PCI spec? The number I have for Intel's PCI group seems to be no longer in service... 1-800-433-5177 is the current number, as far as I know. From owner-current-users@netbsd.org Tue Aug 30 07:06:40 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Profiling Weirdness Solved. Cc: jtc@cygnus.com Sender: owner-current-users@netbsd.org > The enclosed change to asm.h [...]. > I don't understand the "movl $1b,%eax" that I removed, or the .long 0 > in the data segement. %eax is likely to be clobbered by mcount(), > and the .long 0 doesn't look like it is ever referenced. [diff, edited down] > *** 67,69 **** > # define _BEGIN_ENTRY .data; 1:; .long 0; .text; .align 2 > ! # define _END_ENTRY movl $1b,%eax; call PIC_PLT(mcount) > #else > --- 67,69 ---- > # define _BEGIN_ENTRY .data; 1:; .long 0; .text; .align 2 > ! # define _END_ENTRY pushl %ebp; movl %esp,%ebp; call PIC_PLT(mcount); popl %ebp > #else The "movl $1b,%eax" moves the address of local label 1b - ie, the address of that .long 0 that was mystifying you - into %eax. Presumably mcount uses this address for something. (Many UNIX-derived assemblers use $ to indicate an immediate operand, what many other assemblers use # for. Confusing, but that's history for you. The resulting code, because it contains an address in an immediate operand, is not PIC, but presumably that doesn't matter. If the '386 has an instruction that, like the VAX MOVAB/MOVAW/MOVAL, moves the address of a datum that can be referred to with a pc-relative addressing mode, one could perhaps argue that it'd be better to use it.) So that long in the data segment _is_ referenced, and I hope this clears up the mystery instruction for you. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@netbsd.org Tue Aug 30 07:25:03 1994 From: Thor Lancelot Simon To: port-i386@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: BT946C support -- maybe I _am_ an idiot? Sender: owner-current-users@netbsd.org Many motherboards seem to ship with all the PCI interrupts switched off. Incredibly enough, the BT946 will boot DOS and even some Unixes in this condition. To make it work correctly, the "PIN" setting in the "Auto-SCSI" adapter BIOS has to be set to the letter of the PCI INterrupt (ever wonder what PIN stood for? Nice that the BT946 manual documents it, huh?) that your motherboard's BIOS has set to the same IRQ number as the board's slot. That sounds somewhat complex, but that's what appears to work, and I can't seem to find a better way to simplify it. If you still can't get it to work, try turning off some of the PCI caches your chipset may provide. Of course, most motherboards ship with *those* turned off, too, but who knows? My motherboards actually seem to work OK modulo coming from the manufacturer in a really stupid configuration. When will people learn that turning off features can sometimes make hardware *less* compatible? Of the three different kinds of PCI motherboards I tested today, *none* worked right with their default settings or the recommended settings from their alleged "manuals". Two seemed to work okay once I learned what parts of the manual I had to ignore completely. PCI autoconfiguration. heh. Could the kernel autodetect some of this stuff? Where do I get a copy of the PCI spec? The number I have for Intel's PCI group seems to be no longer in service... Hope this is helpful to someone. Thor From owner-amiga@netbsd.org Tue Aug 30 08:55:45 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: elm 2.4 PL23 + emacs -> no go! :-( To: chopps@emunix.emich.edu Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 485 Sender: owner-amiga@netbsd.org > There seem to be problems with a few setups, however I must ask you: > "How do you expect a system to become stable?" Do you think that if > we all wait around it will get fixed? No we need people testing it. That is a very good statement. Right now my situation is so tight that I can't spend any extra time to setup a whole new system. I believe upgrading from #744 to -current means that? Things will get better in a month or two, maybe the -current stability too :-) ++Tero From owner-amiga@netbsd.org Tue Aug 30 12:27:40 1994 From: Hubert Feyrer "X11 and me" (Aug 29, 11:03pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I really need X11 soon, and regensburg has X11R6. I got the bin and the fonts > what else do I need? Thanks. -rw-rw-r-- 1 bsdadmin ftpadmin 1523819 Aug 17 17:22 X11R6.lib-16Aug94.tar.gz Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@netbsd.org Tue Aug 30 12:34:37 1994 From: Karl-Gunnar Hultland Subject: Upgrading... To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 795 Sender: owner-amiga@netbsd.org OK, now I have a couple of questions. I have FINALLY decided to upgrade from 744 to the 1.0b version and now I have a couple of questions. 1) First what is on the RootFS floppy? As it lacks a ls command I have been unable to list its contents. 2) I understand that the filesystem has changed and that I thus will need to reformat my old partitions. Now my question is, how do I do such a thing and is it possible from NetBSD 1.0 to READ the old format? I would like to keep an old partition with the sourcefiles and such that I gathered during my 744 days. 3) Where can I find info on what to call the partitions now under 1.0b. Does anyone of you have some kind of installation manual floating around, even a draught one would be very much appreciated. Karl From owner-amiga@netbsd.org Tue Aug 30 12:36:40 1994 From: Hubert Feyrer "Keymaps, Views, Docs." (Aug 29, 2:11pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Keymaps, Views, Docs. Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@netbsd.org > 1) How do I change the keymaps without recompiling. Hubert > mentioned that this was possible. Is it so difficult to look at the stuff in the directory I gave you? 1.) Get /pub/netbsd/NetBSD-current/src/src/sys/arch/amiga/stand/loadkmap/* from ftp.iastate.edu 2.) Be sure to have enought of the other source 'round, mainly header-files. 3.) gcc din-kbdmap.c -o din-kbdmap ; din-kbdmap >din.map 4.) gcc us-kbdmap.c -o us-kbdmap ; us-kbdmap >us.map 5.) gcc loadkmap.c -o loadkmap 6.) Now... "loadkmap din.map" -> German keymap "loadkmap us.map" -> US keymap 7.) rm din-kbdmap us-kbdmap > 2) Is it possible to have different 'views' or 'screens' .. with a > different login in each? No, not with native NetBSD. Look at the screen-package available via FTP somewhere. > 3) Where is the rest of /usr/share/doc. there looks to be some really > good info in there, if it wasn't missing. I cant find it in sun-lamp Have you searched everywhere below ftp.iastate.edu /pub/netbsd/NetBSD-current/src/src/share/doc? I guess it it's not there, it will be nowhere else. > 4) Is the ados filesystem r/w or just read? Is it safe? It's read-only and I guess it can be considered safe, although it's not the fastest. > 5) - finally - are the answers to these questions written up anywhere? > Is there an Amiga FAQ? Is there going to be one? Try ftp.uni-regensburg.de:/pub/NetBSD-Amiga/doc, but beware, they haven't yet been updated to 1.0. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@netbsd.org Tue Aug 30 12:42:16 1994 X400-Originator: Knappe@tu-harburg.d400.de X400-Recipients: non-disclosure:; X400-Mts-Identifier: [/PRMD=tu-harburg/ADMD=d400-gw/C=de/;<199408301006.MAA02641@indi1.cip] X400-Content-Type: P2-1984 (2) Content-Identifier: Generic-A3000... Alternate-Recipient: Allowed From: Frank Knappe To: amiga@sun-lamp.cs.berkeley.edu Subject: Generic-A3000.Kernel X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 869 Sender: owner-amiga@netbsd.org Hallo ! Yesterday I changed my Kernel of my 1.0_Beta.NetBSD from generic-Kernel of the 1.0-release to the netbsd.a3000-940814-Kernel. After changing the fstab-file ( sd6 to sd0 ) , the system works and I have more memory ( great ). But then comes the Problem : If I want mount my ados-partition with mount_ados /dev/sd0d /mnt I get the error-message ........ Operation not supportet by device. Has the A3000.Kernel no ados-support or what the mistake ? Another question: It's possible to use a HD-Floppy under NetBSD? Thanks for help ! Frank -- ************************************************************************** " The world is coming to an end . Please log off . " Anonymous Frank Knappe E-Mail : Knappe@tu-harburg.d400.de *************************************************************************** From owner-amiga-dev@netbsd.org Tue Aug 30 12:57:55 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: RE: NetBSD 1.0b SCSI problem To: buehler@chclu.chemie.uni-konstanz.de (JOCHEN BUEHLER) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Amiga development) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@netbsd.org > > The default setup tries to allocate a DMA bounce buffer in Z2 memory > > (if available) or Chip mem, but there must be something wrong > > with the DMA routines. > > Hmm.. Is anybody working on fixing this? > > Michael Hitch tried but as he doesn't own an A2091 I had to test > the changes. > As I'm no kernel hacker I cannot contribute much to this problem. > But if you want to investigate you're welcome ! I'm not a kernel hacker neither. Not yet anyway :) but if it's only one driver I might figure out something.. > Thanks I'll try that, just a same DMA will not work.. It worked fine in > my old 0.9a #744 kernel.. > > Really ? On my system HD speed wasn't faster with 744 (haven't checked > wether DMA worked or not :) ) Hmm.. I thought DMA was default enabled but perhaps it wasn't.. I tried to binpatch my kernel yesterday but I got a Symbol not found, what kernel are you using? Can you uuencode and send it to me or suply me with a ftp site? > Hmm.. Maybe I should have a look at some source files. > > Yes. I'll see if I can get them home today.. /Michael From owner-amiga@netbsd.org Tue Aug 30 13:25:17 1994 From: Hubert Feyrer "Upgrading..." (Aug 30, 10:18am) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Upgrading... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@netbsd.org > 1) First what is on the RootFS floppy? As it lacks a ls command > I have been unable to list its contents. "echo *" worked fine with me, and "pwd" is a big help, too. :-) > 2) I understand that the filesystem has changed and that I thus will need > to reformat my old partitions. Now my question is, how do I do such > a thing and is it possible from NetBSD 1.0 to READ the old format? I > would like to keep an old partition with the sourcefiles and such > that I gathered during my 744 days. Yes, NetBSD-1.0(b) can read old filesystems. > 3) Where can I find info on what to call the partitions now under 1.0b. > Does anyone of you have some kind of installation manual floating > around, even a draught one would be very much appreciated. There was a instlalation guide some time ago, but it contained some bugs. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@netbsd.org Tue Aug 30 14:13:32 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Viking Moniter" (Aug 25, 4:16pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu, slotta@viper.ELP.CWRU.Edu (Douglas Slotta) Subject: Re: Viking Moniter Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@netbsd.org On Aug 25, 4:16pm, chopps@emunix.emich.edu wrote: > Subject: Re: Viking Moniter > Doesn't this use the same hardware as the A2024 monitor? If so then yes > it will work. Same hardware, but other resolutions. -- Markus Illenseer From owner-current-users@netbsd.org Tue Aug 30 14:15:47 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: core@sun-lamp.cs.berkeley.edu Subject: I was gone... now I'm back. From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@netbsd.org I just got home less than two hours ago from spending more than a week at Microsoft in Redmond working on a project. I had been getting current-users directly on my home NetBSD box via my PPP link. When I got home this evening, I noticed that my phone line had been disconnected by a break in the cable outside my house (so says the fixit-line answer droid), and all netbsd-current mail to me (michaelv@HeadCandy.com) will bounce if it hasn't already. What's more, they can't fix the damn thing til Wednesday. :-( So, if you sent me anything you deem important, please resend it to this address. Also, could a core member please fill me in on what's happened with NetBSD in the last week and a half. Especially with the impending release of 1.0. Also, you may want to remove my other address from majordomo temporarily so things don't bounce all over the place, until I get a chance to get my PPP link back up after Wednesday. (And, Adam, I looked you up in the Microsoft internal directory, but was too busy to give you a ring. But your office number and extension have been noted for future reference. ;-) ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-amiga-x@netbsd.org Tue Aug 30 14:21:49 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "New stuff on ftp.uni-regensburg.de" (Aug 28, 9:41pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hubert Feyrer , amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: New stuff on ftp.uni-regensburg.de Sender: owner-amiga-x@netbsd.org On Aug 28, 9:41pm, Hubert Feyrer wrote: > 1.) contrib/X11/german.xmodmaprc, a german .xmodmaprc (I didn't do this myself, > can't remember where I got it from). Flames, contributions and bug reports to this file go to Harald 'Bodo_II' Backert and me. Remember to set your shell and Xterm to 8Bit, and use an ISO-8859-Font to get Umlauts displayed correctly. -- Markus Illenseer From owner-current-users@netbsd.org Tue Aug 30 14:55:22 1994 From: Hubert Feyrer "Mirrors for 1.0" (Aug 29, 1:03pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Mirrors for 1.0 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-current-users@netbsd.org > Anyway, i'd like to: > (1) set up a bunch of mirror sites before it's announced > to the public (for obvious reasons), and > (2) set up a mailing list of people running mirror sites, > so that i can get in contact with you all easily. > > If you're interested in mirroring the FULL 1.0 release, i.e. > source distributions, and binary distributions for ALL architectures, > please send me mail. Can you give an estimate of the disk space needed for this? Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga@netbsd.org Tue Aug 30 15:13:26 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "New stuff on ftp.uni-regensburg.de" (Aug 28, 9:41pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Hubert Feyrer , amiga@sun-lamp.cs.berkeley.edu, amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: New stuff on ftp.uni-regensburg.de Sender: owner-amiga@netbsd.org On Aug 28, 9:41pm, Hubert Feyrer wrote: > 1.) contrib/X11/german.xmodmaprc, a german .xmodmaprc (I didn't do this myself, > can't remember where I got it from). Flames, contributions and bug reports to this file go to Harald 'Bodo_II' Backert and me. Remember to set your shell and Xterm to 8Bit, and use an ISO-8859-Font to get Umlauts displayed correctly. -- Markus Illenseer From owner-amiga-dev@netbsd.org Tue Aug 30 16:06:22 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Problem reports?" (Aug 29, 10:56am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@netbsd.org On Aug 29, 10:56am, chopps@emunix.emich.edu wrote: > Subject: Problem reports? > > Can I see a show of hands from people that are having problems > with the current release? I recall seeing posts about > system hangs with heavy disk activety. Can people seeing > this please report your system configuration (i.e. dmesg) I had the (funny) oportunity to run netBSD on a friend's A2000 with A2091 and A2630. It was recognized as A1200... no idea why. Unfortunately i can't send you dmseg-output. -- Markus Illenseer From owner-amiga@netbsd.org Tue Aug 30 16:10:04 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Problem reports?" (Aug 29, 10:56am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Problem reports? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@netbsd.org On Aug 29, 10:56am, chopps@emunix.emich.edu wrote: > Subject: Problem reports? > > Can I see a show of hands from people that are having problems > with the current release? I recall seeing posts about > system hangs with heavy disk activety. Can people seeing > this please report your system configuration (i.e. dmesg) I had the (funny) oportunity to run netBSD on a friend's A2000 with A2091 and A2630. It was recognized as A1200... no idea why. Unfortunately i can't send you dmseg-output. -- Markus Illenseer From owner-amiga@netbsd.org Tue Aug 30 16:15:15 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Keymaps, Views, Docs." (Aug 29, 2:11pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Steve Parkinson , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Keymaps, Views, Docs. Sender: owner-amiga@netbsd.org On Aug 29, 2:11pm, Steve Parkinson wrote: > Subject: Keymaps, Views, Docs. > > 1) How do I change the keymaps without recompiling. Hubert > mentioned that this was possible. Which keymaps? Have a look in /usr/src/sys/amiga/stand/loadkmap > 4) Is the ados filesystem r/w or just read? Is it safe? Read-only, safe. > 5) - finally - are the answers to these questions written up anywhere? > Is there an Amiga FAQ? Is there going to be one? There are plenty of FAQs... just none of them cover above questions anyway. -- Markus Illenseer From owner-amiga@netbsd.org Tue Aug 30 17:22:16 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Problem reports? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@netbsd.org In article <9408301257.AA00637@lerche.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > On Aug 29, 10:56am, chopps@emunix.emich.edu wrote: > > Subject: Problem reports? > > > > Can I see a show of hands from people that are having problems > > with the current release? I recall seeing posts about > > system hangs with heavy disk activety. Can people seeing > > this please report your system configuration (i.e. dmesg) > > I had the (funny) oportunity to run netBSD on a friend's A2000 > with A2091 and A2630. It was recognized as A1200... no idea why. I posted why some months back. Loadbsd looks at the resident list to decide what model the computer is, and on some 2000s the card.resource or whatever it's called is present. Loadbsd needs to try actually opening the thing to see if it's really a 1200. -- Ty Sarna "You can lead a gift horse to water but tsarna@endicor.com you can't make him look you in the mouth" From owner-amiga-dev@netbsd.org Tue Aug 30 17:45:35 1994 From: Hubert Feyrer "Re: Problem reports?" (Aug 30, 1:57pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I had the (funny) oportunity to run netBSD on a friend's A2000 > with A2091 and A2630. It was recognized as A1200... no idea why. Which kernel did you use? I haven't observed this on dusk. Hubert P.S.: Please stop posting to multiple lists. -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@netbsd.org Tue Aug 30 17:57:13 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Problem reports?" (Aug 30, 4:20pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Problem reports? Sender: owner-amiga-dev@netbsd.org On Aug 30, 4:20pm, Hubert Feyrer wrote: > Subject: Re: Problem reports? > > I had the (funny) oportunity to run netBSD on a friend's A2000 > > with A2091 and A2630. It was recognized as A1200... no idea why. > > Which kernel did you use? I haven't observed this on dusk. Latest netbsd kernel on your ftp-server and my own compilation (with Picasso support :-). -- Markus Illenseer From owner-current-users@netbsd.org Tue Aug 30 19:09:03 1994 From: Mark Gooderum Subject: Re: Am I an idiot, or is the BT946C support flaky? To: Thor Lancelot Simon Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 906 Sender: owner-current-users@netbsd.org Well, some quick comments on the BT946C... I just put up one of these in a BSDI box (using the AHA1542) drive. I had few problems...execpt: The PC's are the new DEC PCI machines. Their PCI isn't quite up to snuff...they autoconf the rom address but not the IRQ. To get it to work, I had to enable the PCI slot, set the IRQ (I used 15) on the slot, enable the slot for bus mastering, go into the card bios, and set it to the matching IRQ. If the IRQ was wrong, the symptom would be the machine would boot all the way through the autoconf stuff (because the probes poll), but would hang (time out or just hang), on mounting root because that is when the card would start to be accessed in non-polled mode. The card would probe at the IRQ set in the card, but if this didn't match the IRQ set on the slot...tough nuggies. Good luck though, the card is fast, even in 1542 compatibility mode... -- Mark From owner-amiga-dev@netbsd.org Tue Aug 30 19:56:23 1994 From: chammer@hrz.uni-bielefeld.de Subject: supservers for netbsd-current: where? To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: Elm [revision: 109.14] Sender: owner-amiga-dev@netbsd.org Hi, since dusk is gone offline i need another supserver. please tell me. ciao Carsten -- Carsten Hammer Schwindstr. 7 33615 Bielefeld Fakultaet fuer Physik D4-139 chammer@POST.uni-bielefeld.de http://phyhammer.uni-bielefeld.de/ From owner-amiga@netbsd.org Wed Aug 31 02:02:54 1994 From: Hartmut Kuehn Subject: Re: NetBSD 1.0 and install (fwd) To: amiga@netbsd.org X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1162 Sender: owner-amiga@netbsd.org SULEWSKIJ@delphi.com: >From SULEWSKIJ@delphi.com Tue Aug 30 05:42:29 1994 From: SULEWSKIJ@delphi.com Date: Mon, 29 Aug 1994 22:54:24 -0400 (EDT) Subject: Re: NetBSD 1.0 and install To: ghost@cs.tu-berlin.de Message-id: <01HGHYAJT3HE9898KN@delphi.com> X-VMS-To: IN%"ghost@cs.tu-berlin.de" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: 7BIT thanks, I did get it to work, but how do you get your arrow keys and number keys to work. At the command line up and down give me funny characters and in vi they do delete right and left. My backspace and del key don't work either. Does anybody now how to map the keyboard? ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@{cs.tu|macbeth.in}-berlin.de * * (or kuehaaaf@zrz.tu-berlin.de) * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-current-users@netbsd.org Wed Aug 31 02:54:51 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: small patch for tcsh under NetBSD/sparc X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 482 Sender: owner-current-users@netbsd.org Hi, here is a small patch for tcsh-6.05 to compile under NetBSD/sparc: --- sh.sem.c~ Sun Jun 26 00:02:49 1994 +++ sh.sem.c Tue Aug 30 18:39:45 1994 @@ -50,7 +50,7 @@ #endif /* CLOSE_ON_EXEC */ #if defined(__sparc__) || defined(sparc) -# if !defined(MACH) && SYSVREL == 0 && !defined(Lynx) +# if !defined(MACH) && SYSVREL == 0 && !defined(Lynx) && !defined(__NetBSD__) # include # endif /* !MACH && SYSVREL == 0 */ #endif /* __sparc__ || sparc */ Matthieu From owner-current-users@netbsd.org Wed Aug 31 03:00:29 1994 From: Hubert Feyrer X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@netbsd.org Wed Aug 31 03:06:43 1994 To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Profiling Weirdness Solved. <199408300107.VAA01821@Collatz.McRCIM.McGill.EDU> From: "J.T. Conklin" Sender: owner-current-users@netbsd.org > > I don't understand the "movl $1b,%eax" that I removed, or the .long 0 > > in the data segement. %eax is likely to be clobbered by mcount(), > > and the .long 0 doesn't look like it is ever referenced. > > The "movl $1b,%eax" moves the address of local label 1b - ie, the > address of that .long 0 that was mystifying you - into %eax. > Presumably mcount uses this address for something. (Many UNIX-derived > assemblers use $ to indicate an immediate operand, what many other > assemblers use # for. Confusing, but that's history for you. Thanks, I read the $1b has an immediate operand, and didn't realize it refered to the address of label 1. However, I am still confused by the fact that the %eax is not used by mcount(), and `gcc -pg' generated code emits .long 0's, but doesn't reference them at all. It's probably just an anachronism. Probably gcc should be changed to stop emitting the .long 0's; and the ENTRY() macro in should be changed to omit the .long 0 and the movl $1b,%eax. --jtc From owner-current-users@netbsd.org Wed Aug 31 03:16:03 1994 To: Hubert Feyrer Cc: current-users@netbsd.org Subject: Re: Intel: supported hardware? <9408310020.ZM10785@rrzc1> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@netbsd.org > Is there a list of hardware supported by NetBSD/Intel? I'm in the process of writing up installation notes, and will be kicking out some _real_ binaries that people can test install as soon as one of my least favorite regional network providers gets their collective butt in gear to fix a problem... anyway, below is the 'hardware' list. Note that not all of the supported hardware isn't supported on the distribution floppies, for various reasons. (In particular, i'm disappointed that the 'wt' driver won't be on the distribution floppies. however, if it is, it can reprogram people's SMC/Western Digital ethernet boards accidentally!) chris ========================================================================= NetBSD/i386 1.0 runs on ISA (AT-Bus), EISA, PCI, and VL-bus systems with 386-family processors, with or without math coprocessors. It does NOT support MCA systems, such as some IBM PS/2 systems. The minimal configuration requires 4M of RAM and 40M of disk space. To install the entire system requires much more disk space, and to run X or compile the system, more RAM is recommended. (4M of RAM will actually allow you to run X and/or compile, but it won't be speedy.) Supported devices include: Floppy controllers. MFM, ESDI, IDE, and RLL hard disk controllers. SCSI host adapters: Adaptec AHA-152x (and other AIC-6260-based boards, such as the SoundBlaster SCSI host adapter) Adaptec AHA-154xA, -B, -C, and -CF [only on kcaha floppy] Adaptec AHA-174x Adaptec AIC-6360-based boards Buslogic 54x [AHA-154x clones; only on kcaha floppy] Buslogic 445, 74x, 9xx [only on kcbt floppy] NCR 53C810 PCI SCSI host adapter Ultrastor 14f, 34f, and (possibly) 24f MDA, CGA, VGA, SVGA, and HGC Display Adapters. (Note that not all of the display adapters NetBSD/i386 can work with are supported by X.) Serial ports: 8250/16450-based ports 16550-based ports AST-style 4-port serial boards [*] IBM PC-RT 4-port serial boards [*] Parallel ports. Ethernet controllers: AT&T StarLAN 10, EN100, and StarLAN Fiber 3COM 3c501 [*] 3COM 3c503 3COM 3c505 [*] 3COM 3c507 3COM 3c509 and 3c579 Digital DEPCA BICC Isolan [not recently tested] SMC/WD 8003, 8013, and the SMC "Elite16" ISA boards SMC/WD 8216 (the SMC "Elite16 Ultra" ISA boards) Novell NE1000, NE2000 Novell NE2100 [not recently tested] Tape drives: Most SCSI tape drives QIC-02 and QIC-36 format (Archive- and Wangtek- compatible) tape drives [*] CD-ROM drives: Mitsumi CD-ROM drives [*] Most SCSI CD-ROM drives Mice: "Logitech"-style mice [*] "Microsoft"-style mice [*] "PS/2"-style mice [*] Serial mice (no kernel support necessary) Miscellaneous: SoundBlaster [*] Drivers for hardware marked with "[*]" are NOT included on the distribution floppies. Except as noted above, all other drivers are present on both kernel-copy disks. Also, at the present time, the distributed kernels support only one SCSI host adapter per machine. NetBSD normally allows more, though, so if you have more than one, you can use all of them by compiling a custom kernel once NetBSD is installed. Hardware the we do NOT currently support, but get many questions about: Adaptec AIC-7770-based SCSI host adapters (including the Adaptec AHA-274x, AHA-284x, and AHA-294x families). Intel EtherExpress Ethernet boards. NCR 5380-based SCSI host adapters. PCMCIA devices. QIC-40 and QIC-80 tape drives. (Those are the tape drives that connect to the floppy disk controller.) WD-7000 SCSI host adapters. To be detected by the distributed kernels, the devices must be configured as follows: Device Name Port IRQ DRQ Misc ------ ---- ---- --- --- ---- Serial ports com0 0x3f8 4 [8250/16450/16550/clones] com1 0x2f8 3 [8250/16450/16550/clones] com2 0x3e8 5 [8250/16450/16550/clones] Parallel ports lpt0 0x378 7 [interrupt-driven or polling] lpt1 0x278 [polling only] lpt2 0x3bc [polling only] MFM/ESDI/IDE/RLL hard disk controller wdc0 0x1f0 14 [supports two disks] Floppy controller fdc0 0x3f0 6 2 [supports two disks] AHA-154x, AHA-174x (in compatibility mode), or BT-54x SCSI host adapters aha0 0x330 any any [only on kcaha kernel floppy] AHA-174x SCSI host adapters (in enhanced mode) ahb0 any any any BT445, BT74x, or BT9xx SCSI host adapters bt0 0x330 any any [only on kcbt kernel floppy] Ultrastor 14f, 24f (if it works), or 34f SCSI host adapters uha0 0x330 any any AHA-152x, AIC-6260- or AIC-6360-based SCSI host adapters aic0 0x340 11 6 NCR 53C810 PCI SCSI host adapter ncr0 any any any SCSI disks sd0 first SCSI disk (by SCSI id) sd1 second SCSI disk (by SCSI id) sd2 third SCSI disk (by SCSI id) sd3 fourth SCSI disk (by SCSI id) SCSI tapes st0 first SCSI tape (by SCSI id) st1 second SCSI tape (by SCSI id) SCSI CD-ROMs cd0 first SCSI CD-ROM (by SCSI id) cd1 second SCSI CD-ROM (by SCSI id) SMC/WD 8003, 8013, Elite16, and Elite16 Ultra Ethernet boards, 3c503, Novell NE1000, or NE2000 Ethernet boards ed0 0x280 2 iomem 0xd0000 ed1 0x250 2 iomem 0xd8000 ed2 0x300 10 iomem 0xcc000 3COM 3c509 or 3COM 3c597 Ethernet boards ep0 any any AT&T StarLAN 10, EN100, or StarLAN Fiber, or 3COM 3c507 Ethernet boards ie0 0x360 7 iomem 0xd0000 BICC Isolan, Novell NE2100, or Digitial DEPCA Ethernet boards le0 0x320 10 7 From owner-current-users@netbsd.org Wed Aug 31 03:23:38 1994 From: "Charles M. Hannum" To: agc@uts.amdahl.com Cc: cagney@highland.oz.au, current-users@sun-lamp.cs.berkeley.edu Subject: Re: VI in dumb mode? Sender: owner-current-users@netbsd.org The problem above is that you should be invoking vi by using the name "ex" - and you can edit using ex-mode commands (all the ':' ones you use in vi). vi(1)'s historic `open mode' is *not* the same as the ex(1) interface, unfortunately. From owner-current-users@netbsd.org Wed Aug 31 03:37:30 1994 To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: cagney@highland.oz.au (Andrew Cagney), current-users@sun-lamp.cs.berkeley.edu Subject: Re: VI in dumb mode? X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@netbsd.org > The problem above is that you should be invoking vi by using the name > "ex" - and you can edit using ex-mode commands (all the ':' ones you > use in vi). not really true: traditional 'vi' invokes 'open mode' if it can't do the right thing with the terminal. for instance, under OSF/1: 127 [alpha] cgd % setenv TERM dumb 128 [alpha] cgd % vi /etc/passwd [Using open mode] "/etc/passwd" [Read only] 16 lines, 1025 characters root:YOU_WISH!:0:1:system PRIVILEGED account:/:/bin/csh nvi should do this as well, but Keith Bostic hasn't done the support for it yet. it requires several things: (1) one line 'editing windows' and currently nvi only has support for windows >= 2 lines, and (2) a reasonable idea of what open mode does; it's completely undocumented! chris From owner-amiga@netbsd.org Wed Aug 31 04:45:39 1994 From: Hartmut Kuehn Subject: Re: NetBSD 1.0 and install (fwd) To: amiga@netbsd.org X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1268 Sender: owner-amiga@netbsd.org michel beausejour: > From mbeausej@qc.bell.ca Wed Aug 31 03:12:35 1994 > Date: Tue, 30 Aug 94 21:10:28 EDT > From: mbeausej@qc.bell.ca (michel beausejour) > Message-Id: <9408310110.AA04333@blmc36.QC.Bell.CA> > To: ghost@cs.tu-berlin.de > Subject: Re: NetBSD 1.0 and install (fwd) > > > If your using BASH as a shell the del key and left arrow will delete characters > plus it has a recall (using up arrow) of the previous commands which is nice > Bye > Michel Thanks for the info, Michel, but I am not the original poster, it was suleswkij@delphi.com, who had problems with his keys. I will forward this mail to amiga@netbsd.org, please fellows, don't reply directly but forward all answers to the mailing list by putting amiga...@netbsd.org in Cc:. Thanks ******************************************************* * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ******************************************************* * E-Mail: ghost@{cs.tu|macbeth.in}-berlin.de * * (or kuehaaaf@zrz.tu-berlin.de) * ******************************************************* * "There are two ways of writing error-free programs. * * Only the third one works." * ******************************************************* From owner-current-users@netbsd.org Wed Aug 31 05:04:37 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: VI in dumb mode? To: cagney@highland.oz.au (Andrew Cagney) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1199 Sender: owner-current-users@netbsd.org > I've noticed that the new VI(1) (to 0.9) no longer works in dumb mode. > i.e.: > > $ touch test > $ TERM=unknown vi test > test: new file: line 1 > Error: Initscr failed: No such file or directory > No TERM environment variable set, or TERM set to "unknown" The "vi" in 0.9 was elvis. Since about February/March, the -current vi has been nvi, from Berkeley. Over the last week, the version of nvi has just been updated from 1.11 to 1.34, and that version includes many bug fixes. The 1.34 sources I grabbed compiled out of the box on NetBSD 1.0_BETA from 21st August. The problem above is that you should be invoking vi by using the name "ex" - and you can edit using ex-mode commands (all the ':' ones you use in vi). $ TERM=unknown vi crap crap: unmodified: line 1 Error: Initscr failed: No such file or directory No TERM environment variable set, or TERM set to "unknown" $ TERM=unknown ex crap crap: unmodified: line 32 : version Version 1.11, Thu Mar 24 21:07:47 1994 The CSRG, University of California, Berkeley. : q $ Cheers, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From owner-amiga@netbsd.org Wed Aug 31 06:06:29 1994 From: SULEWSKIJ@delphi.com Subject: Install X HelpMe To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: INTERNET"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@netbsd.org Okay, I successfully downloaded and uncompressed the needed X files. X11R6.bin X11R6.lib X11R6.fonts I install these files to /usr/X11R6/bin and /usr/x11R6/lib. However, I can't run X windows. First I make sure there is a path to: /usr/X11R6/bin /usr/X11R6/lib /usr/X11R6 I then execute ldconfig /usr/X11R6/lib Then I type startx The following error occurs about a minute later. fatal server error failed to establish all listening sockets amigachangekbdtranslation can't open kb file or directory does not exist WHat does this mean. I am try to run this in single user mode because my arrow keys don't allow me the luxury of using vi. Besides, vi now crashes on me whenever I try to run it anyway. But I don't think this is causing the problem. The only Faqs I found were on X11R5, are there install faq for R6. Besides, I found the X11R5 a bit confusing. Are there any faqs out there that I can read? Thanks in advance, Joe Sulewski From owner-amiga-dev@netbsd.org Wed Aug 31 06:19:28 1994 Subject: Re: Problem reports? To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) From: "Dick Wood" Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 943 Sender: owner-amiga-dev@netbsd.org > From: sjr@zombie.ncsc.mil (Stephen J. Roznowski) > > From: chopps@emunix.emich.edu > > Can I see a show of hands from people that are having problems > > with the current release? I recall seeing posts about > > system hangs with heavy disk activety. Can people seeing > > this please report your system configuration (i.e. dmesg) > > I'm still having occasional hangs under heavy floppy driver activity > (for example, running the mkfloppy script that I sent you). This is > on a stock A3000. > > Other than that, the current release has been pretty solid for me. > > -SR > Well, Stephen, I'm still having only rare successful use from my Archive Viper Tape drive. And then only with 'tar'. 'dd' absolutely refuses to work for me - either reading or writing; at least with the senarios I've tried. Did you ever get a (definitive) answer on the "flakey-ness" you were looking into? If you did, I guess I missed your post. -dick From owner-current-users@netbsd.org Wed Aug 31 07:14:40 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: what changed recently in i386 com/tty driver? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@netbsd.org I don't have an old copy of com.c or tty.c hanging around, and I wish I did. I'm seeing a total failure of Taylor UUCP 1.05 to connect via a modem using the i or j protocol, and a lot of failures using 'g'. Things worked just fine before I built a -current kernel sometime in the past week. I tried recompiling tuucp with the most recent header files, but I don't have an absolutely-up-to-date libc. The recompiled versions still can't connect with 'i' or 'j' Did something change in the kernel innards that would confuse/screw up UUCP negotations? [Maybe parity stuff or 8-bit stuff?] ==John From owner-current-users@netbsd.org Wed Aug 31 07:23:32 1994 To: "Chris G. Demetriou" Cc: Hubert Feyrer , current-users@netbsd.org Subject: Re: Intel: supported hardware? <9408302306.AA00539@alpha.bostic.com> From: HINO Koji Sender: owner-current-users@netbsd.org Just some comments.. :> SCSI host adapters: :> Adaptec AHA-152x (and other AIC-6260-based boards, such :> as the SoundBlaster SCSI host adapter) Additional note: without a boot ROM on these board, you can not boot NetBSD from these boards.. IDE or other type of disk required. :> MDA, CGA, VGA, SVGA, and HGC Display Adapters. (Note that not :> all of the display adapters NetBSD/i386 can work with :> are supported by X.) Additional note: refer XFree FAQ. :> Hardware the we do NOT currently support, but get many questions :> about: :> Adaptec AIC-7770-based SCSI host adapters (including the :> Adaptec AHA-274x, AHA-284x, and AHA-294x families). :> .... Draw a distinction between them. * May be supported soon. * not supported for a while, or forever X-< ==================================================================== Koji HINO(HINO is my family name) C&C Research Laboratories, NEC Corporation From owner-amiga-x@netbsd.org Wed Aug 31 07:46:22 1994 From: "L. Todd Masco" To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Interesting effect... Sender: owner-amiga-x@netbsd.org I was playing around with the most recent Xmono (for X11R5), trying to find the largest screen I could get w/out getting that annoying PAL flicker on my ECS machine (A3000). At the dividing line between PAL and NTSC behavior, you get something very... odd. Try invoking the server with -H 483 and you'll see what I mean. No big deal, just an interesting little thing. -- L. Todd Masco | "Which part of 'shall not be infringed' didn't cactus@bb.com | you understand?" From owner-netbsd-users@netbsd.org Wed Aug 31 08:09:33 1994 From: allex@phys10.phys.nchu.edu.tw (Administrator Ru-han Juang) Subject: How to read MS-DOS file from NetBSD To: netbsd-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 288 Sender: owner-netbsd-users@netbsd.org I'm using NetBSD 0.9, and not familiar with it. How can I read DOS files from floppy ? I found a program in /usr/local/bin named mread, which seems like what I want. But how to use it ? I use 'man mread', and found no entry of that. Please help me. Thanks a lot. From owner-amiga-dev@netbsd.org Wed Aug 31 08:14:02 1994 From: Arthur Hoffmann Subject: gdb broken with new kernels? To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 645 Sender: owner-amiga-dev@netbsd.org Hi I was wondering if something changed in later kernels which prevents gdb from workin? not too long ago I still could use gdb, even it told me something about terminal inferior for each step I went through the source code. Now it starts up ok, but when I want to debug it it tells me that it can't read (acces) register 17 and can't run. I'll have a look when I'm home and send a complete error message of it. My kernel was compiled with a sup update of last week's sources. thanks. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-amiga@netbsd.org Wed Aug 31 08:30:10 1994 Subject: Re: Install X HelpMe To: SULEWSKIJ@delphi.com, amiga@sun-lamp.cs.berkeley.edu Followup-To: amiga-x@sun-lamp.cs.berkeley.edu From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 642 Sender: owner-amiga@netbsd.org SULEWSKIJ@delphi.com writes: >Okay, I successfully downloaded and uncompressed the needed X files. >X11R6.bin >X11R6.lib >X11R6.fonts > >I install these files to /usr/X11R6/bin and /usr/x11R6/lib. However, I >can't run X windows. First I make sure there is a path to: >/usr/X11R6/bin >/usr/X11R6/lib >/usr/X11R6 ?? Only /usr/X11R6/bin needs an path. >I then execute ldconfig /usr/X11R6/lib >Then I type startx >The following error occurs about a minute later. >fatal server error >failed to establish all listening sockets >amigachangekbdtranslation can't open kb file or directory does not exist Mmmh, which kernel do you use ? Bernd From owner-current-users@netbsd.org Wed Aug 31 09:49:26 1994 From: "Mark P. Gooderum" Subject: i386/machdep.c broken To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 386 Sender: owner-current-users@netbsd.org After supping last night, I get this error on machdep.c: ../../../../arch/i386/i386/machdep.c:768: unterminated character constant ../../../../arch/i386/i386/machdep.c:844: unterminated string or character constant ../../../../arch/i386/i386/machdep.c:531: possible real start of unterminated constant The offending line 531 is an asm(" at the beginning of check_selector(). -- Mark From owner-amiga@netbsd.org Wed Aug 31 10:55:27 1994 From: Hubert Feyrer "Install X HelpMe" (Aug 30, 11:10pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/Ihere. From owner-amiga-dev@netbsd.org Wed Aug 31 11:06:42 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: malloc above splimp Sender: owner-amiga-dev@netbsd.org I'm getting successful with the GoldenGate and the com driver. Now I can actually use it for logging in and dialout. However at high speeds there can occur some problems, one of them being malloc messing up its internal state. After some investigation I found that malloc does splimp which is spl3 in the amiga port. As I use si_addcallback at spl6 this can (and will) result in bad behaviour. This morning I saw the following call chain (from memory, excuse me if I don't remember the exact names): lev4intr -> si_remcallback -> malloc -> lev6intr -> ggbusintr -> comintr -> si_addcallback -> malloc -> lev6intr -> ggbusintr -> comintr -> si_addcallback -> malloc -> addrerr As you can see malloc won't be enough protected. This can either be solved by increasing splimp(), but that might affect other parts of the system badly performancewise, I don't know, or we could change malloc to be splhigh which also could increase interrupt latencies, or we could drop malloc from the si_callback handling using a callback pool instead. This would both be faster than malloc and an easy fix as it will only have local influences. The drawback is that it has to be a static limit of callbacks, but as the descriptors are small anyway I think this is not a problem. I'm thinking of a default of about 64 descriptors requiring about a K of coremem. Do someone have a problem with this? I'll probably write the support down this evening, if someone (Chris) doesn't say we should solve it differently. And yes, I've already change the si_callback stack to a queue instead. I'll provide a patch to anyone interested. On a related topic, we need to redo the interrupt system a bit in order to have drivers being LKMs. We must have a interrupt handling registration during attachment like the i386 port. I'm willing to write this if Chris says go. A new isa-support patchset will be put up for ftp in a day or two, this time with at least a mostly working com-driver (and if we're lucky, a start of the isa ed ethernet driver, NE-2000 and such). I'd like to poll this group for people having interests in the isabus efforts. If you want to use your specific bridgecard with NetBSD, please mail me a say what HW you're most interested in seeing support for. I'm going for parallel ports, floppies, mice and Mitsumi CDs next, mostly because I have use for them. Other interesting things would be other E-net cards, SVGAs, SCSI, IDE & soundcards, but those I don't need myself. 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 From owner-amiga-dev@netbsd.org Wed Aug 31 19:46:56 1994 From: chopps@emunix.emich.edu To: niklas@appli.se (Niklas Hallqvist) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, chopps@emunix.emich.edu Subject: Re: malloc above splimp <9408310835.AA22318@della.appli.se> X-Mts: smtp Sender: owner-amiga-dev@netbsd.org > I'm getting successful with the GoldenGate and the com driver. Now I > can actually use it for logging in and dialout. However at high speeds > there can occur some problems, one of them being malloc messing up its > internal state. After some investigation I found that malloc does > splimp which is spl3 in the amiga port. As I use si_addcallback at > spl6 this can (and will) result in bad behaviour. This morning I saw > the following call chain (from memory, excuse me if I don't remember > the exact names): The point of si_callbacks as far as I saw was that you wanted to delay processing of a certain interrupt code to lower priority. I guess I need to here why your callbacks need splhigh() protection (if I understand what your requesting). If its do to interrupts from the IO bridge, is it possible to use interrupt level 2 instead? This is the level that IO should take place at not level 6. Interrupt level 6 is reserved for system clocks and other things (?) of such high importance. Changing splimp() to splhigh() whould have many unwanted side-effects I would think. I don't like the idea at all. For example spltty() would be interrupted by a level 6 interrupt to what would you do for that? I have run into a similar problem however with the ASDG LAN Rover. My board interrupts only at level 6. To solve this I will use an si_callback that processes most of the interrupt. With the actual level 6 handler just clearing the interrupt and saving it in a software register for processing by the call back. This is messy but its really the only way to handle such problems. > using a callback pool instead. This would both be faster than malloc > and an easy fix as it will only have local influences. The drawback > is that it has to be a static limit of callbacks, but as the descriptors Using malloc is nice in that it doesn't waste any memory and it can accomadte many requests all made at `once'. I think we should keep it. > On a related topic, we need to redo the interrupt system a bit in order > to have drivers being LKMs. We must have a interrupt handling > registration during attachment like the i386 port. I'm willing to > write this if Chris says go. I was going to write this and put it in after the release. If you can wait I would appreciate it. If you need it now however go ahead. Chris. From owner-amiga@netbsd.org Wed Aug 31 19:49:57 1994 From: Karl-Gunnar Hultland Subject: Problems with installing 1.0b To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 854 Sender: owner-amiga@netbsd.org After finding a fossile (Aug 1st) NetBSD 1.0b draft install I have managed to get all the .tar.gz files installed on my A3000. After seeing some corrections in the comp.unix.amiga newsgroup I managed to create the -altroot-dev entries too. The problem now for me is that I can't make the new root read only... When I try the /altroot/sbin/mount -u -r /altroot command I get the message that /etc/fstab is missing, then I tried to skip that part and continued with the install instructions. What happened then was: 1) When I did the reboot I ended up in AmigaDOS and not in single-user mode 2) After then trying to use my new root file system as boot-device my Amy locked up after the 2 Mice 10 views message. Anyone has any ideas what might be wrong, and do anyone of you have a more recent pre-release doc on installing 1.0b? Karl From owner-amiga-dev@netbsd.org Wed Aug 31 20:06:44 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: gtsc_dma timeout Sender: owner-amiga-dev@netbsd.org Hi, again. I've started to get this message: gtsc_dma0: timeout #1 sometimes during startup. I have recently changed my config so it'll configure my 2nd gtsc controller, but I don't know if it started before or after that change. I haven't seen any bad behaviour apart from the message. Before I look into it, does anyone know if this is normal when having two gtsc controllers configured. If it had been gtsc_dma1 I'd not worried at all (hey that SCSIbus is empty and even unterminated) but it says gtsc_dma0, which is the controller where I keep all my data. 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 From owner-netbsd-users@netbsd.org Wed Aug 31 20:19:03 1994 From: Hubert Feyrer "How to read MS-DOS file from NetBSD" (Aug 31, 12:30pm) X-Face: iT2VNvH@a.&tC|E|:zwsgA^NC@o4gqqj3M3b-R4~1zpZ4y%@B@ZfP,7=U"{2^xd%"5iGa-* ss+;}8PfLd?Fx[>$>E^GO:Xb"N!k`8&f1;UPdEl;\:1'stGP/I I'm using NetBSD 0.9, and not familiar with it. > How can I read DOS files from floppy ? > I found a program in /usr/local/bin named mread, which seems like > what I want. > But how to use it ? > I use 'man mread', and found no entry of that. I haven't installed NetBSD/intel, so the following might be wrong... There's a package out there called "Mtools" which enables you to access MS-DOS-disks via commands as mdir, mcopy, ... AFAIK, mread is one of them, but not intended to be used by users directly. Als, "mount -t msdosds /dev/fd0c /mnt" or such should work. Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@netbsd.org Wed Aug 31 20:20:49 1994 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.169:31.07.94.17.33.53] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: malloc ab... From: "hamish (h.i.) macdonald" To: chopps@emunix.emich.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: malloc above splimp Sender: owner-amiga-dev@netbsd.org >>>>> On Wed Aug 31 13:22:00 1994, >>>>> You wrote: chopps> The point of si_callbacks as far as I saw was that you wanted chopps> to delay processing of a certain interrupt code to lower chopps> priority. I guess I need to here why your callbacks need chopps> splhigh() protection (if I understand what your requesting). I believe that the problem that Niklas is seeing is: 1) somebody calls malloc 2) as part of malloc processing, malloc calls splimp, presumably to block out anybody messing around with mallocs data structures from an interrupt. 3) his board interrupts at level 6 (this is allowed, because only levels 3 and below are blocked out at splimp) 4) Niklas *wants* to delay processing to a lower interrupt level, so he calls si_callback in order to schedule his callback at a lower interrupt level. 5) si_callback calls malloc to allocate some structures: OOPS, malloc has been re-entrantly called, its data structures get hosed. Niklas is proposing that either: 1) make malloc call splhigh, to block *all* interrupts. 2) make si_callback not use malloc, so that it is usable from interrupt levels above splimp. I can see a third alternative: 3) don't allow interrupts above splimp to call si_callback. This doesn't seem reasonable. Caveat: I don't really know anything about the internals in NetBSD of all this stuff. I'm just pointing out what I inferred from Niklas' article. From owner-amiga-dev@netbsd.org Wed Aug 31 21:15:21 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: Re: Problem reports? To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Amiga development) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@netbsd.org > > Regarding the A2091 in a A4000 problems. Is anyone out there > > using an A2091 in a A2000? If so are you seeing problems? > > > > I haven't made changes to these subsystems in a while that > > would cause any of these problems so its hard to figure > > out what the problem is. > > I have been attempting to track down this problem with Jochen Buehler > without much luck. Not having an A2091 on my machine is a very severe > handicap in trying to troubleshoot a problem like this. I will gladly help in anyway I can. Just let me know what you need and I'll try to help.. > worked fine up to that point.] At this point, I've run out of things > to try and don't know what else to do to try and fix this. I only seem to have the problem when booting with root on a A2091 partition, I can mount the partitions and transfer from them just fine if I have root on an IDE partition.. /Michael From owner-amiga-dev@netbsd.org Wed Aug 31 21:23:31 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: RE: NetBSD 1.0b SCSI problem To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Amiga development) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@netbsd.org > From: JOCHEN BUEHLER > > I'm not a kernel hacker neither. Not yet anyway :) but if it's only one > driver I might figure out something.. > > Hope so :) So do I, I'll try my first kernel compile today I hope.. > Hmm.. I thought DMA was default enabled but perhaps it wasn't.. I tried > to binpatch my kernel yesterday but I got a Symbol not found, what > kernel are you using? Can you uuencode and send it to me or suply me with > a ftp site? > > The symbols for SCSI-DMA have changed between 744 and -current. > -current: _sbic_no_dma=[0,1] (0...enabled,1...disabled) > _use_z2_mem = [0,1] (use Zorro2 memory for bounce buffer > if available, else Chip-mem) Guess I'll have to try again then.. > -744: don't remember (long gone... :) ). > Maybe something like _scsi_no_dma (it's listed in the > old 744 FAQ though) > Doesn't matter anyway #744 is long gone from my Harddisk :) /Michael From owner-amiga-dev@netbsd.org Wed Aug 31 23:54:41 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: niklas@appli.se (Niklas Hallqvist) Subject: Re: malloc above splimp Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@netbsd.org On Aug 31, 8:23pm, Niklas Hallqvist wrote: > follow. What I find peculiar is that our good old serial driver doesn't > trigger this. Am I forgetting a fact? It may of course be pure luck I think you misunderstand the Amiga serial driver. The only thing done at interrupt level 5 is the character is read from the serial input buffer and stored into a local fifo buffer. The fifo buffer is processed later by a routine called from the vertical blank interrupt. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA