From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 1 03:49:31 1994 Subject: Problems w/ 940329 SUP kernel 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 A few problems with a kernel SUPed yesterday: - machdep.c makes a reference to arpintr, which is defined only if the ethernet pseudo-device is enabled. I run SLIP, and no Ethernet, so... barf. - I get "panic: swfree()" when I try to boot the new kernel. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 04:02:04 1994 From: "Nathan J. Dohm" To: amiga@sun-lamp.cs.berkeley.edu Subject: SLIP problems, etc. Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm reinstalling NetBSD after a hiatus. I installed the new root installation and booted it up. I'm trying to set up a SLIP connection to download the rest of the software. When I type slattach -s 38400 /dev/tty00 It returns an error message: Ioctl inappropriate for device. I've got an A3000, 4 MB ram, nothing else special. Any help would be appreciated. Also -- is it even possible to run X with 4 MB? I tried the very first server that was released (w/o shared libs) and it started up but swapped when I moved the mouse, which wasn't real useful. :) How is the performance with 8 MB? If I got a Retina board, does the on-board memory affect performance much? Well, I guess you guys now have the only Amiga operating system under development anymore, congrats. :) Thanks, Nathan From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 04:33:42 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: mouse device To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu does anyone have a description of the mouse device? Tim N. From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 05:36:56 1994 From: Keith Lea Subject: Can't get Netbsd to Find Root To: NetBSD Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have a Progressive 040 W/58MB of ram I am using a Commodore 2091 with a Micropolis 323M Hard Drive only for Net bsd It goes through the initialization and then says cannot mount Root It says that it finds the root partition and switching root to sd2a and still did not find it. Anyone could help I would appreciate it. Also does anyone know where I can find version ixemul.library version 46 the version of binpatch says I have version 44, I have not been able to find it Anyone could tell me where it is I would appreciate it. One last thing, Why does the NEtbsd rootfs not look past the second SCSI device. I have 3 SCSI controller in my machine and it does not find it and it has the tape drive. Thanks keith ***************************************************************************** *Keith Lea--Software Engineer/Certified Novell Engineer *100% Amiga All Day All the time--I don't Like Windows its just my Day Job *Amiga 2000/040,2000/030,4000/030-Emplant,386BB,VLAB,EGS-Spectrum ***************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 06:10:55 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: mouse device To: newsham@uhunix.uhcc.Hawaii.Edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 312 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > does anyone have a description of the mouse > device? > > Tim N. Heh I wondered the same thing awhile back. I don't rember now but I do remember how I figured it out simply. cat /dev/mouse0 | hexdump along with looking at the files related to the mouse device should help you.. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 06:34:39 1994 Subject: vi and termcap From: David Jones To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Vi scrolls the screen slowely. I've ktraced it, and instead of scrolling, vi writes out the entire screen. /etc/termcap and /usr/share/misc/termcap both exist. I have looked at the NetBSD FAQ on eunet, but this does not help. Any ideas? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 06:50:15 1994 From: Steve Parkinson Subject: Boot problems 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: 1274 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > a2000/a2620/4mb 32bit fast/1mb chip/240mb quantum (netbsd)/ 40mb segate. > > Using rootfs_720 loadbsd-940320 and vmunix.generic.940305 or vmunix.generic- > 940325. > > It seems to startup ok... > > thinks its a a2000/68030 etc.. not a 68020. > > It finds root ok on sd6a but then goes into a dead loop for ever. > > trapsignal(1,11,3466,d8a,d86) > I just reinstalled everything and am having similar problems. Setup: a4000/40 12MB Fast 2MB chip 120MB maxtor, GVP4008 scsi rootfs720 When I use vmunix.generic.940305 I get the same as you. (I have had this running ok previously too, so I'm bemused to why it doesn't work now) When I use netbsd.generic-940427 I get: changing root device ti sd0a sd0: scsi sense class 7, code 0, key 5 blk12599840 (I certainly don't have that many blocks on my drive, if it is blk is disk blocks!) I heard that '/bin/sh' in the 720 rootfs is not 040 compatable. So I extracted the latest (late april) bin.tar and copied /bin/sh from that archive to the rootfs partition with bffs. Still no joy. Any clues? Does anyone know if you are supposed to set the _a3000_flag to 0 if you also set the _a4000_flag to 1. I am not currently changing _a3000_flag. ^^ can someone make sure that the _a4000_flag is in the FAQ. Steve From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 07:07:30 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD Subject: Re: Can't get Netbsd to Find Root Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 30, 10:28pm, Keith Lea wrote: > I have a Progressive 040 W/58MB of ram Must be a Zeus - the 040/2000 board can only have 32MB. > I am using a Commodore 2091 with a Micropolis 323M Hard Drive only for Net > bsd > It goes through the initialization and then says cannot mount Root > It says that it finds the root partition and switching root to sd2a and > still did not find it. > Anyone could help I would appreciate it. What version of the kernel are you using? Since it says it is switching to sd2a, then it sees the root partition, but if it can't mount the root, it isn't seeing the right data in the partition. One suggestion I usually have is to binpatch _sddebug to 1. This will have sddriver print out the information it finds on all the partitions it finds. From that, you can tell if NetBSD is finding the partitions where you actually put them. One possible reason for the "unable to mount root" panic is if the Reserved field in the partition isn't zero (it defaults to 2, so has to be changed). Another possibility is that the data isn't getting written to the correct location on the disk. This is easy to do if using the filedev (?) program. Dcp makes this a little less error prone, and the streamtodev set of programs is almost fool-proof. > One last thing, Why does the NEtbsd rootfs not look past the second SCSI > device. I have 3 SCSI controller in my machine and it does not find it > and it has the tape drive. Most (if not all) kernels are only compiled with support for one each of the 33c39, 53c710, and 5380 based controllers. Since you appear to have a PPI Zeus board, the Zeus controller and the 2091 will be configured. If your third SCSI board is another 2091 or a GVP, it won't be recognized since the single 33C93 controller will be the first 2091. You will need to rebuild the kernel with support for two 33C93 controllers in that case. [I would be interested in knowing if that even works. I didn't have any way to test that support.] Michael From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 07:09:53 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: mouse device Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 30, 11:24pm, Chris Hopps wrote: > > does anyone have a description of the mouse > > device? > > > > Tim N. > > Heh I wondered the same thing awhile back. I don't rember now but > I do remember how I figured it out simply. > > cat /dev/mouse0 | hexdump > > along with looking at the files related to the mouse device should > help you.. There was also a little mouse test program that Markus Wild included when the mouse driver was first added. I don't know if I still have a copy around somewhere or not. Michael From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 07:27:47 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Steve Parkinson , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Boot problems Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Apr 30, 9:01pm, Steve Parkinson wrote: > I heard that '/bin/sh' in the 720 rootfs is not 040 compatable. So I > extracted the latest (late april) bin.tar and copied /bin/sh from that > archive to the rootfs partition with bffs. Still no joy. The /bin/sh on the 720 rootfs will lock up the machine if you try to do any command substitution within a script file. This shouldn't happen until you try to start up multi-user mode. > Does anyone know if you are supposed to set the _a3000_flag to 0 if you > also set the _a4000_flag to 1. I am not currently changing _a3000_flag. If _a4000_flag is set, it doesn't make any difference what _a3000_flag is. Now that I have an A4000/40, I can support it better. Thanks to Bill Coldwell, I think I can now get loadbsd and NetBSD to determine if the machine is an A4000, A1200, A3000, or A2000/A500 and eliminate any need to patch flags for the machine type. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 1 14:32:22 1994 From: Keith Lea Subject: Can't get NetBSD to find root To: NetBSD Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu This is a more complete description of my problem I am just starting trying to get NetBSD to load on My AMIGA here is my problem. I goes through its initilization finding all the HD then it says it cannot find root This is the command I am using to start it. loadbsd vmunix.744 It reboots says the following Amiga/A2000 MC68040 CPU real mem = 50331648 avail mem = 45096960 using 320 buffers containing 2621440 bytes of memory Realtime clock A2000 rtclock0 [1/9] par0 [1/6] grf0: 640 x 400 4 color custom chips display grf0: [1/7] ser0 [1/3] siop: siop id 7 Zeusscsi0 [2026/150] siop0: target 0 now synchronous, period=200ns, offset=8 rz0: SEAGATE ST1480 rev 5972, 832527 512 byte blocks rz0: at Zeusscsi0, slave 0 dma0: A2091 DMA scsi0: scsi id 7 a2091scsi [514/3] sd2: MICROP 1684-07MB1042605 rev , 663476 512 byte blocks sd2 at a2091scsi0, slave2 Changing root device to sd2a bpf: sl0 attached bpf: ppp0 attached bpf: lo0 attached panic: cannot mount root hit any key to boot/dump That is what happens when I try to start it up. I pulled all the NetBSD from ftp.luth.se and am using the NetBSD.Install.744 I have no Idea what these things are telling me so if someone could tell me what the heck is going on, and how to make it work I would appreciate it. My configuration is A2000/040 52MB Ram-Zeus-Progressive Peripherals A2091/2MB RAM - This is the controller the NEtbsd drive is connected to 2 MB of RAM GVP Impact series II no RAM *************************************** Also why doesn't NetBSD look past the first 2 scsi controllers it finds as I have 3 in my machine it never finds the GVP as it is the 3rd one Zorro slot wise. Thanks keith ***************************************************************************** *Keith Lea--Software Engineer/Certified Novell Engineer *100% Amiga All Day All the time--I don't Like Windows its just my Day Job *Amiga 2000/040,2000/030,4000/030-Emplant,386BB,VLAB,EGS-Spectrum ***************************************************************************** *Amiga 2000/040,2000/030,4000/030-Emplant,386BB,VLAB,EGS-Spectrum ***************************************************************************** From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 2 04:34:50 1994 From: Hubert Feyrer Subject: Re: SLIP problems, etc. To: dohm+@CMU.EDU (Nathan J. Dohm) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1442 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I'm reinstalling NetBSD after a hiatus. I installed the new root > installation and booted it up. I'm trying to set up a SLIP connection > to download the rest of the software. When I type > slattach -s 38400 /dev/tty00 > It returns an error message: Ioctl inappropriate for device. Looks as if your slattach isn't compiled to run with your kernel. Try updating slattach! > Also -- is it even possible to run X with 4 MB? I tried the very first > server that was released (w/o shared libs) and it started up but swapped > when I moved the mouse, which wasn't real useful. :) How is the > performance with 8 MB? If I got a Retina board, does the on-board memory > affect performance much? I haven't seen X on a 4MB-machine, but when using the Xmono-server on my 8MB-machine, it's a bit faster than with the Retina-server I tried recently. > > Well, I guess you guys now have the only Amiga operating system under > development anymore, congrats. :) Oh, don't forget about Linux/m68k! 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 Mon May 2 04:36:02 1994 From: Hubert Feyrer Subject: Re: Can't get Netbsd to Find Root To: keith@cais.com (Keith Lea) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 663 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > It goes through the initialization and then says cannot mount Root > It says that it finds the root partition and switching root to sd2a and > still did not find it. Please verify if you've set the reserved blocks to zero! 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 Mon May 2 04:44:09 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: Can't get Netbsd to Find Root Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > One last thing, Why does the NEtbsd rootfs not look past the second SCSI > > device. I have 3 SCSI controller in my machine and it does not find it > > and it has the tape drive. > > Most (if not all) kernels are only compiled with support for one each > of the 33c39, 53c710, and 5380 based controllers. Since you appear to > have a PPI Zeus board, the Zeus controller and the 2091 will be configured. > If your third SCSI board is another 2091 or a GVP, it won't be recognized > since the single 33C93 controller will be the first 2091. You will need > to rebuild the kernel with support for two 33C93 controllers in that case. > [I would be interested in knowing if that even works. I didn't have any > way to test that support.] I'd be interested in knowing what your configuration looks like. That way I can update the GENERIC configuration file to work for multiple controllers. -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 2 04:46:50 1994 From: rhealey@aggregate.com (Rob Healey) Subject: Re: Problems w/ 940329 SUP kernel To: dej@eecg.toronto.edu (David Jones) Cc: amiga-dev@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: 843 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > A few problems with a kernel SUPed yesterday: > > - machdep.c makes a reference to arpintr, which is defined only if the > ethernet pseudo-device is enabled. I run SLIP, and no Ethernet, so... > barf. > This bit the x86 people, you need some ifdefs in machdep.c, maybe Chris can muck with this the next time he's in machdep.c? > - I get "panic: swfree()" when I try to boot the new kernel. > I saw this on a 12M 3000 but not on a 16M 3000, go figure... One VERY disturbing addition to this: fsck TRASHES filesystems when built under the 0429 sup code! I installed the new includes, remade the librarys and then made all. fsck keeps finding truncated inodes where there are none! Worse yet, the old fsck won't run under the 0429 kernel, I think cdg removed backward compatability starting with the 0429 sup. B^(. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 2 05:07:51 1994 From: "Stephen J. Roznowski" To: dej@eecg.toronto.edu, rhealey@aggregate.com Subject: Re: Problems w/ 940329 SUP kernel Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > A few problems with a kernel SUPed yesterday: > > > > - machdep.c makes a reference to arpintr, which is defined only if the > > ethernet pseudo-device is enabled. I run SLIP, and no Ethernet, so... > > barf. > > > This bit the x86 people, you need some ifdefs in machdep.c, maybe > Chris can muck with this the next time he's in machdep.c? One workaround is to define "pseudo-device ether" in your kernel configuration file. > > - I get "panic: swfree()" when I try to boot the new kernel. > > > I saw this on a 12M 3000 but not on a 16M 3000, go figure... > > One VERY disturbing addition to this: > > fsck TRASHES filesystems when built under the 0429 sup code! I > installed the new includes, remade the librarys and then made all. I noticed this after doing a complete build. :-( It doesn't appear that this is fixed in the May 1 sources (nothing that fsck uses was supped between the 29th and the 1st). > fsck keeps finding truncated inodes where there are none! Worse > yet, the old fsck won't run under the 0429 kernel, I think cdg removed > backward compatability starting with the 0429 sup. B^(. I wonder if removing the COMPAT_09 option from the kernel would help? [All I can say is that bffs has been a life saver all day! :-] -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 2 21:03:12 1994 From: DCG9367@tntech.edu Subject: Re: Problems w/ 940329 SUP kernel To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"rhealey@aggregate.com" X-Vms-Cc: IN%"amiga-dev@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >> - I get "panic: swfree()" when I try to boot the new kernel. >> > I saw this on a 12M 3000 but not on a 16M 3000, go figure... I also get this on my 8mb 2000 GForce-040. I found that if I do a "loadbsd vmunix -S" it works alright! I also found that the kernel does the same thing when reloading it from within NetBSD. Why is this kernel requiring the symbol table to be loaded? This puts a SERIOUS damper on changing startup files in NetBSD and then rebooting. From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 3 06:39:54 1994 From: Keith Lea Subject: NetBSD Panic To: NetBSD Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am getting this panic while trying to boot NetBSD how do I get around it? I have yet to get into singel user mode to go any further. panic: swfree hit any key to boot/dump I tried setting the Inhibit_sync bits and the No DMA with no change in the result > > My configuration is > > A2000/040 52MB Ram-Zeus-Progressive Peripherals > > A2091/2MB RAM - This is the controller the NEtbsd drive is connected to > > 2 MB of Chip RAM > > GVP Impact series II No Ram Version Thanks in advance Keith From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 3 10:57:01 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Problems compiling libX* From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I've been trying to compile the Xlibs, but I keep getting strange error messages. Here is part of it: including in ./config [: .././X11: binary operator expected blablabla ln -s ../ .. /./config/imakemdep.h . ^ ^ these spaces should not be here ln: ./ is a directory ln: ./.. file exists Here is what I did: I edited the Imake.tmpl according to the RELNOTES.TXT file that comes with X11R5, so that the netbsd*.* files are used. Could it be that somehow somewhere something goes wrong when the makefile(s) are created ? Maybe too many spaces are introduced ? I'm stills running the 720 binaries, maybe that's the problem ?? John Vrolijk From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 3 22:59:55 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: cross-compiling X11 on Sun's From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Has anyone ever attempted to cross-compile X11 (or any other executable for that matter) on a Sun for NetBSD ??? If it is possible, it would be nice, because my Sparc at work is a lot faster than my humble 25 Mhz 68030 at home ;^) John Vrolijk From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 3 23:17:53 1994 From: ahh@netcom.com (Andy Heffernan) Subject: X11R5 binaries 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: 741 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu [I posted this to comp.unix.amiga last night] I have a set of X11R5 binaries/libraries/includes/manpages built over the weekend but no place to put them! ftp.eunet.ch is giving me grief; the release of R6 probably isn't helping matters much. If anyone can suggest an alternate site, I'd appreciate it. A combined mono-ECS/color-Retina server is included. PEX doesn't work (will look at it after I rebuild XView and take a look over R6). -rw-r--r-- 1 root bin 1811462 May 2 23:03 X11R5.bin-01May94.tar.gz -rw-r--r-- 1 root bin 260982 May 1 21:59 X11R5.include-01May94.tar.gz -rw-r--r-- 1 root bin 5009939 May 1 22:06 X11R5.lib-01May94.tar.gz -rw-r--r-- 1 root bin 484461 May 1 22:07 X11R5.man-01May94.tar.gz Thanks. From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 3 23:51:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Problems compiling libX*" (May 3, 8:38am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Problems compiling libX* Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 3, 8:38am, John Vrolijk wrote: > including in ./config > [: .././X11: binary operator expected > > blablabla > > ln -s ../ .. /./config/imakemdep.h . > ^ ^ > these spaces should not be here I had this problem a while ago, too. If i remember right it was a problem with the gcc/preparser and the famous CAT() macro-'bug'. I can't verify this right now, no X11 handy. BTW, X11R6 requires 109MB for the complete sources alone, not to speak of the object-files, libraries and binaries to be created then. But it looks like the fonts are still the same and thus no need to create them (eats way too much in my eyes to create them). Who has space/time and is willing to compile R6 on NetBSD-Amiga? -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed May 4 00:21:18 1994 From: Hubert Feyrer To: ahh@netcom.com, amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: X11R5 binaries Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > much. If anyone can suggest an alternate site, I'd appreciate it. put it into /pub/NetBSD-Amiga/incoming on ftp.uni-regensburg.de and drop me a mail if it's there. 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@sun-lamp.cs.berkeley.edu Wed May 4 00:47:36 1994 From: DCG9367@tntech.edu Subject: Re: NetBSD Panic To: keith@cais.com Cc: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: IN%"keith@cais.com" X-Vms-Cc: IN%"amiga@sun-lamp.cs.berkeley.edu" "NetBSD" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu >I am getting this panic while trying to boot NetBSD how do I get around it >I have yet to get into singel user mode to go any further. > >panic: swfree >hit any key to boot/dump I am assuming you are trying to boot the latest kernel from sun-lamp? If you are then I had the same problem. It seems that the generic kernel WILL NOT run without the symbol table present. Use "loadbsd vmunix -S" to load the symbol table and it should work fine. This also means that you can't copy /vmunix /dev/reload to reload the kernel. I don't think the reload device reloads the symbol table. At least it hasn't worked for me yet. From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 4 00:50:26 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: NetBSD Panic Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 3, 12:57pm, DCG9367@tntech.edu wrote: > fine. This also means that you can't copy /vmunix /dev/reload to reload > the kernel. I don't think the reload device reloads the symbol table. > At least it hasn't worked for me yet. No, the /dev/reload doesn't reload the symbol table. The problem is that the memory for the kernel image has to be allocated when the /dev/reload is first written to. The exec header is transferred and the size of the kernel is determined from the header. However, the symbol string size isn't known until after the symbol table has been transferred, so the /dev/reload code doesn't know how much memory is needed for the symbol table. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed May 4 01:31:07 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: Mounting NetBSD file systems from PC's with PCNFS To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-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: 650 Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Andrew Wheadon > >> >NFS039F : The NET USE failed with an internal error code of 1007 >> I've just been through alittle of this. Have you done the following?: >> 1.) Built and installed the "pcnfsd" that comes with PC-NFS? >> 2.) Added the file system you want to mount to the /etc/exports file? >> 3.) Added the keyword "NFSSERVER" to your kernel config and rebuilt >> your kernal? >> 4.) Made sure the requisite "nfsd"'s are running? >5.) run mountd -n >So non-root can mount too (for dos clients) Duh, right. *That* was the step that kept coming back to haunt me. I knew there was one more thing I wanted to add to that list. Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 01:36:21 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Hmmm...No sir, I don't like it! From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, kids! loading netbsd locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: Undefined symbol _Xstrayirq_num referenced from text segment locore.o: More undefined symbol _Xstrayirq_num refs follow pmap.o: Undefined symbol _pg referenced from text segment pmap.o: Undefined symbol _pg referenced from text segment pmap.o: Undefined symbol _pg referenced from text segment pmap.o: Undefined symbol _pg referenced from text segment pmap.o: Undefined symbol _pg referenced from text segment pmap.o: Undefined symbol _pg referenced from text segment *** Error code 1 No change to configuration...sources as of 5-2-94 Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 01:40:23 1994 From: gregc@edi.com (Greg Cronau) Subject: Dumb SLIP question. 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: 253 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Netbsd apparently lacks the "sldialup" command I'm familiar with. What's the best way to *initiate* the slip connection from the caller's side. I've tried using tip/cu, but once I'm done and exit from it, it hangs up the phone. Thanks Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 01:53:39 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: Buslogic 545 and DTC3290 problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu I believe I've completely fixed the problems with these controllers and the aha1542 driver (including the silly `ignore that'-style message during the probe). People with either of the aforementioned controllers should try the latest version of aha1542.c (1.29 or later) and let me know whether or not they have any problems with it. From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed May 4 02:14:33 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: X11R5 binaries To: Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) Cc: ahh@netcom.com, 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: 238 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > much. If anyone can suggest an alternate site, I'd appreciate it. > put it into /pub/NetBSD-Amiga/incoming on ftp.uni-regensburg.de and > drop me a mail if it's there. OK, they're there. I can upload a fonts-less lib later today. From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 4 02:26:23 1994 From: Keith Lea Subject: Re: NetBSD Panic To: DCG9367@tntech.edu 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, I am using loadbsd netbsd.generic-940427, I guess that is the newest kernel I tried the loadbsd netbsd.generic-940427 -S and the still got the panic. I then tried to load an older kernel and received a trapsignal(3, 11, 0, 0, 2) that was all kernels prior to netbsd.generic-940427 On Tue, 3 May 1994 DCG9367@tntech.edu wrote: > > >I am getting this panic while trying to boot NetBSD how do I get around it > >I have yet to get into singel user mode to go any further. > > > >panic: swfree > >hit any key to boot/dump > > > I am assuming you are trying to boot the latest kernel from sun-lamp? > If you are then I had the same problem. It seems that the generic > kernel WILL NOT run without the symbol table present. > Use "loadbsd vmunix -S" to load the symbol table and it should work > fine. This also means that you can't copy /vmunix /dev/reload to reload > the kernel. I don't think the reload device reloads the symbol table. > At least it hasn't worked for me yet. > From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed May 4 03:07:32 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: X11R5 binaries To: Hubert.Feyrer@rz.uni-regensburg.de, 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: 536 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > > > much. If anyone can suggest an alternate site, I'd appreciate it. > > put it into /pub/NetBSD-Amiga/incoming on ftp.uni-regensburg.de and > > drop me a mail if it's there. > > OK, they're there. > > I can upload a fonts-less lib later today. Aargh! Leave it to me to find a mistake now. I made a mistake with shared library version numbering; everything worked, but it would have been very confusing whenever R6 showed up. I have deleted the bin and lib files and will upload replacements in the near future. Sorry. From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 03:13:19 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: gregc@edi.com (Greg Cronau) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Dumb SLIP question. From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Netbsd apparently lacks the "sldialup" command I'm familiar with. >What's the best way to *initiate* the slip connection from the caller's >side. I've tried using tip/cu, but once I'm done and exit from it, it >hangs up the phone. I run screen, use cu to dial in, then ~!slattach [options], then detach screen. Gross, but it works. --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 Wed May 4 04:19:27 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Dumb SLIP question. <199405032317.SAA07388@packrat.vorpal.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> Netbsd apparently lacks the "sldialup" command I'm familiar with. >>What's the best way to *initiate* the slip connection from the caller's >>side. I've tried using tip/cu, but once I'm done and exit from it, it >>hangs up the phone. >I run screen, use cu to dial in, then ~!slattach [options], then detach >screen. Gross, but it works. > >--Michael That *is* ugly. ;-) I simply use kermit. When the session is connected, you type ctrl-\ z, which suspends the kermit sessions and brings you back to the shell, where you can type your pppd command, or slattach. --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 Wed May 4 05:02:56 1994 Subject: From: rxtgep@escargot.xx.rmit.EDU.AU (Glen Pill) To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm getting the following message filling up my logs... geppc /netbsd: ed0: NIC memory corrupt - invalid packet length 65535 this is with NetBSD-current binaries from ftp.iastate.edu running on a '486/33 with 8Mb RAM the ethernet card is... geppc /netbsd: ed0 at isa0 port 0x280-0x29f iomem 0xe0000-0xe3fff irq 10: address 00:00:c0:ce:a8:83, type SMC8216/SMC8216C (16-bit) is anyone getting the same kind of error? I thought that current had no problem with the SMC Ultra ethernet card? Glen. -- Glen Pill Internet : glenp@rmit.edu.au Tech. Officer Snail : 124 LaTrobe St, Melb. Oz. 3000 Network Services Phone : +61 3 660 2538 RMIT Computer Centre Fax : +61 3 663 5652 From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 05:51:53 1994 To: Kaleb Keithley Cc: rich@lamprey.utmb.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: X11R6 is not ready for FreeBSD yet <9405032027.AA00407@kanga.x.org> From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu {I am forwarding the relevant section of your email to the netbsd-current mailling list) You write: > I beg to differ. I compiled R6 on FreeBSD 1.1 GAMMA with only two > trivial errors related to the lexical analyzer used by FreeBSD and > presumable NetBSD. Note that BSDI's 386/BSD uses the same lex, so > a fix might be as easy as changing "#ifdef __bsdi__" to "#if defined > (__bsdi__) || defined(__FreeBSD__)" Note that this is not necessary, atleast for NetBSD, if you define LEX to be `lex -l', which generates yylineno & friends. Also, your fix does not work in fonts/PEX as yylineno is not declared in lex.l In NetBSD-current imake fails thanks to the off_t change -- ftruncate fails to truncate the generated Makefile! The fix, which should be safe for all, is to explcitly cast the second arg. to (off_t) in imake.c:875: ftruncate(). [Patch attached below.] I don't understand while 0 is not coerced to an off_t, as the relevant header ofiles seem to be included. But I didn't spend time investigating. The server fails to compile as MAP_FILE is not defined (which should've been in ?). xdm fails to link as _crypt could not be found. I thought the correct crypt would've gotten dynamically linked in???? Anyway, I didn't much time on this (though my machine spend hours:-) -- I am reporting this in the hope it is useful to someone else. Bakul PS: a few clients I tried seem to work fine even with my Sun3 X11R4 server but xterm seems to be huge... *** config/imake/imake.c Mon May 2 20:32:29 1994 --- config/imake/imake.c-dist Sun Apr 17 17:10:29 1994 *************** *** 872,878 **** #if defined(SYSV) || defined(WIN32) freopen(tmpfname, "w+", tmpfd); #else /* !SYSV */ ! ftruncate(fileno(tmpfd), (off_t)0); #endif /* !SYSV */ initialized = TRUE; fprintf (tmpfd, "# Makefile generated by imake - do not edit!\n"); --- 872,878 ---- #if defined(SYSV) || defined(WIN32) freopen(tmpfname, "w+", tmpfd); #else /* !SYSV */ ! ftruncate(fileno(tmpfd), 0); #endif /* !SYSV */ initialized = TRUE; fprintf (tmpfd, "# Makefile generated by imake - do not edit!\n"); From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 07:29:12 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@erewhon.CS.Berkeley.EDU X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: kvm-using programs... X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu don't even bother trying to compile libkvm or kvm-using programs after tonight's sup. (also, don't bother mailing and saying that they don't compile... 8-) they should be fixed within a few days. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 4 07:44:47 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Michael L. VanLoon -- Iowa State University" Cc: "Chris G. Demetriou" , current-users@sun-lamp.cs.berkeley.edu Subject: Re: kvm-using programs... <9405040343.AA08159@ponderous.cc.iastate.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > After which time somebody will release a spiffy new top machine file > for NetBSD-current? :-) i can probably do that; i like top... 8-) > Is it possible to integrate top into the standard set of utilities? I > find it a very useful thing to have around. It's been partially > crippled since early April, and I haven't had the time to go learn > about all the little pieces that have broken. Thanks... really? i banged a 'completely working' version together the other day... what wasn't working? cgd From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed May 4 08:48:37 1994 To: ahh@netcom.com (Andy Heffernan) Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: X11R5 binaries From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu How did you manage to get it to compile ? I tried it also, and I keep getting messages like this: including in ./config [: .././X11: binary operator expected blablabla ln -s ../ .. /./config/imakemdep.h . ^ ^ these spaces should not be here Every Makefile that gets created has this problem it seems. Any help welcome. -John Vrolijk From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 4 09:09:52 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: gcc-2.5.8 ?? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anyone know if gcc-2.5.8 is available for NetBSD ? If not, would it be difficult to port it to NetBSD ? In general, does anyone have experience porting GNU programs/utilities to NetBSD ? John Vrolijk From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 5 01:26:43 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, dsnjvro@etmsun.ericsson.se Subject: Re: gcc-2.5.8 ?? Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Does anyone know if gcc-2.5.8 is available for NetBSD ? I believe that it is. Check ftp.eunet.ch for it. > If not, would it be difficult to port it to NetBSD ? > In general, does anyone have experience porting GNU programs/utilities to > NetBSD ? Not very hard at all (except for lately...) Perhaps if I get the chance I'll produce another GNU update and put it on ftp.eunet.ch (or sun-lamp :-) -SR From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 01:27:00 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "X11R5 binaries" (May 4, 7:55am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , ahh@netcom.com (Andy Heffernan) Subject: Re: X11R5 binaries Cc: amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 4, 7:55am, John Vrolijk wrote: > Subject: X11R5 binaries > How did you manage to get it to compile ? Can't remember right now. All i know is, that it is a bug in the preparser, was something with -standard or -compatible or -old, heck, i forgot. Sorry, no big help, i will have a look when i have some more time. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 01:58:51 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 Null message body; hope that's ok Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/lib/csu/ns32k/Makefile U src/lib/csu/ns32k/crt0.c U src/lib/csu/ns32k/gmon.c U src/lib/libc/shlib_version U src/lib/libc/arch/ns32k/DEFS.h U src/lib/libc/arch/ns32k/Makefile.inc U src/lib/libc/arch/ns32k/SYS.h U src/lib/libc/arch/ns32k/gen/ldexp.S U src/lib/libc/arch/ns32k/gen/setjmp.S U src/lib/libc/arch/ns32k/sys/brk.S U src/lib/libc/arch/ns32k/sys/cerror.S U src/lib/libc/arch/ns32k/sys/exect.S U src/lib/libc/arch/ns32k/sys/ptrace.S U src/lib/libc/arch/ns32k/sys/sbrk.S U src/lib/libc/arch/ns32k/sys/setlogin.S U src/lib/libc/arch/ns32k/sys/sigreturn.S U src/lib/libc/sys/Makefile.inc U src/lib/libc/sys/getrlimit.2 U src/lib/libc/sys/setpgid.2 U src/sys/arch/amiga/amiga/trap.c U src/sys/arch/amiga/include/cpu.h U src/sys/arch/hp300/conf/DUALITY U src/sys/arch/hp300/conf/GENERIC.hp300 U src/sys/arch/hp300/conf/HP300 U src/sys/arch/hp300/conf/LINT.hp300 U src/sys/arch/hp300/conf/PICASSO U src/sys/arch/hp300/conf/files.hp300 U src/sys/arch/hp300/dev/grf.c U src/sys/arch/hp300/dev/hil.c U src/sys/arch/hp300/hp300/machdep.c U src/sys/arch/hp300/hp300/trap.c U src/sys/arch/hp300/hpux/hpux_compat.c U src/sys/arch/hp300/hpux/hpux_net.c U src/sys/arch/hp300/hpux/hpux_sig.c U src/sys/arch/hp300/hpux/hpux_tty.c U src/sys/arch/hp300/include/exec.h U src/sys/arch/hp300/include/param.h U src/sys/arch/hp300/include/pcb.h U src/sys/arch/i386/i386/math_emulate.c U src/sys/arch/i386/i386/microtime.s 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/cpu.h U src/sys/arch/i386/isa/aha1542.c U src/sys/arch/i386/isa/aic6360.c U src/sys/arch/i386/isa/clock.c U src/sys/arch/i386/isa/isa.c U src/sys/arch/m68k/m68k/process_machdep.c U src/sys/arch/mac68k/dev/grf.c U src/sys/arch/pc532/conf/GENERIC_O U src/sys/arch/pc532/conf/GENERIC_RD U src/sys/arch/pc532/conf/GENERIC_Z U src/sys/arch/pc532/conf/GENERIC_ZF U src/sys/arch/pc532/conf/Makefile.pc532 U src/sys/arch/pc532/conf/STEELHEAD U src/sys/arch/pc532/include/asm.h U src/sys/arch/pc532/include/endian.h U src/sys/arch/pc532/pc532/clock.c U src/sys/arch/pc532/pc532/mem.c U src/sys/arch/pc532/pc532/pmap.c U src/sys/arch/sun3/conf/GENERIC U src/sys/arch/sun3/conf/Makefile.sun3 U src/sys/arch/sun3/conf/files.sun3.newconf U src/sys/arch/sun3/dev/kd.c U src/sys/arch/sun3/dev/obio.c U src/sys/arch/sun3/dev/zs.c U src/sys/arch/sun3/dev/zsvar.h U src/sys/arch/sun3/include/eeprom.h U src/sys/arch/sun3/include/obio.h U src/sys/arch/sun3/include/param.h U src/sys/arch/sun3/sun3/autoconf.c U src/sys/arch/sun3/sun3/conf.c U src/sys/arch/sun3/sun3/delay.s U src/sys/arch/sun3/sun3/genassym.c U src/sys/arch/sun3/sun3/locore.s U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/mem.c U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/process.s U src/sys/arch/sun3/sun3/sun3_startup.c U src/sys/arch/sun3/sun3/swapgeneric.c U src/sys/arch/sun3/sun3/vm_machdep.c U src/sys/compat/sunos/sun_misc.c U src/sys/kern/init_main.c U src/sys/kern/init_sysent.c U src/sys/kern/kern_acct.c U src/sys/kern/kern_descrip.c U src/sys/kern/kern_exec.c U src/sys/kern/kern_exit.c U src/sys/kern/kern_fork.c U src/sys/kern/kern_kinfo.c U src/sys/kern/kern_physio.c U src/sys/kern/kern_proc.c U src/sys/kern/kern_prot.c U src/sys/kern/kern_resource.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_synch.c U src/sys/kern/subr_prf.c U src/sys/kern/sys_generic.c U src/sys/kern/sys_process.c U src/sys/kern/syscalls.c U src/sys/kern/tty.c U src/sys/kern/tty_pty.c U src/sys/kern/tty_tty.c U src/sys/kern/uipc_usrreq.c U src/sys/kern/vfs_syscalls.c U src/sys/miscfs/fdesc/fdesc_vnops.c U src/sys/miscfs/procfs/procfs_ctl.c U src/sys/miscfs/procfs/procfs_note.c U src/sys/miscfs/procfs/procfs_regs.c U src/sys/miscfs/procfs/procfs_status.c U src/sys/net/if_tun.c U src/sys/net/if_tun.h U src/sys/sys/dkstat.h U src/sys/sys/proc.h U src/sys/sys/ptrace.h U src/sys/sys/resource.h U src/sys/sys/signalvar.h U src/sys/sys/syscall.h U src/sys/sys/tty.h U src/sys/sys/un.h U src/sys/vm/vm_glue.c U src/sys/vm/vm_meter.c U src/sys/vm/vm_mmap.c Running the SUP scanner: SUP Scan for current starting at Wed May 4 03:34:57 1994 SUP Scan for current completed at Wed May 4 03:39:01 1994 SUP Scan for mirror starting at Wed May 4 03:39:02 1994 SUP Scan for mirror completed at Wed May 4 03:43:05 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 01:59:38 1994 To: "Chris G. Demetriou" Cc: pozar@kksf.tbo.com (Tim Pozar), mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Broken make? From: Havard Eidnes Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > The source tree was updated as of 3:30am this morn (4/30/94). I used > > this "current" to regen my make, and the orginal 0.9 make and the one that > > was in the src tree at ftp.iastate.edu. All have this problem. > > 'make' does and has worked for 'a while' (i.e. it's not been changed > in a couple of weeks, at least). It sounds like you're compiling new > versions wirht inconsistent libraries and includes, or *something*, > but 'make' *definitely* works. If I understand him correctly, what he's trying to do is to compile his way from plain old vanilla 0.9 up to "current". Also, if my memory serves me right this has now been said to be difficult or impossible, since too many changes have ocurred since 0.9 and there are too many inter-dependencies between the libraries, the kernel, the include files and the tools. The only option is to use one of the binary kernels on sun-lamp (or elsewhere) and start from a binary snapshot before trying to remake the current sources. Right? - Havard From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:04:22 1994 From: dgy@mcs.com (Donald G. Yuniskis) Subject: newsyslog & cron To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 537 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Greetings! I've noticed sporadic crashes of an (admittedly) older (4/6) current. The system runs fine, unattended and lightly loaded for a day or so, then dies "on the hour". On reboot, there's always at least one pretty good sized disk terd reported (I've disabled fsck -p in favor of fsck). Suspecting newsyslogd, I've commented out all lines of newsyslog.conf. It's been a few days and no crash yet. I suspect problem to be with rolling over the accounting file. Has anyone else seen (fixed?) this? I'll report further findings... From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:06:26 1994 To: Bakul Shah Cc: Kaleb Keithley , rich@lamprey.utmb.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: X11R6 is not ready for FreeBSD yet From: Kaleb Keithley Sender: owner-current-users@sun-lamp.cs.berkeley.edu >{I am forwarding the relevant section of your email to the > netbsd-current mailling list) >You write: >> I beg to differ. I compiled R6 on FreeBSD 1.1 GAMMA with only two >> trivial errors related to the lexical analyzer used by FreeBSD and >> presumable NetBSD. Note that BSDI's 386/BSD uses the same lex, so >> a fix might be as easy as changing "#ifdef __bsdi__" to "#if defined >> (__bsdi__) || defined(__FreeBSD__)" >Note that this is not necessary, atleast for NetBSD, if you define >LEX to be `lex -l', which generates yylineno & friends. Also, >your fix does not work in fonts/PEX as yylineno is not declared in >lex.l >In NetBSD-current imake fails thanks to the off_t change -- >[and lots more about what doesn't work on NetBSD-current deleted] Now I think you're doing everyone a disservice by quoting me out of context. The original post refered only to FreeBSD and I responded solely in that context. Posting to NetBSD's current-users list sends the debate down a path that I can't follow because I'm not on (nor do I wish to be on, I get enough email as it is, thanks) that list, so I can't address any issues that might come up. X11R6 nominally supports NetBSD 0.9 -- period! If NetBSD-current is as far ahead of 0.9 as freebsd-current is ahead of 1.1, then you're talking about apples and oranges. Building (or failing to build) on -current is not a fair test by any stretch of the imagination. The X Consortium would be happy to hear about any problems (in the form of bug-reports) in R6 built against 0.9. It would probably be a wise idea to cc: the XFree86 project as well. I should mention that it is our policy that we only support the OS versions that are offically released at the time of our release, so 1.0, -current, -whatever will never be offically supported until R7 ships. -- Kaleb KEITHLEY X Consortium From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:07:36 1994 From: pozar@kksf.tbo.com (Tim Pozar) Subject: Re: Broken make? To: Havard.Eidnes@runit.sintef.no (Havard Eidnes) Cc: cgd@postgres.berkeley.edu, pozar@kksf.tbo.com, mycroft@gnu.ai.mit.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: 868 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Havard Eidnes wrote: > If I understand him correctly, what he's trying to do is to compile his way > from plain old vanilla 0.9 up to "current". > > Also, if my memory serves me right this has now been said to be difficult > or impossible, since too many changes have ocurred since 0.9 and there are > too many inter-dependencies between the libraries, the kernel, the include > files and the tools. The only option is to use one of the binary kernels > on sun-lamp (or elsewhere) and start from a binary snapshot before trying > to remake the current sources. > > Right? Right... I ended up using the April 17th snapshot. And much help from Jonathan O'Brien. (Thanks!) Tim -- Internet: pozar@kksf.tbo.com Snail: Tim Pozar / KKSF / 77 Maiden Lane / San Francisco CA 94108 / USA POTS: +1 415 788 2022 Radio: KC6GNJ / KAE6247 From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:08:36 1994 From: "Greg L. Tanaka" Subject: Screwed up bad 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 haven't been keeping currently lately because of classes and what not, but yesterday I had some time. So I decided to update my system. I ftped over the tar ball made by cgd and proceeded to untar everything. Well, things went pretty smoothly till ld.so got written over and then everything broke. I did make a fix it floppy with the old kernel, however I forgot to include gzip and tar. As a result, I can't even finish untaring ld.so... Does anyone have any ideas on how I might fix this problem? -Greg Tanaka From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:08:48 1994 From: "Greg L. Tanaka" Subject: Screwed up bad 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 haven't been keeping currently lately because of classes and what not, but yesterday I had some time. So I decided to update my system. I ftped over the tar ball made by cgd and proceeded to untar everything. Well, things went pretty smoothly till ld.so got written over and then everything broke. I did make a fix it floppy with the old kernel, however I forgot to include gzip and tar. As a result, I can't even finish untaring ld.so... Does anyone have any ideas on how I might fix this problem? -Greg Tanaka From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:13:12 1994 From: "Robert L. Shady" Subject: Latest problems To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2875 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Couple quick questions/comments.. I am running currents from the past 2 weeks or some (Apr 20+) on the following configurations ZEUS HADES GATEWAY1 ==== ===== ======= 486/DX40 VLB 386/DX33 386/DX33 16MB RAM 8MB RAM 4MB RAM Adaptec 1542C Generic IDE Cntrlr Generic IDE Cntrlr 180MB SCSI-2 340MB IDE 40MB IDE 1GB SCSI-2 540MB IDE 250MB Wangtek Soundblaster PRO NE-2000 Clone NE-2000 Clone NE-2000 Clone SVGA Card/Monitor SVGA Card/Monitor Mono Card/Monitor 4 16550 Serials 4 16550 Serials 2 28.8k Modems 2 28.8k Modem 2 14.4k Modems 2 14.4k Modems Gateway1 is our SLIP connection to the Internet. It is also our nameserver, and dialup SLIP/PPP server. Hades is our news server. Zeus is our main Interactive dialup server, and backup nameserver. 1) All machines exhibit some form of crash/reboot at least once every 3 days or so. Gateway1 reboots SEVERAL times a day, generally three or four times per hour under normal->heavy load (Average 1000+ cps constant). Is there still a problem with only 4 MB of ram? It seems as thought there is some form of major problem with tcp/ip code that is causing a crash. How would I go about tracing this more closely (assuming I added the DIAGNOSTIC & DDB options to the kernel, how do I trace the stack/etc). 2) What is the best way to avoid an NFS server 'hang'. I am cross mounting several directories between Hades & Zeus, and when one or the other is down, the other hangs indefinately until the other one comes back up. I am using the following in my /etc/fstab: /dev/sd0a / ufs rw 1 1 /dev/sd0e /tmp ufs rw 1 2 /dev/sd1a /home ufs rw 1 3 /dev/mcd0d /cdrom isofs ro 1 3 kernfs /kern kernfs rw 1 1 procfs /proc procfs rw 1 1 hades:/ /hades nfs rw,soft,intr,bg 1 3 hades:/news /news nfs rw,soft,intr,bg 1 3 3) I am still getting a massive amount of SILO overflow's on Gateway1, even though I am using the 16550 UARTS. This is notices with sustained transfer rates of ~1700cps. 4) Was there a good reason for removing/changing the definitions of some of the most common things (ie: sys_errlist, etc)? I asked this before, and I believe that the answer was to become POSIX compatible, but this is starting to get rediculous. I have to really tear apart programs to get them to compile under NetBSD now, where as before, if they worked on a Sun, they probably compiled under NetBSD without change. Is there some way we can put the old defines back, maybe under a "#ifdef PRE_POSIX" or something to make it easy to port old code that may not yet conform? -- Thanks! From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:13:41 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: Dumb SLIP question. To: mark@aggregate.com (Mark P. Gooderum) Cc: gregc@edi.com, explorer@vorpal.com, 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: 345 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mark P. Gooderum > >Finally, does anyone have a version the the "COM_BIDIR" patch that works with >a post mid-April current? I tried hand adpating an old one but a few areas, >notably the open code, have just changed too much to be able to know what to >do. What is the "COM_BIDIR" patch and what is it supposed to do/correct? Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:17:19 1994 From: mark@aggregate.com (Mark P. Gooderum) To: gregc@edi.com, explorer@vorpal.com Subject: Re: Dumb SLIP question. Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I wrote a script to do this... I use kermit and have the script suspend kermit after connecting. Using kermit you can give it a very sophsiticated login script including looping, retries, etc. Anyways after the script suspends, then I run something like: sliplogin foo-slip < /dev/tty01 The only thing I've found is that sliplogin wont run my host specific login/logout file, only the general one. Some day I'll look into this. Another issue is that I'm still working on getting automatic hangup when slattach/sliplogin dies. I'm still searching for the right combo of tty options and modem config. Of course the fun part is I'm also running flexfax on the same modem, so I've got to kill that first. This all worked great until upgrading to the 4/28 sources (and the 5/2 which I just finished) from about 3/15 current. Since then dial in is hosed. Flexfax hangs saying "waiting for modem to come ready" or using getty it runs once and drops straight into login. If I kill the getty/login, init never respawns it, no matter how many HUPs it gets. Probably realated is that I get *lots* of silo overflow errors, even when the modem is idle, and I never got any before (internal v.fast at 38.4k for now). Anyone else seen this? Finally, does anyone have a version the the "COM_BIDIR" patch that works with a post mid-April current? I tried hand adpating an old one but a few areas, notably the open code, have just changed too much to be able to know what to do. Otherwise current works well for me, and outgoing works fine, but incoming is dinked. (For the no-knowing, flexfax opens the line in w/o waiting for carrier and turns *off* auto answer, it then watches for "RING" from the modem and forces it on line, but it's not even getting that far for now). I'll have a lot more info after some debugging tonight. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:21:50 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: "Robert L. Shady" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Hmmm...No sir, I don't like it! From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Wed, 4 May 1994 07:33:21 +1523847 (EDT) "Robert L. Shady" wrote: > > loading netbsd > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > > locore.o: More undefined symbol _Xstrayirq_num refs follow > > pmap.o: Undefined symbol _pg referenced from text segment > > pmap.o: Undefined symbol _pg referenced from text segment > > pmap.o: Undefined symbol _pg referenced from text segment > > pmap.o: Undefined symbol _pg referenced from text segment > > pmap.o: Undefined symbol _pg referenced from text segment > > pmap.o: Undefined symbol _pg referenced from text segment > > *** Error code 1 > > > > No change to configuration...sources as of 5-2-94 > > Did you rebuild "config" first? > Tried that...Same problem... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:22:44 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: PPP AND SUCCESS? ANYONE? ANYONE? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm wondering if anyone has any experience using ppp under NetBSD or NetBSD-current. I'm trying to get it running on a box I have in combination with our annex terminal server. Slip works fine, but ppp seems to hang in the ipcp negotiation phase of the conversation. The only weird thing I can think of about this connection is that the network address for the netbsd side of the connection has to be asserted by the annex box because the IP address you get is determined by which modem you get. Could someone with experience or with an idea take a look at the options file and the log segment I've enclosed and tell me what they think of the problem or what the problem might be? -thanks -Brian P.S. I'm running sources as of January 16, 1994$a and pppd of November 1993. Options file debug lcp-restart 10 ipcp-restart 30 asyncmap 0005001 local 0.0.0.0:128.114.128.8 defaultroute /dev/com0 19200 May 4 12:59:20 freak pppd[4755]: pppd 2.0.2 started by buhrow, uid 0 May 4 12:59:20 freak pppd[4756]: Using interface ppp0 May 4 12:59:20 freak pppd[4756]: Connect: ppp0 <--> /dev/com0 May 4 12:59:20 freak pppd[4756]: fsm_sdata(LCP): Sent code 1, id 1. May 4 12:59:20 freak pppd[4756]: Timeout 3058:1096c in 10 seconds. May 4 12:59:20 freak pppd[4756]: Setting itimer for 10 seconds. May 4 12:59:20 freak pppd[4756]: LCP: sending Configure-Request, id 1 May 4 12:59:20 freak pppd[4756]: IO signal received May 4 12:59:20 freak pppd[4756]: fsm_rconfack(LCP): Rcvd id 1. May 4 12:59:20 freak pppd[4756]: read(fd): EWOULDBLOCK May 4 12:59:20 freak pppd[4756]: IO signal received May 4 12:59:20 freak pppd[4756]: fsm_rconfreq(LCP): Rcvd id 5. May 4 12:59:20 freak pppd[4756]: lcp_reqci: rcvd ASYNCMAP May 4 12:59:20 freak pppd[4756]: (0) May 4 12:59:20 freak pppd[4756]: (ACK) May 4 12:59:20 freak pppd[4756]: lcp_reqci: rcvd MAGICNUMBER May 4 12:59:20 freak pppd[4756]: (4ca446c7) May 4 12:59:20 freak pppd[4756]: (ACK) May 4 12:59:20 freak pppd[4756]: lcp_reqci: rcvd PCOMPRESSION May 4 12:59:20 freak pppd[4756]: (ACK) May 4 12:59:20 freak pppd[4756]: lcp_reqci: rcvd ACCOMPRESSION May 4 12:59:20 freak pppd[4756]: (ACK) May 4 12:59:20 freak pppd[4756]: lcp_reqci: returning CONFACK. May 4 12:59:20 freak pppd[4756]: fsm_sdata(LCP): Sent code 2, id 5. May 4 12:59:20 freak pppd[4756]: Untimeout 3058:1096c. May 4 12:59:20 freak pppd[4756]: Setting itimer for 0 seconds. May 4 12:59:20 freak pppd[4756]: fsm_sdata(IPCP): Sent code 1, id 1. May 4 12:59:20 freak pppd[4756]: Timeout 3058:11628 in 30 seconds. May 4 12:59:20 freak pppd[4756]: Setting itimer for 30 seconds. May 4 12:59:20 freak pppd[4756]: IPCP: sending Configure-Request, id 1 May 4 12:59:20 freak pppd[4756]: read(fd): EWOULDBLOCK May 4 12:59:21 freak pppd[4756]: IO signal received May 4 12:59:21 freak pppd[4756]: fsm_rconfnakrej(IPCP): Rcvd id 1. May 4 12:59:21 freak pppd[4756]: Untimeout 3058:11628. May 4 12:59:21 freak pppd[4756]: Setting itimer for 0 seconds. May 4 12:59:21 freak pppd[4756]: fsm_sdata(IPCP): Sent code 1, id 2. May 4 12:59:21 freak pppd[4756]: Timeout 3058:11628 in 30 seconds. May 4 12:59:21 freak pppd[4756]: Setting itimer for 30 seconds. May 4 12:59:21 freak pppd[4756]: IPCP: sending Configure-Request, id 2 May 4 12:59:21 freak pppd[4756]: read(fd): EWOULDBLOCK May 4 12:59:21 freak pppd[4756]: IO signal received May 4 12:59:21 freak pppd[4756]: fsm_rconfnakrej(IPCP): Rcvd id 2. May 4 12:59:21 freak pppd[4756]: Untimeout 3058:11628. May 4 12:59:21 freak pppd[4756]: Setting itimer for 0 seconds. May 4 12:59:21 freak pppd[4756]: fsm_sdata(IPCP): Sent code 1, id 3. May 4 12:59:21 freak pppd[4756]: Timeout 3058:11628 in 30 seconds. May 4 12:59:21 freak pppd[4756]: Setting itimer for 30 seconds. May 4 12:59:21 freak pppd[4756]: IPCP: sending Configure-Request, id 3 May 4 12:59:21 freak pppd[4756]: read(fd): EWOULDBLOCK May 4 12:59:21 freak pppd[4756]: IO signal received May 4 12:59:21 freak pppd[4756]: fsm_rconfnakrej(IPCP): Rcvd id 3. May 4 12:59:21 freak pppd[4756]: Untimeout 3058:11628. May 4 12:59:21 freak pppd[4756]: Setting itimer for 0 seconds. May 4 12:59:21 freak pppd[4756]: fsm_sdata(IPCP): Sent code 1, id 4. May 4 12:59:21 freak pppd[4756]: Timeout 3058:11628 in 30 seconds. May 4 12:59:21 freak pppd[4756]: Setting itimer for 30 seconds. May 4 12:59:21 freak pppd[4756]: IPCP: sending Configure-Request, id 4 From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 02:31:35 1994 From: "Stephen J. Roznowski" To: dsnjvro@etmsun.ericsson.se, ahh@netcom.com, markus@techfak.uni-bielefeld.de Subject: Re: X11R5 binaries Cc: amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > On May 4, 7:55am, John Vrolijk wrote: > > Subject: X11R5 binaries > > How did you manage to get it to compile ? > > Can't remember right now. > All i know is, that it is a bug in the preparser, was something > with -standard or -compatible or -old, heck, i forgot. I believe that you are searching for "-traditional" :-) -SR > > Sorry, no big help, i will have a look when i have some more time. > > -- > Markus Illenseer > From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 02:33:26 1994 From: "Robert L. Shady" Subject: Re: Hmmm...No sir, I don't like it! To: thorpej@cs.orst.edu (Jason Thorpe) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1203 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > loading netbsd > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: Undefined symbol _Xstrayirq_num referenced from text segment > locore.o: More undefined symbol _Xstrayirq_num refs follow > pmap.o: Undefined symbol _pg referenced from text segment > pmap.o: Undefined symbol _pg referenced from text segment > pmap.o: Undefined symbol _pg referenced from text segment > pmap.o: Undefined symbol _pg referenced from text segment > pmap.o: Undefined symbol _pg referenced from text segment > pmap.o: Undefined symbol _pg referenced from text segment > *** Error code 1 > > No change to configuration...sources as of 5-2-94 Did you rebuild "config" first? From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 03:17:11 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: X11R5 binaries To: Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) 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: 454 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > > much. If anyone can suggest an alternate site, I'd appreciate it. > put it into /pub/NetBSD-Amiga/incoming on ftp.uni-regensburg.de and > drop me a mail if it's there. Second try, here are the file names: 1811609 May 3 22:53 X11R5.bin-01May94.tar.gz 3618166 May 3 22:52 X11R5.fonts-01May94.tar.gz 260982 May 1 21:59 X11R5.include-01May94.tar.gz 1374382 May 3 22:50 X11R5.lib-01May94.tar.gz 484461 May 1 22:07 X11R5.man-01May94.tar.gz From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 03:29:15 1994 From: Dave Cornejo Subject: PPP forgets IP address To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 645 Sender: owner-current-users@sun-lamp.cs.berkeley.edu A while back and reappearing recently I was having troubles with my PPP interface forgetting it's IP address on ICMP/UDP packets. The latest incarnation will start outputting apparently random IP addresses (God know who I'm pissing off) after a while when I try ping or traceroute. In past lives and up until a day or two ago it would start sending out its IP address as 0.0.0.0. I haven't found a decent way to recover from this short of rebooting. Has anybody else seen this? -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 04:30:02 1994 From: Hubert Feyrer To: ahh@netcom.com, amiga-x@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: X11R5 binaries available for FTP Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Andy's X11R5-distribution from May 1st can be obtained via FTP from ftp.uni-regensburg.de, dir is /pub/NetBSD-Amiga/contrib/bsd/X11: -rw-rw-r-- 1 bsdadmin ftpadmin 1811609 May 4 17:40 X11R5.bin-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 3618166 May 4 18:19 X11R5.fonts-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 260982 May 4 22:35 X11R5.include-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 1374382 May 4 22:39 X11R5.lib-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 484461 May 4 22:37 X11R5.man-01May94.tar.gz Please send all questions etc. regarding the files to Andy Heffernan (ahh@netcom.com)! 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 Thu May 5 07:19:02 1994 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Problems compiling libX* <9405030935.AA05668@ente.techfak.uni-bielefeld.de> From: Bill Squier Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu In message <9405030935.AA05668@ente.techfak.uni-bielefeld.de>, Markus Illenseer writes: > > BTW, X11R6 requires 109MB for the complete sources alone, not to speak >of the object-files, libraries and binaries to be created then. But it looks >like the fonts are still the same and thus no need to create them (eats >way too much in my eyes to create them). R6 added a Type 1 font rendering engine, you'll need to at least include the Type1 fonts. (hardly any) > > Who has space/time and is willing to compile R6 on NetBSD-Amiga? > --whine bitch moan mode on-- IMHO, X11R6 is a pretty big let down (when compared with the amazing amount of hype the X consortium was giving it). (Compiled and installed on our Sparcs at school yesterday). o LBX (Low Bandwidth X) is incomplete o They broke Sun's KP_* (admittedly _wrong_) keysym functionality, and didn't fix Xterm to use the _right_ method... So now your arrow keys won't work... :) o Fresco (the C++ Class Wrappers for X) will not compile under G++. o Display Postscript is... you guessed it... incomplete. I can't remember the rest, but there were a few more major let downs. I'm of the school of thought that doesn't much care if things are late in order to include the promised features. Basically, it's X11R5 with a Type 1 font engine, and the XIE, and it took over 3 hours to compile on our 4-processor 670MP :( --whine bitch moan mode off-- In any case, I'd probably still install it on NetBSD if someone wants to build it :) :) --wps From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 5 07:35:43 1994 From: Hubert Feyrer To: ahh@netcom.com, amiga-x@sun-lamp.cs.berkeley.edu, amiga@sun-lamp.cs.berkeley.edu Subject: X11R5 binaries available for FTP Sender: owner-amiga@sun-lamp.cs.berkeley.edu Andy's X11R5-distribution from May 1st can be obtained via FTP from ftp.uni-regensburg.de, dir is /pub/NetBSD-Amiga/contrib/bsd/X11: -rw-rw-r-- 1 bsdadmin ftpadmin 1811609 May 4 17:40 X11R5.bin-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 3618166 May 4 18:19 X11R5.fonts-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 260982 May 4 22:35 X11R5.include-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 1374382 May 4 22:39 X11R5.lib-01May94.tar.gz -rw-rw-r-- 1 bsdadmin ftpadmin 484461 May 4 22:37 X11R5.man-01May94.tar.gz Please send all questions etc. regarding the files to Andy Heffernan (ahh@netcom.com)! 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 Thu May 5 11:10:29 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@erewhon.CS.Berkeley.EDU X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: the source tree... X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu the source tree, including the kvm utilities, should compile "mostly fine" (i.e. i compiled it OK) on the i386 after the next supscan. it'll work on other architectures when they're updated appropriately. I dunno how long this is going to last; proabably until saturday's tar file creation... 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 12:43:47 1994 Subject: Re: Dumb SLIP question. To: gregc@edi.com (Greg Cronau) From: "Martin Husemann" Cc: mark@aggregate.com, gregc@edi.com, explorer@vorpal.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: 331 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What is the "COM_BIDIR" patch and what is it supposed to do/correct? It isn't necessary any more, since "ttyflags -a" now sets up all ttys mentioned in /etc/ttys to the mode you want them in, my modem line looks like this: > # modem under control of mgetty: > tty01 "/usr/libexec/mgetty tty01" vt100 on local rtscts Martin From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 14:21:36 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: X11R5 binaries" (May 4, 6:48pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , dsnjvro@etmsun.ericsson.se, ahh@netcom.com, markus@techfak.uni-bielefeld.de Subject: Re: X11R5 binaries Cc: amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 4, 6:48pm, "Stephen J. Roznowski" wrote: > > Can't remember right now. > > All i know is, that it is a bug in the preparser, was something > > with -standard or -compatible or -old, heck, i forgot. > > I believe that you are searching for "-traditional" :-) Ah, yeah, great :-) Thanks. The problem was that this flag has to be distributed within all the Makefiles in the entire distribution. I couln'd fix that editing the Imakefile. cpp -traditional in all Makefiles :-/ -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 14:51:20 1994 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: X11R5 binaries <9405051009.AA10610@aidec512.TechFak.Uni-Bielefeld.DE> From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Wouldn't it be possible to change mit/config/imakemdep.h ? Can't you do something like this: --- piece of mit/config/imakemdep.h ---------- /* * Step 5: cpp_argv * The following table contains the cpp flags that should be passed to * cpp whenever a Makefile is being generated. If your preprocessor * doesn't predefine any unique symbols, choose one and add it to the * end of this table. Then, do the following: * * a. Use this symbol at the top of Imake.tmpl when setting MacroFile. * b. Put this symbol in the definition of BootstrapCFlags in your * .cf file. * c. When doing a make World, always add "BOOTSTRAPCFLAGS=-Dsymbol" * to the end of the command line. * * Note that you may define more than one symbols (useful for platforms * that support multiple operating systems). */ #define ARGUMENTS 50 /* number of arguments in various arrays */ char *cpp_argv[ARGUMENTS] = { #ifdef USE_CC_E "cc", /* replaced by the actual cpp program to exec */ "-E", #else "cpp", /* replaced by the actual cpp program to exec */ #endif /* USE_CC_E */ "-I.", /* add current directory to include path */ #ifdef unix "-Uunix", /* remove unix symbol so that filename unix.c okay */ #endif blablabla #ifdef netbsd "-traditional", /* netbsd */ #endif blablablablabla ---------- end piece of mit/config/imakemdep.h -------- John Vrolijk From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 16:01:53 1994 From: "Robert L. Shady" Subject: Source code changes... Kernel stability To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 325 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Okay, so with the 39874937493 kernel changes in the last couple days, is this a bad time to try to grab a stable kernel? Any chance that Chris, you could let us know when you update your kernel so we know it's somewhat safe to update? Pretty stupid for us to update in the 'middle' of a bunch of related changes. -- Rob From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 16:47:50 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 Null message body; hope that's ok Subject: sun-lamp CVS update output Updating src and othersrc trees: U doc/CHANGES U src/bin/csh/func.c U src/bin/ps/keyword.c U src/bin/ps/nlist.c U src/bin/ps/print.c U src/bin/ps/ps.c U src/bin/sh/mystring.c U src/bin/sh/mystring.h U src/bin/sh/output.c U src/bin/sh/output.h U src/bin/sh/sh.1 U src/etc/rc.local U src/etc/etc.mac68k/MAKEDEV U src/games/Makefile U src/games/pig/Makefile U src/games/pig/pig.6 U src/games/pig/pig.c U src/lib/libkvm/kvm.c U src/lib/libkvm/shlib_version U src/lib/libutil/Makefile U src/lib/libutil/login.c U src/lib/libutil/login_tty.c U src/lib/libutil/logout.c U src/lib/libutil/logwtmp.c U src/lib/libutil/pty.c U src/lib/libutil/shlib_version U src/libexec/mail.local/mail.local.c U src/sbin/modload/modload.c U src/sbin/modunload/modunload.c U src/sys/arch/hp300/dev/dma.c U src/sys/arch/hp300/dev/fhpib.c U src/sys/arch/hp300/dev/ite.c U src/sys/arch/hp300/dev/nhpib.c U src/sys/arch/hp300/dev/ppi.c U src/sys/arch/hp300/dev/rd.c U src/sys/arch/hp300/hp300/clock.c U src/sys/arch/hp300/hp300/genassym.c U src/sys/arch/hp300/hp300/locore.s U src/sys/arch/hp300/hp300/machdep.c U src/sys/arch/hp300/hp300/sys_machdep.c U src/sys/arch/hp300/hp300/trap.c U src/sys/arch/hp300/hp300/vm_machdep.c U src/sys/arch/hp300/hpux/hpux_compat.c U src/sys/arch/hp300/hpux/hpux_sig.c U src/sys/arch/hp300/include/cpu.h U src/sys/arch/hp300/include/proc.h U src/sys/arch/i386/conf/ALL U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/i386/conf.c U src/sys/arch/i386/i386/genassym.c U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/i386/math_emulate.c U src/sys/arch/i386/i386/mem.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/cpu.h U src/sys/arch/i386/include/proc.h U src/sys/arch/i386/include/psl.h U src/sys/arch/i386/isa/aha1542.c U src/sys/arch/i386/isa/aha1742.c U src/sys/arch/i386/isa/aic6360.c U src/sys/arch/i386/isa/bt742a.c U src/sys/arch/i386/isa/clock.c U src/sys/arch/i386/isa/fd.c U src/sys/arch/i386/isa/icu.s U src/sys/arch/i386/isa/if_ed.c U src/sys/arch/i386/isa/isa.c U src/sys/arch/i386/isa/lms.c U src/sys/arch/i386/isa/lpt.c U src/sys/arch/i386/isa/mcd.c U src/sys/arch/i386/isa/mms.c U src/sys/arch/i386/isa/npx.c U src/sys/arch/i386/isa/pccons.c U src/sys/arch/i386/isa/ultra14f.c U src/sys/arch/i386/isa/wd.c U src/sys/arch/i386/isa/wt.c U src/sys/arch/i386/isa/pcvt/pcvt_drv.c U src/sys/arch/i386/isa/pcvt/pcvt_sup.c U src/sys/arch/m68k/m68k/process_machdep.c U src/sys/arch/pmax/ultrix/ultrix_compat.c U src/sys/arch/pmax/ultrix/ultrix_sysent.c U src/sys/arch/sparc/conf/Makefile.sparc U src/sys/arch/sparc/conf/SS5 U src/sys/arch/sparc/conf/TDR U src/sys/arch/sparc/dev/cons.c U src/sys/arch/sparc/dev/kbd.c U src/sys/arch/sparc/dev/kbio.h U src/sys/arch/sparc/dev/zs.c U src/sys/arch/sparc/include/cpu.h U src/sys/arch/sparc/include/ctlreg.h U src/sys/arch/sparc/rcons/rcons_kern.c U src/sys/arch/sparc/sparc/clock.c U src/sys/arch/sparc/sparc/locore2.c U src/sys/arch/sparc/sparc/machdep.c U src/sys/arch/sparc/sparc/pmap.c U src/sys/arch/sparc/sparc/trap.c U src/sys/arch/sun3/conf/GENERIC U src/sys/arch/sun3/dev/kd.c U src/sys/arch/sun3/dev/obio.c U src/sys/arch/sun3/dev/prom.c U src/sys/arch/sun3/dev/zs.c U src/sys/arch/sun3/include/cpu.h U src/sys/arch/sun3/sun3/conf.c U src/sys/arch/sun3/sun3/genassym.c U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/trap.c U src/sys/compat/sunos/sun_misc.c U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/conf/newvers.sh U src/sys/kern/init_main.c U src/sys/kern/kern_acct.c U src/sys/kern/kern_clock.c U src/sys/kern/kern_exit.c U src/sys/kern/kern_fork.c U src/sys/kern/kern_kinfo.c U src/sys/kern/kern_ktrace.c U src/sys/kern/kern_resource.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_synch.c U src/sys/kern/kern_time.c U src/sys/kern/subr_prf.c U src/sys/kern/subr_prof.c U src/sys/kern/sys_generic.c U src/sys/kern/sys_process.c U src/sys/kern/tty.c U src/sys/kern/tty_conf.c U src/sys/kern/tty_pty.c U src/sys/kern/tty_subr.c U src/sys/kern/uipc_domain.c U src/sys/kern/uipc_socket.c U src/sys/kern/uipc_socket2.c U src/sys/kern/uipc_syscalls.c U src/sys/lib/libkern/libkern.h U src/sys/miscfs/procfs/procfs_note.c U src/sys/miscfs/procfs/procfs_status.c U src/sys/miscfs/procfs/procfs_vnops.c U src/sys/net/if.c U src/sys/netiso/esis.h U src/sys/netiso/tp_tpdu.h U src/sys/nfs/nfs_boot.c U src/sys/nfs/nfs_socket.c U src/sys/sys/conf.h U src/sys/sys/gmon.h U src/sys/sys/kernel.h U src/sys/sys/lkm.h U src/sys/sys/proc.h U src/sys/sys/resourcevar.h U src/sys/sys/signalvar.h U src/sys/sys/socket.h U src/sys/sys/socketvar.h U src/sys/sys/systm.h U src/sys/sys/tty.h U src/sys/sys/user.h U src/sys/ufs/inode.h U src/sys/ufs/ufs_inode.c U src/sys/ufs/ufs_vfsops.c U src/sys/ufs/ufs_vnops.c U src/sys/vm/vm_glue.c U src/sys/vm/vm_meter.c U src/usr.bin/fstat/fstat.c U src/usr.bin/modstat/modstat.c U src/usr.bin/w/proc_compare.c U src/usr.bin/w/w.c U src/usr.sbin/kgmon/Makefile Running the SUP scanner: SUP Scan for current starting at Thu May 5 04:22:22 1994 SUP Scan for current completed at Thu May 5 04:25:13 1994 SUP Scan for mirror starting at Thu May 5 04:25:14 1994 SUP Scan for mirror completed at Thu May 5 04:27:57 1994 From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 18:48:29 1994 From: rhealey@aggregate.com Subject: Re: X11R5 binaries To: dsnjvro@etmsun.ericsson.se (John Vrolijk) Cc: amiga-x@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: 722 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > Wouldn't it be possible to change mit/config/imakemdep.h ? > Can't you do something like this: > [ Change deleted ] The question that needs to be asked is why are we breaking X code to comfort a braindead cpp-ism? Additionally, /lib/cpp is NOT a proper location for NetBSD cpp, /usr/libexec/cpp is. /lib/cpp is left over from the bad old days before we sync'd with sun-lamp sources. All references to /lib/cpp should be removed and replaced with /usr/bin/cpp or /usr/libexec/cpp depending on whether you want a shell script wrapper or the real McCoy. Once we braindamage X it will be there for all time and shouldn't be done lightly, especially when it will clash with all the other NetBSD ports. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 21:33:13 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: SLIP lossage Sender: owner-current-users@sun-lamp.cs.berkeley.edu A couple of pepole noted that SLIP would blow chunks periodically with newer kernels. This is because I forgot to add back some code to make splimp() > spltty() in the presence of SLIP and PPP, and without this some structures are not locked correctly. Anyway, I just fixed this. Version 1.21 of intr.c should make said users happy. (Note that you don't need the reset of this week's changes to use it, for people who are afraid...) From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 5 21:54:14 1994 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: "Stephen J. Roznowski" , dsnjvro@etmsun.ericsson.se, ahh@netcom.com, amiga-x@sun-lamp.cs.berkeley.edu, mehlhaff@plague.berkeley.edu Subject: Re: X11R5 binaries of Thu, 05 May 1994 12:09:39 -0400 <9405051009.AA10610@aidec512.TechFak.Uni-Bielefeld.DE> From: "'Evil' ERic Mehlhaff" Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) recently wrote: >On May 4, 6:48pm, "Stephen J. Roznowski" wrote: >> >> I believe that you are searching for "-traditional" :-) > > Ah, yeah, great :-) Thanks. > The problem was that this flag has to be distributed within all the >Makefiles in the entire distribution. I couln'd fix that editing the >Imakefile. cpp -traditional in all Makefiles :-/ My horrendous hack around this problem was to make a /lib/cpp what was a stupid shellscript wrapper. Sure its a hack, but it required less work than beating up X's config files... cryptic(23)# cat /lib/cpp #!/bin/sh exec /usr/libexec/cpp -traditional $* It works for me, except that now my imake binaries are spewing corrupt Makefiles. It's pretty clearly a bug in fputs(), as it (mostly) went away when I forced imake to fflush() after EVERY fputs() it made. For what its worth, I just finished installing the latest binaries from the lamp mirror on iastate ('cept for the kernel, which panics when it mounts root :-( My curent kernel is about 2 weeks old compiled from current sources. ). ERic mehlhaff, mehlhaff@ocf.Berkeley.EDU From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 21:55:54 1994 From: mark@aggregate.com (Mark P. Gooderum) To: martin@euterpe.owl.de Subject: Re: Dumb SLIP question. Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 881 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > What is the "COM_BIDIR" patch and what is it supposed to do/correct? > > It isn't necessary any more, since "ttyflags -a" now sets up all > ttys mentioned in /etc/ttys to the mode you want them in, my modem line > looks like this: > > > # modem under control of mgetty: > > tty01 "/usr/libexec/mgetty tty01" vt100 on local rtscts I disagree. The ttyflags solves one of the two problems that the COM_BIDIR patch solves. What it doesn't solve is easy support of bidirectional use of the modem with either the "standard OS utilities (getty)" or any other packages (like flexfax). Without the automatic lockout that the cua like devices offers, you have to do ugly stuff like: switch /etc/ttys HUP init dial out finish switch /etc/ttys HUP init Yeah this works, but there is plenty of room for failure. With a cua device you get easy and automatic cleanup. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 22:09:56 1994 From: Steven Reiz To: current-users@sun-lamp.cs.berkeley.edu Subject: diskless booting Sender: owner-current-users@sun-lamp.cs.berkeley.edu I know it's a FAQ but I can't seem to find a working answer so... I've tried booting NetBSD-cur-i386 diskless, using a NetBSD-cur-i386 machine as server as well. It failed in the middle of the tftp-kernel stage. Is this supposed to work and if so, how? (Which loader used on DOS, which config file for the diskless kernel?) There is supposed to be a diskless(8) manpage but I haven't found it. I've tried two loaders on DOS, both combined with bootpd from /usr/src/libexec/bootpd, the first is netboot.bin from /usr/src/sys/arch/i386/netboot, which only passes the rarp stage if I do a tcpdump rarp as well (!), then successfully starts loading the kernel with tftp, after loading the text the loader hangs. This may be because the config of that kernel is incorrect (I used a normal kernel, not knowing what the diskless config should be), but I expected the loader to load the data segment as well, and the kernel doesn't seem to be called at all. The second loader I tried is the one from FreeBSD, which passes the rarp stage without any problems, but after Loading /tftpboot/cfg.193.78.1.41... it gives Executable too large. Unable to load config file. Thanks for any help, and if there is interest I'll summarize. Bye! -Steven From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 22:24:07 1994 From: "Eric S. Hvozda" Subject: XFree86 2.1 binaries or source patches? 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: 205 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ianyone out there have XFree86 2.1 up and running on a 30Apr94 tar ball source build? If so, did you get bianries or self build? If you did a build, did you need patches? If so, can I have a copy ? :-) From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 23:43:01 1994 From: "Chris G. Demetriou" To: current-users@sun-lamp.cs.berkeley.edu, rls@zeus.id.net Subject: Re: Source code changes... Kernel stability Sender: owner-current-users@sun-lamp.cs.berkeley.edu actually, you should be pretty safe running a kernel based on last night's sources, at least on the i386. I've got a machine running them that's been up for a while now... chris From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 5 23:53:23 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host xanth.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Shell foo From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ummm...guys...When you remove local definitions of something, make sure the code knows it... cc -O -DSHELL -I. -I/tmp_mnt/storm164/usr/local/scratch/thorpej/NetBSD-current/src/bin/sh -c /tmp_mnt/storm164/usr/local/scratch/thorpej/NetBSD-current/src/bin/sh/output.c cc -static -o sh init.o builtins.o cd.o dirent.o echo.o error.o eval.o exec.o expand.o input.o jobs.o mail.o main.o memalloc.o miscbltin.o mystring.o nodes.o options.o parser.o redir.o show.o syntax.o trap.o output.o var.o exec.o: Undefined symbol _mystrchr referenced from text segment exec.o: Undefined symbol _mybcopy referenced from text segment exec.o: Undefined symbol _mystrchr referenced from text segment expand.o: Undefined symbol _mystrchr referenced from text segment expand.o: Undefined symbol _mystrchr referenced from text segment expand.o: Undefined symbol _mystrchr referenced from text segment jobs.o: Undefined symbol _mybcopy referenced from text segment main.o: Undefined symbol _mystrchr referenced from text segment memalloc.o: Undefined symbol _mybcopy referenced from text segment miscbltin.o: Undefined symbol _mystrchr referenced from text segment miscbltin.o: Undefined symbol _mystrchr referenced from text segment options.o: Undefined symbol _mystrchr referenced from text segment parser.o: More undefined symbol _mystrchr refs follow parser.o: Undefined symbol _mybcopy referenced from text segment parser.o: Undefined symbol _mybcopy referenced from text segment parser.o: Undefined symbol _mybcopy referenced from text segment var.o: Undefined symbol _mybcopy referenced from text segment var.o: Undefined symbol _mybcopy referenced from text segment *** Error code 1 Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 01:20:29 1994 From: conklin@ngai.kaleida.com (J.T. Conklin) To: Jason Thorpe Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Shell foo Sender: owner-current-users@sun-lamp.cs.berkeley.edu Jason> Ummm...guys...When you remove local definitions of something, make sure Jason> the code knows it... All of the files (exec.c, expand.c, ...) include mystring.h, so the contents of the .depend file should have instructed make to rebuild them. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 01:54:51 1994 From: "Robert L. Shady" Subject: Re: Source code changes... Kernel stability To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 299 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > actually, you should be pretty safe running a kernel based on last > night's sources, at least on the i386. I've got a machine running > them that's been up for a while now... Great, so if I sup today 05-05-94 06:02pm EDT, I should be safe? Or did you mean, if I have a SUP from yesterday... From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:00:43 1994 From: "Robert L. Shady" Subject: Re: diskless booting To: sreiz@aie.nl (Steven Reiz) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 270 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Thanks for any help, and if there is interest I'll summarize. I am *VERY* interested in this processes, a complete description from beginning to end would be wonderful right about now since I have machines, but I have NO hard drives.. Well, to spare that is.. ;) From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:01:49 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Robert L. Shady" Cc: cgd@postgres.berkeley.edu (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code changes... Kernel stability <199405052201.SAA21215@zeus.id.net> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Great, so if I sup today 05-05-94 06:02pm EDT, I should be safe? "should be," yes. (i.e. it seems to work for me, but i make no guarantees... 8-) > Or did you mean, if I have a SUP from yesterday... I don't encourage time travel. 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:10:39 1994 From: "Robert L. Shady" Subject: Re: Source code changes... Kernel stability To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: cgd@postgres.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1631 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> Great, so if I sup today 05-05-94 06:02pm EDT, I should be safe? > "should be," yes. (i.e. it seems to work for me, but i make no > guarantees... 8-) Okay, that's good.. I need 'something' more stable than what I have now, I have NO idea what has happened, it just seems that "All of the sudden" I am getting these reboots daily, and I can't figure out why.. Speaking of which, I never got an answer to my question about tracing a kernel panic. Do you have a "quick-n-dirty" way of finding out what module/routine caused it and possibly dump the variables, or something? >> Or did you mean, if I have a SUP from yesterday... > I don't encourage time travel. 8-) Cute.. I was just hoping you weren't going to say one from yesterday, cause I just removed it.. ;) I think I will re-sup the current-src portion just to make sure I have "the right stuff" because I haven't been able to sup everyday for a while now... What SUP lists are available? I currently have... current release=allsrc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/usr/current prefix=/usr/current backup use-rel-suffix delete compress current release=security host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/usr/current prefix=/usr/current backup use-rel-suffix delete compress current release=doc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/usr/current prefix=/usr/current backup use-rel-suffix delete compress current release=othersrc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp base=/usr/current prefix=/usr/current backup use-rel-suffix delete compress Obviously without the spaces in the lines.. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:13:39 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Charles Hannum Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SLIP lossage <199405051609.JAA17974@sun-lamp.cs.berkeley.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > (Note that you don't need the reset of this week's > changes to use it, for people who are afraid...) "You shouldn't fear what you cannot escape..." 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:15:36 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: mark@aggregate.com (Mark P. Gooderum) Cc: martin@euterpe.owl.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Dumb SLIP question. <9405051600.AA10141@aggregate.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Yeah this works, but there is plenty of room for failure. With a cua device > you get easy and automatic cleanup. IFF they are implemented correctly. The only place i've seen them implemented correctly is in SunOS. I may get around to doing it correctly, but it won't be this week, and it certainly wasn't the last time i did it! cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:22:22 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Robert L. Shady" Cc: cgd@postgres.berkeley.edu (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code changes... Kernel stability <199405052212.SAA21347@zeus.id.net> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Speaking of which, I never got an answer to my question about tracing a > kernel panic. Do you have a "quick-n-dirty" way of finding out what > module/routine caused it and possibly dump the variables, or something? in DDB, "trace" (funny name for it, eh? 8-) will do what you want. as for dumping the variables, well, DDB isn't quite that sophisticated (it will show you arguments, though, if you know what you're looking for). i'd get out the source to the routine, the assembler version of the routine, etc., and spend time digging... > Cute.. I was just hoping you weren't going to say one from yesterday, cause > I just removed it.. ;) I think I will re-sup the current-src portion just > to make sure I have "the right stuff" because I haven't been able to sup > everyday for a while now... What SUP lists are available? I currently > have... those should get you what you need; most of the rest of the 'current' releases are subsets of allsrc. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 02:40:12 1994 From: "John C. Hayward" Subject: Do we have an all clear for SMC Ethernet Cards 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 Dear NetBSDers, I have a SMC Ethernet card and want to upgrade to Current. A short while back several people reported that their SMC cards were Zapped with the current. Can people who have SMC cards and are keeping current let me know if it is safe to grab binaries and keep up with current without frying my eithernet card? I don't want to be critical of the good work being done by the team, at the same time I don't want to buy new eithernet cards. Thanks in advance, johnh... From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 03:02:55 1994 To: "Eric S. Hvozda" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 2.1 binaries or source patches? <199405051701.NAA29885@clark.net> From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu I built XFree86-2.1 from scratch last week (kernel as of 28th Apr). Any reason why it should not work with a later tarball? If you *exactly* follow the usual instructions for installing xFree, apply the patch from Matthieu(?) and copy a couple of missing files to include/sys or include/machine (files are in the xfree package), you should have no problem. I did have to open /dev/mem as root before starting the server. My link is only 14.4Kbps and rather flaky so I am not going to put up the binaries, atleast until my slip link is up and running, but I'll be happy to answer any questions. Bakul Shah From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 03:16:59 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, johnh@david.wheaton.edu Subject: Re: Do we have an all clear for SMC Ethernet Cards Sender: owner-current-users@sun-lamp.cs.berkeley.edu I explained at the time what was happening; specifically, the el and wt probe routines reprogrammed the cards. People with custom kernels or SMC cards at addresses other than 0x300 never saw the problem in the first place. I've `fixed' this for now by simply removing the el0 and wt0 devices from the GENERIC configs. Clearly this needs to be addressed better, but it certainly cures the symptom for now. I've also worked with a few people to bring their cards back to life. It almost seems like your message was intended to scare people. I hope this is not the case. From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 6 03:58:26 1994 From: msanders@eng.utah.edu Subject: Ethernet / NetBSD To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 488 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi all... I've got some questions about Ethernet and NetBSD-Amiga. First, how would I go about setting NetBSD up to work on an Ethernet network? The FAQ mentions that it 'works perfectly' but nothing about how it's done. Second, what are my options as far as Ethernet cards for an A3000? Recommendations, anyone? Any info/suggestions/whatever would be most appreciated. -- Michael K. Sanders Commodore Int'l may be dead, but my machine still thrives. :) From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 05:30:25 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: rls@zeus.id.net Cc: sreiz@aie.nl, current-users@sun-lamp.cs.berkeley.edu Subject: How to boot diskless... Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From: "Robert L. Shady" > Date: Thu, 5 May 1994 18:14:20 +1523847 (EDT) > > I am *VERY* interested in this processes, a complete description from > beginning to end would be wonderful right about now since I have machines, > but I have NO hard drives.. Well, to spare that is.. ;) Diskless boot works as long as you have a boot program that can get your kernel loaded into memory somehow. I am using the SunOS boot program because netboot has not yet been ported to the Sun3. I'll try to describe both boot programs, but be warned that my description of netboot will probably be inaccurate. First, the basic steps in diskless boot are as follows: 1 PROM Loads a bootstrap program 2 Bootstrap determines client IP address and server 3 Bootstrap loads a kernel from the server 4 Kernel determines client IP address, server(s), and path names for root and swap 5 Kernel does NFS mounts for root and swap Steps 1-3 are, of course, quite machine specific. On a Sun machine, the bootstrap gets loaded as follows: 1a PROM does RARP to determine client and server IP addresses 1b PROM does TFTP to download bootstrap from server 2 Bootstrap (Sun's that is) does RPC to bootparamd to determine the path name for root (to get the kernel) 3 Bootstrap does NFS reads to load kernel (from root path) On a PC, you could load the netboot program from a floppy, or if you have an appropriate Ethernet PROM, that could load it. Once netboot (the NetBSD bootstrap) is loaded, it does this: 2 Uses BOOTP (or RARP?) to get client and server IP addresses 3 Uses TFTP (or NFS?) to download a kernel When the kernel is loaded, it receives little or no information from the boot program, so it needs to AGAIN determine the IP addresses for client and server, request path names, etc. The kernel uses RARP and BOOTP for this, regardless of what the boot program uses. (For example, my use of the SunOS bootstrap means I need both rpc.bootparamd and bootpd running on my server to answer questions from the bootstrap and kernel.) In short, your server needs to be running rarpd, bootpd, and possibly rpc.bootparamd as well, all informed of your client. The current NFS mount_root implementation uses BOOTP to get the path names for root and swap. In fact, it kind of misuses the "boot file name" part of the BOOTP response packet to get it. The client sends a BOOTP request with "root" as the boot file name, and expects the reply to have something like: "/export/myclient/root" as the boot file name. The client then sends another request with "swap" as the boot file and expects something like: "/export/myclient/swap" as the boot file name. Not all bootp servers like this. The bootp server I am maintaining (from CMU originally, and now up to version 2.3.7) did not until recently allow for the boot-file-name to change from one request to another. (Time to check in the latest version, I guess...) Here is a sample bootptab entry for a diskless NetBSD client: # Note that you need to zap the "tftp dir" (td) and set the # home directory (hd), and hd must be common prefix string # to which "root" or "swap" may be appended to for the reply. walnut:tc=.subnet16:ha=walnut:sa=merlin-gw:\ :td@:hd=/export/walnut/: You can test the above entry using "bootptest" (part of the bootp package). For example: % bootptest -f root walnut bootptest: version 2.3.7 Sending to 192.233.16.24 (request) htype:0 hlen:0 xid:11998 \ C:192.233.16.24 file:"root" vend-rfc1395 Recvd from 192.233.16.24 (reply) htype:0 hlen:0 xid:11998 \ C:192.233.16.24 S:192.233.17.32 sname:"walnut" \ file:"/export/walnut/root" vend-rfc1395 \ SM:255.255.255.0 GW:192.233.16.15 TZ:18000 \ DNS:192.233.16.15,192.233.16.4 \ DNAM:"mc.com" HN:"walnut" % I hope this helps more than it confuses... Gordon Ross From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 05:31:58 1994 From: deraadt@fsa.ca (Theo Deraadt) To: gwr@mc.com, rls@zeus.id.net Subject: Re: How to boot diskless... Cc: current-users@sun-lamp.cs.berkeley.edu, sreiz@aie.nl Sender: owner-current-users@sun-lamp.cs.berkeley.edu >On a PC, you could load the netboot program from a floppy, or >if you have an appropriate Ethernet PROM, that could load it. >Once netboot (the NetBSD bootstrap) is loaded, it does this: >2 Uses BOOTP (or RARP?) to get client and server IP addresses >3 Uses TFTP (or NFS?) to download a kernel a good basic description, gordon. a note is needed on the above, though. it is a very bad idea to load a kernel via TFTP. there are fundamental problems with using tftp in this fashion. normally the tftp server will run in secure mode, and it is not possible to get the exact same kernel as in the client's root directory (which you want for kvm stuff) this requires either 1) having /tftpboot on the same partition as the client's root (so you can hard link the kernel) or 2) having two seperate copies of the kernel. it is much better to just load the kernel via nfs, though this does make the boot process a little bit more complicated. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 09:44:34 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu, freebsd-hackers@freefall.cdrom.com Cc: Scott Mace Subject: Kermit and RTS/CTS flow control Organization: Analog Devices Inc, Norwood MA, USA X-Attribution: MWL Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just discovered the reason why I couldn't upload files from NetBSD with C-Kermit 5A(190). It turns out that Kermit was lying to me when it claimed it was using RTS/CTS flow control, and I was overrunning the link. In order to confirm the lie: start up Kermit SET LINE to your modem device (e.g. /dev/tty00) SET FLOW RTS/CTS CONNECT ^\Z check the status of your modem device (e.g. stty -af /dev/tty00) see the -crtscts in the listing, and say AAAAAAAAAAARRGHHHHHH!!! (Scott, does this problem exist under FreeBSD as well? Let me know.) In order to get RTS/CTS flow control to work, you must compile Kermit with (NetBSD example): make bsd44c KFLAGS=-DPOSIX_CRTSCTS Versions of C-Kermit 5A(190) dated after April 10 (ALPHA.02) have all of the patches I sent out earlier on these lists incorporated (UUCP lockfiles, &c.). I plan to try to get a patch for this problem incorporated as well. The only other changes I find necessary to get Kermit to compile on my NetBSD system these days are to change the setuid() and setgid() calls in ckutio.c to seteuid() and setegid(), respectively. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer Analog Devices, SPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 11:26:59 1994 From: matthieu@laas.fr (Matthieu Herrb) To: "Eric S. Hvozda" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 2.1 binaries or source patches? X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 1802 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Thu 5) > Ianyone out there have XFree86 2.1 up and running on a 30Apr94 tar ball > source build? If so, did you get bianries or self build? If you did a build, > did you need patches? If so, can I have a copy ? :-) You can run X without rebuilding it with the following incantations: su sleep 60 < /dev/mem ^D xinit I made a patch for that it will be in XFree86 2.1.1 that is coming out within a few days. Here is the patch if you want to rebuild: *** mit/server/ddx/x386/os-support/bsd/bsd_video.c~ Sat Jan 15 13:57:26 1994 --- mit/server/ddx/x386/os-support/bsd/bsd_video.c Sat Apr 30 09:05:43 1994 *************** *** 53,58 **** --- 53,61 ---- static Bool devMemChecked = FALSE; static Bool useDevMem = FALSE; + #ifdef __NetBSD__ + static int devMemFd = -1; + #endif /* * Check if /dev/mem can be mmap'd. If it can't print a warning when *************** *** 79,85 **** --- 82,92 ---- /* Try to map a page at the VGA address */ base = (pointer)mmap((caddr_t)0, 4096, PROT_READ|PROT_WRITE, MAP_FILE, fd, (off_t)0xA0000); + #ifdef __NetBSD__ + devMemFd = fd; + #else close(fd); + #endif if (base == (pointer)-1) { if (warn) *************** *** 112,125 **** --- 119,138 ---- { int memFd; + #ifdef __NetBSD__ + if ((memFd = devMemFd) < 0) + #else if ((memFd = open("/dev/mem", O_RDWR)) < 0) + #endif { FatalError("xf86MapVidMem: failed to open /dev/mem (%s)\n", strerror(errno)); } base = (pointer)mmap((caddr_t)0, Size, PROT_READ|PROT_WRITE, MAP_FILE, memFd, (off_t)Base); + #ifndef __NetBSD close(memFd); + #endif if (base == (pointer)-1) { FatalError("%s: could not mmap /dev/mem [s=%x,a=%x] (%s)\n", Matthieu From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 6 12:00:39 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Ethernet / NetBSD" (May 5, 7:18pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu (Amiga) Subject: Re: Ethernet / NetBSD Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 5, 7:18pm, msanders@eng.utah.edu wrote: > First, how would I go about setting NetBSD up to work on an Ethernet > network? The FAQ mentions that it 'works perfectly' but nothing about > how it's done. There is a small network-FAQ for NetbSD-Amiga avail on ftp.uni-regensburg.de, thanks to Hubert :-) Basically: You need a kernel with Ethernet-Support (all Generic kernels do), and then perform a 'ifconfig le0 you-ip-address'. > Second, what are my options as far as Ethernet cards for an A3000? > Recommendations, anyone? A2065 or Ameristar. Rumours are that the ASDG Lanrover works, too, but has never been verified to me. Support for upcoming Ariadne-board (with 10-Base-T) is in the works. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 6 12:25:40 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: FAQ for setting up modem connections ? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi I was wondering if there is document somewhere which will help me setup a slip or ppp link from within NetBSD. I would like to try out setting up a connection from my Amiga to my Sparc at work via a 14k4 modem connection. John From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 6 14:18:50 1994 From: Hubert Feyrer Subject: Re: Ethernet / NetBSD To: msanders@eng.utah.edu Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1737 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > First, how would I go about setting NetBSD up to work on an Ethernet > network? The FAQ mentions that it 'works perfectly' but nothing about > how it's done. Watch /etc/netstart and create an apprpriate /etc/hostname.le0. Mine looks like this: inet 132.199.15.99 255.255.255.0 132.199.15.255 (Where 132.199.15.99 is my ip-address, 255.255.255.0 is the netmask and 132.199.15.255 is the broadcast-address). > Second, what are my options as far as Ethernet cards for an A3000? Commodore A2065 and Ameristar-Board (the old one, not A[24]066!) are supported by NetBSD, a driver for the Village-Tronic Ariadne-card is being worked on. > Recommendations, anyone? > > Any info/suggestions/whatever would be most appreciated. Try reading the priliminary Networking-FAQ via WWW: http://dusk.rz.uni-regensburg.de/Personal/hubert/NetBSD/NWF/nwf.html or http://dusk.rz.uni-regensburg.de/Personal/hubert/NetBSD/NWF/nwf.ps. The FAQ will be released in the next few days... BTW, can anyone tell me how to include a PostScript-drawing into a texinfo-file? I tried using a (LaTeX)-eps-style between @iftex ... @end iftex but it didn't work, whereelse it worked fine in plain TeX! Any help on this REALLY appreciated!!! > Commodore Int'l may be dead, but my machine still thrives. :) YEAH! Mine too!!! 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 May 6 14:53: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/games/Makefile U src/games/tetris/Makefile U src/games/tetris/input.c U src/games/tetris/input.h U src/games/tetris/pathnames.h U src/games/tetris/scores.c U src/games/tetris/scores.h U src/games/tetris/screen.c U src/games/tetris/screen.h U src/games/tetris/shapes.c U src/games/tetris/tetris.6 U src/games/tetris/tetris.c U src/games/tetris/tetris.h U src/lib/Makefile U src/lib/libc/shlib_version U src/lib/libc/gen/Makefile.inc U src/lib/libc/gen/getgrouplist.3 U src/lib/libc/gen/getgrouplist.c U src/lib/libc/sys/ftruncate.c U src/lib/libc/sys/lseek.c U src/lib/libc/sys/mmap.c U src/lib/libc/sys/truncate.c U src/lib/libcompat/Makefile U src/lib/libcompat/4.1/ftime.3 U src/lib/libcompat/4.1/ftime.c U src/lib/libcompat/4.1/getpw.3 U src/lib/libcompat/4.1/stty.3 U src/lib/libcompat/4.1/vlimit.3 U src/lib/libcompat/4.1/vtimes.3 U src/lib/libcompat/4.3/cfree.c U src/lib/libcompat/4.3/lsearch.3 U src/lib/libcompat/4.3/lsearch.c U src/lib/libcompat/4.3/re_comp.3 U src/lib/libcompat/4.3/rexec.3 U src/lib/libcompat/4.3/rexec.c U src/lib/libcompat/4.3/m68k/DEFS.h U src/lib/libcompat/4.3/m68k/insque.s U src/lib/libcompat/4.3/m68k/remque.s U src/lib/libcompat/4.4/cuserid.c U src/lib/libcompat/regexp/regexp.3 U src/lib/libedit/Makefile U src/lib/libedit/chared.c U src/lib/libedit/chared.h U src/lib/libedit/common.c U src/lib/libedit/el.c U src/lib/libedit/el.h U src/lib/libedit/emacs.c U src/lib/libedit/hist.c U src/lib/libedit/hist.h U src/lib/libedit/histedit.h U src/lib/libedit/history.c U src/lib/libedit/key.c U src/lib/libedit/key.h U src/lib/libedit/makelist U src/lib/libedit/map.c U src/lib/libedit/map.h U src/lib/libedit/parse.c U src/lib/libedit/parse.h U src/lib/libedit/prompt.c U src/lib/libedit/prompt.h U src/lib/libedit/read.c U src/lib/libedit/refresh.c U src/lib/libedit/refresh.h U src/lib/libedit/search.c U src/lib/libedit/search.h U src/lib/libedit/shlib_version U src/lib/libedit/sig.c U src/lib/libedit/sig.h U src/lib/libedit/sys.h U src/lib/libedit/term.c U src/lib/libedit/term.h U src/lib/libedit/termcap.h U src/lib/libedit/tokenizer.c U src/lib/libedit/tokenizer.h U src/lib/libedit/tty.c U src/lib/libedit/tty.h U src/lib/libedit/vi.c U src/lib/libedit/TEST/test.c U src/sys/arch/i386/conf/TRINITY U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/isa/intr.c U src/sys/arch/i386/isa/pcvt/pcvt_ext.c U src/sys/arch/i386/isa/pcvt/pcvt_hdr.h U src/sys/arch/i386/isa/pcvt/pcvt_sup.c U src/sys/arch/mac68k/dev/asc.c U src/sys/arch/mac68k/dev/console.c U src/sys/arch/sun3/dev/idprom.c U src/sys/arch/sun3/dev/kbd.c U src/sys/arch/sun3/dev/obctl.c U src/sys/arch/sun3/dev/obio.c U src/sys/arch/sun3/dev/obmem.c U src/sys/arch/sun3/dev/zs.c U src/sys/arch/sun3/include/proc.h U src/sys/arch/sun3/sun3/clock.c U src/sys/arch/sun3/sun3/conf.c U src/sys/arch/sun3/sun3/control.c U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/sun3_startup.c U src/sys/arch/sun3/sun3/trap.c U src/sys/arch/sun3/sun3/vector.c U src/sys/arch/sun3/sun3/vm_machdep.c Running the SUP scanner: SUP Scan for current starting at Fri May 6 03:16:18 1994 SUP Scan for current completed at Fri May 6 03:18:32 1994 SUP Scan for mirror starting at Fri May 6 03:18:32 1994 SUP Scan for mirror completed at Fri May 6 03:20:51 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 15:08:41 1994 From: Hannes Deeken Subject: Re: Dumb SLIP question. To: "Mark P. Gooderum" 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 On Thu, 5 May 1994, Mark P. Gooderum wrote: > The ttyflags solves one of the two problems that the COM_BIDIR patch solves. > > What it doesn't solve is easy support of bidirectional use of the modem > with either the "standard OS utilities (getty)" or any other packages > (like flexfax). Huh? With FlexFAX you can't use cua devices since it opens the tty and waits for RING. But FlexFAX goes out of the way if you want to dial out, so it isn't a problem. To enable dialout with the current serial driver the minimum needed is a getty which honors lockfiles from UUCP et al. [...] > Yeah this works, but there is plenty of room for failure. With a cua device > you get easy and automatic cleanup. Agreed, to have them would be nice. Hannes -- Hans-Christoph Deeken | hannes@flinx.{RoBIN.de,hotb.sub.org} (home) Jungfernstrasse 34 | deeken@iti.informatik.th-darmstadt.de (university) 64291 Darmstadt | IRC: Glenlivet | "Tuuut." -- Karate Kid 2 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 16:32:30 1994 From: Dave Cornejo Subject: stability of May 5 kernel To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 467 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I tried out the kernel from May 5 - after 10 hours of compiling X, a new kernel and several X applications it's still running. From the May 2nd kernel I was getting 2-3 hours between reboots under a lesser load. Is the current tree (esp. kvm) in a shape that I dare try out everything else? Thanks -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 17:58:11 1994 From: "D. Jay Newman" Subject: Problem with gcc from yesterday (5/5/95) To: current-users@sun-lamp.cs.berkeley.edu (current) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 928 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I suped and tried to make my system again. I'm running a kernel from 4/29/95. Everything worked fine until I made and installed /usr/src/gnu/usr.bin. The next thing I tried to make came out like: cc -O -DNEWMOVE=12 -c /usr/src/gnu/chess/gnuchess.c cc: Internal compiler error: program cpp got fatal signal 12 *** Error code 1 Stop. I believe that I made everything in the correct order: src/share/mk src/include src/lib src/gnu/lib src/gnu/libexec src/gnu/usr.bin This order normally works for me. Note: last night, when I first tried to do this, before I did a make clean on the src/gnu/games, the error seemed to be with "ld" instead of cpp. I have the latest tar'ed binaries, and will try to recover from them. -- D. Jay Newman ! I'm now on the World Wide Web. To see more dn5@psu.edu ! about me (and trade MtG cards), check out URL jay@qabalah.cac.psu.edu ! http://qabalah.cac.psu.edu/~jay/ From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 18:06:48 1994 From: pdokas@pms988.pms.ford.com (Paul Dokas) Subject: Are these from 4.4-lite? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 454 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Update of /b/source/CVS/usr/games/tetris > In directory sun-lamp.cs.berkeley.edu:/tmp/tetris > > Revision/Branch: 1.1.1 > > Log Message: > ascii tetris! > > Status: > > Vendor Tag: CSRG > Release Tags: lite-1 ^^^^^^ |||||| Does this mean that 4.4-lite has shipped? I haven't seen any announcements on Usenet. Perhaps I'm just living in a cave... Just curious, Paul Dokas pdokas@pms988.pms.ford.com pbd@msen.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 18:19:26 1994 To: deraadt@fsa.ca (Theo Deraadt) Cc: gwr@mc.com, rls@zeus.id.net, current-users@sun-lamp.cs.berkeley.edu, sreiz@aie.nl Subject: Re: How to boot diskless... <9405060123.AA03106@fsa.ca> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > it is a very bad idea to load a kernel via TFTP. ... > it is much better to just load the kernel via nfs, though this does > make the boot process a little bit more complicated. Another possibility is to use regular FTP; there is a "tiny FTP" package out that makes a good start on an FTP kernel boot procedure. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 18:20:05 1994 From: Mike Long To: Mike.Long@analog.com Cc: current-users@sun-lamp.cs.berkeley.edu, freebsd-hackers@freefall.cdrom.com, smace@neosoft.com Subject: Re: Kermit and RTS/CTS flow control Organization: Analog Devices Inc, Norwood MA, USA X-Attribution: MWL Sender: owner-current-users@sun-lamp.cs.berkeley.edu The following patches make C-Kermit 5A(190) of April 10 work for me. *** ckutio.c.orig Mon Apr 4 09:41:40 1994 --- ckutio.c Sat Apr 30 00:15:33 1994 *************** *** 6991,6998 **** * systems that don't fit any of these three cases, we simply can't support * set-UID. */ ! #define switchuid(hidden,active) setuid(active) ! #define switchgid(hidden,active) setgid(active) #endif /* SETREUID */ --- 6991,6998 ---- * systems that don't fit any of these three cases, we simply can't support * set-UID. */ ! #define switchuid(hidden,active) seteuid(active) ! #define switchgid(hidden,active) setegid(active) #endif /* SETREUID */ *** ckcdeb.h.orig Sun Apr 10 18:37:03 1994 --- ckcdeb.h Fri May 6 01:48:55 1994 *************** *** 1093,1098 **** --- 1093,1101 ---- bit(s), seems to be gaining currency on POSIX-based UNIX systems. The following code defines the symbol POSIX_CRTSCTS for such systems. */ + #ifdef __NetBSD__ /* NetBSD */ + #define POSIX_CRTSCTS + #endif #ifdef __bsdi__ /* BSDI, a.k.a. BSD/386 */ #define POSIX_CRTSCTS #endif /* __bsdi__ */ -- Mike Long Mike.Long@Analog.com VLSI Design Engineer Analog Devices, SPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 19:12:23 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: Gorgonio@fee.unicamp.br Cc: current-users@sun-lamp.cs.berkeley.edu Subject: How to boot diskless... Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Date: Fri, 6 May 1994 11:40:08 -0300 > From: "Gorgonio Barreto Ara'ujo" > Is it necessary to change any thing in the kernel? [config] The config file needs: (at least) options INET # IP prototol stack support options NFSCLIENT # nfs client support config netbsd swap nfs # swap on NFS From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 19:12:48 1994 From: "Gorgonio Barreto Ara'ujo" To: rls@zeus.id.net, gwr@mc.com Subject: Re: How to boot diskless... Cc: sreiz@aie.nl, current-users@sun-lamp.cs.berkeley.edu, roberto@fee.unicamp.br Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From: gwr@jericho.mc.com (Gordon W. Ross) >Received: by walnut > (4.1//ident-1.0) id AA12001; Thu, 5 May 94 21:07:09 EDT [...] >The current NFS mount_root implementation uses BOOTP to get the >path names for root and swap. In fact, it kind of misuses the >"boot file name" part of the BOOTP response packet to get it. >The client sends a BOOTP request with "root" as the boot file >name, and expects the reply to have something like: > "/export/myclient/root" >as the boot file name. The client then sends another request >with "swap" as the boot file and expects something like: > "/export/myclient/swap" >as the boot file name. Not all bootp servers like this. >The bootp server I am maintaining (from CMU originally, and >now up to version 2.3.7) did not until recently allow for >the boot-file-name to change from one request to another. >(Time to check in the latest version, I guess...) Is it necessary to change any thing in the kernel? What should I change in the config file from a diskless kernel? Can I just change ``config options'' as follow? config netbsd root on ed0 swap on ed0 [...] > >I hope this helps more than it confuses... >Gordon Ross > netboot, found in /usr/src/sys/arch/i386/netboot, by Jim McKim (mckim@lerc.nasa.gov), does this process from a i386. There are drivers to Western Digital and NE2100. We're trying to port it to NE2000 and DEPCA. Gorgonio ================================================================================ Gorgonio B. Ara'ujo |SIFEE - FEE - UNICAMP Support Engineer |13.081.970 - Campinas/SP - Brazil |phone: +55 192 397421 |fax: +55 192 391395 |Internet: Gorgonio@fee.unicamp.br ================================================================================ From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 19:17:20 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Crash in networking coode (slpat!) Sender: owner-current-users@sun-lamp.cs.berkeley.edu panic: receive 3 _soreceive .. at _soreceive+0x5c2 _recvit .. at _0xfd _recvfrom .. at 0x71 _syscall .. at 0x11f syscall # 29 I have two interfaces running -- a wd8003e (8-bit) using the ed driver and a slip line @ 38400 baud link 0 (compressed) to campus. --M From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 20:33:47 1994 From: Steven Reiz To: Martin Renters Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: diskless booting <199405051702.TAA01692@aie5.aie.nl> Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> "Martin" == Martin Renters writes: Martin> I wrote the FreeBSD netboot program. I don't think the NetBSD Martin> folks ever did anything about running NetBSD diskless. Well, they did, there has been a pretty recent and extensive discussion about in-kernel support for diskless booting, apparently to help porting NetBSD to the sun3 without having to write a disk driver first. The person who did all this work (Adam Glass?), used the sun bootrom, which has support for diskless booting. Martin> think /usr/src/sys/arch/i386/netboot has kept up to date with Martin> other development (but then again, I haven't run NetBSD for a Martin> while, so I don't really know what the status of it is). I Martin> don't even know if it can cope with loading kernels into the Martin> above 1MB range. Exactly. >> The second loader I tried is the one from FreeBSD, which passes the >> rarp stage without any problems, but after Loading >> /tftpboot/cfg.193.78.1.41... it gives Executable too large. >> Unable to load config file. Martin> The FreeBSD netboot will only work with FreeBSD at the moment. Martin> This is because NetBSD has defined the nfs_diskless structure Martin> to be larger than that of FreeBSD and the netboot program Martin> expects the FreeBSD sized version. I had intended to make Martin> changes to support NetBSD as well, but the NetBSD core team Martin> was planning their own implementation so I never bothered. Well, I got past this stage by recompiling both netboot.com and diskless_cfg on NetBSD, the FreeBSD loader succeeds loading the kernel (text and data segments!), then the machine reboots, probably because the kernel is called at the wrong address. I would very much like to use your loader (it looks very nice :), could you give me some directions on how to make it work with NetBSD? I've tried setting RELOCADDR to 0x100000 in the Makefile, but netboot didn't compile with that value, complaining that some assembler instructions were no longer valid. Regards, -Steven From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 6 20:37:36 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 --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/m68k/m68k Modified Files: process_machdep.c Log Message: Rename a lot of process flags. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: trap.c Log Message: update to match current proc flags. --------------------------------- From: "Christian E. Hopps" Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: cpu.h Log Message: update to match current proc flags. --------------------------------- From: "Chris G. Demetriou" Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/m68k/m68k Modified Files: process_machdep.c Log Message: lots of changes: prototype migration, move lots of variables, definitions, and structure elements around. kill some unnecessary type and macro definitions. standardize clock handling. More changes than you'd want. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 20:38:48 1994 From: mark@aggregate.com (Mark P. Gooderum) To: Mike.Long@analog.com Subject: Re: Kermit and RTS/CTS flow control Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1453 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > check the status of your modem device (e.g. stty -af /dev/tty00) > see the -crtscts in the listing, and say AAAAAAAAAAARRGHHHHHH!!! > > (Scott, does this problem exist under FreeBSD as well? Let me know.) > > In order to get RTS/CTS flow control to work, you must compile Kermit > with (NetBSD example): > > make bsd44c KFLAGS=-DPOSIX_CRTSCTS > > Versions of C-Kermit 5A(190) dated after April 10 (ALPHA.02) have all > of the patches I sent out earlier on these lists incorporated (UUCP > lockfiles, &c.). I plan to try to get a patch for this problem > incorporated as well. Hmmm, I'll have to try this. I have patched the Apr 28th kermit (which hasn't changed since then) to use seteuid()/setegid() correctly. I also fixed up ckuuid.c to include this testing. I added a SETEUID define, (which implies SAVEDUIDS since it needs those to work). With these fixes ckuuid.c passes it's tests and says it's safe. (You have to switch the setreXid() calls to seteXid() in the priv_on() and priv_off() stuff and use setXid() for cancel_priv()). I've still got some other issues: It doesn't seem to be using its privleges to open the tty port, which seems to be the whole point of a setuid kermit. Also, "set modem ..." doesn't seem to get it to force NOBLOCK on the open of the tty device (the code seems to assume that this only matters for SysVen...blech). Once I've got the set line stuff working, I'll submit the seteuid() patches. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 21:08:32 1994 From: mark@aggregate.com (Mark P. Gooderum) To: dave@dogwood.com Subject: Re: stability of May 5 kernel Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1826 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I tried out the kernel from May 5 - after 10 hours of compiling X, a > new kernel and several X applications it's still running. From the May > 2nd kernel I was getting 2-3 hours between reboots under a lesser > load. > > Is the current tree (esp. kvm) in a shape that I dare try out > everything else? > > Thanks I've seen similar. I was getting dinked about 2-3 times a day by the May 2 kernel (random SEGVs on ar's, etc). I'm almost all the way through building the May 5 tree under the May 5 kernel w/o a problem. Another tidbit. I have a simple dumb performance test I wrote. It fork()s a child, and then the child sends several megs of data back to the parent using domain sockets (both kinds), UDP, TCP, and a pipe(). It sends the data using increasing message sizes (16, 256, 1024, and 4K), then prints out KB p/sec, msgs p/Sec, etc. This is very non-VM intensive, zero disk I/O, pretty much pure CPU but it seriously beats on context switching, the IPC kernel code, etc. Anyways, the May 2 kernel is about 2-3% slower than the Apr 12th and 28th kernel (which were about 20% faster than the March 15th one, the locore changes made a difference). However, I've never had the TCP test succeed on NetBSD before. It would run with 16 byte writes just fine, but as soon as it went to 256 byte writes both procs hung. They were still killable, but the socket locked up. Ironically, Solaris 2.0 and 2.1 had the same problem. BTW, this code is a pretty portable set of socket() calls. It all compiles without source changes or any conditional #defines except for which headers it needs (and the link has to change) on SunOS 4, SunOS 5, HP/UX 8 and 9, AIX 3.2.5, and NetBSD. But with the May 2 kernel, all tests now complete, so some of the fixes somewhere in the last two weeks made a difference. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 6 23:58:44 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: stability of May 5 kernel To: mark@aggregate.com (Mark P. Gooderum) Cc: dave@dogwood.com, 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: 511 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mark P. Gooderum > >Another tidbit. I have a simple dumb performance test I wrote. It >fork()s a child, and then the child sends several megs of data back to the >parent using domain sockets (both kinds), UDP, TCP, and a pipe(). >It sends the data using increasing message sizes (16, 256, 1024, and 4K), >then prints out KB p/sec, msgs p/Sec, etc. Any chance you'd be willing to post this software to the mailing list? Sounds like a useful "Is-this-week's-kernel-doing-The_Right_Thing" test. Gregc@edi.com From owner-amiga-x@sun-lamp.cs.berkeley.edu Sat May 7 01:47:06 1994 From: Howard Dobson To: amiga-x@sun-lamp.cs.berkeley.edu, dsnjvro@etmsun.ericsson.se Subject: Re: Problems compiling libX* Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > I've been trying to compile the Xlibs, but I keep getting > strange error messages. > > Here is part of it: > > including in ./config > [: .././X11: binary operator expected > > blablabla > > ln -s ../ .. /./config/imakemdep.h . > ^ ^ > these spaces should not be here > I believe you need to patch/compile config/ccimake.c so that it will run use the -traditional flag when calling cpp. From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 02:15:02 1994 From: Charlie Root Subject: Testing out a new SLIP connection To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1233 Sender: owner-current-users@sun-lamp.cs.berkeley.edu If anyone gets this message, then I am not having as much trouble with my sendmail as I thought. Is there anyone out there that would like to do a little hand-holding for getting sendmail installed more or less correctly? This is my 'mailq' output: Mail Queue (5 requests) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ WAA11070 7 Thu May 5 22:51 root (cynjut: Name server timeout) burgess@cynjut WAA11041 52 Thu May 5 22:48 root (news.infonet.net: Name server timeout) news@news.infonet.net WAA10892 1148 Thu May 5 22:40 root (s069.infonet.net: Name server timeout) burgess@s069.infonet.net WAA10545 1148 Thu May 5 22:01 root (insosf1.infonet.net: Name server timeout) news@insosf1.infonet.net VAA10260 936 Thu May 5 21:29 (cwis.unomaha.edu: Name server timeout) where 'cynjut' is my host name. 's069.infonet.net' is an alias. and the rest are generally valid names and hosts. This has me really confused so far. I am really not getting anywhere with this. TSgt Dave From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 02:21:32 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: IPC Test program X-Sun-Charset: US-ASCII Content-Length: 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu After 10 requests already for this I figured it was worth posting. If someone wants to implement some of the unimplmented SysV IPC testing, go to it. There is a -z debug flag as well. Building on SysVen will usually require -lsocket (and maybe -lnsl). The formatting is kind of futzed because I use 4 char tab stops. Use indent in emacs to fix it. If you use vi, that's you're problem ;-). Change the value of BASE_MSG to change the total byte volume to get long enough runs to have good numbers and short enough runs to go home. These numbers are good for 486 up to slow Suns. Faster boxes and screamers require much larger numbers to run long enough to get good timings. -Mark ------ /* * ipc.c - A program to measure local IPC speed. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include /* * Constants... */ #define BASE_MSG (1048576 / 16) #undef TRUE #undef FALSE #define TRUE 1 #define FALSE 0 /* * Type Declarations... */ typedef struct ipc_stat { int io_size; /* # of bytes per I/O op */ int io_total; /* Total # of bytes done */ int millisec; /* # millsecsonds to do types for all I/O */ double io_kps; /* K bytes per/second I/O speed */ double msg_ps; /* # messages per second */ } ipc_stat; /* * Variables... */ int size_list[] = { 16, 256, 1024, 4096, -1 }; ipc_stat stat_tab[100]; char write_buf[4096], read_buf[4096]; int sock_domain_stream = FALSE; int sock_domain_dgram = FALSE; int sock_tcp = FALSE; int sock_udp = FALSE; int msg_port = FALSE; int stream_pipe = FALSE; int debug_flag = FALSE; /* * Socket stuff... */ struct sockaddr_in maddr, saddr; struct sockaddr aaddr; /* * Support functions... */ void usage(void); void print_stats(char *, ipc_stat *); ipc_stat *do_io(int *, ipc_stat *); int sock_master(int); int sock_stream(int); /* * Measurement functions... */ ipc_stat *do_sock_domain_stream(); ipc_stat *do_sock_domain_dgram(); ipc_stat *do_sock_udp(); ipc_stat *do_sock_tcp(); ipc_stat *do_stream_pipe(); /* * Support functions... */ void main(int argc, char *argv[]) { ipc_stat *stats; char opt; /* * Check for args... */ if (argc <= 1) { usage(); exit(0); } /* * Parse our argument list... */ while ((opt = getopt(argc, argv, "adDptumz")) != EOF) { switch(opt) { case 'a': sock_domain_stream = TRUE; sock_domain_dgram = TRUE; sock_tcp = TRUE; sock_udp = TRUE; stream_pipe = TRUE; msg_port = TRUE; break; case 'd': sock_domain_stream = TRUE; break; case 'D': sock_domain_dgram = TRUE; break; case 't': sock_tcp = TRUE; break; case 'u': sock_udp = TRUE; break; case 'm': msg_port = TRUE; break; case 'p': stream_pipe = TRUE; break; case 'z': debug_flag = TRUE; break; default: usage(); exit(1); } /* switch */ } /* while */ /* * Do our measurements and print the results for each * IPC method. */ if (sock_domain_stream) { stats = do_sock_domain_stream(); print_stats("Stream Domain Sockets", stats); } if (sock_domain_dgram) { stats = do_sock_domain_dgram(); print_stats("Datagram Domain Sockets", stats); } if (sock_udp) { stats = do_sock_udp(); print_stats("UDP Sockets", stats); } if (sock_tcp) { stats = do_sock_tcp(); print_stats("TCP Sockets", stats); } if (msg_port) { printf("Warning, '-m' - SysV Messages, currently not supported.\n"); } if (stream_pipe) { stats = do_stream_pipe(); print_stats("Stream Pipe", stats); } } /* main() */ /* * usage() */ void usage(void) { printf("\nUsage: ipc [-dtums]\n"); printf("\t-a\t-Time all.\n"); printf("\t-d\t-Time Stream Domain Sockets\n"); printf("\t-D\t-Time Datagram Domain Sockets\n"); printf("\t-t\t-Time TCP Sockets\n"); printf("\t-u\t-Time UDP Sockets\n"); printf("\t-m\t-Time Message Ports\n"); printf("\t-p\t-Time Stream Pipes\n"); printf("\n"); } /* * do_sock_domain_stream() */ ipc_stat *do_sock_domain_stream(void) { ipc_stat *retval; int fds[2]; int x; /* * Initialize some variables. */ retval = stat_tab; /* * Loop on I/O sizes calling do_io()... */ for (x = 0; size_list[x] != -1; x++) { retval[x].io_size = size_list[x]; if (socketpair(AF_UNIX, SOCK_STREAM, 0, fds) == -1) { perror("socketpair(SOCK_STREAM) failed"); retval[0].io_size = -1; return(NULL); } do_io(fds, &retval[x]); close(fds[0]); close(fds[1]); } retval[x].io_size = -1; /* * And return... */ return(retval); } /* do_sock_domain_stream() */ /* * do_sock_domain_dgram() */ ipc_stat *do_sock_domain_dgram(void) { ipc_stat *retval; int fds[2]; int x; /* * Initialize some variables. */ retval = stat_tab; /* * Loop on I/O sizes calling do_io()... */ for (x = 0; size_list[x] != -1; x++) { retval[x].io_size = size_list[x]; if (socketpair(AF_UNIX, SOCK_DGRAM, 0, fds) == -1) { perror("socketpair(SOCK_DGRAM) failed"); retval[0].io_size = -1; return(NULL); } do_io(fds, &retval[x]); close(fds[0]); close(fds[1]); } retval[x].io_size = -1; /* * And return... */ return(retval); } /* do_sock_domain_dgram() */ /* * do_sock_tcp() */ ipc_stat *do_sock_tcp(void) { ipc_stat *retval; int fds[2]; int x, ts, ssize; /* * Initialize some variables. */ ssize = sizeof(aaddr); retval = stat_tab; /* * Loop on I/O sizes calling do_io()... */ for (x = 0; size_list[x] != -1; x++) { retval[x].io_size = size_list[x]; /* * Initialize our fd's... */ if ((ts = sock_master(SOCK_STREAM)) < 0) { return(NULL); } if ((fds[1] = sock_slave(SOCK_STREAM)) < 0) { return(NULL); } if ((fds[0] = accept(ts, &aaddr, &ssize)) < 0) { return(NULL); } do_io(fds, &retval[x]); close(fds[0]); close(fds[1]); close(ts); } retval[x].io_size = -1; /* * And return... */ return(retval); } /* do_sock_tcp() */ /* * do_sock_udp() */ ipc_stat *do_sock_udp(void) { ipc_stat *retval; int fds[2]; int x, ts, ssize; /* * Initialize some variables. */ ssize = sizeof(aaddr); retval = stat_tab; /* * Initialize our fd's... */ /* * Loop on I/O sizes calling do_io()... */ for (x = 0; size_list[x] != -1; x++) { retval[x].io_size = size_list[x]; /* * Initialize our fd's... */ if ((fds[1] = sock_master(SOCK_DGRAM)) < 0) { return(NULL); } if ((fds[0] = sock_slave(SOCK_DGRAM)) < 0) { return(NULL); } do_io(fds, &retval[x]); close(fds[0]); close(fds[1]); close(ts); } retval[x].io_size = -1; /* * And return... */ return(retval); } /* do_sock_udp() */ /* * do_stream_pipe() */ ipc_stat *do_stream_pipe(void) { ipc_stat *retval; int fds[2]; int x; /* * Initialize some variables. */ retval = stat_tab; /* * Loop on I/O sizes calling do_io()... */ for (x = 0; size_list[x] != -1; x++) { retval[x].io_size = size_list[x]; if (pipe(fds) == -1) { perror("socketpair(SOCK_STREAM) failed"); retval[0].io_size = -1; return(NULL); } do_io(fds, &retval[x]); close(fds[0]); close(fds[1]); } retval[x].io_size = -1; /* * And return... */ return(retval); } /* do_stream_pipe() */ /* * do_io() * * Do the I/O on a given descriptor (writing) and measure it. */ ipc_stat *do_io(int *fd, ipc_stat *istat) { struct timeval begtime, endtime; register int x; register int num_msgs; int pid, ret; int size; int tot_size; register int fd1 = fd[0], fd2 = fd[1]; size = istat->io_size; num_msgs = BASE_MSG / (int) log2(size); tot_size = num_msgs * size; if (debug_flag) { printf("do_io(): Size=%d, msgs=%d\n", size, num_msgs); } if ((pid = fork()) == -1) { return(NULL); } gettimeofday(&begtime); if (pid > 0) { close(fd2); for (x = 0; x < num_msgs ; x++) { writen(fd1, write_buf, size); } } if (pid == 0) { close(fd1); for (x = 0; x < num_msgs ; x++) { readn(fd2, read_buf, size); } _exit(0); } kill(pid, SIGTERM); do { ret = wait(NULL); } while (ret != pid); gettimeofday(&endtime); istat->io_total = tot_size; istat->millisec = (((endtime.tv_sec * 1000) + (endtime.tv_usec / 1000)) - ((begtime.tv_sec * 1000) + (begtime.tv_usec / 1000))); istat->io_kps = ((double) istat->io_total) / ((double) istat->millisec) * 1000.0 / 1024.0; istat->msg_ps = ((double) num_msgs * 1000.0) / ((double)(istat->millisec)); return(istat); } /* do_io() */ /* * print_stats() */ void print_stats(char *io_type, ipc_stat *stats) { int x; printf("Timing for %s:\n", io_type); printf("--------------------------------\n"); for (x = 0; stats[x].io_size != -1; x++) { printf("Size: %d,\tKB p/sec: %.2f,\tMsgs p/sec: %.2f\n", stats[x].io_size, stats[x].io_kps, stats[x].msg_ps); } printf("\n"); } /* print_stats() */ /* * readn() * * Read n bytes from a stream socket. A stream socket may return 0 * read but still have I/O because of buffering constraints. */ int readn(fd, parg, nbytes) int fd; void *parg; int nbytes; { char *ptr= parg; int nleft, nread, ntot = 0; /* * Loop until we read() nbytes bytes or until we get an error (which * may be EWOULDBLOCK if it's a non-blocking socket. */ nleft = nbytes; while (nleft > 0) { nread = read(fd, ptr, nleft); if (nread < 0) { /* * If we have read some bytes throw away the error and return what * we have read, otherwise return the error. */ return(ntot > 0 ? ntot : nread); } else if (nread == 0) { break; } ntot += nread; nleft -= nread; ptr += nread; } return(nbytes - nleft); } /* readn() */ /* * writen() * * Write n bytes to a stream socket. */ int writen(fd, parg, nbytes) int fd; void *parg; int nbytes; { char *ptr = parg; int nleft = nbytes, ntally = 0, nwritten; while (nleft > 0) { nwritten = write(fd, ptr, nleft); if (nwritten < 0) { return(ntally > 0 ? ntally : nwritten); } else if (nwritten == 0) { break; } nleft -= nwritten; ntally += nwritten; ptr += nwritten; } return(nbytes - nleft); } /* writen() */ /* * sock_master() * * This function opens the master half of a Unix socket. * We use a sock of the name */ static int sock_master(type) int type; { int master_fd; int alen; int retval; struct hostent *host; if ((master_fd = socket(AF_INET, type, 0)) < 0) { return(-1); } memset(&maddr, 0, sizeof(maddr)); maddr.sin_family = AF_INET; maddr.sin_addr.s_addr = htonl(INADDR_ANY); maddr.sin_port = 0; alen = sizeof(maddr); if (bind(master_fd, &maddr, alen) < 0) { close(master_fd); return(-1); } if (getsockname(master_fd, &saddr, &alen) < 0) { close(master_fd); return(-1); } if ((host = gethostbyname("localhost")) == NULL) { return(-1); } memcpy(&saddr.sin_addr, host->h_addr_list[0], host->h_length); maddr.sin_port = saddr.sin_port; if (type == SOCK_STREAM) { if ((retval = listen(master_fd, 5)) < 0) { return(-1); } } return(master_fd); } /* sock_master() */ /* * sock_slave() * * This function opens the slave half of a Unix socket. */ static int sock_slave(type) int type; { int slave_fd; int alen; if ((slave_fd = socket(AF_INET, type, 0)) < 0) { return(-1); } alen = sizeof(saddr); if (connect(slave_fd, &saddr, alen) < 0) { close(slave_fd); return(-1); } if (getsockname(slave_fd, &saddr, &alen) < 0) { close(slave_fd); return(-1); } return(slave_fd); } /* sock_slave() */ ----- End Included Message ----- From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 03:09:38 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: Re: Do we have an all clear for SMC Ethernet Cards To: mycroft@gnu.ai.mit.edu Cc: 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: 2605 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > I explained at the time what was happening; specifically, the el and wt > probe routines reprogrammed the cards. People with custom kernels or > SMC cards at addresses other than 0x300 never saw the problem in the > first place. My kernel looks like the following config, but it locks up right after the 'starting network' in the rc. The ed0 probe seems fine though. Is this even related? > I've `fixed' this for now by simply removing the el0 and wt0 devices > from the GENERIC configs. Clearly this needs to be addressed better, > but it certainly cures the symptom for now. And I haven't ever had these in my kernels.... > > I've also worked with a few people to bring their cards back to life. > > It almost seems like your message was intended to scare people. I hope > this is not the case. > Here's my kernel config.... machine "i386" cpu "I486_CPU" ident GHOST timezone 5 dst maxusers 32 maxfdescs 2048 options SWAPPAGER,VNODEPAGER,DEVPAGER options FFS options INET,NFSSERVER,NFSCLIENT,ISOFS,KERNFS options "COMPAT_43" options "COMPAT_09" options "TCP_COMPAT_42" options UCONSOLE, XSERVER options SCSI options "COMPAT_NOMID" options "MACHINE_NONCONTIG" config netbsd root on sd0 swap on sd0 controller isa0 device pc0 at isa? port "IO_KBD" tty irq 1 vector pcrint device com0 at isa? port "IO_COM1" tty irq 4 vector comintr device com1 at isa? port "IO_COM2" tty irq 3 vector comintr controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr disk fd0 at fdc0 drive ? disk fd1 at fdc0 drive ? controller ahb0 at isa? bio irq 11 vector ahbintr master scsibus0 at ahb0 disk sd0 at scsibus0 slave 000 disk sd1 at scsibus0 slave 010 disk sd2 at scsibus0 slave 020 disk sd3 at scsibus0 slave 040 tape st0 at scsibus0 slave 030 tape st1 at scsibus0 slave 050 disk cd0 t scsibus0 slave 060 disk sd4 at scsibus0 slave ? disk sd5 at scsibus0 slave ? tape st2 at scsibus0 slave ? disk cd1 at scsibus0 slave ? device ed0 at isa? port 0x280 net irq 9 iomem 0xd0000 vector edintr device npx0 at isa? port "IO_NPX" irq 13 vector npxintr pseudo-device loop pseudo-device ether pseudo-device log pseudo-device pty 32 pseudo-device ppp From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 03:57:06 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: gillham@andrews.edu (Andrew Gillham) Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Do we have an all clear for SMC Ethernet Cards <9405062319.AA21092@elrond> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > My kernel looks like the following config, but it locks up right > after the 'starting network' in the rc. The ed0 probe seems fine > though. Is this even related? i'd say 'no, not at all.' Umm, how do you have your network devices secified? i.e. by name or ipaddr, etc.? if by name, how are your nameservers, etc., set up? cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 04:56:00 1994 From: Dave Burgess Subject: test(1) patches To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5416 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Here are the patches that I put up once before as a uuencoded file. They are not uuencoded this time (so that it is easier for folks to check them out I guess). The only things that these patches do is allow you to compare file dates. They can be applied directly to the -current sources. - - - - - - - - - - - - - Cut Here - - - - - - - - - - - - - *** Makefile Sat Apr 9 20:43:09 1994 --- ../newtest2/Makefile Sat Apr 2 14:35:13 1994 *************** *** 8,14 **** MLINKS= test.1 '[.1' # use this rule to if you update binary_ops, or unary_ops ! make_op: ! sh ${.CURDIR}/mkops ! .include --- 8,20 ---- MLINKS= test.1 '[.1' # use this rule to if you update binary_ops, or unary_ops ! #make_op: ! # sh ${.CURDIR}/mkops ! # ! # IF YOU UPDATE binary_ops or unary_ops and have an obj directory link, ! # you MUST run mkops yourself. If you don't, the resulting output ! # files will end up in obj. While that isn't a problem (sine they get ! # correctly compiled after that), this program will not run, since you ! # don't have copies of *_ops in obj. ! # .include *** TEST.csh Sat Apr 9 20:43:14 1994 --- ../newtest2/TEST.csh Sat Apr 2 14:40:18 1994 *************** *** 1,6 **** # @(#)TEST.csh 5.1 (Berkeley) 6/8/92 ! alias t './test \!*; echo $status' #alias t 'test \!*; echo $status' echo 't -b /dev/ttyp2' --- 1,6 ---- # @(#)TEST.csh 5.1 (Berkeley) 6/8/92 ! alias t './obj/test \!*; echo $status' #alias t 'test \!*; echo $status' echo 't -b /dev/ttyp2' *************** *** 35,40 **** --- 35,45 ---- echo 't -g /bin/ps' t -g /bin/ps + echo 't -h /sys' + t -h /sys + echo 't -h /usr/src' + t -h /usr/src + echo 't -n ""' t -n "" echo 't -n "hello"' *************** *** 135,137 **** --- 140,172 ---- t 700 -le 1000 -a -n "1" -a "20" = "20" echo 't ! \( 700 -le 1000 -a -n "1" -a "20" = "20" \)' t ! \( 700 -le 1000 -a -n "1" -a "20" = "20" \) + + echo 't /etc/passwd -nt ./obj/test' + t /etc/passwd -nt ./obj/test + echo 't ! /etc/passwd -nt ./obj/test' + t ! /etc/passwd -nt ./obj/test + + echo 't /etc/passwd -ot ./obj/test' + t /etc/passwd -ot ./obj/test + echo 't ! /etc/passwd -ot ./obj/test' + t ! /etc/passwd -ot ./obj/test + + echo 't /etc/passwd -sa ./obj/test' + t /etc/passwd -sa ./obj/test + echo 't ! /etc/passwd -sa ./obj/test' + t ! /etc/passwd -sa ./obj/test + + echo 't /etc/passwd -sa /etc/passwd' + t /etc/passwd -sa /etc/passwd + echo 't ! /etc/passwd -sa /etc/passwd' + t ! /etc/passwd -sa /etc/passwd + + echo 't /etc -nt /etc/passwd # Check Dir age vs. file' + t /etc -nt /etc/passwd + echo 't ! /etc -nt /etc/passwd' + t ! /etc -nt /etc/passwd + + echo 't obj -nt /etc/passwd # Check SymLink age vs. file' + t obj -nt /etc/passwd + echo 't ! obj -nt /etc/passwd' + t ! obj -nt /etc/passwd *** binary_op Sat Apr 9 20:43:18 1994 --- ../newtest2/binary_op Sat Apr 2 14:35:14 1994 *************** *** 53,56 **** LT -lt 4 OP_INT LE -le 4 OP_INT GE -ge 4 OP_INT ! --- 53,58 ---- LT -lt 4 OP_INT LE -le 4 OP_INT GE -ge 4 OP_INT ! NT -nt 4 OP_FILE ! OT -ot 4 OP_FILE ! SA -sa 4 OP_FILE *** mkops Sat Apr 9 20:43:23 1994 --- ../newtest2/mkops Sat Apr 2 14:35:14 1994 *************** *** 71,80 **** }; char *const andor_op[] = {' ! awk '/^[^#]/ && ($3 <= 2) {printf " \"%s\",\n", $2}' binary_op echo ' NULL }; - const char op_priority[] = {' awk '/^[^#]/ {printf " %s,\n", $3}' unary_op binary_op echo '}; --- 71,80 ---- }; char *const andor_op[] = {' ! awk '/^OR/ {printf " \"%s\",\n", $2}' binary_op ! awk '/^AND/ {printf " \"%s\",\n", $2}' binary_op echo ' NULL }; const char op_priority[] = {' awk '/^[^#]/ {printf " %s,\n", $3}' unary_op binary_op echo '}; *** operators.c Sat Apr 9 20:43:26 1994 --- ../newtest2/operators.c Sat Apr 2 14:38:26 1994 *************** *** 40,45 **** --- 40,48 ---- "-lt", "-le", "-ge", + "-nt", + "-ot", + "-sa", NULL }; *************** *** 50,56 **** "&", NULL }; - const char op_priority[] = { 3, 12, --- 53,58 ---- *************** *** 82,87 **** --- 84,92 ---- 4, 4, 4, + 4, + 4, + 4, }; const char op_argflag[] = { *************** *** 115,118 **** --- 120,126 ---- OP_INT, OP_INT, OP_INT, + OP_FILE, + OP_FILE, + OP_FILE, }; *** operators.h Sat Apr 9 20:43:28 1994 --- ../newtest2/operators.h Sat Apr 2 14:38:25 1994 *************** *** 28,33 **** --- 28,36 ---- #define LT 27 #define LE 28 #define GE 29 + #define NT 30 + #define OT 31 + #define SA 32 #define FIRST_BINARY_OP 18 *** test.1 Sat Apr 9 20:43:34 1994 --- ../newtest2/test.1 Sat Apr 2 14:35:29 1994 *************** *** 196,201 **** --- 196,217 ---- is algebraically less than or equal to the integer .Ar \&n\&2 . + .\" New stuff + .It Ar \&file\&1 Fl \&nt Ar \&file\&2 + True if the file + .Ar \&file\&1 + is newer than + .Ar \&file\&2 . + .It Ar \&file\&1 Fl \&ot Ar \&file\&2 + True if the file + .Ar \&file\&1 + is older than + .Ar \&file\&2 . + .It Ar \&file\&1 Fl \&sa Ar \&file\&2 + True if the file + .Ar \&file\&1 + is the \&same \&age as + .Ar \&file\&2 . .El .Pp These primaries can be combined with the following operators: From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 05:18:08 1994 From: Dave Burgess Subject: Patches for slattach(???) To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3516 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have been using this set of patches for slattach for a couple of months. They change a couple of things... 1. They add the functionality of creating a pid file. 2. They change the default baud rate to 38400 baud (the fastest interface speed my modem and software will support). Understanding that the thing with the pid file is for my personal convenience (for killing the slattach that should be running) the program should (but does not yet) check to see if there is a copy of it running. I usurped the -p option for writing the pid file (/var/run/slattach.pid) so that the default behavior is the same as it always was. TSgt Dave - - - - - - - - - - Cut Here - - - - - - - - - - *** slattach.c.orig Fri Feb 11 04:18:05 1994 --- slattach.c Thu Mar 31 21:43:18 1994 *************** *** 1,3 **** --- 1,4 ---- + /* * Copyright (c) 1988 Regents of the University of California. * All rights reserved. *************** *** 59,73 **** #include #include #include ! ! #define DEFAULT_BAUD 9600 ! static char usage_str[] = "\ ! usage: %s [-h] [-m] [-s ] \n\ -h -- turn on CTS/RTS style flow control\n\ -m -- maintain DTR after last close (no HUPCL)\n\ ! -s -- baud rate (default 9600)\n"; ! int main(int argc, char **argv) { struct termios tty; --- 60,75 ---- #include #include #include ! #define PIDFILE "/var/run/slattach.pid" ! #define DEFAULT_BAUD 38400 ! static char usage_str[] = "\ ! usage: %s [-h] [-m] [-p] [-s ] \n\ -h -- turn on CTS/RTS style flow control\n\ -m -- maintain DTR after last close (no HUPCL)\n\ ! -p -- write pid number to %s\n\ ! -s -- baud rate (default 38400)\n"; ! int main(int argc, char **argv) { struct termios tty; *************** *** 78,88 **** int slipdisc = SLIPDISC; int speed = DEFAULT_BAUD; int cflags = HUPCL; extern char *optarg; extern int optind; ! while ((option = getopt(argc, argv, "achmns:")) != EOF) { switch (option) { case 'h': cflags |= CRTSCTS; --- 80,92 ---- int slipdisc = SLIPDISC; int speed = DEFAULT_BAUD; int cflags = HUPCL; + int pidfile = 0; + FILE *outfile; extern char *optarg; extern int optind; ! while ((option = getopt(argc, argv, "achmnps:")) != EOF) { switch (option) { case 'h': cflags |= CRTSCTS; *************** *** 90,101 **** case 'm': cflags &= ~HUPCL; break; case 's': speed = atoi(optarg); break; case '?': default: ! fprintf(stderr, usage_str, argv[0]); exit(1); } } --- 94,108 ---- case 'm': cflags &= ~HUPCL; break; + case 'p': + pidfile = 1; + break; case 's': speed = atoi(optarg); break; case '?': default: ! fprintf(stderr, usage_str, argv[0],PIDFILE); exit(1); } } *************** *** 104,110 **** dev = argv[optind]; if (dev == (char *)0) { ! fprintf(stderr, usage_str, argv[0]); exit(2); } --- 111,117 ---- dev = argv[optind]; if (dev == (char *)0) { ! fprintf(stderr, usage_str, argv[0], PIDFILE); exit(2); } *************** *** 153,158 **** --- 160,175 ---- if (fork() > 0) exit(0); + + if (pidfile) { + outfile = fopen(PIDFILE,"w"); + if (outfile != NULL) { + fprintf(outfile,"%d",(int)getpid()); + fclose(outfile); + } else { + fprintf(stderr,"Invalid pid file name.\n"); + } + } for (;;) sigpause(0L); From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 05:36:46 1994 From: "Chris G. Demetriou" 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 doc/MIRRORS U src/lib/libc/gen/devname.3 U src/lib/libc/gen/devname.c U src/lib/libc/gen/popen.3 U src/lib/libc/gen/popen.c U src/lib/libc/stdlib/getopt.3 U src/lib/libc/stdlib/getopt.c U src/sys/arch/i386/include/cpu.h U src/sys/arch/m68k/m68k/copy.s U src/sys/arch/mac68k/dev/asc.c U src/sys/arch/mac68k/include/cpu.h U src/sys/arch/mac68k/include/param.h U src/sys/arch/mac68k/include/proc.h U src/sys/arch/mac68k/mac68k/clock.c U src/sys/arch/mac68k/mac68k/genassym.c U src/sys/arch/mac68k/mac68k/locore.s U src/sys/arch/mac68k/mac68k/machdep.c U src/sys/arch/mac68k/mac68k/mem.c U src/sys/arch/mac68k/mac68k/trap.c U src/sys/arch/mac68k/mac68k/vm_machdep.c U src/sys/arch/sun3/include/cpu.h U src/sys/arch/sun3/sun3/genassym.c U src/sys/arch/sun3/sun3/process.s U src/sys/kern/kern_exit.c U src/sys/kern/kern_synch.c U src/sys/kern/kern_sysctl.c U src/sys/sys/signal.h U src/sys/sys/sysctl.h U src/sys/sys/time.h U src/sys/vm/vm_extern.h U src/sys/vm/vm_pageout.c U src/sys/vm/vm_pageout.h U src/sys/vm/vm_param.h U src/usr.bin/Makefile U src/usr.bin/id/Makefile U src/usr.bin/id/groups.1 U src/usr.bin/id/groups.sh U src/usr.bin/id/id.1 U src/usr.bin/id/id.c U src/usr.bin/id/whoami.1 U src/usr.bin/id/whoami.sh U othersrc/Makefile Updating tar files: src/usr.sbin: tarring... gzipping... replacing... done src/usr.bin: tarring... gzipping... replacing... done src/sys: tarring... gzipping... replacing... done src/share: tarring... gzipping... replacing... done src/sbin: tarring... gzipping... replacing... done src/libexec: tarring... gzipping... replacing... done src/lib: tarring... gzipping... replacing... done src/include: tarring... gzipping... replacing... done src/gnu: tarring... gzipping... replacing... done src/games: tarring... gzipping... replacing... done src/etc: tarring... gzipping... replacing... done src/regress: tarring... gzipping... replacing... done src/bin: tarring... gzipping... replacing... done othersrc/kermit: tarring... gzipping... replacing... done othersrc/sup: tarring... gzipping... replacing... done othersrc/gated-2.1: tarring... gzipping... replacing... done config: tarring... gzipping... replacing... done config.new: tarring... gzipping... replacing... done Running the SUP scanner: SUP Scan for current starting at Fri May 6 18:38:11 1994 SUP Scan for current completed at Fri May 6 18:50:33 1994 SUP Scan for mirror starting at Fri May 6 18:50:36 1994 SUP Scan for mirror completed at Fri May 6 18:59:51 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 7 06:28:32 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: fsck clears non-empty files Sender: owner-current-users@sun-lamp.cs.berkeley.edu When fsck does the filesystem check (either on boot or when run manually), and a non-empty file is not in a directory, fsck does not put it in lost+found, but rather clears it. This is contrary to both the documentation and what I have experienced on other systems. Is it really supposed to work this way? ~Steve -- Steven R. Allen - wormey@eskimo.com Hatred, n.: A sentiment appropriate to the occasion of another's superiority. -- Ambrose Bierce, "The Devil's Dictionary" From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 8 06:45:47 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Boot loader testers wanted To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD Amiga-Dev) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1260 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi there, I have this boot loader in the point that it would need some tests in different environments. I myself have A3000 w/ 18M ram, two scsi disk drives and a tape. Kickstart is v36 and therefore I would like to see v37 and newer kickstart testers too (I guess just minority of us have v36 ?). To use the boot loader you need: - v36 or newer kickstart (this may change.. I can't test) - 1M or more custom chips memory (just the way loadbsd does) - scsi card & drive usable at boot time (and named as scsi.device) (of course you can compile your own version with different device) - BFFS (BSD Fast File System file handler for AmigaDOS) for install (or some other way to move a file to your bsd root partition boot blocks) - gcc 2.3.3 or newer if you want to compile your own version (I would like to know how this compiles and works with latest (2.5.8) gcc) - some hacker attitude :-) One thing.. I have only #744 kernel (the version before going to SUP) and don't know if the loader works at all with newer kernels. I hear that loadbsd has changed since then.. I would like to give current version of the boot loader (ufsboot) to a handfull of people to test in the first phase and then release the whole thing to public (with sources). ++Tero From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun May 8 07:13:57 1994 From: Donn Cave X-Sender: donn@homer08.u.washington.edu Subject: gfx card drivers To: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 520 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I won't ask if anyone's working on Spectrum or Piccolo support. But I am curious if anyone has any sense of how cooperative their respective manufacturers would be, if approached for hardware programming information? The Retina support code bears a little notice along these lines, that makes it sound like this is a pretty sensitive matter. Was it easy to get the dope on the Picasso card? (Maybe NetBSD looks pretty good to 3rd party Amiga hardware manufacturers, these days.) Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 8 07:39:02 1994 From: Dave Burgess Subject: Lurking for a friend... To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 339 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu A friend of mine is staioned in Panama (the country) and would like to do something with his Amiga3000 other than prop up the end of his printer stand. Would anyone mind dropping me a quick note letting me know more about the Amiga port; I haven't been following it at all, and now suddenly I'm under the gun to produce results :-(.... From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 8 08:00:35 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: NetBSD amiga? Cc: amiga@sun-lamp.cs.berkeley.edu From: Terminator rAT Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, all! I have an A3000 6M ram, 105+40M disk, ASDG LanRover that I want to run NetBSD on. How should I go about bootstrapping said machine? Thanks! -rAT O----O Email: rat@cs.orst.edu Work: (503)737-5567 Home: (503)737-9467 \oo/ Instructional Support Technical Maniac ==\/== "Got carried away...In my dreams you're so far away..." -Violet Arcana From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 8 12:29:31 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: New changes To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1827 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Lots and lots of things are happening right now. For the past week or so I have been converting the amiga source over to config.new and the /sys/scsi system not a small thing indeed. Then suddenly all the kernel and binaries start to change relating to new cool things outside of amiga's So I have commited my personal tree to avoid going insane tracking them both. As a result I can only guarentee that the gvp series 2 driver works I have high expectations that the A3000 and A091 will also work hoever I have no hardware to test them. The things that remain for me to convert are the sci. drivers (5380) and the 53710 siop.c drivers, along with the floppy and ethernet devices. The current sup will not produce a compilable kernel becuase the rest of the kernel is changing to quickly. However my tree from yesterday is what I am running currently. And it shouldn't take but a couple days to catch up to the common source. IDE soon too. Hopefully I can pull a more recent lance ethernet driver from the sparc tree now that we are using config.new Future things I want to work on.. Instalation and similar software. However without another machine I don't know how much aI can do it was scary enough booting the new scsi system on the same machine that held a weeks worth of source. I changed the dostypes used by NetBSD to something more usefull.. It remains backward compatable.. The new types are more similar to amigados 'NBR\x', 'NBS\1', 'NBU\x', for root, swap, and user partitions respectively. The 'x' is the file system type (swap should always be one) The kernel now has a clean method of reading disklabels and in the not so distant future will also write them (as RDB's) Alowing saving of file system parameters as well as configuration of HD's under NetBSD back to work. ETIMEDOUT Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 12:43:48 1994 From: sjg@zen.void.oz.au (Simon J. Gerraty) To: current-users@sun-lamp.cs.berkeley.edu Subject: anyone ported ofiles? Sender: owner-current-users@sun-lamp.cs.berkeley.edu ofiles is a nifty tool by C. Spencer and various contributors, which can display who has a particular file open. It is very useful to see which process is causing a filesystem to be busy etc. Anyway, I was wondering if anyone had ported it or a similar tool to NetBSD? It would help me track down fd leakage in pdksh. --sjg From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 8 12:46:57 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: NetBSD/Amiga To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 451 Sender: owner-amiga@sun-lamp.cs.berkeley.edu (I posted this in comp.unix.amiga too) I have come to drop a note saying two things 1) So far I have received $100 not quite what I need. BTW If at the very least you people can only gather enough to buy me more HD space I will at least be able to do better distributions.. with X.. 2) In the next 3 weeks the amiga port will be taking on a very new and exciting look (well internally at least :) So please be patient. (IDE soon too) Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:13:38 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Dave Burgess Cc: current-users@sun-lamp.cs.berkeley.edu, explorer@vorpal.com Subject: Re: Patches for slattach(???) <199405070121.UAA01391@s069.infonet.net> From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu While I like the baud set to 38400, the pid file is a bad idea mostly because there can be more than one slattach running at any time on two seperate ports. I do this once in a while for testing slip, for example. >1. They add the functionality of creating a pid file. >! #define PIDFILE "/var/run/slattach.pid" >! #define DEFAULT_BAUD 38400 --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 Sun May 8 13:14:00 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: wormey@eskimo.com (Space Case) Cc: "Chris G. Demetriou" , current-users@sun-lamp.cs.berkeley.edu Subject: Re: fsck clears non-empty files <199405080422.AA20466@isumataq.eskimo.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I think I'll try an experiment. If I make a copy of a file, do a > clri on the copy, then reboot, the ensuing fsck should put it in > lost+found, right? NO; if you clear a file's inode, that file is GONE. period. if you clear a file's directory's inode, or otherwise get it into a state where it has no directory entry, THEN it goes into lost and found. blocks without inodes are not files. inodes without names are lost. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:15:44 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: NetBSD amiga? Cc: amiga@sun-lamp.cs.berkeley.edu From: Terminator rAT Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, all! I have an A3000 6M ram, 105+40M disk, ASDG LanRover that I want to run NetBSD on. How should I go about bootstrapping said machine? Thanks! -rAT O----O Email: rat@cs.orst.edu Work: (503)737-5567 Home: (503)737-9467 \oo/ Instructional Support Technical Maniac ==\/== "Got carried away...In my dreams you're so far away..." -Violet Arcana From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:16:44 1994 From: wormey@eskimo.com (Space Case) "Re: fsck clears non-empty files" (May 7, 9:32pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Chris G. Demetriou" Subject: Re: fsck clears non-empty files Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On May 7, 9:32pm, "Chris G. Demetriou" wrote: >if you clear a file's directory's inode, or otherwise get it into >a state where it has no directory entry, THEN it goes into lost >and found. OK, I got it to work as advertised. I'll have to examine the fsck error messages more closely to see why it is these files are being cleared. ~Steve -- Steven R. Allen - wormey@eskimo.com H. L. Mencken's Law: Those who can -- do. Those who can't -- teach. Martin's Extension: Those who cannot teach -- administrate. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:16:48 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Vnodes From: simonm Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi all, Does anyone know the proper way to create a filesystem on a vn device? Do I have to write an entry for disktab, and if so, what should it look like? Thanks for any help, Simon From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:18:20 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, sjg@zen.void.oz.au Subject: Re: anyone ported ofiles? Sender: owner-current-users@sun-lamp.cs.berkeley.edu fstat(8) `works for me'. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:22:27 1994 Subject: SNMP for -current? 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: 311 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have to manage a machine running quite recent -current (no, I'm not realy following current with that machine, but we couldn't stay at 0.9 for several reasons). This machine is located about 50 kilometers from here, so a remote management would be quite usefull. Has anybody done SNMP for -current? Martin From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:29:07 1994 From: wormey@eskimo.com (Space Case) "Re: fsck clears non-empty files" (May 7, 9:02pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Chris G. Demetriou" Subject: Re: fsck clears non-empty files Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On May 7, 9:02pm, "Chris G. Demetriou" wrote: > [I wrote:] >> When fsck does the filesystem check (either on boot or when run >> manually), and a non-empty file is not in a directory, fsck does >> not put it in lost+found, but rather clears it. This is contrary >> to both the documentation and what I have experienced on other >> systems. Is it really supposed to work this way? > >how old and large are the files? if they're recently-created, >relatively small files, it could very well be that their data just >never hit the disk... > >at various times in the past, i've had to clri various directories >inodes (dont' ask) and fsck always worked as i'd have expected it to >(i.e. it deposited things in lost and found). Generally, they are between 1K and 3K, but once, there was one that was about 33k. Then there was the time that had a bunch of files of various vintage go away. I would have liked to have checked them before they disappeared. I think I'll try an experiment. If I make a copy of a file, do a clri on the copy, then reboot, the ensuing fsck should put it in lost+found, right? ~Steve -- Steven R. Allen - wormey@eskimo.com What this country needs is a good five-cent nickel. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:42:45 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: wormey@eskimo.com (Space Case) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: fsck clears non-empty files <199405070308.AA00755@isumataq.eskimo.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > When fsck does the filesystem check (either on boot or when run > manually), and a non-empty file is not in a directory, fsck does > not put it in lost+found, but rather clears it. This is contrary > to both the documentation and what I have experienced on other > systems. Is it really supposed to work this way? how old and large are the files? if they're recently-created, relatively small files, it could very well be that their data just never hit the disk... at various times in the past, i've had to clri various directories inodes (dont' ask) and fsck always worked as i'd have expected it to (i.e. it deposited things in lost and found). cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 13:58:16 1994 From: Peter Galbavy Subject: EXABYTE problems have returned 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: 869 Sender: owner-current-users@sun-lamp.cs.berkeley.edu The problems I was having with a EXB-8500 last year have returned with the last kernel I built. The problem is that accessing the tape drive causes the scsi bus to hang. I can give no diags, 'cause of course the system couldn't write to the log file :( This was with a kernel of about the 25 April. My /sys/scsi/st.c file is dated around then, but I am not sure which came first, so I am recompiling my kernel with more recent sources at the moment, but does this look famuliar to anyone ? The tape drive worked before then, with the new scsi code... Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org +44 71 723 9947 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 Sun May 8 15:29:16 1994 From: "Chris G. Demetriou" X-Authentication-Warning: eden.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Michael Graff" Cc: Dave Burgess , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Patches for slattach(???) <199405071729.MAA00169@packrat.vorpal.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > While I like the baud set to 38400, the pid file is a bad idea mostly > because there can be more than one slattach running at any time on two > seperate ports. I do this once in a while for testing slip, for example. *chuckle* *i* see no reason to set change the default; odds are, most people will have to change it anyway... the pid file idea *is* a *wonderful* idea, but the implementation given is suboptimal, for the reason given. it should write out a 'slattach.%d', where the %d is the slip line number that it's attaching... chris From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 8 17:09:49 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, rat@cs.orst.edu Subject: Re: NetBSD amiga? Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Hi, all! I have an A3000 6M ram, 105+40M disk, ASDG LanRover that I want to > run NetBSD on. How should I go about bootstrapping said machine? Just as the FAQ (NetBSD.Install.744) says! :-) You can get it from ftp.uni-regensburg.de, look in /pub/NetBSD-Amiga/DOCS. Enjoy, 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 May 8 17:56:03 1994 From: Hubert Feyrer To: current-users@sun-lamp.cs.berkeley.edu, sjg@zen.void.oz.au Subject: Re: anyone ported ofiles? Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ofiles is a nifty tool by C. Spencer and various contributors, which > can display who has a particular file open. > > It is very useful to see which process is causing a filesystem to be > busy etc. Have you tried fstat? It does some of the things you suggestet, e.g. I can get get all the prcesses/fds I've open by typing "fstat -u hubert". Try 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-current-users@sun-lamp.cs.berkeley.edu Sun May 8 18:32:28 1994 From: Dave Burgess Subject: Re: Patches for slattach(???) To: explorer@vorpal.com (Michael Graff) Cc: current-users@sun-lamp.cs.berkeley.edu, explorer@vorpal.com X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 928 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > While I like the baud set to 38400, the pid file is a bad idea mostly > because there can be more than one slattach running at any time on two > seperate ports. I do this once in a while for testing slip, for example. > Actually, the 'IDEA' wasn't bad, but from the comments I've recevied (and the excellent suggestions about better ways to do it) I think that the patches are actually not a real great implementation. I still think that some kind of functionality like this would be a boon, but I need to think on how I need to implement it better. If I were to just say 'Nevermind', would anyone be upset? I will continue to add this functionality as a patch, but I will work on improving the implementation later. > >1. They add the functionality of creating a pid file. > >! #define PIDFILE "/var/run/slattach.pid" > >! #define DEFAULT_BAUD 38400 > In the mean time, I have to try and get a FAQ out. Dave From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 19:57:24 1994 From: Yeng-Chee Su Subject: PPP 2.1? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 594 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone installed PPP 2.1 on NetBSD-current? It seems the built-in ppp is still 2.0.4. When will the new PPP be included? -- ________________________________________________________________________ / National Chiao Tung University in Taiwan / \ | Name: Yeng-Chee Su Dept: Computer Engineering |__/ | Phone: +886-35-783513 E-mail: yenchee@csie.nctu.edu.tw | | Address: 22, Alley 2, Lane 173, Gao Tsui Road, HsinChu, Taiwan 300 |___ \______________________________________________________________________\__/ From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 8 21:10:19 1994 From: "Scott B. Anderson" Subject: Help with root file system corruption To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 259 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm running -current as of 2 days ago, and I get get a link count 14 should be 13; correct (y/n) ? You know the story...no matter how many times I tell it to fix it, or clear the 2 unreferenced files after it, it does nothing so far as I can tell. Scott From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 8 21:58:28 1994 Subject: panic: swfree 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 The file /sys/vm/vm_swap.c has changed substantially. It looks like the 4.3 BSD swapper functionality has been incorporated into the Mach VM system. One consequence of this is that swapinit() expects the swdevt array to be terminated differently than from before. The swapgeneric.c module does not do this properly. So, if you build a GENERIC kernel, you get panic: swfree. Alas, when I try to compile a non-GENERIC kernel, _swapconf is undefined. This is probably due to a dependency problem (I'd rather not make clean and spend 90 minutes building the kernel). -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 8 23:40:35 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Boot loader testers wanted" (May 7, 12:27pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tero.manninen@oulu.fi (Tero Manninen), amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD Amiga-Dev) Subject: Re: Boot loader testers wanted Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 7, 12:27pm, Tero Manninen wrote: > One thing.. I have only #744 kernel (the version before going to SUP) > and don't know if the loader works at all with newer kernels. I hear > that loadbsd has changed since then.. I fear that the bootloader is then only usable for a minority among us developers. As for me, i don't have #744 anywhere :-) And yes, loadbsd has changed heavily. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon May 9 00:05:31 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "gfx card drivers" (May 7, 12:40am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Donn Cave , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: gfx card drivers Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 7, 12:40am, Donn Cave wrote: > Subject: gfx card drivers > I won't ask if anyone's working on Spectrum or Piccolo support. But I > am curious if anyone has any sense of how cooperative their respective > manufacturers would be, if approached for hardware programming information? Picasso II, Spectrum and Picollo have all the same VGA-Chipset, which does not mean they address it the same way. At least i am sure Picasso doesn't address the chipset in the way Piccolo and Spectrum do. They have some magic on the board, hehe. > The Retina support code bears a little notice along these lines, that > makes it sound like this is a pretty sensitive matter. Was it easy to > get the dope on the Picasso card? (Maybe NetBSD looks pretty good to > 3rd party Amiga hardware manufacturers, these days.) It _is_ a sensible matter. Once full source-code for one of these cards is available, the others can rip the code and make it usuable for their cards. Retina hasn't had this problem - no competition. And ompetition among these three is heavy, at least in Germany. Me for myself got the sources for Picasso driver for AMIX and currently try to port this driver to NetBSD (Choops, when is the new console-stuff ready, i want to begin somedays...?). I am not allowed to distribute specific parts of the source, so i am obligued to distribute the stuff either as .o-Files or maybe as LKM. As for status of Picasso-driver: I am busy with some exams, sorry. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 01:29:51 1994 From: kim@dde.dk (Kim Andersen) Subject: Misc ramblings 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 all. (Maybe this should only have gone to the core team) 1. What are the current goals keeping version 1.0 from materialising ? Are we waiting for 4.4Lite and integration of this ? I see a lot of changes going on but find it hard to see where it is leading. 2. Would there be any idea in starting a repository of ported packages ? I guess most of the people using NetBSD want to have source for the things on their machine. At least thats my view. Some people out there probably lacks the resources in compiling/porting bigger packages, so it would be a nice service to provide. Anyone having the disk available to offer archiving ? Maybe iastate.edu ? regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 01:46:14 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, owner-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Misc ramblings Sender: owner-current-users@sun-lamp.cs.berkeley.edu 2. Would there be any idea in starting a repository of ported packages ? We have no problem with someone doing that, but it's not really worth our time to. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 01:58:35 1994 From: deraadt@fsa.ca (Theo Deraadt) To: current-users@sun-lamp.cs.berkeley.edu, kim@dde.dk Subject: Re: Misc ramblings Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 2. Would there be any idea in starting a repository of ported packages ? My view is that, if anyone makes some changes to make a package run under NetBSD, that they send those changes back to the original author of the package, for reintegration in the next release of that package. A few have already been done: some gnu stuff, xntp, tcsh, just to name a few. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 9 03:10:06 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: panic: swfree To: dej@eecg.toronto.edu (David Jones) Cc: 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: 2047 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > The file /sys/vm/vm_swap.c has changed substantially. It looks like the > 4.3 BSD swapper functionality has been incorporated into the Mach VM > system. > > One consequence of this is that swapinit() expects the swdevt array to > be terminated differently than from before. The swapgeneric.c module > does not do this properly. So, if you build a GENERIC kernel, you get > panic: swfree. This is what I patched on my sources to get back going again: *** ./arch/amiga/amiga/swapgeneric.c-orig Fri Apr 22 03:13:20 1994 --- ./arch/amiga/amiga/swapgeneric.c Sat May 7 20:06:07 1994 *************** *** 53,60 **** dev_t dumpdev = NODEV; int nswap; struct swdevt swdevt[] = { ! { -1, 1, 0 }, ! { 0, 0, 0 }, }; int dmmin, dmmax, dmtext; --- 53,60 ---- dev_t dumpdev = NODEV; int nswap; struct swdevt swdevt[] = { ! { NODEV, SW_FREED, 0 }, ! { NODEV, 0, 0 }, }; int dmmin, dmmax, dmtext; *** ./arch/amiga/amiga/autoconf.c-orig Fri Apr 22 03:13:19 1994 --- ./arch/amiga/amiga/autoconf.c Sat May 7 20:16:25 1994 *************** *** 951,957 **** register struct swdevt *swp; register int nblks; ! for (swp = swdevt; swp->sw_dev; swp++) { if (bdevsw[major(swp->sw_dev)].d_psize) { nblks = bdevsw[major(swp->sw_dev)].d_psize(swp->sw_dev); --- 951,957 ---- register struct swdevt *swp; register int nblks; ! for (swp = swdevt; swp->sw_dev != NODEV; swp++) { if (bdevsw[major(swp->sw_dev)].d_psize) { nblks = bdevsw[major(swp->sw_dev)].d_psize(swp->sw_dev); *************** *** 1094,1100 **** #ifdef DOSWAP mindev &= ~PARTITIONMASK; ! for (swp = swdevt; swp->sw_dev; swp++) { if (majdev == major(swp->sw_dev) && mindev == (minor(swp->sw_dev) & ~PARTITIONMASK)) { temp = swdevt[0].sw_dev; --- 1094,1100 ---- #ifdef DOSWAP mindev &= ~PARTITIONMASK; ! for (swp = swdevt; swp->sw_dev != NODEV; swp++) { if (majdev == major(swp->sw_dev) && mindev == (minor(swp->sw_dev) & ~PARTITIONMASK)) { temp = swdevt[0].sw_dev; From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 03:52:39 1994 From: Alan Pearson Subject: Re: Misc ramblings 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: 1365 Sender: owner-current-users@sun-lamp.cs.berkeley.edu deraadt@sf.ca wrote: > kim@dde.dk wrote > > 2. Would there be any idea in starting a repository of ported packages ? > > My view is that, if anyone makes some changes to make a package > run under NetBSD, that they send those changes back to the > original author of the package, for reintegration in the next > release of that package. > I second that opinion. I don't personally like the idea of maintaining a separate "ports" archive because it presents a hinderance to keeping NetBSD software up-to-date. Say, for example, that someone ports tcsh 6.01 to NetBSD, and puts the software in some NetBSD ports archive. Then a new version is released. The porting has to be done again. Also, I think there is a opinion that FreeBSD, NetBSD and Linux are not "real" unix among the DEC/SGI/Sun crowds, since it runs on PC's not workstations. Keeping our stuff seperate can't help but reinforce that. But kim's original point was that there should be a repository for NetBSD binaries of ported software. That would be a convenience for people who don't want to compile stuff themselvs (or don't know how), but for small packages, I don't think it is necessary. Now for big stuff, like XFree86 it is, but that kind of thing is already packaged in binary form. -- alan pearson alanp@cory.eecs.berkeley.edu UC Berkeley EECS From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 03:55:50 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: Misc ramblings Sender: owner-current-users@sun-lamp.cs.berkeley.edu >My view is that, if anyone makes some changes to make a package >run under NetBSD, that they send those changes back to the >original author of the package, for reintegration in the next >release of that package. > >A few have already been done: some gnu stuff, xntp, tcsh, just >to name a few. in which case some care has to be taken to account for differences. eg with sendmail 8.6.9 I had to make two changes to the distribution NetBSD build to get it to work on a plain 0.9: POSIX_CHOWN_RESTRICTED to 1 in and -LDADD= -lutil in makefile but I haven't reported these back to Eric 8-). With changes these trivial, just a note in the makefile is probably adequate. Anyway I'd be interested in some discussion of Kim's first point: >1. What are the current goals keeping version 1.0 from materialising ? > Are we waiting for 4.4Lite and integration of this ? > I see a lot of changes going on but find it hard to see where it > is leading. I run two NetBSD 0.9 systems, one in production so I've never had the feeling that any particular time was good to grab a reasonably stable version, say a stage roughly at the 0.95 beta level. At least my IDE hangs are reasonably predictable that I can tolerate, but I would like to repartition and install X11 which would be best done with a system upgrade. A brief roadmap if not a timeframe would be useful. As a specific question, will 4.4s immutable file capability be inherited? cheers, Danny Thomas From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 03:59:18 1994 From: Mark_Weaver@brown.edu To: Kaleb Keithley Cc: Bakul Shah , current-users@sun-lamp.cs.berkeley.edu, rich@lamprey.utmb.edu Subject: Re: X11R6 is not ready for FreeBSD yet <9405041359.AA01291@kanga.x.org> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > X11R6 nominally supports NetBSD 0.9 -- period! If NetBSD-current is > as far ahead of 0.9 as freebsd-current is ahead of 1.1, then you're > talking about apples and oranges. Building (or failing to build) on > -current is not a fair test by any stretch of the imagination. The X > Consortium would be happy to hear about any problems (in the form of > bug-reports) in R6 built against 0.9. It would probably be a wise idea > to cc: the XFree86 project as well. > > I should mention that it is our policy that we only support the OS > versions that are offically released at the time of our release, so 1.0, > -current, -whatever will never be offically supported until R7 ships. I don't believe that much of the NetBSD-specific support made it into the R6 core release. However, the stuff that the XFree86 team submitted was completely compatible with NetBSD-current as of late March. In fact, I don't even know if we got a chance to test it for NetBSD-0.9; I certainly didn't. 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 May 9 05:34:26 1994 From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: whoami(1) removed? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Why was whoami(1) removed? 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 May 9 06:48:15 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: whoami(1) removed? <199405090145.VAA00593@cis-ts3-slip4.cis.brown.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Why was whoami(1) removed? good to see you bothered looking around the source tree before you sent mail! look in usr.bin/id cgd From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 07:45:58 1994 From: hcchu@r350.ee.ntu.edu.tw (Hung-Chi Chu) To: Mark_Weaver@brown.edu Subject: Re: whoami(1) removed? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 10:39:57 1994 > Date: Sun, 8 May 1994 21:45:14 -0400 > From: Mark_Weaver@brown.edu > To: current-users@sun-lamp.cs.berkeley.edu > Subject: whoami(1) removed? > Reply-To: Mark_Weaver@brown.edu > Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Content-Length: 227 > > Why was whoami(1) removed? > No. It was replaced by /usr/src/usr.bin/id/whoami.sh From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon May 9 13:14:13 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: kallio@jyu.fi (Seppo Kallio) Cc: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: Linux Documentation Project Home Page <199405090733.AA18152@tukki.jyu.fi> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > Could the "profile" of netbsd be a little higher? Why doesn't NetBSD have a > group in the Usenet News? Why only mailing lists? What about WWW page? Or > Gopher database? "Why thank you for volunteering to do all of this!" actually, there's already gopher access on sun-lamp, but more or less none of the rest. cgd From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon May 9 13:15:48 1994 X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: netbsd-users@sun-lamp.cs.berkeley.edu From: kallio@jyu.fi (Seppo Kallio) Subject: Linux Documentation Project Home Page Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi Could the "profile" of netbsd be a little higher? Why doesn't NetBSD have a group in the Usenet News? Why only mailing lists? What about WWW page? Or Gopher database? Seppo >From: mdw@cs.cornell.edu (Matt Welsh) >To: Multiple recipients of list >Subject: Linux Documentation Project Home Page >X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas >Status: U > >The Linux Documentation Project, a group of volunteer writers documenting >the Linux operating system, now has a home page on the World Wide >Web. The URL is http://sunsite.unc.edu/mdw/linux.html. It contains >pointers to other Linux-related home pages, the contents of the LDP >document archives, HTML formats of various Linux documents, and more. > >Matt Welsh, mdw@cs.cornell.edu From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 13:39:17 1994 From: kim@dde.dk (Kim Andersen) Subject: Re:Misc ramblings To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu kim>> 2. Would there be any idea in starting a repository of ported packages ? Charles>> We have no problem with someone doing that, but it's not really worth Charles>> our time to. It wasn't my intention that the core should be doing this. Maybe this part should have been directed to non-core members. Theo>> My view is that, if anyone makes some changes to make a package Theo>> run under NetBSD, that they send those changes back to the Theo>> original author of the package, for reintegration in the next Theo>> release of that package. I fully agree. alanp>> But kim's original point was that there should be a repository for NetBSD alanp>> binaries of ported software. That would be a convenience for people who alanp>> don't want to compile stuff themselvs (or don't know how), but for small alanp>> packages, I don't think it is necessary. Yes this was what I meant. I better start thinking before writing. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 13:39:19 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Scott B. Anderson" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Help with root file system corruption <199405081724.KAA07373@sun-lamp.cs.berkeley.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm running -current as of 2 days ago, and I get get a > link count 14 should be 13; correct (y/n) ? > You know the story...no matter how many times I tell it > to fix it, or clear the 2 unreferenced files after it, > it does nothing so far as I can tell. what do you do *after* you fix it, or clear the 2 unreferenced files after it? if it's your root file system, you should probably 'reboot -n' cgd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 9 14:09:33 1994 From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Subject: NetBSD DAT tape problems To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2546 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, Recently I wanted to try a DAT drive to make a backup of my current NetBSD-Amiga setup, so I booted up NetBSD with the tapedrive attached and turned on. However, when booting I get a kernel trap with the 940417 kernel from sun-lamp/net-1 (which I run). I have tried both the newer 940427 kernel and the experimental Warp+IDE kernel, but both of these do (more or less, I'll come back to that later) the same thing. As an aside, why is the (newer, updated?) 940427 kernel so big? Also, running vmstat with this kernel gives some weird error messages about some _vmstat_blahblag functions bot being in the kernel? OK, my system is: A4000/040, 8MB Fast, GVP series II scsi with a DEC DSP3133LS at id 0 and an external WangDAT 3400DX at id 5. Also a Seacrate st1144a is connected to the internal IDE (For Linux :). No other hardware connected. The WangDAT works like a champ under AmigaOS. Now for the boot-up messages I get: --------------------------------------------------------------------------- everything goes pretty normal... .... GVPIIscsi0 [2017/11] sd0: DEC DSP3133LS rev 440E, 2613530 512 byte blocks sd0 at GVPIIscsi0, slave 0 st0: WangDAT Model 3400DX rev 1.10 st0: Unsupported tape device, using GENERIC panic: kernel jump to zero hit any key to boot/dump > [I press enter] trap: bad kernel access at 2 trap type 8, code = 4c5, v=2 pid=0, pc=00000dae, ps=2004, sfc=0001, dfc=0001 registers: etc, etc. blah blah Kernel stack dump: blah blah panic: MMU fault hit any key to boot/dump > ad infinitum, until the keyboard locks up, then it's ye good olde three-fingered salute... --------------------------------------------------------------------------- I have tried patching the _st_pretend_tobe_mt variable to about every possible value (as per the README.vmunix.tapeII doc), but it still fails with exactly the same messages. Like I mentioned, I've tried other kernels: the 940427 sun-lamp one and the Warp + IDE test kernel from Michael Hitch I found at ftp.coe.montana.edu (which probably would have had other problems since I also have an IDE disk connected (IDE sd0 <-> SCSI sd0). Anyhow, this last one also failed but this time it jumped into some sort of boot-monitor, which I didn't quite understand... :) My guess is something goes very wrong when the kernel finds a tape device it doesn't recognize; it seems to jump to some bogus address... If anyone has any ideas, or if you need more info, let me know... I would very much like to backup NetBSD, before something goes very wrong... :) Regards, Patrick. TAPE Digest ****************** ------- From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 17:04:56 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 doc/CHANGES U src/bin/ps/Makefile U src/bin/ps/devname.c U src/bin/ps/extern.h U src/bin/ps/fmt.c U src/bin/ps/keyword.c U src/bin/ps/nlist.c U src/bin/ps/print.c U src/bin/ps/ps.1 U src/bin/ps/ps.c U src/bin/ps/ps.h U src/include/kvm.h U src/include/paths.h U src/include/stdlib.h U src/include/unistd.h U src/lib/libc/shlib_version U src/lib/libc/compat-43/Makefile.inc U src/lib/libc/compat-43/gethostid.3 U src/lib/libc/compat-43/gethostid.c U src/lib/libc/compat-43/sethostid.c U src/lib/libc/gen/Makefile.inc U src/lib/libc/gen/getdomainname.3 U src/lib/libc/gen/getdomainname.c U src/lib/libc/gen/gethostname.3 U src/lib/libc/gen/gethostname.c U src/lib/libc/gen/getloadavg.3 U src/lib/libc/gen/getloadavg.c U src/lib/libc/gen/getpagesize.3 U src/lib/libc/gen/getpagesize.c U src/lib/libc/gen/nlist.3 U src/lib/libc/gen/nlist.c U src/lib/libc/gen/popen.3 U src/lib/libc/gen/popen.c U src/lib/libc/gen/setdomainname.c U src/lib/libc/gen/sethostname.c U src/lib/libc/gen/sysconf.3 U src/lib/libc/gen/sysconf.c U src/lib/libc/gen/sysctl.3 U src/lib/libc/gen/sysctl.c U src/lib/libc/gen/uname.3 U src/lib/libc/gen/uname.c U src/lib/libc/sys/Makefile.inc U src/lib/libc/sys/mlock.2 U src/lib/libc/sys/pathconf.2 U src/lib/libc/sys/revoke.2 U src/lib/libc/sys/sigaltstack.2 U src/lib/libkvm/Makefile U src/lib/libkvm/kvm.3 U src/lib/libkvm/kvm.c U src/lib/libkvm/kvm_file.c U src/lib/libkvm/kvm_geterr.3 U src/lib/libkvm/kvm_getfiles.3 U src/lib/libkvm/kvm_getloadavg.3 U src/lib/libkvm/kvm_getloadavg.c U src/lib/libkvm/kvm_getprocs.3 U src/lib/libkvm/kvm_i386.c U src/lib/libkvm/kvm_m68k.c U src/lib/libkvm/kvm_mips.c U src/lib/libkvm/kvm_nlist.3 U src/lib/libkvm/kvm_open.3 U src/lib/libkvm/kvm_private.h U src/lib/libkvm/kvm_proc.c U src/lib/libkvm/kvm_read.3 U src/lib/libkvm/kvm_sparc.c U src/lib/libkvm/shlib_version U src/sys/arch/amiga/Makefile U src/sys/arch/amiga/amiga/adosglue.h U src/sys/arch/amiga/amiga/amiga_init.c U src/sys/arch/amiga/amiga/autoconf.c U src/sys/arch/amiga/amiga/cfdev.h U src/sys/arch/amiga/amiga/cia.c U src/sys/arch/amiga/amiga/conf.c U src/sys/arch/amiga/amiga/device.h U src/sys/arch/amiga/amiga/disksubr.c U src/sys/arch/amiga/amiga/genassym.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/amiga/pmap.c U src/sys/arch/amiga/amiga/swapgeneric.c U src/sys/arch/amiga/amiga/trap.c U src/sys/arch/amiga/amiga/vectors.s U src/sys/arch/amiga/amiga/vm_machdep.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/conf/Makefile.amiga U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/conf/std.amiga U src/sys/arch/amiga/dev/ahsc.c U src/sys/arch/amiga/dev/ahscreg.h U src/sys/arch/amiga/dev/atzsc.c U src/sys/arch/amiga/dev/atzscreg.h U src/sys/arch/amiga/dev/clock.c U src/sys/arch/amiga/dev/clockioctl.h U src/sys/arch/amiga/dev/dmavar.h U src/sys/arch/amiga/dev/grf.c U src/sys/arch/amiga/dev/grf_cc.c U src/sys/arch/amiga/dev/grf_ccreg.h U src/sys/arch/amiga/dev/grf_rt.c U src/sys/arch/amiga/dev/grf_rtreg.h U src/sys/arch/amiga/dev/grfabs.c U src/sys/arch/amiga/dev/grfvar.h U src/sys/arch/amiga/dev/gtsc.c U src/sys/arch/amiga/dev/gtscreg.h U src/sys/arch/amiga/dev/gvpbus.c U src/sys/arch/amiga/dev/gvpbusvar.h U src/sys/arch/amiga/dev/ite.c U src/sys/arch/amiga/dev/ite_cc.c U src/sys/arch/amiga/dev/ite_rt.c U src/sys/arch/amiga/dev/itevar.h U src/sys/arch/amiga/dev/ivsc.c U src/sys/arch/amiga/dev/kbd.c U src/sys/arch/amiga/dev/kf_8x11.c U src/sys/arch/amiga/dev/kf_8x8.c U src/sys/arch/amiga/dev/mgnsc.c U src/sys/arch/amiga/dev/mlhsc.c U src/sys/arch/amiga/dev/ms.c U src/sys/arch/amiga/dev/otgsc.c U src/sys/arch/amiga/dev/par.c U src/sys/arch/amiga/dev/rtc.h U src/sys/arch/amiga/dev/rtmondefs.c U src/sys/arch/amiga/dev/rtmons U src/sys/arch/amiga/dev/sbic.c U src/sys/arch/amiga/dev/sbicreg.h U src/sys/arch/amiga/dev/sbicvar.h U src/sys/arch/amiga/dev/sci.c U src/sys/arch/amiga/dev/scivar.h U src/sys/arch/amiga/dev/sd.c U src/sys/arch/amiga/dev/ser.c U src/sys/arch/amiga/dev/serreg.h U src/sys/arch/amiga/dev/siop.c U src/sys/arch/amiga/dev/view.c U src/sys/arch/amiga/dev/wstsc.c U src/sys/arch/amiga/dev/zssc.c U src/sys/arch/amiga/dev/ztwobus.c U src/sys/arch/amiga/dev/ztwobusvar.h U src/sys/arch/amiga/include/cpu.h U src/sys/arch/amiga/include/disklabel.h U src/sys/arch/amiga/include/param.h U src/sys/arch/amiga/include/proc.h U src/sys/arch/amiga/include/pte.h U src/sys/arch/hp300/hp300/machdep.c U src/sys/arch/hp300/hp300/trap.c U src/sys/arch/hp300/include/cpu.h U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/include/cpu.h U src/sys/arch/i386/include/limits.h U src/sys/arch/sparc/sbus/cgsix.c U src/sys/arch/sparc/sbus/cgsixreg.h U src/sys/arch/sparc/sparc/cpu.c U src/sys/arch/sparc/sparc/machdep.c U src/sys/arch/sparc/sparc/trap.c U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/trap.c U src/sys/compat/sunos/sun_syscall.h U src/sys/compat/sunos/sun_syscalls.c U src/sys/compat/sunos/sun_sysent.c U src/sys/compat/sunos/syscalls.master U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/isofs/isofs_util.c U src/sys/kern/init_sysent.c U src/sys/kern/kern_clock.c U src/sys/kern/kern_descrip.c U src/sys/kern/kern_exec.c U src/sys/kern/kern_prot.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_synch.c U src/sys/kern/kern_xxx.c U src/sys/kern/subr_prof.c U src/sys/kern/sys_generic.c U src/sys/kern/sys_process.c U src/sys/kern/syscalls.c U src/sys/kern/syscalls.master U src/sys/kern/uipc_domain.c U src/sys/kern/vfs_subr.c U src/sys/kern/vfs_syscalls.c U src/sys/lib/libsa/Makefile U src/sys/lib/libsa/arp.c U src/sys/lib/libsa/bootp.c U src/sys/lib/libsa/bootp.h U src/sys/lib/libsa/close.c U src/sys/lib/libsa/ether.c U src/sys/lib/libsa/exec.c U src/sys/lib/libsa/exit.c U src/sys/lib/libsa/globals.c U src/sys/lib/libsa/in_cksum.c U src/sys/lib/libsa/ioctl.c U src/sys/lib/libsa/iodesc.h U src/sys/lib/libsa/net.c U src/sys/lib/libsa/net.h U src/sys/lib/libsa/netif.c U src/sys/lib/libsa/netif.h U src/sys/lib/libsa/nfs.c U src/sys/lib/libsa/nfs.h U src/sys/lib/libsa/open.c U src/sys/lib/libsa/rarp.c U src/sys/lib/libsa/rpc.c U src/sys/lib/libsa/rpc.h U src/sys/lib/libsa/stand.h U src/sys/miscfs/procfs/procfs_ctl.c U src/sys/net/if_ppp.c U src/sys/net/if_ppp.h U src/sys/net/rtsock.c U src/sys/net/slcompress.c U src/sys/net/slcompress.h U src/sys/scsi/cd.c U src/sys/scsi/scsi_all.h U src/sys/scsi/scsi_base.c U src/sys/scsi/sd.c U src/sys/scsi/st.c U src/sys/sys/dirent.h U src/sys/sys/disklabel.h U src/sys/sys/signal.h U src/sys/sys/signalvar.h U src/sys/sys/syscall.h U src/sys/sys/types.h U src/sys/sys/unistd.h U src/sys/sys/user.h U src/sys/vm/vm_meter.c U src/sys/vm/vm_mmap.c U src/usr.bin/fstat/Makefile U src/usr.bin/fstat/fstat.1 U src/usr.bin/fstat/fstat.c U src/usr.bin/mail/def.h U src/usr.bin/make/Makefile.boot U src/usr.bin/make/make.h U src/usr.bin/make/util.c U src/usr.bin/make/lst.lib/Makefile U src/usr.bin/telnet/commands.c U src/usr.bin/w/Makefile U src/usr.bin/w/extern.h U src/usr.bin/w/pr_time.c U src/usr.bin/w/proc_compare.c U src/usr.bin/w/uptime.1 U src/usr.bin/w/w.1 U src/usr.bin/w/w.c U src/usr.sbin/Makefile U src/usr.sbin/mrouted/defs.h U src/usr.sbin/mrouted/dvmrp.h U src/usr.sbin/mrouted/main.c U src/usr.sbin/mrouted/route.c U src/usr.sbin/mrouted/mrinfo/mrinfo.c U src/usr.sbin/pppd/Makefile U src/usr.sbin/pppd/auth.c U src/usr.sbin/pppd/chap.c U src/usr.sbin/pppd/chap.h U src/usr.sbin/pppd/fsm.c U src/usr.sbin/pppd/fsm.h U src/usr.sbin/pppd/ipcp.c U src/usr.sbin/pppd/ipcp.h U src/usr.sbin/pppd/lcp.c U src/usr.sbin/pppd/lcp.h U src/usr.sbin/pppd/main.c U src/usr.sbin/pppd/options.c U src/usr.sbin/pppd/patchlevel.h U src/usr.sbin/pppd/pathnames.h U src/usr.sbin/pppd/pppd.8 U src/usr.sbin/pppd/pppd.h U src/usr.sbin/pppd/sys-bsd.c U src/usr.sbin/pppd/upap.c U src/usr.sbin/pppd/upap.h U src/usr.sbin/pppd/pppstats/pppstats.c U src/usr.sbin/sysctl/Makefile U src/usr.sbin/sysctl/pathconf.c U src/usr.sbin/sysctl/sysctl.8 U src/usr.sbin/sysctl/sysctl.c Running the SUP scanner: SUP Scan for current starting at Mon May 9 03:57:08 1994 SUP Scan for current completed at Mon May 9 04:01:10 1994 SUP Scan for mirror starting at Mon May 9 04:01:11 1994 SUP Scan for mirror completed at Mon May 9 04:05:26 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 9 17:13:10 1994 From: Scott Anderson Subject: Re: Help with root file system corruption To: cgd@postgres.berkeley.edu (Chris G. Demetriou) 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: 479 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > if it's your root file system, you should probably 'reboot -n' > > cgd > I always reboot with shutdown -r. I would assume this is the proper thing to do. As for the suggestions I received, booting off of floppy and doing the fsck from there with the root hard drive not mounted it was the correct answer. Apparently no matter how you sync after the fsck, you can not fix such problems on your root file system without unmounting it first. (booting off of floppy). Scott From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon May 9 18:21:33 1994 From: Hubert Feyrer To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: Linux Documentation Project Home Page Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > Could the "profile" of netbsd be a little higher? Why doesn't NetBSD have a > group in the Usenet News? Why only mailing lists? What about WWW page? Or > Gopher database? Check out the NetBSD-Amiga-part of the following page: http://dusk.rz.uni-regensburg.de Enjoy, 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 Mon May 9 20:39:56 1994 To: Scott Anderson Cc: cgd@postgres.berkeley.edu (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Help with root file system corruption <199405091244.HAA12675@rush.cc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <797.768498864.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > if it's your root file system, you should probably 'reboot -n' > > I always reboot with shutdown -r. I would assume this is the > proper thing to do. Unfortunately, in this case it is not. > As for the suggestions I received, booting off of floppy and > doing the fsck from there with the root hard drive not mounted > it was the correct answer. Apparently no matter how you sync > after the fsck, you can not fix such problems on your root file > system without unmounting it first. (booting off of floppy). If you fsck a mounted root file system, the important thing is to NOT sync. That is what you do with 'reboot -n', reboot without doing a sync first... 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-dev@sun-lamp.cs.berkeley.edu Mon May 9 21:52:58 1994 From: Danny Lepage Subject: m4: does'nt handle filename "-" ??? To: amiga-dev@sun-lamp.cs.berkeley.edu 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 I'm porting piewm to NetBSD but I came across a little problem. m4 does'nt handle "-" as filename (standard input, as in "tar xvfp -"). Is it a known bug? If I decide to get m4 sources from sun-lamp, and patch it, what is the proper procedure to upload the patch? BTW, if there is enough interest, I'll upload a compiled version of piewm and its man pages (as soon as I can get it to work correctly. piewm run ok except that it don't process the .piewmrc (or any rc) properly because of the above bug with m4). Danny Lepage From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 9 22:20:49 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: NetBSD DAT tape problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 9, 10:51am, Patrick Vervoorn wrote: > Like I mentioned, I've tried other kernels: the 940427 sun-lamp one and the > Warp + IDE test kernel from Michael Hitch I found at ftp.coe.montana.edu > (which probably would have had other problems since I also have an IDE disk > connected (IDE sd0 <-> SCSI sd0). Anyhow, this last one also failed but > this time it jumped into some sort of boot-monitor, which I didn't quite > understand... :) My kernel is compiled with the debugger. If you add the -S option to loadbsd, the kernel symbols should be available to the debugger. Then when your system panics, you can enter the command "trace" and get a stack trace. This should show what routines had been called at that point. That should give a clue as to what is going on. > My guess is something goes very wrong when the kernel finds a tape device > it doesn't recognize; it seems to jump to some bogus address... I suspect it's trying to call a routine that hasn't been set up yet, so the address is NULL. I can't think of any thing in the tape driver that should cause that. > If anyone has any ideas, or if you need more info, let me know... I would > very much like to backup NetBSD, before something goes very wrong... :) One problem with the "GENERIC" tape handling now is that it assumes a 512-byte fixed length record, so it can't handle variable length record devices. The stack trace back with symbols should give me a good idea of what is happening, so give that a try. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 10 00:51:56 1994 From: Hubert Feyrer Subject: Xretina & pixmap depth To: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1100 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Lately I had the chance to test a Retina under NetBSD. When I wanted to display a picture from a remote machine on the Xretina, I got the following error: rrzc1a% setenv DISPLAY dusk:0.0 rrzc1a% xl -onroot -fullscreen seashore.gif seashore.gif is a 640x480 GIF image with 256 colors Zooming image by 160%...done Merging...done Converting true color image to RGB image with 64 colors...image uses 241 colors...done Building XImage...bitsPerPixelAtDepth: Can't find pixmap depth info! Dusk is the Xretina-machine, rrzc1 the remote one. Has anyone seen this bug? (I just wanted to report the bug, I don't have the retina any more to bother with 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-current-users@sun-lamp.cs.berkeley.edu Tue May 10 01:11:18 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: libm with i387 support? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I uncommented the parts in libm/Makefile which should cause libm to be built with i387 support, but make still insists on using the generic .c files. Has anyone else noticed this, or is something odd with my configuration? --M From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 01:11:57 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: libm and i387 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ooops, sorry. I had an old .depend around, which told make to do what I thought was wrong. As soon as I rm'd that, it worked. *blush* From owner-amiga-x@sun-lamp.cs.berkeley.edu Tue May 10 01:28:28 1994 From: Donn Cave X-Sender: donn@homer06.u.washington.edu Subject: Re: gfx card drivers To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: donn@u.washington.edu, amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1708 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 8, 11:12PM, Markus Illenseer wrote: (quoting from me) |> The Retina support code bears a little notice along these lines, that |> makes it sound like this is a pretty sensitive matter. Was it easy to |> get the dope on the Picasso card? (Maybe NetBSD looks pretty good to |> 3rd party Amiga hardware manufacturers, these days.) | | It _is_ a sensible matter. Once full source-code for one of these | cards is available, the others can rip the code and make it usuable | for their cards. Retina hasn't had this problem - no competition. | And ompetition among these three is heavy, at least in Germany. I asked about this on the Piccolo mailing list, and while I haven't gotten any authoritative response, I thought people would be interested to hear that ``several NetBSD people have already said that they would write a driver for the GVP Spectrum.'' (Just for the record, let me say it too: I will write a driver for the GVP Spectrum! Might take a while, though, especially if I don't get around to buying the card, as I probably won't. Ask me how it's going, next millenium. Anyway, they sound like good hardware for AmigaDOS.) | Me for myself got the sources for Picasso driver for AMIX and currently | try to port this driver to NetBSD (Chopps, when is the new console-stuff | ready, i want to begin somedays...?). I am not allowed to distribute | specific parts of the source, so i am obligued to distribute the stuff | either as .o-Files or maybe as LKM. Hope it goes well. If the whole source can't be made available, I hope you don't someday get the urge to move to Nepal or something. Eat nutritious food, drive slow on the Autobahn, etc. Donn Cave, donn@cac.washington.edu From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 01:40:57 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: libm and i387 X-Sun-Charset: US-ASCII Content-Length: 1437 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Ooops, sorry. I had an old .depend around, which told make to do what I > thought was wrong. As soon as I rm'd that, it worked. *blush* Some good safety tips: Never be afraid to do a "make depend" on every thing. Sure it takes an hour or two. Just run it overnight. What's waiting an extra day or 1/2 a day to avoid loosing an evening chasing dumb problems. (On my machine, make depend only takes a couple of hours). Anytime I sup I do this...and of course more limited bits can be done when you change specific subsystems that you know the scope of...you hope. Also, log your make output and review it before installing...you never know what you'll find. Finally, log and review your sup output. For instance, with things like groups and whoami being moved and whole directories going away you often have to do some manual cleanup (sup can't blow away and doesn't clean up seperate obj dirs or object files for instance). Also think a little rationally. I noticed right away that "whoami" was deleted. At first I thought "What on earth"....then realized, something like that isn't going to be summarily deleted or broken (intentionally at least ;-). A quick review of the sup output (I always run -v into a log file) found the answer without even a "find -name " needed... Just remember... " |& tee blech" or " | tee blech 2>&1" if you like to watch but still want a log file...almost always worth the trouble. -Mark From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 10 02:22:26 1994 From: Hubert Feyrer Subject: Networking-FAQ available NOW! To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1547 Sender: owner-amiga@sun-lamp.cs.berkeley.edu ANNOUNCE The "NetBSD-Amiga Beginner's Guide to TCP/IP Networking ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ and Networking-FAQ" ~~~~~~~~~~~~~~~~~~~ has finally been released! It's available from ftp.uni-regensburg.de in /pub/NetBSD-Amiga/DOCS/Networking-FAQ. Available versions are: * Texinfo-source (nwf.ti) * DVI-File (nwf.dvi) * PostScript (nwf.ps, pic1.ps, pic2.ps) * Info-format (nwf.info*) * Plain ASCII (nwf.txt, pic1.txt, pic2.txt) * HTML (nwf.html, nwf_toc.html) The HTML-version is also reachable via WWW: http://dusk.rz.uni-regensburg.de/Personal/hubert/NetBSD/NWF/nwf_toc.html This should be enough versions to fit everyone's needs. ;-) If someone wants to recreate the above versions from scratch, the Makefile, a self-written script and texi2html have also been put onto the FTP-Server. A simple "make all" should rebuild all. Please email any comments, etc. to hubert.feyrer@rz.uni-regensburg.de. P.S.: I'm still searching for someone to tell me how to include a Encapsulated PostScript-file into a texinfo-document. =============== 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 May 10 02:54:34 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@erewhon.CS.Berkeley.EDU X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: SysV Shared Memory X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu SysV Shared Memory is No More; it was considered 'contaminated' by USL code, etc., etc., etc. A replacement is in the works, but it's not quite finished, nor well tested; you'll see an announcement when it's ready for widespread testing. Sorry for the inconvenience. cgd From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 10 04:28:45 1994 To: Hubert Feyrer Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD amiga? <9405081351.AA08996@rrzc1.rz.uni-regensburg.de> From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu In message <9405081351.AA08996@rrzc1.rz.uni-regensburg.de>, Hubert Feyrer writes: > >> Hi, all! I have an A3000 6M ram, 105+40M disk, ASDG LanRover that I want to >> run NetBSD on. How should I go about bootstrapping said machine? > >Just as the FAQ (NetBSD.Install.744) says! :-) Do you mean to imply that the ASDG LanRover is supported? Does anyone know for certain whether this card is supported? Your FAQ mentions only the Ameristar and A2065 boards. -wps From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 04:54:47 1994 To: "Chris G. Demetriou" Cc: cgd@erewhon.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: SysV Shared Memory <199405092252.PAA23869@erewhon.CS.Berkeley.EDU> From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu >SysV Shared Memory is No More; it was considered 'contaminated' by >USL code, etc., etc., etc. is this semaphores and message queues as well, or just shared memory ? (ie, sysv ipc is gone) From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 05:02:03 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: matthew green Cc: cgd@postgres.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: SysV Shared Memory <199405100052.KAA04987@circlip.mame.mu.OZ.AU> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > >SysV Shared Memory is No More; it was considered 'contaminated' by > >USL code, etc., etc., etc. > > is this semaphores and message queues as well, or just shared > memory ? (ie, sysv ipc is gone) just shared memory. I'll be providing a replacement implementation sometime this week. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 05:07:42 1994 From: Mark_Weaver@brown.edu To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: libm and i387 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Ooops, sorry. I had an old .depend around, which told make to do what I > > thought was wrong. As soon as I rm'd that, it worked. *blush* > > Some good safety tips: > > Never be afraid to do a "make depend" on every thing. [...] In fact, "make depend" doesn't even always fix it, because it only remakes .depend if one of the local source files has changed. If a new "#include" is added to a system header file, you really need to remove all the .depend files explicitly. 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 Tue May 10 05:22:51 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, vervoorn@dutiws.TWI.TUDelft.NL Subject: Re: NetBSD DAT tape problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) > As an aside, why is the (newer, updated?) 940427 kernel so big? Because it includes support for everything.... It will only get larger as time goes on.... :-) -SR From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 05:56:08 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: matthew green Cc: "Chris G. Demetriou" , cgd@erewhon.CS.Berkeley.EDU, current-users@sun-lamp.cs.berkeley.edu Subject: Re: SysV Shared Memory <199405100052.KAA04987@circlip.mame.mu.OZ.AU> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >SysV Shared Memory is No More; it was considered 'contaminated' by > >USL code, etc., etc., etc. > > is this semaphores and message queues as well, or just shared > memory ? (ie, sysv ipc is gone) *just* sysv shared memory. It will be replaced, hopefully within the next few weeks. cgd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 10 07:00:35 1994 From: Dave Burgess Subject: Re: NetBSD DAT tape problems To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga-dev@sun-lamp.cs.berkeley.edu, vervoorn@dutiws.TWI.TUDelft.NL X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 358 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) > > > As an aside, why is the (newer, updated?) 940427 kernel so big? > > Because it includes support for everything.... > > It will only get larger as time goes on.... :-) > Isn't there a Murphy about that... Programs expand to consume all memory and files increase to exhaust all disk? From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 08:36:08 1994 From: Dave Burgess Subject: Re: SysV Shared Memory To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 574 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > >SysV Shared Memory is No More; it was considered 'contaminated' by > > >USL code, etc., etc., etc. > > > > is this semaphores and message queues as well, or just shared > > memory ? (ie, sysv ipc is gone) > > *just* sysv shared memory. It will be replaced, hopefully within > the next few weeks. > SysV? Yuck. Good riddance to bad rubbish, says I. A three week old dead smelt would be a better shared memory implementation than anything those code grinders at AT&T could come up with. ObHumorAlert: Just kidding. Especially those lawyer types from USL! From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 09:43:39 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@erewhon.CS.Berkeley.EDU X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: RS232 tablets? X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu does anybody out there use an rs-232 tablet, as grokked by tty_tb.c? chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 10 11:47:24 1994 From: Yeng-Chee Su Subject: kvm changed? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1001 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried to build the source tree supped on May 9. I've found the kvm library seems to be changed these days and some programs can't be built properly, such as identd, dmesg, etc. It seems the original kinfo.h is missed. By the way, the declaration of sys_signame seems be lost in signal.h too. This makes /bin/kill can't be built because of variable undefined. I also noticed the version number of libc is changed rapidly. I will recompile XFree 2.1.1 soon, so I need to know when will the shlib version be stable? Thanks. -- ________________________________________________________________________ / National Chiao Tung University in Taiwan / \ | Name: Yeng-Chee Su Dept: Computer Engineering |__/ | Phone: +886-35-783513 E-mail: yenchee@csie.nctu.edu.tw | | Address: 22, Alley 2, Lane 173, Gao Tsui Road, HsinChu, Taiwan 300 |___ \______________________________________________________________________\__/ From owner-amiga-x@sun-lamp.cs.berkeley.edu Wed May 11 02:26:06 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: gfx card drivers" (May 9, 3:17pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Donn Cave , markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: gfx card drivers Cc: amiga-x@sun-lamp.cs.berkeley.edu Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 9, 3:17pm, Donn Cave wrote: > I asked about this on the Piccolo mailing list, and while I haven't gotten > any authoritative response, I thought people would be interested to hear > that ``several NetBSD people have already said that they would write a driver > for the GVP Spectrum.'' I wonder who might be responsible for that. Haven't heard of any activities yet. > Hope it goes well. If the whole source can't be made available, I hope > you don't someday get the urge to move to Nepal or something. Eat > nutritious food, drive slow on the Autobahn, etc. Hm, i'd love to trek in Nepal once in while *passionate mountain climber*. Let's see... -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 11 02:44:57 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: NetBSD amiga?" (May 9, 9:28pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Bill Squier , Hubert Feyrer Subject: Re: NetBSD amiga? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 9, 9:28pm, Bill Squier wrote: > >Just as the FAQ (NetBSD.Install.744) says! :-) > > Do you mean to imply that the ASDG LanRover is supported? Does anyone > know for certain whether this card is supported? Your FAQ mentions > only the Ameristar and A2065 boards. He doesn't imply anything :-) As i have already mentioned it, noone has ever reported success yet. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 11 02:49:07 1994 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD amiga? <9405100903.AA28118@aidec512.TechFak.Uni-Bielefeld.DE> From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu In message <9405100903.AA28118@aidec512.TechFak.Uni-Bielefeld.DE>, Markus Illenseer writes: >On May 9, 9:28pm, Bill Squier wrote: >> >Just as the FAQ (NetBSD.Install.744) says! :-) >> >> Do you mean to imply that the ASDG LanRover is supported? Does anyone >> know for certain whether this card is supported? Your FAQ mentions >> only the Ameristar and A2065 boards. > > He doesn't imply anything :-) > As i have already mentioned it, noone has ever reported success yet. Does anyone have the tech specs for this card? It seems to be one of the only remaining Amiga Ethernet cards available. I haven't heard of this other one (Ariadne). If it runs on the same chipset, the patches to get it to work should be trivial. Anyone know if the LanRover (or even this Ariadne) has a BNC connector? -wps grumbling at the lack of A2065s... :-( From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed May 11 03:04:35 1994 X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: netbsd-users@sun-lamp.cs.berkeley.edu From: kallio@jyu.fi (Seppo Kallio) Subject: Experimental NetBSD WWW site at kaarna.jyu.fi Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi! I did some experimental WWW site containing raw bsd.faq -files and some other info + links. Experimental NetBSD WWW info database at Jyvaskyla Seppo From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 03:26:20 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Yeng-Chee Su Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kvm changed? <199405100715.PAA22142@jupiter.csie.nctu.edu.tw> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just tried to build the source tree supped on May 9. I've found the > kvm library seems to be changed these days and some programs can't be built > properly, such as identd, dmesg, etc. It seems the original kinfo.h is > missed. By the way, the declaration of sys_signame seems be lost in > signal.h too. This makes /bin/kill can't be built because of variable > undefined. I also noticed the version number of libc is changed rapidly. > I will recompile XFree 2.1.1 soon, so I need to know when will the shlib > version be stable? Thanks. i warned you all about this, then fixed it for the tar files, then broke it again. I'm in the process of making about 10 different sets of changes, and i hope to have the kvm stuff resolved by next saturday's tar files. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 03:53:50 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Subject: Perl with -current Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anybody have perl-4.036 running with -current ( April 23rd sources )? I've been trying o get it up and running, but it keeps failing on the 'make test' ( on the comp/cpp test and the op/dbm test ). Any help would be most appreciated. Thanks, Brian Moore ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 03:58:11 1994 From: "Robert L. Shady" Subject: Fatal Page Fault -- Again! To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 586 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Running on NetBSD-current sources from ~05-07-94, I receive the following: vm_fault( f83a6300, 0, 1, 0) -> 1 fatal page fault in supervisor mode trap type 6 code 0 eip f815e0f3 cs 20008 eflags 10202 cr2 a cpl 0 panic: trap syncing disks... c19 19 16 13 7 done dumping to dev 1, offset 23984 dump 7 6 5 4 3 2 1 Which is the same exact thing I was complaining about before. I am recompiling with the debugger in this time, and if nobody has any ideas I will try to dig through this mess, assuming I am around next time it happens... Suggestions, Ideas, etc are welcome. -- Rob From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 03:58:45 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Cc: sinha@data.cerc.utexas.edu Subject: Re: -current and X386 2.1 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I figured out the problem. I was having a problem with XFree86 2.1 and -current, where xdm would let me log in once, but when logging out would hang the console. The problem was a bug in the Mach32 and S3 servers. The patch for this is below ( via the folks at XFree86 ) and has been fixed in 2.1.1. So if you are having this same problem with the Mach32 or S3 servers, either apply this patch or get 2.1.1. Brian Moore ziff@eecs.umich.edu From: David Dawes Subject: Re: Problem with xdm on NetBSD-current and XFree 2.1 >I been having the problem that is listed below and have not been able to >diagnose it. Other people have had xdm running on NetBSD-current, but at least >one other person has had this same problem. I have the sources that I dragged >down and everything works, but xdm. I can help debug this problem, but I'll >need some pointers on where to look. This sounds like a problem someone found and fixed on the freebsd-hackers list. You don't say which server you are using, but the fix was to change the following in the server's EnterLeaveVT() function from: pspix = (PixmapPtr)pScreen->devPrivate; to: if (!x386Exiting && !x386Resetting) pspix = (PixmapPtr)pScreen->devPrivate; It looks like the server is dereferencing an invalid pointer at exit/reset. I don't know why this problem hasn't shown up before (or maybe it has?). Let me know if this fix helps. I plan to include it in 2.1.1. David From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 03:59:40 1994 From: Duncan McEwan To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Help with root file system corruption <199405090840.BAA17861@erewhon.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Scott B. Anderson said: > > I'm running -current as of 2 days ago, and I get get a > link count 14 should be 13; correct (y/n) ? > You know the story...no matter how many times I tell it > to fix it, or clear the 2 unreferenced files after it, > it does nothing so far as I can tell. To which Chris G. Demetriou replied: > > if it's your root file system, you should probably 'reboot -n' > I sent Scott the same suggestion in private mail, but then afterwards decided to check whether I was correct (I know that 'reboot -n' used to be necessary with older unices such as 7th edition, but back then fsck explicity printed out "REBOOT UNIX (NO SYNC)", which is no longer the case). On looking at the fsck sources, it seems that "fsck" will always exit with status 4 if it has to fix a mounted root file system. If fsck was running with '-p' from /etc/rc, this will cause a "reboot" rather than "reboot -n". So, is it no longer necessary to do the reboot with no sync in the event of fixing a mounted root, or is it just not needed when using the '-p' option, perhaps because of the limited range of errors that '-p' is able to correct? Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 04:07:22 1994 From: mark@aggregate.com (Mark P. Gooderum) To: Mark_Weaver@brown.edu Subject: Re: libm and i387 Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You're right, I forgot to mention this little step... cd /usr/src ; find . -name .depend -print | xargs rm I also tend to usually do a make clean on every thing (or do a find rm on the obj tree, then you at least don't have to remake all the man pages if you do it right...). The extra few hours to rebuild everything from scratch is worth the trouble it saves. (I'm a tcsh user...) cd /usr/obj.i386 ; find . -type f -a \! -name "*.0" -print | xargs rm I also never do an install of a new tree without having a current level 0 dump of / and /usr...makes it easy to fall back if things get dinked. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 04:11:35 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, duncan@comp.vuw.ac.nz Subject: Re: Help with root file system corruption Sender: owner-current-users@sun-lamp.cs.berkeley.edu So, is it no longer necessary to do the reboot with no sync in the event of fixing a mounted root, or is it just not needed when using the '-p' option, perhaps because of the limited range of errors that '-p' is able to correct? `None of the above.' It's not necessary from /etc/rc because at that point root is supposed to be mounted read-only. From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 04:12:53 1994 From: rhealey@aggregate.com Subject: Re: SysV Shared Memory To: burgess@s069.infonet.net (Dave Burgess) 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: 1298 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > *just* sysv shared memory. It will be replaced, hopefully within > > the next few weeks. > > > > SysV? Yuck. > > Good riddance to bad rubbish, says I. > > A three week old dead smelt would be a better shared memory > implementation than anything those code grinders at AT&T could come up > with. > Obviously rabid but, sysv shared memory could be needed by SunOS emulation, databases use sysv shared memory... Other emulations might need it as well. Just because System V is used in commercial environments doesn't make it junk, it does some things better than BSD ever will do due to BSD having a different focus than System V, i.e. research vs boring commercial apps. By the same token, BSD does some things better because it can play it fast and loose since it doesn't have to give a flying vfork() about backwards compatability. System V could never move as fast as NetBSD has, but my SVR4 system is more functional and much more stable and predictable than NetBSD is. Each has it's purpose and expertise, both should seriously consider features of the other than might help in application support. Also, UNIX(tm) stopped being AT&T's baby a while ago and some of those "code grinders" at USL are pretty good programmers & people. Have you met any of them? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 05:22:22 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Brian Moore Subject: Re: Perl with -current <199405102359.TAA00237@zip.eecs.umich.edu> Cc: current-users@sun-lamp.cs.berkeley.edu From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ignore that test. The reason it fails I believe is that it assumes the dbm files will be called ``.pag'' and ``.dir'' where NetBSD uses the newer naming, and only one file to boot. >Does anybody have perl-4.036 running with -current ( April 23rd sources )? >I've been trying o get it up and running, but it keeps failing on the 'make >test' ( on the comp/cpp test and the op/dbm test ). Any help would be most >appreciated. > >Thanks, >Brian Moore >ziff@eecs.umich.edu > --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 Wed May 11 05:23:18 1994 To: Brian Moore Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Perl with -current <199405102359.TAA00237@zip.eecs.umich.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Does anybody have perl-4.036 running with -current ( April 23rd sources )? >I've been trying o get it up and running, but it keeps failing on the 'make >test' ( on the comp/cpp test and the op/dbm test ). Any help would be most >appreciated. Yes, I have it running fine with current. Last recompiled on April 20th. I don't really remember what changes I made to make it work, since I didn't really record anything, but I suppose I could put up the sources somewhere if they're not already available. It seems to pass all the expected tests. --Michael Incidentally, certain tests are supposed to fail because they expect a "standard" Unix, and NetBSD does a few things differently (some of the db stuff). ----------------------------------------------------------------------------- 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 May 11 05:26:00 1994 Subject: Re: Perl with -current To: ziff@eecs.umich.edu (Brian Moore) Cc: 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: 746 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does anybody have perl-4.036 running with -current ( April 23rd sources )? > I've been trying o get it up and running, but it keeps failing on the 'make > test' ( on the comp/cpp test and the op/dbm test ). Any help would be most > appreciated. Perl fails the cpp test because you don't have cppstdin in installed. I usually install it and then run the tests again. You may have to modify it slightly to use gcc as the cpp. (cppstdin comes with perl.) As for the dbm tests, hack op/dbm and change the code so it looks for a single file suffixed with '.db' (instead of '.dir' and '.pag'). This is because netbsd (since 0.8 I think) has used the 4.4BSD db code to emulate dbm files. If you change the test it should work as advertised. lm. From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 05:27:16 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Duncan McEwan Cc: current-users@sun-lamp.cs.berkeley.edu, explorer@vorpal.com Subject: Re: Help with root file system corruption <199405102239.KAA06137@bats.comp.vuw.ac.nz> From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >'-p' from /etc/rc, this will cause a "reboot" rather than "reboot -n". >So, is it no longer necessary to do the reboot with no sync in the event of >fixing a mounted root, or is it just not needed when using the '-p' option, >perhaps because of the limited range of errors that '-p' is able to correct? It's not the -p option that is important here I believe. At the time fsck runs in /etc/rc, no partitions are mounted read/write, so sync/no sync shouldn't matter one bit. --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 Wed May 11 05:29:52 1994 To: "Robert L. Shady" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Fatal Page Fault -- Again! <199405101054.GAA29251@zeus.id.net> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Running on NetBSD-current sources from ~05-07-94, I receive the following: >vm_fault( f83a6300, 0, 1, 0) -> 1 Actually, the kernel I built just before all the kvm changes started is running fabulously: [michaelv@MindBender]~> uptime 8:48pm up 9 days, 7 hrs, 11 users, load average: 0.16, 0.30, 0.25 [michaelv@MindBender]~> cat /kern/version NetBSD 0.9a (MINDBENDER) #129: Sun May 1 13:43:01 CDT 1994 Please let us know when things will be stable again... I don't want to sup again when I have such a stable kernel at the moment. :-) Incidentally, this is running with my Cyrix/TI 486DLC patches, with the cache running in non-flush mode, and cache invalidations added at strategic points. I guess should I hurry up and clean it up so others can try it. --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 Wed May 11 05:33:13 1994 To: Brian Moore Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Perl with -current From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 10 May 1994 19:59:33 -0400 Brian Moore wrote: > Does anybody have perl-4.036 running with -current ( April 23rd sources )? > I've been trying o get it up and running, but it keeps failing on the 'make > test' ( on the comp/cpp test and the op/dbm test ). Any help would be most > appreciated. I compiled it a *long* time ago...I think it's using libc.so.2.1 :-) Anyway...I plan to build it again as soon as the c library revision is stable :-)... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 08:05:07 1994 To: mycroft@sun-lamp.cs.berkeley.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: mouse interrupts From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu In icu.h it mentions the interrupts being in a certain priority. How exactly is this "priority" determined? Is this just the priority given to the interrupt controller, or something more complex that tells the low-level interrupt handler to handle interrupts in a certain order? Interrupt 5 is almost at the bottom of the list. This, in my system, is the port containing my Logitech bus mouse. I assume the reason for putting it down there is to give the parallel ports relatively low priority (5 being a common IRQ for LPT2 on DOS machines), which seems like a reasonable thing to do. But, under heavy use (modem going, some paging, etc.) the mouse can sometimes get way behind on my system. It's like moving the mouse, then having to sit and wait for several seconds to see anything at all happen. In contrast, no matter what is happening on my DECstation at work, the mouse is always smoooooooth and updated instantly whenever it moves. Would changing the "priority" of the mouse from near the bottom, to right up near the top after the keyboard interrupt be a reasonable way to maybe get a bit more smoothness? I know this isn't a simple thing to do since the mouse could potentially be found on several different interrupts, depending on the model and manufacturer. In addition, I understand the X server actually has to receive the mouse movements and write them to the video card. But, maybe some cryptic little bit in config could figure which port you wanted a mouse on and lift that up in priority when you built a kernel. In the interest in aesthetics and ergonomics, if this were a workable way to get better mouse responsiveness, it might be worth playing with a bit. --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 Wed May 11 11:06:49 1994 X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: PATCH for ftpd Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" From: David Carrel Sender: owner-current-users@sun-lamp.cs.berkeley.edu ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" The following is a quick patch to fix an off_t problem in ftpd. The only problem is in the sizes that get printed (they always show up as zero). You might have noticed output like this when ftp-ing to a NetBSD machine: ftp> get xv xv.foo 227 Entering Passive Mode (198,92,30,121,4,16) 150 Opening BINARY mode data connection for xv (0 bytes). I solved this by casting the off_t values to unsigned longs when printing them. The truely correct way to fix this would be to have printf() recognize a "long long". I tried "%lld" and "%llu" but they did not work. Maybe I'll be more energetic tomorrow night and look into a patch for printf. Dave ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-Description: ftpd patch diff -r -c /usr/src/libexec/ftpd/ftpcmd.y ./ftpcmd.y *** /usr/src/libexec/ftpd/ftpcmd.y Fri Apr 15 04:06:43 1994 --- ./ftpcmd.y Tue May 10 23:21:31 1994 *************** *** 1171,1177 **** (stbuf.st_mode&S_IFMT) != S_IFREG) reply(550, "%s: not a plain file.", filename); else ! reply(213, "%lu", stbuf.st_size); break;} case TYPE_A: { FILE *fin; --- 1171,1177 ---- (stbuf.st_mode&S_IFMT) != S_IFREG) reply(550, "%s: not a plain file.", filename); else ! reply(213, "%lu", (unsigned long)stbuf.st_size); break;} case TYPE_A: { FILE *fin; diff -r -c /usr/src/libexec/ftpd/ftpd.c ./ftpd.c *** /usr/src/libexec/ftpd/ftpd.c Fri Apr 15 04:06:44 1994 --- ./ftpd.c Tue May 10 23:21:10 1994 *************** *** 719,725 **** file_size = size; byte_count = 0; if (size != (off_t) -1) ! (void) sprintf (sizebuf, " (%ld bytes)", size); else (void) strcpy(sizebuf, ""); if (pdata >= 0) { --- 719,725 ---- file_size = size; byte_count = 0; if (size != (off_t) -1) ! (void) sprintf (sizebuf, " (%ld bytes)", (unsigned long)size); else (void) strcpy(sizebuf, ""); if (pdata >= 0) { ------- =_aaaaaaaaaa0-- From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed May 11 11:12:27 1994 From: Peter Galbavy To: cgd@postgres.berkeley.edu, kallio@jyu.fi Subject: Re: Linux Documentation Project Home Page Cc: netbsd-users@sun-lamp.cs.berkeley.edu Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Apart from the fact that my main system (the web/news/ftp etc server) has just kicked the bucket (the root disk died), I *was* sort of planning to do just this sort of thing. I don't think I would be the right person to author Web pages "selling" NetBSD, but I was in the process to HTML'ing the manual set and README files etc. Ah well, maybe next week when my system is restored to life... (On a completely off topic, should be for port-sparc, I have realised how useful tape support would have been for this system, which is imitating alice.wonderland.org for mail purposes only at the moment. Anyone working on it - apart from Theo who is already doing too much ? :) Regards, Peter G From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 11 12:47:13 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: NetBSD amiga?" (May 10, 8:09pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Bill Squier Subject: Re: NetBSD amiga? Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 10, 8:09pm, Bill Squier wrote: > Does anyone have the tech specs for this card? It seems to be one of > the only remaining Amiga Ethernet cards available. I haven't heard of > this other one (Ariadne). If it runs on the same chipset, the patches > to get it to work should be trivial. Have no specs for Lanrover, but i do have some for upcoming Ariadne. Later one will probably be embedded into the kernel on a meeting in two weeks (big event in Germany). > Anyone know if the LanRover (or even this Ariadne) has a BNC > connector? Ariadne has Thin-Ether (10-Base-2) and Twisted-Pair (10-Base-T) (and two parallel-Ports). -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 13:31:08 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: route(8) lossage Sender: owner-current-users@sun-lamp.cs.berkeley.edu After updating your kernel sources for the new pid_t and new route.h, you will need to also rebuild route(8) (in /usr/src/sbin/route), for the new format of routing control messages. (And routed as well.) From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 14:51:55 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 Null message body; hope that's ok Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/include/Makefile U src/include/signal.h U src/lib/libc/arch/m68k/gen/setjmp.S U src/lib/libc/gen/Makefile.inc U src/lib/libc/gen/popen.c U src/sbin/dmesg/Makefile U src/sbin/dmesg/dmesg.8 U src/sbin/dmesg/dmesg.c U src/sys/arch/hp300/dev/cd.c U src/sys/arch/hp300/dev/ct.c U src/sys/arch/hp300/dev/rd.c U src/sys/arch/hp300/dev/sd.c U src/sys/arch/hp300/dev/st.c U src/sys/arch/hp300/dev/vn.c U src/sys/arch/i386/conf/ALL U src/sys/arch/i386/conf/PAIN U src/sys/arch/i386/conf/PATEK U src/sys/arch/i386/conf/TDR U src/sys/arch/i386/i386/conf.c U src/sys/arch/i386/isa/fd.c U src/sys/arch/i386/isa/mcd.c U src/sys/arch/i386/isa/ultra14f.c U src/sys/arch/m68k/include/ansi.h U src/sys/arch/m68k/include/limits.h U src/sys/arch/m68k/m68k/db_disasm.c U src/sys/arch/sun3/conf/files.sun3.newconf U src/sys/arch/sun3/include/cpu.h U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/trap.c U src/sys/dev/vn.c U src/sys/net/route.c U src/sys/net/route.h U src/sys/net/rtsock.c U src/sys/scsi/cd.c U src/sys/scsi/st.c U src/sys/sys/conf.h U src/sys/sys/errno.h U src/sys/sys/ktrace.h U src/sys/vm/vm_meter.c U src/usr.bin/Makefile U src/usr.bin/getconf/Makefile U src/usr.bin/getconf/getconf.c U src/usr.bin/ipcrm/Makefile U src/usr.bin/ipcrm/ipcrm.c U src/usr.bin/ipcs/Makefile U src/usr.bin/ipcs/ipcs.c U src/usr.bin/kdump/Makefile U src/usr.bin/kdump/kdump.1 U src/usr.bin/kdump/kdump.c U src/usr.bin/kdump/mkioctls U src/usr.bin/ktrace/Makefile U src/usr.bin/ktrace/ktrace.1 U src/usr.bin/ktrace/ktrace.c U src/usr.bin/ktrace/ktrace.h U src/usr.bin/ktrace/subr.c U src/usr.bin/vmstat/Makefile U src/usr.bin/vmstat/names.c U src/usr.bin/vmstat/vmstat.8 U src/usr.bin/vmstat/vmstat.c Running the SUP scanner: SUP Scan for current starting at Wed May 11 03:28:40 1994 SUP Scan for current completed at Wed May 11 03:31:19 1994 SUP Scan for mirror starting at Wed May 11 03:31:20 1994 SUP Scan for mirror completed at Wed May 11 03:33:57 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 11 21:03:17 1994 From: Eric Augustine Subject: Serial device and others... To: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Cc: 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: 818 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello... I am having trouble downloading material to my machine via kermit. Seems when I get to the receive part, kermit exits. I remember there being some mention of serial device problems a while ago but, unfortunately there's been a system error between then and now and what mail I had saved on that subject has been lost. Also, does anyone out there have a 744 kernel compiled with the floppy driver. I have been trying to compile the sources from 26April with no luck... some sort of mixup in the configuring files - all I'd really like to get going is the serial transfers and the floppy driver... I'm using: A3000/25 with 68882, ECS, 8Megs Fast, 1Meg Chip Maxtor 7120SCS (address 6) Quantum PD210S (address 5) Kernel #744, with #720 Binaries and GCC2.5.6 Thanks much for the help... - Eric. From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 11 21:31:38 1994 From: Eric Augustine Subject: Serial device and others... To: amiga@sun-lamp.cs.berkeley.edu (Net NetBSD-Amiga) Cc: 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: 818 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello... I am having trouble downloading material to my machine via kermit. Seems when I get to the receive part, kermit exits. I remember there being some mention of serial device problems a while ago but, unfortunately there's been a system error between then and now and what mail I had saved on that subject has been lost. Also, does anyone out there have a 744 kernel compiled with the floppy driver. I have been trying to compile the sources from 26April with no luck... some sort of mixup in the configuring files - all I'd really like to get going is the serial transfers and the floppy driver... I'm using: A3000/25 with 68882, ECS, 8Megs Fast, 1Meg Chip Maxtor 7120SCS (address 6) Quantum PD210S (address 5) Kernel #744, with #720 Binaries and GCC2.5.6 Thanks much for the help... - Eric. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 11 21:50:41 1994 From: nix@stekt16.oulu.fi (Tero Manninen) Subject: Re: Boot loader testers wanted To: markus@techfak.uni-bielefeld.de (Markus Illenseer) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1634 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > On May 7, 12:27pm, Tero Manninen wrote: > > One thing.. I have only #744 kernel (the version before going to SUP) > > and don't know if the loader works at all with newer kernels. I hear > > that loadbsd has changed since then.. > > I fear that the bootloader is then only usable for a minority among > us developers. As for me, i don't have #744 anywhere :-) And yes, loadbsd > has changed heavily. That's true, but I don't have time to set up a new system (SUP). Actually the difference between #744 kernel boot loader and the latest kernel version should be quite small and isolated. I have taken the actual booting mechanism (assembly code) and memory configuration code from loadbsd.c. So it should be very easy to update the boot loader for latest kernel. Right now I have one very peculiar problem with this boot loader. When I set the boot priority of netbsd root (boot) partition so high that the boot code is actually loaded before amigados is ever run (and workbench) the boot fails (fireworks). On the other hand, if I let the system boot once to amigados and then reboot (going thru all the v36 boot menues (the kickstart 2.x / 1.3 menu and so on)) everything goes well. I can even reboot from netbsd or give three-finger-salute :-/ Does anyone know what could be wrong? > Markus Illenseer Due to this booting problem I won't release the current system (yet) to anyone who has requested it. If someone really wants to debug the symptoms I can give the sources and development environment. Next few days I will be away (to Stockholm) and I'll be back answering any questions on Monday. So, until then.. ++Tero From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 21:56:36 1994 From: Manuel Bouyer Subject: chmod g+s on directory To: current-users@sun-lamp.cs.berkeley.edu (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: 592 Sender: owner-current-users@sun-lamp.cs.berkeley.edu What is the SGID bit on directory expected to do ? On sunos4, it should propagate the group id when a new file/directory is created. The SGID bit is also propagated. On netbsd-current (at least tar-balls of 16 april, but i've took a lock at the last tar-balls, it seems to me that nothing changes for this), the SGID bit has no effect, and is'nt propagated to new dirs. The group id is always propagated, even if the user which create the file isn't member of this group. Bug or feature ? -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 11 22:02:01 1994 From: deraadt@fsa.ca (Theo Deraadt) To: bouyer@ensta.fr, current-users@sun-lamp.cs.berkeley.edu Subject: Re: chmod g+s on directory Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Bug or feature ? Feature. > The group id is always > propagated, even if the user which create the file isn't member of this group. This is the BSD way to do it. The setgid bit thing you are describing is used to map to the SYSV way of creating new files -- in SYSV they files always take on the gid of the user. You can look in the NetBSD mailinglist archives for previous discussions on this. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 00:34:24 1994 To: current-users@sun-lamp.cs.berkeley.edu From: "John M Crawford" Subject: New to this group Sender: owner-current-users@sun-lamp.cs.berkeley.edu Greetings, I'm new to this list. I've got NetBSD 0.9 running on my i486 machine. I have base and etc installed. I've rz'ed the "current" gz files to a directory on this machine. Now I am ready to go further... questions: Where are good cookbook instructions on what I should do next to get current running? Can someone point me to archives of this group? Thanks, John ---- John M. Crawford (614) 292-9518 Computing and Communications Services Max M. Fisher College of Business craw4d+@osu.edu 1775 College Road craw4d@prime.cob.ohio-state.edu The Ohio State University (614) 292-1651 FAX Columbus, Ohio 43210 ---- From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 00:54:03 1994 From: ddzehr@telecom.ksu.edu (Dylan D Zehr) To: current-users@sun-lamp.cs.berkeley.edu Subject: libc compile prob. Cc: ddzehr@telecom.ksu.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have the lastest source tree and am getting the following error when building libc. /usr/local/src/lib/libc/gen/nlist.c: In function `__fdnlist': /usr/local/src/lib/libc/gen/nlist.c:91: `SIZE_T_MAX' undeclared (first use this function) The error looks fairly simple to fix, it's dealing with the maximum file size that can be mmaped, but I'm currently not familiar enough with the source to add the define myself. Thanks for any help. --- Dylan Zehr From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 01:43:55 1994 From: "Chris G. Demetriou" To: current-users@sun-lamp.cs.berkeley.edu, ddzehr@telecom.ksu.edu Subject: Re: libc compile prob. Sender: owner-current-users@sun-lamp.cs.berkeley.edu SIZE_T_MAX was recently added to the include files... (it was added at the same time the nlist code was updated, actually... 8-) anyway, you need to reinstall your include files. chris From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 07:09:57 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: `amd -r' dumps core ... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, Specifying the `-r' flag to amd gives a core dump. The problem is in: src/usr.sbin/amd/config/mtab_bsd.c The code didn't zero terminate the list of mount table entries. This problem is fixed (at least) in `amd920824upl75'. A patch is below: *** mtab_bsd.c.dist Wed May 11 15:04:37 1994 --- mtab_bsd.c Wed May 11 15:26:28 1994 *************** *** 114,119 **** --- 114,124 ---- mpp = &(*mpp)->mnext; } + /* + * Terminate the list + */ + *mpp = 0; + return mhp; } Andrew (cagney@highland.oz.au) From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 07:41:41 1994 From: Craig Bevins Subject: Re: chmod g+s on directory To: bouyer@ensta.fr (Manuel Bouyer) Cc: current-users@sun-lamp.cs.berkeley.edu X-Organisation: IPS Radio & Space Services. Sydney, Australia. X-Face: #&>A)BGF5=|+^cx#bXVaO{j@eYXuC/#u4.[aWf|EFHz5VKY0:*2gLbm]4C{p/L}1$G0o6 4O*3:\a8&j{nI[7c* Message-Id: <199405111650.SAA00417@bsdtest.ensta.fr> Subject: chmod g+s on directory To: current-users@sun-lamp.cs.berkeley.edu (current-users) Date: Wed, 11 May 1994 18:50:08 +0200 (MET DST) What is the SGID bit on directory expected to do ? On sunos4, it should propagate the group id when a new file/directory is created. The SGID bit is also propagated. On netbsd-current ... the SGID bit has no effect, and is'nt propagated to new dirs. The group id is always propagated, even if the user which create the file isn't member of this group. The SGID bit on directories was a hack introduced to force BSD behaviour after SunOS became schizophrenic and System V file creation semantics were made the default. This first appeared, I think, in SunOS 4.0. Repeat after me: NetBSD != SunOS. csb From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 14:49:55 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/sh/Makefile U src/bin/sh/TOUR U src/bin/sh/alias.c U src/bin/sh/alias.h U src/bin/sh/arith.y U src/bin/sh/arith_lex.l U src/bin/sh/builtins U src/bin/sh/cd.c U src/bin/sh/errmsg.c U src/bin/sh/errmsg.h U src/bin/sh/error.c U src/bin/sh/error.h U src/bin/sh/eval.c U src/bin/sh/eval.h U src/bin/sh/exec.c U src/bin/sh/exec.h U src/bin/sh/expand.c U src/bin/sh/expand.h U src/bin/sh/histedit.c U src/bin/sh/init.h U src/bin/sh/input.c U src/bin/sh/input.h U src/bin/sh/jobs.c U src/bin/sh/jobs.h U src/bin/sh/machdep.h U src/bin/sh/mail.c U src/bin/sh/mail.h U src/bin/sh/main.c U src/bin/sh/main.h U src/bin/sh/memalloc.c U src/bin/sh/memalloc.h U src/bin/sh/miscbltin.c U src/bin/sh/mkbuiltins U src/bin/sh/mkinit.c U src/bin/sh/mknodes.c U src/bin/sh/mksyntax.c U src/bin/sh/mktokens U src/bin/sh/myhistedit.h U src/bin/sh/mystring.c U src/bin/sh/mystring.h U src/bin/sh/nodes.c.pat U src/bin/sh/nodetypes U src/bin/sh/options.c U src/bin/sh/options.h U src/bin/sh/output.c U src/bin/sh/output.h U src/bin/sh/parser.c U src/bin/sh/parser.h U src/bin/sh/redir.c U src/bin/sh/redir.h U src/bin/sh/sh.1 U src/bin/sh/shell.h U src/bin/sh/show.c U src/bin/sh/trap.c U src/bin/sh/trap.h U src/bin/sh/var.c U src/bin/sh/var.h U src/bin/sh/bltin/bltin.h U src/bin/sh/bltin/echo.1 U src/bin/sh/bltin/echo.c U src/bin/sh/funcs/cmv U src/bin/sh/funcs/dirs U src/bin/sh/funcs/kill U src/bin/sh/funcs/login U src/bin/sh/funcs/newgrp U src/bin/sh/funcs/popd U src/bin/sh/funcs/pushd U src/bin/sh/funcs/suspend U src/etc/rc.local U src/sys/adosfs/adlookup.c U src/sys/adosfs/adosfs.h U src/sys/adosfs/adutil.c U src/sys/adosfs/advfsops.c U src/sys/adosfs/advnops.c U src/sys/arch/amiga/amiga/amiga_init.c U src/sys/arch/amiga/amiga/autoconf.c U src/sys/arch/amiga/amiga/disksubr.c U src/sys/arch/amiga/amiga/genassym.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/conf/Makefile.amiga U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/conf/std.amiga U src/sys/arch/amiga/dev/ahsc.c U src/sys/arch/amiga/dev/atzsc.c U src/sys/arch/amiga/dev/grf.c U src/sys/arch/amiga/dev/gtsc.c U src/sys/arch/amiga/dev/ite.c U src/sys/arch/amiga/dev/iteioctl.h U src/sys/arch/amiga/dev/mgnsc.c U src/sys/arch/amiga/dev/sbic.c U src/sys/arch/amiga/dev/ser.c U src/sys/arch/amiga/dev/siop.c U src/sys/arch/amiga/dev/siopreg.h U src/sys/arch/amiga/dev/siopvar.h U src/sys/arch/amiga/dev/wesc.c U src/sys/arch/amiga/dev/zssc.c U src/sys/arch/amiga/dev/zthreebus.c U src/sys/arch/amiga/dev/zthreebusvar.h U src/sys/arch/amiga/dev/ztwobus.c U src/sys/arch/amiga/stand/loadbsd/loadbsd.c U src/sys/arch/amiga/stand/loadkmap/loadkmap.c U src/sys/arch/hp300/hp300/conf.c U src/sys/arch/i386/isa/if_ed.c U src/sys/arch/i386/isa/if_el.c U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_ie.c U src/sys/arch/i386/isa/if_is.c U src/sys/arch/sparc/conf/SS5 U src/sys/arch/sparc/conf/TDR U src/sys/arch/sparc/conf/TDR2 U src/sys/arch/sparc/sparc/conf.c U src/sys/arch/sparc/sparc/locore.s U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/kern/subr_autoconf.c U src/sys/kern/subr_prf.c U src/sys/kern/subr_xxx.c U src/sys/kern/sys_socket.c U src/sys/kern/sysv_ipc.c U src/sys/kern/tty.c U src/sys/kern/tty_compat.c U src/sys/kern/tty_conf.c U src/sys/kern/tty_pty.c U src/sys/kern/tty_tb.c U src/sys/kern/tty_tty.c U src/sys/kern/vfs_conf.c U src/sys/nfs/nfs_vfsops.c U src/sys/sys/malloc.h U src/sys/sys/mount.h U src/sys/sys/syslog.h U src/sys/sys/systm.h U src/sys/sys/tty.h U src/sys/sys/vnode.h Running the SUP scanner: SUP Scan for current starting at Thu May 12 03:37:59 1994 SUP Scan for current completed at Thu May 12 03:41:12 1994 SUP Scan for mirror starting at Thu May 12 03:41:13 1994 SUP Scan for mirror completed at Thu May 12 03:45:22 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 18:30:46 1994 From: ddzehr@telecom.ksu.edu (Dylan D Zehr) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: libc compile prob. Cc: ddzehr@telecom.ksu.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Chris G. Demetriou writes: >SIZE_T_MAX was recently added to the include files... (it was added >at the same time the nlist code was updated, actually... 8-) > >anyway, you need to reinstall your include files. ok, did that, (I have the most recent version from sun-lamp.) still doesn't work. How about a hint as to which include file? --- dylan From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 12 19:36:34 1994 From: Manuel Bouyer Subject: Re: chmod g+s on directory To: deraadt@fsa.ca (Theo Deraadt) Cc: bouyer@ensta.fr, 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: 5230 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > The group id is always > > propagated, even if the user which create the file isn't member of this group. > > This is the BSD way to do it. The setgid bit thing you are describing > is used to map to the SYSV way of creating new files -- in SYSV they > files always take on the gid of the user. So, the behavior for an UFS file system and a NFS one should be the same, i think. It is if the NFS server is a NetBSD, but it is not whith other os as server (at least SunOS 4.1.1 and HP-UX 9.01). Here are my diffs (from tar_ball of 16 april) to have the gid propagated on nfs filesystems. This works whith SunOS 4.1.1 and HP-UX 9.01 servers. Perhaps this sould be set as an option. *** nfs_vnops.c- Thu May 12 16:40:00 1994 --- nfs_vnops.c Thu May 12 16:03:55 1994 *************** *** 789,794 **** --- 789,795 ---- int error = 0; struct mbuf *mreq, *mrep, *md, *mb, *mb2; u_long rdev; + struct nfsnode *dnp=VTONFS(ndp->ni_dvp); if (vap->va_type == VCHR || vap->va_type == VBLK) rdev = txdr_unsigned(vap->va_rdev); *************** *** 809,815 **** nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(vap->va_type, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid); sp->sa_size = rdev; /* or should these be VNOVAL ?? */ txdr_time(&vap->va_atime, &sp->sa_atime); --- 810,817 ---- nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(vap->va_type, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! /* sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid);*/ ! sp->sa_gid = txdr_unsigned(dnp->n_vattr.va_gid); sp->sa_size = rdev; /* or should these be VNOVAL ?? */ txdr_time(&vap->va_atime, &sp->sa_atime); *************** *** 838,843 **** --- 840,846 ---- u_long xid; int error = 0; struct mbuf *mreq, *mrep, *md, *mb, *mb2; + struct nfsnode *dnp=VTONFS(ndp->ni_dvp); nfsstats.rpccnt[NFSPROC_CREATE]++; nfsm_reqhead(nfs_procids[NFSPROC_CREATE], ndp->ni_cred, *************** *** 847,853 **** nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(vap->va_type, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid); sp->sa_size = txdr_unsigned(0); /* or should these be VNOVAL ?? */ txdr_time(&vap->va_atime, &sp->sa_atime); --- 850,857 ---- nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(vap->va_type, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! /* sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid);*/ ! sp->sa_gid = txdr_unsigned(dnp->n_vattr.va_gid); sp->sa_size = txdr_unsigned(0); /* or should these be VNOVAL ?? */ txdr_time(&vap->va_atime, &sp->sa_atime); *************** *** 1111,1116 **** --- 1115,1121 ---- u_long xid; int error = 0; struct mbuf *mreq, *mrep, *md, *mb, *mb2; + struct nfsnode *dnp=VTONFS(ndp->ni_dvp); nfsstats.rpccnt[NFSPROC_SYMLINK]++; nfsm_reqhead(nfs_procids[NFSPROC_SYMLINK], ndp->ni_cred, *************** *** 1121,1127 **** nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(VLNK, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid); sp->sa_size = txdr_unsigned(VNOVAL); txdr_time(&vap->va_atime, &sp->sa_atime); /* or VNOVAL ?? */ txdr_time(&vap->va_mtime, &sp->sa_mtime); /* or VNOVAL ?? */ --- 1126,1133 ---- nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(VLNK, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! /* sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid);*/ ! sp->sa_gid = txdr_unsigned(dnp->n_vattr.va_gid); sp->sa_size = txdr_unsigned(VNOVAL); txdr_time(&vap->va_atime, &sp->sa_atime); /* or VNOVAL ?? */ txdr_time(&vap->va_mtime, &sp->sa_mtime); /* or VNOVAL ?? */ *************** *** 1155,1160 **** --- 1161,1167 ---- u_long xid; int error = 0, firsttry = 1; struct mbuf *mreq, *mrep, *md, *mb, *mb2; + struct nfsnode *dnp=VTONFS(ndp->ni_dvp); len = ndp->ni_namelen; nfsstats.rpccnt[NFSPROC_MKDIR]++; *************** *** 1165,1171 **** nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(VDIR, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid); sp->sa_size = txdr_unsigned(VNOVAL); txdr_time(&vap->va_atime, &sp->sa_atime); /* or VNOVAL ?? */ txdr_time(&vap->va_mtime, &sp->sa_mtime); /* or VNOVAL ?? */ --- 1172,1179 ---- nfsm_build(sp, struct nfsv2_sattr *, NFSX_SATTR); sp->sa_mode = vtonfs_mode(VDIR, vap->va_mode); sp->sa_uid = txdr_unsigned(ndp->ni_cred->cr_uid); ! /* sp->sa_gid = txdr_unsigned(ndp->ni_cred->cr_gid);*/ ! sp->sa_gid = txdr_unsigned(dnp->n_vattr.va_gid); sp->sa_size = txdr_unsigned(VNOVAL); txdr_time(&vap->va_atime, &sp->sa_atime); /* or VNOVAL ?? */ txdr_time(&vap->va_mtime, &sp->sa_mtime); /* or VNOVAL ?? */ -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 04:03:21 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Manuel Bouyer Cc: deraadt@fsa.ca, current-users@sun-lamp.cs.berkeley.edu Subject: Re: chmod g+s on directory <199405121445.QAA00365@bsdtest.ensta.fr> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > So, the behavior for an UFS file system and a NFS one should be the same, i > think. Note even close. UFS defines a certain set of semantics, which it follows. NFS defines a different set (and for things like this, follows the server's idea of what's right). You can't say "it works this way on UFS, so it should work this way on NFS" -- that's just not the way it works. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 08:13:45 1994 From: Yeng-Chee Su Subject: xfishtank To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 833 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried to port xfishtank on NetBSD-current but failed. It is compiled fine but it will catch SIGSEGV while running. Strangely, the stop point in core file isn't the same as the one which I ran it under gdb. In addition, I got 'sigvec call OK' even I comment out the init_signal function. I've never met such strange things before. Have any one ported it? -- ________________________________________________________________________ / National Chiao Tung University in Taiwan / \ | Name: Yeng-Chee Su Dept: Computer Engineering |__/ | Phone: +886-35-783513 E-mail: yenchee@csie.nctu.edu.tw | | Address: 22, Alley 2, Lane 173, Gao Tsui Road, HsinChu, Taiwan 300 |___ \______________________________________________________________________\__/ From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 09:56:45 1994 From: Ewan Tempero To: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Building gcc-2.5.8 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have been trying to build gcc-2.5.8. When I compared stage3 with stage2 I got differences in the following files: cp-call.o cp-class.o cp-cvt.o cp-decl.o cp-decl2.o cp-edsel.o cp-errfn.o cp-error.o cp-except.o cp-expr.o cp-gc.o cp-init.o cp-lex.o cp-method.o cp-parse.o cp-pt.o cp-ptree.o cp-search.o cp-spew.o cp-tree.o cp-type2.o cp-typeck.o cp-xref.o getopt.o getopt1.o objc-act.o objc-parse.o protoize.o unprotoize.o I assume someone has already done this (surely someone other than me wants a more up-to-date g++). Can said someone please shed any light on what my problem is? I'm running Netbsd-current of about april 29 (timezones etc make it hard to be precise). I configured with i386-unknown-bsd, there being no netbsd available. thanks, --ewan From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 13 16:39:06 1994 From: Hubert Feyrer Subject: sys.19940513 To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: hubert.feyrer@rz.uni-regensburg.de X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1129 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Last night I compiled the kernel from 13th may, and except for two little things, it compiled flawlessly: 1.) There was an ')' missing quite at the end of .../sys/syslog.h 2.) ttnread must be non-static in .../kern/tty.c But after that, friday 13th took his toll: When I tried loading it (either from /dev/reboot or via loadbsd), it barfed on me. After loadbsd tells his story about availabel memory etc., all I get is a black screen! I've tried loadbsd-940320.gz and even managed to compile the loadbsd.c that came with the kernel, but none of the two worked. (I also did a "make install" in /usr/include ...) What am I missing/what's wrong 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 Fri May 13 17:48:14 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/Makefile U src/bin/sh/Makefile U src/bin/sh/cd.c U src/bin/sh/error.c U src/bin/sh/eval.c U src/bin/sh/exec.c U src/bin/sh/expand.c U src/bin/sh/histedit.c U src/bin/sh/input.c U src/bin/sh/jobs.c U src/bin/sh/main.c U src/bin/sh/memalloc.c U src/bin/sh/miscbltin.c U src/bin/sh/mystring.c U src/bin/sh/options.c U src/bin/sh/output.c U src/bin/sh/output.h U src/bin/sh/trap.c U src/bin/sh/var.c U src/games/mille/Makefile U src/games/mille/comp.c U src/games/mille/end.c U src/games/mille/extern.c U src/games/mille/init.c U src/games/mille/mille.6 U src/games/mille/mille.c U src/games/mille/mille.h U src/games/mille/misc.c U src/games/mille/move.c U src/games/mille/print.c U src/games/mille/roll.c U src/games/mille/save.c U src/games/mille/table.c U src/games/mille/types.c U src/games/mille/unctrl.h U src/games/mille/varpush.c U src/sbin/route/Makefile U src/sbin/route/ccitt_addr.c U src/sbin/route/keywords U src/sbin/route/route.8 U src/sbin/route/route.c U src/sbin/routed/Makefile U src/sbin/routed/af.c U src/sbin/routed/af.h U src/sbin/routed/defs.h U src/sbin/routed/if.c U src/sbin/routed/inet.c U src/sbin/routed/input.c U src/sbin/routed/interface.h U src/sbin/routed/main.c U src/sbin/routed/output.c U src/sbin/routed/pathnames.h U src/sbin/routed/routed.8 U src/sbin/routed/startup.c U src/sbin/routed/table.h U src/sbin/routed/tables.c U src/sbin/routed/timer.c U src/sbin/routed/trace.c U src/sbin/routed/trace.h U src/sbin/routed/query/Makefile U src/sbin/routed/query/query.c U src/sbin/routed/trace/Makefile U src/sbin/routed/trace/trace.c U src/sys/adosfs/adlookup.c U src/sys/adosfs/advnops.c U src/sys/arch/amiga/amiga/Locore.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/trap.c U src/sys/arch/hp300/dev/if_le.c U src/sys/arch/hp300/hp300/Locore.c U src/sys/arch/hp300/hp300/locore.s U src/sys/arch/hp300/hp300/trap.c U src/sys/arch/i386/conf/PAIN U src/sys/arch/i386/conf/TRINITY U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/include/profile.h U src/sys/arch/i386/isa/icu.s U src/sys/arch/i386/isa/if_ed.c U src/sys/arch/i386/isa/if_el.c U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_ie.c U src/sys/arch/i386/isa/if_is.c U src/sys/arch/m68k/include/profile.h U src/sys/arch/m68k/m68k/db_disasm.c U src/sys/arch/m68k/m68k/db_trace.c U src/sys/arch/sun3/sun3/conf.c U src/sys/arch/sun3/sun3/swapgeneric.c U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/kern/init_main.c U src/sys/kern/kern_exit.c U src/sys/kern/kern_fork.c U src/sys/kern/kern_malloc.c U src/sys/kern/kern_synch.c U src/sys/kern/subr_autoconf.c U src/sys/kern/subr_prf.c U src/sys/kern/sys_socket.c U src/sys/kern/uipc_domain.c U src/sys/kern/uipc_mbuf.c U src/sys/kern/uipc_proto.c U src/sys/kern/uipc_socket.c U src/sys/kern/uipc_socket2.c U src/sys/net/bpf.c U src/sys/net/bpf.h U src/sys/net/bpf_filter.c U src/sys/net/bpfdesc.h U src/sys/net/if.c U src/sys/net/if.h U src/sys/net/if_arp.h U src/sys/net/if_dl.h U src/sys/net/if_ethersubr.c U src/sys/net/if_llc.h U src/sys/net/if_loop.c U src/sys/net/if_ppp.c U src/sys/net/if_sl.c U src/sys/net/if_slvar.h U src/sys/net/if_types.h U src/sys/net/netisr.h U src/sys/net/radix.c U src/sys/net/radix.h U src/sys/net/raw_cb.c U src/sys/net/raw_cb.h U src/sys/net/raw_usrreq.c U src/sys/net/route.c U src/sys/net/route.h U src/sys/net/rtsock.c U src/sys/net/slcompress.c U src/sys/net/slcompress.h U src/sys/net/slip.h U src/sys/netccitt/README.hdlc U src/sys/netccitt/README.packet U src/sys/netccitt/ccitt_proto.c U src/sys/netccitt/dll.h U src/sys/netccitt/hd_debug.c U src/sys/netccitt/hd_input.c U src/sys/netccitt/hd_output.c U src/sys/netccitt/hd_subr.c U src/sys/netccitt/hd_timer.c U src/sys/netccitt/hd_var.h U src/sys/netccitt/hdlc.h U src/sys/netccitt/if_x25subr.c U src/sys/netccitt/llc_input.c U src/sys/netccitt/llc_output.c U src/sys/netccitt/llc_subr.c U src/sys/netccitt/llc_timer.c U src/sys/netccitt/llc_var.h U src/sys/netccitt/pk.h U src/sys/netccitt/pk_acct.c U src/sys/netccitt/pk_debug.c U src/sys/netccitt/pk_input.c U src/sys/netccitt/pk_llcsubr.c U src/sys/netccitt/pk_output.c U src/sys/netccitt/pk_subr.c U src/sys/netccitt/pk_timer.c U src/sys/netccitt/pk_usrreq.c U src/sys/netccitt/pk_var.h U src/sys/netccitt/x25.h U src/sys/netccitt/x25acct.h U src/sys/netccitt/x25err.h U src/sys/netinet/icmp_var.h U src/sys/netinet/if_ether.c U src/sys/netinet/if_ether.h U src/sys/netinet/igmp.c U src/sys/netinet/igmp.h U src/sys/netinet/igmp_var.h U src/sys/netinet/in.c U src/sys/netinet/in.h U src/sys/netinet/in_cksum.c U src/sys/netinet/in_pcb.c U src/sys/netinet/in_pcb.h U src/sys/netinet/in_proto.c U src/sys/netinet/in_systm.h U src/sys/netinet/in_var.h U src/sys/netinet/ip.h U src/sys/netinet/ip_icmp.c U src/sys/netinet/ip_icmp.h U src/sys/netinet/ip_input.c U src/sys/netinet/ip_mroute.c U src/sys/netinet/ip_mroute.h U src/sys/netinet/ip_output.c U src/sys/netinet/ip_var.h U src/sys/netinet/raw_ip.c U src/sys/netinet/tcp.h U src/sys/netinet/tcp_debug.c U src/sys/netinet/tcp_debug.h U src/sys/netinet/tcp_fsm.h U src/sys/netinet/tcp_input.c U src/sys/netinet/tcp_output.c U src/sys/netinet/tcp_seq.h U src/sys/netinet/tcp_subr.c U src/sys/netinet/tcp_timer.c U src/sys/netinet/tcp_timer.h U src/sys/netinet/tcp_usrreq.c U src/sys/netinet/tcp_var.h U src/sys/netinet/tcpip.h U src/sys/netinet/udp.h U src/sys/netinet/udp_usrreq.c U src/sys/netinet/udp_var.h U src/sys/netiso/argo_debug.h U src/sys/netiso/clnl.h U src/sys/netiso/clnp.h U src/sys/netiso/clnp_debug.c U src/sys/netiso/clnp_er.c U src/sys/netiso/clnp_frag.c U src/sys/netiso/clnp_input.c U src/sys/netiso/clnp_options.c U src/sys/netiso/clnp_output.c U src/sys/netiso/clnp_raw.c U src/sys/netiso/clnp_stat.h U src/sys/netiso/clnp_subr.c U src/sys/netiso/clnp_timer.c U src/sys/netiso/cltp_usrreq.c U src/sys/netiso/cltp_var.h U src/sys/netiso/cons.h U src/sys/netiso/cons_pcb.h U src/sys/netiso/eonvar.h U src/sys/netiso/esis.c U src/sys/netiso/esis.h U src/sys/netiso/idrp_usrreq.c U src/sys/netiso/if_cons.c U src/sys/netiso/if_eon.c U src/sys/netiso/iso.c U src/sys/netiso/iso.h U src/sys/netiso/iso_chksum.c U src/sys/netiso/iso_errno.h U src/sys/netiso/iso_pcb.c U src/sys/netiso/iso_pcb.h U src/sys/netiso/iso_proto.c U src/sys/netiso/iso_snpac.c U src/sys/netiso/iso_snpac.h U src/sys/netiso/iso_var.h U src/sys/netiso/tp.trans U src/sys/netiso/tp_astring.c U src/sys/netiso/tp_clnp.h U src/sys/netiso/tp_cons.c U src/sys/netiso/tp_driver.c U src/sys/netiso/tp_emit.c U src/sys/netiso/tp_events.h U src/sys/netiso/tp_inet.c U src/sys/netiso/tp_input.c U src/sys/netiso/tp_ip.h U src/sys/netiso/tp_iso.c U src/sys/netiso/tp_meas.c U src/sys/netiso/tp_meas.h U src/sys/netiso/tp_output.c U src/sys/netiso/tp_param.h U src/sys/netiso/tp_pcb.c U src/sys/netiso/tp_pcb.h U src/sys/netiso/tp_seq.h U src/sys/netiso/tp_stat.h U src/sys/netiso/tp_states.h U src/sys/netiso/tp_states.init U src/sys/netiso/tp_subr.c U src/sys/netiso/tp_subr2.c U src/sys/netiso/tp_timer.c U src/sys/netiso/tp_timer.h U src/sys/netiso/tp_tpdu.h U src/sys/netiso/tp_trace.c U src/sys/netiso/tp_trace.h U src/sys/netiso/tp_user.h U src/sys/netiso/tp_usrreq.c U src/sys/netiso/tuba_subr.c U src/sys/netiso/tuba_table.c U src/sys/netiso/tuba_table.h U src/sys/netiso/tuba_usrreq.c U src/sys/netiso/xebec/Makefile U src/sys/netiso/xebec/debug.h U src/sys/netiso/xebec/llparse.c U src/sys/netiso/xebec/llparse.h U src/sys/netiso/xebec/llscan.c U src/sys/netiso/xebec/main.c U src/sys/netiso/xebec/main.h U src/sys/netiso/xebec/malloc.c U src/sys/netiso/xebec/malloc.h U src/sys/netiso/xebec/procs.c U src/sys/netiso/xebec/procs.h U src/sys/netiso/xebec/putdriver.c U src/sys/netiso/xebec/sets.c U src/sys/netiso/xebec/sets.h U src/sys/netiso/xebec/test.trans U src/sys/netiso/xebec/test_def.h U src/sys/netiso/xebec/xebec.bnf U src/sys/netiso/xebec/xebec.c U src/sys/netiso/xebec/xebec.h U src/sys/netns/idp.h U src/sys/netns/idp_usrreq.c U src/sys/netns/idp_var.h U src/sys/netns/ns.c U src/sys/netns/ns.h U src/sys/netns/ns_cksum.c U src/sys/netns/ns_error.c U src/sys/netns/ns_error.h U src/sys/netns/ns_if.h U src/sys/netns/ns_input.c U src/sys/netns/ns_ip.c U src/sys/netns/ns_output.c U src/sys/netns/ns_pcb.c U src/sys/netns/ns_pcb.h U src/sys/netns/ns_proto.c U src/sys/netns/sp.h U src/sys/netns/spidp.h U src/sys/netns/spp_debug.c U src/sys/netns/spp_debug.h U src/sys/netns/spp_timer.h U src/sys/netns/spp_usrreq.c U src/sys/netns/spp_var.h U src/sys/nfs/nfs_vfsops.c U src/sys/scsi/scsiconf.h U src/sys/sys/domain.h U src/sys/sys/malloc.h U src/sys/sys/mbuf.h U src/sys/sys/proc.h U src/sys/sys/protosw.h U src/sys/sys/socket.h U src/sys/sys/socketvar.h U src/sys/sys/syslog.h U src/sys/sys/un.h U src/sys/sys/unpcb.h U src/sys/ufs/ufs_vfsops.c U src/sys/vm/vm_glue.c U src/usr.bin/netstat/Makefile U src/usr.bin/netstat/if.c U src/usr.bin/netstat/inet.c U src/usr.bin/netstat/iso.c U src/usr.bin/netstat/main.c U src/usr.bin/netstat/mbuf.c U src/usr.bin/netstat/mroute.c U src/usr.bin/netstat/netstat.1 U src/usr.bin/netstat/netstat.h U src/usr.bin/netstat/ns.c U src/usr.bin/netstat/route.c U src/usr.bin/netstat/unix.c U src/usr.bin/vmstat/vmstat.c U src/usr.sbin/arp/Makefile U src/usr.sbin/arp/arp.8 U src/usr.sbin/arp/arp.c U src/usr.sbin/arp/arp4.4 U src/usr.sbin/sysctl/sysctl.c Updating tar files: src/usr.sbin: tarring... gzipping... replacing... done src/usr.bin: tarring... gzipping... replacing... done src/sys: tarring... gzipping... replacing... done src/share: tarring... gzipping... replacing... done src/sbin: tarring... gzipping... replacing... done src/libexec: tarring... gzipping... replacing... done src/lib: tarring... gzipping... replacing... done src/include: tarring... gzipping... replacing... done src/gnu: tarring... gzipping... replacing... done src/games: tarring... gzipping... replacing... done src/etc: tarring... gzipping... replacing... done src/regress: tarring... gzipping... replacing... done src/bin: tarring... gzipping... replacing... done othersrc/kermit: tarring... gzipping... replacing... done othersrc/sup: tarring... gzipping... replacing... done othersrc/gated-2.1: tarring... gzipping... replacing... done config: tarring... gzipping... replacing... done config.new: tarring... gzipping... replacing... done Running the SUP scanner: SUP Scan for current starting at Fri May 13 05:26:18 1994 SUP Scan for current completed at Fri May 13 05:29:06 1994 SUP Scan for mirror starting at Fri May 13 05:29:08 1994 SUP Scan for mirror completed at Fri May 13 05:31:58 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 18:04:12 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, s_grau@ira.uka.de Subject: Re: Building gcc-2.5.8 Sender: owner-current-users@sun-lamp.cs.berkeley.edu What about incorporating a more up-to-date gcc than gcc-2.4.5 into the source tree? Is there something *wrong* with the one currently in the tree? It seems to work just fine for everything I've built. Updating for the sake of updating is silly; it leads to more bugs and more of our time wasted. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 18:12:24 1994 To: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re:Building gcc-2.5.8 From: Guenther Grau Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ewan Tempero wrote: >I have been trying to build gcc-2.5.8. When I compared stage3 with stage2 >I got differences in the following files: [...] >I assume someone has already done this (surely someone other than me >wants a more up-to-date g++). Can said someone please shed any light >on what my problem is? What about incorporating a more up-to-date gcc than gcc-2.4.5 into the source tree? If there are any diffs between the stock gcc and the one we need for NetBSD, why not reporting them back to the gcc maintainers and have them create some defines for NetBSD in gcc? I don't think that it will be a great problem to have the gnu-folks incorporating our changes. This would make it easier to port gcc to NetBSD in future releases. >I'm running Netbsd-current of about april 29 (timezones etc make it hard >to be precise). I configured with i386-unknown-bsd, there being no >netbsd available. See above. Any comments? Guenther From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 18:59:02 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Building gcc-2.5.8 From: Guenther Grau Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What about incorporating a more up-to-date gcc than gcc-2.4.5 into > the source tree? > >Is there something *wrong* with the one currently in the tree? It seems >to work just fine for everything I've built. Not exactly *wrong*, but I don't think the gcc-maintainer haven't changed anything in the following versions, but the version numbers, or do you? Maybe you should have a look at the changelog to see what has changed. To give you an example which might not bother you that much, but which bothers me alot, is that gcc-2.4.5 produces one of the worst m68k-codes ever. This changed in the later versions an assembly code of gcc-2.5.8 is quite good again. I am sure there are other reasons, even for you, to have gcc updated. What is important to me is that we incorporate the changes necessary back into the gcc-mainstream, so future ports will be easier. This would also allow the individual user to choose when to update and not depending on the src in the NetBSD-tree. >Updating for the sake of updating is silly; it leads to more bugs and >more of our time wasted. Agreed!!! Guenther From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 20:23:00 1994 From: phil@cs.wwu.edu (Phil Nelson) To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu, s_grau@ira.uka.de Subject: Building gcc-2.5.8 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What about incorporating a more up-to-date gcc than gcc-2.4.5 into > the source tree? > >Is there something *wrong* with the one currently in the tree? It seems >to work just fine for everything I've built. **YES** For the pc532 (ns32k) port, gcc-2.4.5 has *TOO MANY* bugs. I need 2.5.8 to compile a reliable kernel. (It has some optimization bugs that change the meaninig of code ... and when optimization was turned off, things really went bad.) Also, the shared lib work for the ns32k (which is not yet fully in the tree) was done to 2.5.8. And finally, 2.4.5 cc1plus can not compile the C++ in the source tree on the pc532. So for the pc532 port to have its compiler in the tree, we need to update. I would recommend that the gcc2/arch/xxx/insn-yyyy.c files NOT be part of the tree but get generated from the config files. --Phil From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 20:29:37 1994 From: "I can teach you how to fish..." 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: 3145 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: "Chris G. Demetriou" , Manuel Bouyer Subject: Re: chmod g+s on directory Cc: deraadt@fsa.ca, current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu "Chris G. Demetriou" writes... /* * > So, the behavior for an UFS file system and a NFS one should be the same, i * > think. * * Note even close. UFS defines a certain set of semantics, which it * follows. NFS defines a different set (and for things like this, * follows the server's idea of what's right). * * You can't say "it works this way on UFS, so it should work this way * on NFS" -- that's just not the way it works. [ I realise most of us know what NFS does and I apologise if this wasted too much bandwidth. I think I understand what happens, more or less; may I clarify for those who are even fuzzier on this than I am? ] For those who are unclear on NFS (forgive the redundancy of the following thought): Chris is right on the money here. If you're a NetBSD machine and you're mounting a SunOS filesystem NFS, the interactions follow those of the fileserver. When you do transactions on a NFS, the vn subsystem just throws RPC calls at the server, and it's up to the server to handle the calls. If you do NetBSD-NetBSD, you will find that the NFS semantics and the UFS semantics are identical; but SunOS/SVR4/SVR3/SVR2(Yuck!) will all do something different (and yes there are implementations of SVR{2,3} with NFS built in -- I worked on one), i.e. if you say "mkdir(path, mode)", the kernel goes to (vn_ops)->vn_mkdir(path,mode) and eventually ends up passing an RPC(NFS_MKDIR, PATH, MODE) to the server [ these names are almost certainly wrong, but I think the general procedure is correct, barring locking and error checking for brevity ]. The server then LOCALLY translates the mount and calls mkdir(new_path,mode), not caring what kind of OS the request came from. * cgd */ [ End of excerpt from cgd@postgres.berkeley.edu ("Chris G. Demetriou") ] Make a hacker happy. Use a *real* OS. -- ________ _____ ____ ________ _____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 Woof... From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 20:36:37 1994 From: mark@aggregate.com (Mark P. Gooderum) To: mycroft@gnu.ai.mit.edu Subject: Re: Building gcc-2.5.8 Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 2478 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What about incorporating a more up-to-date gcc than gcc-2.4.5 into > the source tree? > > Is there something *wrong* with the one currently in the tree? It seems > to work just fine for everything I've built. > > Updating for the sake of updating is silly; it leads to more bugs and > more of our time wasted. True, but 2.5.8 is very stable and there are several key improvements in 2.5.8 that aren't in 2.4.5 that are nice, matter now, or will matter in the future. >From reading the NEWS file in 2.5.8 back to 2.5.0, key things are: Power PC and fixed Power RISC support C++ fixes for local variables and nested type references Complex number support and some other NECG related bits Real long doubles on Sparc and i386 Support for hints to optimizer (for no return and no side effects) ARM/ANSI overloading behavior (very important for porting many C++ programs originally written on cfront based systems) Much better C++ nesting support Other ARM/ansi compliance fixes Much better sparc, pa-risc, and i386 (with m586) code generation I've heard that -m586 even with a 486 can provide a good win in 2.5.8. But there is nothing that keeps a user from building it themselves. I would be curious though if someone who did the initial incorporation of the 2.4.5 sources could just post what changes needed to be done for that (not counting just reorganization of the build into the source tree). However, I agree that this would take a fair bit of work and there are much more important things to do for now given that gcc/g++ do work fine as they are for all (most?) of us, and that updating for the sake of updating is silly. Gas is one good example...the first version of gas after incorporation of the bfd stuff was as much as *100 times* slower, and even today is still 2-3 times slower that it was before this change...and its arguable what the bfd support buys you at this level. It would be also be nice if somebody could send/submit a set of -netbsd changes to the gcc maintainers for 2.5.8. I'd be game but with getting married in a week it would have to wait a bit. One important note though is that g++ >= 2.5.5 is not compatible with older g++ versions/libraries. The name mangling has changed. Another thing is that more that one person has suggested that the g++/libg++ release from Cygnus is much better shape than the FSF release especially in the iostreams library, these can be found at: ftp.cygnus.com:/pub/reno-1.3.tar.gz -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 20:45:34 1994 From: Manuel Bouyer Subject: Re: chmod g+s on directory To: greywolf@autodesk.com (I can teach you how to fish...) Cc: current-users@sun-lamp.cs.berkeley.edu (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: 1441 Sender: owner-current-users@sun-lamp.cs.berkeley.edu greywolf@autodesk.com wrote: > > [ I realise most of us know what NFS does and I apologise if this wasted > too much bandwidth. I think I understand what happens, more or less; > may I clarify for those who are even fuzzier on this than I am? ] > > For those who are unclear on NFS (forgive the redundancy of the following > thought): > > Chris is right on the money here. If you're a NetBSD machine and you're > mounting a SunOS filesystem NFS, the interactions follow those of the > fileserver. When you do transactions on a NFS, the vn subsystem just > throws RPC calls at the server, and it's up to the server to handle the > calls. If you do NetBSD-NetBSD, you will find that the NFS semantics > and the UFS semantics are identical; but SunOS/SVR4/SVR3/SVR2(Yuck!) > will all do something different Yes, whith an NetBSD nfs server, NFS and UFS semantics are identical. The problem for me (and, i think for all people which uses SunOS nfs servers and don't want to do a chgrp each time they create a file) is that a SunOS nfs server always create files whith the group id specified by the client (i.e. the gid of the user on NetBSD), even if the directory has the SGID bit set. In this case, the semetic is defined by the client. I know, this is a problem from SunOS, and not from NetBSD, but i don't have SunOS sources ... -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 13 20:53:46 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 --------------------------------- From: The Source Master briggs Fri May 6 10:37:41 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/m68k/m68k Modified Files: copy.s Log Message: Add fuswintr and suswintr. briggs Fri May 6 10:38:43 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k/dev In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/dev Modified Files: asc.c Log Message: Missed some warnings... briggs Fri May 6 10:39:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Modified Files: cpu.h param.h proc.h Log Message: Get things to compile with latest changes. briggs Fri May 6 10:39:57 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k/mac68k In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/mac68k Modified Files: clock.c genassym.c locore.s machdep.c mem.c trap.c vm_machdep.c Log Message: Get things to compile with latest changes. --------------------------------- From: The Source Master chopps Sat May 7 22:47:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga Modified Files: Makefile Log Message: fix tags. --------------------------------- From: The Source Master chopps Sat May 7 22:52:35 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c autoconf.c cia.c conf.c disksubr.c genassym.c locore.s machdep.c pmap.c swapgeneric.c trap.c vectors.s vm_machdep.c Removed Files: clock.c clockioctl.h Log Message: resistance is futile, you will be assimilated. amiga goes: config.new *and* /sys/scsi. clock code coerced into a single .c file adding an accurate usec delay(). disklabel.c updated to DTRT, code to write RDB's to be added soon. sbic (old scsi) converted over to new scsi and config this covers about 90% of users. Other drivers soon. chopps Sat May 7 22:52:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Makefile.amiga Removed Files: devices.amiga files.amiga Log Message: resistance is futile, you will be assimilated. amiga goes: config.new *and* /sys/scsi. clock code coerced into a single .c file adding an accurate usec delay(). disklabel.c updated to DTRT, code to write RDB's to be added soon. sbic (old scsi) converted over to new scsi and config this covers about 90% of users. Other drivers soon. chopps Sat May 7 22:53:54 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: dmavar.h grf.c grf_cc.c grf_ccreg.h grf_rt.c grf_rtreg.h grfabs.c grfvar.h ite.c ite_cc.c ite_rt.c itevar.h kbd.c kf_8x11.c kf_8x8.c ms.c par.c sci.c scivar.h sd.c ser.c serreg.h siop.c view.c Added Files: ahsc.c ahscreg.h atzsc.c atzscreg.h clock.c clockioctl.h gtsc.c gtscreg.h gvpbus.c gvpbusvar.h ivsc.c mgnsc.c mlhsc.c otgsc.c rtc.h rtmondefs.c rtmons sbic.c sbicreg.h sbicvar.h wstsc.c zssc.c ztwobus.c ztwobusvar.h Removed Files: a2091dma.c a2091dmareg.h a3000dma.c a3000dmareg.h csa12gdma.c device.h grf_tg.c gvp11dma.c gvp11dmareg.h ite_tg.c ivsdma.c magnumdma.c mlhdma.c retina-mondefs.c retina-monitors rtclocka.c rtclocka_var.h rtclockb.c rtclockb_var.h scsi.c scsireg.h scsivar.h supradma.c zeusdma.c Log Message: resistance is futile, you will be assimilated. amiga goes: config.new *and* /sys/scsi. clock code coerced into a single .c file adding an accurate usec delay(). disklabel.c updated to DTRT, code to write RDB's to be added soon. sbic (old scsi) converted over to new scsi and config this covers about 90% of users. Other drivers soon. chopps Sat May 7 22:54:01 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: cpu.h param.h proc.h pte.h Added Files: disklabel.h Log Message: resistance is futile, you will be assimilated. amiga goes: config.new *and* /sys/scsi. clock code coerced into a single .c file adding an accurate usec delay(). disklabel.c updated to DTRT, code to write RDB's to be added soon. sbic (old scsi) converted over to new scsi and config this covers about 90% of users. Other drivers soon. chopps Sat May 7 22:54:41 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Added Files: files.amiga.newconf Log Message: oops forgot one. chopps Sat May 7 22:56:21 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Added Files: adosglue.h cfdev.h device.h Log Message: a few files that were forgoton in the last batch. chopps Sat May 7 22:56:54 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Added Files: std.amiga Log Message: a few files that were forgoton in the last batch. --------------------------------- From: The Source Master chopps Sun May 8 11:21:40 PDT 1994 Update of /b/source/CVS/src/sys/sys In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/sys Modified Files: disklabel.h Log Message: Amiga now has a machine/disklabel.h --------------------------------- From: The Source Master cgd Sun May 8 21:02:34 PDT 1994 Update of /b/source/CVS/src/usr.sbin/sysctl In directory sun-lamp.cs.berkeley.edu:/usr/src/usr.sbin/sysctl Modified Files: sysctl.c Log Message: punt networking goo for now cgd Sun May 8 21:09:26 PDT 1994 Update of /b/source/CVS/src/lib/libkvm In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libkvm Modified Files: Makefile Added Files: kvm_m68k.c Removed Files: kvm_hp300.c Log Message: m68k-ify the hp300 kvm file; use MACHINE_ARCH to pick files up --------------------------------- From: The Source Master glass Sun May 8 23:36:23 PDT 1994 Update of /b/source/CVS/src/usr.bin/make In directory sun-lamp.cs.berkeley.edu:/c/users/glass/src/usr.bin/make Modified Files: Makefile.boot make.h util.c Log Message: bootstrap improvements glass Sun May 8 23:36:25 PDT 1994 Update of /b/source/CVS/src/usr.bin/make/lst.lib In directory sun-lamp.cs.berkeley.edu:/c/users/glass/src/usr.bin/make/lst.lib Modified Files: Makefile Log Message: bootstrap improvements chopps Sun May 8 23:38:04 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: machdep.c swapgeneric.c trap.c Log Message: update for recent sig changes and fix clock.c chopps Sun May 8 23:38:41 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: clock.c ite.c Log Message: update for recent sig changes and fix clock.c and ite.c chopps Sun May 8 23:38:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: cpu.h Log Message: update for recent sig changes and fix clock.c and ite.c --------------------------------- From: The Source Master chopps Mon May 9 04:44:34 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/m68k/include Modified Files: ansi.h Log Message: Add _SSIZE_T_. --------------------------------- From: The Source Master chopps Mon May 9 05:39:39 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/m68k/include Modified Files: limits.h Log Message: Add SSIZE_MAX and SIZE_T_MAX, also fix other broken values. --------------------------------- From: The Source Master gwr Mon May 9 09:17:10 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/m68k/m68k Modified Files: db_disasm.c Log Message: This file was using off_t where it should have had db_expr_t and these are, of course, no longer the same thing. --------------------------------- From: The Source Master chopps Tue May 10 01:15:58 PDT 1994 Update of /b/source/CVS/src/lib/libc/arch/m68k/gen In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/lib/libc/arch/m68k/gen Modified Files: setjmp.S Log Message: update to use sigaltstack. --------------------------------- From: The Source Master chopps Wed May 11 11:47:54 PDT 1994 Update of /b/source/CVS/src/sys/adosfs In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/adosfs Log Message: Directory /b/source/CVS/src/sys/adosfs added to the repository chopps Wed May 11 11:49:21 PDT 1994 Update of /b/source/CVS/src/sys/adosfs In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/adosfs Added Files: adlookup.c adosfs.h adutil.c advfsops.c advnops.c Log Message: First version of AmigaDOS fast file system. needs work, read only. --------------------------------- From: The Source Master chopps Wed May 11 12:03:00 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: autoconf.c disksubr.c genassym.c locore.s machdep.c Log Message: fix mmutype recocgnition cleanup cpu identify and other boot diags. chopps Wed May 11 12:03:35 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Makefile.amiga Log Message: compile genassym static and add adosfs to GENERIC chopps Wed May 11 12:06:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ahsc.c atzsc.c grf.c gtsc.c ite.c iteioctl.h ser.c ztwobus.c Log Message: general cleanup including boot diag messages. chopps Wed May 11 12:09:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/stand/loadkmap In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/stand/loadkmap Modified Files: loadkmap.c Log Message: update to new ioctl names --------------------------------- From: The Source Master chopps Wed May 11 22:56:35 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c autoconf.c locore.s machdep.c Log Message: update from osymh@gemini.oscs.montana.edu (Michael L. Hitch) add support for zthreebus siop scsi drivers and better machine recocgnition. chopps Wed May 11 22:57:02 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC files.amiga.newconf std.amiga Log Message: update from osymh@gemini.oscs.montana.edu (Michael L. Hitch) add support for zthreebus siop scsi drivers and better machine recocgnition. chopps Wed May 11 22:57:27 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: mgnsc.c siop.c siopreg.h siopvar.h zssc.c Log Message: update from osymh@gemini.oscs.montana.edu (Michael L. Hitch) add support for zthreebus siop scsi drivers and better machine recocgnition. chopps Wed May 11 22:57:34 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/stand/loadbsd In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/stand/loadbsd Modified Files: loadbsd.c Log Message: update from osymh@gemini.oscs.montana.edu (Michael L. Hitch) add support for zthreebus siop scsi drivers and better machine recocgnition. --------------------------------- From: The Source Master chopps Wed May 11 23:00:11 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Added Files: wesc.c zthreebus.c zthreebusvar.h Log Message: new scsi siop drivers and zthreebus support from osymh@gemini.oscs.montana.edu (Michael L. Hitch) --------------------------------- From: The Source Master chopps Wed May 11 23:43:13 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: sbic.c siop.c Log Message: ifdef out use of scsi_xfer->req_sense_length for now.. --------------------------------- From: The Source Master gwr Thu May 12 21:41:47 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/m68k/m68k Modified Files: db_trace.c Log Message: Fix parentheses bug in code that counts function args. gwr Thu May 12 21:46:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/m68k/m68k Modified Files: db_disasm.c Log Message: Print offset from symbol in same format as input parser understands (so they can be cut and pasted in an xterm). --------------------------------- From: The Source Master mycroft Thu May 12 23:01:42 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/kern Modified Files: sys_socket.c uipc_domain.c uipc_mbuf.c uipc_proto.c uipc_socket.c uipc_socket2.c Log Message: Update to 4.4-Lite networking code, with a few local changes. cgd Thu May 12 23:02:50 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/kern Modified Files: subr_prf.c Log Message: update; minor clean, cruft removal. mycroft Thu May 12 23:03:34 PDT 1994 Update of /b/source/CVS/src/sys/net In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/net Modified Files: bpf.c bpf.h bpf_filter.c bpfdesc.h if.c if.h if_arp.h if_dl.h if_ethersubr.c if_llc.h if_loop.c if_ppp.c if_sl.c if_slvar.h if_types.h netisr.h radix.c radix.h raw_cb.c raw_cb.h raw_usrreq.c route.c route.h rtsock.c slcompress.c slcompress.h slip.h Log Message: Update to 4.4-Lite networking code, with a few local changes. mycroft Thu May 12 23:05:12 PDT 1994 Update of /b/source/CVS/src/sys/netccitt In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/netccitt Modified Files: README.hdlc README.packet ccitt_proto.c hd_debug.c hd_input.c hd_output.c hd_subr.c hd_timer.c hd_var.h hdlc.h if_x25subr.c pk.h pk_acct.c pk_debug.c pk_input.c pk_output.c pk_subr.c pk_timer.c pk_usrreq.c pk_var.h x25.h x25acct.h x25err.h Added Files: dll.h llc_input.c llc_output.c llc_subr.c llc_timer.c llc_var.h pk_llcsubr.c Log Message: Update to 4.4-Lite networking code, with a few local changes. mycroft Thu May 12 23:06:59 PDT 1994 Update of /b/source/CVS/src/sys/netinet In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/netinet Modified Files: icmp_var.h if_ether.c if_ether.h igmp.c igmp.h igmp_var.h in.c in.h in_cksum.c in_pcb.c in_pcb.h in_proto.c in_systm.h in_var.h ip.h ip_icmp.c ip_icmp.h ip_input.c ip_mroute.c ip_mroute.h ip_output.c ip_var.h raw_ip.c tcp.h tcp_debug.c tcp_debug.h tcp_fsm.h tcp_input.c tcp_output.c tcp_seq.h tcp_subr.c tcp_timer.c tcp_timer.h tcp_usrreq.c tcp_var.h tcpip.h udp.h udp_usrreq.c udp_var.h Log Message: Update to 4.4-Lite networking code, with a few local changes. chopps Thu May 12 23:07:09 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: Locore.c locore.s trap.c Log Message: setrq -> setrunqueue --------------------------------- From: The Source Master mycroft Fri May 13 03:40:32 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/include Modified Files: profile.h Log Message: Do this better. mycroft Fri May 13 03:41:03 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/include Added Files: profile.h Log Message: Needed for new profiling code. mycroft Fri May 13 03:47:59 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/include Modified Files: profile.h Log Message: Need some more macros not in the 4.4-Lite version. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 21:03:58 1994 From: Manuel Bouyer Subject: Re: Building gcc-2.5.8 To: jfw@ksr.com (John F. Woods) Cc: bouyer@ensta.fr, 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: 322 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > I think there is a bug in gcc2.4.5 optimisation. > > There is a bug in your code. The variable "index" in main() is used > before it is set. Fix the program and try again. > You're rigth. It works now. Sorry. -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 21:19:09 1994 From: Manuel Bouyer Subject: Re: Building gcc-2.5.8 To: current-users@sun-lamp.cs.berkeley.edu (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: 6446 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What about incorporating a more up-to-date gcc than gcc-2.4.5 into > the source tree? > >Is there something *wrong* with the one currently in the tree? It seems >to work just fine for everything I've built. I think there is a bug in gcc2.4.5 optimisation. The folloing code works for me (pc 486 dx2 66, tar-balls from 16 april) whith cc or cc -g, but not whith cc -O. Compile whith cc -o rdate rdate.c, and then rdate . repeat whith cc -O and see. rdate.c: /* Ce programme est l'equivalent de rdate (Sun). Ecrit par P.Chiccourat. Usage: rdate */ #include #include #include #include #include #define OFFSET 0x83aa7e80 int length[] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 }; main(argc,argv) int argc; char **argv; { unsigned char s[1024], *t; union time { u_long l; unsigned char c[sizeof(u_long)]; } clock; int fd, pid, l, index; union wait status; struct tm *tm; int fildes[2]; struct timeval timeval; struct timezone timezon; gettimeofday(&timeval,&timezon); tm = localtime(&timeval.tv_sec); if (argc != 2) { fprintf(stderr,"Use: getdate \n"); exit(3); } if ((fd = c_clientbyname(argv[1],"time")) == -1) { printf("Error when creating socket\n"); exit (1); } pipe(fildes); if (!(pid = fork())) { close(fildes[0]); while ((l = read(fd,s,1024)) > 0) { write(fildes[1],s,l); #ifdef DEBUG t = s; while (t - s < l) fprintf(stderr,"> %02x",*t++); #endif } close(fildes[1]); exit(0); } else { close(fildes[1]); while ((l = read(fildes[0],s,1024)) > 0) { #ifdef DEBUG fprintf(stderr,"Read: %d\n",l); #endif t = s; while ((t - s < l) && (index < sizeof(u_long))) { #ifdef DEBUG fprintf(stderr,"< %02x",*t); #endif clock.c[index++] = *t++; } } wait(&status); clock.l = ntohl(clock.l) - OFFSET; if (index != sizeof(u_long)) { fprintf(stderr,"getdate: Unable to get a correct answer\n"); exit(1); } gettimeofday(&timeval,&timezon); #ifdef DEBUG fprintf(stderr,"Was %lx, now %lx\n",timeval.tv_sec, clock.l); #endif timeval.tv_sec = clock.l; timeval.tv_usec = 0; #ifndef SGI if (settimeofday(&timeval,&timezon) == -1) { #else if (stime(&timeval.tv_sec) == -1) { #endif perror("getdate"); #ifdef DEBUG exit(2); #endif } gettimeofday(&timeval,&timezon); tm = localtime(&clock.l); printf("Date set to: %02d/%02d/%02d %02d:%02d:%02d (from %s)\n", tm->tm_mday, tm->tm_mon+1, tm->tm_year, tm->tm_hour, tm->tm_min, tm->tm_sec, argv[1]); exit(0); } } /* * * * Routines standard de creation de sockets cote client. * * Permet de creer des socket tcp sur un service donne). * */ #include #include #include #ifndef u_short #define u_short ushort #endif u_short /* * * Cree une socket vers un hote donne, sur un service donne, * Hote et service peuvent etre des numeros. * * Ex : sock = c_clientbyname("aneth","courier") * sock = c_clientbyname("129.199.98.20","213") * * Renvoie comme resultat : * - dans le cas tcp : la socket prete a l'emploie (sur laquelle on * peut faire des read ou des write). * */ c_clientbyname(host,name) char *host,*name; { int sock, i, num; struct sockaddr_in addr; struct servent *sv; struct hostent *hp, hp_entry; char host_number[4], *p; int host_bis[4]; /* Recupere l'adresse de l'hote cible */ if ((*host >= '0') && (*host <= '9')) { hp_entry.h_addrtype = AF_INET; hp_entry.h_length = 4; p = host_number; hp_entry.h_addr_list = &p; sscanf(host,"%d.%d.%d.%d",host_bis,host_bis+1,host_bis+2,host_bis+3); host_number[0] = host_bis[0]; host_number[1] = host_bis[1]; host_number[2] = host_bis[2]; host_number[3] = host_bis[3]; hp = &hp_entry; } else if (!(hp = gethostbyname(host))) { perror("gethostbyname"); return (-1); } /* Description du service recherche (essentiellement, le numero de port) */ if ((*name >= '0') && (*name <= '9')) { num = htons(atoi(name)); } else if (!(sv = getservbyname(name,"tcp"))) { perror("getservbyname"); return(-1); } else num = sv->s_port; /* Et on cree la socket */ if ((sock = socket(AF_INET, SOCK_STREAM,0)) == -1) { perror("socket"); return (-1); } /* Preparons l'adresse pour le connect */ /* Le type d'adresse */ /* la macro htons est un peut bidon : elle est la pour assurer */ /* la compatibilite avec le vax qui inverse les bits entre le local */ /* et ethernet .... */ addr.sin_family = hp->h_addrtype; /* Le port (recupere dans le getservbyname) */ addr.sin_port = num; /* L'adresse de l'hote cible */ #ifdef hpux memcpy( (caddr_t)&addr.sin_addr, hp->h_addr,hp->h_length); #else bcopy(hp->h_addr, (caddr_t)&addr.sin_addr, hp->h_length); #endif hpux /* Et zoup : on se connecte */ if ( connect(sock,(struct sockaddr *)&addr, sizeof(addr)) == -1){ perror("connect"); return (-1); } /* Ok ! : on a une socket en tcp de bon gout */ return (sock); } /* * * Cree une socket vers un hote donne, sur un service donne, * * Ex : sock = c_clientbyport("aneth",port) * * Renvoie comme resultat : * - dans le cas tcp : la socket prete a l'emploie (sur laquelle on * peut faire des read ou des write). * */ c_clientbyport(host,port) char *host; int port; { int sock; struct sockaddr_in addr; struct hostent *hp; /* Recupere l'adresse de l'hote cible */ if (!(hp = gethostbyname(host))){ perror("gethostbyname"); return (-1); } /* Et on cree la socket */ if ((sock = socket(AF_INET, SOCK_STREAM,0)) == -1){ perror("socket"); return (-1); } /* Preparons l'adresse pour le connect */ /* Le type d'adresse */ /* la macro htons est un peut bidon : elle est la pour assurer */ /* la compatibilite avec le vax qui inverse les bits entre le local */ /* et ethernet .... */ addr.sin_family = hp->h_addrtype; /* Le port (recupere dans le getservbyname) */ addr.sin_port = port; /* L'adresse de l'hote cible */ #ifdef hpux memcpy( (caddr_t)&addr.sin_addr, hp->h_addr,hp->h_length); #else bcopy(hp->h_addr, (caddr_t)&addr.sin_addr, hp->h_length); #endif hpux /* Et zoup : on se connecte */ if ( connect(sock,(struct sockaddr *)&addr, sizeof(addr)) == -1){ perror("connect"); return (-1); } /* Ok ! : on a une socket en tcp de bon gout */ return (sock); } -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 21:20:19 1994 To: Manuel Bouyer Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Building gcc-2.5.8 <199405131637.SAA06153@bsdtest.ensta.fr> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I think there is a bug in gcc2.4.5 optimisation. There is a bug in your code. The variable "index" in main() is used before it is set. Fix the program and try again. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 21:21:57 1994 From: mark@aggregate.com (Mark P. Gooderum) To: bouyer@ensta.fr Subject: Re: chmod g+s on directory Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 532 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Of course if we say that a user on a NetBSD system gets SysV creation semantics over NFS to a server which does such a beastie (which I agree is correct), then we really need a "newgrp" command so that said user can still have some control over the group the files are created with without having to chgrp all the time. Actually, I prefer the SysV semantics...I would be kind of nice if both ufs and nfs mounts supported the "grpid" option like Sun's NFS mount does. Then the system could select the behavior it wishes. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 23:17:20 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu, s_grau@ira.uka.de Subject: Re: Building gcc-2.5.8 From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Fri, 13 May 94 10:03:07 edt mycroft@gnu.ai.mit.edu wrote: > > What about incorporating a more up-to-date gcc than gcc-2.4.5 into > the source tree? > > Is there something *wrong* with the one currently in the tree? It seems > to work just fine for everything I've built. > > Updating for the sake of updating is silly; it leads to more bugs and > more of our time wasted. > My $.02...Please don't go to a gcc any higher then 2.4.5...I *very* quickly 'upgraded' to the older version after trying out 2.5.8 on our HPs... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 13 23:42:22 1994 From: "Segmentation Violation. Core dumped." 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: 3145 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: Manuel Bouyer , current-users@sun-lamp.cs.berkeley.edu (current-users) Subject: Re: Building gcc-2.5.8 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone want a replacement for "rdate"? I sent one to comp.sources.unix but it hasn't been posted yet. It's short, sweet, and to the point. If there is sufficient demand I'll see if I can get it disted to interested parties... Make a hacker happy. Use a *real* OS. -- ________ _____ ____ ________ _____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 My other car was on Alderaan. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat May 14 00:00:11 1994 From: Olaf Seibert To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940513 Cc: hubert.feyrer@rz.uni-regensburg.de Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hubert Feyrer wrote: > Last night I compiled the kernel from 13th may, and except for two > little things, it compiled flawlessly: > > 1.) There was an ')' missing quite at the end of .../sys/syslog.h I was compiling the 10 may sources, and fixed this too. Then I went on with the 11 may sources, and the weirdest thing happened: make depend caused my kernel to freeze! To be more specific, there is this line in Makefile: depend: assym.s param.c mkdep ... I have determined that I can make assym.s and param.c, but making depend, even with -n, will cause the kernel to freeze before it gets to print the command it wants to do. Doing stuff like make -dA (all debugging info) shows nothing after it finishes with param.c. I once managed to keep the ktrace.out file from make -n, (with luck and by mounting /usr synchronous) which ends after a vfork() call returns. Which is funny, because I wouldn't expect a make -n to do vfork. Also, hitting ^T shows a few processes besides make running (sh echo and printf), also with make -n. (This also looks fishy especially since there is no output.) The Makefile looks pretty normal to me, it was not the first time I used a Makefile from config.new, all my binaries in /usr/bin were identical to my installation tar files, (except that tar +diff reported just about all modes to be different even though visual inspection indicates they're not), the kernels I used were used pretty extensively before, etc... "I didn't change anything!" Version info: kernel self-compiled, supped 25 march, or 8 april (identical behaviour), binaries 940219 (I put off upgrading until versions after the off_t changes are available). Does this ring a bell for somebody? I hope it's not hardware related... (A4000/040, 2+8M ram, Supra Wordsync + Quantum LPS105) I'm getting a bit desperate over this situation... -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat May 14 00:31:01 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: sys.19940513 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 13, 11:27pm, Olaf Seibert wrote: > Hubert Feyrer wrote: > > Last night I compiled the kernel from 13th may, and except for two > > little things, it compiled flawlessly: > > > > 1.) There was an ')' missing quite at the end of .../sys/syslog.h > > I was compiling the 10 may sources, and fixed this too. Then I went on > with the 11 may sources, and the weirdest thing happened: make depend > caused my kernel to freeze! That sounds very much like the problem the original bash distributed on the root file systems had with the 68040. I'm assuming that you have gotten the recompiled version that I uploaded to ftp.eunet.ch? However, I did run into a problem with the recompiled version when I was trying to build lib/libc. The command substitution (which is what caused the original version of bash to hang on the 68040) ran into problems when passed a very long command. I found that bash had a fixed size string buffer that was allocated on the stack. The buffer was too small for the particular instance I ran into while building lib/libc and overwrote the stack. I've recompiled it using a larger buffer and was able to get around that problem. > Does this ring a bell for somebody? I hope it's not hardware > related... (A4000/040, 2+8M ram, Supra Wordsync + Quantum LPS105) > I'm getting a bit desperate over this situation... If you are using bash as the shell and want to try out the fixed one I'm using, I have put it on ftp.coe.montana.edu in /tmp/NetBSD-bash.gz. If you're not using bash, then I don't have any other ideas as to what's happening. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat May 14 00:31:11 1994 From: Olaf Seibert To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu, rhialto@mbfys.kun.nl Subject: Re: sys.19940513 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I wrote: >I was compiling the 10 may sources, and fixed this too. Then I went on >with the 11 may sources, and the weirdest thing happened: make depend >caused my kernel to freeze! Make that 11 and 12 may... -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat May 14 00:49:05 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: sys.19940513 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > On May 13, 11:27pm, Olaf Seibert wrote: > > Hubert Feyrer wrote: > > > Last night I compiled the kernel from 13th may, and except for two > > > little things, it compiled flawlessly: > > > > > > 1.) There was an ')' missing quite at the end of .../sys/syslog.h > > > > I was compiling the 10 may sources, and fixed this too. Then I went on > > with the 11 may sources, and the weirdest thing happened: make depend > > caused my kernel to freeze! > > That sounds very much like the problem the original bash distributed on > the root file systems had with the 68040. I'm assuming that you have gotten > the recompiled version that I uploaded to ftp.eunet.ch? I have - otherwise I wouldn't get through netstart. > However, I did run into a problem with the recompiled version when I > was trying to build lib/libc. The command substitution (which is what caused > the original version of bash to hang on the 68040) ran into problems when > passed a very long command. I found that bash had a fixed size string buffer ... > If you are using bash as the shell and want to try out the fixed one > I'm using, I have put it on ftp.coe.montana.edu in /tmp/NetBSD-bash.gz. I'll try it, and see what happens... thanks... > Michael -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 03:18:04 1994 From: gregc@edi.com (Greg Cronau) Subject: SCSI questions 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: 2382 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am currently running Netbsd current from the Aprill 6th sources. My machine is as follows: AMI Enterprise III EISA 486-66 with 12meg. Bustek 747S EISA Fast-SCSI at 0x330, int-11, DMA-5 Adaptec 1542B ISA SCSI at 0x334, int-12, DMA-6 I have an HP 1.355 gig drive on the Bustek controller. I had my Viper 2150S on the same controller. I had an extra adaptec laying around, so I decided, what the hell, let's see if both will work. They seem to co-exist just fine and I get much better throughput on my backups. This setup has run fine for over a month. 2 days ago I opened the machine up to make 2 addtions: I added an additional 8 meg of memory to bring the total to 20megs, and I added an NEC CDR-74-1 CDROM drive. I put the CDROM on the adaptec controller, becuase it seemed to be more of a "low bandwidth device". The 74-1(as opposed to the older 74) has a switch to select SCSI-I and SCSI-II operation. I set it for SCSI-II operation. During bootup, the probe seemed to find the drive just fine, but when I tried to mount a disk, I got an error from the kernel saying something to the effect "error: DMA past end of isa" or something like that. I then switched the drive to SCSI-I mode and everything works fine. The following questions come to mind: 1.) Why did I get that error in SCSI-II mode? 2.) I seem to vaguely recall a warning about mixing SCSI-I and SCSI-II devices on the same bus. This may just be computer urban legend, or may be OS/hardware dependant, because I know there is no problem doing this on a Sun for instance. Should I move the CDROM to the Bustek? 3.) Will the abiility to run the CDROM in SCSI-II mode buy me anything? 4.) My machine is EISA and the Bustek is EISA, but the adaptec is only ISA. Could this problem have something to do with the extra memory I added? 5.) Does Netbsd properly handle DMA to ISA devices from memory beyond the 16mem boundary? Weird question: Now that I have added the extra memory, I notice a couple of operations in X that actually seem alittle *slower*. Is it possible that somewhere in NetBSD their is code that detects the fact that: a.) There is more than 16meg of memory, and b.) there is an ISA device present and then switches the system into some kind of double buffer mode to compensate? I can't think of any reason that *more* memory should make an X app *slower*. Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 04:16:53 1994 From: gregc@edi.com (Greg Cronau) Subject: SCSI questions 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: 2382 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am currently running Netbsd current from the Aprill 6th sources. My machine is as follows: AMI Enterprise III EISA 486-66 with 12meg. Bustek 747S EISA Fast-SCSI at 0x330, int-11, DMA-5 Adaptec 1542B ISA SCSI at 0x334, int-12, DMA-6 I have an HP 1.355 gig drive on the Bustek controller. I had my Viper 2150S on the same controller. I had an extra adaptec laying around, so I decided, what the hell, let's see if both will work. They seem to co-exist just fine and I get much better throughput on my backups. This setup has run fine for over a month. 2 days ago I opened the machine up to make 2 addtions: I added an additional 8 meg of memory to bring the total to 20megs, and I added an NEC CDR-74-1 CDROM drive. I put the CDROM on the adaptec controller, becuase it seemed to be more of a "low bandwidth device". The 74-1(as opposed to the older 74) has a switch to select SCSI-I and SCSI-II operation. I set it for SCSI-II operation. During bootup, the probe seemed to find the drive just fine, but when I tried to mount a disk, I got an error from the kernel saying something to the effect "error: DMA past end of isa" or something like that. I then switched the drive to SCSI-I mode and everything works fine. The following questions come to mind: 1.) Why did I get that error in SCSI-II mode? 2.) I seem to vaguely recall a warning about mixing SCSI-I and SCSI-II devices on the same bus. This may just be computer urban legend, or may be OS/hardware dependant, because I know there is no problem doing this on a Sun for instance. Should I move the CDROM to the Bustek? 3.) Will the abiility to run the CDROM in SCSI-II mode buy me anything? 4.) My machine is EISA and the Bustek is EISA, but the adaptec is only ISA. Could this problem have something to do with the extra memory I added? 5.) Does Netbsd properly handle DMA to ISA devices from memory beyond the 16mem boundary? Weird question: Now that I have added the extra memory, I notice a couple of operations in X that actually seem alittle *slower*. Is it possible that somewhere in NetBSD their is code that detects the fact that: a.) There is more than 16meg of memory, and b.) there is an ISA device present and then switches the system into some kind of double buffer mode to compensate? I can't think of any reason that *more* memory should make an X app *slower*. Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 05:16:37 1994 From: Dave Burgess Subject: Everything I compile core dumps.... To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1094 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, this has been an interesting couple of days. I rebuilt the kernel last week: -rwxr-xr-x 1 root wheel 768862 May 8 21:50 /netbsd Now, whenever I recompile a program, it core dumps with this error: Bad system call (core dumped) Any good ideas? I rebuilt the libraries (are we really supposed to be up to version 11 (/usr/lib/libc.so.11.0)) in the shred libs. I also rebuilt all of the other standard libraries. It started with make. I rebuilt make using the old static library. It started to barf. I then reloaded make from the tar_files, and proceeded agin from there. I rebuilt everything the usr /usr/src/gnu directory tree and tried them before I installed them. Good thing too. Every one of them pukes on its shoes. Now, since I am the ONLY person on the planet that seems to be having this problem (why is that such a common ocurrance????) I was wondering what I did (or didn't do)? OBTW: The console keyboard hangs on CRON startups are back. It has happened twice. The bad news is that they keyboard doesn't ever return now. Color me more confused than usual. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat May 14 05:47:47 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Hubert Feyrer , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940513 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 13, 3:09pm, Hubert Feyrer wrote: > 1.) There was an ')' missing quite at the end of .../sys/syslog.h Looks like this was fixed in the 940513 changes. > 2.) ttnread must be non-static in .../kern/tty.c No, the reference to ttnread is from extraneous code in amiga/ser.c - the serselect routine is no longer used, so needs to be removed. > But after that, friday 13th took his toll: When I tried loading it > (either from /dev/reboot or via loadbsd), it barfed on me. After > loadbsd tells his story about availabel memory etc., all I get is a > black screen! I just compiled the 940513 sources, and after removing serselect in amiga/ser.c, it linked with no problem and booted up just fine on my PPI Zeus system. I have put the 2.4 version of loadbsd (latest and greatest) on ftp.coe.montana.edu as /tmp/loadbsd-2.4.gz. [Ftp.eunet.ch appears to be out of disk space.] This version should be able to detect the A4000, A3000, and A2000/A500 systems and hopefully any kernels after 940512 shouldn't need the _a4000_flag and _a3000_flag values binpatched. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 05:48:46 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Dave Burgess Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Everything I compile core dumps.... <199405140124.UAA01248@s069.infonet.net> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I rebuilt the libraries (are we really supposed to be up to version 11 > (/usr/lib/libc.so.11.0)) in the shred libs. I also rebuilt all of the > other standard libraries. but i bet you didn't MAKE SURE you rebuilt your crt0.o from scratch. make depend/make won't do it right... > OBTW: The console keyboard hangs on CRON startups are back. It has > happened twice. The bad news is that they keyboard doesn't ever return > now. really? that's news to me... i've not had any problems with it since last i got done hacking on it... cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 06:39:34 1994 From: Michael Graff To: Dave Burgess Subject: Re: Everything I compile core dumps.... To: netbsd-current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Now, whenever I recompile a program, it core dumps with this error: >Bad system call (core dumped) >Any good ideas? Build a new kernel. I just did that, and it all works again. And I can't even get libc to build as of the latest sources. :( From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 06:53:09 1994 To: gregc@edi.com (Greg Cronau) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SCSI questions From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I am currently running Netbsd current from the Aprill 6th sources. >My machine is as follows: > > AMI Enterprise III EISA 486-66 with 12meg. > Bustek 747S EISA Fast-SCSI at 0x330, int-11, DMA-5 > Adaptec 1542B ISA SCSI at 0x334, int-12, DMA-6 > >2 days ago I opened the machine up to make 2 addtions: I added an additional >8 meg of memory to bring the total to 20megs, >5.) Does Netbsd properly handle DMA to ISA devices from memory beyond the > 16mem boundary? No. It has been posted repeatedly that it doesn't. The ISA bus doesn't address more than 16 meg, and NetBSD doesn't yet do anything to compensate for that. Your EISA BusLogic card should work fine in 20 meg, but the ISA-bus Adaptec will only work if you have less than 16 meg. >Weird question: Now that I have added the extra memory, I notice a couple >of operations in X that actually seem alittle *slower*. It's possible that your caching hardware is poorly designed. There are some cheap caches out there that will only cache the first 16 meg of RAM. Your last 4 meg might not be getting cached. --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 Sat May 14 09:08:50 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: SCSI questions To: michaelv@iastate.edu (Michael L. VanLoon -- Iowa State University) Cc: gregc@edi.com, 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: 1775 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Michael L. VanLoon -- Iowa State University > > >>I am currently running Netbsd current from the Aprill 6th sources. >>My machine is as follows: >> >> AMI Enterprise III EISA 486-66 with 12meg. >> Bustek 747S EISA Fast-SCSI at 0x330, int-11, DMA-5 >> Adaptec 1542B ISA SCSI at 0x334, int-12, DMA-6 >> >>2 days ago I opened the machine up to make 2 addtions: I added an additional >>8 meg of memory to bring the total to 20megs, > >>5.) Does Netbsd properly handle DMA to ISA devices from memory beyond the >> 16mem boundary? > >No. It has been posted repeatedly that it doesn't. The ISA bus >doesn't address more than 16 meg, and NetBSD doesn't yet do anything >to compensate for that. Your EISA BusLogic card should work fine in >20 meg, but the ISA-bus Adaptec will only work if you have less than >16 meg. Ok, thanks. I must have missed the earlier posts. I knew that an ISA bus master card couldn't get to memory beyond 16meg directly, but most PC based UNIX that I have used, have included some buffer dancing logic to make sure the DMA is always below the 16meg boundary. I just didn't know whether netbsd was capable of this. >>Weird question: Now that I have added the extra memory, I notice a couple >>of operations in X that actually seem alittle *slower*. > >It's possible that your caching hardware is poorly designed. There >are some cheap caches out there that will only cache the first 16 meg >of RAM. Your last 4 meg might not be getting cached. Ah yes, I forgot about that. However the AMI Enterprise III is a fairly topend motherboard and I can't believe that would have done something that silly. I can also believe that on an ISA board, but this is an EISA. *But*, I may have something mis-configured in the bios setup. Thanks Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 09:27:54 1994 To: gregc@edi.com (Greg Cronau) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SCSI questions From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>I am currently running Netbsd current from the Aprill 6th sources. >>>My machine is as follows: >>> >>> AMI Enterprise III EISA 486-66 with 12meg. >>> Bustek 747S EISA Fast-SCSI at 0x330, int-11, DMA-5 >>> Adaptec 1542B ISA SCSI at 0x334, int-12, DMA-6 >>> >>>2 days ago I opened the machine up to make 2 addtions: I added an additional >>>8 meg of memory to bring the total to 20megs, >>> >>>5.) Does Netbsd properly handle DMA to ISA devices from memory beyond the >>> 16mem boundary? >>No. It has been posted repeatedly that it doesn't. The ISA bus >>doesn't address more than 16 meg, and NetBSD doesn't yet do anything >>to compensate for that. Your EISA BusLogic card should work fine in >>20 meg, but the ISA-bus Adaptec will only work if you have less than >>16 meg. >Ok, thanks. I must have missed the earlier posts. I knew that an ISA >bus master card couldn't get to memory beyond 16meg directly, but most PC >based UNIX that I have used, have included some buffer dancing logic to >make sure the DMA is always below the 16meg boundary. I just didn't know >whether netbsd was capable of this. Well, the stubs are there, the code has just never been written to do the actual dance. There is a performance hit for doing it this way, however, since you're doing a lot more copying for each disk transfer. An EISA board will just plain be faster in this scenario. I know it isn't a high priority -- any idea on when bounce buffers might make the list? --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 Sat May 14 12:35:47 1994 From: Jarkko Hietaniemi To: amiga@sun-lamp.cs.berkeley.edu Subject: trouble: my harddisk timeouting Sender: owner-amiga@sun-lamp.cs.berkeley.edu My NetBSD harddisk is an IBM OEM 0663E15, rev 5 51, 1.2 GB SCSI-2 disk. I have had timeout problems with it using vmunix.720 and vmunix.730, but now I tried to use vmunix.744 and the thing simply does not work at all... "at all" here defined to be "not working 6 times in a row". 0) My machine: A3000 with ADOS 2.05, 8+2 MB, QUANTUM PD125 + the IBM disk 1) I have to "binpatch -s _inhibit_sync -b -r 0 vmunix" (SCSI id 0) otherwise the disk won't even budge. 2) The timeout: even the 720 and the 730 have had trouble like this: dma0: A3000 32bit DMA scsi0: scsi id 7 a3000scsi0 [1/1] scsi0: target 0 now asynchronous, period=208ns, offset=12 sbic_wait TIMEO @1210 with asr=x0 csr=x41 and then the sd6 (my standard A3000 system disk is found). As the NetBSD is only on the IBM, "no suitable root". With the 720 and 730 I manage to loadbsd about half the time, the other half I get bitten by this timeout. But with the 744, I simply cannot get past this timeout. Is there a way to binpatch this timeout somehow? The IBM disk is quite new technology (about half a year) but many of its big brothers (0664) are working quite happily at my work attached to UNIX boxen. ++jhi; From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 14 16:30:42 1994 From: "Stephen J. Roznowski" To: Jarkko.Hietaniemi@hut.fi, amiga@sun-lamp.cs.berkeley.edu Subject: Re: trouble: my harddisk timeouting Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: Jarkko Hietaniemi > My NetBSD harddisk is an IBM OEM 0663E15, rev 5 51, 1.2 GB SCSI-2 disk. > I have had timeout problems with it using vmunix.720 and vmunix.730, but > now I tried to use vmunix.744 and the thing simply does not work at all... > "at all" here defined to be "not working 6 times in a row". > > [Rest of problem deleted] Time for my stock answer. The 744 binaries are old (Can we *please* get them deleted from the ftp sites?). Try running the latest binaries that are available from sun-lamp.cs.berkeley.edu and its mirrors (use the mirrors). -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 16:55:12 1994 From: Scott Reynolds Subject: Re: SCSI questions To: Greg Cronau 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 On Fri, 13 May 1994, Michael L. VanLoon -- Iowa State University wrote: > No. It has been posted repeatedly that it doesn't. The ISA bus > doesn't address more than 16 meg, and NetBSD doesn't yet do anything > to compensate for that. I regularly patch my machdep.c to fake the kernel into thinking there's only 16 meg of RAM, because my two choices for RAM are 4 and 20 meg on one particular machine. It's not difficult, and it works for me... --scott From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 14 21:04:02 1994 From: Jarkko Hietaniemi To: "Stephen J. Roznowski" Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: trouble: my harddisk timeouting Sender: owner-amiga@sun-lamp.cs.berkeley.edu Jarkko Hietaniemi : jhi> My NetBSD harddisk is an IBM OEM 0663E15, rev 5 51, 1.2 GB SCSI-2 disk. jhi> I have had timeout problems with it using vmunix.720 and vmunix.730, but jhi> now I tried to use vmunix.744 and the thing simply does not work at all... jhi> "at all" here defined to be "not working 6 times in a row". jhi> jhi> [Rest of problem deleted] "Stephen J. Roznowski" : sjr> Time for my stock answer. The 744 binaries are old (Can we *please* sjr> get them deleted from the ftp sites?). Try running the latest binaries sjr> that are available from sun-lamp.cs.berkeley.edu and its mirrors (use sjr> the mirrors). This is what I got from the ftp.funet.fi mirror (sun-lamp did not answer at the moment so I cannot check whether there are newer kernels): netbsd a3000 0427 locks up after the "scsi0: target 0 now async..." *) netbsd generic -"- 1/2 time the aforementioned timeout, 1/2 time it gets past this but then hits swfree panic netbsd a3000 0413 locks up netbsd generic -"- 1/2 the time timeout, 1/2 the time boots ok vmunix generic 0325 -"- vmunix generic 0305 -"- Ahem...as far as I go, 730 works as fine as anything for me. The A3000-kernels lock up, the generic ones stutter between timeout and a succesful boot. What next? *) after waiting for 1 minute, I got bored and interrupted the test :-) Repeated attempts bring no solace. ++jhi; From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 21:56:13 1994 From: randy@ugn.unomaha.edu (Randy Terbush) Subject: Upgrade to 5-8 sources. Help requested. (LONG) To: current-users@sun-lamp.cs.berkeley.edu Cc: Mark_Weaver@brown.edu, cgd@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu After being gone a few weeks, I am trying to get "current". The following recaps the chain of events. I would be very grateful if someone could help me unravel this. I know! What I did was dumb. Feel free to remind me of that. Compiled and installed libraries. Compiled kernel. (Not yet installed) Compiled everything. Copied /bin, /sbin to /usr/old.root.bin, and /usr/old.root.sbin. Copied /usr/bin, /usr/sbin to /usr/old.usr.bin and /usr/old.usr.sbin. (obviously counting on being able to mount /usr...) Moved kernel to /netbsd.old, and copied new kernel to /. Set PATH to include the above copied dirs before $PATH. Ran 'make install' in /usr/src/bin without problem. Ran 'make install' in /usr/src/sbin. (Here's the beginning of problems) 'make install' errored out when the install tried to run ./strip on /usr/sbin/strip. Every attempt to run 'make install' after that gave "cannot map ld.so". After discovering that /usr/libexec/ld.so no longer existed, I copied the new ld.so into /usr/libexec. (I know, wrong!) After doing so, attempting to run almost anything gave "libc.so.9.0 invalid arg", or something like that. Seeing that most of /bin, and /sbin had successfully installed, I decided to boot the new kernel and see, if nothing else, if I could restore my backed up binaries. Booting from the new kernel panics at about the time when changing to root device sd0a. (At this point, I was getting a bit shocky, so the chain of events is 1.stupid, and 2.unclear.) Rebooted from the new kernel in single user mode. Attempted to run fsck on /usr part. with many "can't read block XX" errors. Attempted to mount it on /usr, and got "not supported by device" error. ?? Rebooted from floppy. Mounted /dev/sd0a on /mnt. Attempted to run new version of fsck on /usr partition. Got many "can't read block XX" errors, so I terminated fsck. Somewhere in this process, the boot blocks got nuked "NO ROM BASIC". The disklabel is still intact though. 'mount_ufs' disappeared. Can't make boot disk writeable due to missing /etc/fstab on floppy. HELP! My old kernel on disk is dated 4-13. It is the first required jump that Chris indicated would be necessary to follow the changes. It seems like it would be easiest to move forward at this point. Are there new boot floppies with the latest kernel somewhere? (w/fsck) Any suggestions as to what I should do to save /usr? Any other help would be greatly appreciated. I'll accept collect phone calls from anyone in the US having the inclination to see if I sound as stupid as I apparently am. :-) 402-488-8163 -Randy Terbush randy@ugn.unomaha.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 23:02:32 1994 From: chase@pine.ece.utexas.edu (Craig M. Chase) Subject: typo is syslog.h? 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: 728 Sender: owner-current-users@sun-lamp.cs.berkeley.edu It appears a paren is (was?) left out of syslog.h. Here's a trivial patch for /usr/src/sys/sys/syslog.h *** syslog.h.dist Thu May 12 05:31:34 1994 --- syslog.h Sat May 14 14:44:05 1994 *************** *** 181,187 **** #else /* !KERNEL */ ! void logpri __P((int); void log __P((int, const char *, ...)); void addlog __P((const char *, ...)); --- 181,187 ---- #else /* !KERNEL */ ! void logpri __P((int)); void log __P((int, const char *, ...)); void addlog __P((const char *, ...)); -- Craig Chase --- Assistant Professor (512) 471 7457 Electrical and Computer Engineering Fax: (512) 471 5907 The University of Texas at Austin Austin, TX 78712 From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 14 23:15:24 1994 From: kim@dde.dk (Kim Andersen) Subject: Problems with 05/13 sources To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm have a number of problems with the current sources. 1. src/usr.sbin/pppd Missing lock.c 2. src/usr.sbin/ppp/pppstats Lots of problems due to changes in kvm_ routines 3. sys/netinet/in.h and/or include/rpc/rpc.h The problem shows when compiling gethostnamaddr.c. sys/netinet/in.h is not proteced against multiple inclusions. 4. Errors when using vn, eg. doing a make snap_md in src/etc. I get this: mount /dev/vnd0a /mnt /dev/vnd0a on /mnt: Operation not supported by device 5. vi does nothing when run on the console (pccons). Works in a xterm. It seems to "sleep" without entering any mode nor showing output. It is interruptable. 6. sys/socket.h The prototypes for recv and sendv has changed, but the functions hasn't. Changed "int len" to "size_t len" 7. X is cpu hungry. In a otherwise idle system the server uses 95% cpu. The server were last compiled on May10 using libc.so.10.1. Any else seen this ?. Will a simple recompile help ? (This is XFree86-2.1.1) Comments ? regards kim From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 14 23:38:22 1994 From: "Stephen J. Roznowski" To: Jarkko.Hietaniemi@hut.fi Subject: Re: trouble: my harddisk timeouting Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Jarkko Hietaniemi : > jhi> My NetBSD harddisk is an IBM OEM 0663E15, rev 5 51, 1.2 GB SCSI-2 disk. > jhi> I have had timeout problems with it using vmunix.720 and vmunix.730, but > jhi> now I tried to use vmunix.744 and the thing simply does not work at all... > jhi> "at all" here defined to be "not working 6 times in a row". > jhi> > jhi> [Rest of problem deleted] > > "Stephen J. Roznowski" : > sjr> Time for my stock answer. The 744 binaries are old (Can we *please* > sjr> get them deleted from the ftp sites?). Try running the latest binaries > sjr> that are available from sun-lamp.cs.berkeley.edu and its mirrors (use > sjr> the mirrors). > > This is what I got from the ftp.funet.fi mirror (sun-lamp did not answer > at the moment so I cannot check whether there are newer kernels): > > netbsd a3000 0427 locks up after the "scsi0: target 0 now async..." *) > netbsd generic -"- 1/2 time the aforementioned timeout, > 1/2 time it gets past this but then hits swfree panic > netbsd a3000 0413 locks up > netbsd generic -"- 1/2 the time timeout, 1/2 the time boots ok > vmunix generic 0325 -"- > vmunix generic 0305 -"- > > Ahem...as far as I go, 730 works as fine as anything for me. Well, so much for my "stock answer". The 0427 kernel is the latest that I've made available. > > The A3000-kernels lock up, the generic ones stutter between timeout > and a succesful boot. What next? Have you tried the latest version of loadbsd? I believe that a new version has come out within the last couple of days. (But I doubt that it will help you here....) Have you tried turning on scsi and sd debugging? -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 00:37:35 1994 From: Mark_Weaver@brown.edu To: Dave Burgess Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Everything I compile core dumps.... Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Well, this has been an interesting couple of days. > > I rebuilt the kernel last week: > > -rwxr-xr-x 1 root wheel 768862 May 8 21:50 /netbsd > > Now, whenever I recompile a program, it core dumps with this error: > > Bad system call (core dumped) > > Any good ideas? You're not the only one who had this problem. When I upgraded from May 2's kernel to May 8's kernel, I noticed that: 1. Old dynamic executables wouldn't work with the new kernel 2. New dynamic executables wouldn't work with the old kernel I was able to upgrade by a carefully orchestrated process, which included plenty of backups. :-) I am also confused that other people didn't post about this. Maybe if I had been keeping up to date every day I wouldn't have had the problem. 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 Sun May 15 01:07:08 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Mark_Weaver@brown.edu Cc: Dave Burgess , netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Everything I compile core dumps.... <199405142116.RAA18470@cis-ts3-slip4.cis.brown.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > You're not the only one who had this problem. When I upgraded from > May 2's kernel to May 8's kernel, I noticed that: > > 1. Old dynamic executables wouldn't work with the new kernel > 2. New dynamic executables wouldn't work with the old kernel the former makes sense. i'd never seen the latter happen, but... > I am also confused that other people didn't post about this. Maybe if > I had been keeping up to date every day I wouldn't have had the > problem. It boils down the the fact that your crt0.o was probably never completely remade (because it doesn't deal with dependencies right), and so binaries that used its idea of some syscalls (i.e. dynamically linked binaries) had the wrong idea of what to do, and croaked. that's the cause of the problem... cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 01:14:39 1994 From: Mark_Weaver@brown.edu To: "Chris G. Demetriou" Cc: Dave Burgess , netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Everything I compile core dumps.... <199405142143.OAA15631@erewhon.CS.Berkeley.EDU> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > It boils down the the fact that your crt0.o was probably never > completely remade (because it doesn't deal with dependencies right), > and so binaries that used its idea of some syscalls (i.e. dynamically > linked binaries) had the wrong idea of what to do, and croaked. Actually, I rebuilt the new (May 8) system from scratch. (ie, rm -rf /usr/obj, make obj, make depend, make) 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 Sun May 15 02:00:14 1994 From: Dave Burgess Subject: Re: Problems with 05/13 sources To: kim@dde.dk (Kim Andersen) Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 766 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Fix for one of the problems. > 3. sys/netinet/in.h and/or include/rpc/rpc.h > The problem shows when compiling gethostnamaddr.c. > sys/netinet/in.h is not proteced against multiple inclusions. > Undefine YP. Everything in the library then seems to make it. The network interface rpc stuff doesn't seem to be able to coexist with the new stuff... > 6. sys/socket.h > The prototypes for recv and sendv has changed, but the functions > hasn't. Changed "int len" to "size_t len" Found that one too. > regards > kim > Well, I got 'round the 'everything core dumping' problem. Step 1: ebuild and Boot with a new kernel Step 2: Rebuild everything else. If you try to do the steps the other way, you are toast. Dave "the ex-toasted" Burgess From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 02:01:16 1994 From: Dave Burgess Subject: Re: Everything I compile core dumps.... To: Mark_Weaver@brown.edu Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 621 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > It boils down the the fact that your crt0.o was probably never > > completely remade (because it doesn't deal with dependencies right), > > and so binaries that used its idea of some syscalls (i.e. dynamically > > linked binaries) had the wrong idea of what to do, and croaked. > > Actually, I rebuilt the new (May 8) system from scratch. > (ie, rm -rf /usr/obj, make obj, make depend, make) > Me too, but I was running from an older kernel. The sources from that kernel were probably from around the 6th or the 7th. I needed to install a new kernel. Once I did that, everything seemed to work as expected. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 04:08:17 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: kim@dde.dk (Kim Andersen) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems with 05/13 sources <9405142201.AA10319@nessie.dde.dk> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 1. src/usr.sbin/pppd > Missing lock.c > 2. src/usr.sbin/ppp/pppstats > Lots of problems due to changes in kvm_ routines > 3. sys/netinet/in.h and/or include/rpc/rpc.h > The problem shows when compiling gethostnamaddr.c. > sys/netinet/in.h is not proteced against multiple inclusions. fixed. > 4. Errors when using vn, eg. doing a make snap_md in src/etc. > I get this: > mount /dev/vnd0a /mnt > /dev/vnd0a on /mnt: Operation not supported by device > 5. vi does nothing when run on the console (pccons). Works in a xterm. > It seems to "sleep" without entering any mode nor showing output. > It is interruptable. i'm looking into these, but won't have anything conclusive on either until tomorrow at the earliest. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 05:38:39 1994 From: Yeng-Chee Su Subject: 8bit clean more? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 763 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there any 8bit clean version of more? The current version in NetBSD uses the 8th bit as the control character bit. This makes me not to show Chinese character. There is a modified version of less called cless. I am looking for the equivalent version of more. Any help will be welcome. -- ________________________________________________________________________ / National Chiao Tung University in Taiwan / \ | Name: Yeng-Chee Su Dept: Computer Engineering |__/ | Phone: +886-35-783513 E-mail: yenchee@csie.nctu.edu.tw | | Address: 2, Alley 2, Lane 173, Gao Tsui Rd., HsinChu, Taiwan 30038 |___ \______________________________________________________________________\__/ From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 10:50:04 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: cksum listing also? Sender: owner-current-users@sun-lamp.cs.berkeley.edu ``Dear netbsd-current archive maintainers'', Could there be generated (as part of the weekly processing) a set of files each containing a cksum listing of a major part of the NetBSD - current source tree. Having this available would greatly simplify the task (for those without `sup' and an level IP connection) of comparing a local source tree with that found on sun-lamp. Any other solutions to this problem (comparing source trees with out `sup' and/or IP) would also be appreciated. regards Andrew ---- Something like (ignoring syntax errors: cd /usr/src for f in * do find $f -name CVS -prune -o -type f -print | xargs cksum | gzip -9 > /some/where/in/the/ftp/area/$f.cksum.gz done From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 13:48:21 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/sh/Makefile U src/bin/sh/builtins U src/bin/sh/eval.c U src/bin/sh/input.c U src/bin/sh/mkbuiltins U src/bin/sh/options.c U src/bin/sh/var.c U src/lib/csu/i386/Makefile U src/lib/csu/m68k/Makefile U src/lib/csu/ns32k/Makefile U src/lib/csu/sparc/Makefile U src/lib/libc/Makefile U src/lib/libc/gmon/Makefile.inc U src/lib/libc/gmon/gmon.c U src/lib/libc/gmon/mcount.c U src/lib/libc/gmon/moncontrol.3 U src/lib/libc/net/recv.c U src/lib/libc/net/send.c U src/libexec/identd/netbsd.c U src/libexec/rpc.rstatd/rstat_proc.c U src/regress/sys/arch/i386/ldt/testldt.c U src/sbin/route/Makefile U src/sbin/routed/Makefile U src/sys/arch/hp300/hp300/disksubr.c U src/sys/arch/i386/floppy/sh/Makefile U src/sys/arch/sparc/dev/cons.c U src/sys/arch/sparc/dev/zs.c U src/sys/arch/sparc/include/limits.h U src/sys/arch/sparc/sbus/if_le.c U src/sys/arch/sparc/sbus/if_lereg.h U src/sys/arch/sparc/sparc/locore2.c U src/sys/arch/sparc/sparc/trap.c U src/sys/arch/sun3/conf/Makefile.sun3 U src/sys/arch/sun3/conf/SCSITEST U src/sys/arch/sun3/dev/si.c U src/sys/arch/sun3/include/sun_disklabel.h U src/sys/arch/sun3/sun3/disksubr.c U src/sys/kern/kern_synch.c U src/sys/lib/libkern/Makefile U src/sys/lib/libkern/mcount.c U src/sys/netinet/in.h U src/usr.bin/gprof/Makefile U src/usr.bin/gprof/gprof.h U src/usr.sbin/Makefile U src/usr.sbin/iostat/Makefile U src/usr.sbin/iostat/iostat.8 U src/usr.sbin/iostat/iostat.c U src/usr.sbin/pppd/lock.c U src/usr.sbin/pppd/pppstats/pppstats.c U src/usr.sbin/pstat/Makefile U src/usr.sbin/pstat/pstat.8 U src/usr.sbin/pstat/pstat.c U src/usr.sbin/rarpd/rarpd.c U src/usr.sbin/sliplogin/sliplogin.c U src/usr.sbin/slstats/slstats.c Running the SUP scanner: SUP Scan for current starting at Sun May 15 03:23:44 1994 SUP Scan for current completed at Sun May 15 03:26:24 1994 SUP Scan for mirror starting at Sun May 15 03:26:24 1994 SUP Scan for mirror completed at Sun May 15 03:28:37 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 15 14:58:33 1994 From: Jarkko Hietaniemi To: "Stephen J. Roznowski" Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: trouble: my harddisk timeouting Sender: owner-amiga@sun-lamp.cs.berkeley.edu Stephen J. Roznowski : sjr> Have you tried the latest version of loadbsd? I believe that a new version sjr> has come out within the last couple of days. (But I doubt that it will sjr> help you here....) Nope. sjr> Have you tried turning on scsi and sd debugging? Yup. netbsd.generic-940413 (binpatch could neither find _scsi_debug nor _sdddebug in 0427 nor a3000-0413 kernels?): 2 Amiga memory segments segment 0 at 07800000 size 00800000 segment 1 at 00000000 size 00200000 dma0: A3000 32bit DMA issue select 0 wait_for_select: 11 8e ixfer_start 6, 6, 50000 ixfer_out {6} 80 01 03 01 34 0c 00 01 e5 00 ixfer_out done [1f] >CSR: 1fCSR: 8aCSR: 1a Subject: ser.c and ttneread 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: 546 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I have a little problem to get the latest kernel compiled,(The last one that compiled was on 20.Apr) Everything goes fine until it comes to loading netbsd and it tells me that _ttnread in ser.o is not defined. I have seen the function in tty.c, Is there any way around this bug? Also The list has been awfully quiet recently I wonder if I've been kicked off... Any way to chekc tahat? Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 Arthur Hoffmann Message-Id: <199405151321.WAA09599@morinda> Subject: ser.c and ttneread To: amiga-dev@sun-lamp.cs.berkeley.edu Date: Sun, 15 May 1994 22:51:52 +0930 (CST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 546 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Precedence: bulk Status: O Hi, I have a little problem to get the latest kernel compiled,(The last one that compiled was on 20.Apr) Everything goes fine until it comes to loading netbsd and it tells me that _ttnread in ser.o is not defined. I have seen the function in tty.c, Is there any way around this bug? Also The list has been awfully quiet recently I wonder if I've been kicked off... Any way to chekc tahat? 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 Sun May 15 17:02:31 1994 From: "Robert L. Shady" Subject: Re: 8bit clean more? To: yenchee@YENCHEE.csie.nctu.edu.tw (Yeng-Chee Su) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 371 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Is there any 8bit clean version of more? The current version in NetBSD > uses the 8th bit as the control character bit. This makes me not to show > Chinese character. There is a modified version of less called cless. I > am looking for the equivalent version of more. Any help will be welcome. Why?? Take the modified version of 'cless' and call it 'more'. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 15 18:08:33 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: ser.c and ttneread Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 15, 10:51pm, Arthur Hoffmann wrote: > Everything goes fine until it comes to loading netbsd > and it tells me that _ttnread in ser.o is not defined. > I have seen the function in tty.c, Is there any way around this bug? Yes, just remove the serselect routine in amiga/ser.c. It's not being referenced anymore. > Also The list has been awfully quiet recently I wonder if I've been > kicked off... Any way to chekc tahat? If you get this message twice, once directly from me and a second from amiga-dev-owner@sun-lamp.cs.berkeley.edu, then you are still on the list. You can also send a message to majordomo@sun-lamp.cs.berkeley.edu and request a listing of who's subscribed to the amiga-dev list. I don't remember the command at the moment, but if you send a help request to majordomo, it should tell you how to do it. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 18:10:42 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 8bit clean more? <199405151406.KAA12504@zeus.id.net> From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> Is there any 8bit clean version of more? The current version in NetBSD >> uses the 8th bit as the control character bit. This makes me not to show >> Chinese character. There is a modified version of less called cless. I >> am looking for the equivalent version of more. Any help will be welcome. > >Why?? Take the modified version of 'cless' and call it 'more'. especially considering that /usr/bin/more is really less with a hack to make it exit at the end of a file (damn i hate that! ;-) ..and possibly other stuff too. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 18:53:38 1994 From: Tim Chase Subject: X server eating CPU 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: 515 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just thought I'd also mention that I'm seeing the X server eat the CPU when used on recent kernels. A little ktracing shows that its select calls are continuously returning when no I/O is possible (presumably on the mouse port and on the X socket). I havn't investigated any further, but I think I'll try rebuilding the X server first. Specifically, this is the XFree86 2.1 server running a kernel from a sup on Friday. Does anyone have any idea what may be causing this? - Tim Chase tim@introl From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 18:59:29 1994 From: Scott Anderson Subject: Help, where's sys/sysctl.h ? 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: 120 Sender: owner-current-users@sun-lamp.cs.berkeley.edu This is a very simple question: Where did sysctl.h go? running may 2 binaries, trying to build 5/14/94's sup. Scott From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 15 19:48:58 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Tim Chase Subject: Re: X server eating CPU <199405151544.KAA32125@introl.introl.com> Cc: current-users@sun-lamp.cs.berkeley.edu From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I'll try rebuilding the X server first. I did that last night, and the sucker is still using as much CPU as it can get. --Michael -- Michael Graff 1304 Florida #3 (515) 296-2735 Ames, IA 50014 PGP key on a server near YOU! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 02:58:21 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, osymh@gemini.oscs.montana.edu Subject: Re: sys.19940513 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu osymh@gemini.oscs.montana.edu (Michael L. Hitch) wrote: > If you are using bash as the shell and want to try out the fixed one > I'm using, I have put it on ftp.coe.montana.edu in /tmp/NetBSD-bash.gz. I tried this, and also got the fri 13 sources, and also trimmed my config a bit.. and now make depend works again.. Anyway, the fri 13 stuff is a nightmare.. somehow it always seems like *I* get the inconsistent sources sets... I had missing structure members, undefined #defines, etc.. after fixing the obvious first few of those, I gave up.. Sat May 14 18:32:10 MET DST 1994 Making kernel... .. cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0xffffffc4" -DDST="1" -DMAXFDESCS="0x800" -DFPSP -DFPCOPROC -DETHER -DINET -DQUOTA -DFFS -DMFS -DPROCFS -DKERNFS -DFDESC -DLOFS -DPORTAL -DFIFO -DADOSFS -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DCOMPAT_09 -DCOMPAT_43 -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVMSG -DSYSVSEM -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DKTRACE -DPANICWAIT -DDIAGNOSTIC -DDEBUG -DDDB -DNKMEMCLUSTERS=256 -DGENERIC -DLKM -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../kern/kern_malloc.c ../../../../kern/kern_malloc.c: In function `malloc': ../../../../kern/kern_malloc.c:126: structure has no member named `ks_size' ../../../../kern/kern_malloc.c:132: structure has no member named `kb_last' ../../../../kern/kern_malloc.c:187: structure has no member named `kb_last' ../../../../kern/kern_malloc.c:188: structure has no member named `kb_last' ../../../../kern/kern_malloc.c: In function `free': ../../../../kern/kern_malloc.c:343: structure has no member named `kb_last' ../../../../kern/kern_malloc.c:345: structure has no member named `kb_last' *** Error code 1 Stop. Sat May 14 18:56:56 MET DST 1994 Sat May 14 19:09:07 MET DST 1994 Making kernel... ... cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0xffffffc4" -DDST="1" -DMAXFDESCS="0x800" -DFPSP -DFPCOPROC -DETHER -DINET -DQUOTA -DFFS -DMFS -DPROCFS -DKERNFS -DFDESC -DLOFS -DPORTAL -DFIFO -DADOSFS -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DCOMPAT_09 -DCOMPAT_43 -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVMSG -DSYSVSEM -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DKTRACE -DPANICWAIT -DDIAGNOSTIC -DDEBUG -DDDB -DNKMEMCLUSTERS=256 -DGENERIC -DLKM -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../kern/uipc_domain.c ../../../../kern/uipc_domain.c: In function `net_sysctl': ../../../../kern/uipc_domain.c:180: structure has no member named `pr_sysctl' ../../../../kern/uipc_domain.c:181: structure has no member named `pr_sysctl' *** Error code 1 Stop. Sat May 14 19:42:08 MET DST 1994 Sat May 14 20:08:07 MET DST 1994 Making kernel... ... cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0xffffffc4" -DDST="1" -DMAXFDESCS="0x800" -DFPSP -DFPCOPROC -DETHER -DINET -DQUOTA -DFFS -DMFS -DPROCFS -DKERNFS -DFDESC -DLOFS -DPORTAL -DFIFO -DADOSFS -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DCOMPAT_09 -DCOMPAT_43 -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVMSG -DSYSVSEM -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DKTRACE -DPANICWAIT -DDIAGNOSTIC -DDEBUG -DDDB -DNKMEMCLUSTERS=256 -DGENERIC -DLKM -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../kern/uipc_socket.c ../../../../kern/uipc_socket.c: In function `soreceive': ../../../../kern/uipc_socket.c:560: `MSG_DONTWAIT' undeclared (first use this function) ../../../../kern/uipc_socket.c:560: (Each undeclared identifier is reported only once ../../../../kern/uipc_socket.c:560: for each function it appears in.) ../../../../kern/uipc_socket.c: In function `sosetopt': ../../../../kern/uipc_socket.c:866: `SO_REUSEPORT' undeclared (first use this function) ../../../../kern/uipc_socket.c: In function `sogetopt': ../../../../kern/uipc_socket.c:984: `SO_REUSEPORT' undeclared (first use this function) *** Error code 1 Stop. Sat May 14 20:12:58 MET DST 1994 Sat May 14 20:22:25 MET DST 1994 Making kernel... ... cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0xffffffc4" -DDST="1" -DMAXFDESCS="0x800" -DFPSP -DFPCOPROC -DETHER -DINET -DQUOTA -DFFS -DMFS -DPROCFS -DKERNFS -DFDESC -DLOFS -DPORTAL -DFIFO -DADOSFS -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DCOMPAT_09 -DCOMPAT_43 -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVMSG -DSYSVSEM -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DKTRACE -DPANICWAIT -DDIAGNOSTIC -DDEBUG -DDDB -DNKMEMCLUSTERS=256 -DGENERIC -DLKM -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../net/radix.c ../../../../net/radix.c: In function `rn_init': ../../../../net/radix.c:741: structure has no member named `dom_maxrtkey' ../../../../net/radix.c:742: structure has no member named `dom_maxrtkey' *** Error code 1 Stop. Sat May 14 20:55:23 MET DST 1994 > Michael -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 16 03:13:43 1994 From: GDRUEBSAMEN@csupomona.edu Subject: X-Windows for Spectrum........! To: "amiga" Sender: owner-amiga@sun-lamp.cs.berkeley.edu Date sent: 15-MAY-1994 Please bare with me because I am quite new to net-bsd... Well, my question/problem is that I have an Amiga 3000 with a GVP EGS Spectrum graphics card... I can get netbsd working no problem.. but I would LOVE LOVE LOVE to run X-Windows (my friend has an IBM and runs x-winodows.. makes me jealous)... Is there a way to get X-Windows working under the Spectrum card? If not is there a port being planned (I cannot beleive there wouldnt be with so many spectrum users...) Also, can someone tell me exaclty what DaggeX is?? Is it x-windows for Amigados? Is there a FAQ? Thanks alot! --- 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 Mon May 16 03:37:15 1994 From: Arthur Hoffmann Subject: Re: ser.c and ttneread To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: 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: 2044 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > On May 15, 10:51pm, Arthur Hoffmann wrote: > > Everything goes fine until it comes to loading netbsd > > and it tells me that _ttnread in ser.o is not defined. > > I have seen the function in tty.c, Is there any way around this bug? > > Yes, just remove the serselect routine in amiga/ser.c. It's not > being referenced anymore. > > > Also The list has been awfully quiet recently I wonder if I've been > > kicked off... Any way to chekc tahat? > > If you get this message twice, once directly from me and a second > from amiga-dev-owner@sun-lamp.cs.berkeley.edu, then you are still on > the list. > > You can also send a message to majordomo@sun-lamp.cs.berkeley.edu > and request a listing of who's subscribed to the amiga-dev list. I > don't remember the command at the moment, but if you send a help > request to majordomo, it should tell you how to do it. > > Michael > > -- > Michael L. Hitch INTERNET: osymh@montana.edu > Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET > Office of Systems and Computing Services > Montana State University Bozeman, MT USA > Thank's for your reply, Michael I did as you suggested, and the kernel compiled fine :) Just loading it seems to be a bit strange. To make sure all works I just built a Generic kernel config.new GENERIC make depend make Anyway when I boot the kernel it reports that I'm running on an Amiga 500/2000, then it tells me ztwobus0 at mainbus0 no suitable root. What went wrong now? I have an A3000. Now I commented out all the scsi drivers in my GENERIC file, except ahsc0, also I suped the very latest 16.05.1994 stuff and did make depend; make again, now The kernel doesn't compile anymore, because of a missing include file: machine/profile no such file or directory. I just found the file in /usr/src/sys/arch/m68k/include/profile.h. I'll try to make a link to that and see what happens. 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 Mon May 16 03:49:51 1994 From: Arthur Hoffmann Subject: Re: ser.c and ttneread To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: 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: 958 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > when I boot the kernel it reports that I'm running on an Amiga > 500/2000, > then it tells me ztwobus0 at mainbus0 > no suitable root. > > What went wrong now? I have an A3000. > Now I commented out all the scsi drivers in my GENERIC file, except > ahsc0, also I suped the very latest 16.05.1994 stuff and did make > depend; make again, now The kernel doesn't > compile anymore, because of a missing include file: machine/profile no > such file or directory. I just found the file in > /usr/src/sys/arch/m68k/include/profile.h. I'll try to make a link to > that and see what happens. > Well what happened was that the kern library was built, but then the compile stopped with the following: loading netbsd sd.o: Undefined symbol _dk_establish referenced from text segment *** Error code 1 Stop. 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 Mon May 16 03:58:22 1994 From: Arthur Hoffmann Subject: config.new how? 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: 523 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I have been trying to build a new kernel with the latest sources and using config.new. I have some questions about that: How do I tell config.new that I wish to use the custom font and the floppy drive? (just in case I get a woring kernel again :). Is there any info on config.new available (in addition to the man page)? If yes, where? Thanks for your patience. 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 Mon May 16 04: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: Arthur Hoffmann , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: config.new how? Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 16, 10:59am, Arthur Hoffmann wrote: > I have been trying to build a new kernel with the latest sources and > using config.new. > I have some questions about that: > How do I tell config.new that I wish to use the custom font and the > floppy drive? (just in case I get a woring kernel again :). The current kernel does not have a floppy driver yet - it hasn't been converted over to the config.new stuff yet (unless Chris Hopps has been busy today). The way I got the custom font to configure was to modify the conf/files.amiga.newconf to include ite as well as KF_CUSTOM to the kf_custom.c line. It appears that KF_CUSTOM doesn't work to cause that file to be included. > Is there any info on config.new available (in addition to the man > page)? If yes, where? The source code? :-) Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 04:16:23 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: 8bit clean more? To: mrgreen@mame.mu.oz.au (matthew green) 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: 1010 Sender: owner-current-users@sun-lamp.cs.berkeley.edu matthew green > > >>> Is there any 8bit clean version of more? The current version in NetBSD >>> uses the 8th bit as the control character bit. This makes me not to show >>> Chinese character. There is a modified version of less called cless. I >>> am looking for the equivalent version of more. Any help will be welcome. >> >>Why?? Take the modified version of 'cless' and call it 'more'. > >especially considering that /usr/bin/more is really >less with a hack to make it exit at the end of a >file (damn i hate that! ;-) ..and possibly other >stuff too. Hmmm, I've been meaning to ask that. Netbsd's "more" command felt alot like an old(or hacked) version of less. Here's a quick side question: When I was building up my Netbsd system, I went off to several archive sites to get my favorite utilities, tcsh, elm, less, smail, etc, but less-177 seemed to be missing from the gnu tree on every site I checked. Does anybody know what has happened to less? Has it been renamed/moved? Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 04:40:42 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, gregc@edi.com Subject: Re: 8bit clean more? Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...] less-177 seemed to be missing from the gnu tree on every site I checked. Does anybody know what has happened to less? Has it been renamed/moved? The author refused to put a GPL on it. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 05:08:01 1994 From: Christos Zoulas "Re: 8bit clean more?" (May 15, 6:17pm) 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: gregc@edi.com (Greg Cronau) Subject: Re: 8bit clean more? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On May 15, 6:17pm, gregc@edi.com (Greg Cronau) wrote: -- Subject: Re: 8bit clean more? | matthew green | > | > | >>> Is there any 8bit clean version of more? The current version in NetBSD | >>> uses the 8th bit as the control character bit. This makes me not to show | >>> Chinese character. There is a modified version of less called cless. I | >>> am looking for the equivalent version of more. Any help will be welcome. | >> | >>Why?? Take the modified version of 'cless' and call it 'more'. | > | >especially considering that /usr/bin/more is really | >less with a hack to make it exit at the end of a | >file (damn i hate that! ;-) ..and possibly other | >stuff too. | | Hmmm, I've been meaning to ask that. Netbsd's "more" command felt alot like | an old(or hacked) version of less. Here's a quick side question: | When I was building up my Netbsd system, I went off to several archive | sites to get my favorite utilities, tcsh, elm, less, smail, etc, but less-177 | seemed to be missing from the gnu tree on every site I checked. | Does anybody know what has happened to less? Has it been renamed/moved? | it should be ther in your favourite ftp site. For a version that compiles off the box on NetBSD [and has the highlighting search patch on it] look on tesla.ee.cornell.edu christos From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 16 05:28:13 1994 From: Donn Cave X-Sender: donn@homer06.u.washington.edu Subject: Re: X-Windows for Spectrum........! To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2204 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | Is there a way to get X-Windows working under the Spectrum card? If not is | there a port being planned (I cannot beleive there wouldnt be with so many | spectrum users...) I heard that ``several people have already said they would write a driver.'' That probably doesn't mean much. I was asking around because I'm interested in how cooperative these 3rd party hardware manufacturers will be, with ventures like NetBSD. While you'd think that a competitive environment would make manufacturers eager to provide any assistance that would make their products more widely usable, it turns out that in some cases they are not at all interested in having code laying around for everyone to look at, that exposes the inner secrets of their hardware. For examples of this on the Intel side, ask the X people about Diamond, or the kernel people about Adaptec. The only board currently supported, to my knowledge, is the Retina. MacroSystems GmbH have reportedly been more cooperative because they have less to lose, with an NCR chip where the crowd is using Cirrus. It may also just be a corporate personality issue; MacroSystems Design in the US (the Warp Engineers) also seem friendly towards NetBSD. I hope that as it becomes clearer what position the various manufacturers are going to take, the NetBSD-Amiga folks won't be bashful about recommending cooperating products, as is done on the Intel side. We can be organized consumers, and maybe help our friends. Now, hardware support could conceivably be engineered for a binary release. That's kind of unlikely to work out well, though, for a couple of reasons. The general BSD support folks aren't likely to put in a lot of work helping out with this sort of thing, I'd guess, but the worst part is that there's no one in charge, who can sign a non-disclosure and enforce it. So the manufacturer has to make a deal with a private individual, who will put out a couple of releases and then pretty much disappear, when he gets a job or something. Meanwhile the kernel changes constantly, so if you want to run X you're stuck with an old kernel and no one will talk to you. That's my $0.02, as they say. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 05:54:56 1994 From: Arthur Hoffmann Subject: Wrong Machine identification (was ser.c and ttnread) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: 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: 2137 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Anyway when I boot the kernel it reports that I'm running on an Amiga > > 500/2000, > > then it tells me ztwobus0 at mainbus0 > > no suitable root. > > > > What went wrong now? I have an A3000. > > Are you using the latest version of loadbsd (version 2.4)? If so, > what version of AmigaDOS are you running? Loadbsd looks through the > resident modules to find ones that are particular to a specific > machine. I don't know if it's been tested on the A3000 sucessfully. > It looks like maybe loadbsd doesn't find what it expects for the A3000, > so defaults to the A2000. You may have to use the previous version > of loadbsd in this case (2.0, I think). > I actually was running loadbsd version 2.4. The OS is Kickstart version 37.175 and Workbench is 37.67. I then used the old loadbsd2.0 and I got a little farther. Now I commented out all the scsi drivers in my GENERIC file, except ahsc0, also I suped the very latest 16.05.1994 stuff and did make depend; make again, now The kernel had a problem with sd.c (the one in /usr/src/sys/scsi, not the one in /usr/src/sys/arch/amiga/dev) loadbsd resulted in an undefined function dk_establish I found it in the /usr/src/sys/arch/amiga/gtsc.c file, so I just copied it into the sd.c file and the compile worked. The function only contains: int dk_establish() { return(-1); } But when starting the sysem with the new kernel I got the following: ahsc0 targ5 lun0 SCSI2 direct fixed sd5 at scsibus1: 100MB, 1211 cyl, 4 head, 42 sec, 512 bytes/sec ahsc0 targ6 lun0 SCSI2 direct fixed sd5 at scsibus1: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec zthreebus0 at mainbus0 here the machine hangs with the HD light on steady. When I press a key I get a panic with the PC at 0001A34E. Is this related to the dk_establish function? And why SCSI2? I thought A3000 are SCSI1. Just in case it matters my SCSI chip is the A version rev 00-08. Any Ideas? 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 May 16 06:45:36 1994 From: Dave Burgess Subject: Weirdnesses with Saturday's sources... To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1180 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello all, Just a quick report to let everyone know how things are going. 1. The coreing problem I was having is fixed. I needed the new kernel before the new utilities. 2. I now am having a problem (that was previously reported) with vi not wanting to talk to the screen. I checked the status with 'ps' and it says that vi is blocking with an 'S+' status. No big deal, it works great on the VT102. Any ideas why? 3. Has any done anything to the floppy drive code lately. Whenever I try to access a floppy using the fd0d device (as in mount -t msdos...) I get all kind of read errors. Hard read errors. Like the drive isn't responding. The drive probes alright during the boot up. The select light comes on and everything (except the read errors) makes it look like it should be working. When I try to access fd0c, the drive reads OK, but the directory structure is toast. I looks like the fd0c device might be pointing to an offset onto the disk instead of the beginning. This was working in the sources from the 8th. 4. I understand that this has been an eventful week-end. Could we try and do it so it doesn't coincide with Friday the 13th next time :-) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 06:46:20 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 , osymh@gemini.oscs.montana.edu (Michael L. Hitch) Subject: Re: Wrong Machine identification (was ser.c and ttnread) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 16, 12:57pm, Arthur Hoffmann wrote: > Now I commented out all the scsi drivers in my GENERIC file, except > ahsc0, also I suped the very latest 16.05.1994 stuff and did make > depend; make again, now The kernel had a problem with sd.c (the > one in /usr/src/sys/scsi, not the one in /usr/src/sys/arch/amiga/dev) The amiga/dev/sd.c (and st.c) is no longer being used. > loadbsd resulted in an undefined function > dk_establish > I found it in the /usr/src/sys/arch/amiga/gtsc.c file, so I just > copied it into the sd.c file and the compile worked. > The function only contains: > > int > dk_establish() > { > return(-1); > } Hmmm. I'm not sure where that routine is supposed to be, but it certain shouldn't be in the driver file that may not be included. > ahsc0 targ5 lun0 SCSI2 direct fixed > sd5 at scsibus1: 100MB, 1211 cyl, 4 head, 42 sec, 512 bytes/sec > ahsc0 targ6 lun0 SCSI2 direct fixed > sd5 at scsibus1: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec > zthreebus0 at mainbus0 > > here the machine hangs with the HD light on steady. When I press a key > I get a panic with the PC at 0001A34E. Maybe you are the first on to test the A3000 driver code? I don't know if Chris Hopps had anyone try out the A3000 or A2091 driver. Neither he nor I have an A3000 to test A3000-specific things on. Oh oh - I found what may be the problem: a3000dmaintr() calls sbicintr, but passes the controller number instead of the sbic_softc pointer. Try changing "sbicintr(i)" to "sbicintr(dev)". The A2091 driver has the same bug (atzsc.c). The panic is probably caused by a bug when a keyboard interrupt is generated before the console device has been opened. > Is this related to the dk_establish function? I doubt it. > And why SCSI2? I thought A3000 are SCSI1. Just in case it matters my > SCSI chip is the A version rev 00-08. SCSI2 is the value the drive reports in the inquiry data. It has nothing to do with the host adapter. Michael From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 07:01:27 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: cagney@highland.oz.au Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: cksum listing also? <9405150716.AA00376@highland.oz.au> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Could there be generated (as part of the weekly processing) a set > of files each containing a cksum listing of a major part of the NetBSD - > current source tree. I see several problems with this: (1) if you generate the cksums weekly, then, on all the other days of the week, some files will look bogus. i don't like this -- it defeats the purpose of doing the cksum to begin with. (2) i *definitely* do not want to run cksum over 93 megs of source nightly! chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 07:41:05 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: dk_establish To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 99 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu dk_establish and ttnread problems are now fixed (they were locally but not checked in yet) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 08:39:13 1994 From: Hubert Feyrer Subject: sys.19940515 To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: osymh@montana.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1220 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Last night i recompiled the kernel using the sources from 15. may. Everything compiled fine except the funcion in ser.c which Michael told me to comment out. After doing so, loadbsd'ing the kernel (using Michael's loadbsd-2.4) I _again_ just get a black screen after loadbsd tells me that I use 8 megs of fast and 1 meg of chip ram. :-( What's wrong here? I renamed the GENERIC config-file to DUSK (no other changes), then did config.new, make depend and make all. Can this be a problem of my A2091? I didn't see any comment in the config-file regarding it, just A3k, GVP, ... BTW, this is all on a A2000 with A2630 (68030, 68882). Is this probably a problem with my compiler/assembler? I use the latest gas from src/gnu/usr/sbin/gas (or such...). Desperately crying for help!!! 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 Mon May 16 08:51:37 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: dead vi and loopy X Sender: owner-current-users@sun-lamp.cs.berkeley.edu A couple of people recently noted that vi didn't work on the console and the X server would eat infinite CPU time. This turns out to be due to a slight error I made when rewriting conf.c. The following should fix both. 323,324c323,324 < (dev_type_reset((*))) nullop, dev_tty_init(c,n), \ < (dev_type_select((*))) enodev, dev_init(c,n,mmap), 0 } --- > (dev_type_reset((*))) nullop, dev_tty_init(c,n), ttselect, \ > dev_init(c,n,mmap), 0 } Thanks to cgd for pointing out the mistake. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 08:52:50 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, root@s069.infonet.net Subject: Re: Weirdnesses with Saturday's sources... Sender: owner-current-users@sun-lamp.cs.berkeley.edu 2. I now am having a problem (that was previously reported) with vi not wanting to talk to the screen. Fixed. 3. Has any done anything to the floppy drive code lately. Whenever I try to access a floppy using the fd0d device [...] I get all kind of read errors. That's because you should be using `fd0a' instead. The minor number now represents the media format, with `a' being the drive's `normal' setting (i.e. whatever the CMOS/BIOS says). It's been this way for a *while*. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 08:55:01 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Tim Chase Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: X server eating CPU <199405151544.KAA32125@introl.introl.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just thought I'd also mention that I'm seeing the X server > eat the CPU when used on recent kernels. A little ktracing > shows that its select calls are continuously returning when > no I/O is possible (presumably on the mouse port and on the > X socket). I havn't investigated any further, but I think > I'll try rebuilding the X server first. This was caused by a minor bug in the i386 conf.c, which has been fixed. It was the same bug that caused the problems with 'vi' on console. chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 09:01:02 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Dave Burgess Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: Weirdnesses with Saturday's sources... <199405160305.WAA00356@s069.infonet.net> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 2. I now am having a problem (that was previously reported) with vi > not wanting to talk to the screen. I checked the status with 'ps' and > it says that vi is blocking with an 'S+' status. No big deal, it works > great on the VT102. Any ideas why? bug in i386/conf.c; fixed a few minutes ago. > 3. Has any done anything to the floppy drive code lately. Whenever I > try to access a floppy using the fd0d device (as in mount -t msdos...) you should most likely be using 'fd0a' for this, not fd0d... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 12:09:30 1994 From: Arthur Hoffmann Subject: Re: Wrong Machine identification To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: 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: 776 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > > I actually was running loadbsd version 2.4. The OS is Kickstart > > version 37.175 and Workbench is 37.67. > > Can you look at the resident module list under AmigaDOS and see > if there is a module with the name "A3000 Bonus" or something > similar? That's what loadbsd is looking for to tell that it is > running on an A3000. > > Michael > > -- > Michael L. Hitch INTERNET: osymh@montana.edu > Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET > Office of Systems and Computing Services > Montana State University Bozeman, MT USA > There is nothing specific about the A3000 when doing a resident. 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 Mon May 16 13:07:38 1994 From: Arthur Hoffmann Subject: A3000 SCSI problems To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: 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: 1852 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > ahsc0 targ5 lun0 SCSI2 direct fixed > > sd5 at scsibus1: 100MB, 1211 cyl, 4 head, 42 sec, 512 bytes/sec > > ahsc0 targ6 lun0 SCSI2 direct fixed > > sd5 at scsibus1: 234MB, 1818 cyl, 4 head, 65 sec, 512 bytes/sec > > zthreebus0 at mainbus0 > > > > here the machine hangs with the HD light on steady. When I press a key > > I get a panic with the PC at 0001A34E. > > Maybe you are the first on to test the A3000 driver code? I don't > know if Chris Hopps had anyone try out the A3000 or A2091 driver. > Neither he nor I have an A3000 to test A3000-specific things on. > > Oh oh - I found what may be the problem: a3000dmaintr() calls > sbicintr, but passes the controller number instead of the sbic_softc > pointer. Try changing "sbicintr(i)" to "sbicintr(dev)". The A2091 > driver has the same bug (atzsc.c). > > Michael > You were right :) I changed the 'i' to a 'dev' and after zthreebus0 at mainbus0 it kept on going, but not very far. I get lots of hd types which were depreciated, then it went to fsck where it right away comes back with: /dev/rsd6a CANNOT SEEK: BLK 16 /dev/rsd6a UNEXPECTED INCONSISTENCY run fsck manually. manually didn't help either. Also I keep on getting: can not map ld.so errors.... cp complains about wrong arguments. When I try to go into mulit user mode lots of errors come flying along the screen until it says: init getty repeating too quickly on port /dev/ite0, sleeping. (Actually I had this error a couple of weeks ago when I was running old binaries with a new kernel) Does this mean that I need to have the rest of the source tree recompiled in order to use the new kernels? 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 Mon May 16 13:11:33 1994 From: Olaf Seibert To: hoffmann@it.ntu.edu.au, osymh@gemini.oscs.montana.edu Subject: Re: Wrong Machine identification Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Michael Hitch wrote: > Can you look at the resident module list under AmigaDOS and see > if there is a module with the name "A3000 Bonus" or something > similar? That's what loadbsd is looking for to tell that it is > running on an A3000. Well, I seem to have an A1000 Bonus. Which does not mean my A4000 is a A1000. Perhaps it magically knows that I also have an A1000 somewhere... *grin*. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 16 13:38:52 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "X-Windows for Spectrum........!" (May 15, 3:54pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: GDRUEBSAMEN@csupomona.edu, "amiga" Subject: Re: X-Windows for Spectrum........! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 15, 3:54pm, GDRUEBSAMEN@CSUPomona.Edu wrote: > Is there a way to get X-Windows working under the Spectrum card? If not is > there a port being planned (I cannot beleive there wouldnt be with so many > spectrum users...) There is a way - gotta do it yourself. Grab the Retina-sources, grab a manual for the Cirrus-Chipset and start programming. No joke. > Also, can someone tell me exaclty what DaggeX is?? Is it x-windows for > Amigados? Is there a FAQ? Is an X-server for AmigaDOS, yes. No FAQ. Some Apllications available for DaggeX, although what you want is to connect to a remote machine and start applications there. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 14:51:18 1994 From: Jarle.F.Greipsland@idt.unit.no To: current-users@sun-lamp.cs.berkeley.edu Subject: getrusage() returns bogus values Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, anyone else noticed that getrusage() returns garbage for ru_utime and ru_stime? I noticed this when I for once paid attention to what was at the end of one of my make log files. I usually do a % (time make whatever) >& makelog & or similar, and since the "offending" make job had failed almost immediately I was a bit surprised to see that it had spent thousands of seconds in system-cpu-state doing this..... Someone may want to have a look at it. Example output: % /usr/bin/time ls /tmp 0.02 real 0.00 user 2078.12 sys -jarle ---- "On the business front, UNIX has been under attack from a variety of sources, primarily by the nonexistant Windows NT. Luckily, the UNIX vendors have their own nonexistant products with which to answer the threat." -- Stephen C. Johnson, President (Usenix) From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 15:29:11 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 binaries for current? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <470.769087886.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone have XFree86-2.1.1 or 3.0 binaries for current available for FTP? Preferrably ones that use libc.so.11.x? Thanks in advance, Thorstn - 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 Mon May 16 15:41:23 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Jarle.F.Greipsland@idt.unit.no Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: getrusage() returns bogus values <199405161040.AA29595@drue.idt.unit.no> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Hi, anyone else noticed that getrusage() returns garbage for ru_utime and > ru_stime? Yes, i noticed this, know what the problem is, and will be fixing it tomorrow (later today). (I noticed it when profiling some things...) chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 17:10:17 1994 From: Arthur Hoffmann Subject: Re: Wrong Machine identification 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: 1046 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Michael Hitch wrote: > > Can you look at the resident module list under AmigaDOS and see > > if there is a module with the name "A3000 Bonus" or something > > similar? That's what loadbsd is looking for to tell that it is > > running on an A3000. > > Well, I seem to have an A1000 Bonus. Which does not mean my A4000 is > a A1000. Perhaps it magically knows that I also have an A1000 somewhere... > *grin*. > > -Olaf. > -- > ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl > \X/ An original idea. That can't be too hard. The library must be full of them. > Does that come up using the Amiga's shell program 'resident'? That is what I understood Michael wanted me to use to test it. I know that there is an A3000 bonus thing and some other strange A3000 related tasks (eg. battmem.device or something) because it comes up somewhere when using ARTM. 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 Mon May 16 18:29:56 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 Subject: Re: A3000 SCSI problems Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 16, 6:10pm, Arthur Hoffmann wrote: > You were right :) I changed the 'i' to a 'dev' and after zthreebus0 at > mainbus0 it kept on going, but not very far. I get lots of hd types > which were depreciated, then it went to fsck where it right away comes > back with: > /dev/rsd6a CANNOT SEEK: BLK 16 > /dev/rsd6a UNEXPECTED INCONSISTENCY run fsck manually. > manually didn't help either. Is /dev/rsd6a your root partition? If it is, I don't know what would be happening. I first suspected a problem doing DMA, but if that were the case, the root fs should never have gotten mounted in the first place. The DOS type fields in the RDB are handled a bit differently now. 'BSDR' still maps to partition 'a', and 'BSDS' maps to partition 'b'. The other values ('BSD[DEFGH]') are mapped to a single partition type and assigned to the partitions in the order they appear in the RDB. Most people probably have their partitions set up as 'BSDR', 'BSDS', 'BSDD', 'BSDE'... This setup should still work, but if the partitions are in a little different order, things won't map so good. On one of my disks I have the partitions as 'BSDR', 'BSDH', 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition was slightly larger than the second, so I exchanged them - they originally were in order]. This results in the 'BSDH' partition being assigned to 'd' and the 'BSDD' partition assigned to 'e'. As a result, /etc/fstab is no longer correct. > Also I keep on getting: can not map ld.so errors.... > cp complains about wrong arguments. > When I try to go into mulit user mode lots of errors come flying along > the screen until it says: > init getty repeating too quickly on port /dev/ite0, sleeping. > (Actually I had this error a couple of weeks ago when I was running > old binaries with a new kernel) > > Does this mean that I need to have the rest of the source tree > recompiled in order to use the new kernels? Yep - more syscall changes have been done making binaries and libraries incompatible. I haven't rebuilt the new stuff yet, as the kernel still isn't functional enough for my to really use. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 18:38:08 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Olaf Seibert Subject: Re: Wrong Machine identification Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 16, 12:28pm, Olaf Seibert wrote: > Michael Hitch wrote: > > Can you look at the resident module list under AmigaDOS and see > > if there is a module with the name "A3000 Bonus" or something > > similar? That's what loadbsd is looking for to tell that it is > > running on an A3000. > > Well, I seem to have an A1000 Bonus. Which does not mean my A4000 is > a A1000. Perhaps it magically knows that I also have an A1000 somewhere... > *grin*. So does mine. Loadbsd looks for "A1000 Bonus" and "A4000 Bonus" for the A4000 systems, and "A3000 Bonus" for the A3000. It appears that perhaps not all A3000 systems have that module (if any even do). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 18:56:07 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: Wrong Machine identification Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 16, 11:38pm, Arthur Hoffmann wrote: > Does that come up using the Amiga's shell program 'resident'? That is > what I understood Michael wanted me to use to test it. I know that > there is an A3000 bonus thing and some other strange A3000 related > tasks (eg. battmem.device or something) because it comes up somewhere when > using ARTM. No - the Amiga's shell program "resident" command only deals with AmigaOS commands. The resident modules I am referring to are modules detected at boot time that are resident - most of them will be from the Kickstart ROM, but some may be present from RAM via the KickMemPtr data. I need to know what the exact text for the A3000 Bonus module is (loadbsd is currently looking for "A3000 Bonus" and apparently is not finding it). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 16 22:37:58 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: adjtime(2) a noop? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <10817.769112763.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am running xntp and have lately experienced that it does not succeed in keeping the clock in sync with other servers. As far as I can make out, adjtime(2) calls never succeed, and I get a stream of "previous adjtime did not complete" before xntpd stops logging these events. This is with current as of May 14th. Ideas? 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 | ____________________________________ Meeting mailing list Administration: Send listserv-requests to From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 16 23:15:30 1994 From: GDRUEBSAMEN@csupomona.edu Subject: X-Windows Server for Spectrum.. To: "amiga" Sender: owner-amiga@sun-lamp.cs.berkeley.edu Date sent: 16-MAY-1994 I am no programmer... (ie cant program very well). I would like to however, help anyone who will write a server for the Spectrum by Beta Testing.. If there is anyone interested please let me know.. --- 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-current-users@sun-lamp.cs.berkeley.edu Mon May 16 23:33:25 1994 From: mark@aggregate.com (Mark P. Gooderum) To: michaelv@iastate.edu Subject: Re: SCSI questions Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 971 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Well, the stubs are there, the code has just never been written to do > the actual dance. There is a performance hit for doing it this way, > however, since you're doing a lot more copying for each disk transfer. > An EISA board will just plain be faster in this scenario. > > I know it isn't a high priority -- any idea on when bounce buffers > might make the list? > > --Michael Silly question... Wouldn't it be easier to write an allocator that just returns memory within the first 16M...the DMA bufs already have to be contiguous and locked in RAM...so it couldn't be too hard to look for a mem chunk in the first 16M and failing that reclaim pages until it did? You already have to have some way to get memory in the first 16M anyway so the first buffer of the bounce works, why not just make sure that the inital allocation gets the buffer that will work all the way through? This asked by a total non-expert in the details of the whole thing... -Mark From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 16 23:34:03 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Problems SUPping src/sys/lib/libkern 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 I tried supping ksrc-common and ksrc-amiga from scratch. When I tried to compile the kernel, it complained about a missing `../../../lib/libkern/Makefile.inc'. The only files in libkern were: Makefile libkern.h mcount.c ntohs.c I then popped over to sun-lamp and discovered many more files and an m68k subdirectory. Has this stuff been moved? I really don't want to sup all of ksrc. ========================================================================= 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 Tue May 17 00:10:08 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Problems SUPping src/sys/lib/libkern 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 Mon, 16 May 1994, I wrote: > > I tried supping ksrc-common and ksrc-amiga from scratch. When I tried > to compile the kernel, it complained about a missing > `../../../lib/libkern/Makefile.inc'. The only files in libkern were: Sorry. False alarm. I forgot I had to tell sup to check for old files. I would have noticed much sooner if so much of the source tree had not changed. Eduardo. From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 00:14:08 1994 Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SCSI questions <9405161949.AA08296@aggregate.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>Well, the stubs are there, the code has just never been written to do >> the actual dance. There is a performance hit for doing it this way, >> however, since you're doing a lot more copying for each disk transfer. >> An EISA board will just plain be faster in this scenario. >> >> I know it isn't a high priority -- any idea on when bounce buffers >> might make the list? >> >> --Michael >Wouldn't it be easier to write an allocator that just returns memory within >the first 16M...the DMA bufs already have to be contiguous and locked in >RAM...so it couldn't be too hard to look for a mem chunk in the first 16M >and failing that reclaim pages until it did? > >You already have to have some way to get memory in the first 16M anyway >so the first buffer of the bounce works, why not just make sure that the >inital allocation gets the buffer that will work all the way through? I'm not exactly sure what you're asking. If the memory allocator only gave memory below 16M, any extra memory you had would be worthless. It really wouldn't be useful to only allocate certain buffers below 16M because they aren't the only thing that gets direcly accessed. For instance, I believe the I/O code likes to transfer directly to/from user memory if possible when doing block transfers, and the kernel has no way of knowing at allocation time if a variable being allocated on the stack is going to be used only internally, or is going to end up as a block of memory used for buffered I/O. Also, what about paging? When the kernel elects a page to get swapped out, it DMA's that page directly to the disk device if possible. So, any allocated pages above 16M would either have to be bounced lower, or not paged out at all. NetBSD already allocates its buffers in very low memory. But they aren't the only things DMA touches in normal operation. Understand that these are just my understanding of the situation, and I very well could be missing something. >This asked by a total non-expert in the details of the whole thing... > >-Mark Don't worry -- I'm decidedly a non-expert myself. :-) I've just been hanging around here for a very long time. --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 May 17 00:18:46 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SCSI questions <9405161949.AA08296@aggregate.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 >Wouldn't it be easier to write an allocator that just returns memory within >the first 16M...the DMA bufs already have to be contiguous and locked in >RAM...so it couldn't be too hard to look for a mem chunk in the first 16M >and failing that reclaim pages until it did? > >You already have to have some way to get memory in the first 16M anyway >so the first buffer of the bounce works, why not just make sure that the >inital allocation gets the buffer that will work all the way through? > >This asked by a total non-expert in the details of the whole thing... Well, from someone who is almost but not quite a total non-expert ... As I understand it, the main problem lies with busmastering cards (for example, the Adaptec 1542). If you look in the dma routines in /sys/arch/i386/isa/isa.c you'll see that there is already bounce buffer support; this works great when it's the kernel that programs the DMA controllers (for example, the floppy controllers use this). However, when you have a card that does the DMA itself, THEN you have a problem, as it's not as easy to guarantee where the buffer is going to be located, and you don't want to have to copy every hunk of data. I think the solution you propose is one of the better ones; this completely gets rid of the need for bounce buffers. To really do this right, however, it would also be nice to guarantee that memory for user processes got allocated out of the upper memory first, so you could leave more in the lower 16Mb for use by the kernel. You could enable this gross hack by putting something like "options 16MEGHACK" in your kernel. If I remember right, the bounce buffer routines in isa.c allocate the space as a static array right in the kernel, guaranteeing that the space is below the 16Mb line; but I sure hope there is a better way than that :-) What does everyone else think? --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 00:59:19 1994 To: Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SCSI questions <9405162029.AA26325@ponderous.cc.iastate.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 >For instance, I believe the I/O code likes to transfer directly >to/from user memory if possible when doing block transfers, and the >kernel has no way of knowing at allocation time if a variable being >allocated on the stack is going to be used only internally, or is >going to end up as a block of memory used for buffered I/O. Also, >what about paging? When the kernel elects a page to get swapped out, >it DMA's that page directly to the disk device if possible. So, any >allocated pages above 16M would either have to be bounced lower, or >not paged out at all. Good points; please forget what I said before :-) Ya know ... it seems that in the case of the aha1542 at least, to get bounce buffers working all you'd need to do was to modify aha_scsi_cmd() and aha_done() to bounce if you had a transfer above the 16Mb line. Is that correct, or am I missing something else again? I realize that's not a very general solution, but it seems like it would be easy to apply to all the affected cards ... --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 04:36:16 1994 Subject: ramblings... 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: 2222 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I decided to upgrade from late March sources to current. A bit of a fight, especially in the middle of kvm changes, but I managed to get there. A couple of comments/ideas: - some SVR4 (notably solaris 2.x) have /var/mail (or whatever) with perms like: drwxrwxr-x 3 root mail 2048 May 17 10:39 /var/mail The mail.local (or whatever) is setgid mail instead of setuid root. Other mail delivery agents (such as elm's filter) are the same. As a recent problem with our favourite insecure os that is Not NetBSD (SunOS4 :) shows, maybe it would be a good idea to do this incase there are holes in the delivery agent, and anyway, it fits in with the concept of "don't make it suid root, make it sgid own_group". Would this be a Good Thing to do? - I have a 8MB root partition. As things are going with current, I can keep 2 kernels in / before I run out of space. As a space saving measure, would there be a problem in integrating all the mount_*fs commands which contain the same code with three lines changed (the 2 printf error messages & the mount(MOUNT_xxxFS) line) as one command. Then the program could check argv[0] and do a simple switch. Sure, it would only save about 150K, but that's 150K that /bin/sh now takes up because it has been attacked with rampant featuritus. - Another thing. Whilst building the tree, I noticed that links are fast, but compiles aren't. E.g, a command which has 2 .o files would link like: cc -o blah foo.o blah.o but a program with 1 .c file would compile/link like: cc -o blah -O ... blah.c Maybe if the above was changed to: cc -c -O ... blah.c cc -o blah blah.o So that when I do a make from the top level, all those commands in usr.bin are just relinked :) Enough crap, now let the threads begin... PS: has anyone noticed that gnu's groff, rcs, gcc, and uucp alone probably take more time to compile that the rest of the tree. I don't recompile groff or uucp anymore because of it :) -- ``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 May 17 04:58:42 1994 Subject: Re: XFree86 binaries for current? To: tholo@sigmasoft.com (Thorsten Lockert) Cc: 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: 1040 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does anyone have XFree86-2.1.1 or 3.0 binaries for current > available for FTP? Preferrably ones that use libc.so.11.x? I've just compiled up (from scratch), X11R5 with Xfree86-2.1.1, on the latest srcs. I intend (in the next couple of days) to make a) a binary distribution of netbsd-current, and b) a linkkit (shared only) of Xfree86-2.1.1 for the above. I know other people have done this, but I think I'm the only person who has done it where: 1) used the non-US crypt (written by davidb@werj.com.au), and 2) used the non-US Wraphelp.c for xdm (by eay@psych.psy.uq.oz.au? ) If I can drag my HD's into work tomorrow I'll put it on my anon. ftp site and mail this list again. & I finally decided to try & get X running at home. 3 compiles later (I wanted to do it myself :) and a bit of hair pulling (like, finding out about ttyv0 needs to be renamed back to ttyqf), and last night, I had X & lm. -- Luke Mewburn System Administrator & Programmer, Technical Email: Services Group, RMIT Computer Science From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 08:46:43 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: vmstat doesn't work: undefined symbols in /netbsd From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm running the generic kernel from 940427 and vmstat doesn't work with that one. It complains about undefined symbols in /netbsd. I have the binaries ( /usr etc. ) from ftp.iastate.edu. Any ideas anyone ? Speaking of kernels, is there a place where new kernels can be fetched ? John From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 09:13:32 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Libkern does not use the same includes as the kernel sources 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 was building a new kernel and discovered that CFLAGS are not passed on when the kernel build fires up the libkern makefile. This means that while the kernel is built using /src/sys/sys include files, libkern is build with /usr/include/sys. This could cause problems when upgrading to a major change, such as a /usr/include with a 32-bit off_t and a /src/sys/sys with a 64-bit off_t. Here is my proposed enhancement to make libkern consistent with the rest of the kernel: *** src/sys/lib/libkern/Makefile.inc~ Mon May 16 20:40:35 1994 --- src/sys/lib/libkern/Makefile.inc Mon May 16 20:40:17 1994 *************** *** 12,21 **** $(KERNLIB): .NOTMAIN __always_make_kernlib @echo making sure the kern library is up to date... ! @(cd $(KERNDIR) ; $(MAKE)) $(KERNLIB_PROF): .NOTMAIN __always_make_kernlib @echo making sure the profiled kern library is up to date... ! @(cd $(KERNDIR) ; $(MAKE)) __always_make_kernlib: .NOTMAIN --- 12,21 ---- $(KERNLIB): .NOTMAIN __always_make_kernlib @echo making sure the kern library is up to date... ! @(cd $(KERNDIR) ; $(MAKE) "CFLAGS=$(CFLAGS)") $(KERNLIB_PROF): .NOTMAIN __always_make_kernlib @echo making sure the profiled kern library is up to date... ! @(cd $(KERNDIR) ; $(MAKE) "CFLAGS=$(CFLAGS)") __always_make_kernlib: .NOTMAIN ========================================================================= 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 Tue May 17 09:15:09 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: make drops NULL arguments ..... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, FYI: I encountered this bug when building AUIS (Andrew User Inteface System or ATK) (all versions). At present the work arround is documented as `use gnu-make'. The versions of make found in NetBSD-0.9 and NetBSD-current (~ 2nd May) have a problem with executing commands of the form: rule: program arg "arg" "" where the last quoted argument is empty. Both versions of make drop the empty argument instead of passing a null string. This problem only occures when make tries to be smart by avoiding the need to use a shell to run the program. A rule like: rule: : && program arg "arg" "" which forces the use of the shell avoids the problem Has this been fixed in a more recent NetBSD-current? regards Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 10:50:33 1994 From: "Mark P. Gooderum" To: current-users@sun-lamp.cs.berkeley.edu Subject: Broken Bits in Current (5/16) Content-Length: 1791 Sender: owner-current-users@sun-lamp.cs.berkeley.edu With today's (Monday) current, I'm seeing the following problems: uname(3) is broken - I've traced this down to the sysctl() for KERN_VERSION failing with ENOMEM...the source for uname(3) looks good as best I can tell. This of course breaks uname(1). kernfs file sizes are broken - They show up like this: nirvana::mark-21> ls -l /kern total 0 -r--r--r-- 1 root wheel -4294967195 May 17 01:24 copyright -rw-r--r-- 1 root wheel -4294967288 May 17 01:24 hostname -r--r--r-- 1 root wheel -4294967292 May 17 01:24 hz -r--r--r-- 1 root wheel -4294967276 May 17 01:24 loadavg -r--r--r-- 1 root wheel -4294967291 May 17 01:24 physmem brw-r----- 1 root operator 0, 0 Apr 20 01:41 rootdev -r--r--r-- 1 root wheel -4294967279 May 17 01:24 time -r--r--r-- 1 root wheel -4294967170 May 17 01:24 version nirvana::mark-22> Finally, escaping $ in sh seems to have busted. The following line which used to work now tries to map to arg 6. It may be a POSIX thing but it works under bash. It only shows up with double escapes and recursive shells. This shows up in a script when trying to pass something like foo=`awk " print { \\$6 }" `, but is easily illustrated with the following example: sh-6/15: $ echo `echo $6` $ echo `echo \$6` $ echo `echo \\$6` $ bash: bash$ echo `echo $6` bash$ echo `echo \$6` bash$ echo `echo \\$6` $6 bash$ If bash is wrong then I'd appreciate the "right" way to do this... The kernfs and uname broke going from 5/6 current to 5/12 current and stayed busted through today (everything else broken over the weekend seems to have been gotten). I'm not sure where sh broke since it didn't build for sups over 5/12 and 5/13. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 11:35:31 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: "Mark P. Gooderum" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Broken Bits in Current (5/16) <199405170634.BAA00532@nirvana.good.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > uname(3) is broken - I've traced this down to the sysctl() for > KERN_VERSION failing with ENOMEM...the source for uname(3) > looks good as best I can tell. This of course breaks > uname(1). i fixed this the other day; you need the new utsname.h header file, and then you need to recompile the uname.c header file. > kernfs file sizes are broken - They show up like this: > > nirvana::mark-21> ls -l /kern > total 0 > -r--r--r-- 1 root wheel -4294967195 May 17 01:24 copyright > -rw-r--r-- 1 root wheel -4294967288 May 17 01:24 hostname > -r--r--r-- 1 root wheel -4294967292 May 17 01:24 hz > -r--r--r-- 1 root wheel -4294967276 May 17 01:24 loadavg > -r--r--r-- 1 root wheel -4294967291 May 17 01:24 physmem > brw-r----- 1 root operator 0, 0 Apr 20 01:41 rootdev > -r--r--r-- 1 root wheel -4294967279 May 17 01:24 time > -r--r--r-- 1 root wheel -4294967170 May 17 01:24 version > nirvana::mark-22> charles fixed these a few minutes ago. > Finally, escaping $ in sh seems to have busted. The following > line which used to work now tries to map to arg 6. It may be a POSIX thing > but it works under bash. It only shows up with double escapes and > recursive shells. This shows up in a script when trying to pass something > like foo=`awk " print { \\$6 }" `, but is easily illustrated with the > following example: I'm not sure about this; perhaps jtc can shed some light on it... later, chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 11:43:54 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 binaries for current? <199405170031.KAA23538@goanna.cs.rmit.oz.au> X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 420 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Tue 17) > Does anyone have XFree86-2.1.1 or 3.0 binaries for current > available for FTP? Preferrably ones that use libc.so.11.x? I updated the binary distribution on ftp.laas.fr:/pub/netbsd/XFree86-2.1.1/ It was built under 05/14 -current. There are new bin, lib, xdm and linkit tarfiles. BTW the linkkit is now up-to date. (previous version missed some files). Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 14:11:36 1994 From: jmc@gnu.ai.mit.edu Subject: Re: ramblings... To: lm@rmit.edu.au 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: 508 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >PS: has anyone noticed that gnu's groff, rcs, gcc, and uucp alone probably >take more time to compile that the rest of the tree. I don't recompile >groff or uucp anymore because of it :) > I've gotten to the point here, that unless something drastic changes like a shared library revision for libc, I won't make the gnu subdir since it takes forever...Otherwise, it's still always the last thing to get done for me since its rather boring (I've compiled gcc enough already on other systems :-). James From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 14:49:24 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: Broken Bits in Current (5/16) To: mark@nirvana.good.com (Mark P. Gooderum) 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: 533 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Finally, escaping $ in sh seems to have busted. The following > line which used to work now tries to map to arg 6. It may be a POSIX thing > but it works under bash. It only shows up with double escapes and > recursive shells. This shows up in a script when trying to pass something > like foo=`awk " print { \\$6 }" `, but is easily illustrated with the > following example: It's not a POSIX thing, bash is much closer to POSIX.2 compliant than we we are. It's just plain broken. I'll look into it tomorrow. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 15:12:44 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: Broken Bits in Current (5/16) To: mark@nirvana.good.com (Mark P. Gooderum) 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: 159 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Finally, escaping $ in sh seems to have busted. The following > line which used to work now tries to map to arg 6. I just checked in the fix. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 16:07:43 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Should SIZE_T_MAX be defined (machine dependantly) everywhere? From: - Greg Earle Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I'm running NetBSD/SPARC with Theo's last binary snapshot and I downloaded Saturday's tar balls and set off to do a "make build". It fell over in .../lib/libc/gen/nlist.c because __fdnlist() wants to check to see if a file is too large to mmap(), and it compares it against SIZE_T_MAX. From what I can tell, SIZE_T_MAX is only defined in limits.h for the i386, m68k and pmax architectures. (No wonder I hadn't seen anything posted about it, since it works on i386 (-: ) Should there be a SIZE_T_MAX in every limits.h for all architectures (i.e., in /usr/src/sys/arch//include/limits.h, so it'll end up in /usr/include/machine/limits.h), or should there be a global default in /usr/include/sys/syslimits.h, perhaps using "#ifndef SIZE_T_MAX"? To put it another way, I haven't seen any port where _SIZE_T_ wasn't an "unsigned int"; would putting "#ifndef SIZE_T_MAX \ #define SIZE_T_MAX UINT_MAX \ #endif" into the default be a Bad Idea? (Being cautious here ... ) In the meantime, how do I "properly" fix lib/libc/gen/nlist.c - Greg From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 16:14:32 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 doc/CHANGES U src/bin/df/df.c U src/bin/ps/Makefile U src/include/Makefile U src/include/ar.h U src/include/assert.h U src/include/ctype.h U src/include/grp.h U src/include/nlist.h U src/include/pwd.h U src/include/setjmp.h U src/include/time.h U src/include/utmp.h U src/include/protocols/dumprestore.h U src/lib/libc/gen/assert.c U src/lib/libc/gen/ctype_.c U src/lib/libc/gen/isctype.c U src/lib/libc/stdio/printf.3 U src/lib/libkvm/Makefile U src/lib/libkvm/kvm_om68k.c U src/sbin/restore/dirs.c U src/sbin/restore/pathnames.h U src/sbin/restore/restore.h U src/sbin/restore/tape.c U src/sys/adosfs/advnops.c U src/sys/arch/amiga/amiga/device.h U src/sys/arch/amiga/amiga/disksubr.c U src/sys/arch/amiga/amiga/swapgeneric.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/dev/ahsc.c U src/sys/arch/amiga/dev/atzsc.c U src/sys/arch/amiga/dev/gtsc.c U src/sys/arch/amiga/dev/ser.c U src/sys/arch/amiga/include/profile.h U src/sys/arch/hp300/conf/DUALITY U src/sys/arch/hp300/conf/HP300 U src/sys/arch/hp300/dev/grf.c U src/sys/arch/hp300/hp300/clock.c U src/sys/arch/hp300/hp300/conf.c U src/sys/arch/hp300/hp300/machdep.c U src/sys/arch/hp300/hp300/pmap.c U src/sys/arch/hp300/hp300/trap.c U src/sys/arch/hp300/hpux/hpux_compat.c U src/sys/arch/hp300/hpux/hpux_sig.c U src/sys/arch/hp300/hpux/hpux_syscall.h U src/sys/arch/hp300/hpux/hpux_syscalls.c U src/sys/arch/hp300/hpux/hpux_sysent.c U src/sys/arch/hp300/hpux/syscalls.master U src/sys/arch/hp300/include/cpu.h U src/sys/arch/hp300/include/param.h U src/sys/arch/hp300/include/pmap.h U src/sys/arch/i386/i386/conf.c U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/include/varargs.h U src/sys/arch/m68k/include/varargs.h U src/sys/arch/m68k/m68k/db_disasm.c U src/sys/arch/pc532/include/ansi.h U src/sys/arch/pc532/include/stdarg.h U src/sys/arch/pc532/include/varargs.h U src/sys/arch/pc532/pc532/conf.c U src/sys/arch/sun3/dev/if_le.c U src/sys/arch/sun3/dev/si.c U src/sys/arch/sun3/sun3/isr.c U src/sys/arch/sun3/sun3/process.s U src/sys/arch/sun3/sun3/trap.c U src/sys/conf/param.c U src/sys/kern/init_main.c U src/sys/kern/init_sysent.c U src/sys/kern/kern_acct.c U src/sys/kern/kern_descrip.c U src/sys/kern/kern_exit.c U src/sys/kern/kern_fork.c U src/sys/kern/kern_prot.c U src/sys/kern/kern_resource.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_subr.c U src/sys/kern/kern_xxx.c U src/sys/kern/makesyscalls.sh U src/sys/kern/syscalls.c U src/sys/kern/syscalls.master U src/sys/kern/vfs_bio.c U src/sys/kern/vfs_lookup.c U src/sys/kern/vfs_subr.c U src/sys/kern/vfs_vnops.c U src/sys/lib/libkern/Makefile U src/sys/miscfs/kernfs/kernfs_vnops.c U src/sys/net/if_tun.c U src/sys/sys/acct.h U src/sys/sys/callout.h U src/sys/sys/exec.h U src/sys/sys/fcntl.h U src/sys/sys/ioctl.h U src/sys/sys/ioctl_compat.h U src/sys/sys/ipc.h U src/sys/sys/map.h U src/sys/sys/param.h U src/sys/sys/stat.h U src/sys/sys/syscall.h U src/sys/sys/timeb.h U src/sys/sys/times.h U src/sys/sys/ttydefaults.h U src/sys/sys/types.h U src/sys/sys/utsname.h U src/sys/ufs/dir.h U src/sys/ufs/ufs_lookup.c U src/sys/ufs/ufs_vfsops.c U src/usr.bin/gprof/Makefile U src/usr.bin/gprof/arcs.c U src/usr.bin/gprof/dfn.c U src/usr.bin/gprof/gprof.1 U src/usr.bin/gprof/gprof.c U src/usr.bin/gprof/gprof.h U src/usr.bin/gprof/hertz.c U src/usr.bin/gprof/i386.c U src/usr.bin/gprof/i386.h U src/usr.bin/gprof/lookup.c U src/usr.bin/gprof/m68k.c U src/usr.bin/gprof/m68k.h U src/usr.bin/gprof/mips.c U src/usr.bin/gprof/mips.h U src/usr.bin/gprof/pathnames.h U src/usr.bin/gprof/pmax.c U src/usr.bin/gprof/pmax.h U src/usr.bin/gprof/printgprof.c U src/usr.bin/gprof/printlist.c U src/usr.bin/gprof/sparc.c U src/usr.bin/gprof/sparc.h U src/usr.bin/gprof/tahoe.c U src/usr.bin/gprof/tahoe.h U src/usr.bin/gprof/vax.c U src/usr.bin/gprof/vax.h U src/usr.bin/gprof/PSD.doc/Makefile U src/usr.bin/gprof/PSD.doc/abstract.me U src/usr.bin/gprof/PSD.doc/gathering.me U src/usr.bin/gprof/PSD.doc/header.me U src/usr.bin/gprof/PSD.doc/intro.me U src/usr.bin/gprof/PSD.doc/postp.me U src/usr.bin/gprof/PSD.doc/postp1.pic U src/usr.bin/gprof/PSD.doc/postp2.pic U src/usr.bin/gprof/PSD.doc/postp3.pic U src/usr.bin/gprof/PSD.doc/pres1.pic U src/usr.bin/gprof/PSD.doc/pres2.pic U src/usr.bin/gprof/PSD.doc/present.me U src/usr.bin/gprof/PSD.doc/profiling.me U src/usr.bin/gprof/PSD.doc/refs.me U src/usr.bin/m4/serv.c U src/usr.bin/mesg/mesg.c U src/usr.sbin/Makefile U src/usr.sbin/arp/Makefile U src/usr.sbin/iostat/Makefile U src/usr.sbin/lpr/common_source/common.c U src/usr.sbin/lpr/lpr/lpr.c U src/usr.sbin/mrouted/config.c U src/usr.sbin/mrouted/mrouted.8 U src/usr.sbin/mrouted/vif.c U src/usr.sbin/mrouted/vif.h U src/usr.sbin/pstat/pstat.c U src/usr.sbin/traceroute/Makefile U src/usr.sbin/traceroute/mean.awk U src/usr.sbin/traceroute/median.awk U src/usr.sbin/traceroute/traceroute.8 U src/usr.sbin/traceroute/traceroute.c Running the SUP scanner: SUP Scan for current starting at Tue May 17 03:58:41 1994 SUP Scan for current completed at Tue May 17 04:01:47 1994 SUP Scan for mirror starting at Tue May 17 04:01:48 1994 SUP Scan for mirror completed at Tue May 17 04:05:03 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 16:45:46 1994 From: deraadt@fsa.ca (Theo Deraadt) To: current-users@sun-lamp.cs.berkeley.edu, eeh@btr.btr.com Subject: Re: Libkern does not use the same includes as the kernel sources Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ! @(cd $(KERNDIR) ; $(MAKE) "CFLAGS=$(CFLAGS)") This won't work, and in fact will break the sparc. You can't do this. I am well aware of the dependence of /usr/include. It's a very bad thing, but passing in -DKERNEL is worse. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 17:44:07 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 Subject: Re: Wrong Machine identification Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 17, 2:21pm, Arthur Hoffmann wrote: > > > > No - the Amiga's shell program "resident" command only deals with AmigaOS > > commands. The resident modules I am referring to are modules detected at > > boot time that are resident - most of them will be from the Kickstart ROM, > > but some may be present from RAM via the KickMemPtr data. I need to know > > what the exact text for the A3000 Bonus module is (loadbsd is currently > > looking for "A3000 Bonus" and apparently is not finding it). > > > > Michael > > > I used artm now to see what you mean, when I use the resident button > in there I get the following: > > Address Type Pri Vers Flags Name > 00f864f8 unknown 101 37 00000001 A3000 bonus > > I don't know if the case matters, but it comes up exactly as above > (bonus in lower case letters). Yes, the case does matter - loadbsd is looking for upper case. A quick fix would be to use a binary file editor on loadbsd and change the string "A3000 Bonus" to "A3000 bonus". That should fix it. I'll change loadbsd to check for the uncapitalized string. > I hope that helps. Yes, it does. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 17:49:50 1994 From: Hubert Feyrer Subject: sys.19940515 II To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 872 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've tweaked start_c() in amiga/amiga_init.c and inserted some rollcolor()'s just as Chris told me, but no change so far: Even if I do rollcolor() ath the very beginning of start_c(), it won't change any color, so I guess this locore.s 's the guilty one? Again, this is on a A2000 with 68030+68882. Help, Hubert P.S.: Who _has_ a kernel running with the sources from last weekend (13.-15. may), and on which machine (CPU/MMU)? =============== 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 Tue May 17 17:57:07 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Problem with sys/gmon.h 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 I found a little problem with sys/gmon.h. It includes machine/profile.h, but for 68000 based systems, machine/profile.h is m68k/profile.h. I can't find a clean solution to this problem. 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 Tue May 17 18:17:44 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Eduardo E. Horvath eeh@btr.com" , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Problem with sys/gmon.h Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 17, 7:49am, "Eduardo E. Horvath eeh@btr.com" wrote: > I found a little problem with sys/gmon.h. It includes machine/profile.h, > but for 68000 based systems, machine/profile.h is m68k/profile.h. I > can't find a clean solution to this problem. Any ideas? The standard solution is to create a file .../amiga/include/profile.h that includes "m68k/profile.h". See other files in amiga/include for examples. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 18:30:02 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: fix for empty quoted args in make(1) Cc: Keith Bostic Sender: owner-current-users@sun-lamp.cs.berkeley.edu Fix for quoted args in make: Repeat by: % cat t1 #!/bin/sh echo $# for i do echo ">$i<" done % cat Makefile foo: t1 "''" '"' "'" '""' '' 'a b' "b c" % make Note that the argument before 'a b' is missing. christos *** str.c.orig Thu Mar 24 05:59:35 1994 --- str.c Tue May 17 09:37:11 1994 *************** *** 139,146 **** inquote = '\0'; else break; ! else inquote = (char) ch; continue; case ' ': case '\t': --- 138,151 ---- inquote = '\0'; else break; ! else { inquote = (char) ch; + /* Don't miss "" or '' */ + if (start == NULL && p[1] == inquote) { + start = t + 1; + break; + } + } continue; case ' ': case '\t': From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 18:34:15 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: kern/tty_tb.c does not compile? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Here's a patch: *** tty_tb.c.dist Tue May 17 09:46:42 1994 --- tty_tb.c Fri May 13 15:54:55 1994 *************** *** 42,48 **** --- 42,50 ---- */ #include #include + #include #include + #include /* * Tablet configuration table. *************** *** 333,349 **** if (tbp->tbflags&TBSTOP) { if (tc->tbc_stop) for (c = tc->tbc_stop; *c != '\0'; c++); ! ttyout(c, tp); } else if (tc->tbc_start) for (c = tc->tbc_start; *c != '\0'; c++); ! ttyout(c, tp); if (tbp->tbflags&TBPOINT) { if (tc->tbc_point) for (c = tc->tbc_point; *c != '\0'; c++); ! ttyout(c, tp); } else if (tc->tbc_run) for (c = tc->tbc_run; *c != '\0'; c++); ! ttyout(c, tp); ttstart(tp); break; } --- 335,351 ---- if (tbp->tbflags&TBSTOP) { if (tc->tbc_stop) for (c = tc->tbc_stop; *c != '\0'; c++); ! ttyoutput(*c, tp); } else if (tc->tbc_start) for (c = tc->tbc_start; *c != '\0'; c++); ! ttyoutput(*c, tp); if (tbp->tbflags&TBPOINT) { if (tc->tbc_point) for (c = tc->tbc_point; *c != '\0'; c++); ! ttyoutput(*c, tp); } else if (tc->tbc_run) for (c = tc->tbc_run; *c != '\0'; c++); ! ttyoutput(*c, tp); ttstart(tp); break; } From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 18:47:12 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Hubert Feyrer , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940515 II Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 17, 4:50pm, Hubert Feyrer wrote: > I've tweaked start_c() in amiga/amiga_init.c and inserted some > rollcolor()'s just as Chris told me, but no change so far: Even if I > do rollcolor() ath the very beginning of start_c(), it won't change > any color, so I guess this locore.s 's the guilty one? You can also set the color in locore.s in the startup code to be sure you are getting that far. I usually just set the color directly: movw #0xf00,0xdff180 Putting on right after start: should indicate that you got to the kernel entry point. Adding another just before the jsr _start_c will let you know you got to that point. > P.S.: Who _has_ a kernel running with the sources from last weekend > (13.-15. may), and on which machine (CPU/MMU)? I've got a kernel created from the 940513 sources and it works fine on both my 68040 systems (A4000+Warp Engine, and A2000+PPI Zeus). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 19:18:50 1994 From: mw@eunet.ch Subject: Re: A3000 SCSI problems To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1161 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > values ('BSD[DEFGH]') are mapped to a single partition type and assigned > to the partitions in the order they appear in the RDB. Most people probably > have their partitions set up as 'BSDR', 'BSDS', 'BSDD', 'BSDE'... This > setup should still work, but if the partitions are in a little different > order, things won't map so good. On one of my disks I have the partitions > as 'BSDR', 'BSDH', 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition > was slightly larger than the second, so I exchanged them - they originally > were in order]. This results in the 'BSDH' partition being assigned to 'd' > and the 'BSDD' partition assigned to 'e'. As a result, /etc/fstab is no > longer correct. Eh, simple question, sorry, but isn't such a behavior plain braindead? I used different DOS types *on purpose* to be able to exchange partitions on the fly. If I wanted the current behavior, there'd be only one type.. ARGL... Guess I'll really freeze my own NetBSD core sources now... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 19:57:07 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A3000 SCSI problems To: mw@eunet.ch Cc: osymh@gemini.oscs.montana.edu, hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2064 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > > values ('BSD[DEFGH]') are mapped to a single partition type and assigned > > to the partitions in the order they appear in the RDB. Most people probably > > have their partitions set up as 'BSDR', 'BSDS', 'BSDD', 'BSDE'... This > > setup should still work, but if the partitions are in a little different > > order, things won't map so good. On one of my disks I have the partitions > > as 'BSDR', 'BSDH', 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition > > was slightly larger than the second, so I exchanged them - they originally > > were in order]. This results in the 'BSDH' partition being assigned to 'd' > > and the 'BSDD' partition assigned to 'e'. As a result, /etc/fstab is no > > longer correct. > > Eh, simple question, sorry, but isn't such a behavior plain braindead? I used > different DOS types *on purpose* to be able to exchange partitions on the > fly. If I wanted the current behavior, there'd be only one type.. ARGL... What is the purpose of switching user partitions? I asked myself this when I first changed it and I came up with no good answer. Furthermore your old system was far more broken in that it did not allow the user to specify the file system type I seem to remeber a line of source: ->p_fstype = FS_BSDFFS; /* XXX */ Thats not braindead? AmigaDos types for AmigaDos specify the file system type and not the order of configuration and now thats how they work for NetBSD. > Guess I'll really freeze my own NetBSD core sources now... I think you would be doing a real diservice to all amiga owners if you do something like this Markus. Do you really want to remove yourself from NetBSD over small things like this? I wouldn't like to lose you. However your free to do what you wish. Nothing new for netbsd will run on your frozen sources. 4.4 Lite is being actively integrated. You either get on the train or you sit at the station and go nowhere. If all you ever wanted NetBSD for was to run it at home then I suppose this works for you. Thanks for all your work either way. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:16:42 1994 From: mw@eunet.ch Subject: Re: A3000 SCSI problems To: chopps@emunix.emich.edu (Chris Hopps) Cc: mw@eunet.ch, osymh@gemini.oscs.montana.edu, hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2804 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > What is the purpose of switching user partitions? I asked myself this > when I first changed it and I came up with no good answer. Furthermore Ok, I might not exactly be Joe User when it comes to setting up different partitions to test different configurations, but believe me, it came in very handy.. One trick a lot of users certainly used was to swap the root partition on the fly, I hope you at least kept that feature? > your old system was far more broken in that it did not allow the user > to specify the file system type I seem to remeber a line of source: > > ->p_fstype = FS_BSDFFS; /* XXX */ Eh, right:-) > Thats not braindead? AmigaDos types for AmigaDos specify the file system > type and not the order of configuration and now thats how they work > for NetBSD. The reason why I implemented things my way were based on my experiences with Amiga Unix, mapping first found partition to ...s1, second to ...s2, etc, with the VERY annoying problem that this put you under the dictate of the person who configured the kernel for how many partitions it would recognize. Of course, on my first attempt, I had Unix partitions start at partition #8, and Unix knew only about 7 partitions... I already have partition overflow with the (my..:-))current kernel of 16 partitions, and I'm glad I can at least force BSD to use whatever partitions I want it to, and whereever they might be on my disk. Filesystem was a secondary issue, there was only ufs :-) > > Guess I'll really freeze my own NetBSD core sources now... > > I think you would be doing a real diservice to all amiga owners if you > do something like this Markus. Do you really want to remove yourself > from NetBSD over small things like this? I wouldn't like to lose you. Well, first of all, thanks:-) Lets make the above statement clearer. NetBSD has taken a course which I don't like in some parts. This is pretty personal, and I explained some dislikes when they were added (hello, 64bit..). I'll continue to work on my system, work on device drivers in which I have personal interest (just as always:-)), but I'll not work with 'off-the-shelve' NetBSD-current any longer. I'll from time to time incorporate what I like though. Since this is going to be real work, updating my system will certainly take time. For now, I'm happy with a perfectly running system, and don't feel very motivated to change that status... So, I'm glad that you Chris continue to keep in touch with the main NetBSD line. I myself was always pretty lazy incorporating other sources:-)) For those that want a `real' NetBSD on their amiga, that's the optimal sollution! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:23:01 1994 From: rhealey@aggregate.com Subject: Intergalactic Amiga stellar filesystem peace To: amiga-dev@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: 475 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Re: the recent positions on how filesystem partitions should be named and groked: All this happens in one or two routines yes? Maybe we can add a config option to select one of two methods? I'd still like to see the UNI\? naming scheme for the newer method as ADOS ROMS can grok these as UNIX partitions which would be c00l! B^). C= has marooned us all recently, let's put forth an effort not to divvy up the island in to too many pieces and factions... -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:23:44 1994 From: rhealey@aggregate.com Subject: Re: A3000 SCSI problems To: mw@eunet.ch Cc: amiga-dev@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: 3196 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > values ('BSD[DEFGH]') are mapped to a single partition type and assigned > > to the partitions in the order they appear in the RDB. Most people probably > > have their partitions set up as 'BSDR', 'BSDS', 'BSDD', 'BSDE'... This > > setup should still work, but if the partitions are in a little different > > order, things won't map so good. On one of my disks I have the partitions > > as 'BSDR', 'BSDH', 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition > > was slightly larger than the second, so I exchanged them - they originally > > were in order]. This results in the 'BSDH' partition being assigned to 'd' > > and the 'BSDD' partition assigned to 'e'. As a result, /etc/fstab is no > > longer correct. > > Eh, simple question, sorry, but isn't such a behavior plain braindead? I used > different DOS types *on purpose* to be able to exchange partitions on the > fly. If I wanted the current behavior, there'd be only one type.. ARGL... > Enter soapbox mode: I suppose it all depends on how you look at the partitioning pair-O-digm. Under the other Unixi they don't use unique identifiers to decide which goes where, it's simply their assigned in order of their appearance in the tables. Under this view the new scheme is consistant with other architectures and might simplify generic support for Amiga. Other people, yourself included, want the type name to matter so you can move it around at will and have the assignments match. I guess to be consistant with ADOS, AmigaUNIX and how other arch's do things the newer method makes more sense although it makes it a bitch to move partition names around arbitrarily. ADOS has DOS\? partition names, Amix has UNI\?. To be consistant NetBSD probably should call it's partitions BSD\? or extend the Amix model and use UNI\?. UNI\1 is s5 format, UNI\2 is paging, UNI\3 is 4.2 UFS. UNI\4 could be new style UFS and UNI\5 could be the 4.4 log file system. Or we could say fork() Amix and use UNI\1 as BSD UFS, UNI\2 as paging and UNI\3 as 4.4 log fs. This would be more consistant than either then new or old NetBSD ways as it jibes with the precident in ADOS and AMIX. Actually, by using the Amix UNI\? values the 2.04 and above ROMs would grok them as UNIX partitions as the newer ROMS know about UNI\? stuff. As I don't move partition names around arbitrarily I guess I'm for the new method. I can see why you'd consider it braindead but I don't see the moving of partitions happening often enough to matter. As for changing it, it is now consistant with how the other ports handle their partitions, in order, and that seems more important to keep the Amiga port in step with the other ports. All comes back to what individuals feel should be the goal of NetBSD Amiga. If it's to make the Amiga port as close to standard ports as possible then the newer method, maybe with UNI\? names, should be used. If it's to do whatever would be cool for the Amiga and don't care if it differs from other ports then you should definitely keep the old method as it's easier to play musical disks and partitions. Whatever flips your flipper I guess... End of soapbox speech, -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:31:32 1994 From: mw@eunet.ch Subject: Re: A3000 SCSI problems To: rhealey@aggregate.com Cc: mw@eunet.ch, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2021 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Enter soapbox mode: Yeah, got too soapy there, sorry for the harsh tone. > I suppose it all depends on how you look at the partitioning > pair-O-digm. Under the other Unixi they don't use unique identifiers > to decide which goes where, it's simply their assigned in order of > their appearance in the tables. Under this view the new scheme is > consistant with other architectures and might simplify generic > support for Amiga. True aspect. I detailed my intentions behind the scheme in my last mail. > To be consistant NetBSD probably should call it's partitions BSD\? or > extend the Amix model and use UNI\?. UNI\1 is s5 format, UNI\2 is > paging, UNI\3 is 4.2 UFS. UNI\4 could be new style UFS and UNI\5 could > be the 4.4 log file system. Or we could say fork() Amix and use UNI\1 > as BSD UFS, UNI\2 as paging and UNI\3 as 4.4 log fs. Well, nuke Amiga Unix use, if you want, it completely ignores dostypes.. (when I still had it up, I changed its filesystem dostypes to BSDx types, and Amiga Unix didn't care a bit...). > This would be more consistant than either then new or old NetBSD ways > as it jibes with the precident in ADOS and AMIX. Actually, by using the > Amix UNI\? values the 2.04 and above ROMs would grok them as UNIX > partitions as the newer ROMS know about UNI\? stuff. Yes, but besided getting a neater description of the type in HDToolBox, this doesn't give you additional functionality, as newer ADos software doesn't show you partitions with dostypes that don't match any loaded filesystems, anyway. > All comes back to what individuals feel should be the goal of NetBSD > Amiga. Yup, and that's the reason why I feel I'm not very helpful to those that want a `compatible' NetBSD Amiga, so I'm taking some distance. Hey, we still have just one BSD for the Amiga, PCs have 1, 2, 3, ... :-)) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:34:45 1994 From: chopps@emunix.emich.edu (Chris Hopps) Subject: Re: A3000 SCSI problems To: mw@eunet.ch Cc: osymh@gemini.oscs.montana.edu, hoffmann@it.ntu.edu.au, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1174 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > partition on the fly, I hope you at least kept that feature? Yes. NBR\fs NBS\1 and NBU\fs > The reason why I implemented things my way were based on my experiences > with Amiga Unix, mapping first found partition to ...s1, second to ...s2, > etc, with the VERY annoying problem that this put you under the dictate of > the person who configured the kernel for how many partitions it would > recognize. Of course, on my first attempt, I had Unix partitions start > at partition #8, and Unix knew only about 7 partitions... I already have > partition overflow with the (my..:-))current kernel of 16 partitions, and > I'm glad I can at least force BSD to use whatever partitions I want it to, > and whereever they might be on my disk. Filesystem was a secondary issue, there > was only ufs :-) Well I am unsure of you current setup, however under mine you can have up to 13 partitions plus root and swap. It matters not what file system type they are. If you have 13 BSD file systems that will work if you have 3 ados and 10 bsd that works too. neither of those situations was covered by the older system which limited bsd file systems to 5 plus root and swap. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:51:34 1994 From: Greg Oster Subject: Re: A3000 SCSI problems To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: 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: 1817 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Michael L. Hitch writes: > The DOS type fields in the RDB are handled a bit differently now. 'BSDR' > still maps to partition 'a', and 'BSDS' maps to partition 'b'. The other > values ('BSD[DEFGH]') are mapped to a single partition type and > assigned to the partitions in the order they appear in the RDB. > Most people probably have their partitions set up as 'BSDR', 'BSDS', > 'BSDD', 'BSDE'... This setup should still work, but if the > partitions are in a little different order, things won't map so > good. On one of my disks I have the partitions as 'BSDR', 'BSDH', > 'BSDD', 'BSDE', 'BSDF', 'BSDG', 'BSDS' [the last partition was > slightly larger than the second, so I exchanged them - they > originally were in order]. This results in the 'BSDH' partition > being assigned to 'd' and the 'BSDD' partition assigned to 'e'. As > a result, /etc/fstab is no longer correct. Why is has this changed? Does it make it easier to do something on the NetBSD side? I don't see any gain here, only discomfort... In particular, if you have a configuration like: BSDR - root1 BSDS - swap BSDH - root2 BSDE - /usr BSDF - /home ... You now won't be able to swap root1 with root2 (i.e. rename the partitions under AmigaDOS to BSDH, BSDS, BSDR, ...) to boot from an alternate root without a) putting root2 at the end of your drive and hacking /etc/fstab to flipflop amongst BSDE, BSDF, etc. and never really know where the heck anything is, or b) making BSDE the name of the second root partition. Neither of these are very desirable options for me... Just my $0.02. Maybe someone can enlighten me as to why this change is a good one... Keep up the good work guys... Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 20:51:53 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: What happened to `SGTTY'? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, In NetBSD-0.9:/usr/include/curses.h there was the definition: typedef struct sgttyb SGTTY; It's not (or at least I can't find it) in NetBSD-current.2-may. Should it be missing? If so what should be done for programs requiring this? Any hints appreciated. Andrew From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 20:52:12 1994 From: rhealey@aggregate.com Subject: Re: A3000 SCSI problems To: mw@eunet.ch Cc: amiga-dev@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: 4008 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Ok, I might not exactly be Joe User when it comes to setting up different > partitions to test different configurations, but believe me, it came in > very handy.. One trick a lot of users certainly used was to swap the root > partition on the fly, I hope you at least kept that feature? > If we did this the RIGHT way then we SHOULD use the partition priority in the RDB record, after all, THAT'S WHAT IT'S THERE FOR! i.e. have loadbsd or the bootsector loader scan the rdb for the highest priority UNI\1, BSDR or whatever we end up calling it. > > Thats not braindead? AmigaDos types for AmigaDos specify the file system > > type and not the order of configuration and now thats how they work > > for NetBSD. > > The reason why I implemented things my way were based on my experiences > with Amiga Unix, mapping first found partition to ...s1, second to ...s2, > etc, with the VERY annoying problem that this put you under the dictate of > the person who configured the kernel for how many partitions it would > recognize. Of course, on my first attempt, I had Unix partitions start > at partition #8, and Unix knew only about 7 partitions... I already have > partition overflow with the (my..:-))current kernel of 16 partitions, and > I'm glad I can at least force BSD to use whatever partitions I want it to, > and whereever they might be on my disk. Filesystem was a secondary issue, there > was only ufs :-) > Well, as a fellow elderly fart who toiled and labored under AmigaUNIX I'd like to clearify some things and point out the the AMIX boot BS made the above necessary but with NetBSD we can do it THE RIGHT WAY(tm)! AMIX was braindead in it's boot in that it used a seperate boot partition from root in order to allow booting from s5 or ufs filesystems, i.e. s5 doesn't have the 8k free area at the front of the filesystem like ufs does for a bootstrap loader. If only UFS was allowed then they could have put the bootstrap in the 8k on the front of root and just use the RDB priority to decide who was the root filesystem. With NetBSD we can "DO THE RIGHT THING(tm)". We can put the direct bootstrap stage 1 in the 8k area on the front of the root filesystem and then use the rdb priority scheme + bootstrap smarts to "do the right thing"! > Well, first of all, thanks:-) Lets make the above statement clearer. > NetBSD has taken a course which I don't like in some parts. This is > pretty personal, and I explained some dislikes when they were added > (hello, 64bit..). I'll continue to work on my system, work on device > drivers in which I have personal interest (just as always:-)), but > I'll not work with 'off-the-shelve' NetBSD-current any longer. I'll > from time to time incorporate what I like though. Since this is going to be > real work, updating my system will certainly take time. For now, I'm happy > with a perfectly running system, and don't feel very motivated to change that > status... > > So, I'm glad that you Chris continue to keep in touch with the main > NetBSD line. I myself was always pretty lazy incorporating other > sources:-)) For those that want a `real' NetBSD on their amiga, that's > the optimal sollution! > True. It would be nice to have you along for the ride tho. But, I suppose you'll keep the rest of us on our toes with new features found only in MWBSD. B^). I assume you'll still be lurking on the list to interject new ideas and opinions yes? I would like to take this opportunity to give a virtual brew and pat on the back for all the work you've done for first the AmigaUNIX community, libbsd and such, the AmigaDOS community, (gcc, ixemul.library and such) and the NetBSD community (initial Amiga port and SUNOS emulation) . You've given us all good platforms to start on our various journeys. Thanks! I'm sure we will be keeping a close watch out for your future capers. B^). Who knows, maybe when the 4.4 stuff is fully integrated, Amiga NetBSD will tweek your interest once again! -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 21:23:59 1994 Subject: Serial problems From: David Jones To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu It's getting to the point where NComm is the only application I run under AmigaOS - everything else is NetBSD. But... 1. The internal port drops characters. I know that this is because: - Paula does not support true hardware RTS/CTS flow control - It ain't buffered - Unix interrupt latency sucks big eggs The only real solution is a 3rd party serial port that supports proper flow control. Any suggestions as to which one? 2. I have encountered a bug where the serial port transmits garbage to the modem. Has anyone else encountered this bug? Once it starts, you can't regain control over the port. Kermit can't even close it! 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, even with window-size set to 10, only goes so far... -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 22:02:06 1994 From: Randy Terbush To: current-users@sun-lamp.cs.berkeley.edu Subject: ICBS/ICBS2 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did I see someone mention recently that they had ELF, or SCO Binaries running on NetBSD? Or was I dreaming?..... -- Randy Terbush INET: randy@ugn.unomaha.edu UUCP: sierra!randy From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 22:29:03 1994 Subject: Re: XFree86 binaries for current? To: lm@rmit.edu.au From: "Martin Husemann" Cc: tholo@sigmasoft.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: 236 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I've just compiled up (from scratch), X11R5 with Xfree86-2.1.1, on > the latest srcs. Has anybody done X11R6 ? I was able to compile, but get signal 10's (yes, I applied Mathieaus patch to keep /dev/mem open all the time). Martin From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 23:01:09 1994 From: Christos Zoulas "ICBS/ICBS2" (May 17, 5:57am) 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: randy@ugn.unomaha.edu Subject: Re: ICBS/ICBS2 Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On May 17, 5:57am, dsndata!sierra!randy@sterling.com (Randy Terbush) wrote: -- Subject: ICBS/ICBS2 | Did I see someone mention recently that they had ELF, or SCO Binaries | running on NetBSD? | | Or was I dreaming?..... I have not mentioned it before, but I am working on it. If anyone else has done some work on it, please let me know. christos From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 23:18:38 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: Serial problems To: dej@eecg.toronto.edu (David Jones) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > It's getting to the point where NComm is the only application I run under > AmigaOS - everything else is NetBSD. But... > > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! This I have encountered. The problem it turns out is that you have your kermit set up for xon/xoff flow control. Now when the tty gets a ^S from the remote (ie. in line noise) it stops sending until you get a ^Q from the remote. For some reason when the tty is in this state kermit cannot close() it and quit.. when it tries to close kermit hangs. Nobody else will be able to open the tty to use the modem until the machine gets rebooted. I dont know the proper fix to this (to make the tty closeable when it has received ^S) but in kermit you issue this command before you start: set flow-control none Of course if you can use hardware flow control that should work fine too.. just not xon/xoff. > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... I've always used rz/sz from the kermit command prompt (run rz /dev/tty00). Thanx for the defines, markus. > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto > The Toronto Free-Net... paving the information superhighway. > email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 23:22:56 1994 From: rhealey@aggregate.com Subject: Re: A3000 SCSI problems To: oster@skdad.usask.ca (Greg Oster) Cc: amiga-dev@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: 1211 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Why is has this changed? Does it make it easier to do something on > the NetBSD side? I don't see any gain here, only discomfort... > In particular, if you have a configuration like: > > BSDR - root1 > BSDS - swap > BSDH - root2 > BSDE - /usr > BSDF - /home > ... > > You now won't be able to swap root1 with root2 (i.e. rename the > partitions under AmigaDOS to BSDH, BSDS, BSDR, ...) to boot from an > alternate root without a) putting root2 at the end of your drive and > hacking /etc/fstab to flipflop amongst BSDE, BSDF, etc. and never > really know where the heck anything is, or b) making BSDE the name of > the second root partition. Neither of these are very desirable > options for me... > In my ever so humble/obnoxious opinion the PROPER way to switch root's should be to use the priority field in the RDB, THIS IS WHAT THE FIELD IS FOR! Both setups are braindead in this respect currently. Hopefully the newer scheme can be corrected to use the priority field and the proper file system whatever we end up calling it. It's a pretty bad situation that we are using partition names to do this sort of thing when RDB offers us the CORRECT way to do it with little/no cost. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 23:37:51 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: A3000 SCSI problems To: rhealey@aggregate.com Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > I would like to take this opportunity to give a virtual brew and > pat on the back for all the work you've done for first the AmigaUNIX > community, libbsd and such, the AmigaDOS community, (gcc, ixemul.library > and such) and the NetBSD community (initial Amiga port and SUNOS > emulation) . You've given us all good platforms to start on our various > journeys. Thanks! Yes, thanks Markus. > I'm sure we will be keeping a close watch out for your future capers. > B^). How about VSTa for amiga? ;-) > -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 17 23:42:36 1994 From: rhealey@aggregate.com Subject: Re: Serial problems To: mleung@ee.ualberta.ca (Max Leung) Cc: amiga-dev@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: 917 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Well, I have a C= A2232 multiport serial card (8 serial ports), but no > NetBSD driver for it. :-( > I will be converting the old 2232 driver to the new config method in a week or so after I get some experience with the new system. The original driver was whipped up by a gentleman down under who's name I forget; sorry. The problem is it needs the AmigaUNIX download code for the CPU on the 2232 card. If somebody can rewrite the 6502 2232 CPU code then we can release the whole smash unencumbered. The 2232 has none of the problems of lock up and works at 115K, 19K and below just fine. It doesn't do dialin/dialout locking right tho. B^(. If you have AmigaUNIX to snarf the 6502 code for the 2232 board I can package up the rest of the driver when I finish porting it to the new config method. Obviously the code won't be accepted by the BSD team till the 6502 code is rewritten. B^(. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 23:47:29 1994 From: mw@eunet.ch Subject: Re: Serial problems To: dej@eecg.toronto.edu (David Jones) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2971 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > 1. The internal port drops characters. I know that this is because: > - Paula does not support true hardware RTS/CTS flow control > - It ain't buffered > - Unix interrupt latency sucks big eggs What Amiga, which speed? I run ppp over a 38k4 connection to my modem, and I hardly ever get silo-overflow errors in my syslogs. If you're using a GVP controller, things might look different though.. I've set up the serial driver once to do 57k6, but had to drop it pretty quickly afterwards, because then ppp was busy correcting transmission errors, and thruput was clearly worse than before... > The only real solution is a 3rd party serial port that supports proper > flow control. Any suggestions as to which one? Good idea.. I have an MultiFaceIII board in my amiga, and never got up to really go looking for docs for the used chip and where it's located in the boards config area... > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! Hm, no, don't think I've seen this, never happend at least not in my ppp-only usage of the port. > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... You know that you can start rz/sz from withing kermit...? Here's an article I kept for reference on how to do this: ----------------------------------------------------------------------------- Here's a few lines for your .kermrc file. This allows you to type 'rz' at the Kermit command line and have everything work happily. You'll need the just-released version of C-kermit or one of the many alphas/betas that led up to it. You need to 1) be using a version of rz/sz before 3.0, or 2) modify a later version to not force the file transfer to '/dev/tty'. Older versions of rz fail on my '386 SVR4 system by default, but if you define HOWMANY to be less than 128, things will work fine. I haven't got a non-Unix box for calling out with at the moment; this combo of Kermit and rz/sz works adequately for now. The fancy Unix communications packages I've seen cannot keep up with high-speed modems. define rz !rz \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) define sz !sz \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) define rb !rb \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) define sb !sb \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) define rx !rx \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) define sx !sx \%1 \%2 \%3 \%4 \%4 \%5 \%6 \%7 \%8 \%9 < \v(line) > \v(line) --jh -- John Hood, Marlboro student and non-smoker-- Marlboro VT jhood@smoke.marlboro.vt.us -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 17 23:53:46 1994 From: "Segmentation Violation. Core dumped." 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: 3145 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: current-users@sun-lamp.cs.berkeley.edu Subject: ttyv0? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I was reminded by a post here regarding X11 that I had a question: What is ttyv0 for, and why, specifically, was ttyqf chosen for this purpose? - could we use ttysf instead? - could we not set it to its own device of (whatever, (minor dev) -1)? Make a hacker happy. Use a *real* OS. -- ________ _____ ____ ________ _____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 # On the 'Net: Why are more and more fourth-level wizard(-wannabe)s trying # to invoke ninth-level magic instead of taking the time to climb the other # (quite essential) thirteen or fourteen levels so they can do this properly? # Don't they know their console will crumble into dust if they do that? # greywolf@autodesk.com From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 17 23:57:06 1994 From: Max Leung Subject: Re: Serial problems To: David Jones 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, 17 May 1994, David Jones wrote: > It's getting to the point where NComm is the only application I run under > AmigaOS - everything else is NetBSD. But... Term 3.4 is the only thing I run under AmigaDOS too...we have the same problem! :) > 1. The internal port drops characters. I know that this is because: > - Paula does not support true hardware RTS/CTS flow control > - It ain't buffered > - Unix interrupt latency sucks big eggs > > The only real solution is a 3rd party serial port that supports proper > flow control. Any suggestions as to which one? Well, I have a C= A2232 multiport serial card (8 serial ports), but no NetBSD driver for it. :-( I keep losing characters too, especially if there is any hard drive activity (I have a 22MhZ GVP Combo with 13 megs of 32 bit RAM). It is VERY frustration. I can't use my machine as an X-server anymore like I did in the 744 kernel. I posted this problem before, but nobody responded, so I assume nobody can duplicate the problem, or nobody cares. Needless to say, I don't run NetBSD very much anymore. Just too lazy to figure out how to write an A2232 driver. :-) > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! Never had this problem. What's your hardware again? > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... Just get rz and sz. You can then type "sz >/dev/tty00 /dev/tty00 -- > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto > The Toronto Free-Net... paving the information superhighway. > email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key > Max Leung mleung@ee.ualberta.ca From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 00:20:53 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: A3000 SCSI problems To: Greg Oster Cc: 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 Tue, 17 May 1994, Greg Oster wrote: > In particular, if you have a configuration like: > > BSDR - root1 > BSDS - swap > BSDH - root2 > BSDE - /usr > BSDF - /home > ... > > You now won't be able to swap root1 with root2 (i.e. rename the > partitions under AmigaDOS to BSDH, BSDS, BSDR, ...) to boot from an > alternate root without a) putting root2 at the end of your drive and > hacking /etc/fstab to flipflop amongst BSDE, BSDF, etc. and never > really know where the heck anything is, or b) making BSDE the name of > the second root partition. Neither of these are very desirable > options for me... > And since I have precisely this configuration, I am not happy with the new partitioning scheme. Rob Healy stated his opinion that root partitions should be identified with boot priority. Although this idea has merit, I also like to be able to mount my backup root partition to copy my primary root partition onto it. How would I be able to do this with two BSDR (or BS/? or UNI/1 or whatever) partitions distinguished only by boot priority? ========================================================================= 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 May 18 00:25:45 1994 Subject: Re: Serial problems From: David Jones To: rhealey@aggregate.com Cc: mleung@ee.ualberta.ca, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > I can package up the rest of the driver when I finish porting > it to the new config method. Obviously the code won't be accepted > by the BSD team till the 6502 code is rewritten. B^(. Has anybody done a Commodore 64 emulator for BSD yet? That way, I could boot up my homebrew 64 assembler and get hacking... :-) Hmmm... how painful would the port be? An assembler written in assembler, to C. Could be useful :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 00:46:14 1994 From: rhealey@aggregate.com Subject: Re: root and partition labeling To: eeh@btr.btr.com Cc: amiga-dev@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: 1690 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > And since I have precisely this configuration, I am not happy with the > new partitioning scheme. Rob Healy stated his opinion that root > partitions should be identified with boot priority. Although this idea > has merit, I also like to be able to mount my backup root partition to > copy my primary root partition onto it. How would I be able to do this > with two BSDR (or BS/? or UNI/1 or whatever) partitions distinguished > only by boot priority? > The new scheme assigns partitions in order. After root was assigned the others would be assigned partitions in order. While this will differ from setup to setup a quick run of disklabel should reveal which is which. You could mount the other "root" filesystem using whatever device it corresponds too. Actually, to be purist there should be NO difference between one UFS file system or another. The priority should decided who gets grand pooba status, not some label you have to go futtsing with, I find that so damn annoying... With 3.x you can ditz with the boot prioritys from the boot menu so if done properly, you don't have to run hdtoolbox to change who is root and who is not. I find this annoying in the extreme that you have to run hdtoolbox to deal with this sort of thing. While some people might dislike having to run disklabel once to figure out what partition is what, it doesn't seem like too much to ask or any more confusing than messing with extended options in hdtoolbox... Once NetBSD has standalone boot it will be immensly annoying to have to boot in to ados to futts with stuff when the boot menu or an rdb program under NetBSD should be able to accomplish the task. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 18 01:45:03 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Serial problems To: David Jones 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, 17 May 1994, David Jones wrote: > It's getting to the point where NComm is the only application I run under > AmigaOS - everything else is NetBSD. But... > > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! What I have seen happening is that something (getty?) sends a character out the serial port to the modem which the modem then echos back, which is echoed by BSD, etc., ad nauseum. Power cycling the modem usually fixes that up for me. > > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... I have been using tip with sz/rz very successfully since I first got NetBSD running on my machine. The only problem I have is I have yet to figure out how to get tip to successfuly dial out. I do it by hand. Eduardo Horvath From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 02:05:45 1994 Subject: Re: Serial problems From: David Jones To: rhealey@aggregate.com Cc: mleung@ee.ualberta.ca, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > I can package up the rest of the driver when I finish porting > it to the new config method. Obviously the code won't be accepted > by the BSD team till the 6502 code is rewritten. B^(. Has anybody done a Commodore 64 emulator for BSD yet? That way, I could boot up my homebrew 64 assembler and get hacking... :-) Hmmm... how painful would the port be? An assembler written in assembler, to C. Could be useful :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 02:06:42 1994 From: rhealey@aggregate.com Subject: Re: root and partition labeling To: eeh@btr.btr.com Cc: amiga-dev@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: 1690 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > And since I have precisely this configuration, I am not happy with the > new partitioning scheme. Rob Healy stated his opinion that root > partitions should be identified with boot priority. Although this idea > has merit, I also like to be able to mount my backup root partition to > copy my primary root partition onto it. How would I be able to do this > with two BSDR (or BS/? or UNI/1 or whatever) partitions distinguished > only by boot priority? > The new scheme assigns partitions in order. After root was assigned the others would be assigned partitions in order. While this will differ from setup to setup a quick run of disklabel should reveal which is which. You could mount the other "root" filesystem using whatever device it corresponds too. Actually, to be purist there should be NO difference between one UFS file system or another. The priority should decided who gets grand pooba status, not some label you have to go futtsing with, I find that so damn annoying... With 3.x you can ditz with the boot prioritys from the boot menu so if done properly, you don't have to run hdtoolbox to change who is root and who is not. I find this annoying in the extreme that you have to run hdtoolbox to deal with this sort of thing. While some people might dislike having to run disklabel once to figure out what partition is what, it doesn't seem like too much to ask or any more confusing than messing with extended options in hdtoolbox... Once NetBSD has standalone boot it will be immensly annoying to have to boot in to ados to futts with stuff when the boot menu or an rdb program under NetBSD should be able to accomplish the task. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 18 02:39:33 1994 From: Donn Cave X-Sender: donn@homer06.u.washington.edu Subject: Re: Serial problems To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 467 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | I have been using tip with sz/rz very successfully since I first got | NetBSD running on my machine. The only problem I have is I have yet to | figure out how to get tip to successfuly dial out. I do it by hand. You can get cu to dial out, log in and answer your mail. I've been using it, would be happy to supply config files, at least for dialing out and certain parts of logging in. I've been using it with term 1.08. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 02:43:53 1994 From: "Stephen J. Roznowski" To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940515 II Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: Hubert Feyrer > > P.S.: Who _has_ a kernel running with the sources from last weekend > (13.-15. may), and on which machine (CPU/MMU)? I've been able to run with a 14 May A3000 kernel (with some kernel mods to get it to build). If I could get a stable one built (i.e. I'm running it), I'd upload new ones, but I'm back running a 940502 version. :-( -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 02:50:18 1994 From: "Stephen J. Roznowski" To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940515 II Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: Hubert Feyrer > > P.S.: Who _has_ a kernel running with the sources from last weekend > (13.-15. may), and on which machine (CPU/MMU)? I've been able to run with a 14 May A3000 kernel (with some kernel mods to get it to build). If I could get a stable one built (i.e. I'm running it), I'd upload new ones, but I'm back running a 940502 version. :-( -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 03:10:56 1994 Subject: Re: Serial problems From: David Jones To: rhealey@aggregate.com Cc: mleung@ee.ualberta.ca, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > I can package up the rest of the driver when I finish porting > it to the new config method. Obviously the code won't be accepted > by the BSD team till the 6502 code is rewritten. B^(. Has anybody done a Commodore 64 emulator for BSD yet? That way, I could boot up my homebrew 64 assembler and get hacking... :-) Hmmm... how painful would the port be? An assembler written in assembler, to C. Could be useful :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 18 03:17:06 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Serial problems To: David Jones 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, 17 May 1994, David Jones wrote: > It's getting to the point where NComm is the only application I run under > AmigaOS - everything else is NetBSD. But... > > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! What I have seen happening is that something (getty?) sends a character out the serial port to the modem which the modem then echos back, which is echoed by BSD, etc., ad nauseum. Power cycling the modem usually fixes that up for me. > > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... I have been using tip with sz/rz very successfully since I first got NetBSD running on my machine. The only problem I have is I have yet to figure out how to get tip to successfuly dial out. I do it by hand. Eduardo Horvath From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 03:17:49 1994 From: rhealey@aggregate.com Subject: Re: root and partition labeling To: eeh@btr.btr.com Cc: amiga-dev@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: 1690 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > And since I have precisely this configuration, I am not happy with the > new partitioning scheme. Rob Healy stated his opinion that root > partitions should be identified with boot priority. Although this idea > has merit, I also like to be able to mount my backup root partition to > copy my primary root partition onto it. How would I be able to do this > with two BSDR (or BS/? or UNI/1 or whatever) partitions distinguished > only by boot priority? > The new scheme assigns partitions in order. After root was assigned the others would be assigned partitions in order. While this will differ from setup to setup a quick run of disklabel should reveal which is which. You could mount the other "root" filesystem using whatever device it corresponds too. Actually, to be purist there should be NO difference between one UFS file system or another. The priority should decided who gets grand pooba status, not some label you have to go futtsing with, I find that so damn annoying... With 3.x you can ditz with the boot prioritys from the boot menu so if done properly, you don't have to run hdtoolbox to change who is root and who is not. I find this annoying in the extreme that you have to run hdtoolbox to deal with this sort of thing. While some people might dislike having to run disklabel once to figure out what partition is what, it doesn't seem like too much to ask or any more confusing than messing with extended options in hdtoolbox... Once NetBSD has standalone boot it will be immensly annoying to have to boot in to ados to futts with stuff when the boot menu or an rdb program under NetBSD should be able to accomplish the task. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 03:52:03 1994 From: "Stephen J. Roznowski" To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940515 II Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: Hubert Feyrer > > P.S.: Who _has_ a kernel running with the sources from last weekend > (13.-15. may), and on which machine (CPU/MMU)? I've been able to run with a 14 May A3000 kernel (with some kernel mods to get it to build). If I could get a stable one built (i.e. I'm running it), I'd upload new ones, but I'm back running a 940502 version. :-( -SR From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 03:55:49 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: ICBS/ICBS2 Sender: owner-current-users@sun-lamp.cs.berkeley.edu This little program will run an elf/svr4 statically linked binary of "hello world"; I am currently working on the system call remapping... I put this hack quickly together, just to make sure it would work... christos /* * Parse an Elf binary, load it into memory and execute it. */ #include #include #include #include #include typedef unsigned long Elf32_Addr; typedef unsigned long Elf32_Off; typedef long Elf32_Sword; typedef long Elf32_Word; typedef unsigned short Elf32_Half; #define ELF_IDSIZE 16 enum Elf32_e_type { Elf32_et_none = 0, Elf32_et_rel, Elf32_et_exec, Elf32_et_dyn, Elf32_et_core, Elf32_et_num }; enum Elf32_e_machine { Elf32_em_none = 0, Elf32_em_m32, Elf32_em_sparc, Elf32_em_386, Elf32_em_86k, Elf32_em_88k, Elf32_em_486, Elf32_em_860, Elf32_em_num }; typedef struct { unsigned char e_ident[ELF_IDSIZE]; /* Id bytes */ Elf32_Half e_type; /* file type */ Elf32_Half e_machine; /* machine type */ Elf32_Word e_version; /* version number */ Elf32_Addr e_entry; /* entry point */ Elf32_Off e_phoff; /* Program hdr offset */ Elf32_Off e_shoff; /* Section hdr offset */ Elf32_Word e_flags; /* Processor flags */ Elf32_Half e_ehsize; /* sizeof ehdr */ Elf32_Half e_phentsize; /* Program header entry size */ Elf32_Half e_phnum; /* Number of program headers */ Elf32_Half e_shentsize; /* Section header entry size */ Elf32_Half e_shnum; /* Number of section headers */ Elf32_Half e_shstrndx; /* Section header string table index */ } Elf32_Ehdr; enum Elf32_p_pf { Elf32_pf_r = 4, Elf32_pf_w = 2, Elf32_pf_x = 1 }; typedef struct { Elf32_Word p_type; /* entry type */ Elf32_Off p_offset; /* offset */ Elf32_Addr p_vaddr; /* virtual address */ Elf32_Addr p_paddr; /* physical address */ Elf32_Word p_filesz; /* file size */ Elf32_Word p_memsz; /* memory size */ Elf32_Word p_flags; /* flags */ Elf32_Word p_align; /* memory & file alignment */ } Elf32_Phdr; #define Elf32_e_ident "\177ELF" #define Elf32_e_siz (sizeof(Elf32_e_ident) - 1) void print_Ehdr(e) Elf32_Ehdr *e; { printf("e_ident %s\n", e->e_ident); printf("e_type %d\n", e->e_type); printf("e_machine %d\n", e->e_machine); printf("e_version %ld\n", e->e_version); printf("e_entry %lx\n", e->e_entry); printf("e_phoff %lx\n", e->e_phoff); printf("e_shoff %lx\n", e->e_shoff); printf("e_flags %lx\n", e->e_flags); printf("e_ehsize %d\n", e->e_ehsize); printf("e_phentsize %d\n", e->e_phentsize); printf("e_phnum %d\n", e->e_phnum); printf("e_shentsize %d\n", e->e_shentsize); printf("e_shnum %d\n", e->e_shnum); printf("e_shstrndx %d\n", e->e_shstrndx); } void print_Phdr(p) Elf32_Phdr *p; { printf("p_type %ld\n", p->p_type); printf("p_offset %lx\n", p->p_offset); printf("p_vaddr %lx\n", p->p_vaddr); printf("p_paddr %lx\n", p->p_paddr); printf("p_filesz %ld\n", p->p_filesz); printf("p_memsz %ld\n", p->p_memsz); printf("p_flags %lx\n", p->p_flags); printf("p_align %ld\n", p->p_align); } void load_psection(fd, p) int fd; Elf32_Phdr *p; { #define AL(a,b) ((a) & ~((b) - 1)) unsigned long vaddr = AL(p->p_vaddr, p->p_align); unsigned long offset = p->p_offset - (p->p_vaddr - vaddr); int prot = 0; caddr_t m; #ifdef DEBUG printf("vaddr = %x p_vaddr %x\n", vaddr, p->p_vaddr); printf("offset = %x p_offset %x\n", offset, p->p_offset); #endif prot |= (p->p_flags & Elf32_pf_r) ? PROT_READ : 0; prot |= (p->p_flags & Elf32_pf_w) ? PROT_WRITE : 0; prot |= (p->p_flags & Elf32_pf_x) ? PROT_EXEC : 0; m = mmap((caddr_t) vaddr, p->p_memsz, prot, MAP_FIXED, fd, offset); if (m == (caddr_t) -1) perror("mmap"); #ifdef DEBUG else printf("Mapped at %lx prot=%x\n", m, prot); #endif } int main(argc, argv) int argc; char **argv; { Elf32_Ehdr e; Elf32_Phdr p; int i; int fd; fd = open(argv[1], O_RDONLY); if (fd == -1) { perror("open"); return 1; } if (read(fd, &e, sizeof(e)) != sizeof(e)) { perror("read"); return 1; } #ifdef DEBUG print_Ehdr(&e); #endif if (memcmp(e.e_ident, Elf32_e_ident, Elf32_e_siz) != 0) { fprintf(stderr, "Not an elf file\n"); return 1; } if (e.e_type != Elf32_et_exec) { fprintf(stderr, "Not an elf executable\n"); return 1; } if (e.e_machine != Elf32_em_386 && e.e_machine != Elf32_em_486) { fprintf(stderr, "Not an elf/386 or 486 executable\n"); return 1; } if (lseek(fd, e.e_phoff, L_SET) == (off_t) -1) { perror("lseek"); return 1; } for (i = 0; i < e.e_phnum; i++) { if (read(fd, &p, sizeof(p)) != sizeof(p)) { perror("read"); return 1; } #ifdef DEBUG print_Phdr(&p); #endif load_psection(fd, &p); } return ((int (*)()) e.e_entry)(); } From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 18 04:06:43 1994 From: Donn Cave X-Sender: donn@homer06.u.washington.edu Subject: Re: Serial problems To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 467 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | I have been using tip with sz/rz very successfully since I first got | NetBSD running on my machine. The only problem I have is I have yet to | figure out how to get tip to successfuly dial out. I do it by hand. You can get cu to dial out, log in and answer your mail. I've been using it, would be happy to supply config files, at least for dialing out and certain parts of logging in. I've been using it with term 1.08. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 04:10:25 1994 Subject: Re: Serial problems From: David Jones To: rhealey@aggregate.com Cc: mleung@ee.ualberta.ca, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > I can package up the rest of the driver when I finish porting > it to the new config method. Obviously the code won't be accepted > by the BSD team till the 6502 code is rewritten. B^(. Has anybody done a Commodore 64 emulator for BSD yet? That way, I could boot up my homebrew 64 assembler and get hacking... :-) Hmmm... how painful would the port be? An assembler written in assembler, to C. Could be useful :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 04:54:36 1994 From: rhealey@aggregate.com Subject: Re: root and partition labeling To: eeh@btr.btr.com Cc: amiga-dev@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: 1690 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > And since I have precisely this configuration, I am not happy with the > new partitioning scheme. Rob Healy stated his opinion that root > partitions should be identified with boot priority. Although this idea > has merit, I also like to be able to mount my backup root partition to > copy my primary root partition onto it. How would I be able to do this > with two BSDR (or BS/? or UNI/1 or whatever) partitions distinguished > only by boot priority? > The new scheme assigns partitions in order. After root was assigned the others would be assigned partitions in order. While this will differ from setup to setup a quick run of disklabel should reveal which is which. You could mount the other "root" filesystem using whatever device it corresponds too. Actually, to be purist there should be NO difference between one UFS file system or another. The priority should decided who gets grand pooba status, not some label you have to go futtsing with, I find that so damn annoying... With 3.x you can ditz with the boot prioritys from the boot menu so if done properly, you don't have to run hdtoolbox to change who is root and who is not. I find this annoying in the extreme that you have to run hdtoolbox to deal with this sort of thing. While some people might dislike having to run disklabel once to figure out what partition is what, it doesn't seem like too much to ask or any more confusing than messing with extended options in hdtoolbox... Once NetBSD has standalone boot it will be immensly annoying to have to boot in to ados to futts with stuff when the boot menu or an rdb program under NetBSD should be able to accomplish the task. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 18 05:39:33 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Serial problems To: David Jones 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, 17 May 1994, David Jones wrote: > It's getting to the point where NComm is the only application I run under > AmigaOS - everything else is NetBSD. But... > > 2. I have encountered a bug where the serial port transmits garbage to > the modem. Has anyone else encountered this bug? Once it starts, you > can't regain control over the port. Kermit can't even close it! What I have seen happening is that something (getty?) sends a character out the serial port to the modem which the modem then echos back, which is echoed by BSD, etc., ad nauseum. Power cycling the modem usually fixes that up for me. > > 3. Is there a good terminal program that supports Zmodem for NetBSD? Kermit, > even with window-size set to 10, only goes so far... I have been using tip with sz/rz very successfully since I first got NetBSD running on my machine. The only problem I have is I have yet to figure out how to get tip to successfuly dial out. I do it by hand. Eduardo Horvath From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 18 05:59:38 1994 From: Zik Saleeba Subject: Re: Serial problems To: rhealey@aggregate.com Cc: mleung@ee.ualberta.ca, 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: 1765 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Rob Healey, a man whose name _I_ never forgot said: >... > new system. The original driver was whipped up by a gentleman > down under who's name I forget; sorry. The problem is it > needs the AmigaUNIX download code for the CPU on the 2232 card. > > If somebody can rewrite the 6502 2232 CPU code then we can > release the whole smash unencumbered. Actually I've been thinking of messing with this driver again since the existing 6502 code doesn't handle flow control on input. Would you believe that NetBSD's tty device rint() routine is so slow that a 19baud upload can get ahead of it (at least when the system's heavily loaded with ten or so users). > The 2232 has none of the problems of lock up and works at 115K, > 19K and below just fine. It doesn't do dialin/dialout locking > right tho. B^(. Maybe I'l take a look at this too. The other thing it never handled right was software flow control. I never needed this for my modem bank so it never got done :-) > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > I can package up the rest of the driver when I finish porting > it to the new config method. Obviously the code won't be accepted Does anyone have any pointers on the new config method? I guess I'll work with the old method for now though, since the only kernel I've got that compiles and runs nicely is an ancient December version. +--------------------------------+----------------------------------------+ | zik@zikzak.apana.org.au | "You begin to understand politics when | | zik@bruce.cs.monash.edu.au | you realise that it is the only way | | Zik Saleeba | that boring people can become famous" | +--------------------------------+----------------------------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 06:39:27 1994 From: Yeng-Chee Su Subject: compile problem To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 700 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have some problem when I compile today's supped source. Here is the problem. 1. incomplete declaration of struct vop_bwrite_args in vfs_bio.c 2. undefined symbol syncprt and bufstats in nfs_vfsops.c and ufs_vfsops.c -- ________________________________________________________________________ / National Chiao Tung University in Taiwan / \ | Name: Yeng-Chee Su Dept: Computer Engineering |__/ | Phone: +886-35-783513 E-mail: yenchee@csie.nctu.edu.tw | | Address: 22, Alley 2, Lane 173, Gao Tsui Road, HsinChu, Taiwan 300 |___ \______________________________________________________________________\__/ From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 07:10:15 1994 From: cagney@highland.oz.au To: cgd@postgres.berkeley.edu Subject: Re: cksum listing also? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I write: > > Could there be generated (as part of the weekly processing) a set > > of files each containing a cksum listing of a major part of the NetBSD - > > current source tree. Any you respond: > I see several problems with this: > (1) if you generate the cksums weekly, then, on all the other > days of the week, some files will look bogus. i don't > like this -- it defeats the purpose of doing the cksum > to begin with. Very true. I chose weekly so that: o They would match the source.tar files which I think are created each week. o Would keep the load down (daily as you noted would kill the machine) To re-construct todays source tree both the most recent cksum listings and the following few days `daily CVS update output' would be needed. What about making the cksum outputs available weekly and attach to them a README file containing something like: ``These weekly cksum(1) listings are provided as is. Trying to maintain a NetBSD-current source tree using this information is not supported. It is assumed that people tracking the NetBSD-current source tree are able to make IP level connections to the NetBSD-current archive and can run sup(1). It is also assumed that people wishing to obtain individual files from the NetBSD-current source tree have some form of ftp access to the archive site. If you do not have access to sup(1) then these cksum listings may be helpfull (but remember `they are not supported') To check your NetBSD source tree against NetBSD-current you will need both these cksum files _and_ any `daily CVS update output' posted since the files were last generated. Even then, because of network delays, you may find that you are playing a `catch up game' with the NetBSD-current sources.'' Re-phrase it (make it stronger) if you want, I think, however, it gets most of the points across. regards Andrew PS: Cksum's on the `daily CVS update output' would be nice but I should think that is pushing things too far :-) From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 07:43:12 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host xanth.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: drive geom... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu Any of you folks got drive geom's for a CDC Wren IV (~300 megs)? I'm installing it on a Sparc 1+ so I have a drive to put NetBSD on... Thanks... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 10:39:45 1994 From: eric@ee.pdx.edu To: Jason Thorpe Cc: current-users@sun-lamp.cs.berkeley.edu, eric@ee.pdx.edu Subject: Re: drive geom... <199405180349.UAA29627@xanth.CS.ORST.EDU> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Any of you folks got drive geom's for a CDC Wren IV (~300 megs)? > > I'm installing it on a Sparc 1+ so I have a drive to put NetBSD on... Try one of these : disk_type = "CDC Wren IV 94171-344" \ : ctlr = MD21 : fmt_time = 4 \ : cache = 0x11 : trks_zone = 9 : asect = 3 \ : ncyl = 1545 : acyl = 2 : pcyl = 1549 : nhead = 9 : nsect = 46 \ : rpm = 3600 : bpt = 20833 I got it out of the periodical postings of format.dat on one of the comp.sun.admin groups. later, -eric -- Eric Berggren | "Parts of this product may be derived from Portland State University | from UNIX and Berkeley 4.3 BSD systems..." eric@ee.pdx.edu | -- Label on Solaris 2.x disk From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 10:55:29 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host xanth.CS.ORST.EDU didn't use HELO protocol To: eric@ee.pdx.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: drive geom... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 17 May 94 23:24:18 PDT eric@ee.pdx.edu wrote: > > Any of you folks got drive geom's for a CDC Wren IV (~300 megs)? > > > > I'm installing it on a Sparc 1+ so I have a drive to put NetBSD on... > > Try one of these : > > disk_type = "CDC Wren IV 94171-344" \ > : ctlr = MD21 : fmt_time = 4 \ > : cache = 0x11 : trks_zone = 9 : asect = 3 \ > : ncyl = 1545 : acyl = 2 : pcyl = 1549 : nhead = 9 : nsect = 46 \ > : rpm = 3600 : bpt = 20833 Thanx dude! > > > I got it out of the periodical postings of format.dat on one of the > comp.sun.admin groups. > > later, > -eric > > -- > Eric Berggren | "Parts of this product may be derived from > Portland State University | from UNIX and Berkeley 4.3 BSD systems..." > eric@ee.pdx.edu | -- Label on Solaris 2.x disk ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 11:08:10 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 binaries for current? X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 516 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Tue 17) > > I've just compiled up (from scratch), X11R5 with Xfree86-2.1.1, on > > the latest srcs. > > Has anybody done X11R6 ? > > I was able to compile, but get signal 10's (yes, I applied Mathieaus > patch to keep /dev/mem open all the time). > I'd suggest you wait for XFree 3.1 that will be available with the contrib tape. NetBSD-current is not supported by the X Consortium, that mean that they don't integrate patches specific to NetBSD-current. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 18 11:10:16 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: statically linked XFree86-2.1.1 binaries X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 297 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I've made a set of statically linked binaries of XFree86 2.1.1. I hope that they will resist better to libc version updates. For xdm, I only provide a version with the dummy libcrypt. Sorry about that. They are available from ftp.laas.fr:/pub/NetBSD/XFree86-2.1.1/static. Matthieu From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 19 09:00:36 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: startx problems (Surprise, surprise!) To: l150649@proffa.cc.tut.fi (Lammi Jani) 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: 617 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > I installed the 1st May binaries of X11R5, but startx won't > co-operate: > > ----- > > /dev/grf1: No such file or directory > xopen_view(): No such file or directory > > Fatal server error: > no screens found > XIO: fatal IO 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. I think the problem is that you don't have any view devices configured. Make a bunch: for i in 0 1 2 3 4 5; do mknod /dev/view0$i c 16 $i; chmod 666 /dev/view0$i done and try it out again. From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 19 09:02:03 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "startx problems (Surprise, surprise!)" (May 18, 9:43pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Lammi Jani , amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: startx problems (Surprise, surprise!) Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On May 18, 9:43pm, Lammi Jani wrote: > Subject: startx problems (Surprise, surprise!) > > I installed the 1st May binaries of X11R5, but startx won't > co-operate: > > ----- > > /dev/grf1: No such file or directory > xopen_view(): No such file or directory Looks like you forgot to make the new link from Xmono to X, but i remember that in the new archive there was a server which had both, Retina and ECS support, i couldn't try it out yet, due to my old ld.so. Sorry, no help. -- Markus Illenseer From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu May 19 09:02:10 1994 From: Lammi Jani Subject: startx problems (Surprise, surprise!) To: amiga-x@sun-lamp.cs.berkeley.edu 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: 742 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I installed the 1st May binaries of X11R5, but startx won't co-operate: ----- /dev/grf1: No such file or directory xopen_view(): No such file or directory Fatal server error: no screens found XIO: fatal IO 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. ----- It seems that it tries to open a Retina display? So how do I tell it to open native Amiga display? (I am using the latest kernel from iastate.) -- ------------------------------------------------ Jani Lammi -+*+- l150649@cc.tut.fi ------------------------------------------------ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 09:03:33 1994 From: Olaf Seibert To: dej@eecg.toronto.edu, rhealey@aggregate.com Subject: Re: Serial problems Cc: amiga-dev@sun-lamp.cs.berkeley.edu, mleung@ee.ualberta.ca Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu David Jones wrote: > > If you have AmigaUNIX to snarf the 6502 code for the 2232 board > > I can package up the rest of the driver when I finish porting > > it to the new config method. Obviously the code won't be accepted > > by the BSD team till the 6502 code is rewritten. B^(. > > Has anybody done a Commodore 64 emulator for BSD yet? > > That way, I could boot up my homebrew 64 assembler and get hacking... :-) > > Hmmm... how painful would the port be? An assembler written in assembler, > to C. Could be useful :-) There is already Matt Dillon's assembler for 6502, 68HC11, and a few other similar processors. It is written in C and as far as I can recall, it should be very portable. It's fancy too - I assembled C64 Kermit with it (after converting its source format). It can create several output formats (I think at least C= Basic load format, hexdump, S-records, and plain binary dump). I'm not sure if it's on a Fish disk, but I think I can dig it up if needed. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 09:03:36 1994 From: Olaf Seibert To: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: sys.19940515 II Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hubert Feyrer wrote: > P.S.: Who _has_ a kernel running with the sources from last weekend > (13.-15. may), and on which machine (CPU/MMU)? I deleted the previous thread, but wasn't it about only getting a black screen on reboot? Well, I finally built a kernel again (15 may sources probably) and indeed, it does not work when copied over /dev/reboot: a black screen. But loadbsd-ing it works ok. (Well, apart from the fact that the supra scsi is gone for now so that it doesn't have disks anymore, but that's a minor detail). Oh yes, mine is an A4000/040. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:07:43 1994 From: Charles Hannum To: andrew@wipux2.wifo.uni-mannheim.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: 4 letter make, pk_subr.c missing _npaidb_enter etc. Sender: owner-current-users@sun-lamp.cs.berkeley.edu My make is only outputting 4 letters then a space and then the next 4 letters, I can't speak about this problem, because I have no idea what would cause it, and honestly, I simply *can't* believe it unless I see it happening myself. However, there was a bug in tee(1) such that it would only copy 4 characters at a time. tee(1)ing the output of make(1) also just happened to catch the scheduler in its worst mood, and the output would end up coming out in 4-byte chunks, approximately once per two disk I/Os. Anyway, I've updated tee(1) from 4.4-Lite (plus our previous changes), and the latter problem should be fixed (with the exception that the scheduling algorithm needs work). From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:08 1994 From: "Segmentation Violation. Core dumped." 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: 3145 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: "Mark P. Gooderum" , deraadt@fsa.ca Subject: Re: Sparc ports Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On a similar note, has anyone out there got a protocol spec for NIS+? I keep bugging sun for one, but they don't respond. I want to build client-side code for non-solaris machines (of course the upcoming birth of a hackerlet might put a damper on any free time I might otherwise have.) #define AUTHOR "mark@aggregate.com (Mark P. Gooderum)" /* * > > Has anyone done any work on a YP server implementation for NetBSD... * > * > No, and I don't feel like doing it. Go for it, knock yourself dead. * > It's not that hard. * * Actually I had been thinking of just such a thing. I worked up a * prototype a while back to address some security issues. The idea was * to have RPC compatibility with ypserv but not worry about the same * implementation server side. Also some optional extensions to help address the * security issues (shadow passwords, "coldstart" files like NIS+ uses, * etc) and allow remote administration. * * The extensions would require integration with the yp client libs and ypbind, * but would be optional. * * I guess the only question would be is the YP stuff and related code * (getXXXyyXXX() funcs) fairly stable so I can take off and not have a major * integration headache in a month or so? (ie: is there much coming in from * 4.4 still that will impact this?). This is really only an issue with the * extras since "true" compatibility for the server doesn't impact the * client side. * * -Mark * * * * */ /*** end two cents worth from Mark P. Gooderum ****/ Make a hacker happy. Use a *real* OS. -- ________ _____ ____ ________ _____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 Woof... From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 09:09:13 1994 From: Lammi Jani Subject: Flickering console 8( To: amiga@sun-lamp.cs.berkeley.edu 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: 386 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Has anyone pathced NetBSD to use 31kHz AGA-screenmodes? It is really irritating to watch a 640x400 interlaced display on an A4000/040 w/ multisync monitor! Even 640x200 would look better. -- ------------------------------------------------ Jani Lammi -+*+- l150649@cc.tut.fi ------------------------------------------------ From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 09:09:20 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Serial problems" (May 17, 4:26pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Donn Cave , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Serial problems Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 17, 4:26pm, Donn Cave wrote: > You can get cu to dial out, log in and answer your mail. I've been using > it, would be happy to supply config files, at least for dialing out and > certain parts of logging in. I've been using it with term 1.08. Go ahead please :-) Don't forget to mention anything required, ie. /dev/group:dialer or special permissions. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:30 1994 Subject: Re: XFree86 V2.1 - Complete NetBSD Source code? To: rls@zeus.id.net (Robert L. Shady) Cc: 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: 527 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Where can I find the COMPLETE XFree86 2.1 source code tree for > NetBSD-current? To compile everything, you need: 1. x11r5 mit sources 2. xfree86-2.1 sources 3. xfree86-2.1 diff (applied against x11r5 sources.) 4. (optionally) xfree86-2.1-2.1.1 diffs ftp.cs.rmit.edu.au has (1) in pub/X11R5 (as 3 tar files instead of lots of 500K chunks), and (2-4) in pub/netbsd/XFree86-2.1.1-src. I recommend that you get (1) from ftp.x.org though. & I'm glad X11R6 is shipped as <10 tar.gz files instead of heaps of 500k parts... & From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:32 1994 From: Drew Hess Subject: Kernel help To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 229 Sender: owner-current-users@sun-lamp.cs.berkeley.edu My May 18 config core dumps with my May 9 kernel, making it impossible to build a new one. Could someone build a -current i386 kernel for me if I give you the kernel config file? Thanks in advance, -dwh- dhess@cs.stanford.edu From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 09:09:33 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Serial problems" (May 17, 2:10pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Serial problems Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 17, 2:10pm, "Eduardo E. Horvath eeh@btr.com" wrote: > I have been using tip with sz/rz very successfully since I first got > NetBSD running on my machine. The only problem I have is I have yet to > figure out how to get tip to successfuly dial out. I do it by hand. Same here, looks like successfull serial i/o depends on the used host- adaptor for harddrives. I'd be very interested in a working script for tip to dial out to a specific number and do an auto-login... -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:37 1994 From: cagney@highland.oz.au To: jconklin@netcom.com Subject: Re: Problem with ftruncate() .(thanks) Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, > From jconklin@netcom.com Wed May 18 22:41:15 1994 > Subject: Re: Problem with ftruncate() ... > > NetBSD-current has recently extending off_t's from 32 to 64 bits. `Bingo'. That explains why that code stub is going wrong. thanks Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:43 1994 From: kim@dde.dk (Kim Andersen) Subject: Re: New problems with kern/vfs_bio.c To: cgd@sun-lamp.cs.berkeley.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu I wrote: I guess that's one of the problems relying on the daily SUP/CVS messages. Upon studying the SUP/CVS message I see that my ftp-get has failed for a number of the updated files. I recently changed my scripts for updating the tree, and of course forget to check for errors :-(. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:45 1994 From: "Chris G. Demetriou" To: cgd@sun-lamp.cs.berkeley.edu, kim@dde.dk Subject: Re: New problems with kern/vfs_bio.c Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu your sys/buf.h isn't up to date. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:09:48 1994 From: kim@dde.dk (Kim Andersen) Subject: Re: New problems with kern/vfs_bio.c To: cgd@postgres.Berkeley.EDU (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > your sys/buf.h isn't up to date. Thanks. I guess that's one of the problems relying on the daily SUP/CVS messages. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:15 1994 From: "Robert L. Shady" Subject: XFree86 V2.1 - Complete NetBSD Source code? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 90 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Where can I find the COMPLETE XFree86 2.1 source code tree for NetBSD-current? Thanks.. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:21 1994 From: kim@dde.dk (Kim Andersen) Subject: New problems with kern/vfs_bio.c To: cgd@sun-lamp.cs.berkeley.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm having problems compiling a kernel based on MAY18 sources. When compiling kern/vfs_bio.c I get: .../../../../kern/vfs_bio.c: In function `bwrite': .../../../../kern/vfs_bio.c:303: `B_WRITEINPROG' undeclared .../../../../kern/vfs_bio.c: In function `biowait': .../../../../kern/vfs_bio.c:740: `B_EINTR' undeclared Also there is plenty of warnings about missing casts and previously declared things. Solutions ? regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:32 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host xanth.CS.ORST.EDU didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: Drive config. From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu This is not a NetBSD question, per se, but some of you Sparc folks will certainly be of help...:-) I have NetBSD/sparc on a couple of old CDC Wren III's. Can someone send me a diagram or describe jumper config on this beast - I gotta put it on SCSI id 3. Thanx... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:37 1994 From: mark@aggregate.com (Mark P. Gooderum) To: deraadt@fsa.ca Subject: Re: Sparc ports Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1040 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Has anyone done any work on a YP server implementation for NetBSD... > > No, and I don't feel like doing it. Go for it, knock yourself dead. > It's not that hard. Actually I had been thinking of just such a thing. I worked up a prototype a while back to address some security issues. The idea was to have RPC compatibility with ypserv but not worry about the same implementation server side. Also some optional extensions to help address the security issues (shadow passwords, "coldstart" files like NIS+ uses, etc) and allow remote administration. The extensions would require integration with the yp client libs and ypbind, but would be optional. I guess the only question would be is the YP stuff and related code (getXXXyyXXX() funcs) fairly stable so I can take off and not have a major integration headache in a month or so? (ie: is there much coming in from 4.4 still that will impact this?). This is really only an issue with the extras since "true" compatibility for the server doesn't impact the client side. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:49 1994 From: mark@aggregate.com (Mark P. Gooderum) To: Sean.Bennett@uk.sun.com, kenh@wrl.EPI.COM Subject: Re: Sparc ports Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 77 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone done any work on a YP server implementation for NetBSD... -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:53 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 4 letter make, pk_subr.c missing _npaidb_enter etc. X-Sun-Charset: US-ASCII Content-Length: 192 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I ran into this. CCITT requires LLC and HDLC but the files file doesn't have these dependancies. Adding: option LLC option HDLC if you have option CCITT fixed the problem for me. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:11:58 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Libkern does not use the same includes as the kernel sources 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 Yesterday or the day before libkern/Makefile was modified to create symlinks to the machine and arch include directories. This scheme does not work for 68K ports since there is already an m68k directory in libkern. ========================================================================= 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 Thu May 19 09:12:05 1994 Disclaimer: "The National Aerospace Laboratory NLR DOES NOT ACCEPT ANY FINANCIAL COMMITMENT derived from this message." From: Gerard J van der Grinten Subject: Re: 4 letter make, pk_subr.c missing _npaidb_enter etc. To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1253 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello ... > My make is only outputting 4 letters then a space and then the next 4 > letters, it is also adding /src to the end of the compilation line. > I have installed the newest /usr/share/mk stuff. > > My kernel when compiling the last steps by hand (because of the /src addition) > is complaining that pk_subr.o is referencing _npaidb_enter from a text > segment. > > The new libraries are not functioning with my old kernel. > > any hints ? That entry point is in sys/netccitt/pk_llcsubr.c , witch is missing in the make file. To be able to compile pk_llcsubr.c you have to make an empty #define of a name (cc will complain , i forgot the name...) You have X25 defined in your config... That hits it. > -- > 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 > Regards, Gerard. -- Gerard J van der Grinten pa0gri@net.pa0gri.ampr.org [44.137.1.1] Elzenlaan 8 gvdg@nlr.nl (temporary qrl) 3467 TJ Driebruggen gvdg@fridley.pa0gri.ampr.org (home) Netherlands (+031)-34871606 Home. (+031)-52748435 Qrl. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:12:15 1994 To: Henning Schulzrinne Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: challenge/response password program <199405181218.FAA01879@sun-lamp.cs.berkeley.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 >Is there a NetBSD(-current) compatible login program that avoids >having to type passwords across a network (some form >of challenge-response program)? Have you looked at S/KEY? I haven't tried building it under NetBSD, but since you have source it should be pretty easy to do it. It's not exactly a challenge-response, but I think it will do what you want. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:12:21 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/gdb/gdb/kcorelow.c U src/gnu/usr.bin/gdb/gdb/arch/i386/i386b-nat.c U src/sys/arch/hp300/hp300/machdep.c U src/sys/arch/i386/i386/conf.c U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/pc532/conf/Makefile.pc532 U src/sys/arch/pc532/dev/dp.c U src/sys/arch/pc532/dev/ncr.c U src/sys/arch/pc532/dev/scn.c U src/sys/arch/pc532/include/cpu.h U src/sys/arch/pc532/include/icu.h U src/sys/arch/pc532/include/limits.h U src/sys/arch/pc532/include/param.h U src/sys/arch/pc532/include/proc.h U src/sys/arch/pc532/include/profile.h U src/sys/arch/pc532/include/psl.h U src/sys/arch/pc532/include/vmparam.h U src/sys/arch/pc532/pc532/clock.c U src/sys/arch/pc532/pc532/conf.c U src/sys/arch/pc532/pc532/genassym.c U src/sys/arch/pc532/pc532/icode.c U src/sys/arch/pc532/pc532/icuinit.c U src/sys/arch/pc532/pc532/locore.s U src/sys/arch/pc532/pc532/machdep.c U src/sys/arch/pc532/pc532/proc_machdep.c U src/sys/arch/pc532/pc532/trap.c U src/sys/arch/sparc/sbus/if_le.c U src/sys/kern/init_main.c U src/sys/kern/kern_ktrace.c U src/sys/kern/kern_resource.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_subr.c U src/sys/kern/kern_synch.c U src/sys/kern/makesyscalls.sh U src/sys/kern/sys_process.c U src/sys/kern/tty_tb.c U src/sys/kern/vfs_bio.c U src/sys/kern/vfs_conf.c U src/sys/kern/vfs_lookup.c U src/sys/kern/vfs_syscalls.c U src/sys/nfs/nfs_vfsops.c U src/sys/sys/buf.h U src/sys/sys/types.h U src/sys/sys/vnode.h U src/sys/ufs/ufs_alloc.c U src/sys/ufs/ufs_bmap.c U src/sys/ufs/ufs_inode.c U src/sys/ufs/ufs_vfsops.c U src/usr.bin/make/str.c U src/usr.sbin/inetd/inetd.c U src/usr.sbin/lpr/Makefile U src/usr.sbin/lpr/SMM.doc/0.t U src/usr.sbin/lpr/SMM.doc/1.t U src/usr.sbin/lpr/SMM.doc/2.t U src/usr.sbin/lpr/SMM.doc/3.t U src/usr.sbin/lpr/SMM.doc/4.t U src/usr.sbin/lpr/SMM.doc/5.t U src/usr.sbin/lpr/SMM.doc/6.t U src/usr.sbin/lpr/SMM.doc/7.t U src/usr.sbin/lpr/SMM.doc/Makefile U src/usr.sbin/lpr/SMM.doc/spell.ok U src/usr.sbin/lpr/common_source/common.c U src/usr.sbin/lpr/common_source/displayq.c U src/usr.sbin/lpr/common_source/lp.h U src/usr.sbin/lpr/common_source/lp.local.h U src/usr.sbin/lpr/common_source/pathnames.h U src/usr.sbin/lpr/common_source/printcap.c U src/usr.sbin/lpr/common_source/rmjob.c U src/usr.sbin/lpr/common_source/startdaemon.c U src/usr.sbin/lpr/filters/Makefile U src/usr.sbin/lpr/filters/lpf.c U src/usr.sbin/lpr/lpc/Makefile U src/usr.sbin/lpr/lpc/cmds.c U src/usr.sbin/lpr/lpc/cmdtab.c U src/usr.sbin/lpr/lpc/extern.h U src/usr.sbin/lpr/lpc/lpc.8 U src/usr.sbin/lpr/lpc/lpc.c U src/usr.sbin/lpr/lpc/lpc.h U src/usr.sbin/lpr/lpd/Makefile U src/usr.sbin/lpr/lpd/extern.h U src/usr.sbin/lpr/lpd/lpd.8 U src/usr.sbin/lpr/lpd/lpd.c U src/usr.sbin/lpr/lpd/lpdchar.c U src/usr.sbin/lpr/lpd/printjob.c U src/usr.sbin/lpr/lpd/recvjob.c U src/usr.sbin/lpr/lpq/Makefile U src/usr.sbin/lpr/lpq/lpq.1 U src/usr.sbin/lpr/lpq/lpq.c U src/usr.sbin/lpr/lpr/Makefile U src/usr.sbin/lpr/lpr/lpr.1 U src/usr.sbin/lpr/lpr/lpr.c U src/usr.sbin/lpr/lprm/Makefile U src/usr.sbin/lpr/lprm/lprm.1 U src/usr.sbin/lpr/lprm/lprm.c U src/usr.sbin/lpr/lptest/Makefile U src/usr.sbin/lpr/lptest/lptest.1 U src/usr.sbin/lpr/lptest/lptest.c U src/usr.sbin/lpr/pac/Makefile U src/usr.sbin/lpr/pac/pac.8 U src/usr.sbin/lpr/pac/pac.c Running the SUP scanner: SUP Scan for current starting at Wed May 18 06:14:17 1994 SUP Scan for current completed at Wed May 18 06:17:02 1994 SUP Scan for mirror starting at Wed May 18 06:17:02 1994 SUP Scan for mirror completed at Wed May 18 06:19:44 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:12:31 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, earle@isolar.Tujunga.CA.US Subject: Re: libc hiccups with May 14th tar balls? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Both of the problems you mentioned have been fixed. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:12:43 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: challenge/response password program From: Henning Schulzrinne Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a NetBSD(-current) compatible login program that avoids having to type passwords across a network (some form of challenge-response program)? Thanks. Henning --- Henning Schulzrinne email: hgs@fokus.gmd.de GMD-Fokus phone: +49 30 25499 219 Hardenbergplatz 2 fax: +49 30 25499 202 D-10623 Berlin From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:12:47 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: 4 letter make, pk_subr.c missing _npaidb_enter etc. To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 641 Sender: owner-current-users@sun-lamp.cs.berkeley.edu My make is only outputting 4 letters then a space and then the next 4 letters, it is also adding /src to the end of the compilation line. I have installed the newest /usr/share/mk stuff. My kernel when compiling the last steps by hand (because of the /src addition) is complaining that pk_subr.o is referencing _npaidb_enter from a text segment. The new libraries are not functioning with my old kernel. any hints ? -- 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 Thu May 19 09:12:58 1994 From: Manuel Bouyer Subject: Re: Problem with ftruncate() ... To: cagney@highland.oz.au 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: 1545 Sender: owner-current-users@sun-lamp.cs.berkeley.edu cagney@highland.oz.au wrote: > > Hi, > > The code below doesn't work on NetBSD-current ~2nd May on a x86 > yet works under SunOS 4.1.3. (The call to ftruncate() fails???). > > One thing I did notice but didn't seem to fix the problem (I didn't really > expect it to :-) is in: > > src/lib/libc/sys/ftruncate.c > > it is declared as: > > ftruncate(char *path, off_t length) > > instead of: > > ftruncate(int fd, off_t length) > > The output I get is: > > After open: Undefined error: 0 > Open returns 3 > After Write: Undefined error: 0 > Write returns 6 > After ftruncate: Invalid argument > ftruncate returns -1 > > > any hints? Is it an error and if so has it been fixed? > > Andrew > > > > #include > main() > { > int fd; > int status; > char *file = "/tmp/foo"; > char *data = "123456"; > int datalen = strlen(data); > > fd = open(file, O_RDWR | O_CREAT, 0600); > perror("After open"); > printf("Open returns %d\n", fd); > > status = write(fd, data, datalen); > perror("After Write"); > printf("Write returns %d\n", status); > > status = ftruncate(fd, 6); > perror("After ftruncate"); > printf("ftruncate returns %d\n", status); > > unlink(file); > > exit(0); > } > > /usr/include/fnctl.h doesn't seem to include /usr/include/unistd.h, where is the prototype for ftruncate. Perhaps you should add '#include ', or use a cast: 'status = ftruncate(fd, (off_t)6);' -- -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:03 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: libc hiccups with May 14th tar balls? From: - Greg Earle Sender: owner-current-users@sun-lamp.cs.berkeley.edu Had troubles compiling in libc with last Saturday's tar balls: (1) /usr/src/lib/libc/net/recv.c declared "len" param to recv() as "int", but prototype in says it's supposed to be a size_t. Just noticed that it appears that some files got updated last Friday, but it looks like the header files made it in but some of the code files (like the aforementioned recv.c) didn't make it into the tar balls. (Since it looks like the most current recv.c matches it OK, maybe it's time to learn how to get "sup" up and running? (-: ) (2) /usr/src/lib/libc/net/gethostnamadr.c includes , then later includes (et al.) if YP is defined. But itself includes , so a rash of multiple defines ensues. My kludge workaround puts the #ifdef YP stuff up where is, with #include as the #else clause. Works, but it looks bad. Perhaps there's a cleaner way than this? (Yes, I can't program my way out of a wet paper bag ... ) I *will* make it through a "make build" even if it kills me :-) - Greg From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:11 1994 From: mycroft@gnu.ai.mit.edu To: cagney@highland.oz.au, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problem with ftruncate() ... Sender: owner-current-users@sun-lamp.cs.berkeley.edu any hints? Is it an error and if so has it been fixed? The error is in your program. To wit: status = ftruncate(fd, 6); You *must* either have a prototype for ftruncate in scope, or explicitly cast the argument to `off_t'. The problem is that what you're passing to ftruncate() is an int, and it tries to read an off_t and gets 32 bits of garbage. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:20 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: Problem with csh freeing stack/heap... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I found this long ago in NetBSD-0.9 (while compiling AUIS 5.1) it seems the problem is still there (NetBSD-current ~2nd May). Unfortunatly, I've since deleted the bit of shell script that could tickle the problem. Oops :-( Any way, in `dir.c:dinit()' the variable `tcp' is either set to an automatic buffer `getwd(path)' or part of the environment space `getenv("PWD")' and then passed to dcanon() vis: cp = dcanon(str2short(tcp), STRNULL); dir.c:dcanon() then free's it's first argument (here tcp) ... The patch below fixed the problem in NetBSD 0.9. Andrew bash$ diff -c src/bin/csh/dir.c.dist src/bin/csh/dir.c *** src/bin/csh/dir.c.dist Sun Feb 6 01:44:54 1994 --- src/bin/csh/dir.c Sun Feb 6 01:45:34 1994 *************** *** 123,129 **** swd.st_ino == shp.st_ino) tcp = cwd; } ! cp = dcanon(str2short(tcp), STRNULL); } } --- 123,129 ---- swd.st_ino == shp.st_ino) tcp = cwd; } ! cp = dcanon(SAVE(tcp), STRNULL); } } bash$ From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:27 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: cagney@highland.oz.au Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problem with ftruncate() ... <9405180758.AA01374@highland.oz.au> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ftruncate(char *path, off_t length) The "char *" bit is wrong, but it doesn't have anything to do with the reason your program doesn't work. your program doesn't work because you need to include the prototype for ftruncate() for it to work properly. that prototype is defined in . cgd From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:44 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: Problem with ftruncate() ... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, The code below doesn't work on NetBSD-current ~2nd May on a x86 yet works under SunOS 4.1.3. (The call to ftruncate() fails???). One thing I did notice but didn't seem to fix the problem (I didn't really expect it to :-) is in: src/lib/libc/sys/ftruncate.c it is declared as: ftruncate(char *path, off_t length) instead of: ftruncate(int fd, off_t length) The output I get is: After open: Undefined error: 0 Open returns 3 After Write: Undefined error: 0 Write returns 6 After ftruncate: Invalid argument ftruncate returns -1 any hints? Is it an error and if so has it been fixed? Andrew #include main() { int fd; int status; char *file = "/tmp/foo"; char *data = "123456"; int datalen = strlen(data); fd = open(file, O_RDWR | O_CREAT, 0600); perror("After open"); printf("Open returns %d\n", fd); status = write(fd, data, datalen); perror("After Write"); printf("Write returns %d\n", status); status = ftruncate(fd, 6); perror("After ftruncate"); printf("ftruncate returns %d\n", status); unlink(file); exit(0); } From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 09:13:47 1994 From: Manuel Bouyer Subject: MAKEDEV and lpa To: current-users@sun-lamp.cs.berkeley.edu (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: 371 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Shouldn't MAKEDEV also create /dev/lpa?p ? (whith lpa1p: crw-r--r-- 1 root wheel 16, 193 May 18 09:02 /dev/lpa1p) I have to use this one, my printer hangs after the first printing if i use /dev/lpa1, and i have to reboot my 486 NetBSD box to have it working again. -- Manuel Bouyer, Ecole Nationale Superieure de Techniques Avancees, Paris email: bouyer@ensta.fr -- From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 11:47:59 1994 From: matthieu@laas.fr (Matthieu Herrb) To: "Robert L. Shady" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 V2.1 - Complete NetBSD Source code? X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 489 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Wed 18) > Where can I find the COMPLETE XFree86 2.1 source code tree for NetBSD-current? > > Thanks.. > If you don't wat to start from an X11R5 tree, a complete "official" XFree86 2.1 source code distribution is on ftp.physics.su.oz.au:/XFree86/2.1-source. However 2.1 doesn't work on latest -current. You need either 2.1.1 (the patch from 2.1 is also available on ftp.) or the patches I sent to this list to fix /dev/mem opening. Matthieu From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 12:16:40 1994 From: Donn Cave X-Sender: donn@homer08.u.washington.edu Subject: Re: Serial problems To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 3420 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | On May 17, 4:26pm, Donn Cave wrote: | > You can get cu to dial out, log in and answer your mail. I've been using | > it, would be happy to supply config files, at least for dialing out and | > certain parts of logging in. I've been using it with term 1.08. | | Go ahead please :-) | Don't forget to mention anything required, ie. /dev/group:dialer or | special permissions. Now that you mention it, /usr/gnu/bin/cu is setuid "uucp". It probably comes that way, I think this is the cu in the usr.gnu.bin distribution that was going around at the time of the 720 kernel. The two configuration files are "port" and "dial", both in /usr/gnu/conf/uucp. The comments mention "sys" file, but it must be optional - if I have one, I'm not able to find it. I say cu -p port1 <9600 dialin number>, which connects to a terminal server that issues some predictable responses. You can see that in the dial "chat" line, which has a fairly intuitive pattern-space- action syntax. It says "OK", then "CONNECT", and then gives a standard prompt like "cs1> " or "cs4> "; cu just looks for "\ncs", at which point it enters "xyz", supposed to be a hostname. Etc. Have fun. Your mileage may vary, as always. Donn Cave, donn@cac.washington.edu ======== # /usr/gnu/conf/uucp/port # All ports named in the sys file must be described in a port file. # It is also possible to describe the port directly in the sys file. # Commands that appears before the first ``port'' command are defaults # for all ports that appear later in the file. In this case all ports # will default to being modems (other possible types are direct, tcp # and tli). type modem # Now we describe two ports. # This is the name of the port. This name may be used in the sys file # to select the port, or the sys file may just specify a baud rate in # which case the first matching unlocked port will be used. port port1 # This is the device name to open to dial out. device /dev/tty00 # This is the dialer to use, as described in the dialer file. dialer hayes # This is the baud rate to dial out at. speed 9600 # Here is a second port. This is like the first, except that it uses # a different device. It also permits a range of speeds, which is # mainly useful if the system specifies a particular baud rate. port port2 device /dev/tty01 dialer hayes speed-range 2400 9600 ======== # /usr/gnu/conf/uucp/dial # All dialers named in the port (or sys) file must be described in the # dial file. It is also possible to describe a dialer directly in the # port (or sys) file. # This is a typical Hayes modem definition. dialer hayes # The chat script used to dial the phone. # This means: # 1) expect nothing (i.e., continue with step 2) # 2) send "ATZ", then a carriage return, then sleep for 1 to 2 # seconds. The \c means to not send a final carriage return. # 3) wait until the modem echoes "OK" # 4) send "ATDT", then the telephone number (after translating any # dialcodes). # 5) wait until the modem echoes "CONNECT" chat "" AT&K4\r\d\c OK ATDT\T CONNECT \d \ncs xyz\r\c login: donn\r\c Password: xyxyxyx\r # or just to the terminal server: #chat "" AT&K4\r\d\c OK ATDT\T CONNECT # If we get "BUSY" or "NO CARRIER" during the dial chat script we # abort the dial immediately. chat-fail BUSY chat-fail NO\sCARRIER # When the call is over, we make sure we hangup the modem. complete \d+++\dATH\r\c abort \d+++\dATH\r\c From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 12:24:22 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: challenge/response password program Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article <9405181416.AA18841@entropic.com> Ken Hornstein writes: > Have you looked at S/KEY? I haven't tried building it under NetBSD, but since > you have source it should be pretty easy to do it. It's not exactly a > challenge-response, but I think it will do what you want. S/KEY 1.1b ports to -current with only a few minor annoyances. Appended are quick patches to /usr/bin/{login,su} to allow s/key authentication. You will need the s/key binaries and libskey.a built and installed, and need to compile login+su with -DSKEY and link them with -lskey. With these patches you can enter "s/key" at a {su,login} Password: prompt and then be prompted for a s/key one-time password, or if you're on a secure login you can just enter your regular password. I'd be willing to do a port of s/key to NetBSD for proper integration if the core team is agreeable... I think that would be a Really Really Good Thing, what with the recent spate of password snooping. BTW, the tests for skey_haskey() below are correct. Contrary to common sense, a true return from skey_haskey() means the user does NOT have a key! *** login/login.c.orig Wed May 18 19:32:50 1994 --- login/login.c Wed May 18 19:43:22 1994 *************** *** 79,84 **** --- 79,85 ---- void sleepexit __P((int)); char *stypeof __P((char *)); void timedout __P((int)); + int pwcheck __P((char *, char *, char *, char *)); #ifdef KERBEROS int klogin __P((struct passwd *, char *, char *, char *)); #endif *************** *** 257,265 **** if (rval == 0) authok = 1; else if (rval == 1) ! rval = strcmp(crypt(p, salt), pwd->pw_passwd); #else ! rval = strcmp(crypt(p, salt), pwd->pw_passwd); #endif } bzero(p, strlen(p)); --- 258,266 ---- if (rval == 0) authok = 1; else if (rval == 1) ! rval = pwcheck(username, p, salt, pwd->pw_passwd); #else ! rval = pwcheck(username, p, salt, pwd->pw_passwd); #endif } bzero(p, strlen(p)); *************** *** 427,432 **** --- 428,451 ---- execlp(pwd->pw_shell, tbuf, 0); (void)fprintf(stderr, "%s: %s\n", pwd->pw_shell, strerror(errno)); exit(1); + } + + int + pwcheck(user, p, salt, passwd) + char *user, *p, *salt, *passwd; + { + #ifdef SKEY + if (strcasecmp(p, "s/key") == 0) { + if (skey_haskey(user)) { + fprintf(stderr, "You have no s/key. "); + return 1; + } else { + fprintf(stderr, "\n"); + return skey_authenticate(user); + } + } + #endif + return strcmp(crypt(p, salt), passwd); } #ifdef KERBEROS *** su/su.c.orig Wed May 18 18:53:22 1994 --- su/su.c Wed May 18 19:13:07 1994 *************** *** 169,175 **** --- 169,190 ---- /* if target requires a password, verify it */ if (*pwd->pw_passwd) { p = getpass("Password:"); + #ifdef SKEY + if (strcasecmp(p, "s/key") == 0) { + if (skey_haskey(user)) { + fprintf(stderr, "Sorry, you have no s/key.\n"); + exit(1); + } else { + fprintf(stderr, "\n"); + if (skey_authenticate(user)) { + goto badlogin; + } + } + + } else + #endif if (strcmp(pwd->pw_passwd, crypt(p, pwd->pw_passwd))) { + badlogin: fprintf(stderr, "Sorry\n"); syslog(LOG_AUTH|LOG_WARNING, "BAD SU %s to %s%s", username, -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 12:50:22 1994 From: jmc@cis.ksu.edu (James Michael Chacon) Subject: Patches to get current source working To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1515 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I needed the following patches to today's source (Wed) to get a kernel to compile with slip and inet defined, but no ether defined. I just went ahead and followed to style that icu.s used to do the same checks. James -- Cut Here -- *** nfs_vfsops.c+ Thu May 19 03:12:44 1994 --- nfs_vfsops.c Thu May 19 03:13:29 1994 *************** *** 159,164 **** --- 159,166 ---- */ nfs_mountroot() { + #include "ether.h" + #if NETHER > 0 register struct mount *mp; register struct mbuf *m; struct socket *so; *************** *** 320,325 **** --- 322,328 ---- rootvp = vp; inittodr((time_t)0); /* There is no time in the nfs fsstat so ?? */ return (0); + #endif } static void *** in.c+ Wed May 18 23:17:28 1994 --- in.c Thu May 19 03:10:59 1994 *************** *** 423,433 **** ia->ia_addr = oldaddr; return (error); } ! if (ifp->if_output == ether_output) { /* XXX: Another Kludge */ ia->ia_ifa.ifa_rtrequest = arp_rtrequest; ia->ia_ifa.ifa_flags |= RTF_CLONING; } ! splx(s); if (scrub) { ia->ia_ifa.ifa_addr = (struct sockaddr *)&oldaddr; in_ifscrub(ifp, ia); --- 423,436 ---- ia->ia_addr = oldaddr; return (error); } ! #include "ether.h" ! #if NETHER > 0 ! if (ifp->if_output == ether_output) { /* XXX: Another Kludge */ ia->ia_ifa.ifa_rtrequest = arp_rtrequest; ia->ia_ifa.ifa_flags |= RTF_CLONING; } ! #endif ! splx(s); if (scrub) { ia->ia_ifa.ifa_addr = (struct sockaddr *)&oldaddr; in_ifscrub(ifp, ia); From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 13:55:06 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) To: amiga@sun-lamp.cs.berkeley.edu Subject: Multiuser problem Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm having a bit of problem getting NetBSD into multiuser mode.. I can get to the login prompt but when I try to login as root or my normal user, I get "ld.so: login: libcrypt.so.0.0: Invalid Argument".. Does anybody know how to fix this? My setup is: Amiga 4000, 68040, 2 MB chip, 8 MB 32-bit fast, A2091 with .5Mb dma fast, rootfs and ~90 MB /usr on SyQuest 105, and 32MB swap on 120 MB Quantum I have the loadbsd.730 and vmunix.744 kernel, the rootfs is version 720, and I installed the bin-*.940319.tar.gz from NetBSD-Amiga/bin-dist on /usr... My libcrypt.so.0.0 is from NetBSD-Amiga/bin-current.. Is it btw: possible to binpatch the kernel to use DblNtsc on AGA instead of Ntsc? Or will I have to mess with the grf0.h? Please help.. /Michael From owner-netbsd-users@sun-lamp.cs.berkeley.edu Thu May 19 18:29:15 1994 Subject: X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: netbsd-users@sun-lamp.cs.berkeley.edu From: kallio@jyu.fi (Seppo Kallio) Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I am getting this error cc -O -DKERNEL -c mcount.c mcount.c:39: sys/gmon.h: No such file or directory *** Error code 1 When compiling kernel with NFSSERVER option Should it be possible to compile NetBSD current with this option? Or is there some error in my NetBSD sources? Seppo From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 18:55:40 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: Emacs 19.23 Organization: Analog Devices Inc, Norwood MA, USA X-Attribution: MWL Sender: owner-current-users@sun-lamp.cs.berkeley.edu I built Emacs 19.23 on my slightly-out-of-date (April 17?) -current system last night. It built "out of the box." I don't run X, however, so I can't say anything about Emacs' X capabilities. I didn't notice until afterwards that I had used NetBSD's make instead of GNU make, which made it even cooler. My thanks to those who beat Emacs and make into shape. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer Analog Devices, SPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 19:07:58 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 binaries for current? From: Guenther Grau Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, Matthieu.Herrb@laas.fr wrote [...] > I'd suggest you wait for XFree 3.1 that will be available with the > contrib tape. NetBSD-current is not supported by the X Consortium, > that mean that they don't integrate patches specific to > NetBSD-current. What does this mean, NetBSD-current isn't supported by the X Consortium? I thought the XFree-Team were members of the X Consortium and THEY support NetBSD-current, or am I wrong here? > > Matthieu Guenther From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 19:24:40 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/lib/libc/compat-43/creat.2 U src/lib/libc/gen/Makefile.inc U src/lib/libc/sys/umask.2 U src/lib/libcompat/Makefile U src/lib/libcompat/4.4/cuserid.3 U src/sys/arch/amiga/amiga/conf.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/trap.c U src/sys/arch/amiga/amiga/vm_machdep.c U src/sys/arch/hp300/hp300/vm_machdep.c U src/sys/arch/i386/conf/ALL U src/sys/arch/i386/conf/PAIN 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/i386/process_machdep.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/i386/include/cpu.h U src/sys/arch/i386/isa/if_ed.c U src/sys/arch/m68k/conf/files.m68k.newconf U src/sys/arch/m68k/fpsp/fpspnull.s U src/sys/arch/m68k/m68k/process_machdep.c U src/sys/arch/sparc/dev/zs.c U src/sys/arch/sparc/include/autoconf.h U src/sys/arch/sparc/include/cpu.h U src/sys/arch/sparc/include/param.h U src/sys/arch/sparc/include/pcb.h U src/sys/arch/sparc/sparc/autoconf.c U src/sys/arch/sparc/sparc/cpu.c U src/sys/arch/sparc/sparc/intr.c U src/sys/arch/sparc/sparc/locore.s U src/sys/arch/sparc/sparc/locore2.c U src/sys/arch/sparc/sparc/machdep.c U src/sys/arch/sparc/sparc/mem.c U src/sys/arch/sparc/sparc/pmap.c U src/sys/arch/sparc/sparc/trap.c U src/sys/arch/sparc/sparc/vm_machdep.c U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/kern/init_main.c U src/sys/kern/kern_descrip.c U src/sys/kern/kern_exit.c U src/sys/kern/kern_fork.c U src/sys/kern/kern_proc.c U src/sys/kern/kern_prot.c U src/sys/kern/kern_resource.c U src/sys/kern/kern_sig.c U src/sys/kern/subr_disk.c U src/sys/kern/subr_log.c U src/sys/kern/sys_generic.c U src/sys/kern/vfs_bio.c U src/sys/kern/vfs_lockf.c U src/sys/nfs/nfs_vnops.c U src/sys/sys/disklabel.h U src/sys/sys/errno.h U src/sys/sys/gmon.h U src/sys/sys/lockf.h U src/sys/sys/malloc.h U src/sys/sys/queue.h U src/sys/sys/select.h U src/sys/sys/socketvar.h U src/sys/sys/ucred.h U src/sys/vm/vm_glue.c U src/usr.bin/kdump/kdump.c U src/usr.bin/tee/Makefile U src/usr.bin/tee/tee.1 U src/usr.bin/tee/tee.c U src/usr.bin/vmstat/names.c Running the SUP scanner: SUP Scan for current starting at Thu May 19 04:20:57 1994 SUP Scan for current completed at Thu May 19 04:23:26 1994 SUP Scan for mirror starting at Thu May 19 04:23:26 1994 SUP Scan for mirror completed at Thu May 19 04:26:06 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 19:28:24 1994 From: Mats O Jansson To: Sean.Bennett@uk.sun.com, kenh@wrl.epi.com, mark@aggregate.com Subject: Re: Sparc ports Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <9405181605.AA23973@aggregate.com>, mark@aggregate.com (Mark P. Gooderum) writes: > >Has anyone done any work on a YP server implementation for NetBSD... > >-Mark > Yes, I've been working on it for the last two weeks. There is a small number of routines missing, but hopefully I'll have a alpha release ready early next week. The server will not support map transfer in the alpha release, but a configuration of a master server without slave servers should work. The reason for this project is that ypserv is the only thing between me and running NetBSD/sparc, all the time, on my ipc at home. moj From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 19:39:59 1994 From: (Cheng-Chung Song) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Cannot mount root partition Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I finally managed to build the kernel, from May 15 tar source, which configs to use ahsc only. When I tried to boot from the kernel, it ended with message of cannot mount root partition after successfully identify my two dard drives. I figured that it might relate to the new way of specifying dostype on the partition. My root partition is the last partition on the drive. I don't know if it matters or not. Those partition setup works fine with sys-744. So, if it is because of the dostype, I someone explain how one can convert old specification to the new specification. Song. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 19:54:55 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: Wrong Machine identification Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 18, 8:14pm, Christopher Eric Hanson wrote: > In article osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > > So does mine. Loadbsd looks for "A1000 Bonus" and "A4000 Bonus" for the > > A4000 systems, and "A3000 Bonus" for the A3000. It appears that perhaps > > not all A3000 systems have that module (if any even do). > > My v39 developer ROM A3000 shows "A3000 Bonus" with the B in uppercase. > The A3000T v37.175 (Real ROM, not Kickbooter ROM) says "A3000 bonus" with > the b in lowercase. This could be the problem, no? Lovely - nice and consistent of Commodore. Well, the next version of loadbsd is currently checking for both for the A3000. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 19:58:02 1994 From: "Gorgonio Barreto Ara'ujo" To: deraadt@fsa.ca, mark@aggregate.com Subject: Re: Sparc ports Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...] >Date: Wed, 18 May 94 12:44:09 CDT >From: mark@aggregate.com (Mark P. Gooderum) [...] > >> > Has anyone done any work on a YP server implementation for NetBSD... >> >> No, and I don't feel like doing it. Go for it, knock yourself dead. >> It's not that hard. > >Actually I had been thinking of just such a thing. I worked up a >prototype a while back to address some security issues. The idea was >to have RPC compatibility with ypserv but not worry about the same >implementation server side. Also some optional extensions to help address the >security issues (shadow passwords, "coldstart" files like NIS+ uses, >etc) and allow remote administration. > >The extensions would require integration with the yp client libs and ypbind, >but would be optional. > >I guess the only question would be is the YP stuff and related code >(getXXXyyXXX() funcs) fairly stable so I can take off and not have a major >integration headache in a month or so? (ie: is there much coming in from >4.4 still that will impact this?). This is really only an issue with the >extras since "true" compatibility for the server doesn't impact the >client side. > >-Mark > > Even thought kerberos' goal wasn't this, can't it replace NIS' function of propagate passwd's map? Does it work well now? How can I use it? Gorgonio ================================================================================ Gorgonio B. Ara'ujo |SIFEE - FEE - UNICAMP Support Engineer |13.081.970 - Campinas/SP - Brazil |phone: +55 192 397421 |fax: +55 192 391395 |Internet: Gorgonio@fee.unicamp.br ================================================================================ From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 19:59:44 1994 From: matthieu@laas.fr (Matthieu Herrb) To: Guenther Grau Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 binaries for current? <"irafs2.ira.792:19.04.94.13.21.26"@ira.uka.de> X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 914 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Thu 19) > > What does this mean, NetBSD-current isn't supported by the X > Consortium? I thought the XFree-Team were members of the X Consortium > and THEY support NetBSD-current, or am I wrong here? Yes, XFree86 supports NetBSD-current. But the XFree86 Project Inc. is seen by the X Consortium as a member among other. The X Consortium does not support all it's members platform/OS. (For example they have never supported Sun's GS and GT Framebuffers). The X Consortium only provide the sample implementation, known to work under certain specific platform/OS combination. One great news with X11R6 is that XFree86 is provided as sample implementation for x86 platorms. On another side, the X Consortium only knows "released" versions. Which, for NetBSD, would mean NetBSD-0.9. (I'm pretty sure that NetBSD isn't yet on their list of "known-to-work" OS). Matthieu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 20:15:35 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: (Cheng-Chung Song), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Cannot mount root partition Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 19, 9:12am, (Cheng-Chung Song) wrote: > > I finally managed to build the kernel, from May 15 tar source, which configs to > use ahsc only. When I tried to boot from the kernel, it ended with message of > cannot mount root partition after successfully identify my two dard drives. I > figured that it might relate to the new way of specifying dostype on the > partition. My root partition is the last partition on the drive. I don't know > if it matters or not. Those partition setup works fine with sys-744. So, if it > is because of the dostype, I someone explain how one can convert old > specification to the new specification. The DOStype field in the RDB PART blocks for the root partition will still work - BSDR should still be picked for the root partition. I think the May 15 sources may still have a bug in the A3000/A2091 scsi code. Look in .../dev/ahasc.c and find the call to sbicintr(i) - that needs to be changed to sbicintr(dev) if I remember right. There may be some other problems with the May 15 sources, but I can't think of any at the moment. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 20:22:27 1994 From: Alain Chofardet Subject: A4091 To: amiga@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 72.14] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi. What about A4091 support for new releases of NetBSD ? I've heard similar SCSI controllers were already supported (Michael ?)... Thanks. Alain. From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 20:25:12 1994 To: "Gorgonio Barreto Ara'ujo" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Sparc ports <199405191315.KAA20779@rubi.fee.unicamp.br> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> > Has anyone done any work on a YP server implementation for NetBSD... >Even thought kerberos' goal wasn't this, can't it replace NIS' function of pro pagate passwd's map? Does it work well now? How can I use it? > > Gorgonio Actually, Hesiod is usually used to distribute domain information such as passwords. Hesiod and Kerberos don't *need* each other, but were designed to work with each other. --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 May 19 20:35:55 1994 To: Guenther Grau Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree86 binaries for current? <"irafs2.ira.792:19.04.94.13.21.26"@ira.uka.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 >> I'd suggest you wait for XFree 3.1 that will be available with the >> contrib tape. NetBSD-current is not supported by the X Consortium, >> that mean that they don't integrate patches specific to >> NetBSD-current. > >What does this mean, NetBSD-current isn't supported by the X >Consortium? I thought the XFree-Team were members of the X Consortium >and THEY support NetBSD-current, or am I wrong here? I was under the impression that the X Consortium would only support OS levels up to the last official release. Since the last release of NetBSD is 0.9, they would only support that. --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 20:36:02 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: Wrong Machine identification Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9405191500.AA06416@gemini.oscs.montana.edu> osymh@gemini.oscs.montana.edu (Michael L. Hitch) writes: > > My v39 developer ROM A3000 shows "A3000 Bonus" with the B in uppercase. > > The A3000T v37.175 (Real ROM, not Kickbooter ROM) says "A3000 bonus" with > > the b in lowercase. This could be the problem, no? > > Lovely - nice and consistent of Commodore. Well, the next version of > loadbsd is currently checking for both for the A3000. Well, be fair... this is hardly a documented feature. They can change it any way they want to. As far as Commodore is (was) concerned, there is no approved way to tell different models apart. -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 20:45:36 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Alain Chofardet , amiga@sun-lamp.cs.berkeley.edu Subject: Re: A4091 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 19, 7:08pm, Alain Chofardet wrote: > What about A4091 support for new releases of NetBSD ? I've heard similar > SCSI controllers were already supported (Michael ?)... When somone can provide me with the particulars of the A4091, it should be trivial to add it. I need the manufacturer/product code values (easy to get), the offset of the 53C710 from the board base (not as easily obtained), and the values used to initialize the 53C710 registers. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 19 20:54:46 1994 From: Danny Lepage Subject: Swapping questions ... To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1602 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! First, this a copy of a post from Markus Wild in comp.unix.amiga. I did'nt asked permission from Markus, so I of he won't be to mad. The reason for posting this here instead of comp.unix.amiga is that our news server is broken, I can read but can't post to news group. >From comp.unix.amiga Thu May 19 13:27:04 1994 >Newsgroups: comp.unix.amiga >From: mw@eunet.ch (Markus Wild) >Subject: Re: Swap on different drive than rootfs >In article <2rcoi4$k4r@goliat.eik.bme.hu> mohacsi@fsz.bme.hu writes: >>Is it possible set up the NetBSD on a A300 which swap partition is on a >>different drive than rootfs (BSDR and BSDS on different drive). >>Will it recognize or not? It would be important to know >>how to partition my A3000. >Non-generic kernels support this, generic kernels want swap space on >the same drive as the root. That means, you'll have to compile your >own kernel to make this work. >-Markus Is this true? I have set my swap partition on a different drive then the root partition. I can go multi-user no problem, but I've noticed that no process get ever swapped. Since I was having some problem while compiling and using X (May distribution, the system progressively slow down, to the point where it seems it is completly frozen and I have to do the 3 fingers salute). So, might the fact that my swap and my root partitions are on two different drives cause the above behavior ? That is, no swapping -> frozen systems? Note: I'm using the April kernel and binaries set from sun-lamp/aistate. Thanks in advance. Danny Lepage poutine@M3iSystems.QC.CA dlepage@altitude.CAM.ORG From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 21:04:05 1994 From: Lennart Augustsson To: mycroft@duality.gnu.ai.mit.edu Cc: andrew@wipux2.wifo.uni-mannheim.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: 4 letter make, pk_subr.c missing _npaidb_enter etc. Sender: owner-current-users@sun-lamp.cs.berkeley.edu > My make is only outputting 4 letters then a space and then the next > 4 letters, > > I can't speak about this problem, because I have no idea what would > cause it, and honestly, I simply *can't* believe it unless I see it > happening myself. I had this problem a while ago. It turned out to be the version of echo that is supposed to be on the floppy had gotten installed instead of the real one. And this version of echo had a bug with that exact effect (it said "write(1, *argv, sizeof(*argv))" instead of "write(1, *argv, strlen(*argv))"). But both the bug in echo and in the installation have been fixed long (weeks) ago, so I don't know why you get it now. -- Lennart From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 21:17:08 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: IDE driver lockups (apparently solved) Sender: owner-current-users@sun-lamp.cs.berkeley.edu A while ago, I mailed that the new(er) wd.c hung my controller with 2 disks attached during startup. I 'fixed' this by doing a bogus hack. Charles Hannum suggested that I check if the alt_sts register of my controller actually worked. Well, the busy bit in this was always set.. I switched controllers, and all is fine now. So I guess it was a hardware fault. - Frank +----------------------------------------------------------------------------+ | I am not sure what a .signature is for, but my mom told me to make one. | | Frank van der Linden, vdlinden@fwi.uva.nl | +----------------------------------------------------------------------------+ From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 21:37:01 1994 From: (Cheng-Chung Song) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Cannot mount root partition Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >> >> I finally managed to build the kernel, from May 15 tar source, which configs to >> use ahsc only. When I tried to boot from the kernel, it ended with message of >> cannot mount root partition after successfully identify my two dard drives. .. > I think the May 15 sources may still have a bug in the A3000/A2091 scsi >code. Look in .../dev/ahasc.c and find the call to sbicintr(i) - that needs >to be changed to sbicintr(dev) if I remember right. I did change that. Otherwise, it probably won't go that far. >Michael After digging into the code, I find that the 'cannot mount root' were sent by main() in init_main.c after an unsuccessful ufs_mountroot(). I think the problem is probably in mountfs() where so many things can go wrong. Is it possible to go this far if something's wrong in the scsi driver code. In my config file, I have 'config netbsd swap on generic' statement. I wonder if thing will be better if I specify the root and swap partitions like 'config netbsd root on sd0a swap on sd0b'. Song. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 19 22:14: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: Cannot mount root partition Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 19, 10:48am, (Cheng-Chung Song) wrote: > > I think the May 15 sources may still have a bug in the A3000/A2091 scsi > >code. Look in .../dev/ahasc.c and find the call to sbicintr(i) - that needs > >to be changed to sbicintr(dev) if I remember right. > > I did change that. Otherwise, it probably won't go that far. Probably not - I think it hangs the first time it tries to access the disk using interrupts. > After digging into the code, I find that the 'cannot mount root' were sent by > main() in init_main.c after an unsuccessful ufs_mountroot(). I think the > problem is probably in mountfs() where so many things can go wrong. Is it > possible to go this far if something's wrong in the scsi driver code. Yes, it is. Some of the initial disk accesses are done without DMA or interrupts. These could succeed, while following accesses that use DMA could be failing. The mountfs() probably fails because what it is reading doesn't appear to be a valid file system. If you still have your root partition setup with the DOStype 'BSDR', you should get a message printed out when the readdisklabel routine processes the RDB partitions. There used to be a slight bug in the root device selection that could cause some confusion. I haven't checked to see if the problem still exists in the current kernel. The bug is that if no root partition was found on any disks, and a working SCSI drive was found on ID 0, it would attempt to use drive 0 as the root, and panic because there wasn't an 'a' partition. (If drive 0 didn't exist, the kernel would say "no suitable root found" and halt.) I don't know if the current kernel will still have this behaviour - I'd have to dig through the code to see how it does things now. I'm not sure what else may be causing the problem. I don't know if there's enough debugging code left in the new drivers to be able to track down what may be happening. > In my config file, I have 'config netbsd swap on generic' statement. I wonder > if thing will be better if I specify the root and swap partitions like > 'config netbsd root on sd0a swap on sd0b'. I doubt this would make any difference. The "swap on generic" just uses the 'b' partition on the drive containing the 'a' partition for the swap area. Changing the config file shouldn't change the behaviour on your system (assuming NetBSD is using /dev/sd0a as the root). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 22:14:50 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: man bug fix Sender: owner-current-users@sun-lamp.cs.berkeley.edu Explained in the patch.... christos *** src/usr.bin/man/man.c.dist Sun Apr 17 06:23:28 1994 --- src/usr.bin/man/man.c Thu May 19 14:14:13 1994 *************** *** 484,489 **** --- 484,490 ---- ENTRY *ep; TAG *intmpp; int fd; + char *p; char buf[MAXPATHLEN], cmd[MAXPATHLEN], tpath[sizeof(_PATH_TMP)]; /* Let the user know this may take awhile. */ *************** *** 492,503 **** warnx("Formatting manual page..."); } /* Add a remove-when-done list. */ if ((intmpp = getlist("_intmp")) == NULL) intmpp = addlist("_intmp"); /* Move to the printf(3) format string. */ ! for (; *fmt && isspace(*fmt); ++fmt); /* * Get a temporary file and build a version of the file --- 493,520 ---- warnx("Formatting manual page..."); } + /* + * Historically man chdir'd to the root of the man tree. + * This was used in man pages that contained relative ".so" + * directives (including other man pages for command aliases etc.) + * It even went one step farther, by examining the first line + * of the man page and parsing the .so filename so it would + * make hard(?) links to the cat'ted man pages for space savings. + * (We don't do that here, but we could). + */ + strcpy(buf, *pathp); + if ((p = strrchr(buf, '/')) != NULL) { + strcpy(++p, ".."); + chdir(buf); + } + /* Add a remove-when-done list. */ if ((intmpp = getlist("_intmp")) == NULL) intmpp = addlist("_intmp"); /* Move to the printf(3) format string. */ ! for (; *fmt && isspace(*fmt); ++fmt) ! continue; /* * Get a temporary file and build a version of the file From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 23:34:57 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: SYS_sigstack undefined references From: - Greg Earle Sender: owner-current-users@sun-lamp.cs.berkeley.edu The following smells like an ordering problem - i.e., something should have been built before something else, but wasn't. Is my suspicion correct, and if so what is the likely candidate for "you should have built this before that"? This is from a "make build" done on NetBSD/SPARC using last weekend's tar balls. netbsd4me# egrep SYS_sigstack make_build.log | sort | uniq ld.so: Undefined symbol "SYS_sigstack" in initdeck:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in make:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in makedefs:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mkastods:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mkastosc:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mkdstoas:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mkhits:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mknodes:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in mksyntax:/usr/lib/libc.so.11.0 ld.so: Undefined symbol "SYS_sigstack" in strfile:/usr/lib/libc.so.11.0 setjmp.o: Undefined symbol SYS_sigstack referenced from text segment TIA, - Greg From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 19 23:39:48 1994 From: deraadt@fsa.ca (Theo Deraadt) To: current-users@sun-lamp.cs.berkeley.edu, earle@isolar.Tujunga.CA.US Subject: Re: SYS_sigstack undefined references Sender: owner-current-users@sun-lamp.cs.berkeley.edu Last weekends sources would not have worked because I had not put the sigaltstack stuff into libc/arch/sparc/gen/setjmp.S yet. From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 01:06:09 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: amiga@sun-lamp.cs.berkeley.edu Subject: A3000 Kickstart Rom/Bootstrap question From: Terminator rAT Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! Just a quick question - will a 3000 with the disk-based kickstart work with NetBSD? Thanks! -rAT O----O Email: rat@cs.orst.edu Work: (503)737-5567 Home: (503)737-9467 \oo/ Instructional Support Technical Maniac ==\/== "Got carried away...In my dreams you're so far away." -VioletArcana From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 02:02:19 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: rhealey@aggregate.com Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: A3000 Kickstart Rom/Bootstrap question From: Terminator rAT Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Thu, 19 May 1994 17:32:13 -0500 (CDT) rhealey@aggregate.com wrote: > > Hi! Just a quick question - will a 3000 with the disk-based kickstart work > > with NetBSD? > > > Yes. Cool. Tnx! -rAT O----O Email: rat@cs.orst.edu Work: (503)737-5567 Home: (503)737-9467 \oo/ Instructional Support Technical Maniac ==\/== "Got carried away...In my dreams you're so far away." -VioletArcana From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 02:03:57 1994 From: rhealey@aggregate.com Subject: Re: A3000 Kickstart Rom/Bootstrap question To: rat@cs.orst.edu (Terminator rAT) 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: 102 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Hi! Just a quick question - will a 3000 with the disk-based kickstart work > with NetBSD? > Yes. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 20 02:17:40 1994 Subject: The revolution 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 A while back, chopps sent a note either here or in comp.unix.amiga to the effect that he was reworking all device drivers, so expect major changes. This comes at a time when the main NetBSD people are cutting over to 4.4-Lite. At that time, he implied that kernel sources were not compilable, really. I now ask: what condition are they in? I am thinking of re-installing NetBSD from scratch once the 4.4-Lite cutover has completed. That way, I can reduce the size of the AmigaOS partition from 100M to 20M and put the savings on the BSD side. In the meantime, how useful is the "latest SUP" (assuming I take one tonight) and do I need to get new binaries (if they exist)? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 20 04:12:12 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Subject: Re: The revolution Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: David Jones > > At that time, he implied that kernel sources were not compilable, really. > I now ask: what condition are they in? As of a few hours ago, they are still not buildable..... -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 20 04:35:30 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: David Jones , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: The revolution Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 19, 7:26pm, David Jones wrote: > A while back, chopps sent a note either here or in comp.unix.amiga to the > effect that he was reworking all device drivers, so expect major changes. > This comes at a time when the main NetBSD people are cutting over to > 4.4-Lite. > > At that time, he implied that kernel sources were not compilable, really. > I now ask: what condition are they in? > > I am thinking of re-installing NetBSD from scratch once the 4.4-Lite > cutover has completed. That way, I can reduce the size of the AmigaOS > partition from 100M to 20M and put the savings on the BSD side. > > In the meantime, how useful is the "latest SUP" (assuming I take one > tonight) and do I need to get new binaries (if they exist)? I don't know about tonight, but the sources I supped yesterday had to be fixed up a bit before I got a clean link. The problem I had should be fixed in the current sources, but I haven't check yet. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 09:59:00 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: site's in Europe for mirroring NetBSD-current ?? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu Anyone have a site in Europe for mirroring NetBSD-current ? We want to change our mirroring for NetBSD-Amiga. We used to get this from ftp.eunet.ch, but since everything is now incorporated in NetBSD-current, I was thinking about changing our mirroring scheme. Any suggestions anyone ? John From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 10:55:28 1994 From: matthieu@laas.fr (Matthieu Herrb) To: noses@oink.rhein.de (Noses) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: statically linked XFree86-2.1.1 binaries X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 150 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've added Xfree86-2.1.1-xdm-des.tar.gz on ftp.laas.fr in pub/NetBSD/XFree86-2.1.1/static. It's linked with the FreeSec libcrypt. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 11:20:25 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu Subject: s/key and -current Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ty Sarna writes: >With these patches you can enter "s/key" at a {su,login} Password: >prompt and then be prompted for a s/key one-time password, or if you're >on a secure login you can just enter your regular password. I don't think this is the right way to do things. Why not just have /bin/login prompt for an s/key if you have one, and likewise for su? Actually, why keep the old NetBSD /bin/login hanging around, s/key patches or no? Wietse's login package which comes with s/key is much nicer and has meny new security features, like a login.access file. Besides which, two of us here has been over the code with a nervous eye to security; it's a bit longer than the old /bin/login but it is most assuredly clean. >I'd be willing to do a port of s/key to NetBSD for proper integration if >the core team is agreeable... I think that would be a Really Really I have a fully working (except that I told it that netbsd used the wrong kind of rlogind) port of s/key 1.1b, plus a few local enhancements, for 0.9 or -current. Gimme a day or so to clean it up if you want it, and everyone's more than welcome. >Good Thing, what with the recent spate of password snooping. I still really, really hope that access to the master -current tree is controlled by one-time passwords somehow. I still don't know if it is or not, but when it's so _easy_ to install and run s/key, I can't see any reason why everyone in the known universe oughtn't be using it -- operating system developers in particular. From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 11:57:07 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "site's in Europe for mirroring NetBSD-current ??" (May 20, 8:37am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu Subject: Re: site's in Europe for mirroring NetBSD-current ?? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 20, 8:37am, John Vrolijk wrote: > Subject: site's in Europe for mirroring NetBSD-current ?? > > Anyone have a site in Europe for mirroring NetBSD-current ? > We want to change our mirroring for NetBSD-Amiga. > We used to get this from ftp.eunet.ch, but since everything is now > incorporated in NetBSD-current, I was thinking about changing our mirroring scheme. > Any suggestions anyone ? As far as i know there are plenty of sites, one i know of is ftp.uni-kassel.de. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 12:01:57 1994 Disclaimer: "The National Aerospace Laboratory NLR DOES NOT ACCEPT ANY FINANCIAL COMMITMENT derived from this message." From: Gerard J van der Grinten Subject: rlogind and rshd wont compile after 18-5 To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 739 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello... After the transfer of lib/libc/net/rcmd.c rlogind and rshd (in libexec) wont compile anymore. Missing symbol __check_rhosts_file. In libc/net/rcmd.c __check_rhosts_file is defined (and ends up to be ___check_rhosts_file in the library, no wonder it is not found...) Please resubmit rcmd.c with _check_rhosts_file defined.... Regards, Gerard. PS, I added LCC and HDLC to my system definitons. It worked.. Sorry for my too quick hack and answer.... -- Gerard J van der Grinten pa0gri@net.pa0gri.ampr.org [44.137.1.1] Elzenlaan 8 gvdg@nlr.nl (temporary qrl) 3467 TJ Driebruggen gvdg@fridley.pa0gri.ampr.org (home) Netherlands (+031)-34871606 Home. (+031)-52748435 Qrl. From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 12:02:43 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Multiuser problem" (May 19, 12:39pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: v17@dec5102.aarhues.dk (Michael Kofod), amiga@sun-lamp.cs.berkeley.edu Subject: Re: Multiuser problem Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 19, 12:39pm, Michael Kofod wrote: > I have the loadbsd.730 and vmunix.744 kernel, the rootfs is version 720, > and I installed the bin-*.940319.tar.gz from NetBSD-Amiga/bin-dist on > /usr... My libcrypt.so.0.0 is from NetBSD-Amiga/bin-current.. And this is the problem... Your libcrypt doesn't include the crypt() command - old US-export problem. Get the libcrypt which is avail on either eunet or ftp.uni-regensburg.de > Is it btw: possible to binpatch the kernel to use DblNtsc on AGA instead > of Ntsc? Or will I have to mess with the grf0.h? No. Yes, and more than that. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 12:09:50 1994 From: Petri Nordlund Subject: Latest kernel and other problems 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: 1831 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have many questions, so let's get started: I compiled a GENERIC kernel from 940519 sources. The only change I had to make to get the kernel to compile was to add: extern struct utsname utsname; to compat/sunos/sun_misc.c. Otherwise everything went just fine. I booted the machine with the new kernel and mounted everything like before. This worked fine. But when I try to run some program that uses shared libraries, it says: "Cannot map anonymous memory ld.so: virtual memory exhausted". It did the same thing with a kernel compiled about a week ago. I compiled a new ld.so, with the same result. I also tried to change the DOS type fields to NBR\7, NBS\1, NBU\7 but it didn't help either. 'df' shows that swap is mounted correctly and copying files to /tmp works ok. Any ideas? I'm also having problems with 'Term'. I'm using Term 1.1.1 and it works fine with a kernel dated 16-Apr-94, but not with a kernel compiled 10th May. The main binary starts ok, but trsh doesn't do anything. Term is the most important program that I run under NetBSD, so I'd like to get it working. I have got two SCSI-controllers on my machine. I have GVP Series-II with a 340MB drive and a Wordsync with a 40MB drive. The 40MB drive didn't want to cooperate with the bigger drive, so I left it in the old controller. I have all the NetBSD partitions on the 340MB drive but I'd also like to use the drive connected to Wordsync with NetBSD. Is there a way to make NetBSD use two SCSI-controllers? I'm running NetBSD on Amiga 2000/G-Force 030, latest binaries from ftp.istate.edu. Thanks. -- __ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Petri Nordlund _ /// petrin@mits.mdata.fi ------------------------------\XX/------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 14:46:32 1994 X-Authentication-Warning: oink.home: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: kernfs .. From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu i had a look in /kern again today for the first time in a while, and i noticed that all the files were sorta big. oink /kern> l total 0 -r--r--r-- 1 root wheel 438086664191 May 20 20:44 copyright -rw-r--r-- 1 root wheel 47244640255 May 20 20:44 hostname -r--r--r-- 1 root wheel 21474836479 May 20 20:44 hz -r--r--r-- 1 root wheel 77309411327 May 20 20:44 loadavg -r--r--r-- 1 root wheel 25769803775 May 20 20:44 physmem brw-r----- 1 root operator 7, 0 Apr 12 16:16 rootdev -r--r--r-- 1 root wheel 77309411327 May 20 20:44 time -r--r--r-- 1 root wheel 489626271743 May 20 20:44 version looks a little silly. i seem to remember they used to give the `real' size of what they held. From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 15:24:36 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 Null message body; hope that's ok Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/gnu/usr.bin/gas/app.c U src/gnu/usr.bin/gas/read.c U src/gnu/usr.bin/gas/read.h U src/gnu/usr.bin/gawk/ACKNOWLEDGMENT U src/gnu/usr.bin/gawk/FUTURES U src/gnu/usr.bin/gawk/LIMITATIONS U src/gnu/usr.bin/gawk/NEWS U src/gnu/usr.bin/gawk/PORTS U src/gnu/usr.bin/gawk/README U src/gnu/usr.bin/gawk/array.c U src/gnu/usr.bin/gawk/awk.h U src/gnu/usr.bin/gawk/awk.y U src/gnu/usr.bin/gawk/builtin.c U src/gnu/usr.bin/gawk/config.h U src/gnu/usr.bin/gawk/dfa.c U src/gnu/usr.bin/gawk/dfa.h U src/gnu/usr.bin/gawk/eval.c U src/gnu/usr.bin/gawk/field.c U src/gnu/usr.bin/gawk/getopt.c U src/gnu/usr.bin/gawk/getopt.h U src/gnu/usr.bin/gawk/getopt1.c U src/gnu/usr.bin/gawk/io.c U src/gnu/usr.bin/gawk/iop.c U src/gnu/usr.bin/gawk/main.c U src/gnu/usr.bin/gawk/msg.c U src/gnu/usr.bin/gawk/node.c U src/gnu/usr.bin/gawk/patchlevel.h U src/gnu/usr.bin/gawk/protos.h U src/gnu/usr.bin/gawk/re.c U src/gnu/usr.bin/gawk/regex.c U src/gnu/usr.bin/gawk/regex.h U src/gnu/usr.bin/gawk/version.c U src/gnu/usr.bin/gdb/bfd/trad-core.c U src/gnu/usr.bin/gdb/bfd/arch/sparc/sysdep.h U src/gnu/usr.bin/gdb/gdb/arch/sparc/sparc-nat.c U src/lib/libc/stdlib/Makefile.inc U src/libexec/rlogind/rlogind.c U src/libexec/rshd/rshd.c U src/sbin/route/Makefile U src/sys/arch/hp300/hp300/conf.c U src/sys/arch/hp300/hp300/vm_machdep.c U src/sys/arch/pc532/conf/GENERIC_OF U src/sys/arch/pc532/include/reg.h U src/sys/arch/pc532/pc532/clock.c U src/sys/arch/pc532/pc532/icode.c U src/sys/arch/pc532/pc532/locore.s U src/sys/arch/pc532/pc532/machdep.c U src/sys/arch/pc532/pc532/trap.c U src/sys/arch/pc532/pc532/vm_machdep.c U src/sys/arch/sparc/sparc/vm_machdep.c U src/sys/arch/sun3/dev/zs.c U src/sys/arch/sun3/sun3/autoconf.c U src/sys/arch/sun3/sun3/conf.c U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/process.s U src/sys/arch/sun3/sun3/trap.c U src/sys/arch/sun3/sun3/vm_machdep.c U src/sys/compat/sunos/sun_misc.c U src/sys/kern/kern_acct.c U src/sys/kern/kern_physio.c U src/sys/kern/kern_sig.c U src/sys/kern/kern_time.c U src/sys/kern/kern_xxx.c U src/sys/kern/subr_autoconf.c U src/sys/sys/device.h U src/sys/sys/disk.h U src/sys/sys/vnode.h U src/sys/vm/vm_mmap.c U src/usr.bin/cksum/cksum.1 U src/usr.bin/fstat/Makefile U src/usr.sbin/amd/amq/Makefile Running the SUP scanner: SUP Scan for current starting at Fri May 20 03:39:57 1994 SUP Scan for current completed at Fri May 20 03:42:23 1994 SUP Scan for mirror starting at Fri May 20 03:42:23 1994 SUP Scan for mirror completed at Fri May 20 03:44:56 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 15:35:37 1994 From: Noel Cragg To: current-users@sun-lamp.cs.berkeley.edu Subject: Problems building -current as of 19 May Sender: owner-current-users@sun-lamp.cs.berkeley.edu I encountered a problems when building the current source because the Makefile for sh didn't have libedit in its list of directories to include. Also, I added a few #if statements to the code to get it to work correctly for the version compiled with NO_HISTORY (specifically in the arch/i386/floppy directory). Patches follow. ./bin/sh/eval.c *** ./bin/sh/eval.c.orig Fri May 20 07:32:14 1994 --- ./bin/sh/eval.c Fri May 20 07:32:41 1994 *************** *** 60,66 **** --- 60,68 ---- #include "memalloc.h" #include "error.h" #include "mystring.h" + #ifndef NO_HISTORY #include "myhistedit.h" + #endif #include #include ./bin/sh/input.c *** ./bin/sh/input.c.orig Fri May 20 07:32:50 1994 --- ./bin/sh/input.c Fri May 20 07:36:41 1994 *************** *** 55,61 **** --- 55,63 ---- #include "error.h" #include "alias.h" #include "parser.h" + #ifndef NO_HISTORY #include "myhistedit.h" + #endif #define EOF_NLEFT -99 /* value of parsenleft when EOF pushed back */ *************** *** 96,102 **** --- 98,106 ---- int init_editline = 0; /* editline library initialized? */ int whichprompt; /* 1 == PS1, 2 == PS2 */ + #ifndef NO_HISTORY EditLine *el; /* cookie for editline package */ + #endif #ifdef __STDC__ STATIC void pushfile(void); ./bin/sh/parser.c *** ./bin/sh/parser.c.orig Fri May 20 07:33:21 1994 --- ./bin/sh/parser.c Fri May 20 07:37:50 1994 *************** *** 52,59 **** #include "memalloc.h" #include "mystring.h" #include "alias.h" #include "myhistedit.h" ! /* * Shell command parser. --- 52,60 ---- #include "memalloc.h" #include "mystring.h" #include "alias.h" + #ifndef NO_HISTORY #include "myhistedit.h" ! #endif /* * Shell command parser. *************** *** 1339,1345 **** --- 1340,1348 ---- { whichprompt = which; + #ifndef NO_HISTORY if (!el) + #endif out2str(getprompt(NULL)); } ./bin/sh/Makefile *** ./bin/sh/Makefile.orig Fri May 20 07:58:20 1994 --- ./bin/sh/Makefile Fri May 20 07:58:46 1994 *************** *** 9,15 **** LDADD+= -ll -ledit -ltermcap DPADD+= ${LIBL} ${LIBEDIT} ${LIBTERMCAP} LFLAGS= -8 # 8-bit lex scanner for arithmetic ! CFLAGS+=-DSHELL -I. -I${.CURDIR} .PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf CLEANFILES+=\ builtins.c builtins.h init.c mkinit mknodes mksyntax \ --- 9,15 ---- LDADD+= -ll -ledit -ltermcap DPADD+= ${LIBL} ${LIBEDIT} ${LIBTERMCAP} LFLAGS= -8 # 8-bit lex scanner for arithmetic ! CFLAGS+=-DSHELL -I. -I${.CURDIR} -I../../lib/libedit .PATH: ${.CURDIR}/bltin ${.CURDIR}/../../usr.bin/printf CLEANFILES+=\ builtins.c builtins.h init.c mkinit mknodes mksyntax \ -- Noel Cragg \\ 283 North Main Street \\ Oberlin OH 44074-1119 \\ 216/774-3140 noel@cs.oberlin.edu \\ noel@gnu.ai.mit.edu -- Noel Cragg \\ 283 North Main Street \\ Oberlin OH 44074-1119 \\ 216/774-3140 noel@cs.oberlin.edu \\ noel@gnu.ai.mit.edu -- Noel Cragg \\ 283 North Main Street \\ Oberlin OH 44074-1119 \\ 216/774-3140 noel@cs.oberlin.edu \\ noel@gnu.ai.mit.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 18:24:08 1994 From: Tim Chase Subject: getty - problem on a serial port 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: 741 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, Is anyone using getty on a serial port right now? This may be i386-specific, but I don't think I've been able to login using a modem to my system since getty was changed to use termios. Actually, the problem may not be with getty. After the modem connects, I get the "NetBSD/ ..." message and the "login:" prompt just fine. After typing my login name, however, it prints a line of garbage and is, apparently, hung. It's kind of hard for me to debug this since I'm calling into my home system and I can't tell what's happening on the system. This is running a current kernel/getty/login/libutil (but not libc) supped yesterday night (Thursday). Any ideas? Could libc be the culprit? - Tim Chase tim@introl.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 19:01:49 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: s/key and -current Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article Thor Lancelot Simon writes: > Ty Sarna writes: > >With these patches you can enter "s/key" at a {su,login} Password: > >prompt and then be prompted for a s/key one-time password, or if you're > >on a secure login you can just enter your regular password. > > I don't think this is the right way to do things. Why not just have > /bin/login prompt for an s/key if you have one, and likewise for su? Because I don't want to FORCE people to use S/Key all the time if they don't want to. Consider my own situation: I normally login in locally, so I don't want to bother with S/Key in that case. But I want to have a key for when I log in remotely. Also, once have a key there's no easy way for me to get rid of it, so then I'd have to continue using S/Key all the time, even for local logins. Finally, by leaving the choice the user is provided an "emergency exit", so if they absolutely need access to their account and don't have prepepared keys or the key program availible, they can use their regular password and risk it. > Actually, why keep the old NetBSD /bin/login hanging around, s/key patches or > no? Wietse's login package which comes with s/key is much nicer and has meny > new security features, like a login.access file. I wanted to make minimal changes to start with. If somebody wants to try to get NetBSD's login replaced with Weitse's in the tree, they can go ahead. I would ask that they change it to handle passwords like my skey version does. My ftpd changes also allow either S/Key or regular passwords, but handle it slightly diferently. > I have a fully working (except that I told it that netbsd used the wrong kind > of rlogind) port of s/key 1.1b, plus a few local enhancements, for 0.9 or > -current. Gimme a day or so to clean it up if you want it, and everyone's > more than welcome. I finished up my port yesterday and sent it off to Theo, so hopefully it can go into the tree soon. Mine's cleaned up and NetBSD-ized in terms of directory structure and Makefiles. > >the core team is agreeable... I think that would be a Really Really > >Good Thing, what with the recent spate of password snooping. > > I still really, really hope that access to the master -current tree is > controlled by one-time passwords somehow. I still don't know if it is or not, > but when it's so _easy_ to install and run s/key, I can't see any reason why > everyone in the known universe oughtn't be using it -- operating system > developers in particular. Definately agreed... sun-lamp people are at a high-risk for password snooping, I'm sure, since access to the NetBSD tree for purposes of adding trojans would be a valuable prize for a cracker. Of course, Theo probably wants to make sure I din't add my own trojans to S/Key before he commits it or starts using it :-) You have to be careful when someone sends you patches to things like login and su :-) -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 19:46:49 1994 From: Magnus Gronlund Subject: Re: site's in Europe for mirroring NetBSD-current ?? To: dsnjvro@etmsun.ericsson.se (John Vrolijk) Cc: 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: 742 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > > Anyone have a site in Europe for mirroring NetBSD-current ? > We want to change our mirroring for NetBSD-Amiga. > We used to get this from ftp.eunet.ch, but since everything is now > incorporated in NetBSD-current, I was thinking about changing our mirroring scheme. > Any suggestions anyone ? Ftp.luth.se. As of now we have a complete mirror of sun-lamp, (and of ftp.eunet.ch) and the disks are far from full. The machine is a VAX-8530 with 13GB disk, no access restrictions and a 34Mbit connection to the rest of the world. It can be reached through ftp, fsp, http and ftpmail, (I have compiled sup but it isn't running at the moment). > > John > /Magnus Gr|nlund - NetBSD-Amiga adm. ftp.luth.se, d91-mgd@ludd.luth.se From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 20:03:34 1994 From: phil@cs.wwu.edu (Phil Nelson) To: tim@introl.introl.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: getty - problem on a serial port Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Is anyone using getty on a serial port right now? This may be >i386-specific, but I don't think I've been able to login using a modem >to my system since getty was changed to use termios. Actually, the >problem may not be with getty. After the modem connects, I get the >"NetBSD/ ..." message and the "login:" prompt just fine. After typing >my login name, however, it prints a line of garbage and is, apparently, >hung. It's kind of hard for me to debug this since I'm calling into my >home system and I can't tell what's happening on the system. This is >running a current kernel/getty/login/libutil (but not libc) supped >yesterday night (Thursday). Any ideas? Could libc be the culprit? Something very similar is happening currently (since around May 10) on the pc532 port also. (It always uses serial ports.) On the pc532, just the output part is messed up and an appropriate "stty cs8 -parenb" gets it fixed. You do need to type your password to the grabage prompt. I also have the "stty ..." in my login script, so I get back readable output before my next input is required. --Phil From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 20:30:17 1994 To: "Gorgonio Barreto Ara'ujo" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Sparc ports <199405201414.LAA07791@rubi.fee.unicamp.br> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>Actually, Hesiod is usually used to distribute domain information such >>as passwords. Hesiod and Kerberos don't *need* each other, but were >>designed to work with each other. >> --Michael >What's ``hesiod'' and where can I find it? > Gorgonio Hesiod is a distributed database system for domain information like usernames, service locations, etc. that works through BIND. It's a part of the Project Athena distributed computer system. Kerberos is commonly used with it for authentication purposes in a centralized fashion. I'd suggest getting the postscript files on gatekeeper.dec.com in /pub/athena/doc/ and reading through them. --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 Fri May 20 20:31:42 1994 To: Thor Lancelot Simon Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: s/key and -current From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Ty Sarna writes: >>With these patches you can enter "s/key" at a {su,login} Password: >>prompt and then be prompted for a s/key one-time password, or if you're >>on a secure login you can just enter your regular password. >Actually, why keep the old NetBSD /bin/login hanging around, s/key patches or >no? Wietse's login package which comes with s/key is much nicer and has meny >new security features, like a login.access file. It must support kerberos as an optional part of the package. Does it? --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 Fri May 20 21:13:14 1994 From: jgb@tornasol.uc3m.es Subject: Trying to port GNAT (Ada compiler). To: current-users@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 66.33] Sender: owner-current-users@sun-lamp.cs.berkeley.edu After some time of problemas and unexpected work load, last week I had time to go ahead and try to compile GNAT for NetBSD. I succeded in building a cross-compiler from SunOS 4.1 to NetBSD. It compiles the examples, and the examples run. When trying to build the native compiler (compiling all the sources with the cross-compiler), it eats everything with no errors. And generated executables seem to be "correct" ones. And they come up and die gracefully when run with no arguments. Some of them even do their job. But the most important, gnat1 (equivalent to cc1), dies from signal 11, always in the same (Ada) line. I've tried to debug it with gdb, but I have no experience about that, and I find nothing interesting --except the fact that it always dies in the same line, trying to access to an unexisting memory address. Is there anybody out there with Ada and gdb knowledge, and some time to help me? I can upload the cross-compiler (or the patches) somewhere, also, if somebody is interested. My NetBSD is no very current --mid march, I was afraid when the off_t thing--, and gnat is 1.74 --yes, I know there are newer versions, but I have been out of Internet for a while... Thanks in advance, Jesus. -- Jesus M. Gonzalez Barahona Universidad Carlos III, Spain e-mail: jgb@inf.uc3m.es tel: +34 1 624 94 58 jgb@tornasol.uc3m.es fax: +34 1 624 94 30 From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 20 21:26:52 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 --------------------------------- cgd Fri May 13 23:31:21 PDT 1994 Update of /b/source/CVS/src/lib/libc/gmon In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/libc/gmon Modified Files: Makefile.inc gmon.c mcount.c moncontrol.3 Log Message: rcsids. also, avoid floating point when picking scale value. doesn't cost much, only done once. cgd Fri May 13 23:33:12 PDT 1994 Update of /b/source/CVS/src/lib/csu/i386 In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/i386 Modified Files: Makefile Removed Files: gmon.c gmon.h gprof.ex Log Message: kill all gprof-related stuff; it's now in libc, and the header is elsewhere cgd Fri May 13 23:33:16 PDT 1994 Update of /b/source/CVS/src/lib/csu/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/m68k Modified Files: Makefile Removed Files: gmon.c gmon.h Log Message: kill all gprof-related stuff; it's now in libc, and the header is elsewhere cgd Fri May 13 23:33:20 PDT 1994 Update of /b/source/CVS/src/lib/csu/ns32k In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/ns32k Modified Files: Makefile Removed Files: gmon.c gmon.h Log Message: kill all gprof-related stuff; it's now in libc, and the header is elsewhere cgd Fri May 13 23:33:26 PDT 1994 Update of /b/source/CVS/src/lib/csu/sparc In directory sun-lamp.cs.berkeley.edu:/usr/src/lib/csu/sparc Modified Files: Makefile Removed Files: gmon.c gmon.h Log Message: kill all gprof-related stuff; it's now in libc, and the header is elsewhere deraadt Fri May 13 23:39:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/dev In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/sparc/dev Modified Files: zs.c Log Message: TIOCSBRK/TIOCCBRK --------------------------------- chopps Sun May 15 21:50:05 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Log Message: remove SYSVSHM chopps Sun May 15 21:50:46 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: device.h swapgeneric.c Log Message: add macro and fix typo. chopps Sun May 15 21:52:45 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: device.h Log Message: ()'s for macro args, sheesh. chopps Sun May 15 21:55:15 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ahsc.c atzsc.c ser.c Log Message: remove uneeded function from ser.c and fix common bad arg to sbicintr() in ahsc and atzsc --------------------------------- chopps Sun May 15 22:04:02 PDT 1994 Update of /b/source/CVS/src/sys/adosfs In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/adosfs Modified Files: advnops.c Log Message: directories wired to have link count 1 not 2, pointed out by Charles. chopps Sun May 15 22:08:33 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: disksubr.c Log Message: move mysterious dk_establish() stub routine from gtsc driver to disksubr.c chopps Sun May 15 22:09:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: gtsc.c Log Message: move mysterious dk_establish() stub routine from gtsc driver to disksubr.c --------------------------------- mycroft Sun May 15 22:13:53 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/i386 Modified Files: conf.c Log Message: Correct select function for pccons and pcvt. chopps Sun May 15 22:17:18 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Added Files: profile.h Log Message: just include common m68k version --------------------------------- chopps Sun May 15 22:31:50 PDT 1994 Update of /b/source/CVS/src/lib/libkvm In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/lib/libkvm Modified Files: Makefile Added Files: kvm_om68k.c Log Message: add support for current m68k based pmaps till they can be "fixed" --------------------------------- cgd Mon May 16 03:58:29 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/include Modified Files: varargs.h Log Message: USL copyright foo cgd Mon May 16 03:58:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/include Modified Files: varargs.h Log Message: USL copyright foo cgd Mon May 16 03:59:05 PDT 1994 Update of /b/source/CVS/src/include In directory sun-lamp.cs.berkeley.edu:/usr/src/include Modified Files: Makefile ar.h assert.h ctype.h grp.h nlist.h pwd.h setjmp.h time.h utmp.h Removed Files: varargs.h Log Message: update all but ctype.h, dumprestore.h, time.h to 4.4-Lite versions. USL copyright additions on those. Kill varargs.h, because it can simply be a link to the machine-dependent version. cgd Mon May 16 03:59:13 PDT 1994 Update of /b/source/CVS/src/include/protocols In directory sun-lamp.cs.berkeley.edu:/usr/src/include/protocols Modified Files: dumprestore.h Log Message: update all but ctype.h, dumprestore.h, time.h to 4.4-Lite versions. USL copyright additions on those. Kill varargs.h, because it can simply be a link to the machine-dependent version. --------------------------------- gwr Mon May 16 09:51:50 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/m68k/m68k Modified Files: db_disasm.c Log Message: Fix disassembly of "mov #0xNNNN,sr" --------------------------------- cgd Mon May 16 20:36:41 PDT 1994 Update of /b/source/CVS/src/usr.bin/gprof In directory sun-lamp.cs.berkeley.edu:/usr/src/usr.bin/gprof Modified Files: Makefile arcs.c dfn.c gprof.1 gprof.c gprof.h hertz.c i386.c i386.h lookup.c m68k.c m68k.h mips.c mips.h pathnames.h printgprof.c printlist.c sparc.c sparc.h tahoe.c tahoe.h vax.c vax.h Added Files: pmax.c pmax.h Log Message: clean up import, etc. --------------------------------- pk Tue May 17 07:01:54 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gdb/gdb Modified Files: Makefile defs.h gdbcore.h init.c main.c target.c target.h Log Message: Framework for kernel debugging, needs more work. pk Tue May 17 07:02:03 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb/arch/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gdb/gdb/arch/i386 Modified Files: i386b-nat.c Log Message: Framework for kernel debugging, needs more work. pk Tue May 17 07:02:09 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb/arch/sparc In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gdb/gdb/arch/sparc Modified Files: sparc-nat.c Log Message: Framework for kernel debugging, needs more work. pk Tue May 17 07:04:51 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb/arch/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gdb/gdb/arch/m68k Modified Files: m68k-tdep.c Log Message: dummy kernel-debug routines for now. --------------------------------- chopps Wed May 18 09:05:09 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: conf.c locore.s trap.c vm_machdep.c Log Message: mirror recent i386 changes to conf and regarding profiling in trap and swtch nameing changes. --------------------------------- chopps Wed May 18 09:31:20 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/m68k/conf Modified Files: files.m68k.newconf Log Message: always assemble fpspnull.s chopps Wed May 18 09:31:50 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/m68k/fpsp Modified Files: fpspnull.s Log Message: conditional contents on !FPSP --------------------------------- mycroft Wed May 18 23:33:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/i386 Modified Files: machdep.c Log Message: I don't have a VAX. mycroft Wed May 18 23:34:55 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/i386 Modified Files: process_machdep.c Log Message: Minor changes. mycroft Wed May 18 23:36:07 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/m68k Modified Files: process_machdep.c Log Message: Speed up process_sstep() and process_set_pc(). cgd Wed May 18 23:39:47 PDT 1994 Update of /b/source/CVS/src/sys/sys In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/sys Modified Files: select.h Log Message: update to 4.4-lite cgd Wed May 18 23:39:51 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/kern Modified Files: sys_generic.c Log Message: update to 4.4-lite --------------------------------- deraadt Thu May 19 01:23:46 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/include In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/sparc/include Modified Files: autoconf.h cpu.h param.h pcb.h Log Message: liten deraadt Thu May 19 01:25:27 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/sparc In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/sparc/sparc Modified Files: vm_machdep.c Log Message: enable cpu_coredump chopps Thu May 19 01:29:23 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: vm_machdep.c Log Message: add cpu_coredump from i386/vm_machdep.c --------------------------------- chopps Thu May 19 01:51:49 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: vm_machdep.c Log Message: need to include vnode.h --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 21:43:20 1994 To: phil@cs.wwu.edu (Phil Nelson) Cc: tim@introl.introl.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: getty - problem on a serial port <9405201604.AA06611@strawberry.cs.wwu.edu> X-Mailer: exmh version 1.3 4/7/94 From: John Brezak Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >Is anyone using getty on a serial port right now? This may be > >i386-specific, but I don't think I've been able to login using a modem > >to my system since getty was changed to use termios. Actually, the > >problem may not be with getty. After the modem connects, I get the > >"NetBSD/ ..." message and the "login:" prompt just fine. After typing > >my login name, however, it prints a line of garbage and is, apparently, > >hung. It's kind of hard for me to debug this since I'm calling into my > >home system and I can't tell what's happening on the system. This is > >running a current kernel/getty/login/libutil (but not libc) supped > >yesterday night (Thursday). Any ideas? Could libc be the culprit? > > Something very similar is happening currently (since around May 10) > on the pc532 port also. (It always uses serial ports.) On the pc532, > just the output part is messed up and an appropriate "stty cs8 -parenb" > gets it fixed. You do need to type your password to the grabage prompt. > I also have the "stty ..." in my login script, so I get back readable > output before my next input is required. > > --Phil I think I "fixed" this by creating a special gettytab entry for the console so that the tty lines used the default. Then I changed "ap" to "ep" in the default entry. I remember some discussion about changing ttydefaults to 8-bit no parity a while back - is this a dead idea ? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5122 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 21:51:33 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: s/key and -current Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article <9405201617.AA01497@ponderous.cc.iastate.edu> "Michael L. VanLoon -- Iowa State University" writes: > > >Actually, why keep the old NetBSD /bin/login hanging around, s/key patches or > >no? Wietse's login package which comes with s/key is much nicer and has meny > >new security features, like a login.access file. > > It must support kerberos as an optional part of the package. Does it? BTW, I haven't tested my S/Key support with kerberos enabled, since I don't have kerberos installed. If anyone is able to try it and make sure it works correctly I'd appreciate it. I think I did it right, but who knows :-) -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 22:13:50 1994 From: Tim Chase Subject: Re: getty - problem on a serial port 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: 852 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > --Phil > I think I "fixed" this by creating a special gettytab entry for the console > so that the tty lines used the default. Then I changed "ap" to "ep" in the > default entry. Okay, I bet that'll "fix" it. I tried calling into my system awhile ago and fiddled with the bits & parity settings on the remote end and did manage to get logged in (I'm using seyon on the remote side). However, in playing with the settings in seyon, there didn't seem to be _any_ combination of bits & parity that would not cause received characters to be trashed. Maybe I'll have to fiddle with it more. Anyways, thanks for the suggestions. I didn't think it was a parity, etc. issue at first because the line seemed so dead after entering my login name and also because the initial login string & prompt were clean. - Tim Chase tim@introl.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 23:26:25 1994 From: Drew Hess Subject: WrapHelp.c for X11R5 To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 328 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am going to rebuild XFree86 2.1.1 for my system this weekend. Unfortunately ftp.x.org no longer seems to have WrapHelp.c available in /etc/help as the /pub/R5/xdm-auth/README file claims. Could someone in the US please send me this file if you happen to have a X11R5 source tree handy? Thanks -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 20 23:46:14 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: multiport serial boards 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'm interested in getting a 4 or 8 port serial board to use with -current and I see that there is support for a 4-port AST card and Cyclades Cyclom-Y. What do people out there use and/or recommend? It looks like the AST driver only supports 4-port cards, but it looks like it would be easy to add support for 8 ports ... or am I wrong? --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 00:10:39 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: may 19 sources: lpd does not compile From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu linking fails with the message: lpd.o: Undefined symbol ___ivaliduser referenced from text segment There is a _validuser() in libc/net/rcmd.c, which seems to fit the bill. The follwing patch allows a clean link. *** lpd.c Fri May 20 13:11:47 1994 --- lpd.c-orig Wed May 18 13:11:01 1994 *************** *** 478,484 **** hostf = fopen(_PATH_HOSTSEQUIV, "r"); again: if (hostf) { ! if (_validuser(hostf, f->sin_addr.s_addr, DUMMY, DUMMY) == 0) { (void) fclose(hostf); return; --- 478,484 ---- hostf = fopen(_PATH_HOSTSEQUIV, "r"); again: if (hostf) { ! if (__ivaliduser(hostf, f->sin_addr.s_addr, DUMMY, DUMMY) == 0) { (void) fclose(hostf); return; From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 00:43:21 1994 From: Olaf Seibert To: michaelv@iastate.edu, tls@panix.com Subject: Re: s/key and -current Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ty Sarna writes: >With these patches you can enter "s/key" at a {su,login} Password: >prompt and then be prompted for a s/key one-time password, or if you're >on a secure login you can just enter your regular password. Am I completely misunderstanding this, or would this imply that attackers still can do a brute-force attack on the regular password? -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 00:43:29 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: gcc -Wall From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there any interest and/or work being done in getting everything compile cleanly (or as cleanly as possible) with gcc -Wall? This can be done piecemeal so as to minimize impact on others. Another thing worth doing (IMHO) is ANSI C style function headers. A tool like cproto can be used to finish 99% of the work. Note that many commercial vendors (e.g. SGI) have already made their sources ANSI-C-hip. Goes a long way towards catching dumb mistakes upfront. I'd be more than happy to help out. Comments? Bakul Shah PS: along these lines: has anyone looked at using cproto as a starting point for a new lint? From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 02:16:28 1994 From: phil@cs.wwu.edu (Phil Nelson) To: current-users@sun-lamp.cs.berkeley.edu Subject: 8mm SCSI tape? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'd like to get some e-mail from anyone using an 8mm SCSI tape on NetBSD. I have some questions for you. --Phil From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 02:20:02 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: IBCS2 kernel changes. Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just wrote the kernel exec module to run i386 elf svr4 binaries. I can run *very* simple binaries right now, but there are a lot of system calls that need to be implemented. The programming task is very simple for most system calls, but time consuming. If you would like to help, and you have access to an svr4 x86 machine, drop me a note and I'll tell you where you can ftp the kernel changes from. christos From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 04:38:05 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: s/key and -current Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article <9405202110.AA26448@augustus.mbfys.kun.nl> Olaf Seibert writes: > Ty Sarna writes: > >With these patches you can enter "s/key" at a {su,login} Password: > >prompt and then be prompted for a s/key one-time password, or if you're > >on a secure login you can just enter your regular password. > > Am I completely misunderstanding this, or would this imply that > attackers still can do a brute-force attack on the regular password? Yes, they can still do that. For that matter, they can brute-force attack an S/Key secret password just as easily as your regular password -- the only difference is that they need a slightly smarter brute-force guesser program that knows to run guesses through key(1) with the appropriate challenge before trying them. S/Key doesn't try to solve the brute force problem, it only solves the problem of transmitting reusable passwords across insecure channels. An easily guessable S/Key password is just as dangerous as an easily-guessable normal password. -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 04:59:35 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Noel Cragg Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current as of 19 May <199405201100.HAA21712@cs.oberlin.edu> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I encountered a problems when building the current source because the > Makefile for sh didn't have libedit in its list of directories to > include. Also, I added a few #if statements to the code to get it to > work correctly for the version compiled with NO_HISTORY (specifically > in the arch/i386/floppy directory). Patches follow. Actually, you've got that problem because you didn't install libedit; libedit installed histedit.h. However, since, as you pointed out, a few more things can be omitted if NO_HISTORY is defined, i've bought back _those_ patches. later, chris From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 21 05:15:07 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: Bakul Shah Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: gcc -Wall <199405202100.OAA20331@netcom.com> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Is there any interest and/or work being done in getting everything > compile cleanly (or as cleanly as possible) with gcc -Wall? This > can be done piecemeal so as to minimize impact on others. actually, integrating 4.4-Lite utilities will deal with a fair amount of that. It's on "the list" of things to do. cgd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 02:19:14 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Donn Cave , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 23, 9:56am, Donn Cave wrote: > With May 22 sources the ordinary st driver was disabled and we were > building st from the main tree, with less than satisfactory results - what > was supposed to be mt status went out as something else, like a fsf or > something (thank heavens not a weof!) Kids don't try this at home. Nothing should have changed as far as the IOCTL calls from mt, since both the old Amiga st driver and the new scsi one used the same definitions (in sys/mtio.h). However, the interpretation of the minor number has changed. The Amiga driver expects the tape device to be defined as follows: /dev/rst0 minor number = 0 /dev/nrst0 minor number = 4 The new st driver expects the following: /dev/rst0 minor number = 0 /dev/nrst0 minor number = 1 If the existing /dev/nrst0 (minor number = 4) is used, the 4 is one of the density bits, so it will still rewind the tape device. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 02:23:14 1994 From: Donn Cave Subject: Re: help with A3000 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: 1695 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu |> With May 22 sources the ordinary st driver was disabled and we were |> building st from the main tree, with less than satisfactory results - what |> was supposed to be mt status went out as something else, like a fsf or |> something (thank heavens not a weof!) Kids don't try this at home. | | Nothing should have changed as far as the IOCTL calls from mt, since both | the old Amiga st driver and the new scsi one used the same definitions | (in sys/mtio.h). However, the interpretation of the minor number has changed. | | The Amiga driver expects the tape device to be defined as follows: | /dev/rst0 minor number = 0 | /dev/nrst0 minor number = 4 | | The new st driver expects the following: | /dev/rst0 minor number = 0 | /dev/nrst0 minor number = 1 | If the existing /dev/nrst0 (minor number = 4) is used, the 4 is one of the | density bits, so it will still rewind the tape device. All I'm going on is that the drive seemed to be doing tape motion, and I guess that could account for it, although since it was already at BOT I wouldn't have thought it would take so long. If the src/sys/scsi/st.c is what we're going to be using, I'll have a look at it if I get time. I have been meaning to look at st anyway, because it locks the system while doing tape motion, which probably isn't the desired effect. For example, type "mt -f /dev/nrst0 fsf 1". The SCSI LED goes on and stays on, the keyboard is 99% disabled, mouse disabled, etc. (I can get a few characters through to the keyboard, to show on the screen after the tape's through, but most of them are just dropped.) The drive is an Exabyte 8200; no problem with BTNtape. Donn Cave, donn@cac.washington.edu From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 25 02:58:21 1994 From: v17@dec5102.aarhues.dk (Michael Kofod) Subject: Re: Multiuser problem To: amiga@sun-lamp.cs.berkeley.edu (NetBSD Amiga-Maillist) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu markus@techfak.uni-bielefeld.de writes: > > On May 19, 12:39pm, Michael Kofod wrote: > > I have the loadbsd.730 and vmunix.744 kernel, the rootfs is version 720, > > and I installed the bin-*.940319.tar.gz from NetBSD-Amiga/bin-dist on > > /usr... My libcrypt.so.0.0 is from NetBSD-Amiga/bin-current.. > > And this is the problem... Your libcrypt doesn't include the crypt() > command - old US-export problem. I got an old libcrypt from a local guy and everything went well.. Now I have a problem with "read". It complains about a "Invalid Argument" when it tries to check for saved cores when I go multiuser.. > Get the libcrypt which is avail on either eunet or ftp.uni-regensburg.de I tried the one in bin-current and that didn't work (It was from ftp.luth.se) > > Is it btw: possible to binpatch the kernel to use DblNtsc on AGA instead > > of Ntsc? Or will I have to mess with the grf0.h? > > No. Yes, and more than that. Hmm.. And nobody have compiled a kernel that uses Productivity on ECS and AGA machines? I must admit that I'm not too thrilled about compiling my kernel yet :) /Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 03:04:04 1994 From: Arthur Hoffmann Subject: Patches for Emacs... anyone? 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: 523 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I was wondering if there are any patches for emacs around, so that I can compile it on my A3000NetBSD? I still have an old version installed and put binaries for X11 on as well (I found those ages ago on eunet) Anyway I was hoping I could compile the latest version (19.24) to get a clean installation that runs under X11 and supports help, apropos .... 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-x@sun-lamp.cs.berkeley.edu Wed May 25 03:06:40 1994 Subject: ECS color servers? From: David Jones To: amiga-x@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Maybe a month ago a "new" set of updated color ECS X servers were uploaded to ftp.eunet.ch. Well, there was a screw-up, and the old binaries were uploaded by mistake. Have the new servers been uploaded somewhere? If so, where? If you have xbsdcc2.gz and xbsdcc4.gz dated March 21, they are old and buggy. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto The Toronto Free-Net... paving the information superhighway. email: dej@eecg.toronto.edu, finger for latest Free-Net info/PGP public key From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 03:15:23 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: Hubert Feyrer Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: help with A3000 From: Jason Thorpe Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Tue, 24 May 1994 16:46:24 +0200 (MET DST) Hubert Feyrer wrote: > > We're having some problems with NetBSD/Amiga. The kernel from the binary > > shapshot boots, but then seems to hang after about 30 seconds after > > getting a shell, no matter what you doing. It works fine until then. > > Ideas? It's an A3000 with 4 Fast megs and 2 Chip megs. > > > > Also...does anyone have any info on the ASDG EB920 eithernet controller? > > There's currently not a driver for it, but we'll write one if someone has > > interfacing info... > > I guess you have that unsupported ethernet-card plugged in when you > get those errors? If so, that might be the cause for your crashes, > because if you initialize the card on the AmigaOD-side and then switch > over to NetBSD, the card's still initialized and expects certain > handlers to be present in RAM which surely aren't there when you run > NetBSD! > > So, to test the binaries you should remove the ethernet-card from your > amiga before re-trying (or even better: write a driver for it ;-) This was the problem. We're working on a driver now. In the mean time, we're trying to SLIP to a Sparc 1+ (that runs NetBSD and SunOS off and on...) Thanx... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 03:33:03 1994 From: Greg Oster Subject: Re: Patches for Emacs... anyone? To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: 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: 935 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Arthur Hoffmann writes: > > Hi, > I was wondering if there are any patches for emacs around, so that I > can compile it on my A3000NetBSD? You don't need any patches with 19.23. I just compiled it the other day, and it build like a charm. All I did was grab the source, did a: ./configure m68k-hp-netbsd --with-x11 and gave it a while to compile... (and it even compiled a shared-lib version!) > I still have an old version installed and put binaries for X11 on as > well (I found those ages ago on eunet) Anyway I was hoping I could > compile the latest version (19.24) to get a clean installation that ^^^^^ I believe 19.23 is the latest version, no? > runs under X11 and supports help, apropos .... I believe it supports all the bells and whistles... Later... Greg Oster oster@cs.usask.ca Department of Computational Science University of Saskatchewan, Saskatoon, Saskatchewan, CANADA From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:39:02 1994 From: Mark Townley To: current-users@sun-lamp.cs.berkeley.edu Subject: reading sunos disk label Sender: owner-current-users@sun-lamp.cs.berkeley.edu Can anyone tell me whether it's possible to read (and consequently mount) a SCSI disk label originally written under sunos 4.1.3 on NetBSD-current. Thanks alot Mark Townley Unix Systems Manager Praxis Systems 20 Manvers St Bath BA1 1PX England From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:39:03 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mark@praxis.co.uk Subject: Re: reading sunos disk label Sender: owner-current-users@sun-lamp.cs.berkeley.edu Can anyone tell me whether it's possible to read (and consequently mount) a SCSI disk label originally written under sunos 4.1.3 on NetBSD-current. NetBSD-current *on what architecture*? It should work fine for SPARCs, but not (currently) for anything else. From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:42:07 1994 From: "Robert L. Shady" Subject: /usr/include/curses.h To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 162 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a major problem, my curses.h file seems to just up and "disappear" quite often.. Anybody have any idea why, and what the fix is to get it back to normal? From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:44:11 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Strange packets on local ethernet Sender: owner-current-users@sun-lamp.cs.berkeley.edu My net config has a slip line from campus to home, with three NetBSD-currentish machines on the local side. I was playing with network protocols and used tcpdump to see what was going on today, and I happened upon some strange (at least to me) packets: 18:15:52.198994 0:d0:8e:95:0:0 2:0:0:0:45:0 4011 198: cf78 c685 c704 c685 c7ff 0201 0201 00bc f5f3 0101 0000 2de2 8aa8 0000 0000 7061 636b 7261 7400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0003 0000 0002 0000 0000 7667 6100 0000 0000 6578 706c 6f72 6572 2de2 4d27 0000 0000 7474 7970 3000 0000 6578 706c 6f72 6572 2de2 4e40 0000 056f 7474 7970 3100 0000 6578 706c 6f72 6572 2de2 5284 0000 000b 7474 7970 3200 0000 6578 706c 6f72 6572 2de2 7ae0 0000 016a 7474 7970 3500 0000 6578 706c 6f72 6572 2de2 6e48 0000 0461 18:18:52.919020 0:d0:8e:9e:0:0 2:0:0:0:45:0 4011 198: cf6f c685 c704 c685 c7ff 0201 0201 00bc f328 0101 0000 2de2 8b5c 0000 0000 7061 636b 7261 7400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0007 0000 0003 0000 0001 0000 0000 7667 6100 0000 0000 6578 706c 6f72 6572 2de2 4d27 0000 0000 7474 7970 3000 0000 6578 706c 6f72 6572 2de2 4e40 0000 0623 7474 7970 3100 0000 6578 706c 6f72 6572 2de2 5284 0000 0000 7474 7970 3200 0000 6578 706c 6f72 6572 2de2 7ae0 0000 021e 7474 7970 3500 0000 6578 706c 6f72 6572 2de2 6e48 0000 0515 18:18:55.890284 1:28:8e:a3:0:0 2:0:0:0:45:0 4011 286: cf12 c685 c704 c685 c7ff 020d 020d 0114 4bda 1801 d868 0a6f 7270 616c 2e63 7061 636b 7261 742e 766f 7270 616c 2e63 6f6d 0000 0700 0000 12bf 0010 6070 0110 0000 0710 c0d0 0110 18a3 0610 55da 0610 5fbf 0010 12bf 0010 6070 0110 0000 0710 c0d0 0110 78a9 0610 bcde 0610 5f70 0110 1000 0000 88d4 0610 507d 0610 789a 0610 c0d0 0110 0000 0000 3cda bff7 f1c2 0010 2803 0710 2803 0710 b41e 0610 6000 0710 2803 0710 ecdb bff7 789a 0610 3300 0000 afde 0610 c0d0 0110 6cda bff7 6cb0 0010 2803 0710 3300 0000 ecdb bff7 c8db bff7 6cda bff7 6cda bff7 6000 0710 94da bff7 6c6e 0710 88da bff7 8cda bff7 b41e 0610 7e88 0410 0100 0000 0000 0000 88da bff7 0000 0000 0000 0000 40df bff7 0000 0000 a0da bff7 1277 0000 0000 0000 0000 0000 Now, the real questions is, what the hell are these? I don't think the slip iface can route these to me (since it checks for AF_INET and rejects all others in the code) but I can't see where these would be coming from if not the slip link. Anyone else seeing this type of thing? Kinda scarry. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 03:46:28 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: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 24, 2:36pm, Donn Cave wrote: > I have been meaning to look at st anyway, because it locks the system while > doing tape motion, which probably isn't the desired effect. For example, > type "mt -f /dev/nrst0 fsf 1". The SCSI LED goes on and stays on, the > keyboard is 99% disabled, mouse disabled, etc. (I can get a few characters > through to the keyboard, to show on the screen after the tape's through, > but most of them are just dropped.) The drive is an Exabyte 8200; no > problem with BTNtape. It locks the system because none of the scsi drivers implement disconnect/reconnect. Nothing else can be done on the scsi bus until the current operation completes. Keyboard characters shouldn't be lost though. Oops, I just thought of something - I mentioned this to Chris Hopps when I saw it and didn't think that what he was doing was correct. The 33C93 driver (A3000, A2091, and GVP Series II) always uses the polled I/O when doing a non-data transfer. The driver is probably called at the slpbio() level, which is going to block the keyboard interrupts. I didn't do that with the 53C710 driver, so I don't see that problem. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:48:05 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: what happened to SIOCGARP SIOCSARP? Sender: owner-current-users@sun-lamp.cs.berkeley.edu pppd and bootpd need it.. christos From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 03:59:23 1994 From: hm@ernie.hcs.de (Hellmuth Michaelis) Subject: sh: warning: running as root with dot in PATH To: current-users@sun-lamp.cs.berkeley.edu (NetBSD-current Users) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 606 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since some days i get the message "sh: warning: running as root with dot in PATH" on every invocation of the sh - make world gets quite noisy ... Then i started to look: i don't have any dot in my root PATH !! It got sooo loud that i experimented - the message is triggered by 1) a double colon in PATH i.e.: /bin::/usr/bin and 2) a trailing colon in PATH i.e.: /bin:/usr/bin: My tree is dated May 22nd (+/- timezone). hellmuth -- Hellmuth Michaelis hm@ernie.hcs.de Prototypes are a crutch for the weak. (John F. Woods) From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 04:01:11 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: protect against multiple inclusion Sender: owner-current-users@sun-lamp.cs.berkeley.edu Otherwise inetd does not compile: *** wait.h.dist Sun May 22 06:39:13 1994 --- wait.h Tue May 24 17:39:03 1994 *************** *** 33,38 **** --- 33,40 ---- * from: @(#)wait.h 8.1 (Berkeley) 6/2/93 * $Id: wait.h,v 1.5 1994/05/21 03:52:24 cgd Exp $ */ + #ifndef _SYS_WAIT_H_ + #define _SYS_WAIT_H_ /* * This file holds definitions relevent to the wait4 system call *************** *** 154,157 **** --- 156,160 ---- pid_t wait4 __P((pid_t, int *, int, struct rusage *)); #endif __END_DECLS + #endif #endif From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 04:05:39 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: bug in rlogind.c Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just found a horrible bug in rlogind.c: ruserok() now calls gethostbyname(host) with "host" passed from rlogind.c This "host" can be the result of a hp = gethostbyaddr() call and it is really host == hp->h_name! When that happens, and we have a /etc/hosts lookup the same local buffer (hostbuf) from gethostnameaddr.c is used to place the result, and hp->h_name is now trashed! The following fix, simplifies the code too, since remotehost is used to keep the remote host name or stringified address! I have not checked any other programs that user ruserok(), but someone should. Maybe it is worth copying the buffer one extra time in ruserok(), to make sure that it is not being passed hp->h_name... christos *** rlogind.c.dist Fri May 20 06:27:27 1994 --- rlogind.c Tue May 24 12:21:05 1994 *************** *** 195,201 **** int authenticated = 0, hostok = 0; register struct hostent *hp; char remotehost[2 * MAXHOSTNAMELEN + 1]; - struct hostent hostent; char c; alarm(60); --- 195,200 ---- *************** *** 213,223 **** hp = gethostbyaddr((char *)&fromp->sin_addr, sizeof(struct in_addr), fromp->sin_family); if (hp == 0) { ! /* ! * Only the name is used below. ! */ ! hp = &hostent; ! hp->h_name = inet_ntoa(fromp->sin_addr); hostok++; } else if (check_all || local_domain(hp->h_name)) { /* --- 212,218 ---- hp = gethostbyaddr((char *)&fromp->sin_addr, sizeof(struct in_addr), fromp->sin_family); if (hp == 0) { ! strcpy(remotehost, inet_ntoa(fromp->sin_addr)); hostok++; } else if (check_all || local_domain(hp->h_name)) { /* *************** *** 233,249 **** for (; hp->h_addr_list[0]; hp->h_addr_list++) if (!bcmp(hp->h_addr_list[0], (caddr_t)&fromp->sin_addr, sizeof(fromp->sin_addr))) { hostok++; break; } ! } else hostok++; #ifdef KERBEROS if (use_kerberos) { if (!hostok) fatal(f, "rlogind: Host address mismatch.", 0); ! retval = do_krb_login(hp->h_name, fromp); if (retval == 0) authenticated++; else if (retval > 0) --- 228,247 ---- for (; hp->h_addr_list[0]; hp->h_addr_list++) if (!bcmp(hp->h_addr_list[0], (caddr_t)&fromp->sin_addr, sizeof(fromp->sin_addr))) { + strcpy(remotehost, hp->h_name); hostok++; break; } ! } else { ! strcpy(remotehost, hp->h_name); hostok++; + } #ifdef KERBEROS if (use_kerberos) { if (!hostok) fatal(f, "rlogind: Host address mismatch.", 0); ! retval = do_krb_login(remotehost, fromp); if (retval == 0) authenticated++; else if (retval > 0) *************** *** 287,293 **** } } #endif ! if (do_rlogin(hp->h_name) == 0 && hostok) authenticated++; } if (confirmed == 0) { --- 285,291 ---- } } #endif ! if (do_rlogin(remotehost) == 0 && hostok) authenticated++; } if (confirmed == 0) { *************** *** 324,337 **** syslog(LOG_INFO|LOG_AUTH, "ROOT Kerberos login from %s.%s@%s on %s\n", kdata->pname, kdata->pinst, kdata->prealm, ! hp->h_name); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, "-f", lusername, 0); } else execl(_PATH_LOGIN, "login", "-p", ! "-h", hp->h_name, lusername, 0); fatal(STDERR_FILENO, _PATH_LOGIN, 1); /*NOTREACHED*/ } --- 322,335 ---- syslog(LOG_INFO|LOG_AUTH, "ROOT Kerberos login from %s.%s@%s on %s\n", kdata->pname, kdata->pinst, kdata->prealm, ! remotehost); #endif execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, "-f", lusername, 0); } else execl(_PATH_LOGIN, "login", "-p", ! "-h", remotehost, lusername, 0); fatal(STDERR_FILENO, _PATH_LOGIN, 1); /*NOTREACHED*/ } From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 04:21:56 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, christos@deshaw.com Subject: Re: what happened to SIOCGARP SIOCSARP? X-Sun-Charset: US-ASCII Content-Length: 645 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > pppd and bootpd need it.. > > christos > I ran into this too...a couple of other things barfed on this too... I looked all over, it isn't like a missing include, they aren't defined anywhere. Also, files.i386 is missing conf.c, no conf.o gives a *ton* of link errors. Adding it and rerunning config (I did rebuild config) solves the problem. Also, is not idempotent. This hits in compiling src/usr.sbin/inetd.c. The includes in inetd.c look kind of hokey (it inlcudes 10 or so files, does a #define RPC, and then includes them again) but (everything in /usr/include IMHO) should be idempotent anyway. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 04:25:31 1994 From: gregc@edi.com (Greg Cronau) Subject: 1542C 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: 248 Sender: owner-current-users@sun-lamp.cs.berkeley.edu We're thinking of setting up -current at work. I seem to remember somebody saying they had problems with an Adaptec 1542C board awhile back. What's the status of this board? Does it work ok now, or are there still Problems? Thanks Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 04:46:13 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: rlogind bug revisited... Sender: owner-current-users@sun-lamp.cs.berkeley.edu If you did not understand the previous message, here's some code that demonstrates the problem. christos #include #include #include #include main(argc, argv) int argc; char *argv[]; { struct hostent *hp; hp = gethostbyname(argv[1]); if (hp == NULL) { herror("gethostbyname 1"); return 1; } hp = gethostbyaddr((char*) &hp->h_addr[0], 4, AF_INET); if (hp == NULL) { herror("gethostbyaddr"); return 1; } hp = gethostbyname(hp->h_name); if (hp == NULL) { herror("gethostbyname 2"); return 1; } return 0; } From owner-amiga@sun-lamp.cs.berkeley.edu Wed May 25 05:49:37 1994 From: marc@offline.be (Marc Duponcheel) Subject: X bootstrap To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 830 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Thanks everybody who helped me to setup NetBSD I am stuck now with X ... I got the 1May94 files and installed them. (the X server is called Xamiga+retina or something) I read the X faq and when I now run startx or xinit the system says: /dev/grf1 No such file or directory trying "/dev /view00"...failed. xopen_view(): No such file or directory The FAQ talks about 'configuring the graphical display' but I don't know what that means. For completeness: I *can* ping localhost I have set DISPLAY I have set PATH I have done ldconfig I did not find a global xinitrc so I made an empty one (I don't think this matters here, the problem seems to be more fundamantal). CONGRATULATIONS again NetBSD-Amiga folks ! and ... thanks for any help ! -- marc. email marc@offline.be [= me@home] fido 2:292/603.26 [= me@home] From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 06:44:01 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: Mark Townley Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: reading sunos disk label From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 24 May 94 22:52:28 +0100 Mark Townley wrote: > > Can anyone tell me whether it's possible to read (and consequently mount) > a SCSI disk label originally written under sunos 4.1.3 on NetBSD-current. Well, as far as I know, the sparc port just uses SunOS disklabels. At least, my Sparc does...:-) > > Thanks alot > > Mark Townley > > Unix Systems Manager > Praxis Systems > 20 Manvers St > Bath > BA1 1PX > England > ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 07:37:26 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: gregc@edi.com (Greg Cronau) Subject: Re: 1542C Cc: current-users@sun-lamp.cs.berkeley.edu From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >We're thinking of setting up -current at work. I seem to remember somebody >saying they had problems with an Adaptec 1542C board awhile back. What's >the status of this board? Does it work ok now, or are there still Problems? Works for me -- now. I did have some oddities at one point however. It was a mix of a ``bad'' external CPU cache (which works now) and a ``bad'' controller termination resister (replaced it) Just be sure the 1542C was repaired -- it should have a little capicator soldered near the external scsi connector. If not, call Adaptec. --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 Wed May 25 09:05:03 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: sh: warning: running as root with dot in PATH To: hm@hcswork.hcs.de 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: 568 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Then i started to look: i don't have any dot in my root PATH !! > > It got sooo loud that i experimented - the message is triggered by > > 1) a double colon in PATH i.e.: /bin::/usr/bin and > 2) a trailing colon in PATH i.e.: /bin:/usr/bin: The message is misleading, but the warning is warranted. A leading, trailing, or double colon in $PATH is equivalent to having a dot there. And root user's should _never_ have a dot in their path since you never know if a user is going to put a trojan "ls" somewhere where you will inadvertantly run it. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 09:49:14 1994 From: (This is my bacque pas, this is my faux pas) 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: 3145 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: Jason Thorpe , Mark Townley Subject: Re: reading sunos disk label Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could the NetBSD label perhaps be put at a different offset than the SunOS label, and the SunOS label be translated concurrently? Something to make the DKIOSLABEL stuff work so that things like "newfs" and "disklabel" work... Just a thought. -- Make a hacker happy. Use a *real* OS. ________ _____ ____ ________ _____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 Just because memory, disk and cpu speed are cheap is no excuse for shoddy programming. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 12:27:00 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: help with A3000" (May 24, 4:46pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 24, 4:46pm, Hubert Feyrer wrote: > get those errors? If so, that might be the cause for your crashes, > because if you initialize the card on the AmigaOD-side and then switch > over to NetBSD, the card's still initialized and expects certain > handlers to be present in RAM which surely aren't there when you run > NetBSD! Not entirely true. The problem is, that a once initilized card such as Ethernet, Arcnet or even several gfx-boards are sending interrupts, which NetBSD cannot evoluate and then just hangs. Possible workarounds: Don't start network on ADos when you know you will start NetBSD. Don't forget to rename nipc.library if you run (or don't run, but have it present) Envoy and ToolManager. If the network is still working when you start NetBSD, then just don't stop the remote machines, while you run NetBSD. Final workaround: The kernel needs to reset every possible card or needs to be poloished to work with non-identified interrupts. > So, to test the binaries you should remove the ethernet-card from your > amiga before re-trying (or even better: write a driver for it ;-) No need to remove. Just don't initialize the card with ifconfig on ADos-side. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 12:29:03 1994 From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Subject: New kernels and DAT drive and other things To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 5703 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Howdy all, Well, it seems my DAT problems have been solved (or will be solved once the new stuff is stable :). Using a rather recent kernel (many thanks to Michael Hitch, who was so friendly to provide one), my system got along just fine past the SCSI detection phase (and recognised the DAT drive as a tape device and even mentioned it's density code (0x13?)), so I'm quite confident the new SCSI stuff will work OK. BTW, these newer kernels do look a lot more 'professional' than the old ones. All those ztwobus, zthreebus, etc messages look pretty impressive. ;-) But, do they have any relevance to underlying changes/mechanisms? :) I did have another problem; I got a message sounding something like: warning: nsectors (820 ) != nheads (10) * sectorspertrack (83) After that it also printed something about dostypes being depreciated and suggested other values (I guess that's because my partitions are still marked with the BSD? dostypes), printed a "could not find root" and subsequently paniced and went into the boot-monitor. In there I typed c(ontinue). It then rebooted, which I suppose is meant to happen. I could spot something like "dumping ..." before the screen went black, but I'm not sure; the screen blanks too fast for me to read it. Since I found the "nsectors != whatever" message always a bit scary and because something looking like this also popped up under all previous kernels when I mounted the mfs /tmp filesystem, I set forth to fix this message (hoping it would fix the panic). The tool I ended up using, after some experimentation (with little luck) with HDToolBox, was RDPrep. For those interested, I'll describe the procedure: **** If you try this, you do this on your own risk. It worked for me, but it won't necessary work for you. I.e., if you nuke your HD, data, whatever I'm not responsible. (Phew! :) **** Start up RDPrep, choose your harddrive if necessary, click "Read RDB", then click "Save Mountfile" and choose a destination. Anything should do, although a Rescue-type floppy would be rather handy. Also, don't forget to put RDPrep on this floppy, together with some other DiskRepair-type programs. (Just in case...) After that, click RDPrep to the back (or exit it), and make a safety copy of the file you just wrote (probably called "000.list"). Next, edit a copy of the file "000.list", which is just a plain textfile, with your favourite text-editor. In my case, I changed the value for BlocksPerTrack from 83 to 82 and then saved it. (The 820 number is what all prep-like programs seemed to use; it's the 10*83=830!=820 number that produced the warnings and errors. Probably a fluke of HDToolBox(?)). Next, restart RDPrep if necessary, click "Load Mountfile" to load the mountfile you've just modified into RDPrep. Next, check (in the other RDPrep screens) everything is still allright _VERY_ carefully (Are partitions the right size? Are the BlockPerTrack/Cylinder values OK? Etc, etc.), and when you're convinced everything looks 100% okey-dokey, click "Save RDB" to write it to your HD. Next, reboot and keep your fingers crossed. If all comes up just fine, you're all set and your troubles (and warnings from NetBSD) should be over. If the system doesn't come up; scream, get the earlier made emergency floppy, boot from floppy (a workbench floppy will do), start up RDPrep, reload your original MountFile (you did keep a copy, didn't you?), and write that one back to your HD. After a reboot all should be fine again and you can retry the procedure (if you dare :). Anyhow, after I fixed this, the new kernel continued just fine and presented me with a single user prompt. Typing "ls -l" and some other trivial (static) programs still worked OK (excluding of course ps and friends). However, after mounting /usr, I tried some shared binaries but then I got "could not map ld.so" or something to that effect and, of course, these programs didn't work. I guess my binaries are too old. What should I do now? The kernel looks pretty stable (is it Michael? :), but I definately need new binaries... What I'm also wondering about is, how do I do that? What should I build first? A new ld.so? Something else? Any hints and/or tips would be appreciated. And, what would 'supping' gain me over getting the .tar.gz snapshots from a sun-lamp mirror? While I'm on the question-asking tour, what is the status of the memory management changes that were suggested quite a while ago? I have the feeling NetBSD-Amiga is still far from usable in 4megs of RAM (and I mean this with regard to console-only stuff). Even with 8megs (which I have) I find memory still rather tight. Of course, I should just plunk in another 8megs and be done with it, but I find that a rather silly solution. :) Also, I can remember the '040 support consisted of setting up a complete level-[123] (?) page-table of about 60KB for every process started. Is this still the case? If so, that would explain why I have so little memory left after booting into multi-user mode. (I have 8 meg, but it leaves me, according to vmstat, with about 300/400KB of free memory. Of course stuff gets swapped out after a while.) Are there any plans to fix this? Is it even fixable or is it a 'feature'? After trying Linux/68k a while back, I couldn't help notice that their console is much (MUCH) faster than NetBSD-Amiga's console, due to which it, on the whole, just 'feels' (a lot) faster than NetBSD-Amiga. Is there any chance the NetBSD-Amiga console could get any faster? Also, Linux/68k has support for some neat (AGA?) modes (720x400@70Hz NI, 640x400@76Hz NI, etc). Could the implementation of these be of any help to NetBSD-Amiga? Well, that's it for now. Regards, Patrick. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed May 25 12:50:50 1994 X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: netbsd-users@sun-lamp.cs.berkeley.edu From: kallio@jyu.fi (Seppo Kallio) Subject: sup + kernel compiling Cc: cgd@postgres.berkeley.edu Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi I got file 'releases' from sun-lamp - it seems like sup control file allsrc list=3Dlist/allsrc scan=3Dscan/allsrc prefix= =3D/b/anon_f tp/pub/NetBSD/NetBSD-current doc list=3Dlist/doc scan=3Dscan/doc prefix= =3D/b/anon_f tp/pub/NetBSD/NetBSD-current games list=3Dlist/games scan=3Dscan/games prefix= =3D/b/anon_f tp/pub/NetBSD/NetBSD-current gnu list=3Dlist/gnu scan=3Dscan/gnu prefix= =3D/b/anon_f tp/pub/NetBSD/NetBSD-current include list=3Dlist/include scan=3Dscan/include prefix= =3D/b/anon_f tp/pub/NetBSD/NetBSD-current ksrc list=3Dlist/ksrc scan=3Dscan/ksrc prefix= =3D/b/anon_f But my sup (version 8.26) is complaining SUP: Invalid supfile option list for collection allsrc SUP: Invalid supfile option list for collection doc SUP: Invalid supfile option list for collection games SUP: Invalid supfile option list for collection gnu SUP: Invalid supfile option list for collection include SUP: Invalid supfile option list for collection ksrc 1. Is that file for sup (to be used with command % sup -v releases)? 2. Or is my sup too old? 3. Where is the current sup? Seppo From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 13:32:46 1994 X-Authentication-Warning: oink.home: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: modload/modunload From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu are there any examples on how to use the modload/modunload stuff? thanks. From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 14:08:38 1994 From: "Chris G. Demetriou" To: current-users@sun-lamp.cs.berkeley.edu Subject: me, and the next couple of weeks... Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm going to be completely out of touch (eek!) for the next couple of weeks; if you send me mail in that time, don't expect a response until June 15, or so, at the earliest... In general, if i can do it, 'core' probably can, but some of you tend to ask me random questions, etc., and those might not be 'appropriate' to send to core. send them to 'glass'. (HI ADAM! 8-) thanks, chris From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed May 25 15:51:07 1994 From: Ronald G Minnich Subject: Re: sup + kernel compiling To: Seppo Kallio Cc: netbsd-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Your sup file looks like an old one of mine that got the same errors. Here's my latest one that has been working. current release=allsrc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp \\ base=/usr/public/src/netbsd prefix=/usr/public/src/netbsd old delete \\ use-rel-suffix (NOTE the \\ should not be there, it has to be one line) ron rminnich@super.org | The net is for free speech, but advertising? (301)-805-7451 or 7312 | Why not embargo host machines that distribute ads? | (i.e. refuse to accept/deliver traffic to them) From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 17:58:44 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 doc/CHANGES U src/etc/Makefile U src/games/trek/Makefile U src/games/trek/main.c U src/gnu/usr.bin/gdb/gdb/arch/ns32k/ns32k-tdep.c U src/gnu/usr.bin/ld/rtld/rtld.c U src/include/link.h U src/include/locale.h U src/include/rpcsvc/yp_prot.h U src/include/rpcsvc/ypclnt.h U src/lib/Makefile U src/lib/csu/mips/Makefile U src/lib/csu/mips/crt0.s U src/lib/libc/arch/mips/:errfix U src/lib/libc/arch/mips/Makefile.inc U src/lib/libc/arch/mips/SYS.h U src/lib/libc/arch/mips/gen/_setjmp.s U src/lib/libc/arch/mips/gen/fabs.s U src/lib/libc/arch/mips/gen/frexp.c U src/lib/libc/arch/mips/gen/isinf.s U src/lib/libc/arch/mips/gen/ldexp.s U src/lib/libc/arch/mips/gen/modf.s U src/lib/libc/arch/mips/gen/setjmp.s U src/lib/libc/arch/mips/net/htonl.s U src/lib/libc/arch/mips/net/htons.s U src/lib/libc/arch/mips/string/bcmp.s U src/lib/libc/arch/mips/string/bcopy.s U src/lib/libc/arch/mips/string/bzero.s U src/lib/libc/arch/mips/string/ffs.s U src/lib/libc/arch/mips/string/index.s U src/lib/libc/arch/mips/string/rindex.s U src/lib/libc/arch/mips/string/strcmp.s U src/lib/libc/arch/mips/string/strlen.s U src/lib/libc/arch/mips/sys/Ovfork.s U src/lib/libc/arch/mips/sys/brk.s U src/lib/libc/arch/mips/sys/cerror.s U src/lib/libc/arch/mips/sys/exect.s U src/lib/libc/arch/mips/sys/fork.s U src/lib/libc/arch/mips/sys/pipe.s U src/lib/libc/arch/mips/sys/ptrace.s U src/lib/libc/arch/mips/sys/reboot.s U src/lib/libc/arch/mips/sys/sbrk.s U src/lib/libc/arch/mips/sys/setlogin.s U src/lib/libc/arch/mips/sys/sigpending.s U src/lib/libc/arch/mips/sys/sigprocmask.s U src/lib/libc/arch/mips/sys/sigreturn.s U src/lib/libc/arch/mips/sys/sigsuspend.s U src/lib/libc/arch/mips/sys/syscall.s U src/lib/libc/gen/setproctitle.c U src/lib/libc/locale/Makefile.inc U src/lib/libc/locale/_def_monetary.c U src/lib/libc/locale/_def_numeric.c U src/lib/libc/locale/_def_time.c U src/lib/libc/locale/localeconv.c U src/lib/libc/string/strftime.c U src/lib/libc/yp/xdryp.c U src/lib/libc/yp/yplib.c U src/lib/libkvm/kvm_proc.c U src/lib/libskey/skeysubr.c U src/libexec/bootpd/Announce-2.1 U src/libexec/bootpd/Announce-2.2 U src/libexec/bootpd/Announce-2.3 U src/libexec/bootpd/ConvOldTab.sh U src/libexec/bootpd/Installation U src/libexec/bootpd/Makefile U src/libexec/bootpd/Problems U src/libexec/bootpd/README U src/libexec/bootpd/bootp.h U src/libexec/bootpd/bootpd.8 U src/libexec/bootpd/bootpd.c U src/libexec/bootpd/bootpd.h U src/libexec/bootpd/bootpef.8 U src/libexec/bootpd/bootpef.c U src/libexec/bootpd/bootpgw.c U src/libexec/bootpd/bootptab.5 U src/libexec/bootpd/bootptab.cmu U src/libexec/bootpd/bootptab.mcs U src/libexec/bootpd/bootptest.8 U src/libexec/bootpd/bootptest.c U src/libexec/bootpd/bootptest.h U src/libexec/bootpd/bptypes.h U src/libexec/bootpd/dovend.c U src/libexec/bootpd/dovend.h U src/libexec/bootpd/dumptab.c U src/libexec/bootpd/getether.c U src/libexec/bootpd/getif.c U src/libexec/bootpd/getif.h U src/libexec/bootpd/hash.c U src/libexec/bootpd/hash.h U src/libexec/bootpd/hwaddr.c U src/libexec/bootpd/hwaddr.h U src/libexec/bootpd/lookup.c U src/libexec/bootpd/lookup.h U src/libexec/bootpd/patchlevel.h U src/libexec/bootpd/print-bootp.c U src/libexec/bootpd/readfile.c U src/libexec/bootpd/readfile.h U src/libexec/bootpd/report.c U src/libexec/bootpd/report.h U src/libexec/bootpd/syslog.conf U src/libexec/bootpd/syslog.h U src/libexec/bootpd/trygetea.c U src/libexec/bootpd/trygetif.c U src/libexec/bootpd/trylook.c U src/libexec/bootpd/tzone.c U src/libexec/bootpd/tzone.h U src/libexec/ftpd/Makefile U src/libexec/ftpd/ftpd.8 U src/libexec/ftpd/ftpd.c U src/share/man/man5/a.out.5 U src/share/mk/bsd.prog.mk U src/sys/adosfs/advnops.c U src/sys/arch/amiga/amiga/amiga_init.c U src/sys/arch/amiga/amiga/genassym.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/amiga/mem.c U src/sys/arch/amiga/amiga/pmap.c U src/sys/arch/amiga/amiga/trap.c U src/sys/arch/amiga/amiga/vm_machdep.c U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/dev/ite_cc.c U src/sys/arch/amiga/include/cpu.h U src/sys/arch/amiga/include/pmap.h U src/sys/arch/hp300/conf/files.hp300 U src/sys/arch/hp300/dev/device.h U src/sys/arch/hp300/dev/grf.c U src/sys/arch/hp300/dev/grf_conf.c U src/sys/arch/hp300/dev/grf_dv.c U src/sys/arch/hp300/dev/grf_dvreg.h U src/sys/arch/hp300/dev/grf_gb.c U src/sys/arch/hp300/dev/grf_gbreg.h U src/sys/arch/hp300/dev/grf_hy.c U src/sys/arch/hp300/dev/grf_hyreg.h U src/sys/arch/hp300/dev/grf_machdep.c U src/sys/arch/hp300/dev/grf_rb.c U src/sys/arch/hp300/dev/grf_rbreg.h U src/sys/arch/hp300/dev/grf_tc.c U src/sys/arch/hp300/dev/grf_tcreg.h U src/sys/arch/hp300/dev/grfioctl.h U src/sys/arch/hp300/dev/grfreg.h U src/sys/arch/hp300/dev/grfvar.h U src/sys/arch/hp300/dev/hil.c U src/sys/arch/hp300/dev/hil_keymaps.c U src/sys/arch/hp300/dev/hilioctl.h U src/sys/arch/hp300/dev/hilreg.h U src/sys/arch/hp300/dev/hilvar.h U src/sys/arch/hp300/dev/ite.c U src/sys/arch/hp300/dev/ite_dv.c U src/sys/arch/hp300/dev/ite_gb.c U src/sys/arch/hp300/dev/ite_hy.c U src/sys/arch/hp300/dev/ite_rb.c U src/sys/arch/hp300/dev/ite_subr.c U src/sys/arch/hp300/dev/ite_tc.c U src/sys/arch/hp300/dev/itereg.h U src/sys/arch/hp300/dev/itevar.h U src/sys/arch/hp300/dev/kbdmap.h U src/sys/arch/hp300/dev/ppi.c U src/sys/arch/hp300/dev/ppiioctl.h U src/sys/arch/hp300/hp300/autoconf.c U src/sys/arch/hp300/hp300/copy.s U src/sys/arch/hp300/hp300/locore.s U src/sys/arch/hp300/hpux/hpux_compat.c U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/i386/genassym.c U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/i386/mem.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/i386/include/cputypes.h U src/sys/arch/i386/include/specialreg.h U src/sys/arch/i386/include/types.h U src/sys/arch/i386/isa/bt742a.c U src/sys/arch/i386/isa/cy.c U src/sys/arch/i386/isa/if_ed.c U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/spkr.c U src/sys/arch/pc532/conf/GENERIC_O U src/sys/arch/pc532/conf/GENERIC_OF U src/sys/arch/pc532/conf/GENERIC_RD U src/sys/arch/pc532/conf/GENERIC_Z U src/sys/arch/pc532/conf/GENERIC_ZF U src/sys/arch/pc532/conf/STEELHEAD U src/sys/arch/pc532/include/ansi.h U src/sys/arch/pc532/include/cpu.h U src/sys/arch/pc532/include/pcb.h U src/sys/arch/pc532/include/types.h U src/sys/arch/pc532/pc532/conf.c U src/sys/arch/pc532/pc532/genassym.c U src/sys/arch/pc532/pc532/machdep.c U src/sys/arch/pc532/pc532/mem.c U src/sys/arch/pc532/pc532/pmap.c U src/sys/arch/pc532/pc532/trap.c U src/sys/arch/pc532/pc532/vm_machdep.c U src/sys/arch/sparc/include/ansi.h U src/sys/arch/sparc/include/pmap.h U src/sys/arch/sparc/include/types.h U src/sys/arch/sparc/sparc/machdep.c U src/sys/arch/sparc/sparc/vm_machdep.c U src/sys/arch/sun3/include/pcb.h U src/sys/arch/sun3/include/varargs.h U src/sys/arch/sun3/sun3/genassym.c U src/sys/compat/sunos/sun_misc.c U src/sys/compat/svr4/svr4_misc.c U src/sys/dev/vn.c U src/sys/isofs/isofs_vnops.c U src/sys/kern/exec_script.c U src/sys/kern/kern_acct.c U src/sys/kern/kern_exec.c U src/sys/kern/kern_sig.c U src/sys/kern/subr_rmap.c U src/sys/kern/sysv_ipc.c U src/sys/kern/sysv_msg.c U src/sys/kern/sysv_sem.c U src/sys/kern/sysv_shm.c U src/sys/kern/tty.c U src/sys/kern/tty_subr.c U src/sys/miscfs/specfs/spec_vnops.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/net/if_ppp.c U src/sys/nfs/nfs_bio.c U src/sys/nfs/nfs_socket.c U src/sys/sys/cdefs.h U src/sys/sys/core.h U src/sys/sys/disklabel.h U src/sys/sys/ipc.h U src/sys/sys/map.h U src/sys/sys/param.h U src/sys/sys/shm.h U src/sys/sys/stat.h U src/sys/sys/tty.h U src/sys/ufs/ufs_vfsops.c U src/sys/ufs/ufs_vnops.c U src/sys/vm/vm_unix.c U src/sys/vm/vnode_pager.c U src/usr.bin/Makefile U src/usr.bin/login/Makefile U src/usr.bin/login/login.1 U src/usr.bin/login/login.c U src/usr.bin/skey/Makefile U src/usr.bin/skey/key.1 U src/usr.bin/skey/keyaudit U src/usr.bin/skey/keyinfo U src/usr.bin/skey/skey.1 U src/usr.bin/skey/skey.c U src/usr.bin/skeyinit/Makefile U src/usr.bin/skeyinit/skeyinit.1 U src/usr.bin/skeyinit/skeyinit.c U src/usr.bin/su/Makefile U src/usr.bin/su/su.1 U src/usr.bin/su/su.c U src/usr.bin/ypcat/ypcat.c U src/usr.bin/ypmatch/ypmatch.c U src/usr.bin/ypwhich/ypwhich.c U src/usr.sbin/inetd/inetd.c U src/usr.sbin/ypbind/ypbind.c U src/usr.sbin/yppoll/yppoll.c U src/usr.sbin/ypset/ypset.c Running the SUP scanner: SUP Scan for current starting at Wed May 25 05:59:40 1994 SUP Scan for current completed at Wed May 25 06:03:36 1994 SUP Scan for mirror starting at Wed May 25 06:03:36 1994 SUP Scan for mirror completed at Wed May 25 06:07:34 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 18:43:32 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: New kernels and DAT drive and other things Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 25, 11:24am, Patrick Vervoorn wrote: > What should I do now? The kernel looks pretty stable (is it Michael? :), > but I definately need new binaries... What I'm also wondering about is, how > do I do that? What should I build first? A new ld.so? Something else? Any > hints and/or tips would be appreciated. I have been able to binpatch the the kernel enough to get it to run with the older binaries. If anyone is interested in the patches required, I can probably write something up what needs to be patched. This would allow people to use the new kernel with the old binaries until a new binary distribution is available. > And, what would 'supping' gain me over getting the .tar.gz snapshots from a > sun-lamp mirror? Supping allows you to get only the new files that have changed since the last sup, instead of having to ftp the entire tar file(s). If you're updating infrequently, the tar files are probably ok, but if you want to keep real up to date frequently, the supping is more efficient. Also, the tar snapshots are weekly, so if you get a snapshot what won't compile, you either have to fix it yourself, get the required changed files individually, or wait for the next week's snapshot (and hope that it's not broken). One other advantage of supping the kernel changes is that you don't need to get all the other architecture-dependent files. > While I'm on the question-asking tour, what is the status of the memory > management changes that were suggested quite a while ago? I have the > feeling NetBSD-Amiga is still far from usable in 4megs of RAM (and I mean > this with regard to console-only stuff). Even with 8megs (which I have) I > find memory still rather tight. Of course, I should just plunk in another > 8megs and be done with it, but I find that a rather silly solution. :) I put a little fix in that reduces the number of kernel page table pages allocated, but it only does that on systems with 4MB or less. I had thought about doing it for 8MB or less. The fix allows 4MB systems to run in configurations where they wouldn't run before the fix. I don't know if the fix will help 8MB systems that much, but it's very easy to change. > Also, I can remember the '040 support consisted of setting up a complete > level-[123] (?) page-table of about 60KB for every process started. Is this > still the case? If so, that would explain why I have so little memory left > after booting into multi-user mode. (I have 8 meg, but it leaves me, > according to vmstat, with about 300/400KB of free memory. Of course stuff > gets swapped out after a while.) Are there any plans to fix this? Is it > even fixable or is it a 'feature'? It's fixable, but a real fix would require some significant rewriting of the pmap and amiga_init code that I haven't had to time (or ambition) to do yet. The hp300 port has some changes that will help, but that code has just been put into the -current source tree very recently. I hope to take a look at it and see if I can add those changes to the Amiga stuff. > After trying Linux/68k a while back, I couldn't help notice that their > console is much (MUCH) faster than NetBSD-Amiga's console, due to which it, > on the whole, just 'feels' (a lot) faster than NetBSD-Amiga. Is there any > chance the NetBSD-Amiga console could get any faster? Also, Linux/68k has > support for some neat (AGA?) modes (720x400@70Hz NI, 640x400@76Hz NI, etc). > Could the implementation of these be of any help to NetBSD-Amiga? The Amiga console was much faster before Chris Hopps rewrote the console stuff to use views. The trick is to have a copper entry for each line of text, so when you need to scroll the screen, you just update the copper list instead of having to copy all the bitplanes. The Amiga Minix console was done that way and after I fine-tuned it a bit, it would scroll stuff so fast on my 68040 system that it was hard to see what was being output. I'd love to add some AGA modes, but I don't have a monitor that will accept any of the them. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 19:32:42 1994 From: rhealey@aggregate.com Subject: Re: New kernels and DAT drive and other things To: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Cc: amiga-dev@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: 7489 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Well, it seems my DAT problems have been solved (or will be solved once the > new stuff is stable :). Using a rather recent kernel (many thanks to > Michael Hitch, who was so friendly to provide one), my system got along > just fine past the SCSI detection phase (and recognised the DAT drive as a > tape device and even mentioned it's density code (0x13?)), so I'm quite > confident the new SCSI stuff will work OK. > Ya, I had to add an entry to st.c for my C= 3070 CALIPER tape, always burps out illegal request when you first do an open but otherwise it works, no more read errors when untaring the 90M sup tree from work! Now, all we have to do is retrofit the rest of the Amiga port to all the changes in VM and core files in the past day or two. B^(. pmap_bootstrap_alloc() needs to be written in pmap.c and vm_machdep.c needs a cpu_swapin() and new core file format changes; sigh. And OF COURSE cdg is incommunicado for a few weeks;eeek! > BTW, these newer kernels do look a lot more 'professional' than the old > ones. All those ztwobus, zthreebus, etc messages look pretty impressive. > ;-) But, do they have any relevance to underlying changes/mechanisms? :) > Yes, once you understand the profound meaning of the messages the new config system is mearly confusing as opposed to completly incomprehencable... B^). > I did have another problem; I got a message sounding something like: > warning: nsectors (820 ) != nheads (10) * sectorspertrack (83) > This is the result of a bad assumption in disksubr.c, for the line that sets lp->secpercyl you need to assign rdb->secpercyl to it rather than nheads * nsecpertrk. I hope to send Chris fixes later today. I REALLY messed up my NetBSD setup last night/this morning with the May 23rd sup; B^(... > After that it also printed something about dostypes being depreciated and > suggested other values (I guess that's because my partitions are still > marked with the BSD? dostypes), printed a "could not find root" and > subsequently paniced and went into the boot-monitor. In there I typed > c(ontinue). It then rebooted, which I suppose is meant to happen. I could > spot something like "dumping ..." before the screen went black, but I'm not > sure; the screen blanks too fast for me to read it. > The new partition types are NB?\? where the first ? is R for root, S for swap and U for BSD FFS filesystems. The second ? is 7 for root and user, 1 for swap. I also added a few lines to adosglue.h and disksubr.c to recognise AMIX's UNI\? partitions so it will shut the fork() up if you have some. I also sprinkled some \n's around in various places so the output looks better. I have the ql and le drivers going for the new configure method although ql is unavailable as it uses AMIX proprietary 6502 code and the le driver can't get all the ethernet board's serial number, something in the config code seems to be truncating the serno field to 16 bits even though both structure members involved ints; bizzare. file.amiga.newconf also needed a ": ether ifnet" added after the le so the ether and ifnet kernel modules would be pulled in and attached to le. Some other minor tweeks were needed for le as well. See below for horrors from the May 23rd sup. > Since I found the "nsectors != whatever" message always a bit scary and > because something looking like this also popped up under all previous > kernels when I mounted the mfs /tmp filesystem, I set forth to fix this > message (hoping it would fix the panic). > It will but you might have seriously messed up your drive by dinking with the rdb. HDToolBox KNOWS what the fork() it's doing. There is a REASON why your drive told it there were fewer sectors per cyl that nheads * nsecpertrk would seem to indicate. They are called slip or spare sectors. The imbedded SCSI disk controller uses them to optimize sector reallocation when a sector goes bad on a track. The CORRECT solution is to fix the code in disksubr.c like I outlined above. The rdb should NEVER be messed with once these parameters are sucked off the drive by HDToolBox with a SCSI inquiry command. > Next, reboot and keep your fingers crossed. If all comes up just fine, > you're all set and your troubles (and warnings from NetBSD) should be over. Actually, they are just beginning! B^). No floppy driver, no ethernet driver. Slip appears not to work right and you'll probably have to add a tape unit type to sys/scsi/st.c. If you have the May 23rd sup, looks like the same stuff applys to the May 25th as well, you'll have all of the below to deal with; whew! I'm still running off the May 19th sup as pmap_bootstrap_alloc() and cpu_swapin() are puzzling me. 1: amiga/mem.c - machine/pmap.h and vm/vm_prot.h includes have to be swapped as pmap.h needs #define's in vm_prot.h 2: amiga/pmap.c - 3 functions have to be explicitely declared void to match new prototypes in /usr/include. You also need to craft a pmap_bootstrap_alloc() functions, the one shamelessly stolen from the hp300 port no workee. B^(. 3: amiga/vm_machdep.c - Need a cpu_swapin(stuct proc *) function but no real definition of what the function should do other than automagic related to an arch when a program is paged back in at a different address. 4: amiga/trap.c - 040 fans will pull there hair out. The nice clean defines in m68k/frame.h were shamelessly renamed to more cryptic values, in the TRUE BSD spirit of obfusication, for the hell of it. B^(. Need to print out the old headers and the new to compare values and change. About 45 minutes of being pissed off... Non-040 people have to do this as the 040 code is breezed over by 030/020 machines... B^(. There are other annoyances but those are left as an exercise to the kernel hacker... B^). > Anyhow, after I fixed this, the new kernel continued just fine and > presented me with a single user prompt. Typing "ls -l" and some other > trivial (static) programs still worked OK (excluding of course ps and > friends). However, after mounting /usr, I tried some shared binaries but > then I got "could not map ld.so" or something to that effect and, of > course, these programs didn't work. I guess my binaries are too old. > Nope, alot of new binarys won't work either due to the mmap() syscall moving and sysctl() being put in it's place. The new X distribution is a victem of this. B^(. However, I have other things to worry about, like creating a kernel that won't panic... > What should I do now? The kernel looks pretty stable (is it Michael? :), About as stable as nitro in an 8.x earthquake... Superkicked 3000 owners also have the wonderful feature that in most cases you'll have to power cycle the machine after all reboots as the ROM image goes away and the NetBSD panic, KDB and lockup scenerios don't restore it. Probably means some of the 3000's "More magic" bits aren't being twiggled correctly. The good news is that the reboot command will sometimes work although most of the time the kernel panic's with a message having to do with VM maps being whacked out and of course since it panic'd rather than running the reboot() function you lost your ROM image again... This probably doesn't effect the 2.04 ROM systems as they don't store the ROM image in RAM exclusively. Well, enough gloom and doom for now. This stuff won't get fixed unless we all do the fixin'... Off I go... -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 19:41:32 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: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 25, 11:40am, Markus Illenseer wrote: > On May 24, 4:46pm, Hubert Feyrer wrote: > > get those errors? If so, that might be the cause for your crashes, > > because if you initialize the card on the AmigaOD-side and then switch > > over to NetBSD, the card's still initialized and expects certain > > handlers to be present in RAM which surely aren't there when you run > > NetBSD! > > Not entirely true. The problem is, that a once initilized card such > as Ethernet, Arcnet or even several gfx-boards are sending interrupts, > which NetBSD cannot evoluate and then just hangs. > ... > Final workaround: The kernel needs to reset every possible card or > needs to be poloished to work with non-identified interrupts. But how would the kernel know how to deal with non-identified interrupts? It has to know how to clear whatever is causing the interrupt on the card, which means it has to know internal details on each card (i.e. what memory location to read, or bit to set or clear). Resetting every card might be difficult too - how would the kernel know how to reset the card (other than doing a RESET instructions - at which point you may not have any fast memory anymore either). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed May 25 19:45:17 1994 From: David L Miller To: "Michael L. Hitch" Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: help with A3000 Distribution: world X-Newsreader: Pine (proto-3.90) Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Wed, 25 May 1994, Michael L. Hitch wrote: > > But how would the kernel know how to deal with non-identified interrupts? It should report the unexpected interrupt and otherwise ignore it. |\ | |\/| David L. Miller dlm@cac.washington.edu (206) 685-6240 |/ |_ | | Software Engineer, Pine Development Team (206) 685-4045 (FAX) University of Washington, Networks & Distributed Computing, JE-20 4545 15th Ave NE, Seattle WA 98105, USA From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 20:59:13 1994 X-Authentication-Warning: xanth.CS.ORST.EDU: Host mundania.CS.ORST.EDU didn't use HELO protocol To: greywolf@autodesk.com (This is my bacque pas, this is my faux pas) Cc: Jason Thorpe , Mark Townley , current-users@sun-lamp.cs.berkeley.edu Subject: Re: reading sunos disk label From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 24 May 1994 21:53:22 -0700 (This is my bacque pas, this is my faux pas) wrote: > Could the NetBSD label perhaps be put at a different offset than the SunOS > label, and the SunOS label be translated concurrently? Something to make > the DKIOSLABEL stuff work so that things like "newfs" and "disklabel" > work... I can only speak from experience, as I have not taken the time to compare the SunOS disklabel code and the NetBSD/sparc disklabel code...But, I partitioned my two NetBSD drives with SunOS format(8) and NetBSD talked to the drives just fine! > > Just a thought. > > > -- > Make a hacker happy. Use a *real* OS. > > ________ _____ ____ ________ _____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 > Just because memory, disk and cpu speed are cheap is no excuse for > shoddy programming. ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 737-9533 OSU CS Support CSWest Room 12 737-5567 'These are my opinions and not necessarily those of anyone else.' NetBSD/Symmetry - Coming soon to a Sequent near you! From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 23:10:25 1994 From: (This is my bacque pas, this is my faux pas) 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: 3145 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: Jason Thorpe , greywolf@autodesk.autodesk.com (This is my bacque pas, this is my faux pas) Subject: Re: reading sunos disk label Cc: Jason Thorpe , Mark Townley , current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu NetBSD "talks" to the drives okay, but NetBSD "newfs" and "disklabel" seem to depend on BSD labels, and almost completely ignore the SunOS labels. Of course, "disklabel" could be modified for the SPARC to look at SunOS labels, translate them inline...no, that would still require kernel mods. I will look at supplying said code but: - I'm pretty much at a chasm until the next tarballs come out (sounds like I'm tending to a cat), as I have accidentally deleted last week's supdates... - My wife and I are expecting release 1.0 of a new dancer/hacker/ musician shortly, and anyone with a family will be familiar with the two month loss of sleep. I'll give it a shot. If someone else wishes to undertake this, that would be fine, too. (Proofing the checksums is gonna be a pain, too.) -- Make a hacker happy. Use a *real* OS. ________ _____ ____ ________ _____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 I'm really a software toolsmith and a musician by trade, but nobody really needs a software toolsmith much, and the music industry is so cutthroat that it would probably do me in. So I do systems administration on the side as a hobby. Funny that my hobby finds more work than either of my professions... From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 23:43:20 1994 From: gregc@edi.com (Greg Cronau) Subject: Possible problem with sleep(3). 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: 1712 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am currently porting some production code that was originally designed in a SysVr3 environment. I just ran into a minor problem with the sleep() library function. I am not sure whether this is an actual bug in the implementation, or if the BSD semantics of sleep() is different from SysV. Sleep returns an int. Under SysV sleep is supposed to return the "unslept" time if it is interupted. NetBSD appears to restart function calls as the default, but this can be changed with the sigaction() or siginterrupt() calls. However, sleep() apparently ignores the value of siginterrupt() and does not appear to be capable of being interrupted. Notice the following piece of code from the end of .../lib/libc/gen/sleep.c: -------------------------- setvec(vec, sleephandler); (void) sigvec(SIGALRM, &vec, &ovec); omask = sigblock(sigmask(SIGALRM)); ringring = 0; (void) setitimer(ITIMER_REAL, itp, (struct itimerval *)0); while (!ringring) sigpause(omask &~ sigmask(SIGALRM)); (void) sigvec(SIGALRM, &ovec, (struct sigvec *)0); (void) sigsetmask(omask); (void) setitimer(ITIMER_REAL, &oitv, (struct itimerval *)0); return 0; } static void sleephandler() { ringring = 1; } ------------------------- This code will just keep calling sigpause() everytime it is interupted until the real SIGALRM arrives. I need the ability to interupt the sleep() call. I see 3 solutions here: 1.) This is the correct symantics for BSD and I'm just going to have to write my own sleep() function. 2.) This is a bug and I should fix sleep() and post fixes. 3.) If this isn't a bug, would there be interest in code for an isleep() function to be added to libc that would be an interuptable sleep() ? Gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed May 25 23:48:42 1994 From: Paul Kranenburg To: thorpej@mundania.CS.ORST.EDU, greywolf@autodesk.autodesk.com, greywolf@autodesk.com Subject: Re: reading sunos disk label Cc: mark@praxis.co.uk, current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > - My wife and I are expecting release 1.0 of a new dancer/hacker/ > musician shortly, and anyone with a family will be familiar with > the two month loss of sleep. > Yeah, still bug-fixing mine; must be some sort of multiple inheritence hickup:-) From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 00:21:59 1994 From: Paul Kranenburg To: current-users@sun-lamp.cs.berkeley.edu, peter@alice.wonderland.org Subject: Re: Problems with -current build Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ../../../../sys/uio.h:46: parse error before `size_t' Add the prefix `_BSD' to the _SIZE_T et.al. in and/or update /usr/include From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 00:47:27 1994 From: kim@dde.dk (Kim Andersen) Subject: 4.4Lite where ? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Seeing that most/all of the current changes has to do with 4.4Lite, I wonder if the distribution is up for ftp somewhere. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 00:50:02 1994 From: Peter Galbavy To: current-users@sun-lamp.cs.berkeley.edu Subject: Problems with -current build Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sorry to ask the FAQ (I'm sure), but I am getting lots of problems at the moment trying to build a new kernel (SPARC). I get: cc -c -I. -I../../../../arch -I../../../.. -I../../../../sys -DSUN4C -DTIMEZONE="0x1e0" -DDST="1" -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DDEBUG -DDIAGNOSTIC -DKTRACE -DRCONSOLE -DFFS -DNFSSERVER -DINET -DTCP_COMPAT_42 -DCOMPAT_43 -DCOMPAT_SUNOS -DKERNEL -I/usr/include -DMAXUSERS=8 ../../sparc/genassym.c In file included from ../../../../sys/param.h:86, from ../../sparc/genassym.c:48: ../../../../sys/uio.h:46: parse error before `size_t' ../../../../sys/uio.h:46: warning: no semicolon at end of struct or union In file included from ../../../../sys/user.h:49, from ../../sparc/genassym.c:56: ../../../../sys/sysctl.h:331: parse error before `size_t' ../../../../sys/sysctl.h:333: parse error before `size_t' [...etc...] I have been doing this long enough to think I have not missed some vital step, but please tell me where I am losing :( As my systems were up and down recently I may have missed some e-mail to the list or some vital bootstrap somewhere... HELP ! Thanks, -- Peter G From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 01:55:00 1994 From: n62274@pbhrzx.uni-paderborn.de (Klaus Schaefers) Subject: Re: ypserv for NetBSD (ALPHA-940523) To: current-users@sun-lamp.cs.berkeley.edu Cc: moj@stacken.kth.se Comment: No comment Priority: 1 X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 786 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, > As promised last week, now is an ALPHA release of ypserv for NetBSD > available. Utilities in this release are makedbm, stdhosts and ypserv. > A first makefile for creating maps exists but is stupid an rebuilds > all maps every time. > > The server has been tested with the following commands: > > ypwhich -m [map] > yppoll map > ypmatch key map > ypcat map > > ftp.stacken.kth.se:/pub/OS/NetBSD/ypserv/ypserv-ALPHA-940523.tar just tried it on *current from 20.Mar.1994. Great stuff. Could someone please put it in the tree, as soon as there is an yppasswd daemon ? > That's all... > > -moj Thanks Klaus -- / \ n62274@pbhrzx.uni-paderborn.de || << * >> klaus@elostar.owl.de || sowieso: \ / Realname: Klaus Schaefers || NetBSD-current From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 26 02:54:32 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: NetBSD/RCS fusion 40/GVP serieII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, My friend tried to run NETBSD ,but was not able to get it to boot. It's stopped (hang) after trying to access the A3000/scsi.How come the kernel was not able to determine that he had a GVP serieII controller in his 2000? A2000/RCS Fusion-40 with 16 megs/ GVP serieII controller /Quantum 120lps/ Syquest 88. Bye Michel Beausejour From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 03:57:29 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: Endian wierdness in libskey. To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2422 Sender: owner-current-users@sun-lamp.cs.berkeley.edu In file md4.c of libskey we have some of these homebrewed endian checks that can blow up the md4 algorithm. As we have our I propose the following fix: ------------------------------------------------------------------------------- *** md4.c~ Wed May 25 14:13:43 1994 --- md4.c Wed May 25 14:19:20 1994 *************** *** 46,72 **** /* Implementation notes: * This implementation assumes that longs are 32-bit quantities. ! * If the machine stores the least-significant byte of an long in the ! * least-addressed byte (eg., VAX and 8086), then LOWBYTEFIRST should be ! * set to TRUE. Otherwise (eg., SUNS), LOWBYTEFIRST should be set to ! * FALSE. Note that on machines with LOWBYTEFIRST FALSE the routine * MDupdate modifies has a side-effect on its input array (the order of bytes * in each word are reversed). If this is undesired a call to MDreverse(X) can * reverse the bytes of X back into order after each call to MDupdate. */ - #define TRUE 1 - #define FALSE 0 - #if (defined(__MSDOS__) || defined(MPU8086) || defined(MPU8080) \ - || defined(vax) || defined (MIPSEL)) - #define LOWBYTEFIRST TRUE /* Low order bytes are first in memory */ - #else /* Almost all other machines are big-endian */ - #define LOWBYTEFIRST FALSE - #endif - - /* Compile-time includes */ #include #include "md4.h" /* Compile-time declarations of MD4 ``magic constants'' */ --- 46,60 ---- /* Implementation notes: * This implementation assumes that longs are 32-bit quantities. ! * Note that on big endian machines the routine * MDupdate modifies has a side-effect on its input array (the order of bytes * in each word are reversed). If this is undesired a call to MDreverse(X) can * reverse the bytes of X back into order after each call to MDupdate. */ /* Compile-time includes */ #include + #include #include "md4.h" /* Compile-time declarations of MD4 ``magic constants'' */ *************** *** 189,195 **** { register unsigned long tmp, A, B, C, D; ! #if LOWBYTEFIRST == FALSE MDreverse(X); #endif A = MDp->buffer[0]; --- 177,183 ---- { register unsigned long tmp, A, B, C, D; ! #if BYTE_ORDER == BIG_ENDIAN MDreverse(X); #endif A = MDp->buffer[0]; --------------------------------------------------------------------------- Happy hacking, Jan From owner-amiga@sun-lamp.cs.berkeley.edu Thu May 26 04:49:13 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbeausej@qc.bell.ca (michel beausejour), amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD/RCS fusion 40/GVP serieII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 25, 7:56pm, michel beausejour wrote: > My friend tried to run NETBSD ,but was not able to get it to boot. > It's stopped (hang) after trying to access the A3000/scsi.How come > the kernel was not able to determine that he had a GVP serieII controller > in his 2000? > A2000/RCS Fusion-40 with 16 megs/ GVP serieII controller /Quantum 120lps/ > Syquest 88. Which (of the many ones floating around) kernel? If the RCS Fusion-40 has it's memory above 0x07c00000, NetBSD is going to assume that it is running on an A3000 and try to configure the A3000 SCSI interface. To force NetBSD to not attempt configuring the A3000 SCSI, the variable _a3000_flag must be binpatched to 0. Kernels created from the current sources (and used with the 2.4 or later versions of loadbsd) should be able to detect if they are running on an A3000 or A4000 and configure things appropriately. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Thu May 26 10:44:31 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: Possible problem with sleep(3). To: gregc@edi.com (Greg Cronau) 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: 1002 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > This code will just keep calling sigpause() everytime it is interupted until > the real SIGALRM arrives. I need the ability to interupt the sleep() call. > I see 3 solutions here: > 1.) This is the correct symantics for BSD and I'm just going to have to > write my own sleep() function. I don't know. POSIX.1 says: The sleep() function shall cause the current process to be suspended from execution until either the number of real-time seconds specifed by the argument "seconds" has elapsed, or a signal is delivered to the calling process and its action is to invoke a signal-catching function or to terminate the process. And: If the sleep() function returns due to the deliver of a signal, the value returned shall be the unslept amount (the requested time minus the time actually slept) in seconds. Since we want NetBSD to move towards POSIX compliance, I'd say that our sleep() is broken. > 2.) This is a bug and I should fix sleep() and post fixes. I'm on it already. --jtc From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu May 26 15:26:54 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: help with A3000" (May 25, 9:32am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 25, 9:32am, Michael L. Hitch wrote: > But how would the kernel know how to deal with non-identified interrupts? > It has to know how to clear whatever is causing the interrupt on the card, > which means it has to know internal details on each card (i.e. what memory > location to read, or bit to set or clear). Resetting every card might > be difficult too - how would the kernel know how to reset the card (other > than doing a RESET instructions - at which point you may not have any > fast memory anymore either). I guess the whole pseudo-autoconfig needs a rewrite. As i understand, currently the autoconfig is not done by NetBSD itself, but the structs are passed through loadbsd to the kernel. Hence we need to rewrite the autoconfig in a manner that the whole Z-Bus is resetted and then be configed again, if that is possible at all. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 02:02:26 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: help with A3000" (May 26, 9:50am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: rhealey@aggregate.com, markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: help with A3000 Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 26, 9:50am, rhealey@aggregate.com wrote: > There are much more important things to deal with at this time > than that, how about we table this idea till after the kernel > is stable and we can do straight floppy boots without the need > for loadbsd? In the process of doing this we might solve the > config problem anyways. Yes, of course - the topic just popped up... > For now, we still have fundemental stability problems with the > new config method and 3000's also need some work since I appear > to be the only heavy with a 3000, Mike and Chris have other models. I think i will have some time tonight and will get the latest kernel sources and try it on my A3000. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 02:13:09 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 doc/CHANGES U src/gnu/usr.bin/gas/app.c U src/gnu/usr.bin/gas/input-scrub.c U src/gnu/usr.bin/gas/config/tc-i386.c U src/gnu/usr.bin/gdb/bfd/Makefile U src/gnu/usr.bin/gdb/bfd/aout-target.h U src/gnu/usr.bin/gdb/bfd/bfd.h U src/gnu/usr.bin/gdb/bfd/netbsd-core.c U src/gnu/usr.bin/gdb/bfd/targets.c U src/gnu/usr.bin/gdb/bfd/arch/i386/Makefile.inc U src/gnu/usr.bin/gdb/bfd/arch/sparc/Makefile.inc U src/gnu/usr.bin/gdb/bfd/arch/sparc/sysdep.h U src/gnu/usr.bin/gdb/gdb/solib.c U src/gnu/usr.bin/gdb/gdb/arch/m68k/Makefile.inc U src/gnu/usr.bin/gdb/gdb/arch/m68k/m68k-nat.c U src/gnu/usr.bin/gdb/gdb/arch/m68k/m68k-tdep.c U src/gnu/usr.bin/ld/ld.c U src/lib/libc/locale/Makefile.inc U src/lib/libc/net/ns_addr.c U src/lib/libskey/md4.c U src/libexec/rpc.rstatd/rstat_proc.c U src/sbin/quotacheck/quotacheck.c U src/sys/arch/amiga/amiga/adosglue.h U src/sys/arch/amiga/amiga/disksubr.c U src/sys/arch/amiga/conf/A3000 U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/dev/gtsc.c U src/sys/arch/amiga/dev/gvpbus.c U src/sys/arch/amiga/dev/gvpbusvar.h U src/sys/arch/amiga/dev/ztwobus.c U src/sys/arch/hp300/dev/hil.c U src/sys/arch/hp300/dev/hilioctl.h U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/sparc/include/stdarg.h U src/sys/arch/sparc/include/varargs.h U src/sys/kern/subr_rmap.c U src/sys/net/if_tun.c U src/usr.bin/file/magdir/NetBSD U src/usr.sbin/rarpd/rarpd.c Running the SUP scanner: SUP Scan for current starting at Thu May 26 03:43:48 1994 SUP Scan for current completed at Thu May 26 03:49:20 1994 SUP Scan for mirror starting at Thu May 26 03:49:20 1994 SUP Scan for mirror completed at Thu May 26 03:52:25 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 02:15:12 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: Legallity Sender: owner-amiga@sun-lamp.cs.berkeley.edu I currently have the oppertunity to make a snapshot of the current NetBSD-Amiga (at least a version which works, that's an April version then) and put it on a CD together with lot of other stuff. The stuff is revisited and ordered, it is not a snapshot of the NetBSD- current tree and contains lot of binaries from the ftp-sites. The CD will cost very little (about 12$US) and thus won't give much profit to the dealers. It will be a shareware-CD (!) though, if anybody actually pay the fee, we might see some money for NetBSD-Amiga, too. *cross fingers* Now my problem: Is this legal? Can i distribute anything? Is the stuff based on BSD 4.4-lite or isn't it? Do i have to fear a law-suit? What can i distribute, under which terms, and what not? Don't bother about libcrypt, the CD will be pressed and sold in Germany, and all we have to bother there is the _export_ law of the _US_ :) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 02:15:58 1994 From: rhealey@aggregate.com Subject: Re: help with A3000 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga-dev@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: 951 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I guess the whole pseudo-autoconfig needs a rewrite. As i understand, > currently the autoconfig is not done by NetBSD itself, but the structs are > passed through loadbsd to the kernel. Hence we need to rewrite the autoconfig > in a manner that the whole Z-Bus is resetted and then be configed again, > if that is possible at all. > There are much more important things to deal with at this time than that, how about we table this idea till after the kernel is stable and we can do straight floppy boots without the need for loadbsd? In the process of doing this we might solve the config problem anyways. For now, we still have fundemental stability problems with the new config method and 3000's also need some work since I appear to be the only heavy with a 3000, Mike and Chris have other models. Let's get the main kernel and common drivers rock solid again before messing with something as fundemental as autoconfig... -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 02:28:39 1994 From: Christos Zoulas 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: current-users@sun-lamp.CS.Berkeley.EDU Subject: new bootpd still uses SIOCSARP... Sender: owner-current-users@sun-lamp.CS.Berkeley.EDU and does not compile... Is someone working on it, or should I fix it? christos From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 03:26:46 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Newbie SUP question From: - Greg Earle Sender: owner-current-users@sun-lamp.cs.berkeley.edu I finally got "sup" up and working, but discovered to my horror that the next night's sup run fetched the entire universe again :-( What's the most obvious reason why? I have the following sup setup: ("\"'s added for clarity) netbsd4me.jpl.nasa.gov:1:29 [/usr/lib/supfiles] % ls -l total 2 -rw-r--r-- 1 root bin 501 May 25 17:26 coll.list netbsd4me.jpl.nasa.gov:1:30 [/usr/lib/supfiles] % cat coll.list current release=allsrc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp \ base=/usr prefix=/usr backup use-rel-suffix delete current release=security host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp \ base=/usr prefix=/usr backup use-rel-suffix delete current release=doc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp \ base=/usr prefix=/usr backup use-rel-suffix delete current release=othersrc host=sun-lamp.cs.berkeley.edu hostbase=/a/anon_ftp \ base=/usr prefix=/usr backup use-rel-suffix delete netbsd4me.jpl.nasa.gov:1:31 % ls -lt /usr/sup/current total 712 -rw-r--r-- 1 root wheel 4 May 26 06:18 when.othersrc -rw-r--r-- 1 root wheel 5727 May 26 06:18 last.othersrc -rw-r--r-- 1 root wheel 4 May 26 06:17 when.doc -rw-r--r-- 1 root wheel 306 May 26 06:17 last.doc -rw-r--r-- 1 root wheel 47 May 26 06:17 last.security -rw-r--r-- 1 root wheel 4 May 26 06:17 when.security -rw-r--r-- 1 root wheel 343654 May 26 06:17 last.allsrc -rw-r--r-- 1 root wheel 4 May 26 06:17 when.allsrc I run "sup" from "cron" via "/usr/local/sbin/sup -s". Since it created all of the above /usr/sup/current files upon first invocation, I would have thought that from then on, it would know where to get the when.* files and thus know to only sup the latest stuff since the when date. What am I missing? Thanks, - Greg From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 03:42:18 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: Legallity Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9405261438.AA02938@opal.techfak.uni-bielefeld.de> markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) writes: > I currently have the oppertunity to make a snapshot of the current > NetBSD-Amiga (at least a version which works, that's an April version > then) and put it on a CD together with lot of other stuff. [...] > Now my problem: Is this legal? Can i distribute anything? Is the > stuff based on BSD 4.4-lite or isn't it? Do i have to fear a law-suit? > What can i distribute, under which terms, and what not? The kernel still has a lot of Net/2 code in it, and any version from April is all Net/2. Userland is still almost entirely Net/2. Novell/USL has been actively contacting Net/2 distributors and telling them to stop. Note that disc prodecers that do any advertising are going to have to search the entire tree for copyright statements and publish all the required credits in all their ads. I haven't figured out the best way to handle this yet, since there are LOTS of them. -- Ty Sarna "It pays to be obvious, especially if you have a tsarna@endicor.com reputation for subtlety" -- Salvor Hardin From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 10:47:33 1994 From: Arthur Hoffmann Subject: Re: Newbie SUP question To: earle@isolar.Tujunga.CA.US (- Greg Earle) 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: 909 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I finally got "sup" up and working, but discovered to my horror that the next > night's sup run fetched the entire universe again :-( > > What's the most obvious reason why? I have the following sup setup: [Stuff Deleted] I read in some message here a couple of days ago that this might happen once in the near future. So don't worry I think some part of the tree has been moved to a different disk which causes the problem. (I cant find the mail describing it anymore) I'm in the same situation :( I tried last night and just when it was about to finish sun-lamp died :( I wish there was a way to resume where the sup was interrupted, Or at least a way to break up the src part of sup into smaller, more manageable portions. > > > - Greg > 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 Fri May 27 10:59:52 1994 From: mw@eunet.ch Subject: Re: Legallity To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1156 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > The CD will cost very little (about 12$US) and thus won't give much > profit to the dealers. It will be a shareware-CD (!) though, if anybody > actually pay the fee, we might see some money for NetBSD-Amiga, too. > *cross fingers* Who's going to collect the shareware fee? Just curios :-) > Now my problem: Is this legal? Can i distribute anything? Is the > stuff based on BSD 4.4-lite or isn't it? Do i have to fear a law-suit? > What can i distribute, under which terms, and what not? I don't really know, but since you're distributing this from Germany, not the US, I wouldn't care too much about that.. (IMHO of course:-)) > Don't bother about libcrypt, the CD will be pressed and sold in Germany, > and all we have to bother there is the _export_ law of the _US_ :) Eh, wasn't there someone (when we discussed this issue last time) who claimed that it was just as illegal to import foreign crypt technology (if this wasn't sad it would be funny...) into the US. Any takers? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 12:57:07 1994 From: Olaf Seibert To: amiga-dev@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de, osymh@gemini.oscs.montana.edu Subject: Re: help with A3000 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) wrote: > I guess the whole pseudo-autoconfig needs a rewrite. As i understand, > currently the autoconfig is not done by NetBSD itself, but the structs are > passed through loadbsd to the kernel. Hence we need to rewrite the autoconfig > in a manner that the whole Z-Bus is resetted and then be configed again, > if that is possible at all. Why bother? Any way you boot, through loadbsd or via a bootloader, the expansion.library is going to get there first and autoconfig all boards. Why duplicate this arcane magic? If we ever need to really reset the machine, it should be possible to create a new, fake ExecBase structure and use one of the *Capture vectors to come back after rebooting, or somesuch. At least that part is sort-of documented. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. rhialto@mbfys.kun.nl \X/ An original idea. That can't be too hard. The library must be full of them. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri May 27 13:16:38 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu, netbsd-users@sun-lamp.cs.berkeley.edu X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Phone: (510) 549-3563 Subject: At USENIX? Go to the NetBSD BOF, and don't bring fruit! X-Mts: smtp Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu There's going to be a NetBSD BOF at USENIX, on Wednesday night from 8-9PM. Location will be posted on the BOF board at USENIX. It's going to be fun and/or interesting. It'll be a general status report, plus question and answer. I'll babble about the status of our 4.4-Lite integration, the various ports of NetBSD that are happening, our future plans, and anything you might bring up, and more. The entire NetBSD core team will be there to help answer your questions, and we might even commit ourselves to some things that we don't commit to online. If you're interested in a free, BSD UN*X-like system that runs on a variety of platforms, I encourage you to attend. If you can't make it, but can use FTP or ftp-mail, take a look at: ftp.NetBSD.ORG:pub/NetBSD In the 'misc' directory you'll find slides of previous NetBSD BOFs, and after the BOF in Boston, its slides, too. You'll also find the latest NetBSD-current sources, as well as the latest release (for the i386 only; go to the BOF for more info on the next one!) and more recent binary snapshots for various architectures. Chris Demetriou The NetBSD Project From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 13:31:02 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: help with A3000" (May 26, 5:12pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: markus@techfak.uni-bielefeld.de (Markus Illenseer), rhealey@aggregate.com, markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: help with A3000 Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 26, 5:12pm, Markus Illenseer wrote: > > For now, we still have fundemental stability problems with the > > new config method and 3000's also need some work since I appear > > to be the only heavy with a 3000, Mike and Chris have other models. > > I think i will have some time tonight and will get the latest kernel > sources and try it on my A3000. I tried and so far the machine is still compiling... I had some trouble with the new /usr/lib distribution where in libkvm/kvm.c the variable 'cpu040' was missing. I added a 'static int cpu040' in kvm.c, because it wasn't defined anywhere... And then the compiler warns me everytime he includes about memcmp() and memcpy() having other protoypes than the build-in functions - is there a solution for this one? I hope when i get back home, i can start compiling the enw kernel :) For you kernel-hackers: When you hack around the ethernet-stuff, please make the buffer of the ethernet-chip binpatchable. The old kernel worked flawlessly with 16KB but failed when i tried to compile it with 32KB (which the chip actually has!). -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 13:42:10 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Legallity" (May 27, 12:43am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: tsarna@endicor.com (Ty Sarna), amiga@sun-lamp.cs.berkeley.edu Subject: Re: Legallity Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 27, 12:43am, Ty Sarna wrote: > The kernel still has a lot of Net/2 code in it, and any version from > April is all Net/2. Userland is still almost entirely Net/2. Novell/USL > has been actively contacting Net/2 distributors and telling them to > stop. Means: I should forget about this unless i have a recent version of both the kernel and the binaries? > Note that disc prodecers that do any advertising are going to have to > search the entire tree for copyright statements and publish all the > required credits in all their ads. I haven't figured out the best way to > handle this yet, since there are LOTS of them. There probably won't be any ads for this CD :) *sigh* -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 13:59:45 1994 From: Matthias Kirschnick Subject: Binpatching the actually running kernel? 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: 507 Sender: owner-amiga@sun-lamp.cs.berkeley.edu hello, is ist possible to binpatch the running kernel? My problem is to debug the adosfs-code using the _adosfs_debug variable. What I'm doing is binpatching the kernel and starting a reboot. I would like to omit the frequent reboots. Any suggestions? Matthias ------------------------------------------------------------------------------ Matthias Kirschnick kirschnick@immd4.informatik.uni-erlangen.de Phone: 49 9131 85 8027 "Es geht auch anders, aber so geht es auch!" (Lotti Huber) From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 14:08:24 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu, netbsd-users@sun-lamp.cs.berkeley.edu X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Phone: (510) 549-3563 Subject: At USENIX? Go to the NetBSD BOF, and don't bring fruit! X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu There's going to be a NetBSD BOF at USENIX, on Wednesday night from 8-9PM. Location will be posted on the BOF board at USENIX. It's going to be fun and/or interesting. It'll be a general status report, plus question and answer. I'll babble about the status of our 4.4-Lite integration, the various ports of NetBSD that are happening, our future plans, and anything you might bring up, and more. The entire NetBSD core team will be there to help answer your questions, and we might even commit ourselves to some things that we don't commit to online. If you're interested in a free, BSD UN*X-like system that runs on a variety of platforms, I encourage you to attend. If you can't make it, but can use FTP or ftp-mail, take a look at: ftp.NetBSD.ORG:pub/NetBSD In the 'misc' directory you'll find slides of previous NetBSD BOFs, and after the BOF in Boston, its slides, too. You'll also find the latest NetBSD-current sources, as well as the latest release (for the i386 only; go to the BOF for more info on the next one!) and more recent binary snapshots for various architectures. Chris Demetriou The NetBSD Project From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 14:21:46 1994 From: Mats O Jansson To: current-users@sun-lamp.cs.berkeley.edu, n62274@pbhrzx.uni-paderborn.de Subject: Re: ypserv for NetBSD (ALPHA-940523) Cc: moj@stacken.kth.se Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199405252157.AA03482@pbhrzx.uni-paderborn.de>, n62274@pbhrzx.uni-paderborn.de wrote: >just tried it on *current from 20.Mar.1994. Great stuff. >Could someone please put it in the tree, as soon as there is an >yppasswd daemon ? Please, this is an ALPHA release. Just adding an yppasswd deamon isn't enough. I'm not sure that adding this code to the tree is a good idea for now. Lots of things must be done before it's time to consider adding the code to the tree. But I'm working on the yppasswdd. The code is written, it uses some modules from vipw and chpass, but not tested. AIX's rlogin bug and a VMS upgrade last weekend has keep me busy this week. Not much time left for my projects at home. A new release with yppasswdd may be release this weekend. I don't think I'll announce all new releases. But keep an eye on ftp.stacken.kth.se:/pub/OS/NetBSD/ypserv for new releases. >Thanks >Klaus >-- > / \ n62274@pbhrzx.uni-paderborn.de || ><< * >> klaus@elostar.owl.de || sowieso: > \ / Realname: Klaus Schaefers || NetBSD-current That's all... -moj ------------------------------------------------------------------------------ Mats O Jansson, CelsiusTech Systems, Jaerfaella, Sweden email: maja@celsiustech.se (or moj@stacken.kth.se) From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 14:22:38 1994 From: kim@dde.dk (Kim Andersen) Subject: Re: At USENIX? Go to the NetBSD BOF, and don't bring fruit! To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > There's going to be a NetBSD BOF at USENIX, on Wednesday night from > 8-9PM. Location will be posted on the BOF board at USENIX. > > It's going to be fun and/or interesting. It'll be a general status > report, plus question and answer. I'll babble about the status of > our 4.4-Lite integration, the various ports of NetBSD that are > happening, our future plans, and anything you might bring up, and > more. The entire NetBSD core team will be there to help answer your > questions, and we might even commit ourselves to some things that > we don't commit to online. Would it be possible for some-one attending, to write a summary/report for the overseas users. I sure would like to go, but money and time prevents it :-( regards kim From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 14:29:25 1994 From: billa@cu.lu (Billa Manou) To: markus@techfak.uni-bielefeld.de Subject: Re: Legallity Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > Date: Thu, 26 May 1994 16:38:04 MET DST > Subject: Legallity > > I currently have the oppertunity to make a snapshot of the current > NetBSD-Amiga (at least a version which works, that's an April version > then) and put it on a CD together with lot of other stuff. > > > The CD will cost very little (about 12$US) and thus won't give much > profit to the dealers. It will be a shareware-CD (!) though, if anybody > actually pay the fee, we might see some money for NetBSD-Amiga, too. > *cross fingers* > > > -- > Markus Illenseer > At that price I will buy it :-) ... if available sometimes (fingers crossed) <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> cu Manou BILLA billa@cu.lu // // Life starts at 020... vvvvv \\ // ... Creativity at 030 ... @ @ \X/ ... Fun at 040 ... ____oOO_(_)_OOo___ ... Impotence at '86 ! ... keep on Motorol'ing ;-) From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 14:35:41 1994 From: niklas@appli.se (Niklas Hallqvist) To: hoffmann@it.ntu.edu.au Cc: earle@isolar.Tujunga.CA.US, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Newbie SUP question Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> "Arthur" == Arthur Hoffmann writes: Arthur> I wish there Arthur> was a way to resume where the sup was interrupted, Or at least Arthur> a way to break up the src part of sup into smaller, more Arthur> manageable portions. Agreed, I sup over a dial-up line through "term" using my university account as the remote "term" node. The problem is that we just have an hours worth of connect time per day on the dial-in line. If I sup regularily this isn't a problem, but now I've been away for a month doing military service, and the sup session of the src collection just won't get finished in time. I guess I have to cheat, hand carrying a tarball and patching the when.* files manually. I've done this before, but I'd prefer a more fine-grained functionality of sup. I might volunteer to look into this, but only if I *know* it'll be looked at by the sup-server maintainers. I prefer someone else does it, my time is very limited as I've recently bought a house and most spare time goes into fixing things there. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri May 27 14:39:11 1994 X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: netbsd-users@sun-lamp.cs.berkeley.edu From: kallio@jyu.fi (Seppo Kallio) Subject: Cannot compile /usr/src/lib/libc please help! Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu # cd /usr/src/lib/libc # make ... cc -O -DYP -DLIBC_SCCS -DSYSLIBC_SCCS -DPOSIX_MISTAKE -c /usr/src/lib/libc/n= et/g ethostnamadr.c In file included from /usr/include/rpc/rpc.h:44, from /usr/src/lib/libc/net/= geth ostnamadr.c:51: /usr/include/netinet/in.h:75: redefinition of `struct in_addr' /usr/include/netinet/in.h:126: redefinition of `struct sockaddr_in' /usr/include/netinet/in.h:141: redefinition of `struct ip_opts' /usr/include/netinet/in.h:174: redefinition of `struct ip_mreq' *** Error code 1 Stop. The sources should be OK. I heve loaded them from ftp.iastste.edu Seppo From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 14:48:46 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: niklas@appli.se (Niklas Hallqvist) Cc: hoffmann@it.ntu.edu.au, earle@isolar.Tujunga.CA.US, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Newbie SUP question <9405270859.AA07411@della.appli.se> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I might > volunteer to look into this, but only if I *know* it'll be looked at > by the sup-server maintainers. We aren't the "sup-server maintainers" really; people at CMU are. We're not really making any significant changes to the code base... (and, i don't believe they are, either...) cgd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 14:50:24 1994 From: Hubert Feyrer Subject: sun-lamp-mirror on ftp.uni-regensburg.de extended To: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 592 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu FYI: The NetBSD-Amiga-binaries from sun-lamp's /pub/NetBSD/arch/amiga are now mirrored in /pub/NetBSD-Amiga/sun-lamp:arch.amiga on ftp.uni-regensburg.de. 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 May 27 14:53:04 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: kallio@jyu.fi (Seppo Kallio) Cc: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: Cannot compile /usr/src/lib/libc please help! <199405260544.AA25071@cc.jyu.fi> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > The sources should be OK. I heve loaded them from ftp.iastste.edu The sources are old; i just got done from a from-scratch compile of /usr/src. the only things that don't compile are pppd and bootpd. cgd From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 14:54:03 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Legallity" (May 27, 8:53am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mw@eunet.ch, markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: Legallity Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 27, 8:53am, mw@eunet.ch wrote: > Who's going to collect the shareware fee? Just curios :-) Guess who... :-) (no, not me, and probably not even the one you'd think of) > > Now my problem: Is this legal? Can i distribute anything? Is the > > stuff based on BSD 4.4-lite or isn't it? Do i have to fear a law-suit? > > What can i distribute, under which terms, and what not? > > I don't really know, but since you're distributing this from Germany, not the > US, I wouldn't care too much about that.. (IMHO of course:-)) I _need_ a _definitve_ answer for that - where can i have a look, who is to be asked? -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 16:29:50 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, savage@dg-rtp.dg.com Subject: Re: Time to install... but which one? Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: savage@dg-rtp.dg.com (Ed Savage) > > Well, I'm thinking about installed NetBSD on my A3000 this extended > weekend. > > I've got a decent amount of the FAQs I picked up but I still have a > couple of questions. > > Which distributions are the most stable/best to install? The ones in > sun-lamp.cs.berkeley.edu:/pub/NetBSD/arch/amiga? Or the ones in > ftp.eunet.ch:/software/os/bsd/NetBSD/NetBSD-Amiga/* ? Also, which is the > best X11 server package for an ECS machine? And where can it be found? Short answer. Use the rootfs from eunet and the binaries from sun-lamp. -SR From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 16:31:09 1994 From: Hubert Feyrer Subject: sun-lamp-mirror on ftp.uni-regensburg.de extended To: amiga@sun-lamp.cs.berkeley.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL13] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 592 Sender: owner-amiga@sun-lamp.cs.berkeley.edu FYI: The NetBSD-Amiga-binaries from sun-lamp's /pub/NetBSD/arch/amiga are now mirrored in /pub/NetBSD-Amiga/sun-lamp:arch.amiga on ftp.uni-regensburg.de. 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 May 27 16:51:27 1994 X-Sender: kallio@network.jyu.fi Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To: "Chris G. Demetriou" From: kallio@jyu.fi (Seppo Kallio) Subject: Re: Cannot compile /usr/src/lib/libc please help! Cc: netbsd-users@sun-lamp.cs.berkeley.edu Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu >> The sources should be OK. I heve loaded them from ftp.iastste.edu > >The sources are old; i just got done from a from-scratch compile of >/usr/src. the only things that don't compile are pppd and bootpd. You mean, that those src directory *.tar files at sun-lamp are not OK. That is: if I download them I cannot build the whole new system from them? Seppo From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 17:01:28 1994 From: savage@dg-rtp.dg.com (Ed Savage) Subject: Time to install... but which one? To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, I'm thinking about installed NetBSD on my A3000 this extended weekend. I've got a decent amount of the FAQs I picked up but I still have a couple of questions. Which distributions are the most stable/best to install? The ones in sun-lamp.cs.berkeley.edu:/pub/NetBSD/arch/amiga? Or the ones in ftp.eunet.ch:/software/os/bsd/NetBSD/NetBSD-Amiga/* ? Also, which is the best X11 server package for an ECS machine? And where can it be found? Thanks! --Ed -- Edward Savage savage@dg-rtp.dg.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 17:22:27 1994 From: Peter Galbavy To: cgd@postgres.Berkeley.EDU, kim@dde.dk Subject: Re: At USENIX? Go to the NetBSD BOF, and don't bring fruit! Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu And I've got this small patch of water in the way, that stops me attending :( Have fun all, Peter G From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri May 27 17:33:08 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: kallio@jyu.fi (Seppo Kallio) Cc: "Chris G. Demetriou" , netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: Cannot compile /usr/src/lib/libc please help! <199405271133.AA25244@cc.jyu.fi> X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > You mean, that those src directory *.tar files at sun-lamp are not OK. That > is: if I download them I cannot build the whole new system from them? i could believe that; we never made any guarantees about the buildability of the tar files. i know for a fact that several other things in the latest tar files don't build, but i think that's something that we've mostly fixed in the last week. (There are still 2 programs that don't compile.) cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 17:34:34 1994 Subject: sup server almost ready - one more Q 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: 958 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I've got my system working like this: jacana <--- sup --- sun-lamp jacana: supscan jacana --- supfilesrv -l ---> karybdis It works quite well in this mode (the supfilesrv is a one-off server for my client on karybdis.) Now, the tricky bit. If I have supfilesrv running as a daemon on jacana, then each day I run sup/supscan, how will this affect supfilesrv connections serving off jacana at that time? (Obviously I won't serve off it whilst updating from sun-lamp, but other people may be.) If this works ok, I will have a sup server in Australia which has just one distribution (called `current'), which grabs src/othersrc/doc off sun-lamp (sans src/lib/libcrypt because I have FreeSec instead) up for grabs as one chunk. Hopefully I will be able to provide this service `permanently'. -- Luke Mewburn UNIX Systems Programmer, Technical Services Group Department of Computer Science, RMIT. From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 17:49:24 1994 From: rhealey@aggregate.com Subject: Re: Time to install... but which one? To: sjr@zombie.ncsc.mil (Stephen J. Roznowski) Cc: amiga@sun-lamp.cs.berkeley.edu, savage@dg-rtp.dg.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1263 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Well, I'm thinking about installed NetBSD on my A3000 this extended > > weekend. > > > > I've got a decent amount of the FAQs I picked up but I still have a > > couple of questions. > > > > Which distributions are the most stable/best to install? The ones in > > sun-lamp.cs.berkeley.edu:/pub/NetBSD/arch/amiga? Or the ones in > > ftp.eunet.ch:/software/os/bsd/NetBSD/NetBSD-Amiga/* ? Also, which is the > > best X11 server package for an ECS machine? And where can it be found? > > Short answer. Use the rootfs from eunet and the binaries from sun-lamp. > Longer answer, install bffs131 and create your filesystems using that. The 720 rootfs is generally bad news these days, can somebody PLEASE put a -current rootfs up for people to use? 720 is getting more and more wrong with each passing rev, which are coming fast and furious these days... Hopefully Markus can get a CD-ROM out soon and we can ditch the bogus stuff on ftp.eunet.ch and replace it with the CD-ROM contents. Anyways, at this point it will probably turn out to be more hassle to use the 720 rootfs than it would be to use bffs and gtar under ADOS to construct the system. Remember to make root a 16M filesystem or you'll be a hurtin' H. unit in the long run... -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 17:50:22 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: simple SIOCGARP, SIOCSARP ioctl replacement Sender: owner-current-users@sun-lamp.cs.berkeley.edu The following is a simple library intended to help porting pppd and bootpd. I stole most of the code from arp.c. I have not tested it extensively, but it works for me... christos # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # arplib.c # arplib.h # echo x - arplib.c sed 's/^X//' >arplib.c << 'END-of-arplib.c' X/* $Header$ */ X/* X * arplib.c: Library to manage an list of arp entries. X */ X X#include "arplib.h" X X#include X#include X#include X X#include X#include X#include X#include X X#include X X#include X X#include X#include X#include X#include X#include X#include X Xstruct arp_msg { X struct rt_msghdr m_rtm; X char m_space[512]; X}; X Xstruct arp_state { X int as_seq; X int as_fd; X pid_t as_pid; X struct sockaddr_inarp as_sia; X struct sockaddr_dl as_sid; X struct sockaddr_in as_mask; X struct arp_msg as_msg; X}; X Xstatic const char ether_fmt[] = "%x:%x:%x:%x:%x:%x"; X Xvoid * Xarp_open() X{ X struct arp_state *as; X X if ((as = malloc(sizeof(struct arp_state))) == NULL) X return NULL; X X if ((as->as_fd = socket(PF_ROUTE, SOCK_RAW, 0)) == -1) { X free(as); X return NULL; X } X X as->as_mask.sin_len = 8; X as->as_mask.sin_family = AF_UNSPEC; X as->as_mask.sin_port = 0; X as->as_mask.sin_addr.s_addr = 0xffffffff; X memset(as->as_mask.sin_zero, 0, sizeof(as->as_mask.sin_zero)); X X as->as_pid = getpid(); X as->as_seq = 0; X return (void *) as; X} X X Xvoid Xarp_close(vas) X void *vas; X{ X (void) close(((struct arp_state *) vas)->as_fd); X free(vas); X} X X Xstatic int Xether_aton(ea, p) X char *ea; X u_char *p; X{ X int i, x[6]; X X i = sscanf(ea, ether_fmt, &x[0], &x[1], &x[2], &x[3], &x[4], &x[5]); X X if (i != 6) X return -1; X X for (i = 0; i < 6; i++) X p[i] = x[i]; X return 0; X} X Xstatic int Xarp_msg(vas, cmd, flags) X void *vas; X int cmd; X int flags; X{ X struct arp_state *as = (struct arp_state *) vas; X struct rt_msghdr *rtm = &as->as_msg.m_rtm; X char *cp = as->as_msg.m_space; X int l; X X memset(rtm, 0, sizeof(*rtm)); X X switch (cmd) { X case RTM_ADD: X rtm->rtm_addrs = RTA_DST|RTA_GATEWAY; X rtm->rtm_inits = RTV_EXPIRE; X rtm->rtm_flags = RTF_STATIC; X X if (flags & ARP_TEMP) { X struct timeval tv; X gettimeofday(&tv, NULL); X rtm->rtm_rmx.rmx_expire = tv.tv_sec + 20 * 60; X } X else X rtm->rtm_rmx.rmx_expire = 0; X X if (flags & ARP_PROXY) { X rtm->rtm_flags |= RTF_ANNOUNCE; X if (flags & ARP_EXPORT) { X as->as_sia.sin_other = SIN_PROXY; X rtm->rtm_flags |= RTF_HOST; X } X else { X rtm->rtm_addrs |= RTA_NETMASK; X as->as_sia.sin_other = 0; X } X } X else { X as->as_sia.sin_other = 0; X rtm->rtm_flags |= RTF_HOST; X } X break; X X case RTM_GET: X case RTM_DELETE: X rtm->rtm_addrs = RTA_DST; X break; X X default: X errno = EINVAL; X return -1; X } X X#define NEXTADDR(w, s) \ X if (rtm->rtm_addrs & (w)) { \ X memcpy(cp, &s, sizeof(s)); \ X cp += sizeof(s); \ X } X X NEXTADDR(RTA_DST, as->as_sia); X NEXTADDR(RTA_GATEWAY, as->as_sid); X NEXTADDR(RTA_NETMASK, as->as_mask); X rtm->rtm_version = RTM_VERSION; X rtm->rtm_seq = ++(as->as_seq); X rtm->rtm_type = cmd; X l = rtm->rtm_msglen = cp - (char *)rtm; X X if (write(as->as_fd, (char *) &as->as_msg, l) == -1) X if (errno != ESRCH || cmd != RTM_DELETE) X return -1; X X do X l = read(as->as_fd, (char*) &as->as_msg, sizeof(as->as_msg)); X while (l > 0 && (rtm->rtm_seq != as->as_seq || X rtm->rtm_pid != as->as_pid)); X X if (l == -1) X return -1; X else X return 0; X} X X Xstatic int Xarp_process(vas, cmd, flags) X void *vas; X int cmd; X int flags; X{ X struct arp_state *as = (struct arp_state *) vas; X struct rt_msghdr *rtm = &as->as_msg.m_rtm; X struct sockaddr_inarp *sia = &as->as_sia; X struct sockaddr_dl *sid = &as->as_sid; X struct sockaddr_inarp *sin = (struct sockaddr_inarp *) (rtm + 1); X struct sockaddr_dl *sdl; X X for (;;) { X if (arp_msg(vas, RTM_GET, flags) < 0) X return -1; X X sdl = (struct sockaddr_dl *) (((char *) sin) + sin->sin_len); X X if (sin->sin_addr.s_addr == sia->sin_addr.s_addr) { X if (sdl->sdl_family == AF_LINK && X (rtm->rtm_flags & RTF_LLINFO) != 0 && X (rtm->rtm_flags & RTF_GATEWAY) == 0) X switch (sdl->sdl_type) { X case IFT_ETHER: X case IFT_FDDI: X case IFT_ISO88023: X case IFT_ISO88024: X case IFT_ISO88025: X sid->sdl_type = sdl->sdl_type; X sid->sdl_index = sdl->sdl_index; X return arp_msg(vas, cmd, flags); X default: X break; X } X if ((flags & ARP_PROXY) == 0) { X errno = EINVAL; X return -1; X } X X if (sia->sin_other & SIN_PROXY) { X errno = EINVAL; X return -1; X } X X flags |= ARP_EXPORT; X continue; X } X break; X } X X if (sdl->sdl_family != AF_LINK) { X errno = EINVAL; X return -1; X } X X sid->sdl_type = sdl->sdl_type; X sid->sdl_index = sdl->sdl_index; X return arp_msg(vas, cmd, flags); X} X Xint Xarp_set(vas, ia, ea, flags) X void *vas; X struct in_addr *ia; X char *ea; X int flags; X{ X struct arp_state *as = (struct arp_state *) vas; X struct sockaddr_inarp *sia = &as->as_sia; X struct sockaddr_dl *sid = &as->as_sid; X X memset(sid, 0, sizeof(*sid)); X memset(sia, 0, sizeof(*sia)); X X sia->sin_len = sizeof(*sia); X sia->sin_family = AF_INET; X sia->sin_addr = *ia; X X sid->sdl_len = sizeof(*sid); X sid->sdl_family = AF_LINK; X sid->sdl_alen = 6; X if (ether_aton(ea, (u_char *) LLADDR(sid)) != 0) { X errno = EINVAL; X return -1; X } X X return arp_process(vas, RTM_ADD, flags); X} X Xint Xarp_delete(vas, ia, flags) X void *vas; X struct in_addr *ia; X int flags; X{ X struct arp_state *as = (struct arp_state *) vas; X struct sockaddr_inarp *sia = &as->as_sia; X X memset(sia, 0, sizeof(*sia)); X X sia->sin_len = sizeof(*sia); X sia->sin_family = AF_INET; X sia->sin_addr = *ia; X X return arp_process(vas, RTM_DELETE, flags); X} X X X#ifdef TEST Xint Xmain(argc, argv) X int argc; X char *argv[]; X{ X void *a; X struct in_addr ia; X X if ((a = arp_open()) == NULL) { X perror("arp_open"); X return 1; X } X ia.s_addr = inet_addr("149.77.12.253"); X X if (arp_set(a, &ia, "01:01:02:03:04:05", 0) == -1) { X perror("arp_set"); X return 1; X } X X system("arp -a"); X X if (arp_delete(a, &ia) == -1) { X perror("arp_delete"); X return 1; X } X X system("arp -a"); X X arp_close(a); X X return 0; X} X#endif X X END-of-arplib.c echo x - arplib.h sed 's/^X//' >arplib.h << 'END-of-arplib.h' X/* X * arplib.h: Simple library interface to add and delete arp addresses X */ X#define ARP_NONE 0 X#define ARP_TEMP 1 X#define ARP_PROXY 2 X#define ARP_EXPORT 2 X X#include X#include X X__BEGIN_DECLS X Xvoid *arp_open __P((void)); Xint arp_set __P((void *, struct in_addr *, char *, int)); Xint arp_delete __P((void *, struct in_addr *, int)); Xvoid arp_close __P((void *)); X X__END_DECLS END-of-arplib.h exit From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri May 27 18:16:17 1994 From: rhealey@aggregate.com Subject: Re: Legallity To: mw@eunet.ch Cc: amiga-dev@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: 660 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Eh, wasn't there someone (when we discussed this issue last time) who > claimed that it was just as illegal to import foreign crypt technology > (if this wasn't sad it would be funny...) into the US. Any takers? > Yes, the SECOND part of the "munitions" law is that it is just as illegal to import as it is to export without blessing from the NSA, i.e. they have to be sure they can break whatever code you are using or they won't allow it in the country. Heaven forbid citizens should be safe from the prying eyes of the US governement. 1984 comes 10 years late to the US... -Rob #include Speaking for myself only of course! From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 18:30:56 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: christos@deshaw.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: new bootpd still uses SIOCSARP... Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From: Christos Zoulas > Date: Thu, 26 May 1994 08:35:31 -0400 > > and does not compile... Is someone working on it, or should I fix it? How would you propose to fix it? I considered reproducing the functionality of usr.sbin/arp in bootpd, but I'd hate to do that. An alternative (hack) is to just have bootpd do: system("arp -s IP_ADDR ETHER_ADDR temp"); If you have any better alternatives to suggest, I'd like to hear them. Gordon W. Ross Internet: Mercury Computer Systems Voice mail: 508-256-0052x295 199 Riverneck Road Front desk: 508-256-1300 Chelmsford, MA 01824-2820 Facsimile: 508-256-3599 From owner-current-users@sun-lamp.cs.berkeley.edu Fri May 27 19:24:39 1994 From: Joe Ammond Subject: Re: At USENIX? Go to the NetBSD BOF, and don't bring fruit! 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: 1130 Sender: owner-current-users@sun-lamp.cs.berkeley.edu According to Chris G. Demetriou: > There's going to be a NetBSD BOF at USENIX, on Wednesday night from > 8-9PM. Location will be posted on the BOF board at USENIX. Too bad I decided to go to LISA this year, and not USENIX. Maybe there could be a BOF at LISA also? > It's going to be fun and/or interesting. It'll be a general status > report, plus question and answer. I'll babble about the status of > our 4.4-Lite integration, the various ports of NetBSD that are > happening, our future plans, and anything you might bring up, and > more. The entire NetBSD core team will be there to help answer your > questions, and we might even commit ourselves to some things that > we don't commit to online. Would it maybe be possbile for the BOF to be broadcast on the MBONE? That way those of us without plane fair can at least see what's going on. I don't know what the network setup in Boston will be, tho. Just a thought. > Chris Demetriou > The NetBSD Project ja. -- Joe Ammond, a -current user ammond@ee.gatech.edu "Spiney! The sharp pointed toy that's fun to bathe with!" From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 20:48:35 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 --------------------------------- cgd Fri May 20 23:47:56 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/i386/include Modified Files: ansi.h Log Message: new way of naming things cgd Fri May 20 23:48:06 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/i386/include Modified Files: pcb.h Log Message: struct md_coredump cgd Fri May 20 23:48:15 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/i386/include Modified Files: stdarg.h varargs.h Log Message: update from lite cgd Fri May 20 23:49:09 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/m68k/include Modified Files: ansi.h Log Message: new way of naming things cgd Fri May 20 23:49:17 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/ren/sys/arch/m68k/include Modified Files: stdarg.h varargs.h Log Message: update from lite --------------------------------- chopps Sat May 21 03:05:52 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c genassym.c pmap.c trap.c vm_machdep.c Log Message: sys/vmmeter.h, sys/user.h and vm/vm.h shuffle. chopps Sat May 21 03:06:37 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Log Message: bye MAXFDESCS chopps Sat May 21 03:07:09 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: pcb.h Log Message: add md_coredump chopps Sat May 21 03:08:31 PDT 1994 Update of /b/source/CVS/src/usr.bin/vmstat In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.bin/vmstat Modified Files: names.c Log Message: add stub read_names()'s for non hp300 m68k's --------------------------------- chopps Sat May 21 03:12:31 PDT 1994 Update of /b/source/CVS/src/usr.bin/vmstat In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.bin/vmstat Modified Files: Makefile Log Message: add machine define if m68k arch. chopps Sat May 21 03:14:42 PDT 1994 Update of /b/source/CVS/src/usr.sbin/iostat In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/usr.sbin/iostat Modified Files: Makefile Log Message: add machine define if m68k arch (for vmstat/names.c) --------------------------------- chopps Sun May 22 00:22:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c machdep.c Log Message: an ide driver and hack reload device to do symbols. from osymh@gemini.oscs.montana.edu (Michael L. Hitch) chopps Sun May 22 00:22:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC files.amiga.newconf Log Message: an ide driver and hack reload device to do symbols. from osymh@gemini.oscs.montana.edu (Michael L. Hitch) chopps Sun May 22 00:22:36 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ser.c siop.c zssc.c zthreebus.c Added Files: idesc.c Log Message: an ide driver and hack reload device to do symbols. from osymh@gemini.oscs.montana.edu (Michael L. Hitch) --------------------------------- chopps Sun May 22 12:05:15 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: idesc.c Log Message: fix check for configured device in interrupt routine. --------------------------------- chopps Sun May 22 12:33:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC files.amiga.newconf Removed Files: DDBGENERIC GODZILLA ZEUS ZEUSONLY Log Message: lowercase options in files.amiga.newconf required, remove SYS* for now from GENERIC and remove old configs that serve no current purpose. --------------------------------- briggs Sun May 22 20:54:54 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k/include In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k/include Added Files: profile.h Log Message: Copied from Amiga. Just include m68k/profile.h. --------------------------------- mycroft Sun May 22 23:22:03 PDT 1994 Update of /b/source/CVS/src/sys/arch/hp300/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/hp300/include Modified Files: cpu.h frame.h param.h pcb.h pmap.h proc.h psl.h pte.h trap.h vmparam.h Log Message: Merge with 4.4-Lite. mycroft Sun May 22 23:26:07 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/conf In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/conf Modified Files: files.m68k files.m68k.newconf Log Message: Remove copy.s. It's simply not that generic. mycroft Sun May 22 23:29:16 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/include Modified Files: db_machdep.h frame.h psl.h trap.h Log Message: Merge with 4.4-Lite. --------------------------------- cgd Mon May 23 00:41:28 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/include Modified Files: types.h Log Message: can't use u_long cgd Mon May 23 00:41:57 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/include Modified Files: types.h Log Message: can't use u_long --------------------------------- mycroft Mon May 23 05:16:36 PDT 1994 Update of /b/source/CVS/src/sys/arch/hp300/hp300 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/hp300/hp300 Modified Files: locore.s Log Message: Copy copyinstr() from m68k generic, to deal with len > 64k. XXX I think this code is buggy. --------------------------------- chopps Wed May 25 00:58:37 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: amiga_init.c genassym.c locore.s machdep.c mem.c pmap.c trap.c vm_machdep.c Log Message: get up-to-date with recent vm changes and also with change of m68k frame. chopps Wed May 25 00:59:03 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: files.amiga.newconf Log Message: add arch/m68k/m68k/copy.s chopps Wed May 25 00:59:22 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Removed Files: sd.c st.c stvar.h Log Message: remove unused drivers. --------------------------------- chopps Wed May 25 01:00:02 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/include In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/include Modified Files: cpu.h pmap.h Log Message: update to work with new m68k frame and recent vm changes. --------------------------------- pk Wed May 25 11:27:52 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gdb/gdb/arch/m68k In directory sun-lamp.cs.berkeley.edu:/d/users/pk/gdb/gdb/arch/m68k Modified Files: Makefile.inc m68k-tdep.c Added Files: m68k-nat.c Log Message: kernel stuff brought over from gdb-3.5 --------------------------------- chopps Wed May 25 14:48:57 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: adosglue.h disksubr.c Log Message: add AMIX dostype and some changes (hacks) to RDB code. --------------------------------- chopps Wed May 25 14:54:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: files.amiga.newconf Log Message: fix le line chopps Wed May 25 14:55:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: gtsc.c gvpbus.c gvpbusvar.h ztwobus.c Log Message: add beginning of support for series I controllers doesn't work yet. --------------------------------- chopps Wed May 25 18:55:44 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: A3000 Log Message: update from steve. --------------------------------- chopps Wed May 25 20:05:03 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: ztwobus.c Log Message: fix typo --------------------------------- chopps Fri May 27 03:32:13 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: locore.s Log Message: now uses new type of init bootstrap chopps Fri May 27 03:33:27 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/kern Modified Files: init_main.c Log Message: amiga now included in list of new init bootstrap users --------------------------------- gwr Fri May 27 07:55:27 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/include In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/include Modified Files: cpu.h param.h pcb.h proc.h pte.h Log Message: Catch up with frame.h chages, merge stuff from new hp300 port. gwr Fri May 27 07:58:45 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/sun3 In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/sun3 Modified Files: clock.c genassym.c interrupt.s isr.c m68k.s machdep.c pmap.c process.s signal.s softint.s trap.c trap.s vm_machdep.c Log Message: Catch up with frame.h chages, merge stuff from new hp300 port. --------------------------------- gwr Fri May 27 08:02:04 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/conf In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/conf Modified Files: files.sun3.newconf Log Message: Add m68k/copy.s gwr Fri May 27 08:03:20 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/conf In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/conf Modified Files: GENERIC SCSITEST TIMESINK Log Message: Goodbye to MAXFDESCS gwr Fri May 27 08:07:44 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/dev In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/dev Modified Files: if_le.c if_le.h if_le_subr.c if_le_subr.h if_lereg.h Log Message: New lance driver (from Theo). gwr Fri May 27 08:08:13 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/dev In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/dev Modified Files: si.c Log Message: junk removal --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 21:56:42 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Time to install... but which one?" (May 27, 9:18am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: rhealey@aggregate.com, sjr@zombie.ncsc.mil (Stephen J. Roznowski) Subject: Re: Time to install... but which one? Cc: amiga@sun-lamp.cs.berkeley.edu, savage@dg-rtp.dg.com Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 27, 9:18am, rhealey@aggregate.com wrote: > Hopefully Markus can get a CD-ROM out soon and we can ditch the > bogus stuff on ftp.eunet.ch and replace it with the CD-ROM contents. *sigh* Doesn't look good for now. And 'my' CD-ROM is not a snapshot of EuNet. Anyway, there _IS_ a CD-ROM available with a snapshot of ftp.uni-regensburg.de /pub/NetBSD-Amiga dated about late February and contains almost whole EuNet NetBSD-Amiga. > Anyways, at this point it will probably turn out to be more hassle > to use the 720 rootfs than it would be to use bffs and gtar under > ADOS to construct the system. Remember to make root a 16M filesystem > or you'll be a hurtin' H. unit in the long run... We tried that way, but unless there is no gtar for ADos with mknod capabilities this is quite hard. Also i think whole uid/gid are lost using bffs. In my eyes a small rootfs is still the best way. 16M are way too much. -- Markus Illenseer From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri May 27 22:15:03 1994 From: lclee@netcom.com (Larry Lee) To: kallio@jyu.fi, netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: Cannot compile /usr/src/lib/libc please help! Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I had that problem with the May 13 tar files. It appeared to be a double include of the header file. I added to the beginning of /usr/include/netinet/in.h #ifndef _NETINET_IN_H_ #define _NETINET_IN_H_ #endif >ostnamadr.c:51: >/usr/include/netinet/in.h:75: redefinition of `struct in_addr' >/usr/include/netinet/in.h:126: redefinition of `struct sockaddr_in' >/usr/include/netinet/in.h:141: redefinition of `struct ip_opts' >/usr/include/netinet/in.h:174: redefinition of `struct ip_mreq' >*** Error code 1 > From owner-amiga@sun-lamp.cs.berkeley.edu Fri May 27 23:28:42 1994 From: Charles Ewen MacMillan Subject: Re: Time to install... but which one? 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 Fri, 27 May 1994, Markus Illenseer wrote: > Date: Fri, 27 May 1994 20:43:05 MET DST > From: Markus Illenseer > To: rhealey@aggregate.com, "Stephen J. Roznowski" > Cc: amiga@sun-lamp.cs.berkeley.edu, savage@dg-rtp.dg.com > Subject: Re: Time to install... but which one? > (cd rom, and installation speculations ommited) > > In my eyes a small rootfs is still the best way. 16M are way too much. > I tend to disagree. Without adding anything to the root partition, 24 hours of file logs on my file server, are sufficient to bring it to %85 full. I also have several syslog functions turned off, or routed to other systems for security reasons, so I cannot be the only person who has had their root partition overflow. I realize that there are other options than having /var and /var/tmp take up space on root, but if you are running a VERY distributed filing system, and are using sockets or FIFO's of any kind, placing them on a non-local filing system can have dangerous and unpredictable effects. I recently had a make file run a test script that taught me this lesson, by repeatedly opening files over NFS til the system hung. If 16Megs is too much, at least something like 12 or so would help out people doing NEW installs at least, so that they have time to learn to use tar to move the root partition before they run out of room :-) Charles Ewen MacMillan | Tezcat.COM - The Good Guys | Offering Internet Access Modem: 312-850-0112/0117| Via Interactive UNIX to Voice: 312-850-0181 | the Chicago Area. From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 01:44:28 1994 To: Joe Ammond Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: At USENIX? Go to the NetBSD BOF, and don't bring fruit! From: Lee Damon Sender: owner-current-users@sun-lamp.cs.berkeley.edu >According to Chris G. Demetriou: >> There's going to be a NetBSD BOF at USENIX, on Wednesday night from >> 8-9PM. Location will be posted on the BOF board at USENIX. > >Too bad I decided to go to LISA this year, and not USENIX. Maybe >there could be a BOF at LISA also? I'm the BOF coordinator for LISA VIII. If someone wishes to request such a bof, I'll be happy to schedule it. Mail the request to nomad@network.ucsd.edu. Include which day you would prefer (Tuesday, Wednesday, or Thursday) and the number of hours you want: .5, 1, 1.5, 2.) nomad ------------ - Lee "nomad" Damon - \ play: nomad@castle.org or castle!nomad \ work: nomad@qualcomm.com \ Sesnechal, Castle PAUS. / \ "Celebrate Diversity" / \ From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 02:38:27 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: /bin/sh Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has it changed in some incompatible way? I've run into some Configure scripts which fail on it... packrat:~/src/perl-4.036 ./Configure (I see you are using the Korn shell. Some ksh's blow up on Configure, especially on exotic machines. If yours does, try the Bourne shell instead.) ... ... ... [Type carriage return to continue] ./myread: 8: Syntax error: "!" unexpected (expecting "esac") From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 02:58:56 1994 From: Bob Kemp Subject: Re: At USENIX? Go to the NetBSD BOF, and don't bring fruit! To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 167 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ftp.NetBSD.ORG:pub/NetBSD Isn't that a new domain? Did I miss something? (Probably it seems) Someone enlighten me, please. Are there major changes afoot? Bob From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 12:32:50 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: /bin/sh To: explorer@vorpal.com (Michael Graff) 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: 267 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Has it changed in some incompatible way? Possibly, we've upgraded to the 4.4 lite shell, which is closer to POSIX.2 compliant. But your problems with Configure could be a bug. Could you please mail me the script so I can look into it further? Thanks, --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 12:50:06 1994 From: Dave Burgess Subject: Re: Newbie SUP question To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: niklas@appli.se, hoffmann@it.ntu.edu.au, earle@isolar.Tujunga.CA.US, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 775 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > I might > > volunteer to look into this, but only if I *know* it'll be looked at > > by the sup-server maintainers. > > We aren't the "sup-server maintainers" really; people at CMU are. > We're not really making any significant changes to the code base... > (and, i don't believe they are, either...) > I was having a thought the other night (and those of you familiar with my previous throughts are permitted to groan at will). If we included the /usr/sup files in the tar tree somehow, wouldn't that keep folks like this (and me the couple of times it has happened to me) from grabbing ALL of the files in the tree? It shouldn't be that hard to include the right files in the tar-balls, right? Thinking out load, or as close as my keyboard will let me.... From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 16:21:43 1994 From: kim@dde.dk (Kim Andersen) Subject: Floppy problems To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu [this is on i386] Trying to either disklabel or newfs a 1.44Mb floppy fails. This is the error message from newfs: fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 blkno 1 skip 0 cylin 0 status 40 fd0: seek failed st0 c1 cyl 0 fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 blkno 1 skip 0 cylin 0 status 40 fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 blkno 1 skip 0 cylin 0 status 40 fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 blkno 1 skip 0 cylin 0 status 40 fd0d: hard error reading fsbn 1 (st0 40 st1 1 st2 0 cyl 0 hd 0 se c 2) Ideas ? regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Sat May 28 18:14:19 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, kim@dde.dk Subject: Re: Floppy problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu You didn't say exactly *what* you typed to make this happen. But I presume from this: fd0d: hard error reading fsbn 1 (st0 40 st1 1 st2 0 cyl 0 hd 0 se That you're trying to newfs or label partition `d'. This is wrong. The floppy driver used the low bits of the minor number to specify the density. From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 28 20:23:36 1994 From: mbeausej@qc.bell.ca (michel beausejour) To: amiga@sun-lamp.cs.berkeley.edu Subject: NetBSD/A1200/ide Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've picked up the kernel from ftp.uni-regensburg.edu (netbsd-ide and netbsd-ide-2) and tried them on my a1200.I've experienced the same problem with both , it tried to mount root on fd0. Well i format a disk on my A3000 netbsd and put a couple of files from /bin and init died When i try to boot: it identifies that my disk drive is there: ide0: ideattach called: adr $1e50000 root on fd0 { with a disk formated by netbsd } { it acces the floppy } WARNING no battery clock WARNING no swap space present panic: init died Stopped at 0x96008 $96008: unlk a6 db> SO what's wrong? My config: a1200 with mbx1230 50mhz 68030 and 50mhz 68882 with 4 megs of fast ram Thanks, Michel Beausejour mbeausej@qc.bell.ca From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 28 20:54:08 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mbeausej@qc.bell.ca (michel beausejour), amiga@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD/A1200/ide Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 28, 1:38pm, michel beausejour wrote: > I've picked up the kernel from ftp.uni-regensburg.edu (netbsd-ide and > netbsd-ide-2) and tried them on my a1200.I've experienced the same problem > with both , it tried to mount root on fd0. Well i format a disk on my A3000 > netbsd and put a couple of files from /bin and init died You need to have /sbin/init, /bin/sh, and /dev/console as a bare minimum, and possibly /dev/tty. > When i try to boot: > it identifies that my disk drive is there: > ide0: ideattach called: adr $1e50000 Did it show any information about your IDE drive? If it doesn't print out the identification of your drive, then it doesn't see your drive. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 28 21:46:19 1994 From: "Matthew R. Zeier" Subject: supported ether cards? To: amiga@sun-lamp.cs.berkeley.edu (netbsd) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 608 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have ASDG's ethercard with sanaII drivers. Is this card yet supported by NetBSD? Is there anyone working on such an implementation? - Matthew --- =========================================================================== | Matthew R. Zeier "Do what you can with what you have | | mzeier@interaccess.com where you are." -Teddy Roosevelt | | "Fanatasies of the present often | | become realities of the future." -Time Traxx | =========================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Sat May 28 23:34:56 1994 To: "Matthew R. Zeier" Cc: amiga@sun-lamp.cs.berkeley.edu (netbsd) Subject: Re: supported ether cards? From: Terminator rAT Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Sat, 28 May 1994 "Matthew R. Zeier" wrote: > I have ASDG's ethercard with sanaII drivers. Is this card yet supported by > NetBSD? Is there anyone working on such an implementation? Nope. Not yet. I have one as well, and a friend of mine is reverse engineering it for me. He says it uses the same main chip as one of the common PC boards (I've forgotten which one, and he's away for the weekend). We are working on a driver for it. -rAT O----O Email: rat@cs.orst.edu Work: (503)737-5567 Home: (503)737-9467 \oo/ Instructional Support Technical Maniac ==\/== "If Windows 3.1 sucked, it would be good for something." From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 03:21:07 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: Exception 16 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a message on boot that is unlike anything I have seen before and am wondering if it is normal or an indication of a problem. I am running current as of May 20. We just replaced the 386 25 mother board in this thing with a Intel 486 dx2-66 on a generic VLB board. In addition to the exception 16 message, the compilers are dumping core. It may be noteworthy that the gnu stuff is the one thing I did not rebuild. It is from the May 2nd binaries. Any thoughts or help would be appreciated. Thanks!! -Len From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 04:03:14 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, lburns@cats.ucsc.edu Subject: Re: Exception 16 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Your message was *awfully* non-specific. What message about `exception 16' are you referring to? The one which says `using exception 16'? Does it *sound* like an error message? As far as GCC dumping core, it would have been nice if said *how* it was dumping core. Think about it; without specifics, how is anyone supposed to know whether it's a file system bug (corrupted file), a compiler bug, a VM system bug, a hardware bug, or the phase of the moon is wrong? *Please* take the time to write more complete bug reports in the future. Thirdly, you said `the May 2nd binaries', but you didn't state whether you built them yourself or got them from somewhere else, and if the latter, *where* you got them, and if the former, *where* you got the source. The most likely thing I can think of that would make GCC dump core for you is that you have executables or libraries built from source between April 2nd and April 14th, which had temporary syscall assignments which are now gone. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 08:14:47 1994 From: Tim Chase Subject: are the sup mirror(s) working? 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: 510 Sender: owner-current-users@sun-lamp.cs.berkeley.edu With the recent backup/restore on lamp seemingly causing a major sup backlog, I thought I'd try the mirror that was supposed to be on ftp.iastate.edu. Only problem was that it didn't work. Was ftp.iastate.edu ever a running mirror? I got the info from an old message on this list but past attempts to contact the sup server on that system have also been unsuccessful so it may have never been set up. Does anyone know if there are any sup mirrors running? Thanks, Tim Chase tim@introl.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 29 21:43:32 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: retina console 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: 907 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Does anyone have a Retina working as a console? It looks to me like the source I'm building, ca. May 22, doesn't support that. Briefly, the general console initial initialization probes "ite" out of constab, and the ite probe calls console_config() in the amiga autoconf.c. There the "mainbus" and "grfcc" devices are explicitly semi-initialized. When control returns to the ite probe, it finds only grfcc device, which eventually becomes the console more or less by default. In order to configure the Retina in time for this console competition, if I understand what's going on here, the Zorro bus mapping would have to be advanced to that point as well, so that the Retina device would have a functional address. (In my case it's the Retina Z3 and hence the Zorro III bus.) I'm preparing myself to take a crude stab at doing that, but it sounds a little dicey. Donn Cave, donn@cac.washington.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 21:44:47 1994 Subject: Re: Floppy problems To: mycroft@gnu.ai.mit.edu From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu, kim@dde.dk 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: 347 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > That you're trying to newfs or label partition `d'. This is wrong. > The floppy driver used the low bits of the minor number to specify the > density. Is this documented somewhere beside the source? I couldn't find it... Martin P.S.: on my 1.44 / 3.5" drive /dev/fd0a works with 1.44 MB disks, while /dev/fd0f works with 720 kB disks From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun May 29 21:53:15 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: SIOCSARP Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Building entire new tree with supped sources from yesterday yielded into some small problems. It seems that libexec/bootpd/hwaddr.c requires a define named 'SIOCSARP' which is not defined anywhere in the new includes anymore. It was previously found in either /sys/ioctl.h or sys/sockio.h. Same applies for usr/sbin/pppd. I think this is due to recent kernel changes and thought i report this, but i have no idea to hom to report this really... Another grief. How does one set up a new config for the kernel using an old kernel and unable to run the new config binary ? :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 29 22:03:29 1994 From: "Matthew R. Zeier" Subject: what's console look like? To: amiga@sun-lamp.cs.berkeley.edu (netbsd) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 687 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Without Xwindows running on NetBSD, what does a console login look like? 80x24 screen? What res? Do you have only one login per console or are there virtual consoles (similiar to BSDI - ATL function-key)? Thanks, - Matthew --- =========================================================================== | Matthew R. Zeier "Do what you can with what you have | | mzeier@interaccess.com where you are." -Teddy Roosevelt | | "Fanatasies of the present often | | become realities of the future." -Time Traxx | =========================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 29 22:06:38 1994 From: msanders@eng.utah.edu Subject: A2065 Ethernet? To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 448 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does anyone know where I could pick up an A2065 Ethernet Card for NetBSD? They seem to be a little scarce these days... -- Michael K. Sanders There is a theory that states: "If anyone finds out what the universe is for it will disappear and be replaced by something more bazaarly inexplicable." There is another theory that states: "This has already happened ...." -- Donald Adams, "Hitch-Hikers Guide to the Galaxy" From owner-amiga@sun-lamp.cs.berkeley.edu Sun May 29 22:19:36 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "what's console look like?" (May 29, 2:16pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Matthew R. Zeier" , amiga@sun-lamp.cs.berkeley.edu (netbsd) Subject: Re: what's console look like? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 29, 2:16pm, "Matthew R. Zeier" wrote: > Subject: what's console look like? > Without Xwindows running on NetBSD, what does a console login look like? > 80x24 screen? What res? Do you have only one login per console or are > there virtual consoles (similiar to BSDI - ATL function-key)? Any size you like. Thought not larger than x-size of the font and size of the screen (ECS). No virtual consoles yet. -- Markus Illenseer Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 22:43:27 1994 From: rhealey@aggregate.com (Rob Healey) Subject: When is the next sup update? 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: 260 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Anybody know when the next sup update will be done? It hasn't been run since Thursday and I need some updates that have been done since then to do some kernel work. Are we going to have to wait till cgd gets back from whereever in a few weeks?! -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 22:44:17 1994 Newsgroups: culist.netbsd.current Path: mcr From: mcr@sandelman.ocunix.on.ca (Michael Richardson) Subject: Re: a couple of IMPORTANT things... Organization: Sandelman Software Works, Debugging Department, Ottawa, ON Distribution: culist Sender: owner-current-users@sun-lamp.cs.berkeley.edu In a previous article, cgd wrote: >> you're running -current right now, you'll NEED to upgrade >> again. If you've not yet done the first upgrade, DO IT NOW, >> or you'll be somewhat SOL after this weekend -- yes, the >> binary snapshots will prolly be useful, but... Here is a plea for a 0.95 release of base09. Please? Setting up new systems is harder and harder. I considered loading FreeBSD, but I have to share my CVS tree between 386 and Sun-port... (I just moved a disk from a 3/60 to a 386+adaptec card, so now I have enough space to play on the 386 as well) -- :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit mcr@ccs.carleton.ca /of being fun to play with." - p.47 Intro to Quarks&Partons mcr@sandelman.ocunix.on.ca From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 22:45:52 1994 From: Jarle.F.Greipsland@idt.unit.no To: current-users@sun-lamp.cs.berkeley.edu Subject: Floppy problems. Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I've been seeing the same problems as Kim with regards to floppies. I think there are two separate problems here: "disklabel -r fd0" will produce errors because disklabel will assume you want to access /dev/rfd0d ('d' being the default "whole device partition"). With a floppy station differing from a straight 360K one, this means trouble. If the floppy is a pre-labeled BSD floppy "disklabel -r fd0a" will work OK. If the floppy is *not* a BSD floppy both "disklabel -w -r fd0a floppy" and "disklabel -r fd0a" both produces this console output: May 29 15:52:47 darling /netbsd: fd0: read failed st0 40 st1 1 st 2 0 cyl 0 head 0 sec 2 May 29 15:52:47 darling /netbsd: blkno 1 skip 0 cylin 0 status 40 May 29 15:52:47 darling /netbsd: fd0: seek failed st0 80 cyl 1 May 29 15:52:48 darling /netbsd: fd0: read failed st0 40 st1 1 st 2 0 cyl 0 head 0 sec 2 May 29 15:52:48 darling /netbsd: blkno 1 skip 0 cylin 0 status 40 May 29 15:52:48 darling /netbsd: fd0: read failed st0 40 st1 1 st 2 0 cyl 0 head 0 sec 2 May 29 15:52:48 darling /netbsd: blkno 1 skip 0 cylin 0 status 40 May 29 15:52:48 darling /netbsd: fd0: read failed st0 40 st1 1 st 2 0 cyl 0 head 0 sec 2 May 29 15:52:49 darling /netbsd: blkno 1 skip 0 cylin 0 status 40 May 29 15:52:49 darling /netbsd: fd0: read failed st0 40 st1 1 st 2 0 cyl 0 head 0 sec 2 May 29 15:52:49 darling /netbsd: blkno 1 skip 0 cylin 0 status 40 May 29 15:52:49 darling /netbsd: fd0d: hard error reading fsbn 1 (st0 40 st1 1 st2 0 cyl 0 hd 0 sec 2) The labeling however will succeed...... I think the error messages are caused by a piece of code in readdisklabel() around line 100 in /sys/arch/i386/i386/disksubr.c: /* request no partition relocation by driver on I/O operations */ bp->b_dev = makedev(major(dev), dkminor((dkunit(dev)), 3)); Isn't this a hardcoded reference to partition 'd'? This might explain why it tries to read from fd0d. I may be wrong though..... -jarle ---- "-rw-rw-rw-: file permissions of the Beast" From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 22:51:52 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rhealey@aggregate.com Subject: Re: When is the next sup update? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Anybody know when the next sup update will be done? Are you referring to the `nightly CVS update' or the tar files? I'll try to make sure both get done tonight. From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 22:58:21 1994 From: mycroft@gnu.ai.mit.edu To: bdc@ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: USENIX Sender: owner-current-users@sun-lamp.cs.berkeley.edu where is usenix this year anyway? Summer Usenix is in Boston, at the Copley Marriott, June 6-10. It's just a T ride away from you. B-) From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 23:01:07 1994 From: phil@cs.wwu.edu (Phil Nelson) To: current-users@sun-lamp.cs.berkeley.edu Subject: X server always running Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am running X-2.1.1 (May 16 binary) and have noticed that /usr/X386/bin/X is *always* running. Things appear to work, but the smallest load is 1.00. I'm using a 486 and a logitech bus mouse. Does anyone know what is happening here? -Phil From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 23:06:46 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, phil@cs.wwu.edu Subject: Re: X server always running Sender: owner-current-users@sun-lamp.cs.berkeley.edu You didn't say what era your kernel is from. For a few days there was a bug in the pccons select() handling that caused the X server to chew CPU time. This has been fixed since (you guessed it) May 16th. (the bug was actually an error in the device switch table in conf.c.) From owner-current-users@sun-lamp.cs.berkeley.edu Sun May 29 23:53:08 1994 From: gregc@edi.com (Greg Cronau) Subject: Newfs Minfree at 5% 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: 1002 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I noticed this one a while back and forgot about it. When I first installed 0.9 I used it's newfs to create all my file systems. My HP drive uses a translation scheme that reports 128 heads so the cylinder groups were huge. Somewhere around 56meg. When I installed -current I decided to remake the filesystem on /usr/local with a smaller cylinder group size to see how that might affect performance. I wound up with *more* space when I was done. I finnally figured out that the -current newfs has a default value for minfree of 5%, instead of the normal 10%. I can see 3 possible explanations: 1.) The filesystem under -current has been tweaked in such a manner that the performance difference between 10% and 5% is trivial so why bother. 2.) This is a mistake. It should default to 10%. 3.) It's not a mistake, it was intentionally set to 5% as the new default, but you take a performance hit and it should be raised to 10% for better performance. Anybody got any ideas? Gregc@edi.com for better performance. Anybody got any ideas? Gregc@edi.com From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 00:11:40 1994 From: msanders@eng.utah.edu Subject: Ethernet support... To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 293 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Is anyone working on drivers for Ethernet cards other than the A2065 and Ameristar? I'm about ready to give up on trying to find an A2065. :) -- Michael K. Sanders Avoid Quiet and Placid persons unless you are in Need of Sleep. -- National Lampoon, "Deteriorada" From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 00:12:00 1994 From: Christos Zoulas 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: current-users@sun-lamp.cs.berkeley.edu Subject: diffs for arp, bootpd, netboot, pppd, rarpd Sender: owner-current-users@sun-lamp.cs.berkeley.edu The following is a set of diffs that should help to get the whole source tree to compile. Except for the netboot diff [double inclusion of ], all the rest are related to the deletion of SIOCGARP, SIOCSARP. I guess someone should delete 'struct arpreq' , since it is not used anywhere. Since it is not very simple anymore to set and delete arp addresses (it takes a almost 100 lines of code!), I broke out the parts that do this from arp.c into arplib.c and arplib.h. All the programs now use those two files. I only tested the changes in arp.c, and I will be testing the pppd and rarpd changes as soon as I ftp a new binary distribution to my home machine. While I was at it, I cleaned up arp.c a bit and fixed the documented -f flag which was missing from the getopt parsing. Enjoy, christos PS: Theo I want a cookie! #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'arp.diff' <<'END_OF_FILE' X*** Makefile.dist Tue May 17 06:56:12 1994 X--- Makefile Sun May 29 14:29:55 1994 X*************** X*** 4,9 **** X--- 4,10 ---- X PROG= arp X MAN8= arp.0 X CLEANFILES=arp4.0 X+ SRCS= arp.c arplib.c X X .if !defined(NOMAN) X all: ${PROG} arp4.0 ${MAN8} X*** arp.c.dist Fri May 13 07:54:34 1994 X--- arp.c Sun May 29 14:53:24 1994 X*************** X*** 66,119 **** X #include X X #include X- #include X- #include X #include X #include X X- extern int errno; X- static int pid; X- static int kflag; X static int nflag; X! static int s = -1; X X main(argc, argv) X int argc; X char **argv; X { X int ch; X X! pid = getpid(); X! while ((ch = getopt(argc, argv, "ands")) != EOF) X! switch((char)ch) { X case 'a': X! dump(0); X! exit(0); X case 'd': X if (argc < 3 || argc > 4) X! usage(); X! delete(argv[2], argv[3]); X! exit(0); X case 'n': X nflag = 1; X continue; X case 's': X if (argc < 4 || argc > 7) X! usage(); X! exit(set(argc-2, &argv[2]) ? 1 : 0); X case '?': X default: X! usage(); X } X if (argc != 2) X! usage(); X! get(argv[1]); X! exit(0); X } X X /* X * Process a file to set standard arp entries X */ X file(name) X char *name; X { X--- 66,141 ---- X #include X X #include X #include X+ #include X #include X+ #include X+ #include X+ #include X+ #include X+ #include "arplib.h" X+ X+ extern const char *__progname; X X static int nflag; X! static void *ap = NULL; X! X! static int dump __P((u_long)); X! static int usage __P((void)); X! static int delete __P((char *, char *)); X! static int set __P((int argc, char **)); X! static int get __P((char *)); X! static int file __P((char *)); X! static void ether_print __P((u_char *)); X! X X+ int X main(argc, argv) X int argc; X char **argv; X { X int ch; X X! while ((ch = getopt(argc, argv, "andsf:")) != EOF) X! switch(ch) { X case 'a': X! return dump(0); X! X case 'd': X if (argc < 3 || argc > 4) X! return usage(); X! return delete(argv[2], argv[3]); X! X case 'n': X nflag = 1; X continue; X+ X case 's': X if (argc < 4 || argc > 7) X! return usage(); X! return set(argc-2, &argv[2]) ? 1 : 0; X! X! case 'f': X! return file(optarg); X! X case '?': X default: X! return usage(); X } X+ X if (argc != 2) X! return usage(); X! X! if (ap != NULL) X! arp_close(ap); X! X! return get(argv[1]); X } X X /* X * Process a file to set standard arp entries X */ X+ static int X file(name) X char *name; X { X*************** X*** 122,129 **** X char line[100], arg[5][50], *args[5]; X X if ((fp = fopen(name, "r")) == NULL) { X! fprintf(stderr, "arp: cannot open %s\n", name); X! exit(1); X } X args[0] = &arg[0][0]; X args[1] = &arg[1][0]; X--- 144,151 ---- X char line[100], arg[5][50], *args[5]; X X if ((fp = fopen(name, "r")) == NULL) { X! fprintf(stderr, "%s: cannot open %s\n", __progname, name); X! return -1; X } X args[0] = &arg[0][0]; X args[1] = &arg[1][0]; X*************** X*** 135,358 **** X i = sscanf(line, "%s %s %s %s %s", arg[0], arg[1], arg[2], X arg[3], arg[4]); X if (i < 2) { X! fprintf(stderr, "arp: bad line: %s\n", line); X! retval = 1; X continue; X } X if (set(i, args)) X! retval = 1; X } X fclose(fp); X return (retval); X } X X! getsocket() { X! if (s < 0) { X! s = socket(PF_ROUTE, SOCK_RAW, 0); X! if (s < 0) { X! perror("arp: socket"); X! exit(1); X } X } X } X X- struct sockaddr_in so_mask = {8, 0, 0, { 0xffffffff}}; X- struct sockaddr_inarp blank_sin = {sizeof(blank_sin), AF_INET }, sin_m; X- struct sockaddr_dl blank_sdl = {sizeof(blank_sdl), AF_LINK }, sdl_m; X- int expire_time, flags, export_only, doing_proxy, found_entry; X- struct { X- struct rt_msghdr m_rtm; X- char m_space[512]; X- } m_rtmsg; X X /* X * Set an individual arp entry X */ X set(argc, argv) X int argc; X char **argv; X { X! struct hostent *hp; X! register struct sockaddr_inarp *sin = &sin_m; X! register struct sockaddr_dl *sdl; X! register struct rt_msghdr *rtm = &(m_rtmsg.m_rtm); X! u_char *ea; X char *host = argv[0], *eaddr = argv[1]; X X- getsocket(); X argc -= 2; X argv += 2; X! sdl_m = blank_sdl; X! sin_m = blank_sin; X! sin->sin_addr.s_addr = inet_addr(host); X! if (sin->sin_addr.s_addr == -1) { X! if (!(hp = gethostbyname(host))) { X! fprintf(stderr, "arp: %s: ", host); X! herror((char *)NULL); X! return (1); X! } X! bcopy((char *)hp->h_addr, (char *)&sin->sin_addr, X! sizeof sin->sin_addr); X } X! ea = (u_char *)LLADDR(&sdl_m); X! if (ether_aton(eaddr, ea) == 0) X! sdl_m.sdl_alen = 6; X! doing_proxy = flags = export_only = expire_time = 0; X while (argc-- > 0) { X if (strncmp(argv[0], "temp", 4) == 0) { X! struct timeval time; X! gettimeofday(&time, 0); X! expire_time = time.tv_sec + 20 * 60; X } X else if (strncmp(argv[0], "pub", 3) == 0) { X! flags |= RTF_ANNOUNCE; X! doing_proxy = SIN_PROXY; X } else if (strncmp(argv[0], "trail", 5) == 0) { X printf("%s: Sending trailers is no longer supported\n", X host); X } X argv++; X } X! tryagain: X! if (rtmsg(RTM_GET) < 0) { X! perror(host); X! return (1); X! } X! sin = (struct sockaddr_inarp *)(rtm + 1); X! sdl = (struct sockaddr_dl *)(sin->sin_len + (char *)sin); X! if (sin->sin_addr.s_addr == sin_m.sin_addr.s_addr) { X! if (sdl->sdl_family == AF_LINK && X! (rtm->rtm_flags & RTF_LLINFO) && X! !(rtm->rtm_flags & RTF_GATEWAY)) switch (sdl->sdl_type) { X! case IFT_ETHER: case IFT_FDDI: case IFT_ISO88023: X! case IFT_ISO88024: case IFT_ISO88025: X! goto overwrite; X! } X! if (doing_proxy == 0) { X! printf("set: can only proxy for %s\n", host); X! return (1); X! } X! if (sin_m.sin_other & SIN_PROXY) { X! printf("set: proxy entry exists for non 802 device\n"); X! return(1); X } X! sin_m.sin_other = SIN_PROXY; X! export_only = 1; X! goto tryagain; X! } X! overwrite: X! if (sdl->sdl_family != AF_LINK) { X! printf("cannot intuit interface index and type for %s\n", host); X! return (1); X! } X! sdl_m.sdl_type = sdl->sdl_type; X! sdl_m.sdl_index = sdl->sdl_index; X! return (rtmsg(RTM_ADD)); X } X X /* X * Display an individual arp entry X */ X get(host) X char *host; X { X! struct hostent *hp; X! struct sockaddr_inarp *sin = &sin_m; X! u_char *ea; X X! sin_m = blank_sin; X! sin->sin_addr.s_addr = inet_addr(host); X! if (sin->sin_addr.s_addr == -1) { X! if (!(hp = gethostbyname(host))) { X! fprintf(stderr, "arp: %s: ", host); X! herror((char *)NULL); X! exit(1); X! } X! bcopy((char *)hp->h_addr, (char *)&sin->sin_addr, X! sizeof sin->sin_addr); X! } X! dump(sin->sin_addr.s_addr); X! if (found_entry == 0) { X! printf("%s (%s) -- no entry\n", X! host, inet_ntoa(sin->sin_addr)); X! exit(1); X } X } X X /* X * Delete an arp entry X */ X delete(host, info) X char *host; X char *info; X { X! struct hostent *hp; X! register struct sockaddr_inarp *sin = &sin_m; X! register struct rt_msghdr *rtm = &m_rtmsg.m_rtm; X! struct sockaddr_dl *sdl; X! u_char *ea; X! char *eaddr; X X if (info && strncmp(info, "pro", 3) ) X! export_only = 1; X! getsocket(); X! sin_m = blank_sin; X! sin->sin_addr.s_addr = inet_addr(host); X! if (sin->sin_addr.s_addr == -1) { X! if (!(hp = gethostbyname(host))) { X! fprintf(stderr, "arp: %s: ", host); X! herror((char *)NULL); X! return (1); X! } X! bcopy((char *)hp->h_addr, (char *)&sin->sin_addr, X! sizeof sin->sin_addr); X! } X! tryagain: X! if (rtmsg(RTM_GET) < 0) { X! perror(host); X! return (1); X! } X! sin = (struct sockaddr_inarp *)(rtm + 1); X! sdl = (struct sockaddr_dl *)(sin->sin_len + (char *)sin); X! if (sin->sin_addr.s_addr == sin_m.sin_addr.s_addr) { X! if (sdl->sdl_family == AF_LINK && X! (rtm->rtm_flags & RTF_LLINFO) && X! !(rtm->rtm_flags & RTF_GATEWAY)) switch (sdl->sdl_type) { X! case IFT_ETHER: case IFT_FDDI: case IFT_ISO88023: X! case IFT_ISO88024: case IFT_ISO88025: X! goto delete; X } X } X! if (sin_m.sin_other & SIN_PROXY) { X! fprintf(stderr, "delete: can't locate %s\n",host); X! return (1); X! } else { X! sin_m.sin_other = SIN_PROXY; X! goto tryagain; X! } X! delete: X! if (sdl->sdl_family != AF_LINK) { X! printf("cannot locate %s\n", host); X! return (1); X } X! if (rtmsg(RTM_DELETE) == 0) X! printf("%s (%s) deleted\n", host, inet_ntoa(sin->sin_addr)); X } X X /* X * Dump the entire arp table X */ X dump(addr) X u_long addr; X { X int mib[6]; X size_t needed; X! char *host, *malloc(), *lim, *buf, *next; X struct rt_msghdr *rtm; X struct sockaddr_inarp *sin; X struct sockaddr_dl *sdl; X extern int h_errno; X struct hostent *hp; X X mib[0] = CTL_NET; X mib[1] = PF_ROUTE; X--- 157,321 ---- X i = sscanf(line, "%s %s %s %s %s", arg[0], arg[1], arg[2], X arg[3], arg[4]); X if (i < 2) { X! fprintf(stderr, "%s: bad line: %s\n", __progname, line); X! retval = -1; X continue; X } X if (set(i, args)) X! retval = -1; X } X fclose(fp); X return (retval); X } X X! X! /* X! * get a host name or address X! */ X! static int X! gethost(host, ia) X! const char* host; X! struct in_addr *ia; X! { X! X! struct hostent *hp; X! X! ia->s_addr = inet_addr(host); X! X! if (ia->s_addr == -1) { X! if (!(hp = gethostbyname(host))) { X! fprintf(stderr, "%s: %s: ", __progname, host); X! herror((char *)NULL); X! return -1; X } X+ memcpy(ia, hp->h_addr, sizeof *ia); X } X+ return 0; X } X X X /* X * Set an individual arp entry X */ X+ static int X set(argc, argv) X int argc; X char **argv; X { X! struct in_addr ia; X! int flags = ARP_NONE; X char *host = argv[0], *eaddr = argv[1]; X+ u_char ea[6]; X X argc -= 2; X argv += 2; X! X! if (gethost(host, &ia) == -1) X! return -1; X! X! if (arp_atoe(eaddr, ea) == -1) { X! (void) fprintf(stderr, "%s: Bad ethernet address `%s'\n", X! __progname, eaddr); X! return -1; X } X! X while (argc-- > 0) { X if (strncmp(argv[0], "temp", 4) == 0) { X! flags |= ARP_TEMP; X } X else if (strncmp(argv[0], "pub", 3) == 0) { X! flags |= ARP_PROXY; X } else if (strncmp(argv[0], "trail", 5) == 0) { X printf("%s: Sending trailers is no longer supported\n", X host); X } X argv++; X } X! X! if (ap == NULL) { X! if ((ap = arp_open()) == NULL) { X! fprintf(stderr, "%s: %s\n", __progname, arp_error(ap)); X! return -1; X } X! } X! X! if (arp_set(ap, &ia, ea, flags) == -1) { X! fprintf(stderr, "%s: set(%s, %s): %s\n", __progname, X! host, eaddr, arp_error(ap)); X! return -1; X! } X! return 0; X } X X /* X * Display an individual arp entry X */ X+ static int X get(host) X char *host; X { X! struct in_addr ia; X X! if (gethost(host, &ia) == -1) X! return -1; X! X! if (dump(ia.s_addr) == -1) { X! printf("%s (%s) -- no entry\n", host, inet_ntoa(ia)); X! return -1; X } X+ return 0; X } X X /* X * Delete an arp entry X */ X+ static int X delete(host, info) X char *host; X char *info; X { X! struct in_addr ia; X! int flags = ARP_NONE; X X if (info && strncmp(info, "pro", 3) ) X! flags |= ARP_PROXY; X! X! if (gethost(host, &ia) == -1) X! return -1; X! X! if (ap == NULL) { X! if ((ap = arp_open()) == NULL) { X! fprintf(stderr, "%s: %s\n", __progname, arp_error(ap)); X! return -1; X } X } X! X! if (arp_delete(ap, &ia, flags) == -1) { X! fprintf(stderr, "%s: delete(%s): %s\n", __progname, X! host, arp_error(ap)); X! return -1; X } X! X! printf("%s (%s) deleted\n", host, inet_ntoa(ia)); X! return 0; X } X X /* X * Dump the entire arp table X */ X+ static int X dump(addr) X u_long addr; X { X int mib[6]; X size_t needed; X! char *host, *lim, *buf, *next; X struct rt_msghdr *rtm; X struct sockaddr_inarp *sin; X struct sockaddr_dl *sdl; X extern int h_errno; X struct hostent *hp; X+ int found = addr == 0 ? 0 : -1; X X mib[0] = CTL_NET; X mib[1] = PF_ROUTE; X*************** X*** 361,371 **** X mib[4] = NET_RT_FLAGS; X mib[5] = RTF_LLINFO; X if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) X! quit("route-sysctl-estimate"); X if ((buf = malloc(needed)) == NULL) X! quit("malloc"); X if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) X! quit("actual retrieval of routing table"); X lim = buf + needed; X for (next = buf; next < lim; next += rtm->rtm_msglen) { X rtm = (struct rt_msghdr *)next; X--- 324,334 ---- X mib[4] = NET_RT_FLAGS; X mib[5] = RTF_LLINFO; X if (sysctl(mib, 6, NULL, &needed, NULL, 0) < 0) X! err(1, "route-sysctl-estimate"); X if ((buf = malloc(needed)) == NULL) X! err(1, "malloc"); X if (sysctl(mib, 6, buf, &needed, NULL, 0) < 0) X! err(1, "actual retrieval of routing table"); X lim = buf + needed; X for (next = buf; next < lim; next += rtm->rtm_msglen) { X rtm = (struct rt_msghdr *)next; X*************** X*** 374,380 **** X if (addr) { X if (addr != sin->sin_addr.s_addr) X continue; X! found_entry = 1; X } X if (nflag == 0) X hp = gethostbyaddr((caddr_t)&(sin->sin_addr), X--- 337,343 ---- X if (addr) { X if (addr != sin->sin_addr.s_addr) X continue; X! found = 1; X } X if (nflag == 0) X hp = gethostbyaddr((caddr_t)&(sin->sin_addr), X*************** X*** 407,515 **** X } X printf("\n"); X } X } X X ether_print(cp) X u_char *cp; X { X! printf("%x:%x:%x:%x:%x:%x", cp[0], cp[1], cp[2], cp[3], cp[4], cp[5]); X } X X- ether_aton(a, n) X- char *a; X- u_char *n; X- { X- int i, o[6]; X- X- i = sscanf(a, "%x:%x:%x:%x:%x:%x", &o[0], &o[1], &o[2], X- &o[3], &o[4], &o[5]); X- if (i != 6) { X- fprintf(stderr, "arp: invalid Ethernet address '%s'\n", a); X- return (1); X- } X- for (i=0; i<6; i++) X- n[i] = o[i]; X- return (0); X- } X X usage() X { X! printf("usage: arp hostname\n"); X! printf(" arp -a [kernel] [kernel_memory]\n"); X! printf(" arp -d hostname\n"); X! printf(" arp -s hostname ether_addr [temp] [pub]\n"); X! printf(" arp -f filename\n"); X! exit(1); X! } X! X! rtmsg(cmd) X! { X! static int seq; X! int rlen; X! register struct rt_msghdr *rtm = &m_rtmsg.m_rtm; X! register char *cp = m_rtmsg.m_space; X! register int l; X! X! errno = 0; X! if (cmd == RTM_DELETE) X! goto doit; X! bzero((char *)&m_rtmsg, sizeof(m_rtmsg)); X! rtm->rtm_flags = flags; X! rtm->rtm_version = RTM_VERSION; X! X! switch (cmd) { X! default: X! fprintf(stderr, "arp: internal wrong cmd\n"); X! exit(1); X! case RTM_ADD: X! rtm->rtm_addrs |= RTA_GATEWAY; X! rtm->rtm_rmx.rmx_expire = expire_time; X! rtm->rtm_inits = RTV_EXPIRE; X! rtm->rtm_flags |= (RTF_HOST | RTF_STATIC); X! sin_m.sin_other = 0; X! if (doing_proxy) { X! if (export_only) X! sin_m.sin_other = SIN_PROXY; X! else { X! rtm->rtm_addrs |= RTA_NETMASK; X! rtm->rtm_flags &= ~RTF_HOST; X! } X! } X! /* FALLTHROUGH */ X! case RTM_GET: X! rtm->rtm_addrs |= RTA_DST; X! } X! #define NEXTADDR(w, s) \ X! if (rtm->rtm_addrs & (w)) { \ X! bcopy((char *)&s, cp, sizeof(s)); cp += sizeof(s);} X! X! NEXTADDR(RTA_DST, sin_m); X! NEXTADDR(RTA_GATEWAY, sdl_m); X! NEXTADDR(RTA_NETMASK, so_mask); X! X! rtm->rtm_msglen = cp - (char *)&m_rtmsg; X! doit: X! l = rtm->rtm_msglen; X! rtm->rtm_seq = ++seq; X! rtm->rtm_type = cmd; X! if ((rlen = write(s, (char *)&m_rtmsg, l)) < 0) { X! if (errno != ESRCH || cmd != RTM_DELETE) { X! perror("writing to routing socket"); X! return (-1); X! } X! } X! do { X! l = read(s, (char *)&m_rtmsg, sizeof(m_rtmsg)); X! } while (l > 0 && (rtm->rtm_seq != seq || rtm->rtm_pid != pid)); X! if (l < 0) X! (void) fprintf(stderr, "arp: read from routing socket: %s\n", X! strerror(errno)); X! return (0); X! } X! X! quit(msg) X! char *msg; X! { X! fprintf(stderr, "%s\n", msg); X! exit(1); X } X--- 370,396 ---- X } X printf("\n"); X } X+ return found; X } X X+ X+ static void X ether_print(cp) X u_char *cp; X { X! char buf[1024]; X! arp_etoa(cp, buf); X! fputs(buf, stdout); X } X X X+ static int X usage() X { X! printf("usage: %s [-n] hostname\n", __progname); X! printf(" %s [-n] -a [kernel] [kernel_memory]\n", __progname); X! printf(" %s [-n] -d hostname\n", __progname); X! printf(" %s [-n] -s hostname ether_addr [temp] [pub]\n", __progname); X! printf(" %s [-n] -f filename\n", __progname); X! return 1; X } X*** arplib.c.dist Sun May 29 15:27:28 1994 X--- arplib.c Sun May 29 14:52:07 1994 X*************** X*** 0 **** X--- 1,387 ---- X+ /* $Header$ */ X+ /* X+ * arplib.c: Library to manage an list of arp entries. X+ */ X+ X+ #include "arplib.h" X+ X+ #include X+ #include X+ #include X+ X+ #include X+ #include X+ #include X+ #include X+ X+ #include X+ X+ #include X+ X+ #include X+ #include X+ #include X+ #include X+ #include X+ #include X+ X+ struct arp_msg { X+ struct rt_msghdr m_rtm; X+ char m_space[512]; X+ }; X+ X+ struct arp_state { X+ int as_seq; X+ int as_fd; X+ pid_t as_pid; X+ struct sockaddr_inarp as_sia; X+ struct sockaddr_dl as_sid; X+ struct sockaddr_in as_mask; X+ struct arp_msg as_msg; X+ char* as_err; X+ int as_errno; X+ }; X+ X+ static const char ether_fmt[] = "%x:%x:%x:%x:%x:%x"; X+ X+ void * X+ arp_open() X+ { X+ struct arp_state *as; X+ X+ if ((as = malloc(sizeof(struct arp_state))) == NULL) X+ return NULL; X+ X+ if ((as->as_fd = socket(PF_ROUTE, SOCK_RAW, 0)) == -1) { X+ free(as); X+ return NULL; X+ } X+ X+ as->as_mask.sin_len = 8; X+ as->as_mask.sin_family = AF_UNSPEC; X+ as->as_mask.sin_port = 0; X+ as->as_mask.sin_addr.s_addr = 0xffffffff; X+ as->as_err = NULL; X+ as->as_errno = 0; X+ memset(as->as_mask.sin_zero, 0, sizeof(as->as_mask.sin_zero)); X+ X+ as->as_pid = getpid(); X+ as->as_seq = 0; X+ return (void *) as; X+ } X+ X+ X+ void X+ arp_close(vas) X+ void *vas; X+ { X+ (void) close(((struct arp_state *) vas)->as_fd); X+ free(vas); X+ } X+ X+ X+ /* arp_atoe(): X+ * Ascii to ether format X+ */ X+ int X+ arp_atoe(ea, p) X+ char *ea; X+ u_char *p; X+ { X+ int i, x[6]; X+ X+ i = sscanf(ea, ether_fmt, &x[0], &x[1], &x[2], &x[3], &x[4], &x[5]); X+ X+ if (i != 6) X+ return -1; X+ X+ for (i = 0; i < 6; i++) X+ p[i] = x[i]; X+ return 0; X+ } X+ X+ /* arp_etoa(): X+ * Ether address to ascii X+ */ X+ void X+ arp_etoa(p, ea) X+ u_char *p; X+ char *ea; X+ { X+ (void) sprintf(ea, ether_fmt, p[0], p[1], p[2], p[3], p[4], p[5]); X+ } X+ X+ X+ static int X+ arp_msg(vas, cmd, flags) X+ void *vas; X+ int cmd; X+ int flags; X+ { X+ struct arp_state *as = (struct arp_state *) vas; X+ struct rt_msghdr *rtm = &as->as_msg.m_rtm; X+ char *cp = as->as_msg.m_space; X+ int l; X+ X+ memset(rtm, 0, sizeof(*rtm)); X+ X+ switch (cmd) { X+ case RTM_ADD: X+ rtm->rtm_addrs = RTA_DST|RTA_GATEWAY; X+ rtm->rtm_inits = RTV_EXPIRE; X+ rtm->rtm_flags = RTF_STATIC; X+ X+ if (flags & ARP_TEMP) { X+ struct timeval tv; X+ gettimeofday(&tv, NULL); X+ rtm->rtm_rmx.rmx_expire = tv.tv_sec + 20 * 60; X+ } X+ else X+ rtm->rtm_rmx.rmx_expire = 0; X+ X+ if (flags & ARP_PROXY) { X+ rtm->rtm_flags |= RTF_ANNOUNCE; X+ if (flags & ARP_EXPORT) { X+ as->as_sia.sin_other = SIN_PROXY; X+ rtm->rtm_flags |= RTF_HOST; X+ } X+ else { X+ rtm->rtm_addrs |= RTA_NETMASK; X+ as->as_sia.sin_other = 0; X+ } X+ } X+ else { X+ as->as_sia.sin_other = 0; X+ rtm->rtm_flags |= RTF_HOST; X+ } X+ break; X+ X+ case RTM_DELETE: X+ case RTM_GET: X+ if (flags & ARP_PROXY) X+ as->as_sia.sin_other = SIN_PROXY; X+ else X+ as->as_sia.sin_other = 0; X+ rtm->rtm_addrs = RTA_DST; X+ break; X+ X+ default: X+ as->as_errno = EINVAL; X+ as->as_err = "Bad arp command"; X+ return -1; X+ } X+ X+ #define NEXTADDR(w, s) \ X+ if (rtm->rtm_addrs & (w)) { \ X+ memcpy(cp, &s, sizeof(s)); \ X+ cp += sizeof(s); \ X+ } X+ X+ NEXTADDR(RTA_DST, as->as_sia); X+ NEXTADDR(RTA_GATEWAY, as->as_sid); X+ NEXTADDR(RTA_NETMASK, as->as_mask); X+ rtm->rtm_version = RTM_VERSION; X+ rtm->rtm_seq = ++(as->as_seq); X+ rtm->rtm_type = cmd; X+ l = rtm->rtm_msglen = cp - (char *)rtm; X+ X+ if (write(as->as_fd, (char *) &as->as_msg, l) == -1) X+ if (errno != ESRCH || cmd != RTM_DELETE) { X+ as->as_errno = errno; X+ return -1; X+ } X+ X+ do X+ l = read(as->as_fd, (char*) &as->as_msg, sizeof(as->as_msg)); X+ while (l > 0 && (rtm->rtm_seq != as->as_seq || X+ rtm->rtm_pid != as->as_pid)); X+ X+ if (l == -1) { X+ as->as_errno = errno; X+ return -1; X+ } X+ else X+ return 0; X+ } X+ X+ X+ static int X+ arp_process(vas, cmd, flags) X+ void *vas; X+ int cmd; X+ int flags; X+ { X+ struct arp_state *as = (struct arp_state *) vas; X+ struct rt_msghdr *rtm = &as->as_msg.m_rtm; X+ struct sockaddr_inarp *sia = &as->as_sia; X+ struct sockaddr_dl *sid = &as->as_sid; X+ struct sockaddr_inarp *sin = (struct sockaddr_inarp *) (rtm + 1); X+ struct sockaddr_dl *sdl; X+ X+ for (;;) { X+ if (arp_msg(vas, RTM_GET, flags) < 0) X+ return -1; X+ X+ sdl = (struct sockaddr_dl *) (((char *) sin) + sin->sin_len); X+ X+ if (sin->sin_addr.s_addr == sia->sin_addr.s_addr) { X+ if (sdl->sdl_family == AF_LINK && X+ (rtm->rtm_flags & RTF_LLINFO) != 0 && X+ (rtm->rtm_flags & RTF_GATEWAY) == 0) X+ switch (sdl->sdl_type) { X+ case IFT_ETHER: X+ case IFT_FDDI: X+ case IFT_ISO88023: X+ case IFT_ISO88024: X+ case IFT_ISO88025: X+ sid->sdl_type = sdl->sdl_type; X+ sid->sdl_index = sdl->sdl_index; X+ return arp_msg(vas, cmd, flags); X+ default: X+ break; X+ } X+ if (cmd == RTM_ADD) { X+ if ((flags & ARP_PROXY) == 0) { X+ as->as_errno = EINVAL; X+ as->as_err = "Cannot proxy"; X+ return -1; X+ } X+ X+ if (sia->sin_other & SIN_PROXY) { X+ as->as_errno = EINVAL; X+ as->as_err = "Proxy exists for non 802 device"; X+ return -1; X+ } X+ flags |= ARP_EXPORT; X+ continue; X+ } X+ X+ } X+ if (cmd == RTM_DELETE) { X+ if (sia->sin_other & SIN_PROXY) { X+ as->as_errno = EINVAL; X+ as->as_err = "Cannot locate host"; X+ return -1; X+ } X+ else X+ flags |= ARP_PROXY; X+ continue; X+ } X+ X+ break; X+ } X+ X+ if (sdl->sdl_family != AF_LINK) { X+ as->as_errno = EINVAL; X+ as->as_err = "Cannot intuit interface index and type"; X+ return -1; X+ } X+ X+ sid->sdl_type = sdl->sdl_type; X+ sid->sdl_index = sdl->sdl_index; X+ return arp_msg(vas, cmd, flags); X+ } X+ X+ int X+ arp_set(vas, ia, ea, flags) X+ void *vas; X+ struct in_addr *ia; X+ u_char *ea; X+ int flags; X+ { X+ struct arp_state *as = (struct arp_state *) vas; X+ struct sockaddr_inarp *sia = &as->as_sia; X+ struct sockaddr_dl *sid = &as->as_sid; X+ X+ as->as_err = NULL; X+ as->as_errno = 0; X+ X+ memset(sid, 0, sizeof(*sid)); X+ memset(sia, 0, sizeof(*sia)); X+ X+ sia->sin_len = sizeof(*sia); X+ sia->sin_family = AF_INET; X+ sia->sin_addr = *ia; X+ X+ sid->sdl_len = sizeof(*sid); X+ sid->sdl_family = AF_LINK; X+ sid->sdl_alen = 6; X+ X+ memcpy(LLADDR(sid), ea, 6); X+ X+ return arp_process(vas, RTM_ADD, flags); X+ } X+ X+ int X+ arp_delete(vas, ia, flags) X+ void *vas; X+ struct in_addr *ia; X+ int flags; X+ { X+ struct arp_state *as = (struct arp_state *) vas; X+ struct sockaddr_inarp *sia = &as->as_sia; X+ X+ as->as_err = NULL; X+ memset(sia, 0, sizeof(*sia)); X+ X+ sia->sin_len = sizeof(*sia); X+ sia->sin_family = AF_INET; X+ sia->sin_addr = *ia; X+ X+ return arp_process(vas, RTM_DELETE, flags); X+ } X+ X+ X+ /* arp_error(): X+ * Print the error from the last call X+ */ X+ const char * X+ arp_error(vas) X+ void *vas; X+ { X+ struct arp_state *as = (struct arp_state *) vas; X+ X+ if (as == NULL) X+ return strerror(errno); X+ if (as->as_err == NULL) X+ return strerror(as->as_errno); X+ X+ return as->as_err; X+ } X+ X+ #ifdef TEST X+ int X+ main(argc, argv) X+ int argc; X+ char *argv[]; X+ { X+ void *a; X+ struct in_addr ia; X+ X+ if ((a = arp_open()) == NULL) { X+ (void) fprintf(stderr, "arp_open: %s\n", arp_error(a)); X+ return 1; X+ } X+ ia.s_addr = inet_addr("149.77.12.253"); X+ X+ if (arp_set(a, &ia, "01:01:02:03:04:05", 0) == -1) { X+ (void) fprintf(stderr, "arp_set: %s\n", arp_error(a)); X+ return 1; X+ } X+ X+ system("arp -a"); X+ X+ if (arp_delete(a, &ia) == -1) { X+ (void) fprintf(stderr, "arp_delete: %s\n", arp_error(a)); X+ return 1; X+ } X+ X+ system("arp -a"); X+ X+ arp_close(a); X+ X+ return 0; X+ } X+ #endif X+ X+ X*** arplib.h.dist Sun May 29 15:27:28 1994 X--- arplib.h Sun May 29 14:40:40 1994 X*************** X*** 0 **** X--- 1,22 ---- X+ /* X+ * arplib.h: Simple library interface to add and delete arp addresses X+ */ X+ #define ARP_NONE 0 X+ #define ARP_TEMP 1 X+ #define ARP_PROXY 2 X+ #define ARP_EXPORT 4 X+ X+ #include X+ #include X+ X+ __BEGIN_DECLS X+ X+ void *arp_open __P((void)); X+ int arp_set __P((void *, struct in_addr *, u_char *, int)); X+ int arp_delete __P((void *, struct in_addr *, int)); X+ void arp_close __P((void *)); X+ const char *arp_error __P((void *)); X+ void arp_etoa __P((u_char *, char *)); X+ int arp_atoe __P((char *, u_char *)); X+ X+ __END_DECLS END_OF_FILE if test 25133 -ne `wc -c <'arp.diff'`; then echo shar: \"'arp.diff'\" unpacked with wrong size! fi # end of 'arp.diff' fi if test -f 'bootpd.diff' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'bootpd.diff'\" else echo shar: Extracting \"'bootpd.diff'\" \(2830 characters\) sed "s/^X//" >'bootpd.diff' <<'END_OF_FILE' X*** Makefile.dist Wed May 25 07:40:39 1994 X--- Makefile Sun May 29 15:34:10 1994 X*************** X*** 7,17 **** X # Remove the -DVEND_CMU if you don't wish to support the "CMU vendor format" X # in addition to the RFC1048 format. X X PROG= bootpd X # Note: PRIVATE=static is defined by default in bootpd.h X! CFLAGS+=-DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU ${FILESPECS} X SRCS= bootpd.c dovend.c readfile.c hash.c dumptab.c \ X! lookup.c getif.c hwaddr.c report.c tzone.c X MAN5= bootptab.0 X MAN8= bootpd.0 X X--- 7,18 ---- X # Remove the -DVEND_CMU if you don't wish to support the "CMU vendor format" X # in addition to the RFC1048 format. X X+ ALIB=${.CURDIR}/../../usr.sbin/arp X PROG= bootpd X # Note: PRIVATE=static is defined by default in bootpd.h X! CFLAGS+=-DETC_ETHERS -DSYSLOG -DDEBUG -DVEND_CMU ${FILESPECS} -I${ALIB} X SRCS= bootpd.c dovend.c readfile.c hash.c dumptab.c \ X! lookup.c getif.c hwaddr.c report.c tzone.c arplib.c X MAN5= bootptab.0 X MAN8= bootpd.0 X X*************** X*** 19,24 **** X--- 20,27 ---- X X BINDIR=/usr/sbin X X+ .PATH.c: ${ALIB} X+ X .include X X # Additional targets (bootpd is done automatically) X*************** X*** 26,35 **** X CLEANFILES+= bootpef bootpgw bootptest X X bootpef: bootpef.o dovend.o readfile.o hash.o dumptab.o \ X! lookup.o hwaddr.o report.o tzone.o X ${CC} -o ${.TARGET} ${CFLAGS} ${LDFLAGS} ${.ALLSRC} ${LIBS} X X! bootpgw: bootpgw.o getif.o hwaddr.o report.o X ${CC} -o ${.TARGET} ${CFLAGS} ${LDFLAGS} ${.ALLSRC} ${LIBS} X X print-bootp.o : print-bootp.c X--- 29,38 ---- X CLEANFILES+= bootpef bootpgw bootptest X X bootpef: bootpef.o dovend.o readfile.o hash.o dumptab.o \ X! lookup.o hwaddr.o report.o tzone.o arplib.o X ${CC} -o ${.TARGET} ${CFLAGS} ${LDFLAGS} ${.ALLSRC} ${LIBS} X X! bootpgw: bootpgw.o getif.o hwaddr.o report.o arplib.o X ${CC} -o ${.TARGET} ${CFLAGS} ${LDFLAGS} ${.ALLSRC} ${LIBS} X X print-bootp.o : print-bootp.c X*** hwaddr.c.dist Sun May 29 15:16:51 1994 X--- hwaddr.c Sun May 29 15:19:52 1994 X*************** X*** 16,21 **** X--- 16,25 ---- X #include X #include X #endif X+ #ifdef __NetBSD__ X+ #include "arplib.h" X+ #endif X+ X X #include X #include X*************** X*** 71,76 **** X--- 75,81 ---- X u_char *ha; X int len; X { X+ #ifndef __NetBSD__ X struct arpreq arpreq; /* Arp request ioctl block */ X struct sockaddr_in *si; X #ifdef SVR4 X*************** X*** 121,126 **** X--- 126,144 ---- X report(LOG_ERR, "ioctl SIOCSARP: %s", get_errmsg()); X } X #endif /* SVR4 */ X+ #else X+ void *ap; X+ X+ if ((ap = arp_open()) == NULL) { X+ report(LOG_ERR, "arp_open: %s", arp_error(ap)); X+ return; X+ } X+ X+ if (arp_set(ap, ia, ha, ARP_NONE) == -1) X+ report(LOG_ERR, "arp_set: %s", arp_error(ap)); X+ X+ arp_close(ap); X+ #endif /* __NetBSD__ */ X } X X END_OF_FILE if test 2830 -ne `wc -c <'bootpd.diff'`; then echo shar: \"'bootpd.diff'\" unpacked with wrong size! fi # end of 'bootpd.diff' fi if test -f 'netboot.diff' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'netboot.diff'\" else echo shar: Extracting \"'netboot.diff'\" \(274 characters\) sed "s/^X//" >'netboot.diff' <<'END_OF_FILE' X*** exec.c.dist Fri Dec 17 01:59:44 1993 X--- exec.c Sun May 29 15:12:24 1994 X*************** X*** 35,41 **** X #include X #include X #include X- #include X #include X #include X X--- 35,40 ---- END_OF_FILE if test 274 -ne `wc -c <'netboot.diff'`; then echo shar: \"'netboot.diff'\" unpacked with wrong size! fi # end of 'netboot.diff' fi if test -f 'pppd.diff' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'pppd.diff'\" else echo shar: Extracting \"'pppd.diff'\" \(4386 characters\) sed "s/^X//" >'pppd.diff' <<'END_OF_FILE' X*** Makefile.dist Sun May 29 15:07:49 1994 X--- Makefile Sun May 29 15:06:13 1994 X*************** X*** 1,12 **** X # $Id: Makefile,v 1.6 1994/05/08 12:16:10 paulus Exp $ X X PROG= pppd X SRCS= main.c magic.c fsm.c lcp.c ipcp.c upap.c chap.c md5.c \ X! auth.c options.c lock.c sys-bsd.c X MAN8= pppd.0 X SUBDIR= pppstats chat X BINMODE=4555 X BINOWN= root X X LDADD= -lcrypt -lutil X DPADD= ${LIBCRYPT} ${LIBUTIL} X--- 1,16 ---- X # $Id: Makefile,v 1.6 1994/05/08 12:16:10 paulus Exp $ X X+ ALIB=${.CURDIR}/../arp X PROG= pppd X SRCS= main.c magic.c fsm.c lcp.c ipcp.c upap.c chap.c md5.c \ X! auth.c options.c lock.c sys-bsd.c arplib.c X MAN8= pppd.0 X SUBDIR= pppstats chat X BINMODE=4555 X BINOWN= root X+ CFLAGS+=-I${ALIB} X+ .PATH.c: ${ALIB} X+ X X LDADD= -lcrypt -lutil X DPADD= ${LIBCRYPT} ${LIBUTIL} X*** sys-bsd.c.dist Mon May 9 06:54:37 1994 X--- sys-bsd.c Sun May 29 15:32:05 1994 X*************** X*** 41,46 **** X--- 41,47 ---- X X #include "pppd.h" X #include "ppp.h" X+ #include "arplib.h" X X static int initdisc = -1; /* Initial TTY discipline */ X extern int kdebugflag; X*************** X*** 445,471 **** X int unit; X u_long hisaddr; X { X! struct arpreq arpreq; X! X! BZERO(&arpreq, sizeof(arpreq)); X! X /* X * Get the hardware address of an interface on the same subnet X * as our local address. X */ X! if (!get_ether_addr(hisaddr, &arpreq.arp_ha)) { X syslog(LOG_ERR, "Cannot determine ethernet address for proxy ARP"); X return 0; X } X X! SET_SA_FAMILY(arpreq.arp_pa, AF_INET); X! ((struct sockaddr_in *) &arpreq.arp_pa)->sin_addr.s_addr = hisaddr; X! arpreq.arp_flags = ATF_PERM | ATF_PUBL; X! if (ioctl(s, SIOCSARP, (caddr_t)&arpreq) < 0) { X! syslog(LOG_ERR, "ioctl(SIOCSARP): %m"); X return 0; X } X X return 1; X } X X--- 446,477 ---- X int unit; X u_long hisaddr; X { X! void *ap; X! struct in_addr ia; X! u_char ea[6]; X /* X * Get the hardware address of an interface on the same subnet X * as our local address. X */ X! if (!get_ether_addr(hisaddr, ea)) { X syslog(LOG_ERR, "Cannot determine ethernet address for proxy ARP"); X return 0; X } X X! if ((ap = arp_open()) == NULL) { X! syslog(LOG_ERR, "arp_open: %s", arp_error(ap)); X! return 0; X! } X! X! ia.s_addr = hisaddr; X! X! if (arp_set(ap, &ia, ea, ARP_EXPORT) == -1) { X! syslog(LOG_ERR, "arp_set: %s", arp_error(ap)); X! arp_close(ap); X return 0; X } X X+ arp_close(ap); X return 1; X } X X*************** X*** 477,491 **** X int unit; X u_long hisaddr; X { X! struct arpreq arpreq; X X! BZERO(&arpreq, sizeof(arpreq)); X! SET_SA_FAMILY(arpreq.arp_pa, AF_INET); X! ((struct sockaddr_in *) &arpreq.arp_pa)->sin_addr.s_addr = hisaddr; X! if (ioctl(s, SIOCDARP, (caddr_t)&arpreq) < 0) { X! syslog(LOG_WARNING, "ioctl(SIOCDARP): %m"); X return 0; X } X return 1; X } X X--- 483,505 ---- X int unit; X u_long hisaddr; X { X! struct in_addr ia; X! void *ap; X X! if ((ap = arp_open()) == NULL) { X! syslog(LOG_ERR, "arp_open: %s", arp_error(ap)); X return 0; X } X+ X+ ia.s_addr = hisaddr; X+ X+ if (arp_delete(ap, &ia, ARP_NONE) == -1) { X+ syslog(LOG_ERR, "arp_delete: %s", arp_error(ap)); X+ arp_close(ap); X+ return 0; X+ } X+ X+ arp_close(ap); X return 1; X } X X*************** X*** 498,504 **** X int X get_ether_addr(ipaddr, hwaddr) X u_long ipaddr; X! struct sockaddr *hwaddr; X { X struct ifreq *ifr, *ifend, *ifp; X u_long ina, mask; X--- 512,518 ---- X int X get_ether_addr(ipaddr, hwaddr) X u_long ipaddr; X! u_char *hwaddr; X { X struct ifreq *ifr, *ifend, *ifp; X u_long ina, mask; X*************** X*** 563,571 **** X * Found the link-level address - copy it out X */ X dla = (struct sockaddr_dl *)&ifr->ifr_addr; X! hwaddr->sa_len = sizeof(struct sockaddr); X! hwaddr->sa_family = AF_UNSPEC; X! BCOPY(LLADDR(dla), hwaddr->sa_data, dla->sdl_alen); X return 1; X } X ifr = (struct ifreq *) ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len); X--- 577,583 ---- X * Found the link-level address - copy it out X */ X dla = (struct sockaddr_dl *)&ifr->ifr_addr; X! BCOPY(LLADDR(dla), hwaddr, dla->sdl_alen); X return 1; X } X ifr = (struct ifreq *) ((char *)&ifr->ifr_addr + ifr->ifr_addr.sa_len); END_OF_FILE if test 4386 -ne `wc -c <'pppd.diff'`; then echo shar: \"'pppd.diff'\" unpacked with wrong size! fi # end of 'pppd.diff' fi if test -f 'rarpd.diff' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'rarpd.diff'\" else echo shar: Extracting \"'rarpd.diff'\" \(2127 characters\) sed "s/^X//" >'rarpd.diff' <<'END_OF_FILE' X*** Makefile.dist Sun May 29 14:31:45 1994 X--- Makefile Sun May 29 14:56:18 1994 X*************** X*** 1,9 **** X # @(#) $Id: Makefile,v 1.1 1993/12/16 05:31:05 deraadt Exp $ X X PROG= rarpd X! SRCS= rarpd.c X X! CFLAGS+=-I${.CURDIR} -DTFTP_DIR=\"/tftpboot\" X X MAN8= rarpd.0 X X--- 1,12 ---- X # @(#) $Id: Makefile,v 1.1 1993/12/16 05:31:05 deraadt Exp $ X X+ ALIB=${.CURDIR}/../arp X PROG= rarpd X! SRCS= rarpd.c arplib.c X X! CFLAGS+=-I${.CURDIR} -I${ALIB} -DTFTP_DIR=\"/tftpboot\" X! X! .PATH.c: ${ALIB} X X MAN8= rarpd.0 X X*** rarpd.c.dist Sun May 29 14:31:51 1994 X--- rarpd.c Sun May 29 14:48:11 1994 X*************** X*** 57,62 **** X--- 57,64 ---- X #include X #include X X+ #include "arplib.h" X+ X #define FATAL 1 /* fatal error occurred */ X #define NONFATAL 0 /* non fatal error occurred */ X X*************** X*** 629,654 **** X u_char *ep; X u_long ipaddr; X { X! int s; X! struct arpreq request; X! struct sockaddr_in *sin; X! X! request.arp_flags = 0; X! sin = (struct sockaddr_in *) & request.arp_pa; X! sin->sin_family = AF_INET; X! sin->sin_addr.s_addr = ipaddr; X! request.arp_ha.sa_family = AF_UNSPEC; X! /* This is needed #if defined(COMPAT_43) && BYTE_ORDER != BIG_ENDIAN, X! because AF_UNSPEC is zero and the kernel assumes that a zero X! sa_family means that the real sa_family value is in sa_len. */ X! request.arp_ha.sa_len = 16; /* XXX */ X! bcopy((char *) ep, (char *) request.arp_ha.sa_data, 6); X! X! s = socket(AF_INET, SOCK_DGRAM, 0); X! if (ioctl(s, SIOCSARP, (caddr_t) & request) < 0) { X! err(NONFATAL, "SIOCSARP: %s", strerror(errno)); X } X! (void) close(s); X } X /* X * Build a reverse ARP packet and sent it out on the interface. X--- 631,650 ---- X u_char *ep; X u_long ipaddr; X { X! void *ap; X! struct in_addr ia; X! X! if ((ap = arp_open()) == NULL) { X! errx(NONFATAL, "arp_open: %s", arp_error(ap)); X! return; X } X! X! ia.s_addr = ipaddr; X! X! if (arp_set(ap, &ia, ep, ARP_NONE) == -1) X! errx(NONFATAL, "arp_set: %s", arp_error(ap)); X! X! arp_close(ap); X } X /* X * Build a reverse ARP packet and sent it out on the interface. END_OF_FILE if test 2127 -ne `wc -c <'rarpd.diff'`; then echo shar: \"'rarpd.diff'\" unpacked with wrong size! fi # end of 'rarpd.diff' fi echo shar: End of shell archive. exit 0 From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 01:01:05 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu Subject: "arp -f": Don't DO that, then! Sender: owner-current-users@sun-lamp.cs.berkeley.edu >While I was at it, I cleaned up arp.c a bit and fixed the documented -f >flag which was missing from the getopt parsing. No! Don't put the -f flag back unless you're very careful about it; it introduces a security hole which lets anyone who cares to read arbitrary parts of /dev/kmem... From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 02:17:35 1994 From: niklas@appli.se (Niklas Hallqvist) To: msanders@eng.utah.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Ethernet support... Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "msanders" == msanders writes: msanders> Is anyone working on drivers for Ethernet cards other than msanders> the A2065 and Ameristar? I'm about ready to give up on msanders> trying to find an A2065. :) Well, yes, I've just got a GoldenGate II bridgecard and are planning to add at least one ISA ethernetadapter driver, maybe more. I also plan to add the usual stuff: COM, LPT, FD & SVGA drivers... Just wondering where to find the time :-) Anyway Ethernet and SVGA are high on my internal wish list. I'll let you know how I'm doing in a weeks time, even if I have nothing done, I ought to have decided which card(s) I'll go for personally... Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 03:45:37 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: stdio question Sender: owner-current-users@sun-lamp.cs.berkeley.edu how can i tell if there is something ready to be read from a NetBSD stdio stream? on a lot of systems if stream is a (FILE *) then stream->cnt _works. this doesnt work on NetBSD. do i want stream->_r? -bri From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 03:48:49 1994 From: niklas@appli.se (Niklas Hallqvist) To: current-users@sun-lamp.cs.berkeley.edu Subject: SMC Ultrachip 83C790QF P driver available? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a SMC card (model number unknown) with a 83C790QF chip on it. Does anybody know if it's compatible with the 83C690 chip, thus compatible with the ed(4) driver? If not, does someone know of any other driver source, DOS, UNIX, whatever? No, I cannot just test it as I don't have a NetBSD/i386 system. I will maybe use this card at one of the ISA slots inside an Amiga 2000 running NetBSD/Amiga, but I need to tweak the common i386/isa/... drivers a bit in order to make them work on an A2000. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 04:47:56 1994 From: cagney@highland.oz.au To: current-users@sun-lamp.cs.berkeley.edu Subject: Those playing with GNU BFD ... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi (I thought of sending this to some of the kernal groups but chance has it more that that are playing with these things). Re: Changing BFD for so it supports netbsd Just a suggestion before everyone gets their own thing going. I've now seen several references to how to modify the: (gas,gdb,binutils)/bfd/* tree to start to support architectures other than just i386 on net bsd. Can I suggest that people doing this follow the naming schema below (so that when it comes to merging, things are easier). This also brings NetBSD into line with the naming scheme that other newer BFD ports are taking. Hopefully with this, only the file bfd/netbsd.h will need merging.... (It's a suggestion, probably an obvious one at that :-) regards Andrew For `configure' specify: --with-targets=-unknown-netbsd For files: bfd/netbsd.h Generic netbsd:a.out definitions bfd/netbsd-.c Defines: eg bfd/netbsd-i386.c bfd_netbsd_i386_vec bfd/netbsd-pmax.c bfd_netbsd_pmax_vec Architecture specific code. (Was netbsd386.c && netbsd386_vec) bfd/config/-netbsd.mt eg bfd/config/i386-netbsd.mt bfd/config/pmax-netbsd.mt Make file stub for different targets. ... From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 05:01:07 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: gregc@edi.com (Greg Cronau) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Newfs Minfree at 5% X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I finnally figured out that the -current newfs has > a default value for minfree of 5%, instead of the normal 10%. I can see > 3 possible explanations: Actually, something a bit weirder than all of this. In 0.9, it was 10%. then it dropped to 5%, and now it's back at 10%. I talked with a few people for a bit about minfree (incl. Kirk McKusick, who would know 8-), and under net/2's UFS, 5% is OK. (i think it's a 1-2% performance drop from 10%, in disk full conditions.) However, with 4.4-Lite's clustering UFS, 10% is appropriate; you need more space so that clusters can be created optimally. So he bumped it back up to 10% in the 4.4-Lite tree, and i did the same in the NetBSD-current tree, so that we'd not have to worry about it later. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 09:29:37 1994 From: "Chris G. Demetriou" X-Authentication-Warning: erewhon.CS.Berkeley.EDU: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@erewhon.CS.Berkeley.EDU X-Phone: Home: (510) 549-3563 X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: the current source tree. X-Mts: smtp Sender: owner-current-users@sun-lamp.cs.berkeley.edu i just got the entire world to compile, and am running its binaries on a couple of machines... This can be taken as a hint that it's a safe time to recompile... 8-) later, chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 10:25:28 1994 From: hm@ernie.hcs.de (Hellmuth Michaelis) Subject: make snapshot: disklabel -r -w /dev/vnd0a To: current-users@sun-lamp.cs.berkeley.edu (NetBSD-current Users) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 516 Sender: owner-current-users@sun-lamp.cs.berkeley.edu When doing a 'make kc_aha.fs' in /usr/src/etc (yes, as root ;-) the command disklabel -r -w /dev/vnd0a floppy5 .../fdboot .../bootfd aborts with the message: disklabel: /dev/vnd0a: Operation not supported by device. Sorcetree version date is May 27th (+/- timezone). Last time i checked this command (around May 1st) it worked perfectly. hellmuth -- Hellmuth Michaelis hm@ernie.hcs.de Prototypes are a crutch for the weak. (John F. Woods) From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 11:06:14 1994 From: msanders@eng.utah.edu Subject: Groups? To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 781 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Okay, I have a (hopefully) simple question about groups. In the process of trying to su to root with a user account, I came up against a wall. I had set the group to 0 (wheel) with vipw for the user, but still got the message 'You are not in the correct group to su to root'. Then I realized that the user wasn't listed in the "wheel" group in /etc/group. After fixing that, all worked fine. So, my question is this: Do I have to manually add users to /etc/group? Why doesn't just setting the gid in /etc/passwd work? I'm just getting into the sysadmin side of UNIX, so please forgive me if this is a stupid question. :) -- Michael K. Sanders Worst Month of 1981 for Downhill Skiing: August. The lines are the shortest, though. -- Steve Rubenstein From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 11:14:47 1994 From: msanders@eng.utah.edu Subject: Re: Ethernet support... To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 805 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Where is the problem in programming your own driver? All you most probably >need to know is the used chipset, the offset of it regarding the 64K io- >block. THen have a look at the existant driver in either the amiga or the >other part of the source tree of the kernel. The only problem with that idea is that I have very little experience [read none] programming device drivers. I'd be willing to give it a try, but I don't actually have an ethernet card yet, so the first hurdle to be overcome is choosing one. Which cards, assuming I'm successful in writing a driver for one, is support most wanted/needed for? I really don't know much about ethernet cards, so I'm open to suggestions. :) >-- >Markus Illenseer -- Michael K. Sanders New crypt. See /usr/news/crypt. From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 11:22:09 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Ethernet support..." (May 29, 3:31pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu (Amiga) Subject: Re: Ethernet support... Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 29, 3:31pm, msanders@eng.utah.edu wrote: > Subject: Ethernet support... > Is anyone working on drivers for Ethernet cards other than the A2065 and > Ameristar? I'm about ready to give up on trying to find an A2065. :) Where is the problem in programming your own driver? All you most probably need to know is the used chipset, the offset of it regarding the 64K io- block. THen have a look at the existant driver in either the amiga or the other part of the source tree of the kernel. -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 12:31:30 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Ethernet support..." (May 30, 2:14am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: msanders@eng.utah.edu, markus@techfak.uni-bielefeld.de (Markus Illenseer) Subject: Re: Ethernet support... Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 30, 2:14am, msanders@eng.utah.edu wrote: > The only problem with that idea is that I have very little experience > [read none] programming device drivers. I'd be willing to give it a try, > but I don't actually have an ethernet card yet, so the first hurdle to > be overcome is choosing one. Which cards, assuming I'm successful in > writing a driver for one, is support most wanted/needed for? I really > don't know much about ethernet cards, so I'm open to suggestions. :) Everybody had to start sometime. As there is no big chioce for Amiga Ethernet Cards, just get one... :-/ Best chances currently are QuickNet-Card from that australian company (no idea who/when/where/how much) and Ariadne from Village Tronic/Germany (the makers of Picasso Gfx, call Expert Servive in the US). M -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 12:35:43 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Groups?" (May 30, 2:19am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu (Amiga) Subject: Re: Groups? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On May 30, 2:19am, msanders@eng.utah.edu wrote: > worked fine. So, my question is this: Do I have to manually add users to > /etc/group? Why doesn't just setting the gid in /etc/passwd work? I'm just > getting into the sysadmin side of UNIX, so please forgive me if this is a > stupid question. :) It's not a stupid question - it's a flame bait question :-) The group-entry in /etc/passwd is for the default-group. All other groups that specific user should be part of must be added to /etc/groups. There is a maximum of 16 groups for each user (an NFS problem i think). Default group for my guest-users is 'guest'. Only one among them is also allowed to use my modem and is thus part of the group 'dial'. Check your users with 'group username' -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon May 30 13:05:51 1994 From: billa@cu.lu (Billa Manou) To: markus@techfak.uni-bielefeld.de Subject: Re: Ethernet support... Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > Date: Mon, 30 May 1994 11:32:38 MET DST > Subject: Re: Ethernet support... > > Best chances currently are QuickNet-Card from that australian company > (no idea who/when/where/how much) and Ariadne from Village Tronic/Germany > (the makers of Picasso Gfx, call Expert Servive in the US). > > > > -- > Markus Illenseer > Hi Markus, Is the Ariadne Ethernet card from Village Tronic already available ??? The German 'AMIGA Magazin' wrote that the card isn't available yet! :( I ask you, because you once mentioned you are in contact with Village Tronic (CeBiT) ;-) Thanx, Manou <><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><> cu Manou BILLA billa@cu.lu // // Life starts at 020... vvvvv \\ // ... Creativity at 030 ... @ @ \X/ ... Fun at 040 ... ____oOO_(_)_OOo___ ... Impotence at '86 ! ... keep on Motorol'ing ;-) From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 13:45:54 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, niklas@appli.se Subject: Re: SMC Ultrachip 83C790QF P driver available? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a SMC card (model number unknown) with a 83C790QF chip on it. Does anybody know if it's compatible with the 83C690 chip, thus compatible with the ed(4) driver? It is *not* completely compatible with the 690 chip. However, the ed driver does have code to support it. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 21:26:44 1994 From: Dave Burgess Subject: Re: Floppy problems To: martin@euterpe.owl.de (Martin Husemann) Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu, kim@dde.dk X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 562 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > That you're trying to newfs or label partition `d'. This is wrong. > > The floppy driver used the low bits of the minor number to specify the > > density. > > Is this documented somewhere beside the source? I couldn't find > it... > > > Martin > > P.S.: on my 1.44 / 3.5" drive /dev/fd0a works with 1.44 MB disks, while > /dev/fd0f works with 720 kB disks > If someone sends me the list, I will document it in the FAQ which is due out tomorrow. The automatic poster is still broke; but I think I've got it fixed. We will know on the 13th. From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 21:47:46 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/rc U src/etc/mtree/BSD.usr.dist M src/gnu/usr.bin/gas/read.c U src/include/Makefile U src/include/nl_types.h U src/lib/libc/Makefile U src/lib/libc/arch/ns32k/sys/exect.S U src/lib/libc/gen/Makefile.inc U src/lib/libc/gen/shmat.c U src/lib/libc/gen/shmctl.c U src/lib/libc/gen/shmdt.c U src/lib/libc/gen/shmget.c U src/lib/libc/gen/sleep.3 U src/lib/libc/gen/sleep.c U src/lib/libc/net/rcmd.c U src/lib/libc/nls/Makefile.inc U src/lib/libc/nls/catclose.3 U src/lib/libc/nls/catgets.3 U src/lib/libc/nls/catopen.3 U src/lib/libc/nls/msgcat.c U src/lib/libc/nls/msgcat.h U src/libexec/bootpd/Makefile U src/libexec/bootpd/Makefile.inc U src/libexec/bootpd/dumptab.c U src/libexec/bootpd/hwaddr.c U src/libexec/bootpd/bootpd/Makefile U src/libexec/bootpd/bootpef/Makefile U src/libexec/bootpd/bootpgw/Makefile U src/libexec/bootpd/bootptest/Makefile U src/sbin/mount_portal/pt_tcp.c U src/sbin/savecore/savecore.c U src/sys/arch/amiga/amiga/autoconf.c C src/sys/arch/amiga/amiga/conf.c U src/sys/arch/amiga/amiga/genassym.c U src/sys/arch/amiga/amiga/locore.s U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/amiga/vm_machdep.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/conf/std.amiga U src/sys/arch/amiga/dev/fd.c U src/sys/arch/amiga/dev/ivsc.c U src/sys/arch/amiga/dev/mlhsc.c U src/sys/arch/amiga/dev/otgsc.c U src/sys/arch/amiga/dev/sci.c U src/sys/arch/amiga/dev/scireg.h U src/sys/arch/amiga/dev/scivar.h U src/sys/arch/amiga/dev/wstsc.c U src/sys/arch/hp300/dev/rd.c U src/sys/arch/hp300/dev/sd.c U src/sys/arch/hp300/hp300/locore.s U src/sys/arch/hp300/hp300/pmap.c U src/sys/arch/hp300/include/profile.h U src/sys/arch/i386/conf/SUN_LAMP U src/sys/arch/i386/i386/genassym.c U src/sys/arch/i386/i386/locore.s U src/sys/arch/i386/i386/trap.c U src/sys/arch/i386/i386/vm_machdep.c U src/sys/arch/i386/include/cpu.h U src/sys/arch/i386/isa/fd.c U src/sys/arch/i386/isa/lpt.c U src/sys/arch/m68k/fpsp/fpsp.U U src/sys/arch/pc532/Makefile U src/sys/arch/pmax/Makefile U src/sys/arch/pmax/compile/.keep_me U src/sys/arch/pmax/conf/ECOFFTEST U src/sys/arch/pmax/conf/GENERIC.pmax U src/sys/arch/pmax/conf/GLUTTON U src/sys/arch/pmax/conf/Makefile.pmax U src/sys/arch/pmax/conf/devices.pmax U src/sys/arch/pmax/conf/files.pmax U src/sys/arch/pmax/dev/asc.c U src/sys/arch/pmax/dev/ascreg.h U src/sys/arch/pmax/dev/cfb.c U src/sys/arch/pmax/dev/cfbreg.h U src/sys/arch/pmax/dev/dc.c U src/sys/arch/pmax/dev/device.h U src/sys/arch/pmax/dev/dtop.c U src/sys/arch/pmax/dev/dtopreg.h U src/sys/arch/pmax/dev/fb.c U src/sys/arch/pmax/dev/fbreg.h U src/sys/arch/pmax/dev/font.c U src/sys/arch/pmax/dev/if_le.c U src/sys/arch/pmax/dev/if_lereg.h U src/sys/arch/pmax/dev/mfb.c U src/sys/arch/pmax/dev/mfbreg.h U src/sys/arch/pmax/dev/pdma.h U src/sys/arch/pmax/dev/pm.c U src/sys/arch/pmax/dev/pmreg.h U src/sys/arch/pmax/dev/rz.c U src/sys/arch/pmax/dev/scc.c U src/sys/arch/pmax/dev/sccreg.h U src/sys/arch/pmax/dev/scsi.c U src/sys/arch/pmax/dev/scsi.h U src/sys/arch/pmax/dev/sii.c U src/sys/arch/pmax/dev/siireg.h U src/sys/arch/pmax/dev/tz.c U src/sys/arch/pmax/dev/xcfb.c U src/sys/arch/pmax/dev/xcfbreg.h U src/sys/arch/pmax/dist/README U src/sys/arch/pmax/dist/README_TOO U src/sys/arch/pmax/dist/buildmini U src/sys/arch/pmax/dist/get U src/sys/arch/pmax/dist/maketape U src/sys/arch/pmax/include/ansi.h U src/sys/arch/pmax/include/cpu.h U src/sys/arch/pmax/include/dc7085cons.h U src/sys/arch/pmax/include/ecoff.h U src/sys/arch/pmax/include/endian.h U src/sys/arch/pmax/include/exec.h U src/sys/arch/pmax/include/float.h U src/sys/arch/pmax/include/kdbparam.h U src/sys/arch/pmax/include/limits.h U src/sys/arch/pmax/include/machAsmDefs.h U src/sys/arch/pmax/include/machConst.h U src/sys/arch/pmax/include/mips_opcode.h U src/sys/arch/pmax/include/param.h U src/sys/arch/pmax/include/pcb.h U src/sys/arch/pmax/include/pmap.h U src/sys/arch/pmax/include/pmioctl.h U src/sys/arch/pmax/include/proc.h U src/sys/arch/pmax/include/profile.h U src/sys/arch/pmax/include/psl.h U src/sys/arch/pmax/include/pte.h U src/sys/arch/pmax/include/ptrace.h U src/sys/arch/pmax/include/reg.h U src/sys/arch/pmax/include/regdef.h U src/sys/arch/pmax/include/reloc.h U src/sys/arch/pmax/include/signal.h U src/sys/arch/pmax/include/stdarg.h U src/sys/arch/pmax/include/trap.h U src/sys/arch/pmax/include/types.h U src/sys/arch/pmax/include/varargs.h U src/sys/arch/pmax/include/vmparam.h U src/sys/arch/pmax/pmax/asic.h U src/sys/arch/pmax/pmax/autoconf.c U src/sys/arch/pmax/pmax/clock.c U src/sys/arch/pmax/pmax/clockreg.h U src/sys/arch/pmax/pmax/conf.c U src/sys/arch/pmax/pmax/cons.c U src/sys/arch/pmax/pmax/cons.h U src/sys/arch/pmax/pmax/disksubr.c U src/sys/arch/pmax/pmax/fp.s U src/sys/arch/pmax/pmax/genassym.c U src/sys/arch/pmax/pmax/kadb.c U src/sys/arch/pmax/pmax/kmin.h U src/sys/arch/pmax/pmax/kn01.h U src/sys/arch/pmax/pmax/kn02.h U src/sys/arch/pmax/pmax/kn03.h U src/sys/arch/pmax/pmax/locore.s U src/sys/arch/pmax/pmax/machdep.c U src/sys/arch/pmax/pmax/maxine.h U src/sys/arch/pmax/pmax/mem.c U src/sys/arch/pmax/pmax/pmap.c U src/sys/arch/pmax/pmax/pmaxtype.h U src/sys/arch/pmax/pmax/process_machdep.c U src/sys/arch/pmax/pmax/swapgeneric.c U src/sys/arch/pmax/pmax/sys_machdep.c U src/sys/arch/pmax/pmax/trap.c U src/sys/arch/pmax/pmax/turbochannel.h U src/sys/arch/pmax/pmax/vm_machdep.c U src/sys/arch/pmax/stand/Makefile U src/sys/arch/pmax/stand/boot.c U src/sys/arch/pmax/stand/conf.c U src/sys/arch/pmax/stand/dec_boot.h U src/sys/arch/pmax/stand/dec_exec.h U src/sys/arch/pmax/stand/dec_label.c U src/sys/arch/pmax/stand/dec_prom.h U src/sys/arch/pmax/stand/mkboot.c U src/sys/arch/pmax/stand/mkboottape.c U src/sys/arch/pmax/stand/rz.c U src/sys/arch/pmax/stand/start.s U src/sys/arch/pmax/stand/libsa/Makefile U src/sys/arch/pmax/stand/libsa/callvec.c U src/sys/arch/pmax/stand/libsa/devopen.c U src/sys/arch/pmax/stand/libsa/getenv.c U src/sys/arch/pmax/stand/libsa/gets.c U src/sys/arch/pmax/stand/libsa/strcat.c U src/sys/arch/pmax/stand/libsa/strcmp.c U src/sys/arch/pmax/stand/libsa/strcpy.c U src/sys/arch/pmax/ultrix/README U src/sys/arch/pmax/ultrix/exec.h U src/sys/arch/pmax/ultrix/ultrix_compat.c U src/sys/arch/pmax/ultrix/ultrix_syscalls.c U src/sys/arch/pmax/ultrix/ultrix_sysent.c U src/sys/arch/sparc/conf/Makefile.sparc U src/sys/arch/sparc/dev/zs.c U src/sys/arch/sparc/sbus/esp.c U src/sys/arch/sparc/sbus/espreg.h U src/sys/arch/sparc/sparc/autoconf.c U src/sys/arch/sparc/sparc/locore.s U src/sys/arch/sun3/conf/GENERIC U src/sys/arch/sun3/conf/SCSITEST U src/sys/arch/sun3/conf/TIMESINK U src/sys/arch/sun3/conf/files.sun3.newconf U src/sys/arch/sun3/dev/if_le.c U src/sys/arch/sun3/dev/if_le.h U src/sys/arch/sun3/dev/if_le_subr.c U src/sys/arch/sun3/dev/if_le_subr.h U src/sys/arch/sun3/dev/if_lereg.h U src/sys/arch/sun3/dev/si.c U src/sys/arch/sun3/dev/zs.c U src/sys/arch/sun3/include/cpu.h U src/sys/arch/sun3/include/param.h U src/sys/arch/sun3/include/pcb.h U src/sys/arch/sun3/include/proc.h U src/sys/arch/sun3/include/profile.h U src/sys/arch/sun3/include/pte.h U src/sys/arch/sun3/sun3/clock.c U src/sys/arch/sun3/sun3/genassym.c U src/sys/arch/sun3/sun3/interrupt.s U src/sys/arch/sun3/sun3/isr.c U src/sys/arch/sun3/sun3/locore.s U src/sys/arch/sun3/sun3/m68k.s U src/sys/arch/sun3/sun3/machdep.c U src/sys/arch/sun3/sun3/mem.c U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/process.s U src/sys/arch/sun3/sun3/signal.s U src/sys/arch/sun3/sun3/softint.s U src/sys/arch/sun3/sun3/trap.c U src/sys/arch/sun3/sun3/trap.s U src/sys/arch/sun3/sun3/vm_machdep.c U src/sys/conf/files U src/sys/conf/files.newconf U src/sys/kern/exec_conf.c U src/sys/kern/exec_ecoff.c U src/sys/kern/init_main.c U src/sys/kern/kern_exec.c U src/sys/kern/sysv_ipc.c U src/sys/kern/vfs_bio.c U src/sys/lib/libnetboot/exec.c U src/sys/net/if_ppp.c U src/sys/sys/exec.h U src/sys/sys/exec_ecoff.h U src/sys/sys/shm.h U src/usr.bin/Makefile U src/usr.bin/gencat/Makefile U src/usr.bin/gencat/gencat.c U src/usr.bin/gencat/gencat.h U src/usr.bin/gencat/genlib.c U src/usr.bin/ipcrm/Makefile U src/usr.bin/ipcs/Makefile U src/usr.bin/nfsstat/Makefile U src/usr.bin/nfsstat/nfsstat.c U src/usr.bin/skey/keyaudit U src/usr.bin/skeyinit/skeyinit.c U src/usr.sbin/pppd/auth.c U src/usr.sbin/pppd/fsm.c U src/usr.sbin/pppd/ipcp.c U src/usr.sbin/pppd/lcp.c U src/usr.sbin/pppd/lcp.h U src/usr.sbin/pppd/main.c U src/usr.sbin/pppd/options.c U src/usr.sbin/pppd/patchlevel.h U src/usr.sbin/pppd/pathnames.h U src/usr.sbin/pppd/pppd.8 U src/usr.sbin/pppd/pppd.h U src/usr.sbin/pppd/sys-bsd.c U src/usr.sbin/pppd/chat/Makefile U src/usr.sbin/pppd/chat/chat.8 U src/usr.sbin/pppd/chat/chat.c U src/usr.sbin/rwhod/rwhod.8 U src/usr.sbin/rwhod/rwhod.c Running the SUP scanner: SUP Scan for current starting at Mon May 30 04:39:40 1994 SUP Scan for current completed at Mon May 30 04:42:04 1994 SUP Scan for mirror starting at Mon May 30 04:42:05 1994 SUP Scan for mirror completed at Mon May 30 04:44:34 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Mon May 30 22:08:50 1994 From: Mats O Jansson To: current-users@sun-lamp.cs.berkeley.edu Subject: ypserv for NetBSD (ALPHA-940529) Cc: maja@celsiustech.se Sender: owner-current-users@sun-lamp.cs.berkeley.edu Now is a new version released for anonymous ftp from: ftp.stacken.kth.se:/pub/OS/NetBSD/ypserv I've just tried to compile it on NetBSD/sparc but there seems to be some include file problems in ypserv_db.c. But I don't known the date of the source, much might have happened. I normaly works on a 386/33MHz PC, and uses a Sun IPC (running NetBSD/sparc or SunOS 4.1.3) as client. It seems like it's time to get a never release of NetBSD to my IPC (and maybe the PC too). Here is the release information from the file README.ypserv-ALPHA-940529 ----- Stockholm 1994-05-29 23:45 This is the second release of "ypserv for NetBSD". New in this release is the rpc.yppasswdd server. The server supports four switches: -noshell don't allow change of shell -nogecos don't allow change of gecos information -nopw don't allow change of password -m [arg1] [arg2] ... pass the following arguments to make The first three switches ain't tested. The server uses routines from usr.sbin/vipw and usr.bin/chpass. This release only has softlinks to the source directories. ypserv has got a new switch: -d use DNS if hosts queries don't find a match in the YP-map. stdhosts now needs inet_aton to be declared in . It have been added recently to the NetBSD. ypinit is the next thing for me to write. As for now there is two makefiles in the ypinit directory: Makefile.main should be copied to /var/yp/Makefile. Any domain that the server should support must be named in the SUBDIR line. eg: SUBDIR= myypdomain Makefile.yp should be copied to /var/yp//Makefile. It is possible to make a cd to /var/yp and then do a make passwd and passwd maps in all supported domains will be rebuild. -moj ------------------------------------------------------------------------------ Mats O Jansson, CelsiusTech Systems, Jaerfaella, Sweden email: maja@celsiustech.se (or moj@stacken.kth.se) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon May 30 22:20:03 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Donn Cave , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: retina console Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 29, 10:33am, Donn Cave wrote: > Does anyone have a Retina working as a console? The Retina Z3 support has only been done on a real old (relatively speaking) kernel, I think. Markus Wild did one that I think was based on the sources on ftp.eunet.net (probably the #744 kernel). I've added the Zorro III address space handling from Markus's code to the kernel sources so that I could get the Warp Engine support working. That stuff should be in the current kernel sources. > It looks to me like the source I'm building, ca. May 22, doesn't support > that. Briefly, the general console initial initialization probes "ite" > out of constab, and the ite probe calls console_config() in the amiga > autoconf.c. There the "mainbus" and "grfcc" devices are explicitly > semi-initialized. When control returns to the ite probe, it finds only > grfcc device, which eventually becomes the console more or less by default. I don't think the Retina console configuration has been completely added to the current kernel. The config_console routine appears to have the ztwobus config disabled. There's a comment about ztwobus knowing that the configuration isn't "for real", but I didn't see any special handling in ztwobus dealing with that. > In order to configure the Retina in time for this console competition, if > I understand what's going on here, the Zorro bus mapping would have to be > advanced to that point as well, so that the Retina device would have a > functional address. (In my case it's the Retina Z3 and hence the Zorro > III bus.) The Zorro II I/O address space is already mapped when the initial MMU map is set up. All the Zorro II devices have to do is figure out the appropriate virtual memory address that maps to their board address. The Zorro III I/O address space had been reserved, but nothing is intially mapped. The zthreebus() configuration takes care of mapping those address spaces when each Zorro III device is configured (currently only the Warp Engine). I'm not certain what needs to be done in ztwobus() and zthreebus() to handle the console initialization. I think Chris Hopps is probably the only person who throughly understands the new configuration process. [I understand it enough to convert some of the SCSI drivers and to add the Zorro III stuff, but some of the details are still rather hazy.] > I'm preparing myself to take a crude stab at doing that, but it sounds a > little dicey. I had been thinking about adding the Retina Z3 driver to the sources before the config.new stuff showed up. Now that I've gotten the 53C710 and 5380 drivers mostly converted and have a working system using the current sources [I'm currently running with the May 26 sources right now], I can probably take a look at adding the Retina Z3 driver, unless you really want to tackle it. I can probably answer some questions about the config process and Zorro III bus stuff if you need some help. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 00:32:06 1994 From: mike@delfin.com (Mike Wlodarczyk) Subject: SMC card death To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sorry to mail to this list but I never got a reply from mycroft@gnu.ai.mit.edu. So maybe someone who had this problem can help. (Yes, it's been a while :-/ ) mycroft@gnu.ai.mit.edu wrote: > > If you've been bitten by this problem, do the following: > 1) Build a kernel from tonight's sources, which have the user-level I/O > by opening /dev/mem fixed. > 2) Jumper the card at one of the two hard-wired settings. > 3) Make sure you booted the kernel from step 1. B-) > 4) Run the attached program, giving it exactly one argument, the address > of the ethernet board. (i.e. `./wdfix 2a0' if the board is at address > 0x2a0.) > 5) Mail me the output of the program, the correct ether address for the > board, and the exact model number. > 6) I'll tell you how to fix the card. Here is the output: % wdfix 300 Current settings (in hex): 300: 21 05 18 2c 80 01 23 00 05 00 c0 d2 56 26 00 ca This is the info from two stickers on the card: WD8013EP D 10911 Network Address 0000C0 D25626 Thanks... -- Mike Wlodarczyk mike@delfin.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 02:45:51 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Re: retina console To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: donn@u.washington.edu, 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: 3547 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu | On May 29, 10:33am, Donn Cave wrote: | > Does anyone have a Retina working as a console? | | The Retina Z3 support has only been done on a real old (relatively | speaking) kernel, I think. Markus Wild did one that I think was | based on the sources on ftp.eunet.net (probably the #744 kernel). | I've added the Zorro III address space handling from Markus's code | to the kernel sources so that I could get the Warp Engine support | working. That stuff should be in the current kernel sources. Yes, my source had a "wesc" device - hadn't really thought about it, but I guess it sounds like I narrowly missed having to fill in a lot more. I started with the Lutz Vieweg/Markus Wild code you mention, and crossed it with the current Retina driver. Probably there aren't more than 15 lines of my own. ... | I don't think the Retina console configuration has been completely | added to the current kernel. The config_console routine appears to | have the ztwobus config disabled. There's a comment about ztwobus | knowing that the configuration isn't "for real", but I didn't see | any special handling in ztwobus dealing with that. Right, I'm quite sure the original Retina driver needs some repairs. Most of the work has been done, but there are some minor nits in addition to the configuration problem. ... | The Zorro II I/O address space is already mapped when the initial MMU | map is set up. All the Zorro II devices have to do is figure out the | appropriate virtual memory address that maps to their board address. | The Zorro III I/O address space had been reserved, but nothing is | initially mapped. The zthreebus() configuration takes care of mapping | these address spaces when each Zorro III device is configured (currently | only the Warp Engine). I'm not certain what needs to be done in ztwobus() | and zthreebus() to handle the console initialization. I think Chris Hopps | is probably the only person who throughly understands the new configuration | process. [I understand it enough to convert some of the SCSI drivers | and to add the Zorro III stuff, but some of the details are still rather | hazy.] Well, I doubt very much that I'm getting ahead of you, but I did come up with a plan to cope with this. Basically, a new table for the Zorro III, describing any devices that should be configured during the preliminary console. The table entry includes the virtual address assigned, so the device won't get re-allocated later. | I had been thinking about adding the Retina Z3 driver to the sources | before the config.new stuff showed up. Now that I've gotten the 53C710 | and 5380 drivers mostly converted and have a working system using the | current sources [I'm currently running with the May 26 sources right | now], I can probably take a look at adding the Retina Z3 driver, unless | you really want to tackle it. I can probably answer some questions | about the config process and Zorro III bus stuff if you need some help. Thanks! Actually, I think I pretty much have it working, though there are a couple of ugly spots. I haven't compiled an X server yet, so that part of it is pretty much untested. (I have a server from eunet, but it doesn't run because it can't open a TCP socket - maybe more syscall incompatibilities.) I haven't done anything for the Zorro II Retina. I will be happy to suggest some minor changes to the driver (e.g., need to set GF_ALIVE), but someone else will have to test it. Haven't looked at the Zorro II setup yet. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 04:01:43 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: SIOCSARP Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 29, 1:51pm, Markus Illenseer wrote: > Building entire new tree with supped sources from yesterday > yielded into some small problems. > > It seems that libexec/bootpd/hwaddr.c requires > a define named 'SIOCSARP' which is not defined anywhere > in the new includes anymore. It was previously found > in either /sys/ioctl.h or sys/sockio.h. > > Same applies for usr/sbin/pppd. > > I think this is due to recent kernel changes and thought i report this, > but i have no idea to hom to report this really... That appears to have been fixed in today's sources (May 30). I think the -current sources hadn't gotten updated between May 26 and May 30. I was able to compile pppd by commenting out the code that referenced SIOPCSARP and was able to get it to run [I'm connected via ppp right now]. I haven't verified today's sources yet - I just finished compiling the libraries and most binaries, but haven't installed them yet. I did get an error trying to build kdump - it has an include of "/sys/kern/syscalls.h". It would appear that it is supposed to be including the system calls names, but it's using an absolute path. If /sys is supposed to be the the kernel source tree, that would make it a bit messy on my system. I've been running with several kernel source trees lately :-). > Another grief. How does one set up a new config for the kernel using > an old kernel and unable to run the new config binary ? :-) I would think you should be able to build /sbin/config.new using the old kernel. Michael From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 07:56:18 1994 From: Jan-Hinrich Fessel Subject: Re: the current source tree. To: cgd@postgres.berkeley.edu (Chris G. Demetriou) Cc: 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: 8bit Content-Length: 520 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > i just got the entire world to compile, and am running its binaries > on a couple of machines... This can be taken as a hint that it's > a safe time to recompile... 8-) Fine. Where can i get the newest current source tree, sun-lamp was unreachable and all others had old tarballs. even when I checked last on May 26 sun-lamp did not have tarballs updated, I had to do a get libkvm.tar in order to get ps working with the tarballs made the weekend around May 15, which were the last ones I could get. Cheers Oskar From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 07:58:10 1994 Newsgroups: culist.netbsd.current Path: mcr From: mcr@sandelman.ocunix.on.ca (Michael Richardson) Subject: Re: SMC Ultrachip 83C790QF P driver available? Organization: Sandelman Software Works, Debugging Department, Ottawa, ON Distribution: culist Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article <9405292353.AA00059@della.appli.se> niklas@appli.se (Niklas Hallqvist) writes: >system. I will maybe use this card at one of the ISA slots >inside an Amiga 2000 running NetBSD/Amiga, but I need to >tweak the common i386/isa/... drivers a bit in order to >make them work on an A2000. Are you using a GoldenGate card? Is this the first edition? (did David make a second edition yet?) The first edition only provides access to I/O space. Last time I looked the WD/SMC drivers (which was somewhere just before 386bsd 0.1 :-), they mapped memory in. You will have to make extensive modification to the driver to get it to not use memory. (Someone correct me if I'm wrong. My sources are not tape right now) I was working on an NE1000 driver for KA9Q under AmigaDOS+GoldenGate card, but since I didn't have a *real* NE1000 (NS evaluation board), and the RESET wire isn't really hooked up on the PC bus (the bridgeboard can be reset independantly of the Amiga, and under software control via the Bridgeboard interface...) the card never properly reset. The primary difference between NS evaluation boards and real NE1000s is that the later have the reset circuit for cleaning up the 8390 when it gets stuck. I have a 3c503 card, which I'll probably put in the 2000 soon. No MMU in my 2000, or I'd be doing the obvious... -- :!mcr!: | "Elegant and extremely rapid for calculation are the Michael Richardson | techniques of Young tableaux. They also have the merit mcr@ccs.carleton.ca /of being fun to play with." - p.47 Intro to Quarks&Partons mcr@sandelman.ocunix.on.ca From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 12:20:12 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: SIOCSARP" (May 30, 7:38pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: osymh@gemini.oscs.montana.edu (Michael L. Hitch), markus@techfak.uni-bielefeld.de (Markus Illenseer), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: SIOCSARP Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 30, 7:38pm, Michael L. Hitch wrote: [...] > the -current sources hadn't gotten updated between May 26 and May 30. Darn - this is exactly in my time-shedule. And now that i no longer have the borroughed drive i can't do any works anymore :-/ [...] > > Another grief. How does one set up a new config for the kernel using > > an old kernel and unable to run the new config binary ? :-) > I would think you should be able to build /sbin/config.new using the > old kernel. Wrong - all new binaries are using new system calls which don't work on kernels which were buildt around 25April-based sources :-} -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 14:35:47 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 Null message body; hope that's ok Subject: sun-lamp CVS update output Updating src and othersrc trees: U doc/CHANGES U src/bin/sh/parser.c M src/gnu/usr.bin/gas/read.c U src/gnu/usr.bin/gdb/gdb/arch/m68k/m68k-nat.c U src/lib/libc/nls/Makefile.inc U src/lib/libskey/skeylogin.c U src/libexec/bootpd/Makefile U src/libexec/bootpgw/Makefile U src/sbin/savecore/savecore.c U src/sys/adosfs/adlookup.c M src/sys/arch/amiga/amiga/conf.c U src/sys/arch/amiga/dev/ite.c U src/sys/arch/amiga/dev/par.c U src/sys/arch/i386/conf/SUN_LAMP U src/sys/arch/pc532/stand/Makefile U src/sys/arch/pc532/stand/README U src/sys/arch/pc532/stand/boot.c U src/sys/arch/pc532/stand/conf.c U src/sys/arch/pc532/stand/cons.c U src/sys/arch/pc532/stand/devopen.c U src/sys/arch/pc532/stand/filesystem.c U src/sys/arch/pc532/stand/machdep.c U src/sys/arch/pc532/stand/prf.c U src/sys/arch/pc532/stand/samachdep.h U src/sys/arch/pc532/stand/scn.c U src/sys/arch/pc532/stand/scsi_hi.c U src/sys/arch/pc532/stand/scsi_low.c U src/sys/arch/pc532/stand/sd.c U src/sys/arch/pc532/stand/so.h U src/sys/arch/pc532/stand/srt0.s U src/sys/arch/pc532/stand/test.c U src/sys/arch/pc532/stand/tgets.c U src/sys/arch/sparc/sparc/pmap.c U src/sys/lib/libsa/rarp.c U src/sys/vm/vnode_pager.c U src/usr.bin/skey/Makefile U src/usr.bin/skey/keyaudit.sh U src/usr.bin/skey/keyinfo.sh U src/usr.bin/vmstat/Makefile U src/usr.bin/vmstat/names.c U src/usr.sbin/bootpef/Makefile U src/usr.sbin/bootptest/Makefile Running the SUP scanner: SUP Scan for current starting at Tue May 31 03:32:59 1994 SUP Scan for current completed at Tue May 31 03:35:19 1994 SUP Scan for mirror starting at Tue May 31 03:35:19 1994 SUP Scan for mirror completed at Tue May 31 03:37:48 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 16:07:27 1994 From: rhealey@aggregate.com Subject: Sup 30 May experiences; mostly works! To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: chopps@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: 1264 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Howdy, I'm just finishing up compiling the whole smash from a 30 May sup. It appears to be in working order except for the following: 1: ite.c, par.c and adosfs/adlookup.c all use the MIN() macro, this should be changed to use the lower case min() function. Additionally, ite.c also uses the MAX() macro, this should be changed to the max() function. 2: On boot, you HAVE to have a floppy in the drive or the boot will stall. Additionally, my 1.76M floppy registers as 0 rather than the AAAAAAA type so the driver doesn't register it as a 3.5hd" floppy unit. 3: In the C library, the makefile can't seem to find the cat*.3 man pages in the nls directory, I manually copyed them up a level and that seemed to satisfy it. 4: On Superkick 3000's you still lose the boot ROM's unless you do the reboot command; i.e. panics and reboot-without-sync ( For fsck problems on root) still require a power cycle to get back the machine. B^(. Looks like I'll have to weed out the more magic bits involved with the SuperKick boot ROM. B^(. Other than that, things appear to be compiling and installing OK. Thanks for all the work on converting to config.new Chris! It was worth the grief! -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:18:30 1994 From: "Robert L. Shady" Subject: Ethernet Problems To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 512 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Howdy... I narrowed down a nice little problem. When I run "pine" across the ethernet, I get the DMA error messages on the NetBSD-current side, and I get TCP checksum errors on the NCSA-Telnet side. This happens consistantly. I never actually get INTO pine, I just type "pine " and everything locks. Pretty nifty, huh? Excerpt from /var/log/messages: May 31 10:55:17 zeus /netbsd: ed0: remote transmit DMA failed to complete May 31 10:55:17 zeus /netbsd: ed0: remote transmit DMA failed to complete From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:18:47 1994 From: Alan Barrett Subject: sup problems 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 What is the most likely cause of sup saying stuff like the following instead of updating properly? It just reports what it would receive if it were working properly, but in fact it receives nothing. was running sup with the "-v" option, using the same supfile that I have used successfully in the past. SUP Would receive new file src/sys/arch/i386/isa/mms.c SUP Would receive new file src/sys/arch/i386/isa/npx.c SUP Would update file src/sys/arch/i386/isa/nvram.h SUP Would receive new file src/sys/arch/i386/isa/pccons.c SUP Would update file src/sys/arch/i386/isa/pcvt/Doc/Acknowledgements --apb (Alan Barrett) From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:22:44 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: tar archives & sup Organization: Analog Devices Inc, Norwood MA, USA X-Attribution: MWL Sender: owner-current-users@sun-lamp.cs.berkeley.edu The tar_files on both ftp.iastate.edu and sun-lamp are dated May 13. I would appreciate it if someone could update them, especially since cgd has told us that it's safe to upgrade with Sunday's sources. :-) Also, has anyone hacked sup so that it can run without a local source tree, on a non-NetBSD machine? My NetBSD box at home has no net access, but I do have net access from a Sun. Disk space is at a premium on the Sun, so I can't keep a copy of the tree there. What I would like is a version of sup that can grab all files from the server modified after a given date and stuff them into a .tar.gz archive. Also included would be a shell script to delete old files. Then I could download and extract the .tar.gz archive, run the update script, and my tree would be up to date. Has anyone done anything like that? -- Mike Long Mike.Long@Analog.com VLSI Design Engineer Analog Devices, SPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:44:04 1994 X-Authentication-Warning: sierra.weeville.com: Host localhost.weeville.com didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: tar_files? X-Mailer: exmh version 1.3 4/7/94 From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu To add my .02cents... Since things are proclaimed "stable", I would love to grab a new set of tar_files, if there were any..... ------------------- -- Randy Terbush From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 18:58:12 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rhealey@aggregate.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Sup 30 May experiences; mostly works! Cc: chopps@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 31, 8:21am, rhealey@aggregate.com wrote: > > Howdy, I'm just finishing up compiling the whole smash from > a 30 May sup. It appears to be in working order except for the > following: > > 1: ite.c, par.c and adosfs/adlookup.c all use the MIN() macro, > this should be changed to use the lower case min() function. > Additionally, ite.c also uses the MAX() macro, this should be > changed to the max() function. Chris knows about these already - he thought he had fixed them before. > 2: On boot, you HAVE to have a floppy in the drive or the boot > will stall. Additionally, my 1.76M floppy registers as 0 > rather than the AAAAAAA type so the driver doesn't register it > as a 3.5hd" floppy unit. Did you put a HD or DD disk in the drive? The ID is based on the type of disk in the drive when it boots. If I have a HD disk in the floppy on my A4000, it is recognized as 3.5hd. I haven't tried booting without a floppy in the drive (the drive is a handy place to keep the floppy I've been using to transfer the kernel from one system to the other). Michael From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:58:54 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: UltraStor 24f Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've written experimental support for the UltraStor 24f controller, but I can't test it. Anyone interested should send me (private) email. From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:59:01 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rls@zeus.id.net Subject: Re: Ethernet Problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu You didn't say what your hardware is. From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 18:59:07 1994 From: mycroft@gnu.ai.mit.edu To: barrett@daisy.ee.und.ac.za, current-users@sun-lamp.cs.berkeley.edu Subject: Re: sup problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sounds like you used the `-f' option, or you have a bad `refuse' file. From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 19:03:52 1994 To: Alan Barrett Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: sup problems X-Mailer: exmh version 1.3 4/7/94 From: John Brezak Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What is the most likely cause of sup saying stuff like the following > instead of updating properly? It just reports what it would receive if > it were working properly, but in fact it receives nothing. was running > sup with the "-v" option, using the same supfile that I have used > successfully in the past. > > SUP Would receive new file src/sys/arch/i386/isa/mms.c > SUP Would receive new file src/sys/arch/i386/isa/npx.c > SUP Would update file src/sys/arch/i386/isa/nvram.h > SUP Would receive new file src/sys/arch/i386/isa/pccons.c > SUP Would update file src/sys/arch/i386/isa/pcvt/Doc/Acknowledgements > > --apb (Alan Barrett) Using the "-f" flag. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5122 From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 19:07:47 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: Re: tar_files. To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 433 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have created some tar_files of the clean src's as supped half an hour ago. They are in ~ftp/pub/NetBSD/NetBSD-current/tar_files. The standard tree is also to be found there, but supping is preferable. Cheerio -- 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 Tue May 31 19:10:23 1994 From: mark@aggregate.com (Mark P. Gooderum) To: cgd@postgres.berkeley.edu, burgess@s069.infonet.net Subject: Re: Newbie SUP question Cc: niklas@appli.se, hoffmann@it.ntu.edu.au, earle@isolar.Tujunga.CA.US, current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1498 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I was having a thought the other night (and those of you familiar with > my previous throughts are permitted to groan at will). > > If we included the /usr/sup files in the tar tree somehow, wouldn't > that keep folks like this (and me the couple of times it has happened > to me) from grabbing ALL of the files in the tree? It shouldn't be > that hard to include the right files in the tar-balls, right? > > Thinking out load, or as close as my keyboard will let me.... This would be great except for one minor problems. The "when" files contain time_t's that are endian dependant. I ran into this when tarring home a src tree from a Sparc to my PC at home. You should have seen the conniptions sup had when it tried to fetch all the changes since May 17, 2014 or some such. Odd bit is it still deleted deleted files...but didn't fetch any new ones or changes. If you "fix" the when files to the proper endianness, then things work properly. This made me think that it would be nice if dd had a swap word or swap long word or similar options so this fixing could easily be done in a shell script. I couldn't find any shell util that did this and had to write a C program to fix it... Another approach would be to patch sup to do a "reality" check on the time stamps and if way out of range with current time, try reversing the byte order, or just change it to use the time stamps on the files instead of the contents (which do get transferred properly by tar et. al.). -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 19:22:24 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: SILLY QUESTION ABOUT UPGRADING Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm in the process of upgrading my system from Mid January sources to current sources. As the first step, I downloaded and compiled the kernel and config sources as of May 30, 1994. The kernel built itself with no hitches and I thought I was well on my way to a successful upgrade, when I tried booting from the new kernel. I got a message that said it couldn't mount root. I realize that this is probably due to the off_t changes that took place some time back, but I don't remember what people were supposed to do to bring their filesystem into line with the current kernel. As a first step, I tried changing the boot blocks, but this did not work. Can someone give me a pointer as to what I must upgrade to run the new kernel? I would like to make as few changes to my current system as possible in order to run the new kernel. It has proved to be stable for months and, in fact, the only reason I'm upgrading is to take advantage of the if_el driver. Here is my configuration file for a 486DX2 (66 MHZ) 16MB of memory, BT445s SCSI controller, two 16550a UARTS, and a cp30540 Conner SCSI drive. Any comments, pointers as to where I should go next would be greatly appreciated. -thanks -Brian # # GENERICAHBBT -- Generic machine w/ahb and bt drivers -- distribution floppy # # $Id: GENERICAHBBT,v 1.25 1994/01/06 12:07:50 cgd Exp $ # machine "i386" cpu "I386_CPU" cpu "I486_CPU" ident NFBNETBSD timezone 8 dst maxusers 40 options SWAPPAGER,VNODEPAGER,DEVPAGER options INET,ISOFS,NFSCLIENT,NFSSERVER,FFS options "COMPAT_43" options "TCP_COMPAT_42" options XSERVER,UCONSOLE options MSDOSFS options KERNFS options SCSI options "MATH_EMULATE" options "COMPAT_09" options "COMPAT_NOMID" options "MACHINE_NONCONTIG" options "NMBCLUSTERS=1024" options KTRACE options FIFOS options "USER_LDT" options GATEWAY config netbsd root on wd0 swap on wd0 and 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_LPT3" irq 7 device lpt1 at isa? port "IO_LPT1" device lpt2 at isa? port "IO_LPT2" 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 ? #device wt0 at isa? port 0x300 irq 5 drq 1 controller bt0 at isa? port "IO_BT0" irq 11 master scsibus0 at bt0 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 uha0 at isa? port "IO_UHA0" irq 11 drq 5 master scsibus2 at uha0 disk sd0 at scsibus2 slave ? disk sd1 at scsibus2 slave ? disk sd2 at scsibus2 slave ? disk sd3 at scsibus2 slave ? tape st0 at scsibus2 slave ? tape st1 at scsibus2 slave ? disk cd0 at scsibus2 slave ? disk cd1 at scsibus2 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 0x280 irq 9 iomem 0xd0000 #device ed1 at isa? port 0x250 irq 9 iomem 0xd8000 #device ed2 at isa? port 0x300 irq 10 iomem 0xcc000 device el0 at isa? port 0x300 irq 9 #device ep0 at isa? port ? irq ? #device ie0 at isa? port 0x360 irq 7 iomem 0xd0000 #device is0 at isa? port 0x320 irq 10 drq 7 device sb0 at isa? port 0x220 bio irq 7 drq 1 vector sbintr device npx0 at isa? port "IO_NPX" irq 13 pseudo-device ether pseudo-device log pseudo-device loop pseudo-device pty 48 pseudo-device sl 1 pseudo-device speaker pseudo-device bpfilter pseudo-device ppp pseudo-device audio From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 19:23:01 1994 From: Herb Peyerl Subject: Re: Newbie SUP question To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu, niklas@appli.se, hoffmann@it.ntu.edu.au X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 957 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : If you "fix" the when files to the proper endianness, then things work : properly. This made me think that it would be nice if dd had a swap word or : swap long word or similar options so this fixing could easily be done in a : shell script. I couldn't find any shell util that did this and had to write : a C program to fix it... Interesting. I stumbled upon this just the other day. I normally sup to a SunOS machine at home with /usr/src being an nfs mount. I then wanted to sup to one of my NetBSD machines which was an i386. So; Charles suggested I use 'rev' to do the swap. worked for me. Of course; 'rev' appends an 0x0a at the end so your 'when' file becomes 5 bytes long but sup doesn't mind for obvious reasons. 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 May 31 19:24:39 1994 From: Holger Veit Subject: Re: Newbie SUP question 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: 8bit Content-Length: 1488 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > This would be great except for one minor problems. The "when" files contain > time_t's that are endian dependant. I ran into this when tarring home a > src tree from a Sparc to my PC at home. You should have seen the conniptions > sup had when it tried to fetch all the changes since May 17, 2014 or some > such. Odd bit is it still deleted deleted files...but didn't fetch any > new ones or changes. > > If you "fix" the when files to the proper endianness, then things work > properly. This made me think that it would be nice if dd had a swap word or > swap long word or similar options so this fixing could easily be done in a > shell script. I couldn't find any shell util that did this and had to write > a C program to fix it... Can someone explain me why the 'when' file is binary at all? Looks as if the CMU developers did too much optimization of file sizes. Writing the # of secs since 1980 as an ASCII number may be 10 bytes compared to 4, but can be read with atol as easily and would avoid the endian hassle for that problem. -- Dr. Holger Veit | INTERNET: Holger.Veit@gmd.de | | / GMD-SET German National Research | Phone: (+49) 2241 14 2448 |__| / Center for Computer Science | Fax: (+49) 2241 14 2342 | | / Schloss Birlinghoven | Had a nightmare yesterday: | |/ 53754 St. Augustin, Germany | My system started up with | ... Booting vmunix.el ... From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 19:53:07 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: tar files Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just updated the tar files on sun-lamp. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 21:33:15 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 (NetBSD Amiga-Dev) Subject: Re: Sup 30 May experiences; mostly works! Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On May 31, 8:33pm, Tero Manninen wrote: > > > 2: On boot, you HAVE to have a floppy in the drive or the boot > > > will stall. Additionally, my 1.76M floppy registers as 0 > > > rather than the AAAAAAA type so the driver doesn't register it > > > as a 3.5hd" floppy unit. > > > > Did you put a HD or DD disk in the drive? The ID is based on the type > > of disk in the drive when it boots. If I have a HD disk in the floppy on > > my A4000, it is recognized as 3.5hd. > > How about if you don't have a floppy drive at all, like me? I'll bet it hangs, and without a floppy drive, you won't be able to insert a floppy. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 21:55:57 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: Sup 30 May experiences; mostly works! To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD Amiga-Dev) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 499 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > 2: On boot, you HAVE to have a floppy in the drive or the boot > > will stall. Additionally, my 1.76M floppy registers as 0 > > rather than the AAAAAAA type so the driver doesn't register it > > as a 3.5hd" floppy unit. > > Did you put a HD or DD disk in the drive? The ID is based on the type > of disk in the drive when it boots. If I have a HD disk in the floppy on > my A4000, it is recognized as 3.5hd. How about if you don't have a floppy drive at all, like me? ++Tero From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 22:01:14 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: panic in pmap_enter() Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <273.770402932.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu With the current distribution as supped May 30th, I get a panic in pmap_enter(). This is on a i486DX on EISA bus, 32Mb RAM, 1740 SCSI adapter. It apparently panics when trying to fork off the init process. Here is the trace that I typed down: panic: pdti 206067 _Debugger _panic _pmap_enter _vm_fault _vm_fault_enter _vm_map_pageable _kmem_alloc _pmap_pinit _vmspace_alloc _vmspace_fork _fork1 _fork _main Any ideas or fixes for this one? My previous kernel build from current as of about May 16-17th is stable with the same configuration otherwise. 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 Tue May 31 22:10:06 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, tholo@sigmasoft.com Subject: Re: panic in pmap_enter() Sender: owner-current-users@sun-lamp.cs.berkeley.edu panic: pdti 206067 Increase NKPDE in /sys/i386/include/pmap.h. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue May 31 23:14:03 1994 From: rhealey@aggregate.com Subject: Re: Sup 30 May experiences; mostly works! To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga-dev@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: 779 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > 2: On boot, you HAVE to have a floppy in the drive or the boot > > will stall. Additionally, my 1.76M floppy registers as 0 > > rather than the AAAAAAA type so the driver doesn't register it > > as a 3.5hd" floppy unit. > > Did you put a HD or DD disk in the drive? The ID is based on the type > of disk in the drive when it boots. If I have a HD disk in the floppy on > my A4000, it is recognized as 3.5hd. I haven't tried booting without a > floppy in the drive (the drive is a handy place to keep the floppy I've > been using to transfer the kernel from one system to the other). > I tried it with both densitys, they both took the default case and returned zero rather than one of the 3 bit patterns. It is drive 0 so that may be an issue. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 23:31:18 1994 From: hm@ernie.altona.ppp.de (Hellmuth Michaelis) Subject: disklabel: /dev/vnd0a: Operation not supported by device To: current-users@sun-lamp.cs.berkeley.edu (NetBSD-current Users) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 698 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I wrote: > When doing a 'make kc_aha.fs' in /usr/src/etc (yes, as root ;-) the command > disklabel -r -w /dev/vnd0a floppy5 .../fdboot .../bootfd aborts with the > message: disklabel: /dev/vnd0a: Operation not supported by device. > > Sorcetree version date is May 27th (+/- timezone). Last time i checked this > command (around May 1st) it worked perfectly. Solution: it seems that the major number for the vnode disk driver was changed from 14 to 15 in conf.c, struct bdevsw. MAKEDEV should be upgraded to generate major number 15 now - after doing it here, everything worked again as advertized. hellmuth -- Hellmuth Michaelis hm@ernie.altona.ppp.de From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 23:33:26 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: SUP questions X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 1115 Sender: owner-current-users@sun-lamp.cs.berkeley.edu While we are speaking about sup, here's my question: I tried to get a reliable way to sup to my home machine, which is connected through a poor 2400 baud modem to my lab. Using term to set up an IP connection, I tried 2 different setups: 1. Supping from sun-lamp directly from home. This has a number of problems. The biggest is the time it takes because it uses one sup connection on sun-lamp for long times since my link is so slow. 2. Supping from sun-lamp to a Sun in my lab, and then running my own supserver to get files to my home. The second solution seems better too me, especially since take advantage of timezones I can sup while most americans are sleeping... However, if the supserver is a sun, sup seems to transmit the whole 'scan' list everytime, whereas supping directly from sun-lamp seems to transmit the list of files newer than the 'when' timestamp. This is not a big deal on fast links, but this initial list transmission takes about 30 minutes at 2400 bauds. Any ideas why this happens ? Thank you in advance. Matthieu PS: I know I should use a faster modem ! From owner-amiga@sun-lamp.cs.berkeley.edu Tue May 31 23:50:31 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: VT220 as console ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu How easy would it be to make the console be a VT220 terminal plugged into the serial port ? Would I need to re-compile the kernel (this is no-problem, I have done it before) or can I just hack around with device files for tty00 and console ? Which source files do I have to change (if any). TIA, John +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Tue May 31 23:54:08 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: panic in pmap_enter() <9405311658.AA18007@goldman.gnu.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <344.770414367.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > panic: pdti 206067 > > Increase NKPDE in /sys/i386/include/pmap.h. Worked like a charm. Thanks! :) 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 |