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