From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 00:14:15 1994 Subject: Austin-Kyoto Common Lisp? From: Brian de Alwis To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 384 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I remember seeing a port of akcl to NetBSD, but I can't remember where. And sun-lamp is too busy to find the mailing list archive... Can anybody help me out? Thanks. -- Brian de Alwis - University of Waterloo: bsdealwis@math.uwaterloo.ca `How extraordinarily lucky Minta is! She is marrying a man who has a gold watch in a wash-leather bag!' - _To_the_Lighthouse_, Virginia Woolf. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 00:18:01 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: setjmp weirdness Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jun 30, 10:54am, newsham@uhunix.uhcc.Hawaii.Edu wrote: > ok.. let me try this again and hopefully get it right: > > #include > > jmp_buf jbuf; > > main() > { > if(!setjmp(jbuf)) { > printf("a\n"); > longjmp(jbuf, 1); > } > printf("b\n"); > } > > Ok. this time I think I filled all the requirements mentioned. > Still prints 'aab' and any subsequent setjmp/longjmp combinations > will behave properly (ie. only the first time through does it > return incorectly). Did you try linking the program with static libraries? I think the problem is due to some run-time relocation in longjump corrupting some 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-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 00:29:55 1994 From: Drew Hess Subject: Re: 3c509 again To: Herb.Peyerl@sidney.novatel.ca (Herb Peyerl) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 2375 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Herb Peyerl writes: > > : I agree with the other poster that VLB systems with more than 2 slots at > : 33MHz should be avoided. I would tend to blame your problems on the fact > : that your VLB board is outside VLB 1.0 specs before condemning VLB as a whole. > : I have one of the earliest VLB designs, a Micronics JX-30 (basically a > : Gateway machine), with an ATI GUP VLB and a Buslogic BT445S, and only 2 VLB > : slots; it has worked flawlessly in NetBSD, Linux, NT, Windows/DOS, and > : OS/2 2.1. > > I'm sorry. I'm not so sure if I buy this. ie: If the thing had N vlb slots > but I was only using 2 of them; does it really matter? ie: only 2 slots > were actually populated at the time. Yes, of course it does. Each physical connector is a capacitive load on the bus; and since VLB 1.0 is basically being driven by the i486 address and data bus drivers, at 33MHz 2 physical connectors is a safe limit. Any number of connectors beyond this point is asking for trouble (the i486 simply can't drive enough current). In fact, you'll notice that the VLB 1.0 spec does not include support for 486DX50s because the 50MHz part simply couldn't drive *any* loads other than the standard external cache, memory controller, etc. VLB 2.0 corrects these limitations by properly isolating the processor's memory bus from the "local bus." > > I dunno; I'd prefer to stick with stuff that seems to have been engineered > with some forethought. Just MHO. > I agree with you that VLB 1.0 is a hack; and some boards (notably the Ultrastor 34F) are notorious for having problems with certain VLB implementations. However, it's a hack that works well if the designers are careful to stay within the spec's guidelines. If you can afford it you should go with PCI or EISA; if you're looking for cheap video performance, a properly implemented VLB machine is a fine solution. (I won't get into the VLB/SCSI argument because nobody seems to agree on whether or not it's a "good thing" for system performance; I'm not sure how I feel about it because I haven't run enough comparisons with various OSes/mboards/controllers/benchmarks. I *will* say that VLB SCSI boards seem to perform better for disk benchmarks than ISA SCSI boards; whether or not they make a difference in system performance (or even hurt it) is what I'm not sure about.) -dwh- dhess@cs.stanford.edu From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 02:26:41 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: setjmp weirdness To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > Did you try linking the program with static libraries? I think the > problem is due to some run-time relocation in longjump corrupting some > registers. Linking it statically gives the proper behavior. > Michael L. Hitch INTERNET: osymh@montana.edu From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 02:30:04 1994 From: Olaf Seibert To: hth@iar.se, newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: setjmp weirdness Cc: amiga@sun-lamp.cs.berkeley.edu, rhialto@mbfys.kun.nl Sender: owner-amiga@sun-lamp.cs.berkeley.edu newsham@uhunix.uhcc.Hawaii.Edu wrote: > #include > > jmp_buf jbuf; > > main() > { > if(!setjmp(jbuf)) { > printf("a\n"); > longjmp(jbuf, 1); > } > printf("b\n"); > } > > Ok. this time I think I filled all the requirements mentioned. > Still prints 'aab' and any subsequent setjmp/longjmp combinations > will behave properly (ie. only the first time through does it > return incorectly). Ok, this really looks like a bug now. -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 Fri Jul 1 03:30:07 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: can't sup 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 haven't been able to sup since yesterday; I get "connection timed out" when trying to connect to sun-lamp, but sun-lamp is obviously up (I can ping/telnet to it fine from my machine) Has sun-lamp's sup server been taken off line recently, or is something broken on my end? --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 05:07:34 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu Michael Hitchens has sent me his if_se driver for DEPCA boards, which I have re-integrated into the if_is driver. I'd like to test this, and I even have a DEPCA board, but I've on idea at all how to configure it. It's an old full-length board with BNC and what looks like a DIN connector. It probably has either 24k or 48k of RAM on board. (Dumb Toshiba chips don't have an easily recognizable part number.) Other than that, all I know are what the various markings say: Could someone with documentation on these beasts tell me how to set the I/O and shared memory addresses, and the IRQ? From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 05:20:45 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu Subject: Please keep 'arch' mounted? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Let me preface this by saying that I know that -current is always under development; that it's not expected to work on a daily basis or work reliably at all, and so forth. Also, I did read the statement that another binary snapshot probably wasn't going to happen until just before the next official release. Which is all perfectly reasonable and sensible, and I have no problem with any of it, nor do I think it's my place to have a problem with it anyway. However, I've got a major project I'm trying to implement using a number of machines running NetBSD-i386, and 0.9 just won't work, for a number of reasons, including the reason that I need immutable files, and also that 0.9's wd driver is just too flaky for continuous use on a machine with only wd disks. I (after blowing things several times trying to upgrade to the latest current, through various foolish actions of my own) had one prototype machine up and running quite nicely; condensing several steps here, I'd upgraded from 0.9 to the latest binary snapshot I had available, used that snapshot to build the current -current, and everything worked. Then, of course, that machine's disk failed. Now, since bootstrapping -current on 0.9 is substantially nontrivial, I don't have any path back to where I was. This is only because ftp.iastate.edu gets the 'arch' distribution by sup from sun-lamp with the -d flag enabled, and because sun-lamp never seems to have 'arch' mounted anymore. If for some reason 'arch' can't stay mounted on sun-lamp, could it be mounted for some stretch of time such that ftp.iastate could sup it, and the iastae stop deleting the files there? This would give an easy upgrade path from 0.9 to current again, instead of a very difficult one. It would also let those of us who don't already have the binary distributions play with the sparc, sun3, and pmax ports. Having recently glommed onto one of each (I don't know whether to _celebrate_ that I have a pmax again or _cry_ :-) I'd like to give things a go, but since I have nowhere to get the binaries from, it's much harder than I'd expect. I don't mean to complain. I don't mean to whine. I hope I'm not doing either. I just think it would be a lot better for everyone involved if at least the May 2 i386 snapshot could be permanently made available somewhere, and not vanish into the void when its filesystem isn't mounted on sun-lamp, which it never seems to be, anymore. Thanks! Thor From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 06:25:52 1994 From: "Missing - presumed fed." 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" , ejh@slueas.slu.edu (Eric J. Haug) Subject: Re: getttyent problem exposed Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Eric, If you want it labeled as an "unsecure" terminal, or even as an "insecure' one (I've run into both cases :-), just drop the word "secure" from the line. The tty will be a non-secure tty unless you explicitly indicate otherwise. -- 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 Wizardry is dead. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 06:34:59 1994 From: "Missing - presumed fed." 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: Drew Hess , Herb.Peyerl@sidney.novatel.ca (Herb Peyerl) Subject: Re: 3c509 again Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu #define AUTHOR "dhess@CS.Stanford.EDU (Drew Hess)" /* * I *will* say that VLB SCSI * boards seem to perform better for disk benchmarks than ISA SCSI boards; * whether or not they make a difference in system performance (or even hurt * it) is what I'm not sure about.) * Forgive me if my viewpoint is inaccurate, but (quick sanity check) last I looked, ISA was 24 bits wide. Not being a kernel engineer, I'm not sure about when a virtual/physical translation occurs (i.e. does the controller deal with the requests in physical or virtual memory -- at first glance it would make more sense that the address is translated before it is handed to the controller, but VM and UNIX being what they are...), but since everything else (EISA, PCI, VLB) runs at 32 bits, ANY kind of SCSI other than ISA SCSI would probably perform better, no? * * -dwh- * dhess@cs.stanford.edu * * * * * */ /*** end two cents worth from Drew Hess ****/ -- 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 -=*=- "Did her eyes at the Turn of the Century tell me plainly How we'll meet, how we'll love? Oh, let life so transform me..." -- Anderson/Howe/White *YES*RUSH*police*genesis*peter_gabriel*jon_anderson*sting*jefferson_airplane* -> James Graham, Songwriter, Musician, Programmer and Hopeless Romantic <- greywolf@autodesk.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 06:46:04 1994 To: bdc@ai.mit.edu (Brian D. Carlstrom) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup <9407010144.AA09611@blackjack> 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 haven't been able to sup since yesterday; I get "connection > > timed out" when trying to connect to sun-lamp, but sun-lamp is > > obviously up (I can ping/telnet to it fine from my machine) Has > > sun-lamp's sup server been taken off line recently, or is > > something broken on my end? > >i've had the same problems, but mycroft said i was deluding myself. >at least its a shared delusion...=) Well, that's comforting :-) But anyway, it's fixed now ... thanks to whoever did it! --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 06:54:51 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Ken Hornstein Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Ken Hornstein writes: > I haven't been able to sup since yesterday; I get "connection > timed out" when trying to connect to sun-lamp, but sun-lamp is > obviously up (I can ping/telnet to it fine from my machine) Has > sun-lamp's sup server been taken off line recently, or is > something broken on my end? i've had the same problems, but mycroft said i was deluding myself. at least its a shared delusion...=) -bri From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 06:57:48 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: recent init behavior change Sender: owner-current-users@sun-lamp.cs.berkeley.edu Commenting out a tty entry from /etc/ttys and hup'ing init used to end spawning of getty on that tty. Now you need an entry with "off" explicitly to do that. christos From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 08:23:22 1994 To: Christos Zoulas Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: recent init behavior change <199407010324.AA24180@cs4.deshaw.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Commenting out a tty entry from /etc/ttys and hup'ing init used to end > spawning of getty on that tty. really? i thought the following: > Now you need an entry with "off" explicitly > to do that. was always the behaviour evidenced... you _sure_ about this? I know i've seen that behaviour in the past... chris From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 08:49:12 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: HELP: cannot restore from my tape anymore !! From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've done the following: 1) make a dump from all my partitions. this was done running the kernel and binaries from April. Command I used was: dump 0dfnsu 54000 /dev/nrst0 13000 /dev/rsdxxx This I did for all my partitions. 2) make a new root on a 'spare' disk. Install the new rootfs, kernel and binaries ( from 15jun ) 3) newfs my old partitions. At first this didn't work, newfs just hung up. But, having bffs on ADOS, I decided to mount my BSD partitions under ADOS and use the newfs command from bffs. No problems so far. 4) Back to NetBSD. No problem mounting the newfs'ed partition(s) 5) cd to new partition(s) 6) give commmand : restore -ivf /dev/nrst0 Aargh: result from restore -> ILLEGAL REQUEST CANNOT SET SELECTED MODE Now I'm stuck. I need to restore my /usr/local and other stuff, but I cannot get my tape drive working anymore. Also, the command mt -f /dev/rst0 stat complains about my tape drive, something like unrecognized type, 7 cannot remember exactly since it was getting pretty late yesterday evening :^) What shall/can I do , besides trying to remember what was on the partition(s) and try to get it back somewhere else. John Vrolijk From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 10:07:48 1994 To: Thor Lancelot Simon Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Please keep 'arch' mounted? From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >If for some reason 'arch' can't stay mounted on >sun-lamp, could it be mounted for some stretch of time such that ftp.iastate >could sup it, and the iastae stop deleting the files there? I'll turn the delete flag off on that distribution for ftp.iastate.edu. If it shows up again, it'll stick this time. >Thor --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 Fri Jul 1 11:00:04 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Re: HELP: cannot restore from my tape anymore !! To: dsnjvro@etmsun.ericsson.se (John Vrolijk) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1833 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | I need to restore my /usr/local and other stuff, but I cannot get my tape drive | working anymore. Also, the command mt -f /dev/rst0 stat complains about | my tape drive, something like | | unrecognized type, 7 | | cannot remember exactly since it was getting pretty late yesterday evening :^) Don't know about the ``can't get selected mode'' error. Have to encourage you to include some little scrap of information about your equipment, when you post questions like this - what model of Amiga, what SCSI controller, what tape drive, etc. I have been looking at the new st driver, though. Basically, the idea seems to be that we shouldn't care about what type of tape drive it is, and in fact that "7" is hard-coded into the driver. Everyone sees this message as the sole response to "mt -f /dev/rst0 status". The implementation could probably use some work, but the concept may have some merit. The old Amiga BSD st driver had lots of special stuff for the Exabyte, for example, while the new st driver knows it not, yet still it gets the 1024-byte block size and the drive functions (at least to read from). Special handling can be set up for certain models, though, and there are actually a handful already accounted for. If your boot messages mention ``rogue'' after identifying the tape device, then the driver really does know what kind of tape you have, despite the message. The special handling may specify specific densities and things for various minor numbers, or it can over-ride some general defaults. I put in an Exabyte stanza so that I could turn off the default to issue a SCSI "load" command, which is just a nuisance with the Exabyte (and I bet most drives). Apart from the question of the drive's identity, I'd like to see mt status report something useful. Donn Cave, donn@cac.washington.edu From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 11:04:35 1994 To: Donn Cave Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: HELP: cannot restore from my tape anymore !! <9407010736.AA23727@saul1.u.washington.edu> From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu >> Special handling can be set up for certain models, though, and there are >> actually a handful already accounted for. If your boot messages mention >> ``rogue'' after identifying the tape device, then the driver really does >> know what kind of tape you have, despite the message The boot-message does mention 'rogue' for my tape drive. The tapedrive is identified as 'ARCHIVE VIPER' My config: Controller: ----------- GVP G'Force Combo 030, 25Mhz, 13MB 32-bit memory Amiga Model: ------------ 'rebuild' A500 in tower casing with zorro slots. RetinaZ2 graphic card Tape drive: ----------- Archive Viper, 150 MB John Vrolijk, dsnjvro@etmsun.ericsson.se From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 12:47:55 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Re: HELP: cannot restore from my tape anymore !! To: dsnjvro@etmsun.ericsson.se (John Vrolijk) Cc: donn@u.washington.edu, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1187 Sender: owner-amiga@sun-lamp.cs.berkeley.edu | >> Special handling can be set up for certain models, though, and there are | >> actually a handful already accounted for. If your boot messages mention | >> ``rogue'' after identifying the tape device, then the driver really does | >> know what kind of tape you have, despite the message | | The boot-message does mention 'rogue' for my tape drive. | The tapedrive is identified as 'ARCHIVE VIPER' I'm going to take a wild stab at this and guess that what it means by ``cannot set requested mode'' is that the new driver tries a density setting that won't work with your drive. Your rogue entry sets up densities as follows: 0 /* 0-3 */ QIC150 /* 4-7 */ QIC120 /* 8-11 */ QIC24 /* 12-15 */ The density is encoded in the 3rd and 4th bits in the device minor number, so you could make (mknod) an nrst4 device with minor number 5, meaning QIC150 (4) plus no-rewind (1). mknod /dev/nrst4 c 20 5 Who knows, can't hurt to try it. Incidentally, one unfortunate thing about this st driver is that this kind of thing is not very consistent between different drives. While /dev/rst4 may be QIC150 for your drive, it may be QIC120 for another. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Jul 1 13:33:17 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Yet more A3000 SCSI 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: 766 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm a lot closer to a clue on the error I get on tape writes ahsc0: abort intr: csr = 0x4f asr = 0x00 I managed to write a 70Mb file, by specifying an explicit block size. I guess the generic st driver may be a little weak on setting up the right block size for the Exabyte, and after the first write is issued the device might be coming back with a little complaint. Don't know whether it would be a fatal error - I bet the drive actually goes to its ordinary 1K block size and continues on - but the kernel falls over. I think I will have a look at the old Amiga BSD st driver, which probably handled this better, but in the meantime I wonder if there's some better way of dealing with these unexpected events in sbic.c. Donn Cave, donn@cac.washington.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 13:38:59 1994 To: "Missing - presumed fed." Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 3c509 again <199407010041.RAA15416@lonewolf.autodesk.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >last I looked, ISA was 24 bits wide. Not being a kernel engineer, ISA: 16-bit data; 24-bit address; ~8MHz VLB: 32-bit data; 32-bit address; ~33MHz EISA: 32-bit data; 32-bit address; 8.25MHz PCI: 32/64-bit data; 32-bit address; 25-33MHz >I'm not sure about when a virtual/physical translation occurs (i.e. does the Virtual addresses live *only* inside the CPU -- anything external to the CPU is physical. >are...), but since everything else (EISA, PCI, VLB) runs at 32 bits, >ANY kind of SCSI other than ISA SCSI would probably perform better, no? Yes. But that's only part of it. ISA, as has been stated, has only 24-bit address lines, meaning it can't address more than 16MB of physical memory. Also, ISA has no concept of arbitrating bus-masters or burst-mode transfers, so the devices must do that themselves (like the timing settings you have to give to 1542 cards to keep them from dominating the bus, but still give "good" performance). EISA is faster because it's 32-bit data, and because it supports a very well designed bursting scheme (32-bit transfer for each clock cycle). ISA requires at least two clock cycles for each 16-bit transfer in most cases (from what I've been made to understand). The EISA spec is very specific and complete in pretty much all areas of design, and a true EISA bus is pretty much going to perform as consistantly as any other EISA bus. Generally 4-8 times faster than ISA. VLB is fast because it's 32-bits wide and four times the speed of the ISA bus. But, it's a very loosely defined standard, and leaves many things up the the judgement of the motherboard designer. It has no real standard for burst-mode behaviour, and some VLB devices don't even burst (like most ISA devices). Plus, the VLB bus arbitration is much more loosely designed than EISA, so one VLB device can dominate the bus and starve other devices (or the CPU) if they're not configured properly (or are just badly designed). Because of all this, VLB performance varies greatly from one VLB implementation to the next. And some devices may just not run on some motherboards. VLB offers potential throughput roughly 16 times the speed of the ISA bus, but real-world performance varies from one VLB design to the next. And, even though a certain VLB design may be fast in raw transfer speed, it may make the overall machine seem less responsive because of poor bus arbitration. On the other hand, if you are lucky enough to have a very well designed VLB, you might reap all the potential benefits of it. PCI is another story. It's like an EISA bus on steroids in design (even though physically it doesn't use the same connectors). It can run at either 32-bits or 64-bits wide (just like the EISA falls back to 16-bits and 8-bits if an older card is being accessed). The PCI spec says a PCI bus may run anywhere from 25MHz to 33MHz. The CPU is just another device on the PCI bus, so it doesn't matter if it's a 32-bit 486 and you have a 64-bit SCSI controller -- all the buffering is automatic. The PCI bus is theoretically capable of going eight times the full speed of an EISA bus, though generally you'd probably be more likely to see about half that (a lot of the first PCI devices released were 32-bit). Still, the higher clock rate, and much better specification of the PCI bus (vs. VLB) means that the PCI bus is going to be a fast bus for quite some time. The biggest problems with it right now are a) the older PCI chipsets that had some buggy cache problems on Pentiums, and b) the autoconfiguration of PCI devices is still not quite as smart or configurable as it should be. (A) has been fixed by current PCI chipsets, and newer Pentiums are now shipping with the fixed chips. (B) may take some time yet. Devices will probably continue to conflict with each other until either they get a little smarter with their autoconfig algorithms, or get a little less fascist and stop forcing you to live with the settings autoconfiguration gives you and let you set them manually if you want. But regardless, it will be the bus of the future for quite some time. This rambling, babbling letter ran on a lot longer than I intended. ;-) Hope it makes some sense to some tormented soul out there. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 15:32:15 1994 Subject: voxware i386 sound driver - will we use it? 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: 765 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've just received the voxware sound drivers (originally the Linux sound kit, but now with FreeBSD & some SVR4.2 ports.) These drivers seem to support SB, SB-PRO, PAS16, GUS, (and with some patches getting posted on the Netaudio list , SB-16) much better than the current drivers on NetBSD. Does any of the core team (Charles?) want a look at this stuff, and even possibly: a) integrate them, and b) liase (spel?) with the developers to keep the netbsd diffs in the original? I'll bounce them someone's way. [ I had a look at the FreeBSD parts and it looks like wouldn't take much work for a person uptodate with the way drivers currently work on the 386 port (which I'm not).] The main reason I'd like to see this in is PAS16 support :) Luke. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 15:51:43 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/include/a.out.h U src/lib/libcurses/PSD.doc/Makefile U src/sys/arch/amiga/dev/grfabs_cc.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/makesyscalls.sh U src/sys/arch/hp300/hpux/syscalls.master U src/sys/arch/i386/boot/Makefile U src/sys/arch/i386/boot/boot.c U src/sys/arch/i386/i386/machdep.c U src/sys/arch/m68k/m68k/db_disasm.c U src/sys/arch/pc532/conf/NEWCONF U src/sys/arch/pc532/dev/nncr.c U src/sys/arch/pc532/dev/nscn.c U src/sys/arch/pc532/dev/scnreg.h U src/sys/arch/pc532/include/param.h U src/sys/arch/pc532/include/vmparam.h U src/sys/arch/pc532/pc532/autoconf.c U src/sys/arch/pc532/pc532/machdep.c U src/sys/arch/sparc/sparc/clockreg.h U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/trap.c U src/sys/compat/sunos/makesyscalls.sh 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/svr4/makesyscalls.sh U src/sys/compat/svr4/svr4_syscall.h U src/sys/compat/svr4/svr4_syscalls.c U src/sys/compat/svr4/svr4_sysent.c U src/sys/compat/ultrix/makesyscalls.sh U src/sys/compat/ultrix/ultrix_syscall.h U src/sys/compat/ultrix/ultrix_syscalls.c U src/sys/compat/ultrix/ultrix_sysent.c U src/sys/ddb/db_examine.c U src/sys/kern/exec_aout.c U src/sys/kern/exec_conf.c U src/sys/kern/init_main.c U src/sys/kern/init_sysent.c U src/sys/kern/makesyscalls.sh U src/sys/kern/syscalls.c U src/sys/lib/libkern/Makefile U src/sys/nfs/krpc_subr.c U src/sys/sys/disklabel.h U src/sys/sys/exec.h U src/sys/sys/exec_aout.h U src/sys/sys/syscall.h U src/usr.sbin/config.new/mkswap.c U src/usr.sbin/config.new/sem.c Running the SUP scanner: SUP Scan for current starting at Fri Jul 1 03:27:49 1994 SUP Scan for current completed at Fri Jul 1 03:30:25 1994 SUP Scan for mirror starting at Fri Jul 1 03:30:26 1994 SUP Scan for mirror completed at Fri Jul 1 03:32:40 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 17:04:24 1994 From: David Langford Subject: anyone compile Xfree86 on 0.9C? To: current-user@sun-lamp.cs.berkeley.edu X-Blank-Line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 737 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone who compiled XFree86 on a recent version of 0.9C?? The damn thing keeps mangling the Makefile for me I am am trying to figure out if it is me or something else. I thought I heard mention of problems with current and X recently but am not sure. I am running current as of about June 28. Thanks muchly. (yes, I have read all the XFree86 setup documentation and I beleive I have done all correctly) -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | > timed out" when trying to connect to sun-lamp, but sun-lamp is > > obviously up (I can ping/telnet to it fine from my machine) Has > > sun-lamp's sup server been taken off line recently, or is > > something broken on my end? > > i've had the same problems, but mycroft said i was deluding myself. > at least its a shared delusion...=) > > -bri > Me too. tcpdump shows packets going out, but nothing coming back: tcpdump: listening on ppp0 06:37:22.901662 dogwood.com.1939 > 128.32.138.88.supfilesrv: S 1359872000:1359872000(0) win 8192 06:37:28.808380 dogwood.com.1939 > 128.32.138.88.supfilesrv: S 1359872000:1359872000(0) win 8192 06:37:52.813045 dogwood.com.1939 > 128.32.138.88.supfilesrv: S 1359872000:1359872000(0) win 8192 3 packets received by filter 0 packets dropped by kernel FTP, SMTP, ping all seem to work okay, just not sup :-( -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 17:48:58 1994 From: David Langford Subject: Re: anyone compile Xfree86 on 0.9C? To: Matthieu.Herrb@laas.fr Cc: current-users@sun-lamp.cs.berkeley.edu X-Blank-Line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Thank you! this seems to be working (well at least it is trying to compile now....) Now if this can get on to the mirror sites I am sure it would help other out greatly. >Matthieu Herrb >You wrote (in your message from Fri 1) > > > > The damn thing keeps mangling the Makefile for me I am > > am trying to figure out if it is me or something else. > > I thought I heard mention of problems with current and X > > recently but am not sure. > >And which version of XFree86 ? This is a known problem with version >2.1, corrected in 2.1.1. It's caused by off_t now being 64 bit wide. > >You can get the 2.1 -> 2.1.1 patch from >physics.su.oz.au:/XFree86/2.1-2.1.1.diff.gz. > Matthieu -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | 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've just received the voxware sound drivers (originally the Linux >sound kit, but now with FreeBSD & some SVR4.2 ports.) These drivers >seem to support SB, SB-PRO, PAS16, GUS, (and with some patches >getting posted on the Netaudio list , SB-16) much better >than the current drivers on NetBSD. > >Does any of the core team (Charles?) want a look at this stuff, and >even possibly: a) integrate them, and b) liase (spel?) with the >developers to keep the netbsd diffs in the original? I'll bounce >them someone's way. Has the code in those drivers improved at all? Last time I looked at them, they were pretty much Linux-specific drivers with a whole mess of #ifdefs and bizarre wrappers to the different kernel functions on different operating systems. All and all, the whole thing was pretty ugly :-) I have a partially-completed GUS driver working; I had it working under 0.9, but since I upgraded to -current I haven't had a chance to move it over. My company might (MIGHT) have me write a driver for the PAS for BSDI; if so then that work will also become a NetBSD driver as well :-) But this is all pie-in-the-sky right now. But if someone wants to get together and work on this, I'm interested. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 22:10:11 1994 From: soda@sran230.sra.co.jp (Noriyuki Soda) To: bdc@ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu, dave@dogwood.com Subject: Re: can't sup Sender: owner-current-users@sun-lamp.cs.berkeley.edu Dave Cornejo writes: > > > >>> Ken Hornstein writes: > > > > > I haven't been able to sup since yesterday; I get "connection > > > timed out" when trying to connect to sun-lamp, but sun-lamp is > > > obviously up (I can ping/telnet to it fine from my machine) Has > > > sun-lamp's sup server been taken off line recently, or is > > > something broken on my end? > > > > i've had the same problems, but mycroft said i was deluding myself. > > at least its a shared delusion...=) > > > > -bri > > > > Me too. : > FTP, SMTP, ping all seem to work okay, just not sup :-( Me too. for example: sraihb.sra.co.jp% telnet sup.netbsd.org smtp Trying... Connected to sun-lamp.cs.berkeley.edu. Escape character is '^]'. 220-sun-lamp.cs.berkeley.edu Sendmail 8.6.9/8.6.9 ready at Fri, 1 Jul 1994 07:07:02 -0700 220 ESMTP spoken here quit 221 sun-lamp.cs.berkeley.edu closing connection Connection closed by foreign host. sraihb.sra.co.jp% telnet sup.netbsd.org supfilesrv Trying... telnet: connect: Connection timed out "Connection timed out" is something strange, because if supfilesrv dies, It should be "Connection refused". c.f. % telnet sup.netbsd.org 12345 Trying... telnet: connect: Connection refused -- soda@sra.co.jp Software Research Associates, Inc., Japan (Noriyuki Soda) software tools and technology group From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 22:21:41 1994 To: David Langford Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: anyone compile Xfree86 on 0.9C? <199407011207.CAA11904@waena.maui.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 >Has anyone who compiled XFree86 on a recent version of 0.9C?? > > The damn thing keeps mangling the Makefile for me I am > am trying to figure out if it is me or something else. > I thought I heard mention of problems with current and X > recently but am not sure. I seem to remember something about imake needing an (off_t) cast somewhere, otherwise it would munge Makefiles as you describe; sorry I can't give you more details than that. Oh, wait, here's a note I found; maybe it's helpful. --Ken From: uunet!laas.fr!matthieu (Matthieu Herrb) Message-Id: <9404080720.AA19490@elwood.RIA> To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 2.1 and new stuff Reply-To: uunet!laas.fr!Matthieu.Herrb X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 3332 Sender: uunet!sun-lamp.cs.berkeley.edu!owner-current-users Precedence: bulk Some good news: 1. I made a new binary distribution on XFree86-2.1. Available from: ftp.laas.fr:/pub/NetBSD/XFree86-2.1. WARNING: the shared libraries version numbers are now 3.0. 2. Here are the patches I needed to build it with the 4 April's binaries (They mostly come from Mark Weaver). *** mit/config/imake.c.orig Sat Jan 15 13:57:38 1994 --- mit/config/imake.c Thu Apr 7 20:32:36 1994 *************** *** 742,748 **** #if defined(SYSV) || defined(AMOEBA) || defined(_MINIX) freopen(tmpfname, "w+", tmpfd); #else /* !SYSV */ ! ftruncate(fileno(tmpfd), 0); #endif /* !SYSV */ initialized = TRUE; fprintf (tmpfd, "# Makefile generated by imake - do not edit!\n"); --- 742,748 ---- #if defined(SYSV) || defined(AMOEBA) || defined(_MINIX) 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"); *** mit/server/ddx/x386/os-support/bsd/bsd_video.c.orig Sat Jan 15 13:57:26 1994 --- mit/server/ddx/x386/os-support/bsd/bsd_video.c Thu Apr 7 20:35:33 1994 *************** *** 33,38 **** --- 33,42 ---- #include "x386Priv.h" #include "xf86_OSlib.h" + #if defined(__NetBSD__) && !defined(MAP_FILE) + #define MAP_FILE 0 + #endif + /***************************************************************************/ /* Video Memory Mapping section */ /***************************************************************************/ *** mit/config/bsdLib.tmpl.orig Thu Apr 7 20:53:09 1994 --- mit/config/bsdLib.tmpl Thu Apr 7 20:56:27 1994 *************** *** 2,10 **** XCOMM $XConsortium: sunLib.tmpl,v 1.14.1.2 92/11/11 09:52.02 rws Exp $ /* ! * SunOS shared library template */ #ifndef SharedXlibRev #define SharedXlibRev 2.0 #endif --- 2,11 ---- XCOMM $XConsortium: sunLib.tmpl,v 1.14.1.2 92/11/11 09:52.02 rws Exp $ /* ! * Free/NetBSD shared library template */ + #ifndef __NetBSD__ #ifndef SharedXlibRev #define SharedXlibRev 2.0 #endif *************** *** 32,37 **** --- 33,67 ---- #ifndef SharedPexRev #define SharedPexRev 2.0 #endif + #else /* __NetBSD__ */ + #ifndef SharedXlibRev + #define SharedXlibRev 3.0 + #endif + #ifndef SharedOldXRev + #define SharedOldXRev 3.0 + #endif + #ifndef SharedXtRev + #define SharedXtRev 3.0 + #endif + #ifndef SharedXawRev + #define SharedXawRev 3.0 + #endif + #ifndef SharedXmuRev + #define SharedXmuRev 3.0 + #endif + #ifndef SharedXextRev + #define SharedXextRev 3.0 + #endif + #ifndef SharedXinputRev + #define SharedXinputRev 3.0 + #endif + #ifndef SharedXTrapRev + #define SharedXTrapRev 3.0 + #endif + #ifndef SharedPexRev + #define SharedPexRev 3.0 + #endif + #endif /* __NetBSD__ */ SHLIBLDFLAGS = SharedLibraryLoadFlags PICFLAGS = PositionIndependentCFlags *** mit/server/ddx/x386/SuperProbe/OS_386BSD.c.orig Fri Apr 8 08:28:16 1994 --- mit/server/ddx/x386/SuperProbe/OS_386BSD.c Fri Apr 8 07:40:20 1994 *************** *** 48,53 **** --- 48,56 ---- # undef CONSOLE_X_MODE_OFF # define CONSOLE_X_MODE_OFF _IO('t',122) #endif + #if defined(__NetBSD__) && !defined(MAP_FILE) + #define MAP_FILE 0 + #endif static int CONS_fd = -1; static int BIOS_fd = -1; Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 22:41:58 1994 To: soda@sran230.sra.co.jp (Noriyuki Soda) Cc: bdc@ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu, dave@dogwood.com Subject: Re: can't sup <9407011414.AA26568@sran230.sra.co.jp> X-Mailer: exmh version 1.4 6/24/94 From: Marc Evans - Contract Software Hacker Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From what I can tell, the privilaged-socket flavor of supfilesrv on sun-lamp regularly becomes hung. Luckily, they are also running a non-privilaged supfilesrv, which appears to work fine. So, try running "sup -P" and see if that helps any... - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 1 22:42:12 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 --------------------------------- briggs Sun Jun 26 06:00:35 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: scsi.c Added Files: scsi96.c Log Message: Add some support for the '040 macs which use a different scsi chip. The scsi96 driver is just a skeleton at the moment. briggs Sun Jun 26 06:01:27 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: if_ae.c Log Message: MIN -> min. This needs a lot of work. briggs Sun Jun 26 06:02:51 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: grf.c grf_gb.c console.c adb.c asc.c Log Message: Minor mods. Get rid of constants, or update to use a better default value. briggs Sun Jun 26 06:03:44 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: vm_machdep.c Log Message: Update for 4.4-lite. briggs Sun Jun 26 06:04:43 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: via.c via.h Log Message: Change some constants to better values/don't use constants as much. briggs Sun Jun 26 06:05:34 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: trap.c Log Message: Massive changes--largely culled from Amiga version. briggs Sun Jun 26 06:06:10 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: swapgeneric.c Log Message: ufs_mountroot -> ffs_mountroot briggs Sun Jun 26 06:07:51 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: pmap.c Log Message: mmap -> pmap_mmap. extiobase -> NuBusBase intiobase -> IOBase some other minor changes. briggs Sun Jun 26 06:08:26 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: mem.c Log Message: MIN/MAX -> min/max --------------------------------- briggs Sun Jun 26 06:11:13 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: machdep.c Log Message: Lots of changes/cleanup. Note some additions for 4.4-lite and some more functionality for setmachdep. Grantham suggests that maybe function tables or some such would be a better way to handle some of these machine-dependent function--I concur that that would be TRT. briggs Sun Jun 26 06:12:44 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: conf.c Log Message: Checkpoint. Will change some with new keyboard/mouse support is added soon. Still lots of warnings... Added functions for 4.4-lite. briggs Sun Jun 26 06:13:55 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: genassym.c Log Message: Added new constants. Changed some old. Overhauled includes a bit. briggs Sun Jun 26 06:14:56 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: autoconf.c Log Message: Add probe for new scsi driver to top level of configuration. briggs Sun Jun 26 06:19:22 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: locore.s Log Message: Huge, gigantic changes... Including: 68040 support--some by me, much from Amiga... some cleanup The hp300 rei A number of frame-related fixes. Finally all found, I think, thanks to the sharp eyes/mind of Brad Grantham, Lawrence Kesteloot, and Steve Allen. The upshot is that we're finally booting again on the machines that used to work. --------------------------------- jtc Sun Jun 26 21:53:05 PDT 1994 Update of /b/source/CVS/src/usr.bin/skey In directory sun-lamp.cs.berkeley.edu:/c/users/jtc/skey Modified Files: Makefile Log Message: Add to install chopps Sun Jun 26 21:55:41 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: disksubr.c Log Message: recognize amix partitions that are of bsd 4.2 type. chopps Sun Jun 26 21:56: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: A3000 Added Files: BURBCLAVE Log Message: some minor changes chopps Sun Jun 26 21:56:32 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: siop.c Log Message: some fixes from Michael cgd Sun Jun 26 21:57:00 PDT 1994 Update of /b/source/CVS/src/sys/vm In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/vm Modified Files: device_pager.c device_pager.h kern_lock.c lock.h pmap.h swap_pager.c swap_pager.h vm.h vm_extern.h vm_fault.c vm_glue.c vm_inherit.h vm_init.c vm_kern.c vm_kern.h vm_map.c vm_map.h vm_meter.c vm_mmap.c vm_object.c vm_object.h vm_page.c vm_page.h vm_pageout.c vm_pageout.h vm_pager.c vm_pager.h vm_param.h vm_prot.h vm_swap.c vm_unix.c vm_user.c vnode_pager.c vnode_pager.h Log Message: clean up slightly; change RCS ID's to be minimally intrusive --------------------------------- gwr Tue Jun 28 15:06:10 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/sun3 In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/sun3 Modified Files: autoconf.c conf.c isr.c machdep.c process.s signal.s softint.s sun3_startup.c vm_machdep.c Log Message: Make setsoft* use the real software interrupt register. Integrate several fixes from the amiga port (and drop COMPAT_HPUX for now). Add lots of debugging checks to pmap.c - still needs work. deraadt Tue Jun 28 15:07:54 PDT 1994 Update of /b/source/CVS/src/etc/etc.sparc In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/etc/etc.sparc Modified Files: README Log Message: important note about newfs --------------------------------- deraadt Tue Jun 28 17:45:05 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/i386/include Modified Files: varargs.h Log Message: _MACHINE_VARGS_H_ deraadt Tue Jun 28 17:45:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/m68k/include Modified Files: varargs.h Log Message: _MACHINE_VARGS_H_ deraadt Tue Jun 28 17:45:10 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/include In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/pc532/include Modified Files: varargs.h Log Message: _MACHINE_VARGS_H_ deraadt Tue Jun 28 17:45:12 PDT 1994 Update of /b/source/CVS/src/sys/arch/pmax/include In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/arch/pmax/include Modified Files: varargs.h Log Message: _MACHINE_VARGS_H_ --------------------------------- gwr Tue Jun 28 22:32:56 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/include In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/include Modified Files: pmap.h Log Message: ..wrong version last time... gwr Tue Jun 28 22:34:17 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/sun3 In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/sun3 Modified Files: softint.s Log Message: ...wrong version last time... gwr Tue Jun 28 22:36:01 PDT 1994 Update of /b/source/CVS/src/sys/arch/sun3/sun3 In directory sun-lamp.cs.berkeley.edu:/d/users/gwr/src/sys/arch/sun3/sun3 Modified Files: pmap.c trap.c Log Message: Make setsoft* use the real software interrupt register. Integrate several fixes from the amiga port (and drop COMPAT_HPUX for now). Add lots of debugging checks to pmap.c - still needs work. --------------------------------- chopps Wed Jun 29 06:12:48 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 locore.s Log Message: aga mode, finally.. thanks to osymh@gemini.oscs.montana.edu (Michael Hitch) chopps Wed Jun 29 06:12:59 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/conf Modified Files: GENERIC Log Message: aga mode, finally.. thanks to osymh@gemini.oscs.montana.edu (Michael Hitch) chopps Wed Jun 29 06:13:09 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: grfabs_cc.c grfabs_ccglb.c grfabs_ccreg.h grfabs_reg.h Log Message: aga mode, finally.. thanks to osymh@gemini.oscs.montana.edu (Michael Hitch) chopps Wed Jun 29 06:13:13 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: aga mode, finally.. thanks to osymh@gemini.oscs.montana.edu (Michael Hitch) --------------------------------- deraadt Wed Jun 29 21:49:02 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/m68k In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/m68k Removed Files: strcat.c Log Message: some more deraadt Wed Jun 29 21:49:04 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/ns32k In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/ns32k Removed Files: DEFS.h Makefile.inc SYS.h htonl.S htons.S ntohl.S ntohs.S setjmp.S Log Message: some more --------------------------------- deraadt Wed Jun 29 18:10:54 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch added to the repository deraadt Wed Jun 29 18:11:42 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch/i386 In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch/i386 Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch/i386 added to the repository deraadt Wed Jun 29 18:11:43 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch/m68k In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch/m68k Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch/m68k added to the repository deraadt Wed Jun 29 18:11:46 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch/mips In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch/mips Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch/mips added to the repository deraadt Wed Jun 29 18:11:49 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch/ns32k In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch/ns32k Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch/ns32k added to the repository deraadt Wed Jun 29 18:11:55 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/arch/sparc In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/arch/sparc Log Message: Directory /b/source/CVS/src/sys/lib/libkern/arch/sparc added to the repository phil Wed Jun 29 18:12:54 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/scsi In directory sun-lamp.cs.berkeley.edu:/f/users/phil/trees/pc532/scsi Modified Files: cd.c ch.c scsiconf.c sd.c st.c Log Message: => "../../scsi/xxx.h" for use with old conf and "pc532 special scsi." As soon as config.new is working on the pc532, pc532/scsi should disappear. --------------------------------- deraadt Wed Jun 29 21:26:09 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern Modified Files: Makefile Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ deraadt Wed Jun 29 21:26:23 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/i386 In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/i386 Removed Files: DEFS.h Makefile.inc SYS.h bcmp.S bzero.S ffs.S htonl.S htons.S locc.S ntohl.S ntohs.S scanc.S setjmp.S skpc.S strcat.S strcmp.S strcpy.S strlen.S Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ deraadt Wed Jun 29 21:26:24 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/kernel In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/kernel Removed Files: disklib.c Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ deraadt Wed Jun 29 21:26:27 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/m68k In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/m68k Removed Files: DEFS.h Makefile.inc SYS.h bcmp.S bzero.S ffs.S htonl.S htons.S locc.S ntohl.S ntohs.S scanc.S skpc.S strcmp.S strcpy.S strlen.S strncmp.S strncpy.S Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ deraadt Wed Jun 29 21:26:28 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/mips In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/mips Removed Files: Makefile.inc Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ deraadt Wed Jun 29 21:26:28 PDT 1994 Update of /b/source/CVS/src/sys/lib/libkern/sparc In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/sys/lib/libkern/sparc Removed Files: Makefile.inc Log Message: mv ${arch}/ to arch/${arch}, so that libkern builds without obj/ --------------------------------- chopps Thu Jun 30 04:49: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: grfabs_cc.c Log Message: some aga cleanup from osymh@gemini.oscs.montana.edu (Michael Hitch) --------------------------------- gwr Thu Jun 30 05:54:47 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/m68k In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/m68k Modified Files: db_disasm.c Log Message: Fix disassembly of branches with byte displacement. Disassembler routine no longer prints the address because db_examine now does it for us (fixes "double speak" bug). --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 22:42:43 1994 From: Nate Williams "DEPCA" (Jun 30, 7:58pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Michael Hitchens has sent me his if_se driver for DEPCA boards, which I > have re-integrated into the if_is driver. FYI - Francis Hitchens (from DEC) wrote the driver, and I suspect Michael Hitch sent you it. Great deal. I hope the probe works after you integrated than Francis's version. (I've been using for the last year and a half. :-) > I'd like to test this, and I even have a DEPCA board, but I've on idea > at all how to configure it. It's an old full-length board with BNC and > what looks like a DIN connector. It probably has either 24k or 48k of > RAM on board. (Dumb Toshiba chips don't have an easily recognizable part > number.) Other than that, all I know are what the various markings say: That's the older DEPCA board, and it won't work with the driver you were sent. The driver Francis wrote only works on the newer DE100/DE200 series. The version you have (full length) is a piece of crap and doesn't even work well in fast boxes. > Could someone with documentation on these beasts tell me how to set the > I/O and shared memory addresses, and the IRQ? I'll try and dig up the docs on it if you want, but I don't think it will do you any good. Send me private email if you're interested. Nate From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:00:08 1994 To: Marc@synergytics.com Cc: soda@sran230.sra.co.jp (Noriyuki Soda), bdc@ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu, dave@dogwood.com Subject: Re: can't sup <199407011438.KAA27962@Synergytics.Com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>From what I can tell, the privilaged-socket flavor of supfilesrv on sun-lamp >regularly becomes hung. Luckily, they are also running a non-privilaged >supfilesrv, which appears to work fine. So, try running "sup -P" and see if >that helps any... Well, not only was there a reason for that, there was a reason we weren't telling people about it. Thank you! Those of you who should be using it, send me mail asking what port i've moved it to. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:03:27 1994 From: matthew@scruz.net (Matthew Kaufman) To: current-users@sun-lamp.cs.berkeley.edu, mark@aggregate.com Subject: Re: CAP on NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu I had very little problem getting CAP (using the bpf device for native Ethertalk) to run under 0.9, but I haven't tried with anything newer than that. But it definitely works with 0.9. -matthew From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:09:38 1994 From: Nate Williams "Re: DEPCA" (Jul 1, 11:41am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Actually, Nate, I have it (mostly) working on my older board. Turns out > to be very easy to make the driver work for both. Cool! Glad to hear it. When Francis originally sent me the driver, he mentioned that he didn't think it would work on the older boards at all since he didn't have any documentation. I believed him since we have a large number of the older boards locally, and they are really pieces of garbage in comparison to the newer boards. (Which aren't that great either). The large buffer makes them usable. Nate From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:21:03 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mycroft@gnu.ai.mit.edu, nate@bsd.coe.montana.edu Subject: Re: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can't see why this DEPCA board is significantly worse than, say, a SMC board. At least it doesn't have that NatSemi Chip from Hell soldered on it. Anyway, it works. B-) And it's a damned sight better than the NE2000 I *was* using in this machine. B-) From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:32:18 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mycroft@gnu.ai.mit.edu, nate@bsd.coe.montana.edu Subject: Re: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu Actually, Nate, I have it (mostly) working on my older board. Turns out to be very easy to make the driver work for both. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:35:27 1994 To: Marc@synergytics.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup <199407011438.KAA27962@Synergytics.Com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From what I can tell, the privilaged-socket flavor of supfilesrv on sun-lamp >regularly becomes hung. Luckily, they are also running a non-privilaged >supfilesrv, which appears to work fine. So, try running "sup -P" and see if >that helps any... Except that that port, if I remember right, (correct me if I'm wrong) was intended to be used for mirrors and other supservers to use to update themselves, not for user connections. If you start dominating that port with users, your mirrors and secondary supservers are never going to get updated in a timely fashion. --Michael ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 1 23:55:18 1994 From: Charles Hannum To: current-users@sun-lamp.cs.berkeley.edu Subject: DEPCA Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I just committed my changes to make the if_is driver work with DEPCA cards. It should work on any model with a 64k or 32k window (configuring it with `iosiz 49152' or `iosiz 16384', respectively), but I've only tested it on my old `revision E' board. At the same time, I also took the opportunity to rename the driver from `is' to `le', as the old name isn't really appropriate any more. Thanks to: Francis Hitchens, for writing the if_se driver, on which this is based (though the code is now quite different). Kevin Casey, for faxing me the user's manual. A few other people who sent me bits of the manual. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 2 01:33:17 1994 From: gdonl@gv.ssi1.com (Don Lewis) "CAP on NetBSD" (Jul 1, 8:21am) X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: mark@aggregate.com (Mark P. Gooderum), current-users@sun-lamp.cs.berkeley.edu Subject: Re: CAP on NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 1, 8:21am, Mark P. Gooderum wrote: } Subject: CAP on NetBSD } } Has anyone ported CAP to a reasonably current NetBSD? Specifically the } packet filter/nit support to work with the bpf device so that CAP can talk } direct Ethertalk w/o needing an AppleTalk <-> IPTalk router? Netatalk would also be cool. --- Truck From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 2 04:17:56 1994 From: Gordon Good Subject: Re: CAP on NetBSD To: Don Lewis 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, 1 Jul 1994, Don Lewis wrote: > } Has anyone ported CAP to a reasonably current NetBSD? Specifically the > } packet filter/nit support to work with the bpf device so that CAP can talk > } direct Ethertalk w/o needing an AppleTalk <-> IPTalk router? > > Netatalk would also be cool. We're working on it... -Gordon From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 2 06:02:36 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Long uptime Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, this is a sad day in a way. Michael VanLoon and I need to (finally) upgrade the isu-end of the slip link to something we can build kernels for. So, goodbye long uptime! NetBSD 0.9a (JUNKBOX) #1: Tue Mar 29 16:39:36 CST 1994 explorer@junkbox % w 9:19pm up 76 days, 10:10, 1 user, load average: 0.00, 0.00, 0.00 ^^ *sniff* --Michael From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 2 10:12:35 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: ypbind From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu To those of you running YP in NetBSD... In the last 24 hours Wolfgang and I have plugged some fairly big problems with ypbind or, er, we think we have... Since a NetBSD release is about to go out the door fairly soon, I'd appreciate if people could test the new ypbind fairly soon, and see how it handles. I'd be bummed out if it didn't work well..... Thanks. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 2 15:07:20 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/MIRRORS U src/bin/csh/glob.c U src/include/stdlib.h U src/share/man/man4/Makefile U src/share/man/man4/man4.sparc/Makefile U src/share/man/man4/man4.sparc/bwtwo.4 U src/share/man/man4/man4.sparc/cgsix.4 U src/share/man/man4/man4.sparc/cgthree.4 U src/share/man/man4/man4.sparc/le.4 U src/share/man/man4/man4.sparc/mem.4 U src/share/man/man4/man4.sparc/openprom.4 U src/sys/arch/i386/conf/ALL U src/sys/arch/i386/conf/GENERICAHA U src/sys/arch/i386/conf/GENERICBT U src/sys/arch/i386/conf/TRINITY U src/sys/arch/i386/conf/files.i386 U src/sys/arch/i386/floppy/test/Makefile U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_epreg.h U src/sys/arch/i386/isa/if_le.c U src/sys/arch/i386/isa/if_lereg.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/clock.c U src/sys/arch/sparc/sparc/clockreg.h U src/sys/arch/sparc/stand/Makefile U src/sys/arch/sparc/stand/boot.c U src/sys/arch/sparc/stand/filesystem.c U src/sys/arch/sparc/stand/promdev.c U src/sys/arch/sun3/sun3/trap.c U src/sys/dev/ccd.c U src/sys/dev/ccdvar.h U src/sys/kern/vfs_subr.c U src/usr.sbin/ypbind/Makefile U src/usr.sbin/ypbind/ypbind.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 config: tarring... gzipping... replacing... done config.new: tarring... gzipping... replacing... done Running the SUP scanner: SUP Scan for current starting at Sat Jul 2 04:40:40 1994 SUP Scan for current completed at Sat Jul 2 04:47:19 1994 SUP Scan for mirror starting at Sat Jul 2 04:47:20 1994 SUP Scan for mirror completed at Sat Jul 2 04:51:48 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 2 23:02:24 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: grr rootfs and virgin startup Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu heh heh hmm heh he said "virgin". heh heh hmm heh. Yeh, yeh, that was cool. Ok, so I started completely over.. got my partitions setup correctly (18M root, 131M swap, 500M usr. Amiga 4000 (m68040 CPU/MMU/FPU) real mem = 20971520 (2560 pages) avail mem = 18276352 (2231 pages) using 140 buffers containing 1146880 bytes of memory memory segment 0 at 08000000 size 01400000 memory segment 1 at 0a000000 size 00400000 memory segment 2 at 07e00000 size 00200000 memory segment 3 at 00000000 size 00200000 * Why didn't the memory segments get merged (or at least that code merged into the kernel source tree yet)? If the person who did that code hasn't submitted the diffs to Chris, would you please do it? * If a 2065 is in the system, initialized, then netbsd-a3000 is booted, it'll hang when interrupts are enabled. Maybe le0 support should be part of the a3000 kernel by default (just a suggestion after fighting with this problem on the warp kernel with no le0 support). * The rootfs being distributed now is much smarter. In fact, it has completely outsmarted me (which I realize isn't that great big of a feat). Basically, I dcp'ed it on to my root, boot up netbsd, get to the prompt asking me to enter the shell, and all is well... except.. mount -a yields "fstab: /etc/fstabInappropriate file type or format" Granted, my sd0a is a device 0, not 6, so I can understand why it says "/dev/sd6a on /: Specified device does not match mounted device." So when I used BFFS on the Amiga side to edit the fstab to change sd6a and sd6d to sd0a and sd0d (respectively), I still got the above error. So screw it, I tried a df: root_device 19646 15164 3498 81% / root_device? What? Grrr. Fine. Be that way. A mount -u doesn't work either. Nothing does. So, would some kind soul DMS up a boot floppy that will let be newfs my root, and tar -xf from my tape the real bin.tar, so I can get up and running again? Or tell me what I'm doing wrong. I can't even mount my /dev/sd0d because / is still write protected. Help! ;-) -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-x@sun-lamp.cs.berkeley.edu Sun Jul 3 07:39:21 1994 From: rhealey@aggregate.com Subject: A machine that goes bleep... To: 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: 362 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu For those who miss the bell under X, simply add the following in the bell routine for the new Xamiga+retina server: fputc(0x07,stderr); fflush(stderr); Worked on the AMIX X11R5 port and works just fine on the NetBSD port as well. This get's you the ite console beep so make sure you adjust the volume with iteconfig -v before entering X. FYI, -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 3 10:14:12 1994 From: rhealey@aggregate.com Subject: login prompt for telnet 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: 495 Sender: owner-current-users@sun-lamp.cs.berkeley.edu How do you get telnetd to emit the login: string of the login sequence without adding the string to default in /etc/gettytab and thus get two login: strings burped out on your lines running regular getty? i.e. getty seems to know to add login: to the lm string but telnetd doesn't. B^(. Do I have to add a magic flag someplace? -Rob p.s. The default lm line in the distribution doesn't have login: as part of the string so their must be another way to get telnetd to emit it yes? From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 3 12:18:10 1994 From: chammer@hrz.uni-bielefeld.de Subject: Re: grr rootfs and virgin startup To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mailer: Elm [revision: 70.85] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > * The rootfs being distributed now is much smarter. In fact, it has > completely outsmarted me (which I realize isn't that great big of a feat). > Basically, I dcp'ed it on to my root, boot up netbsd, get to the prompt > asking me to enter the shell, and all is well... except.. > mount -a yields > "fstab: /etc/fstabInappropriate file type or format" same problem here; mount -av works but this message appears. what does this funny size information mean in the fstab for the /tmp mount? isnt the size determined by the size of the swappartition? Another problem is that it seems not to be possible to mount_ados in fstab (when booting to multiuser mode). mount_ados /dev/sd5f /ados works. It seems not to be correct to write ro in fstab for ados partitions... why? Then I have perhaps some silly questions. I have added the path entrys for X11 bins in /etc/bash/Bashrc but is seems to be no longer searched for. I cant believe that the environment variables have to be initialized in different ways for different shells..... I tried to change it in rc (or rc.local, dont have my netbsd-amiga handy..) but it didnt work. Where has the ldconfig /usr/lib /usr/X11R5/lib to be called? What is the reason the latest X11R5 bins came for installing in /usr/X11R5/bin /usr/X11R5/lib(my previous configuration was bins in /usr/bin/X11 and libs in /usr/lib/X11) So sorry for some perhaps silly questions, ciao Carsten -- Carsten Hammer Schwindstr. 7 33615 Bielefeld Fakultaet fuer Physik D4-139 chammer@POST.uni-bielefeld.de From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 22:44:35 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Standalone version of loadbsd Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've been playing around with "boot floppies" today.... It would be nice to create an "df0:s/startup-sequence" file that had the "loadbsd -b kernel" sequence in it. However, loadbsd requires the ixemul library... :-( Would it be possible to create a self contained version of loadbsd [that would still fit on a FFS floppy with a GENERIC kernel]? Thanks, -SR P.S. I'm planning on uploading a two disk DMS-ed boot floppy set soon..... From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 22:44:36 1994 From: chopps@emunix.emich.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Watchout #2 X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu A second note about the changes to special files etc.. For people compiling their own kernels and not using a line similar to "config netbsd swap on generic" i.e. you request a specific partition to use. You need to grab the new fixed config.new also. (or fix its incorrect ouput in swapnetbsd.c in your compilation driectory) Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 22:46:11 1994 From: rmcormon@ccs.carleton.ca (Russell McOrmond) Subject: Minimal sources for Kernal compile - Gemini II, ASDG DSB Drivers... To: amiga-dev@sun-lamp.cs.berkeley.edu (Amiga NetBSD developers) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi all, I am curious which tar files would be the minimal required to just re-compile the kernal. I am running with the latest binaries, and want to start hacking away towards the serial drivers that I am going to need. I first want to get a kernal compiled and running before I attempt to play. I looked on the 'projects' list, and did not see anything mentioning a serial driver for the ASDG board, or the 16550 based Gemini board that I have. My guess is that there is probably sources for a PC based 16550 serial driver that could just be 'tweaked' to run on the motorola processor, getting the base address for the card from Autoconfig. I am curious if anyone has tried compiling a driver for one of those GoldenGate cards, etc? Many thanks for any help! -- Russell McOrmond, Ottawa Ontario, Canada. Work: Array Development Standard Disclaimer applies: I didn't do it, it was an accident! Russell's Home Page From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 22:56:35 1994 From: chopps@emunix.emich.edu To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Watchout. X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I commmited the changes to allow 13 partitions today. anyone who will be updating to a new kernel (i.e. not the ones currently up but the next snapshot) or anyone compiling there own kernels be aware. The upgrade procedure is fairly straight-forward but also unforgiving. I am including below the new MAKEDEV incase some people may not have any other access to it. Basically place you new kernel in / and wherever else you need it to boot. Then cd to /dev and with the *new* MAKEDEV type MAKEDEV all then sync and reboot. No olders kernels will boot on you system from this point forth. You can try and boot a new kernel first if you wish to see that it at least gets to the sh (it should) however / will be read-only and you will not be able to mount anything. If you do this beware that you keep an older kernel around so that you can reboot with it and then run MAKEDEV. Chris. #!/bin/sh - # # Copyright (c) 1990 The Regents of the University of California. # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by the University of # California, Berkeley and its contributors. # 4. Neither the name of the University nor the names of its contributors # may be used to endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $Id: MAKEDEV,v 1.7 1994/06/14 09:10:27 chopps Exp $ # # from: # hp300/MAKEDEV (1/15/94), from: # @(#)MAKEDEV 5.5 (Berkeley) 5/28/91 # # Device "make" file. Valid arguments: # all makes all known devices, including local devices, # Tries to make the ``standard'' number of each. # std standard devices # local configuration specific devices # # Tapes: # st* SCSI tapes # # Disks: # fd* Floppy disks # sd* SCSI disks, includes flopticals # cd* SCSI cdrom discs # vnd* "file" pseudo-disks # # Console ports: # ttye* ite bitmapped consoles # # Pointing devices: # mouse* Amiga mice # # Terminal ports: # tty* standard serial port. # # Pseudo terminals: # pty* set of 16 master and slave pseudo terminals # # Printers: # par* motherboard parallel port # # Special purpose devices: # grf* custom chip (grf0) or Retina (grf1) video # kbd Amiga keyboard # view* generic interface to graphic displays. # aconf autoconfig information (not yet) # lkm loadable kernel modules interface. # bpf* Berkeley Packet Filter PATH=/sbin:/bin:/usr/sbin:/usr/bin umask 77 for i do case $i in all) sh MAKEDEV std st0 ttye0 ttye1 mouse0 mouse1 tty00 grf0 grf1 kbd sh MAKEDEV sd0 sd1 sd2 sd3 sd4 sd5 sd6 vnd0 vnd1 vnd2 vnd3 vnd4 sh MAKEDEV view00 view01 view02 view03 view04 view05 pty0 sh MAKEDEV vnd5 vnd6 cd0 fd0 fd1 fd2 fd3 bpf0 bpf1 bpf2 bpf3 par0 sh MAKEDEV lkm local ;; std) rm -f console drum kmem mem reload null zero tty rm -f klog stdin stdout stderr mknod console c 0 0 mknod drum c 3 0 ; chmod 640 drum ; chgrp kmem drum mknod kmem c 2 1 ; chmod 640 kmem ; chgrp kmem kmem mknod mem c 2 0 ; chmod 640 mem ; chgrp kmem mem mknod reload c 2 20 ; chmod 640 mem ; chgrp kmem mem mknod zero c 2 12 ; chmod 666 zero mknod null c 2 2 ; chmod 666 null mknod tty c 1 0 ; chmod 666 tty mknod klog c 6 0 ; chmod 600 klog mknod stdin c 21 0 ; chmod 666 stdin mknod stdout c 21 1 ; chmod 666 stdout mknod stderr c 21 2 ; chmod 666 stderr rm -f fd/* mkdir fd > /dev/null 2>&1 (cd fd && eval `echo "" | awk ' BEGIN { \ for (i = 0; i < 64; i++) \ printf("mknod %d c 21 %d;", i, i)}'`) chown -R bin.bin fd chmod 555 fd chmod 666 fd/* ;; st*) umask 2 ; unit=`expr $i : '..\(.*\)'` case $i in st*) name=st; blk=5; chr=20;; esac rm -f $name$unit n$name$unit e$name$unit en$name$unit \ r$name$unit nr$name$unit er$name$unit enr$name$unit case $unit in 0|1|2|3|4|5|6) mknod ${name}${unit} b $blk `expr $unit '*' 16 + 0` mknod n${name}${unit} b $blk `expr $unit '*' 16 + 1` mknod e${name}${unit} b $blk `expr $unit '*' 16 + 2` mknod en${name}${unit} b $blk `expr $unit '*' 16 + 3` mknod r${name}${unit} c $chr `expr $unit '*' 16 + 0` mknod nr${name}${unit} c $chr `expr $unit '*' 16 + 1` mknod er${name}${unit} c $chr `expr $unit '*' 16 + 2` mknod enr${name}${unit} c $chr `expr $unit '*' 16 + 3` chgrp operator ${name}${unit} n${name}${unit} \ e$name$unit en$name$unit \ r${name}${unit} nr${name}${unit} \ er${name}${unit} enr${name}${unit} chmod 640 ${name}${unit} n${name}${unit} \ e$name$unit en$name$unit \ r${name}${unit} nr${name}${unit} \ er${name}${unit} enr${name}${unit} ;; *) echo bad unit for tape in: $i ;; esac umask 77 ;; fd*) umask 2 ; unit=`expr $i : '.*[^0-9]\([0-9]*\)'` rm -f fd$unit? rfd$unit? case $unit in 0|1|2|3) mknod fd${unit}a b 2 `expr $unit '*' 16` mknod fd${unit}b b 2 `expr $unit '*' 16 + 1` mknod rfd${unit}a c 18 `expr $unit '*' 16` mknod rfd${unit}b c 18 `expr $unit '*' 16 + 1` chgrp operator fd$unit? rfd$unit? chmod 640 fd$unit? rfd$unit? ;; *) echo bad unit for floppy disk in: $i ;; esac umask 77 ;; sd*|vnd*) umask 2 ; unit=`expr $i : '.*[^0-9]\([0-9]*\)'` case $i in sd*) name=sd; blk=4; chr=8;; vnd*) name=vnd; blk=6; chr=19;; esac rm -f $name$unit? r$name$unit? case $unit in 0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15) mknod ${name}${unit}c b $blk `expr $unit '*' 16 + 2` mknod r${name}${unit}c c $chr `expr $unit '*' 16 + 2` if [ $name != cd -a $name != vnd ] then mknod ${name}${unit}a b $blk `expr $unit '*' 16 + 0` mknod ${name}${unit}b b $blk `expr $unit '*' 16 + 1` mknod ${name}${unit}d b $blk `expr $unit '*' 16 + 3` mknod ${name}${unit}e b $blk `expr $unit '*' 16 + 4` mknod ${name}${unit}f b $blk `expr $unit '*' 16 + 5` mknod ${name}${unit}g b $blk `expr $unit '*' 16 + 6` mknod ${name}${unit}h b $blk `expr $unit '*' 16 + 7` mknod r${name}${unit}a c $chr `expr $unit '*' 16 + 0` mknod r${name}${unit}b c $chr `expr $unit '*' 16 + 1` mknod r${name}${unit}d c $chr `expr $unit '*' 16 + 3` mknod r${name}${unit}e c $chr `expr $unit '*' 16 + 4` mknod r${name}${unit}f c $chr `expr $unit '*' 16 + 5` mknod r${name}${unit}g c $chr `expr $unit '*' 16 + 6` mknod r${name}${unit}h c $chr `expr $unit '*' 16 + 7` fi chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h] chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h] ;; *) echo bad unit for disk in: $i ;; esac umask 77 ;; cd*) umask 2 ; unit=`expr $i : '..\(.*\)'` case $i in cd*) name=cd; blk=7; chr=9;; esac rm -f $name$unit? r$name$unit? case $unit in 0|1|2|3|4|5|6) mknod ${name}${unit}a b $blk `expr $unit '*' 8 + 0` mknod ${name}${unit}d b $blk `expr $unit '*' 8 + 3` mknod r${name}${unit}a c $chr `expr $unit '*' 8 + 0` chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h] chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h] ;; *) echo bad unit for disk in: $i ;; esac umask 77 ;; tty0*) unit=`expr $i : 'tty0\(.*\)'` rm -f ser${unit} tty0${unit} ttym${unit} case $unit in 0) mknod tty0${unit} c 12 0 mknod ttym${unit} c 12 128 chown uucp:wheel tty0${unit} ttym${unit} ;; *) echo bad unit for ser in: $i ;; esac ;; par*) unit=`expr $i : 'par\(.*\)'` rm -f par${unit} case $unit in 0) mknod par${unit} c 11 ${unit} ;; *) echo bad unit for par in: $i ;; esac ;; ttye*) unit=`expr $i : 'ttye\(.*\)'` rm -f ttye${unit} rm -f ite* case $unit in 0|1) mknod ttye${unit} c 13 ${unit} ;; *) echo bad unit for ttye in: $i ;; esac ;; grf*) unit=`expr $i : 'grf\(.*\)'` rm -f grf${unit} case $unit in 0|1) mknod grf${unit} c 10 ${unit}; chmod 666 grf${unit} ;; *) echo bad unit for grf in: $i ;; esac ;; mouse*) unit=`expr $i : 'mouse\(.*\)'` rm -f mouse${unit} case $unit in 0|1) mknod mouse${unit} c 15 ${unit}; chmod 666 mouse${unit} if [ $unit = 0 ] then rm -f mouse; ln -s mouse${unit} mouse fi ;; *) echo bad unit for mouse in: $i ;; esac ;; kbd) rm -f kbd mknod kbd c 14 0 ;; view*) unit=`expr $i : 'view\(.*\)'` rm -f view${unit} case $unit in 00|01|02|03|04|05|06|07|08|09) mknod view${unit} c 16 ${unit}; chmod 666 view${unit} ;; *) echo bad unit for view in: $i ;; esac ;; pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=16 name=q;; 2) offset=32 name=r;; 3) offset=48 name=s;; # Note that telnetd, rlogind, and xterm (at least) only look at p-s. 4) offset=64 name=t;; *) echo bad unit for pty in: $i;; esac case $class in 0|1|2|3|4) umask 0 eval `echo $offset $name | awk ' { b=$1; n=$2 } END { for (i = 0; i < 16; i++) printf("rm -f tty%s%x; mknod tty%s%x c 4 %d; \ rm -f pty%s%x; mknod pty%s%x c 5 %d; ", \ n, i, n, i, b+i, n, i, n, i, b+i); }'` umask 77 ;; esac ;; # aconf) not yet # rm -f autoconfig # mknod autoconfig c 18 0 ; chmod 644 autoconfig # ;; bpf*) unit=`expr $i : 'bpf\(.*\)'` rm -f bpf$unit mknod bpf$unit c 22 $unit chown root.wheel bpf$unit ;; lkm) rm -f lkm mknod lkm c 24 0 chown root:kmem lkm chmod 640 lkm ;; local) umask 0 sh MAKEDEV.local ;; *) echo $i: unknown device ;; esac done From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 4 23:05:43 1994 From: chopps@emunix.emich.edu To: amiga@sun-lamp.cs.berkeley.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Watchout. X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I commmited the changes to allow 13 partitions today. anyone who will be updating to a new kernel (i.e. not the ones currently up but the next snapshot) or anyone compiling there own kernels be aware. The upgrade procedure is fairly straight-forward but also unforgiving. I am including below the new MAKEDEV incase some people may not have any other access to it. Basically place you new kernel in / and wherever else you need it to boot. Then cd to /dev and with the *new* MAKEDEV type MAKEDEV all then sync and reboot. No olders kernels will boot on you system from this point forth. You can try and boot a new kernel first if you wish to see that it at least gets to the sh (it should) however / will be read-only and you will not be able to mount anything. If you do this beware that you keep an older kernel around so that you can reboot with it and then run MAKEDEV. Chris. #!/bin/sh - # # Copyright (c) 1990 The Regents of the University of California. # All rights reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted provided that the following conditions # are met: # 1. Redistributions of source code must retain the above copyright # notice, this list of conditions and the following disclaimer. # 2. Redistributions in binary form must reproduce the above copyright # notice, this list of conditions and the following disclaimer in the # documentation and/or other materials provided with the distribution. # 3. All advertising materials mentioning features or use of this software # must display the following acknowledgement: # This product includes software developed by the University of # California, Berkeley and its contributors. # 4. Neither the name of the University nor the names of its contributors # may be used to endorse or promote products derived from this software # without specific prior written permission. # # THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND # ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE # IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE # ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE # FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL # DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS # OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) # HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT # LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY # OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF # SUCH DAMAGE. # # $Id: MAKEDEV,v 1.7 1994/06/14 09:10:27 chopps Exp $ # # from: # hp300/MAKEDEV (1/15/94), from: # @(#)MAKEDEV 5.5 (Berkeley) 5/28/91 # # Device "make" file. Valid arguments: # all makes all known devices, including local devices, # Tries to make the ``standard'' number of each. # std standard devices # local configuration specific devices # # Tapes: # st* SCSI tapes # # Disks: # fd* Floppy disks # sd* SCSI disks, includes flopticals # cd* SCSI cdrom discs # vnd* "file" pseudo-disks # # Console ports: # ttye* ite bitmapped consoles # # Pointing devices: # mouse* Amiga mice # # Terminal ports: # tty* standard serial port. # # Pseudo terminals: # pty* set of 16 master and slave pseudo terminals # # Printers: # par* motherboard parallel port # # Special purpose devices: # grf* custom chip (grf0) or Retina (grf1) video # kbd Amiga keyboard # view* generic interface to graphic displays. # aconf autoconfig information (not yet) # lkm loadable kernel modules interface. # bpf* Berkeley Packet Filter PATH=/sbin:/bin:/usr/sbin:/usr/bin umask 77 for i do case $i in all) sh MAKEDEV std st0 ttye0 ttye1 mouse0 mouse1 tty00 grf0 grf1 kbd sh MAKEDEV sd0 sd1 sd2 sd3 sd4 sd5 sd6 vnd0 vnd1 vnd2 vnd3 vnd4 sh MAKEDEV view00 view01 view02 view03 view04 view05 pty0 sh MAKEDEV vnd5 vnd6 cd0 fd0 fd1 fd2 fd3 bpf0 bpf1 bpf2 bpf3 par0 sh MAKEDEV lkm local ;; std) rm -f console drum kmem mem reload null zero tty rm -f klog stdin stdout stderr mknod console c 0 0 mknod drum c 3 0 ; chmod 640 drum ; chgrp kmem drum mknod kmem c 2 1 ; chmod 640 kmem ; chgrp kmem kmem mknod mem c 2 0 ; chmod 640 mem ; chgrp kmem mem mknod reload c 2 20 ; chmod 640 mem ; chgrp kmem mem mknod zero c 2 12 ; chmod 666 zero mknod null c 2 2 ; chmod 666 null mknod tty c 1 0 ; chmod 666 tty mknod klog c 6 0 ; chmod 600 klog mknod stdin c 21 0 ; chmod 666 stdin mknod stdout c 21 1 ; chmod 666 stdout mknod stderr c 21 2 ; chmod 666 stderr rm -f fd/* mkdir fd > /dev/null 2>&1 (cd fd && eval `echo "" | awk ' BEGIN { \ for (i = 0; i < 64; i++) \ printf("mknod %d c 21 %d;", i, i)}'`) chown -R bin.bin fd chmod 555 fd chmod 666 fd/* ;; st*) umask 2 ; unit=`expr $i : '..\(.*\)'` case $i in st*) name=st; blk=5; chr=20;; esac rm -f $name$unit n$name$unit e$name$unit en$name$unit \ r$name$unit nr$name$unit er$name$unit enr$name$unit case $unit in 0|1|2|3|4|5|6) mknod ${name}${unit} b $blk `expr $unit '*' 16 + 0` mknod n${name}${unit} b $blk `expr $unit '*' 16 + 1` mknod e${name}${unit} b $blk `expr $unit '*' 16 + 2` mknod en${name}${unit} b $blk `expr $unit '*' 16 + 3` mknod r${name}${unit} c $chr `expr $unit '*' 16 + 0` mknod nr${name}${unit} c $chr `expr $unit '*' 16 + 1` mknod er${name}${unit} c $chr `expr $unit '*' 16 + 2` mknod enr${name}${unit} c $chr `expr $unit '*' 16 + 3` chgrp operator ${name}${unit} n${name}${unit} \ e$name$unit en$name$unit \ r${name}${unit} nr${name}${unit} \ er${name}${unit} enr${name}${unit} chmod 640 ${name}${unit} n${name}${unit} \ e$name$unit en$name$unit \ r${name}${unit} nr${name}${unit} \ er${name}${unit} enr${name}${unit} ;; *) echo bad unit for tape in: $i ;; esac umask 77 ;; fd*) umask 2 ; unit=`expr $i : '.*[^0-9]\([0-9]*\)'` rm -f fd$unit? rfd$unit? case $unit in 0|1|2|3) mknod fd${unit}a b 2 `expr $unit '*' 16` mknod fd${unit}b b 2 `expr $unit '*' 16 + 1` mknod rfd${unit}a c 18 `expr $unit '*' 16` mknod rfd${unit}b c 18 `expr $unit '*' 16 + 1` chgrp operator fd$unit? rfd$unit? chmod 640 fd$unit? rfd$unit? ;; *) echo bad unit for floppy disk in: $i ;; esac umask 77 ;; sd*|vnd*) umask 2 ; unit=`expr $i : '.*[^0-9]\([0-9]*\)'` case $i in sd*) name=sd; blk=4; chr=8;; vnd*) name=vnd; blk=6; chr=19;; esac rm -f $name$unit? r$name$unit? case $unit in 0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15) mknod ${name}${unit}c b $blk `expr $unit '*' 16 + 2` mknod r${name}${unit}c c $chr `expr $unit '*' 16 + 2` if [ $name != cd -a $name != vnd ] then mknod ${name}${unit}a b $blk `expr $unit '*' 16 + 0` mknod ${name}${unit}b b $blk `expr $unit '*' 16 + 1` mknod ${name}${unit}d b $blk `expr $unit '*' 16 + 3` mknod ${name}${unit}e b $blk `expr $unit '*' 16 + 4` mknod ${name}${unit}f b $blk `expr $unit '*' 16 + 5` mknod ${name}${unit}g b $blk `expr $unit '*' 16 + 6` mknod ${name}${unit}h b $blk `expr $unit '*' 16 + 7` mknod r${name}${unit}a c $chr `expr $unit '*' 16 + 0` mknod r${name}${unit}b c $chr `expr $unit '*' 16 + 1` mknod r${name}${unit}d c $chr `expr $unit '*' 16 + 3` mknod r${name}${unit}e c $chr `expr $unit '*' 16 + 4` mknod r${name}${unit}f c $chr `expr $unit '*' 16 + 5` mknod r${name}${unit}g c $chr `expr $unit '*' 16 + 6` mknod r${name}${unit}h c $chr `expr $unit '*' 16 + 7` fi chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h] chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h] ;; *) echo bad unit for disk in: $i ;; esac umask 77 ;; cd*) umask 2 ; unit=`expr $i : '..\(.*\)'` case $i in cd*) name=cd; blk=7; chr=9;; esac rm -f $name$unit? r$name$unit? case $unit in 0|1|2|3|4|5|6) mknod ${name}${unit}a b $blk `expr $unit '*' 8 + 0` mknod ${name}${unit}d b $blk `expr $unit '*' 8 + 3` mknod r${name}${unit}a c $chr `expr $unit '*' 8 + 0` chgrp operator ${name}${unit}[a-h] r${name}${unit}[a-h] chmod 640 ${name}${unit}[a-h] r${name}${unit}[a-h] ;; *) echo bad unit for disk in: $i ;; esac umask 77 ;; tty0*) unit=`expr $i : 'tty0\(.*\)'` rm -f ser${unit} tty0${unit} ttym${unit} case $unit in 0) mknod tty0${unit} c 12 0 mknod ttym${unit} c 12 128 chown uucp:wheel tty0${unit} ttym${unit} ;; *) echo bad unit for ser in: $i ;; esac ;; par*) unit=`expr $i : 'par\(.*\)'` rm -f par${unit} case $unit in 0) mknod par${unit} c 11 ${unit} ;; *) echo bad unit for par in: $i ;; esac ;; ttye*) unit=`expr $i : 'ttye\(.*\)'` rm -f ttye${unit} rm -f ite* case $unit in 0|1) mknod ttye${unit} c 13 ${unit} ;; *) echo bad unit for ttye in: $i ;; esac ;; grf*) unit=`expr $i : 'grf\(.*\)'` rm -f grf${unit} case $unit in 0|1) mknod grf${unit} c 10 ${unit}; chmod 666 grf${unit} ;; *) echo bad unit for grf in: $i ;; esac ;; mouse*) unit=`expr $i : 'mouse\(.*\)'` rm -f mouse${unit} case $unit in 0|1) mknod mouse${unit} c 15 ${unit}; chmod 666 mouse${unit} if [ $unit = 0 ] then rm -f mouse; ln -s mouse${unit} mouse fi ;; *) echo bad unit for mouse in: $i ;; esac ;; kbd) rm -f kbd mknod kbd c 14 0 ;; view*) unit=`expr $i : 'view\(.*\)'` rm -f view${unit} case $unit in 00|01|02|03|04|05|06|07|08|09) mknod view${unit} c 16 ${unit}; chmod 666 view${unit} ;; *) echo bad unit for view in: $i ;; esac ;; pty*) class=`expr $i : 'pty\(.*\)'` case $class in 0) offset=0 name=p;; 1) offset=16 name=q;; 2) offset=32 name=r;; 3) offset=48 name=s;; # Note that telnetd, rlogind, and xterm (at least) only look at p-s. 4) offset=64 name=t;; *) echo bad unit for pty in: $i;; esac case $class in 0|1|2|3|4) umask 0 eval `echo $offset $name | awk ' { b=$1; n=$2 } END { for (i = 0; i < 16; i++) printf("rm -f tty%s%x; mknod tty%s%x c 4 %d; \ rm -f pty%s%x; mknod pty%s%x c 5 %d; ", \ n, i, n, i, b+i, n, i, n, i, b+i); }'` umask 77 ;; esac ;; # aconf) not yet # rm -f autoconfig # mknod autoconfig c 18 0 ; chmod 644 autoconfig # ;; bpf*) unit=`expr $i : 'bpf\(.*\)'` rm -f bpf$unit mknod bpf$unit c 22 $unit chown root.wheel bpf$unit ;; lkm) rm -f lkm mknod lkm c 24 0 chown root:kmem lkm chmod 640 lkm ;; local) umask 0 sh MAKEDEV.local ;; *) echo $i: unknown device ;; esac done From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 23:11:39 1994 From: vervoorn@dutiws.TWI.TUDelft.NL (Patrick Vervoorn) Subject: Retina BLT Z3 + NetBSD To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 629 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, Just a small remark. A friend of mine bought a Retina BLT Z3, but due to a too old CPU board (rev 3.0 3640) it didn't quite work, so we tried it in my A4000. It seemed to work ok, so using the opportunity, I booted NetBSD. With a kernel dated 0630 it booted, went through the multi-user init, but when it was time to display the login prompt, it put it up on the Amiga display (of all things). Input, however, still went to the Retina display. Everything upto the login prompt also went to the Retina display. Anyhow, I don't have the Retina anymore, so I posted this just to let you know. Have a nice day, Patrick. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 4 23:13:35 1994 From: chopps@emunix.emich.edu To: hikita@trl.mei.co.jp (Hiroyuki Hikita) Cc: amiga@sun-lamp.cs.berkeley.edu (ML NetBSD), chopps@emunix.emich.edu Subject: Re: netbsd-940620 panics on A3000... <9407040540.AA23400@zibun.trl.mei.co.jp> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu This sounds alot like what happens when an unconfigured board causes an interrupt did you pull *all* the boards and try it? Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 4 23:21:16 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: hikita@trl.mei.co.jp (Hiroyuki Hikita), amiga@sun-lamp.cs.berkeley.edu (ML NetBSD) Subject: Re: netbsd-940620 panics on A3000... Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 4, 2:40pm, Hiroyuki Hikita wrote: > I'm trying to boot up netbsd-940620 Kernel on my A3000. > It seems to hang after checking zthreebus0. I hit a key > then it panics. vmunix.744 and netbsd-940618 will boot ok. [...] > Boards: ( I've tried without them. Same results. ) > A2065 > AMaxII > PicassoII This looks like a problem with an unknown interrupt. I'd suspect that the kernel doesn't have the Ethernet driver configured, and the presence of the A2065 could generate interrupts that NetBSD won't know about and would not be able to respond to. However, if you've removed the A2065 and still have the problem, I'm not sure what it would be. Michael From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 23:26:36 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "grr rootfs and virgin startup" (Jul 2, 1:28pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: billc@icecube.cryogenic.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: grr rootfs and virgin startup Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 2, 1:28pm, William J Coldwell wrote: > * If a 2065 is in the system, initialized, then netbsd-a3000 is booted, it'll > hang when interrupts are enabled. Maybe le0 support should be part of the > a3000 kernel by default (just a suggestion after fighting with this problem > on the warp kernel with no le0 support). Same applies to all boards like Retina, A2060, non-used SCSI-boards. The interrupt handling for non-identified boards must be changed! -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 23:28:03 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: Re: grr rootfs and virgin startup To: billc@icecube.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Amiga 4000 (m68040 CPU/MMU/FPU) > real mem = 20971520 (2560 pages) > avail mem = 18276352 (2231 pages) > using 140 buffers containing 1146880 bytes of memory > memory segment 0 at 08000000 size 01400000 > memory segment 1 at 0a000000 size 00400000 > memory segment 2 at 07e00000 size 00200000 > memory segment 3 at 00000000 size 00200000 > > * Why didn't the memory segments get merged (or at least that code merged > into the kernel source tree yet)? If the person who did that code hasn't > submitted the diffs to Chris, would you please do it? I made patches to my kernel and sent diffs to chris. Problem is the low level code supposedly was rewritten and I'm still running a old (.744 + mods) kernel. Since I'm doing some devel work w/ my machine I cant be upgrading to unstable versions all the time. When I do finally upgrade to -current I will re-implement the patch if no-one else has yet. The changes I had to make were suprisingly simple. If anyone is interested I can dig up a diff and mail them to you or explain what changes I needed to make. Tim N. > William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 4 23:33:25 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: grr rootfs and virgin startup" (Jul 3, 11:46am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chammer@hrz.uni-bielefeld.de, billc@iceCuBE.cryogenic.com Subject: Re: grr rootfs and virgin startup Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 3, 11:46am, chammer@HRZ.Uni-Bielefeld.DE wrote: > same problem here; mount -av works but this message appears. Haven't had that fstab message.. > what does this funny size information mean in the fstab for the /tmp mount? Argl, Carsten! Looks like you haven't followed the discussion living her for quite a time :) > isnt the size determined by the size of the swappartition? It _Can_, but then funny things will happen if space is freed. That -s flag fixes the /tmp size to about 10MB. > Another problem is that it seems not to be possible to mount_ados in fstab > (when booting to multiuser mode). mount_ados /dev/sd5f /ados works. > It seems not to be correct to write ro in fstab for ados partitions... why? Did work fine for me. hm > Where has the ldconfig /usr/lib /usr/X11R5/lib to be called? /etc/rc > What is the reason the latest X11R5 bins came for installing in /usr/X11R5/bin > /usr/X11R5/lib(my previous configuration was bins in /usr/bin/X11 and libs in > /usr/lib/X11) Reason? Thats default naming from MIT for X11. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 4 23:45:27 1994 To: "Szabolcs Szigeti (PinkPanther)" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: COMPAT_SVR4 <199407040916.AA27291@bagira.fsz.bme.hu> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have NetBSD-0.9C/i386 compiled with COMPAT_SVR4 and tried to run a couple of > simple binaries (cat, echo, yes, etc.) from UNIXWARE (it says UNIX System V/386 > Release 4.2 Version 1) without any sucess (core from IOT trap & such). > Is it normal at this stage or do I need any extra option to the kernel? It is not finished yet. christos@deshaw.com is the person working on it. If you can help him write it, contact him. If you cannot, just wait... From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 4 23:47:00 1994 From: "Szabolcs Szigeti (PinkPanther)" To: current-users@sun-lamp.cs.berkeley.edu Subject: COMPAT_SVR4 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone tried the SVR4 compatibility? I have NetBSD-0.9C/i386 compiled with COMPAT_SVR4 and tried to run a couple of simple binaries (cat, echo, yes, etc.) from UNIXWARE (it says UNIX System V/386 Release 4.2 Version 1) without any sucess (core from IOT trap & such). Is it normal at this stage or do I need any extra option to the kernel? Thanks, szabolcs From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 4 23:47:08 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: Aperture driver for XFree86 X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 1558 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, I've placed a new version of my aperture driver for XFree86 on ftp.laas.fr:/pub/NetBSD/XFree86-2.1.1/apNetBSD.shar In order not to break the kernel security too much,I've made the following modifications: 1. Only one open() of /dev/xf86 is allowed at a time. So once you've lauched X, (which keeps it open) no other process can access it. If you're really concerned about kernel security, you can start xdm at boot time. 2. Only mapping of the VGA frambuffer (0xA000-0xBFFFF - as in /dev/vga) and of physical adresses above physmem are allowed. I cannot restrict that more, because there aren't two VLB VGA board with same addressing decoding method. So XFree86 is peeking around to find the adress of the framebuffer at startup time. If you know the physical address of your particular card, you can use the 'memebase' directive in Xconfig to disable the probe and recompile the aperture driver with *your* values. And I remind you that only root is allowed to open /dev/xf86 and that only mmap() is implemented aprt of open() and close(). For now it's still a loadable kernel module, but I'm open to integrate it in the kernel if you find it worth. (It could for example be merged with pccons's mapping of /dev/vga). I've given this version to the XFree86 Dev. Team for inclusion in XFree3.1. By the way, there will be kind of a race between the release of XFree86 3.1 and NetBSD 1.0. I hope that there won't be too much new changes affecting X support so that XFree86 3.1 can support NetBSD 1.0. Matthieu From owner-amiga-x@sun-lamp.cs.berkeley.edu Mon Jul 4 23:50:22 1994 To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Xamiga+retina doesn't work From: John Vrolijk Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I've tried to run X on my Retina this weekend, but it didn't work. It runs ok on my ECS chip but the Retina side just displays garbage. I'm running the binaries from the 15Jun94 snapshot, most recent GENERIC kernel and X11R5 binaries from 19Jun94. I've tried several RetinaMonDef files created under ADos, but none of them work. Any ideas anyone ? John Vrolijk From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 01:29:50 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Xamiga+retina doesn't work properly From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've installed the most recent binaries ( 15Jun94 ) and kernel ( 0.9C ) and also the X11R5 from 19Jun94. Running X on the custom chips is ok, but I cannot get X to run on the Retina, all I get is garbage on the screen. I've tried the RetinaMonDef that is included in the tar file and several definitions I created with definemonitor, but none of them work. Has anyone experienced this behaviour ? John Vrolijk From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 01:36:26 1994 From: hikita@trl.mei.co.jp (Hiroyuki Hikita) Subject: netbsd-940620 panics on A3000... To: amiga@sun-lamp.cs.berkeley.edu (ML NetBSD) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello. I'm trying to boot up netbsd-940620 Kernel on my A3000. It seems to hang after checking zthreebus0. I hit a key then it panics. vmunix.744 and netbsd-940618 will boot ok. System Configuration CPU: A3000 68030/25MHz (very old. ROM-Tower, 04-proto chips...) MEM: Chip 2MB, Fast 16MB DKB4128 8MB Disks: ahsc0 targ 2 lun 0: SCSI1 direct fixed ahsc0 targ 3 lun 0: SCSI2 direct fixed ahsc0 targ 4 lun 0: SCSI1 direct fixed Tapes: ahsc0 targ 6 lun 0: SCSI1 Boards: ( I've tried without them. Same results. ) A2065 AMaxII PicassoII Dump looks like.. ---------------------------------------------------------------------------------- : : : zthreebus0 at mainbus0: i/o size 0x00800000 trap: bad kernel access at 1c trap type 8, code = 200070d, v = 1c pid = 0, pc = 0001BA16, ps = 2400, sfc = 0001, dfc = 0001 Registers: 0 1 2 3 4 5 6 7 dreg: 00000000 00002404 00000020 0000064C 00000040 00002204 00000064 0000000F areg: 0001B9D8 000C0890 00000000 00000000 FFFFFF64 00000006 FFFFFE80 0DFFFFFC Kernel stack (FFFFFD3C): FFFD3C: 000B091E FFFFFDFC 00000080 000B08B8 00000008 0200070D 0000001C 00000000 FFFD5C: FFFFFDA8 000B0BC2 00000008 0200070D 0000001C FFFFFDFC 000B09DF 0000001C FFFD7C: 0200070D 00000008 00000000 0000001C 00000064 0000000F 000C86B8 00000000 FFFD9C: FFFFFF64 00000006 00000003 FFFFFDE8 000B116E 00000008 0200070D 0000001C FFFDBC: FFFFFDFC 000C86B8 00000064 0000000F 00000020 0000064C 00000040 00002204 FFFDDC: 00000064 0000000F 00000000 FFFFFE80 00000522 00000008 0200070D 0000001C FFFDFC: 00000000 00002404 00000020 0000064C 00000040 00002204 00000064 0000000F FFFE1C: 0001B9D8 000C0890 00000000 00000000 FFFFFF64 00000006 FFFFFE80 0DFFFFFC FFFE3C: 00000000 24000001 BA16A008 0EEE070D 000C0BA8 0000001C 0000001C 0000066B FFFE5C: 52B98600 FFFF0020 00000020 00000040 00002204 00000064 00000000 00000000 FFFE7C: FFFFFF64 FFFFFEB0 0008EC46 00000020 00000000 00000040 00000008 00000002 FFFE9C: 00000000 0000000D 000C0BBC 00072664 FFFFFF64 FFFFFED0 0008935C 00000040 FFFEBC: 00000000 00000008 00000008 00000002 000BDADA FFFFFEE8 000AAAE0 00000008 FFFEDC: 00000008 00000002 00017044 FFFFFEF8 000AAB0A 00000000 00000008 FFFFFF08 FFFEFC: 000ACF7E 00000003 00000001 FFFFFF2C 000007C6 00002200 00000001 00002100 FFFF1C: 0167F000 015E54D0 201C000A A49E0068 FFFFFF68 000ABD6A 00000000 00000000 panic: MMU fault ---------------------------------------------------------------------------------- >From the above and nm out put from netbsd-940620 I get this. 0008EC46 0008e7f6 T _ite_filter 0008935C 00089304 T _kbdintr 000AAAE0 000aaaac T _dispatch_cia_ints 000AAB0A 000aaaf2 T _ciaa_intr 000ACF7E 000acea4 T _intrhand 000007C6 000007a6 T _lev1intr 000007a6 T _lev2intr 000007a6 T _lev3intr 000007a6 T _lev4intr 000007a6 T _lev1intr 000007a6 T _lev2intr 000007a6 T _lev3intr 000007a6 T _lev4intr 000ABD6A 0000abc0 T _new_vmcmd -- # hikita@trl.mei.co.jp ( Hiroyuki Hikita ) # Tokyo Information Systems Research Laboratory # Matsusita Electric Industrial Co.Ltd. # 4-5-15 Higasi-Shinagawa, Shinagawa, Tokyo, 140, Japan. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 01:48:48 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: mount_ados and ados filesystem Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Lemme guess.. it only supports 512 byte blocks. I tried to mount a 2k byte block'ed partition and it fails the checksum. Is this the case, or am I just not having a good day? ;-) -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 01:50:08 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: Woe is me Sender: owner-amiga@sun-lamp.cs.berkeley.edu So, I started over with a virgin install. First trap : My SCSI ID was 0, which would normally correspond to /dev/sd0x. Which is what I thought for a long time, until Michael straightened me out that the kernel now treats your IDE harddrive as sd0x (if you have one). This means that my ID, though 0, is now sd7x... Second trap : No /dev/[r]sd7x devices on the current rootfs. A boot floppy (courtesy of Michael again) allowed me to fix this. I then did the root swap to a nice 64M one, and installed the current binaries.tar.gz's. Futzed with the hosts, and stuff, and renamed netstart to something else and created a blank netstart (so the rc script wouldn't puke). Third trap : Some format issue with fstab that I can't seem to figure out. The /etc/fstab just isn't tasty enough to be digested.. I haven't been able to figure this one out (help). Fourth trap : I have a Retina Z2, with _retina_default_mon set to 1. Everything was being dumped to it properly until I (attempted) to go into multiuser mode.. at that point, stuff stopped being printed on the Retina, and this stuff ended up on the Amiga side! NetBSDi(Aeic(tte0 loi: Which wouldn't accept input or display anything further (help). -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 02:14:29 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/ps/extern.h U src/lib/libarch/Makefile U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/dev/atzsc.c U src/sys/arch/amiga/dev/grfabs_ccglb.c U src/sys/arch/amiga/include/vmparam.h U src/sys/arch/m68k/conf/files.m68k U src/sys/arch/m68k/conf/files.m68k.newconf U src/sys/arch/mac68k/Makefile U src/sys/arch/mac68k/dev/console.c U src/sys/arch/mac68k/mac68k/autoconf.c U src/sys/arch/mac68k/mac68k/locore.s U src/sys/arch/mac68k/mac68k/mac68k_init.c U src/sys/arch/mac68k/mac68k/machdep.c U src/sys/isofs/cd9660/cd9660_node.c U src/sys/isofs/cd9660/cd9660_rrip.c U src/sys/isofs/cd9660/cd9660_rrip.h U src/sys/isofs/cd9660/cd9660_util.c U src/sys/isofs/cd9660/cd9660_vnops.c U src/sys/isofs/cd9660/iso.h U src/sys/kern/init_main.c U src/sys/kern/vfs_bio.c U src/sys/kern/vfs_cache.c U src/sys/net/if_ppp.c U src/sys/nfs/nfs_vfsops.c U src/sys/nfs/nfs_vnops.c Running the SUP scanner: SUP Scan for current starting at Sun Jul 3 04:12:18 1994 SUP Scan for current completed at Sun Jul 3 04:14:31 1994 SUP Scan for mirror starting at Sun Jul 3 04:14:31 1994 SUP Scan for mirror completed at Sun Jul 3 04:16:49 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 03:13:10 1994 From: Duncan McEwan To: current-users@sun-lamp.cs.berkeley.edu Subject: Build of ldconfig fails if using "old" make Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried building /usr/src supped on Saturday and the build failed doing a "make depend" in /usr/src/gnu/usr.bin/ld/ldconfig, because make choked on the line CFLAGS += -DSTANDARD_SEARCH_DIRS="\"/usr/lib\", \"/usr/X386/lib\"" This was building on a system that had been last built around the begining of June. I compiled and installed the version of make in the latest sources and it worked fine. This is presumably not a problem if you have kept relatively current (I'm not sure how old your make has to be for you to trip over this problem) but I thought I'd post this incase anyone else found it happening to them... Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 03:14:29 1994 From: rhealey@aggregate.com Subject: Nice PostScript lpr package location 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: 464 Sender: owner-current-users@sun-lamp.cs.berkeley.edu While grunging around the Internet for a decent text to Postscript package for NetBSD I came across the psf package, version 3.6 at ftp.cpsc.ucalgary.ca:pub/projects/psf/psf3.6.tar.Z VERY nice package once you get all the tweeks for yuor printer and personal preferences for landscape, portrait and 1/2/4 logical pages per physical page. If you have a PostScript printer and are looking for a good text to postscript front end, give psf a try. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 03:15:23 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: mountd and /var/db/mountdtab Sender: owner-current-users@sun-lamp.cs.berkeley.edu nfs exporting dies when i reboot apparently because /var/db/mountdtab is rm'ed at bootup and mountd doesnt create a new one. it just gives an error that it cant find it. touching it and restarting mountd solves the problem -bri From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 04:39:16 1994 From: chopps@emunix.emich.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: dmesg X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I was just informed that dmesg has never been mentioned publically Basically the kernel diags (things like boot messages and register dumps after panics) are stored in the last page of memory. These messages survive reboot so that if you have to get at them you can. The utility of choice is dmesg. Which prints this memory out. Thus if you get a panic with a register dump, instead of copying it down by hand you can simply reboot and then redirect dmesg to a file. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 05:10:35 1994 From: wormey@eskimo.com (Space Case) "Nice PostScript lpr package location" (Jul 3, 10:42pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Nice PostScript lpr package location X-Face: "xBPo9!">8y'(?p*x6YoBWQt("0IGaWVZg~m}tIO}lHE/P+j"2@<@C,Ge|9/FPn]XWr5M"f`+SQLFkO Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 3, 10:42pm, rhealey@aggregate.com wrote: > While grunging around the Internet for a decent text to Postscript > package for NetBSD I came across the psf package, version 3.6 at > > ftp.cpsc.ucalgary.ca:pub/projects/psf/psf3.6.tar.Z > > VERY nice package once you get all the tweeks for yuor printer > and personal preferences for landscape, portrait and 1/2/4 logical > pages per physical page. > > If you have a PostScript printer and are looking for a good text > to postscript front end, give psf a try. > > -Rob I've found tgrind (from TeX or GNU groff -- it's been a while since I built it so I forget) to do very well, too. Not a lot of hassle to set up, either. ~Steve -- Steven R. Allen - wormey@eskimo.com Schizophrenia beats being alone. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 05:20:39 1994 From: chopps@emunix.emich.edu To: amiga-dev@sun-lamp.cs.berkeley.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: dmesg X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I was just informed that dmesg has never been mentioned publically Basically the kernel diags (things like boot messages and register dumps after panics) are stored in the last page of memory. These messages survive reboot so that if you have to get at them you can. The utility of choice is dmesg. Which prints this memory out. Thus if you get a panic with a register dump, instead of copying it down by hand you can simply reboot and then redirect dmesg to a file. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 06:21:21 1994 From: David Langford To: current-users@sun-lamp.cs.berkeley.edu Subject: More Xfree+current (ioctl_pc.h and console.h?) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a current analogue to and ? It tries using pcvt_ioctl.h but I still came up with many undefines. Thanx... From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 07:17:45 1994 From: Vincent Poy Subject: Re: Nice PostScript lpr package location To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Length: 1208 Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Sun, 3 Jul 1994 rhealey@aggregate.com wrote: > > While grunging around the Internet for a decent text to Postscript > package for NetBSD I came across the psf package, version 3.6 at > > ftp.cpsc.ucalgary.ca:pub/projects/psf/psf3.6.tar.Z > > VERY nice package once you get all the tweeks for yuor printer > and personal preferences for landscape, portrait and 1/2/4 logical > pages per physical page. > > If you have a PostScript printer and are looking for a good text > to postscript front end, give psf a try. > > -Rob > Hmmm, does this work with a HP DeskJet 500C Printer? Cheers, Vince E-mail:hippo@mercury.sfsu.edu, \|/ System Adm - CircleStar Technologies, Inc. root@berkeley.circlestar.com,(o o) San Francisco, California USA _________________________oOO__(_)__OOo_____________________________ | There are many forms of science but only physics is the quantum | | leap of the 21st Century. | \_________________________________________________________________/ uPoy@physics.ucla.edu UCLA Physics leer@CERF.NET Los Angeles, California USA root@ucla.circlestar.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 07:20:19 1994 From: Donn Cave X-Sender: donn@saul1.u.washington.edu Subject: Re: Retina BLT Z3 + NetBSD 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: 481 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu | With a kernel dated 0630 it booted, went through the multi-user init, | but when it was time to display the login prompt, it put it up on the | Amiga display (of all things). Input, however, still went to the | Retina display. | | Everything upto the login prompt also went to the Retina display. Right - as distributed, /etc/ttys runs getty on the ite0 Amiga display, rather than "console" which would go to the configured console device. Donn Cave, donn@cac.washington.edu From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 07:54:59 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: RETINACONSOLE only? Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I can't get a good link because of some custom chip assumotions that are hanging around even though I have those devices commented out. Do we want to be pure about running solely on a graphics card? kbd.o: Undefined symbol _cc_bell ite.o: Undefined symbol _ite_grf_ioctl -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 08:12:34 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: woe is me pt. 2 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Thanks go to Chris and Michael for taking time out to trace down my problems. I'm documenting all of these issues for addition to the FAQ (or better yet, a new Installation doc). -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 19:38:47 1994 From: Hubert Feyrer Subject: machine/remote-sl.h: No such file or directory 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: 678 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I just got the following error when compiling a kernel from sources supped yesterday (4. july): > ../../../../arch/amiga/dev/ser.c:147: machine/remote-sl.h: No such file or directory Any clues? Anyone? Thanks in advance, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 19:52:44 1994 From: chopps@emunix.emich.edu To: Donn Cave Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Retina BLT Z3 + NetBSD <9407050448.AA20590@saul1.u.washington.edu> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Right - as distributed, /etc/ttys runs getty on the ite0 Amiga display, > rather than "console" which would go to the configured console device. Yes and this is correct. You should enable getty's on whichever devices you want them on. The console /dev/console should always be marked as *off* however. I turned both ttye0 and ttye1 on for the next snapshot to avoid these problems. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 20:03:29 1994 Subject: Re: Standalone version of loadbsd 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 > Would it be possible to create a self contained version > of loadbsd [that would still fit on a FFS floppy with a > GENERIC kernel]? Would it be possible to create a bootblock that contains loadbsd that will suck the kernel right off the FFS using trackdisk.device? The procedure for creating a bootblock is documented on p. 571 of RKM: Devices, Third Edition. -- 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 Jul 5 20:14:01 1994 From: Arthur Hoffmann Subject: NetBSD-current and Term 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: 753 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi, I just installed NetBSD-current on my A3000 and it seems to work fine, except I can't get Term to work anymore. It compiled fine, but running it doesn't seem to work. I get no response whatsoever when typing trsh. I suspect that I haven't got my /etc direcory files setup properly. I would compareit to my old rootfs, but I used the very first rootfs till last and lots of things are different in the new one. I really would appreciate it if someone could help me out. I tried the obvious already, (hosts, myname, some ovious things in netstart) but it didn't help :( Thanks for yoru help. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 20:20:52 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: errors trying to compile kernel From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm trying to compile my own kernel, but I keep getting error messages: see below: Script started on Mon Jul 4 22:00:08 1994 # config.new MARINA # cd ../compile/MARINA # make ./genassym >assym.s cpp -DLOCORE -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="012c" -DDST="1" -DM68040 -DFPSP -DM68030 -DM68020 -DFPCOPROC -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DETHER -DINET -DISO -DTPIP -DQUOTA -DNFSSERVER -DNFSCLIENT -DFFS -DMFS -DPROCFS -DKERNFS -DMSDOSFS -DFDESC -DLOFS -DISOFS -DPORTAL -DFIFO -DADOSFS -DCOMPAT_09 -DCOMPAT_43 -DCOMPAT_SUNOS -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVSHM -DSYSVMSG -DSYSVSEM -DMARINA -DLKM -DKTRACE -DDIAGNOSTIC -DNKMEMCLUSTERS=256 -DPANICWAIT -DDEBUG -DDDB -DRETINACONSOLE -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DGRF_A2024 -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../amiga/locore.s | as -o locore.o cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0x12c" -DDST="1" -DM68040 -DFPSP -DM68030 -DM68020 -DFPCOPROC -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DETHER -DINET -DISO -DTPIP -DQUOTA -DNFSSERVER -DNFSCLIENT -DFFS -DMFS -DPROCFS -DKERNFS -DMSDOSFS -DFDESC -DLOFS -DISOFS -DPORTAL -DFIFO -DADOSFS -DCOMPAT_09 -DCOMPAT_43 -DCOMPAT_SUNOS -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVSHM -DSYSVMSG -DSYSVSEM -DMARINA -DLKM -DKTRACE -DDIAGNOSTIC -DNKMEMCLUSTERS=256 -DPANICWAIT -DDEBUG -DDDB -DRETINACONSOLE -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DGRF_A2024 -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../adosfs/adlookup.c In file included from ../../../../adosfs/adlookup.c:33: ../../../../sys/vnode.h:355: vnode_if.h: No such file or directory *** Error code 1 Stop. # exit Script done on Mon Jul 4 22:00:35 1994 I'm using the include files from 15Jun94. The kernel source is from the snapshot from about the same date. After looking in the source tree, I found something called vnode_if.sh After looking into it, I saw that this will create the needed file, so I run it with vnode_if.sh vnode_if.src And did a make again: Script started on Mon Jul 4 22:20:26 1994 # make cc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DTIMEZONE="0x12c" -DDST="1" -DM68040 -DFPSP -DM68030 -DM68020 -DFPCOPROC -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DETHER -DINET -DISO -DTPIP -DQUOTA -DNFSSERVER -DNFSCLIENT -DFFS -DMFS -DPROCFS -DKERNFS -DMSDOSFS -DFDESC -DLOFS -DISOFS -DPORTAL -DFIFO -DADOSFS -DCOMPAT_09 -DCOMPAT_43 -DCOMPAT_SUNOS -DTCP_COMPAT_42 -DCOMPAT_NOMID -DSYSVSHM -DSYSVMSG -DSYSVSEM -DMARINA -DLKM -DKTRACE -DDIAGNOSTIC -DNKMEMCLUSTERS=256 -DPANICWAIT -DDEBUG -DDDB -DRETINACONSOLE -DGRF_ECS -DGRF_NTSC -DGRF_PAL -DGRF_A2024 -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../adosfs/adlookup.c ../../../../adosfs/adlookup.c: In function `adosfs_lookup': ../../../../adosfs/adlookup.c:72: structure has no member named `ni_nameiop' ../../../../adosfs/adlookup.c:73: structure has no member named `ni_nameiop' ../../../../adosfs/adlookup.c:74: structure has no member named `ni_nameiop' ../../../../adosfs/adlookup.c:75: structure has no member named `ni_ptr' ../../../../adosfs/adlookup.c:76: structure has no member named `ni_namelen' ../../../../adosfs/adlookup.c:90: structure has no member named `ni_cred' ../../../../adosfs/adlookup.c:114: structure has no member named `ni_isdotdot' ../../../../adosfs/adlookup.c:150: structure has no member named `ni_isdotdot' ../../../../adosfs/adlookup.c:216: structure has no member named `ni_cred' ../../../../adosfs/adlookup.c:224: structure has no member named `ni_nameiop' ../../../../adosfs/adlookup.c:230: structure has no member named `ni_makeentry' ../../../../adosfs/adlookup.c:239: structure has no member named `ni_cred' ../../../../adosfs/adlookup.c:256: structure has no member named `ni_cred' ../../../../adosfs/adlookup.c:263: structure has no member named `ni_nameiop' ../../../../adosfs/adlookup.c:273: structure has no member named `ni_makeentry' *** Error code 1 Stop. # exit Script done on Mon Jul 4 22:20:50 1994 Am I doing something wrong ? Or am I missing something in the include files, are there newer versions ? John Vrolijk From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 5 20:33:16 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: machine/remote-sl.h: No such file or directory Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 5, 9:02am, Hubert Feyrer wrote: > I just got the following error when compiling a kernel from sources > supped yesterday (4. july): > > > ../../../../arch/amiga/dev/ser.c:147: machine/remote-sl.h: No such file or directory > > Any clues? Anyone? Did you have the KGDB option in your config file? That file should only be included if the KGDB option is set. I don't think we have a KGDB for the Amiga, so setting that option isn't going to work anyway. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 20:37:27 1994 From: hikita@trl.mei.co.jp (Hiroyuki Hikita) Subject: Solved: netbsd-940620 panics on A3000... To: osymh@gemini.oscs.montana.edu (Michael L. Hitch), amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Thank's for all the replies. I checked out everything again today. I took out the A2065 board and netbsd-940620 booted like a charm. \(^-^)/ My apologies for all the trouble I stirred up. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 20:43:05 1994 From: chopps@emunix.emich.edu To: John Vrolijk Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: errors trying to compile kernel <9407050648.AA01618@etmsun> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu its sounds as if your sources are messed up and you have some new and some old. I suggest you resup: "sup -ov ...". and see if anything comes across. For example your Makefile.amiga is old otherwise it would have created vnode_if.h for you. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 21:01:48 1994 To: kim@dde.dk (Kim Andersen) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: floppy problems <9407040123.AA04174@nessie.dde.dk> 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 keep having problems getting a file system onto a floppy :-( >Could someone give a failsafe and tested recipe for how to doit ? >From what I can tell, the problem is this: writedisklabel() (in arch/i386/i386/disksubr.c) wants to be sure that you're using the right partition when writing disk labels, so it forces the parition always to 2 (or maybe it's 3). Since now the minor bits for floppies now refer to different densities, it ends up using the wrong density and failing miserably. One fix would be to check to see if it's the major device number of the floppy device in writedisklabel() and not change the minor device number. (You know, I could have *sworn* that I mentioned this before ... :-) ) >I've also tried using /dev/vnd0a, but no luck. Ummm ... this is the vnode device, right? I don't think it has anything to do with the floppy drive ... >Is it at all possible to put a disklabel/filesystem onto a floppy at the >moment ? I'm not quite sure; the floppy driver doesn't work at all with my floppy controller and I can't figure out why; I've sat down and littered fd.c with debugging information, and as far as I can tell, it's doing everything right. I'm really stumped. >On the positive side I have no other problems running JUL01 -current. >The change to 4.4Lite has been very well planned and implemented. >I'm sorry you can't hear me clapping !! I'll second that; aside from the floppy controller weirdness, everything is great. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 21:13:16 1994 To: David Langford Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: More Xfree+current (ioctl_pc.h and console.h?) From: "Gary D. Duzan" Sender: owner-current-users@sun-lamp.cs.berkeley.edu In Message <199407050241.QAA21698@waena.maui.com> , David Langford wrote: => =>Is there a current analogue to and ? => =>It tries using pcvt_ioctl.h but I still came up with many undefines. => Just use the ones in mit/server/ddx/x386/etc. Gary D. Duzan Humble Practitioner of the Computer Arts From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 21:46:26 1994 From: kim@dde.dk (Kim Andersen) Subject: floppy problems To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu I keep having problems getting a file system onto a floppy :-( Could someone give a failsafe and tested recipe for how to doit ? What I've tried is: disklabel and newfs onto /dev/fd0a (3 1/2" floppy), plenty of errors like this Jul 2 09:39:58 homer /netbsd: fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 Jul 2 09:39:59 homer /netbsd: blkno 1 skip 0 cylin 0 status 40 Jul 2 09:39:59 homer /netbsd: fd0: seek failed st0 c1 cyl 0 Jul 2 09:39:59 homer /netbsd: fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 (repeat ....) I've also tried using /dev/vnd0a, but no luck. Is it at all possible to put a disklabel/filesystem onto a floppy at the moment ? If it matters this is on an AHA1542B. On the positive side I have no other problems running JUL01 -current. The change to 4.4Lite has been very well planned and implemented. I'm sorry you can't hear me clapping !! regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 21:48:19 1994 From: kim@dde.dk (Kim Andersen) Subject: Re: floppy problems To: kenh@wrl.epi.com (Ken Hornstein) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu > (You know, I could have *sworn* that I mentioned this before ... :-) ) You did, I just didn't notice. > >I've also tried using /dev/vnd0a, but no luck. > > Ummm ... this is the vnode device, right? I don't think it has anything to do > with the floppy drive ... No, the vnode device has nothing to do with the floppy driver, but using the vnode makes it faster to generate a filesystem and putting somthing on it. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 21:53:50 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: [Query] floppy disklabel procedure From: James Dolter Sender: owner-current-users@sun-lamp.cs.berkeley.edu Are others having problems with getting a disklabel on a 3.5" floppy? I am running with a July 2 current system and can't seem to get a valid label out to 3.5" floppy.... (Attemping to make a current set of emergency boot/recovery disks.) This doesn't seem to be related (at least the hardware) that floated by about on current-uesrs around 6/24... My current hardware configuration: AMI 33Mhz 486 Tandem 3.5" floppy Tandem 5.25" floppy Floppy controller on UltraStore EDSI controller 1542 SCSI Floppy controller disabled. Fuji EDSI IBM SCSI -- Jim Dolter -- GNATS People... Will file tomorrow assuming no stupid error on my side .... From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 22:17:38 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: new NetBSD FTP mirror From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu there is a new NetBSD FTP mirror running on: ftp.CSOS.ORST.EDU:/ftp/pub/NetBSD files of interest may currently be found in the NetBSD-current subdirectory. beginning with 1.0, releases will also be available. this mirror is updated daily at about 10:30am, local time (PDT), using SUP. following which, src tar files are generated (yes, daily tar files). there are no access restrictions. this source tree includes the security release, so appropiate caution is recommended for those outside the USA. i will add a SUP server as soon as possible, but that may take a week or so, due to various problems (mostly revolving around that horrid 'Gopher' thing). please drop me a line if you encounter any problems... -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html "what i used to think was me is just a fading memory..." -- NiN/PHM From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 22:24:32 1994 From: Hubert Feyrer Subject: pax & include/Makefile To: current-users@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: 1167 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried updating my system, but without a working pax, I hardly got /usr/include installed, so I just rewrote that pax-command into a pipe using some tar-commands: in src/include/Makefile, replaced cd ../sys; \ pax -rw -pa -L `find ${LDIRS} '(' -type d -path '*/*' -prune ')' -o \ '(' -type f -name '*.h' -print ')'; \ find ${LSUBDIRS} -type f -name '*.h' -print` ${DESTDIR}/usr/include with cd ../sys; \ ( find ${LDIRS} '(' -type d -path '*/*' -prune ')' -o \ '(' -type f -name '*.h' -print ')'; \ find ${LSUBDIRS} -type f -name '*.h' -print ) \ | tar plcTf - - \ | ( cd ${DESTDIR}/usr/include ; tar plxf - ) Works fine for me, and probably all those who don't have pax. ;) 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-current-users@sun-lamp.cs.berkeley.edu Tue Jul 5 23:40:35 1994 To: James Dolter Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: [Query] floppy disklabel procedure <199407051456.HAA08277@coltrane.qualcomm.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Are others having problems with getting a disklabel > on a 3.5" floppy? Disklabel does, and always has, said that disklabels "weren't supported" on floppies, though it can write the boot blocks just fine. Is that the problem you have? That's the only "problem" i've ever seen, and i do label, newfs, etc., floppies occasionally here... chris From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 5 23:43:38 1994 From: mw@eunet.ch Subject: Re: netbsd-940620 panics on A3000... To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: osymh@gemini.oscs.montana.edu, hikita@trl.mei.co.jp, amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 457 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > the AMax-board. I believe the UARTs on it causes the trouble - unidentified > interrupts. Unlikely.. I have an AMax board too, and although I'm running a different kernel, an interrupt problem with the amax board would strike me just as well as users of new kernels. Well, it doesn't.... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 6 00:00:05 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "NetBSD-current and Term" (Jul 5, 10:55pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Arthur Hoffmann , amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD-current and Term Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 5, 10:55pm, Arthur Hoffmann wrote: > I suspect that I haven't got my /etc direcory files setup properly. What for? Term doesn't need anyting there. > I would compareit to my old rootfs, but I used the very first rootfs > till last and lots of things are different in the new one. > I really would appreciate it if someone could help me out. > I tried the obvious already, (hosts, myname, some ovious things in > netstart) but it didn't help :( No need. Check the .term/termrc and the escape-flags. Use the checkline-programm. Get the TERM-FAq *hum* :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 6 00:05:28 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Solved: netbsd-940620 panics on A3000..." (Jul 5, 8:42pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: hikita@trl.mei.co.jp (Hiroyuki Hikita), osymh@gemini.oscs.montana.edu (Michael L. Hitch), amiga@sun-lamp.cs.berkeley.edu Subject: Re: Solved: netbsd-940620 panics on A3000... Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 5, 8:42pm, Hiroyuki Hikita wrote: > Subject: Solved: netbsd-940620 panics on A3000... > > Thank's for all the replies. I checked out everything again today. > I took out the A2065 board and netbsd-940620 booted like a charm. \(^-^)/ > My apologies for all the trouble I stirred up. Don't remove it, just don't initialise (ifconfig) it on the ADos-Side before booting. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 04:26:26 1994 To: apana-lists-os-netbsd-general@apana.org.au Path: news From: mason@werple.apana.org.au (G C Wing) Newsgroups: apana.lists.os.netbsd.general Subject: Re: pax & include/Makefile Organization: werple public-access unix, Melbourne Lines: 10 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) writes: :I just tried updating my system, but without a working pax, I hardly :got /usr/include installed, so I just rewrote that pax-command into a :pipe using some tar-commands: For all those people without pax, why not try either "make symlinks", or insert line SYS_INCLUDE=symlinks into /usr/share/mk/bsd.own.mk before make . You can install them after building everything if you want. -- Mason [G.C.W] mason@werple.apana.org.au Hurt...Agony...Pain...LOVE-IT From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 04:33:06 1994 From: Brian Moore To: michaelv@iastate.edu Cc: Marc@synergytics.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup Sender: owner-current-users@sun-lamp.cs.berkeley.edu So are we supposed to be using the non-privilaged port if we are mirroring sun-lamp? I tried it and it gave me connection refused. Brian Moore ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 04:47:59 1994 To: David Langford Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: More Xfree+current (ioctl_pc.h and console.h?) From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Mon, 4 Jul 1994 16:41:04 -1000 David Langford wrote: > > Is there a current analogue to and ? > > It tries using pcvt_ioctl.h but I still came up with many undefines. They're in the XFree distribution somewhere... > > Thanx... > ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Jul 6 05:11:47 1994 From: der Mouse To: downsj@CSOS.ORST.EDU Subject: Re: wierd FFS... Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > upon reboot, even after syncing the disk, i keep losing a file from > /, usually either inode 3598 or 3597. this is strange because it > happens almost every boot. > i also just recieved a 'PARTIALLY ALLOCATED INODE I=21216' error > while fs checking a newly newfs'd partition, which makes very little > sense, even to my tired brain. > NetBSD 0.9C/hp300. level 2 file systems all around, HPIB disk. > anyone else seen anything like this? If your partition table is such that two partitions overlap (two partitions that you're using, of course), you can get symptoms like this. If that's not it, I don't have further ideas; I'd have to turn to someone who knows the hp300. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 05:24:03 1994 From: Brian Moore To: Marc@synergytics.com Cc: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Reply-To: Marc@Synergytics.Com >cc: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu >X-Mailer: exmh version 1.4 6/24/94 >Date: Tue, 05 Jul 1994 17:40:42 -0400 >From: Marc Evans - Contract Software Hacker > >> So are we supposed to be using the non-privilaged port if we are mirroring >> sun-lamp? I tried it and it gave me connection refused. > >I have bee told a few times now, and I think the list was cc'ed: > > DO NOT USE THE NON-PRIVILAGED PORT! > >Apparently this port is reserved for other purposes. Fine. Just wanted to make sure that mirrors weren't supposed to be using that. Thanks again, Brian Moore ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 05:27:21 1994 From: Hubert Feyrer Subject: pax & include/Makefile To: current-users@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: 1167 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried updating my system, but without a working pax, I hardly got /usr/include installed, so I just rewrote that pax-command into a pipe using some tar-commands: in src/include/Makefile, replaced cd ../sys; \ pax -rw -pa -L `find ${LDIRS} '(' -type d -path '*/*' -prune ')' -o \ '(' -type f -name '*.h' -print ')'; \ find ${LSUBDIRS} -type f -name '*.h' -print` ${DESTDIR}/usr/include with cd ../sys; \ ( find ${LDIRS} '(' -type d -path '*/*' -prune ')' -o \ '(' -type f -name '*.h' -print ')'; \ find ${LSUBDIRS} -type f -name '*.h' -print ) \ | tar plcTf - - \ | ( cd ${DESTDIR}/usr/include ; tar plxf - ) Works fine for me, and probably all those who don't have pax. ;) 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-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 05:42:25 1994 To: Brian Moore Cc: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup <199407052136.RAA04863@zip.eecs.umich.edu> X-Mailer: exmh version 1.4 6/24/94 From: Marc Evans - Contract Software Hacker Sender: owner-current-users@sun-lamp.cs.berkeley.edu > So are we supposed to be using the non-privilaged port if we are mirroring > sun-lamp? I tried it and it gave me connection refused. I have bee told a few times now, and I think the list was cc'ed: DO NOT USE THE NON-PRIVILAGED PORT! Apparently this port is reserved for other purposes. - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 05:50:17 1994 From: mark@aggregate.com (Mark P. Gooderum) To: rhealey@aggregate.com, hippo@mercury.sfsu.edu Subject: Re: Nice PostScript lpr package location Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1417 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > On Sun, 3 Jul 1994 rhealey@aggregate.com wrote: > > > > > While grunging around the Internet for a decent text to Postscript > > package for NetBSD I came across the psf package, version 3.6 at > > > > ftp.cpsc.ucalgary.ca:pub/projects/psf/psf3.6.tar.Z > > .... > > > > -Rob > > > > Hmmm, does this work with a HP DeskJet 500C Printer? Sure, if you build and use GhostScript. I have a straight text print queue, a raw PCL one, and a mono and several color PostScript print queues to my DJ 550C using GhostScript. The text queue goes through lpf into the "raw" queue, the Postscript queues go through GhostScript into the "raw" queue. Font availability is an issue. Look for font packages that have Postscript fonts (or say they support "ATM"). There are several PD fonts supplied in the Ghostscript fonts dist (many borrowed from X11R5...), but many bit map, and even some of the outline ones don't function as full postscript fonts (some can't rotate and some can't scale unless X and Y scaling factors match). I got a very complete font collection for about US $30 called infiniType. It included Type 1 and True Type versions. Ghostscript configures for Unix mostly by editing a the Unix makefile (unlike many things on the net, Ghostscript supports DOS...). I can send mine to those interested. It worked with a mid-May current (and the binaries still work...so I haven't rebuilt). -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 06:15:56 1994 To: Marc@synergytics.com Cc: Brian Moore , michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup <199407052140.RAA03484@Synergytics.Com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > So are we supposed to be using the non-privilaged port if we are mirroring > > sun-lamp? I tried it and it gave me connection refused. > > I have bee told a few times now, and I think the list was cc'ed: > > DO NOT USE THE NON-PRIVILAGED PORT! > > Apparently this port is reserved for other purposes. actually, it's reserved for mirrors. however, i've changed its number. as i said the other day: if you want the new number, you have to send me mail, explaining why you want it, etc. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 06:33:02 1994 From: Yeng-Chee Su Subject: pppd can't be built To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 711 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just tried to build July 4's source. I met a problem which pppd has a conflit symbol 'devname'. It is the same as standard library name and is declared in stdlib.h. I just changed devname to pppddevname in pppd and it seems compiled fine. -- ________________________________________________________________________ / 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@sun-lamp.cs.berkeley.edu Wed Jul 6 06:45:20 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: sup file From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu Two quick questions. 1) How can I find out a list of collection names for ``sup'' (from sun-lamp)? Failing a way to do that, could someone send me their functioning supfile? (actually, mailing me your supfile is the all around cooler option :) ) 2) Is the "compress" option of sup considered a good or a bad thing? thanks, -wps From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 6 08:29:54 1994 From: Charles Ewen MacMillan Subject: Re: Solved: netbsd-940620 panics on A3000... To: Markus Illenseer Cc: Hiroyuki Hikita , "Michael L. Hitch" , 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, 5 Jul 1994, Markus Illenseer wrote: > Date: Tue, 5 Jul 1994 23:10:10 EDT > From: Markus Illenseer > To: Hiroyuki Hikita , > "Michael L. Hitch" , > amiga@sun-lamp.cs.berkeley.edu > Subject: Re: Solved: netbsd-940620 panics on A3000... > > On Jul 5, 8:42pm, Hiroyuki Hikita wrote: > > Subject: Solved: netbsd-940620 panics on A3000... > > > > Thank's for all the replies. I checked out everything again today. > > I took out the A2065 board and netbsd-940620 booted like a charm. \(^-^)/ > > My apologies for all the trouble I stirred up. > > Don't remove it, just don't initialise (ifconfig) it on the ADos-Side > before booting. Aghhhhh! Can we not just establish the A2065 as a fact! I will be more than happy to take and to count a vote here, as I am certain that it is at least %30 of the people that I have seen on this list that have some sort of ethernet. It _should_ be a part of the kernel; there are certainly enough people who cannot use any kernel that does not have it that it warrants the extra 1k to include the driver. Can we not prioritize a bit? How about if those of us who have no use for serial ports argue that serial ports should not be a standard feature? Our next machine to go online here, the third NetBSD machine we will be runnning will have at least one ethernet address. These machines are the mainstay of our system, and I surely do not have the time to futz around with building my own kernels, when I am using the machines in a production context. I have already offered the resources of my site, for pete's sake, build the freaking ethernet in! As for the vote on ethernet support in the kernel, just send a message stating "yes" or "no" and I will be glad to tabulate the outcome. TEZCAT.COM (pronounced: Tezzzz Cat Dot Com) Offering low cost dial-up internet connectivity in Chicago. For information about our service, mail or finger info@tezcat.com Data: 312-850-0112 (located in Wicker Park) Vox: 312-850-0181 Free Access to our BBS system via Telnet to "smirror.tezcat.com" From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 6 08:49:48 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: standalone floppy shell script Sender: owner-current-users@sun-lamp.cs.berkeley.edu I cleaned up the script posted a while ago by Hellmuth Michaelis (thanks!), and made it work with vnode devices. I offer no guarantees, it works for me! christos #! /bin/sh # This is a shell archive. Remove anything before this line, then unpack # it by saving it into a file and typing "sh file". To overwrite existing # files, type "sh file -c". You can also feed this as standard input via # unshar, or by typing "sh 'mkboot' <<'END_OF_FILE' X#!/bin/sh X#--------------------------------------------------------------------------- X# X# make a set of boot-floppies X# =========================== X# X# Hellmuth Michaelis (hm@hcswork.hcs.de) X# Christos Zoulas (christos@deshaw.com) X# X# last edit-date: [Tue Jul 5 14:05:16 EDT 1994] X# X# -cz strip the kernel so that it fits :-( X# -cz use vnd or floppies X# -cz Use copyfile to find the appropriate file to be copied X# -cz select the floppy to be made X# -cz cleanup things into functions X# -cz copy binaries from the standalone directory if possible X# -hm using 0.9 as template X# -hm making it friendlier ... X# -hm optimizing & debugging X# -hm checking for static binaries X# -hm cleaning up X# X#--------------------------------------------------------------------------- X X# The directory where the statically linked stand-alone files live Xstanddir=/usr/src/sys/arch/i386/floppy X Xvnd=/dev/vnd0a X X# the floppy mount point Xfdmnt=/mnt X X# the source directory where the data files [i1-profile etc] live Xsrcdir=`pwd` X X# the device for your 3,5" floppy disk drive (fd0 or fd1) Xfdev=fd0 X X# floppy partition Xpart=a X X# the kernel you want to use Xkerneldir=/usr/src/sys/arch/i386/compile/FLOPPY X X# Use the vnode device Xmount=mountvn Xumount=umountvn X X# Use the floppy directly X#mount=mountfl X#umount=umountfl X X Xaskready() { X echo "" X echo -n "Enter if ready, ^C to abort .... " X read reply X echo "" X} X X Xmakedirs() { X echo -n "making directories: " X for i in "$@" X do X echo -n "$i.." X mkdir $fdmnt$i X done X echo X} X X Xcopyfiles() { X dir=$1 X shift X echo -n "copy files from $dir: " X for i in "$@" X do X copyfile $i $fdmnt/$dir X done X echo X} X X Xmakedevs() { X echo -n "making device files in /dev: $@" X cwd=`pwd` X cd $fdmnt/dev X cp /dev/MAKEDEV . X $fdmnt/dev/MAKEDEV "$@" X cd $cwd X echo X} X X Xcopyfile() { X z= X for i in $standdir/$1/obj /bin /usr/bin /sbin /usr/sbin /etc X do X if [ -f $i/$1 ] X then X echo -n "$1.." X install -c -s $i/$1 $2 2> /dev/null X z=$i/$1 X break X fi X done X if [ "x$z" = "x" ] X then X echo "$1 not found" X fi X} X X Xstatfile() { X z= X for i in $standdir/$1/obj /bin /usr/bin /sbin /usr/sbin X do X if [ -f $i/$1 ] X then X file $i/$1 | grep dynamically >/dev/null 2>&1 X if test $? -ne 0 X then X echo "$i/$1..statically linked ok" X z=$i/$1 X break X else X echo "$i/$1..dynamically linked; please relink statically" X exit 1 X fi X fi X done X X if [ "x$z" = "x" ] X then X echo "$1 not found" X exit 1 X fi X} X X Xmountvn() { X loc=$1 X shift X dd if=/dev/zero of=$loc bs=100k count=12 X vnconfig -c $vnd $loc X X echo "writing disklabel to floppy" X disklabel -r -w $vnd floppy5 /usr/mdec/fdboot /usr/mdec/bootfd X X echo "initializing floppy filesystem $*" X newfs -m 0 -o space $@ $vnd floppy5 X X echo "mounting vn" X mount $vnd $fdmnt X} X X Xumountvn() { X echo "unmounting vn" X umount $fdmnt X vnconfig -u $vnd $1 X} X X Xmountfl() { X echo "Put a formatted, writable floppydisk into drive /dev/$fdev" X X askready X X echo "unmounting floppy" X umount /dev/$fdev/$part X X echo "writing disklabel to floppy" X echo X disklabel -r -w /dev/$fdev/$part floppy5 /usr/mdec/fdboot /usr/mdec/bootfd X echo X X echo "initializing floppy filesystem" X newfs -m0 -ospace /dev/r$fdev$part floppy5 X X echo "mounting floppy" X mount /dev/$fdev$part $fdmnt X} X X Xumountfl() X{ X echo "printing size of floppy [df -ik]" X echo X df -ik $fdmnt X echo X X echo "unmounting floppy" X umount /dev/$fdev$part X X echo "checking floppy" X fsck /dev/r$fdev$part X X echo X echo "REMOVE THE FLOPPY from the drive and label it NOW !" X echo X X askready X} X X# =========================================================================== X# =========================================================================== X# =========================================================================== X Xfloppy1() { X echo " ===============================" X echo " Step 1: Make kernel boot floppy" X echo " ===============================" X echo X X $mount /snapshot/kern.fs -i 6144 -c 80 X X echo "copy kernel: $kerneldir/netbsd" X install -c -s $kerneldir/netbsd $fdmnt X X echo "copy root files: .profile" X cp $srcdir/i0-dot_profile $fdmnt/.profile X X makedirs /bin /dev /mnt /sbin X X copyfiles /bin cp echo sh test X X ln $fdmnt/bin/test $fdmnt/bin/\[ X X makedevs std wd0 wd1 sd0 sd1 fd0 fd1 tty0 pty0 st0 X X copyfiles /sbin fsck halt init mount umount X X $umount /snapshot/kern.fs X} X X# =========================================================================== X# =========================================================================== X# =========================================================================== X Xfloppy2() { X echo X echo " ==============================" X echo " Step 2: Make filesystem floppy" X echo " ==============================" X echo X X $mount /snapshot/inst-1.fs -i 4096 -c 40 X X echo -n "copy root files: " X echo -n ".profile.. " X cp $srcdir/i1-dot_profile $fdmnt/.profile X echo -n "dirlist.. " X cp $srcdir/i1-dirlist $fdmnt/dirlist X echo "install.. " X cp $srcdir/i1-install $fdmnt/install X X makedirs /bin /dev /etc /kern /mnt /sbin /usr X X copyfiles /bin cat df expr ls mkdir sh sync test X ln $fdmnt/bin/test $fdmnt/bin/\[ X X makedevs std wd0 wd1 sd0 sd1 fd0 fd1 tty0 pty0 st0 X X copyfiles disktab group master.passwd passwd pwd.db spwd.db X cp /etc/disktab $fdmnt/etc/disktab.preinstall X X copyfiles /sbin disklabel reboot init mount newfs # bad144 X ln $fdmnt/sbin/reboot $fdmnt/sbin/halt X X makedirs /usr/bin /usr/mdec /usr/sbin X X copyfiles /usr/bin tar X X echo -n "copy files from /usr/mdec: " X echo -n "bootfd.. " X cp /usr/mdec/bootfd $fdmnt/usr/mdec/bootfd X ln $fdmnt/usr/mdec/bootfd $fdmnt/usr/mdec/bootsd X ln $fdmnt/usr/mdec/bootfd $fdmnt/usr/mdec/bootwd X echo "fdboot.. " X cp /usr/mdec/fdboot $fdmnt/usr/mdec/fdboot X ln $fdmnt/usr/mdec/fdboot $fdmnt/usr/mdec/sdboot X ln $fdmnt/usr/mdec/fdboot $fdmnt/usr/mdec/wdboot X X $umount /snapshot/inst-1.fs X} X X# =========================================================================== X# =========================================================================== X# =========================================================================== X Xfloppy3() { X echo X echo " ===============================" X echo " Step 3: Make 2nd install floppy" X echo " ===============================" X echo X X $mount /snapshot/inst-2.fs -i 10000 -c 40 X X echo -n "copy root files: " X echo -n ".profile.. " X cp $srcdir/i2-dot_profile $fdmnt/.profile X echo "install.. " X cp $srcdir/i2-install $fdmnt/install X X makedirs /bin /etc /sbin /tmp /usr X X copyfiles /bin chmod cp mv pwd rm stty X X copyfiles /etc protocols services X X copyfiles /sbin ifconfig mknod route shutdown slattach umount X X makedirs /usr/bin /usr/sbin X X copyfiles /usr/bin ftp gzip more # tip X ln $fdmnt/usr/bin/gzip $fdmnt/usr/bin/gunzip X ln $fdmnt/usr/bin/gzip $fdmnt/usr/bin/gzcat X X # makedirs /usr/local /usr/local/bin X # copyfiles /usr/local/bin mread rz X X copyfiles /usr/sbin update X X $umount /snapshot/inst-2.fs X} X Xfor i in tar ftp gzip more # bad144 tip mread rz Xdo X statfile $i Xdone X Xclear X Xecho Xecho " Make Boot Floppy Disks" Xecho " ======================" Xecho Xecho " This script tries to make a set of three 3,5 inch" Xecho " floppies which can be used as a recovery system." Xecho Xif [ x$1 != x ] Xthen X floppy$1 Xelse X floppy1 X floppy2 X floppy3 Xfi X X Xecho X Xexit 0 END_OF_FILE if test 7677 -ne `wc -c <'mkboot'`; then echo shar: \"'mkboot'\" unpacked with wrong size! fi chmod +x 'mkboot' # end of 'mkboot' fi if test -f 'i0-dot_profile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i0-dot_profile'\" else echo shar: Extracting \"'i0-dot_profile'\" \(1559 characters\) sed "s/^X//" >'i0-dot_profile' <<'END_OF_FILE' X# $Header X# X# rc for kernel distribution floppy X XPATH=/bin:/sbin Xexport PATH X X#test=echo X Xreboot_it() { X echo "" X echo "halting the machine..." X X ${test} halt X} X Xbail_out() { X echo "" X echo "Time to reboot the machine!" X echo "Once the machine has halted (it'll tell you when)," X echo "remove the floppy from the disk drive and press" X echo "any key to reboot." X reboot_it X} X Xecho enter '"copy"' at the prompt to copy the kernel on this Xecho floppy to your hard disk. enter anything else to reboot, Xecho but wait for the machine to restart to remove the floppy. Xecho "" Xecho -n "> " X Xread todo X Xif [ "$todo"X = copyX ]; then X echo "" X echo "what disk partition should the kernel be installed on?" X echo "(e.g. "wd0a", "sd0a", etc.)" X echo "" X echo -n "> " X X read diskpart X X echo "" X echo "checking the filesystem on $diskpart..." X X ${test} fsck -y /dev/r$diskpart X if [ $? -ne 0 ]; then X echo "" X echo "fsck failed... sorry, can't copy kernel..." X bail_out X fi X X echo "" X echo "mounting $diskpart on /mnt..." X X ${test} mount /dev/$diskpart /mnt X if [ $? -ne 0 ]; then X echo "" X echo "mount failed... sorry, can't copy kernel..." X bail_out X fi X X echo "" X echo "copying kernel..." X X ${test} cp /netbsd /mnt/netbsd X if [ $? -ne 0 ]; then X echo "" X echo "copy failed... (?!?!?!)" X bail_out X fi X X echo "" X echo "unmounting $diskpart..." X X ${test} umount /mnt > /dev/null 2>&1 X if [ $? -ne 0 ]; then X echo "" X echo "unmount failed... shouldn't be a problem..." X fi X X bail_out Xfi X Xreboot_it END_OF_FILE if test 1559 -ne `wc -c <'i0-dot_profile'`; then echo shar: \"'i0-dot_profile'\" unpacked with wrong size! fi # end of 'i0-dot_profile' fi if test -f 'i1-dirlist' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i1-dirlist'\" else echo shar: Extracting \"'i1-dirlist'\" \(26 characters\) sed "s/^X//" >'i1-dirlist' <<'END_OF_FILE' Xbin Xdev Xetc Xkern Xsbin Xusr END_OF_FILE if test 26 -ne `wc -c <'i1-dirlist'`; then echo shar: \"'i1-dirlist'\" unpacked with wrong size! fi # end of 'i1-dirlist' fi if test -f 'i1-dot_profile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i1-dot_profile'\" else echo shar: Extracting \"'i1-dot_profile'\" \(134 characters\) sed "s/^X//" >'i1-dot_profile' <<'END_OF_FILE' XPATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/contrib/bin:.: Xexport PATH XHOME=/root Xexport HOME XTERM=pc3 Xexport TERM Xinstall END_OF_FILE if test 134 -ne `wc -c <'i1-dot_profile'`; then echo shar: \"'i1-dot_profile'\" unpacked with wrong size! fi # end of 'i1-dot_profile' fi if test -f 'i1-install' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i1-install'\" else echo shar: Extracting \"'i1-install'\" \(10967 characters\) sed "s/^X//" >'i1-install' <<'END_OF_FILE' X#!/bin/sh X# install1.fs disk 'install' X# Simplified, interactive NetBSD installation script. X# D.E. Silvia (dsilvia@net.com) X# X# (heavily hacked by cgd) X# (and again by rwgrimes, for bad144 support and some error checking) X# X# (once again hacked on by rgrimes 1993/07/29, X# disabled old disktab.preinstall, X# added questions for what blocking factor to use in the file system, X# -- later deleted by cgd, because it's too complicated; fs's are 8k/1k X# added (heads) to clarify what disk tracks means) X# X# Provides for variable swap and multiple partitions. X# X# Installs first minimal part of basic NetBSD system. X# X# Does not appear to work properly IF not using whole disk _AND_ there is X# no DOS partition (kernel bug? Tries to chroot to partition 'd' :-{ ) X# X# Currently, no method for checking to see if the designated disk type is X# already in /etc/disktab. You can edit it out of the file after installation. X# X Xecho "Welcome to NetBSD-current!" Xecho "" Xecho "This program is designed to help you put NetBSD on your hard disk," Xecho "in a simple and rational way. You'll be asked several questions," Xecho "and it would probably be useful to have your disk's hardware" Xecho "manual, the installation notes, and a calculator handy." Xecho "" Xecho "In particular, you will need to know some reasonably detailed" Xecho "information about your disk's geometry, because there is currently" Xecho "no way this this program can figure that information out." Xecho "" Xecho "As with anything which modifies your hard drive's contents, this" Xecho "program can cause SIGNIFICANT data loss, and you are advised" Xecho "to make sure your hard drive is backed up before beginning the" Xecho "installation process." Xecho "" Xecho -n "Proceed with installation? [n] " Xread resp Xcase $resp in X y*|Y*) X echo "Ice-Cool! Let's get to it..." X ;; X *) X echo "" X echo "OK, then. enter 'halt' to halt the machine." X echo "Once the machine has halted, remove the floppy," X echo "and press any key to reboot." X exit X ;; Xesac Xecho "" Xecho "Drive types can be ESDI, SCSI, ST506, or IDE." Xecho -n "Drive type? " Xread type Xcase "$type" in X esdi|ESDI|st506|ST506) X drivename=wd0 X drivetype=wd X echo -n "Does it support _automatic_ sector remapping? [y] " X read remap X case "$remap" in X n*|N*) X sect_fwd="sf:" X ;; X *) X sect_fwd="" X ;; X esac X ;; X ide|IDE) X drivename=wd0 X drivetype=wd X sect_fwd="" X type=ST506 X ;; X scsi|SCSI) X drivename=sd0 X drivetype=sd X sect_fwd="" X type=SCSI X ;; Xesac Xecho "" Xecho "Disk is of type $drivetype" Xecho "going to install on $drivename..." Xecho "" Xecho -n "Label name (what kind of disk is it, one word please)? " Xread name Xecho "" Xecho -n "Number of bytes per disk sector? [512] " Xread bytes_per_sect Xif [ "$bytes_per_sect" = "" ]; then X bytes_per_sect=512 Xfi Xecho "" Xecho -n "Number of disk cylinders? " Xread cyls_per_disk Xecho "" Xecho -n "Number of disk tracks (heads) per disk cylinder? " Xread tracks_per_cyl Xecho "" Xecho -n "Number of disk sectors per disk track? " Xread sects_per_track Xecho "" Xcylindersize=`expr $sects_per_track \* $tracks_per_cyl` Xdisksize=`expr $cylindersize \* $cyls_per_disk` Xecho "Disk has a total of $disksize $bytes_per_sect byte sectors" Xecho "For greater efficiency, partitions should begin and end on cylinder" Xecho "boundaries. Cylinder size (in $bytes_per_sect byte sectors) on this" Xecho "disk is $cylindersize. Choose multiples of this value." Xecho "" Xecho -n "Size of NetBSD portion of disk (in $bytes_per_sect byte sized sectors)? " Xread partition Xpart_offset=0 Xif [ $partition -lt $disksize ]; then X echo -n "Offset of NetBSD portion of disk (in $bytes_per_sect byte sized sectors) " X read part_offset Xfi Xbadspacesec=0 Xif [ "$sect_fwd" = "sf:" ]; then X badspacecyl=`expr $sects_per_track + 126` X badspacecyl=`expr $badspacecyl + $cylindersize - 1` X badspacecyl=`expr $badspacecyl / $cylindersize` X badspacesec=`expr $badspacecyl \* $cylindersize` X echo "" X echo -n "Using $badspacesec sectors ($badspacecyl cylinders) for the " X echo "bad144 bad block table" Xfi Xwhats_left=`expr $partition - $badspacesec` Xcyl_left=`expr $whats_left / $cylindersize` Xecho "" Xecho "There are $whats_left sectors ($cyl_left cylinders) left to allocate" Xecho "" Xroot=0 Xwhile [ $root -eq 0 ]; do X echo -n "Root partition size (in $bytes_per_sect byte sized sectors)? " X read root X case $root in X [1-9]*) X total=$root X if [ $total -gt $whats_left ]; then X echo Total is greater than remaining free space X root=0 X else X part_used=`expr $root + $badspacesec` X fi X ;; X *) X root=0 X ;; X esac Xdone Xroot_offset=$part_offset Xwhats_left=`expr $partition - $part_used` Xecho "" Xswap=0 Xwhile [ $swap -eq 0 ]; do X echo "$whats_left sectors remaining in NetBSD portion of disk" X echo -n "Swap partition size (in $bytes_per_sect byte sized sectors)? " X read swap X case $swap in X [1-9]*) X if [ $swap -gt $whats_left ]; then X echo Swap size is greater than remaining free space X swap=0 X fi X ;; X *) X swap=0 X ;; X esac Xdone Xecho "" X Xswap_offset=`expr $root_offset + $root` Xpart_used=`expr $part_used + $swap` X Xfragsize=1024 Xblocksize=8192 X Xmount -u /dev/fd0a / Xecho "" >/etc/disktab Xecho "$name|NetBSD installation generated:\\" >>/etc/disktab Xecho " :dt=${type}:ty=winchester:\\" >>/etc/disktab Xecho -n " :nc#${cyls_per_disk}:ns#${sects_per_track}" >>/etc/disktab Xecho ":nt#${tracks_per_cyl}:\\" >>/etc/disktab Xecho " :se#${bytes_per_sect}:${sect_fwd}\\" >>/etc/disktab Xecho -n " :pa#${root}:oa#${root_offset}" >>/etc/disktab Xecho ":ta=4.2BSD:ba#${blocksize}:fa#${fragsize}:\\" >>/etc/disktab Xecho " :pb#${swap}:ob#${swap_offset}:tb=swap:\\" >>/etc/disktab Xecho " :pc#${partition}:oc#${part_offset}:\\" >>/etc/disktab Xename="";fname="";gname="";hname="" X Xecho "" Xecho "You will now have to enter information about any other partitions" Xecho "to be created in the NetBSD portion of the disk. This process will" Xecho "be complete when you've filled up all remaining space in the NetBSD" Xecho "portion of the disk." X Xwhile [ $part_used -lt $partition ]; do X part_size=0 X whats_left=`expr $partition - $part_used` X while [ $part_size -eq 0 ]; do X echo "" X echo "$whats_left sectors remaining in NetBSD portion of disk" X echo -n "Next partition size (in $bytes_per_sect byte sized sectors)? " X read part_size X case $part_size in X [1-9]*) X total=`expr $part_used + $part_size` X if [ $total -gt $partition ]; then X echo Total is greater than partition size X part_size=0 X else X part_used=$total X part_name="" X while [ "$part_name" = "" ]; do X echo -n "Mount point? " X read part_name X done X fi X ;; X *) X part_size=0 X ;; X esac X done X if [ "$ename" = "" ]; then X ename=$part_name X offset=`expr $part_offset + $root + $swap` X echo -n " :pe#${part_size}:oe#${offset}" >>/etc/disktab X echo ":te=4.2BSD:be#${blocksize}:fe#${fragsize}:\\" >>/etc/disktab X offset=`expr $offset + $part_size` X elif [ "$fname" = "" ]; then X fname=$part_name X echo -n " :pf#${part_size}:of#${offset}" >>/etc/disktab X echo ":tf=4.2BSD:bf#${blocksize}:ff#${fragsize}:\\" >>/etc/disktab X offset=`expr $offset + $part_size` X elif [ "$gname" = "" ]; then X gname=$part_name X echo -n " :pg#${part_size}:og#${offset}" >>/etc/disktab X echo ":tg=4.2BSD:bg#${blocksize}:fg#${fragsize}:\\" >>/etc/disktab X offset=`expr $offset + $part_size` X elif [ "$hname" = "" ]; then X hname=$part_name X echo -n " :ph#${part_size}:oh#${offset}" >>/etc/disktab X echo ":th=4.2BSD:bh#${blocksize}:fh#${fragsize}:\\" >>/etc/disktab X part_used=partition X fi Xdone X Xecho " :pd#${disksize}:od#0:" >>/etc/disktab Xcat /etc/disktab.preinstall >> /etc/disktab Xsync X Xecho "" Xecho "OK! THIS IS YOUR LAST CHANCE!!!" Xecho -n "Are you sure you want this stuff installed on your hard drive? (yes/no) " Xanswer="" Xwhile [ "$answer" = "" ]; do X read answer X case $answer in X yes|YES) X echo "" X echo "OK! Here we go..." X ;; X no|NO) X echo "" X echo "OK, then. enter 'halt' to halt the machine." X echo "Once the machine has halted, remove the floppy," X echo "and press any key to reboot." X exit X ;; X *) X echo -n "I want a yes or no answer... well? " X answer= X ;; X esac Xdone X Xecho "" Xecho -n "Labelling disk..." Xdisklabel -w -r $drivename $name /usr/mdec/${drivetype}boot /usr/mdec/boot${drivetype} Xecho " done." X Xif [ "$sect_fwd" = "sf:" ]; then X echo -n "Initializing bad144 badblock table..." X bad144 $drivename 0 X echo " done." Xfi X Xecho "Initializing root filesystem, and mounting..." Xnewfs /dev/r${drivename}a $name Xmount -v /dev/${drivename}a /mnt Xif [ "$ename" != "" ]; then X echo "" X echo "Initializing $ename filesystem, and mounting..." X newfs /dev/r${drivename}e $name X mkdir -p /mnt/$ename X mount -v /dev/${drivename}e /mnt/$ename Xfi Xif [ "$fname" != "" ]; then X echo "" X echo "Initializing $fname filesystem, and mounting..." X newfs /dev/r${drivename}f $name X mkdir -p /mnt/$fname X mount -v /dev/${drivename}f /mnt/$fname Xfi Xif [ "$gname" != "" ]; then X echo "" X echo "Initializing $gname filesystem, and mounting..." X newfs /dev/r${drivename}g $name X mkdir -p /mnt/$gname X mount -v /dev/${drivename}g /mnt/$gname Xfi Xif [ "$hname" != "" ]; then X echo "" X echo "Initializing $hname filesystem, and mounting..." X newfs /dev/r${drivename}h $name X mkdir -p /mnt/$hname X mount -v /dev/${drivename}h /mnt/$hname Xfi X Xecho "" Xecho -n "Verbose installation? [n] " Xread resp X Xecho Copying to disk... Xcd / Xcase $resp in X y*) X tarverbose=v X ;; X *) X tarverbose= X ;; Xesac X Xtar cfp - `cat /dirlist` | (cd /mnt ; tar xfp${tarverbose} - ) Xmkdir /mnt/mnt X Xcd /mnt X Xecho /dev/${drivename}a / ufs rw 1 1 >etc/fstab Xecho "kernfs /kern kernfs rw 1 1" >>etc/fstab Xif [ "$ename" != "" ]; then X echo /dev/${drivename}e /$ename ufs rw 1 2 >>etc/fstab Xfi Xif [ "$fname" != "" ]; then X echo /dev/${drivename}f /$fname ufs rw 1 3 >>etc/fstab Xfi Xif [ "$gname" != "" ]; then X echo /dev/${drivename}g /$gname ufs rw 1 4 >>etc/fstab Xfi Xif [ "$hname" != "" ]; then X echo /dev/${drivename}h /$hname ufs rw 1 5 >>etc/fstab Xfi X Xcat << EOF >.profile XPATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/bin:/usr/contrib/bin:.: Xexport PATH XHOME=/root Xexport HOME XTERM=pc3 Xexport TERM Xecho "" Xecho "Insert second installation floppy in drive and" Xecho -n "enter that drive's number (e.g. 0 or 1): " Xread driveno Xmount -o ro /dev/fd\${driveno}a /mnt Xcd /mnt Xinstall XEOF X Xsync X Xecho "The next step: reboot from the kernel copy disk, copy a" Xecho "kernel to your hard disk (to partition ${drivename}a), then reboot" Xecho "from the hard disk." Xecho "" Xecho "Enter 'halt' to halt the machine." Xecho "Once the machine has halted, replace the floppy in the disk drive" Xecho "with the kernel-copy disk that you originally booted from." Xecho "Once you have done that, press any key to reboot." END_OF_FILE if test 10967 -ne `wc -c <'i1-install'`; then echo shar: \"'i1-install'\" unpacked with wrong size! fi chmod +x 'i1-install' # end of 'i1-install' fi if test -f 'i2-dot_profile' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i2-dot_profile'\" else echo shar: Extracting \"'i2-dot_profile'\" \(5510 characters\) sed "s/^X//" >'i2-dot_profile' <<'END_OF_FILE' XHOME=/ XPATH=:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin: XTERM=pc3 # terminal emulator, for elvis XTERMCAP="\ Xpc3|ibmpc3:li#25:co#80:am:bs:bw:eo:cd=\E[J:ce=\E[K:cl=\Ec:cm=\E[%i%2;%2H:\ Xdo=\E[B:ho=\E[;H:nd=\E[C:up=\E[A:so=\E[7m:se=\E[0m:us=\E[4m:ue=\E[0m:\ X:ac=l\332q\304k\277x\263j\331m\300w\302u\264v\301t\303n\305:\ X:kb=^h:kh=\E[Y:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:" Xexport TERMCAP Xexport PATH Xexport TERM Xexport HOME Xecho "Congratulations, you've got NetBSD-current on the hard disk!" Xecho "" Xecho "To finish installation:" Xecho "Pick a temporary directory by running set_tmp_dir. make sure it's" Xecho "in a place with lots of space, probably under /usr." Xecho "Then, load the remaining distribution files into that temporary" Xecho "directory by issuing one of the following commands:" Xecho " load_fd" Xecho " load_qic_tape" Xecho " load_scsi_tape" Xecho "or by fetching the files with ftp (see the installation notes for" Xecho "information on how to do that)." Xecho "" Xecho "Once this is complete, extract the distribution files by issuing the" Xecho "command 'extract ' where is the base name" Xecho "of the distribution files, e.g. 'nbase08'." Xecho "" Xecho "Once all of the filesets you wish to install have been extracted," Xecho "enter the command 'configure' to finish setting up the system" Xecho " " Xecho "If you should wish to uninstall NetBSD, delete the partition by using the " Xecho " DOS 5 FDISK program. If installed on the entire drive, use the FDISK/MBR" Xecho " to remove the NetBSD bootstrap from the drive." Xecho 'erase ^?, werase ^H, kill ^U, intr ^C' Xstty newcrt werase ^H intr ^C kill ^U erase '^?' 9600 Xmount -at ufs Xupdate Xumask 0 X Xbeep() X{ X echo 'Beep!!!' X} X Xset_tmp_dir() X{ X def_tmp_dir=`pwd` X if [ "$def_tmp_dir" = "/" ]; then X def_tmp_dir=/usr/distrib X fi X echo -n "what dir should be used for temporary files? [$def_tmp_dir] " X read tmp_dir X if [ "$tmp_dir" = "" ]; then X tmp_dir=$def_tmp_dir X fi X if [ ! -d "$tmp_dir" ]; then X /bin/rm -rf $tmp_dir X mkdir -p $tmp_dir X fi X} Xtmp_dir() X{ X if [ "$tmp_dir" = "" ]; then X set_tmp_dir X fi X cd $tmp_dir X} Xload_fd() X{ X tmp_dir X which= X while [ "$which" != "a" -a "$which" != "b" ]; do X echo -n "read from which floppy drive? [a or b] " X read which X done X while echo -n "Insert floppy (hit ^C to terminate, enter to load): " X do X read foo X mread "$which:*.*" . X done X} Xload_qic_tape() X{ X tmp_dir X echo -n "Insert tape into QIC tape drive and hit return to continue: " X read foo X tar xvf /dev/rwt0 X} Xload_scsi_tape() X{ X tmp_dir X echo -n "Insert tape into SCSI tape drive and hit return to continue: " X read foo X tar xvf /dev/nrst0 X} Xextract() X{ X tmp_dir X echo -n "Would you like to be verbose about this? [n] " X read verbose X case $verbose in X y*|Y*) X tarverbose=--verbose X ;; X *) X tarverbose= X ;; X esac X cat "$@"* | gunzip | (cd / ; tar --extract --file - --unlink --preserve-permissions ${tarverbose} ) X X sync X} Xconfigure() X{ X echo "You will now be prompted for information about this" X echo "machine. If you hit return, the default answer (in" X echo "brackets) will be used." X X echo "" X echo -n "What is this machine's hostname? [unknown.host.domain] " X read hname X X if [ "$hname" = "" ]; then X hname=unknown.host.domain X fi X echo $hname > /etc/myname X proto_domain=`echo $hname | sed -e 's/[^.]*\.//'` X X echo "" X echo "What domain is this machine in (this is NOT its YP" X echo -n "domain name)? [$proto_domain] " X read dname X X if [ "$dname" = "" ]; then X dname=$proto_domain X fi X X cp /etc/sendmail.cf_proto /etc/sendmail.cf X X beep X echo "WARNING: sendmail will puke on your carpet when the machine" X echo "starts up. If you don't want it to keep doing this, either" X echo "turn it off in /etc/rc, or give it a reasonable" X echo "/etc/sendmail.cf file." X X echo "127.0.0.1 localhost" > /etc/hosts X X echo "" X echo -n "Does this machine have an ethernet interface? [y] " X read resp X case "$resp" in X n*) X ;; X *) X intf= X while [ "$intf" = "" ]; do X echo -n "What is the primary interface name (i.e. ed0, etc.)? " X read intf X done X echo -n "What is the hostname for this interface? [$hname] " X read ifname X if [ "$ifname" = "" ]; then X ifname=$hname X fi X ifaddr= X while [ "$ifaddr" = "" ]; do X echo -n "What is the IP address associated with this interface? " X read ifaddr X done X echo "$ifaddr $ifname `echo $ifname | sed -e s/\.$dname//`" \ X >> /etc/hosts X X echo -n "Does this interface have a special netmask? [n] " X read resp X case "$resp" in X y*) X echo -n "What is the netmask? [0xffffff00] " X read ifnetmask X if [ "$ifnetmask" = "" ]; then X ifnetmask=0xffffff00 X fi X ;; X *) X ifnetmask= X ;; X esac X X echo -n "Does this interface need additional flags? [n] " X read resp X case "$resp" in X y*) X echo -n "What flags? [llc0] " X read ifflags X if [ "$ifflags" = "" ]; then X ifflags=llc0 X fi X ;; X *) X ifflags= X ;; X esac X X echo "inet $ifname $ifnetmask $ifflags" > /etc/hostname.$intf X X beep X echo "WARNING: if you have any more ethernet interfaces, you" X echo "will have to configure them by hand. Read the comments" X echo "in /etc/netstart to learn how to do this" X ;; X esac X X sync X X echo "" X echo "OK. You should be completely set up now." X echo "You should now reboot your machine by issuing the 'reboot' command" X echo "after removing anything that happens to be in your floppy drive." X} END_OF_FILE if test 5510 -ne `wc -c <'i2-dot_profile'`; then echo shar: \"'i2-dot_profile'\" unpacked with wrong size! fi # end of 'i2-dot_profile' fi if test -f 'i2-install' -a "${1}" != "-c" ; then echo shar: Will not clobber existing file \"'i2-install'\" else echo shar: Extracting \"'i2-install'\" \(760 characters\) sed "s/^X//" >'i2-install' <<'END_OF_FILE' X#!/bin/sh X# install2.fs disk 'install' X# Simplified, interactive 386bsd installation script. X# D.E. Silvia (dsilvia@net.com) X# X# Installs balance of basic 386bsd system. X# X Xmount -at ufs Xbin/rm /.profile Xecho -n "Verbose installation? [n] " Xread resp X Xecho Copying to disk. Xcase $resp in X y*) X tarverbose=v X ;; X *) X tarverbose= X ;; Xesac X Xtar cfp - . | (cd / ; tar xfp${tarverbose} -) X Xsync X Xecho "OK. All of the base files are installed." Xecho "" Xecho "The next step: reboot from the hard disk, and follow" Xecho "more instrutctions." Xecho "" Xecho "To do this, enter 'halt' at the prompt to halt the machine." Xecho "Once the machine has halted, remove the floppy from the disk" Xecho "drive, and hit any key to reboot from the hard disk." END_OF_FILE if test 760 -ne `wc -c <'i2-install'`; then echo shar: \"'i2-install'\" unpacked with wrong size! fi chmod +x 'i2-install' # end of 'i2-install' fi echo shar: End of shell archive. exit 0 From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 6 09:42:21 1994 From: chopps@emunix.emich.edu To: Charles Ewen MacMillan Cc: Markus Illenseer , Hiroyuki Hikita , "Michael L. Hitch" , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Solved: netbsd-940620 panics on A3000... X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu le0 is a part of every generic kernel and has been for a while. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 6 10:53:28 1994 From: Charles Ewen MacMillan Subject: Re: Solved: netbsd-940620 panics on A3000... To: chopps@emunix.emich.edu Cc: Markus Illenseer , Hiroyuki Hikita , "Michael L. Hitch" , amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Wed, 6 Jul 1994 chopps@emunix.emich.edu wrote: > Date: Wed, 06 Jul 94 02:35:27 -0400 > From:chopps@emunix.emich.edu > To: Charles Ewen MacMillan > Cc: Markus Illenseer , > Hiroyuki Hikita , > "Michael L. Hitch" , > amiga@sun-lamp.cs.berkeley.edu > Subject: Re: Solved: netbsd-940620 panics on A3000... > > > le0 is a part of every generic kernel and has been for a while. > > Chris. > Well then, perhaps I need to apologize, as I had gotten the feeling that it has not been for some time. I am still loath to upgrade from my crapaloo Mid-March build, as I have a running and producing system. The next machine we are about to bring online, as soon as I finish the BBS software for it, is a 4000/040. Are the kernels for this machine as well built with le0? TEZCAT.COM (pronounced: Tezzzz Cat Dot Com) Offering low cost dial-up internet connectivity in Chicago. For information about our service, mail or finger info@tezcat.com Data: 312-850-0112 (located in Wicker Park) Vox: 312-850-0181 Free Access to our BBS system via Telnet to "smirror.tezcat.com" From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 09:11:54 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Anybody seen this? From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm elbow deep in bringing my i486 to Jul5 sources. I'm seeing something that I haven't seen for a *LONG* time when using the ed driver... Its running a brand-new kernel... /netbsd: ed1: reciever ring buffer overrun This had disappeared long ago and had not been a problem...until now...My machine's source tree is on a Sequent (over an NFS link, obviously), and access is noticably slower now... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Jul 7 09:11:59 1994 From: "Szabolcs Szigeti (PinkPanther)" To: current-users@sun-lamp.cs.berkeley.edu Subject: ppp panic & slip question Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm a bit new to this, so i might be doing something wrong, but a panic shouldn't happen. I'd like to connect my two home machines (a 486/66 and a 386/40 both the latest current) via slip. The slip connection builds up all right, but when I start using it the connection breaks sooner or later, and have to reboot both of them to reconnect. (they work otherwise). So my question is: is a 3 wire null-modem cable (RXT to TXT, modem lines looped back) ok, or do I have to connect the modem ctlr lines. At least this is what i expect to be the cause. BTW the serial chips are no-fifos. The other problem is a bit more serious: I was experimenting with ppp. After starting pppd it builds the connection, and quickly panics the system. Even just starting pppd on the console without any options, so that it starts writing its packets on the screen panics the system (may have to try it a couple of times). DDB shows the panic is in pppioctl(). This happens on both machines, a hardware bug can be ruled out. BTW, savecore doesn't find any dump after a panic, but i see the kernel doing the dump, so it makes debugging a little harder (I have IDE disks and a week old savecore.) Has anybody experienced these? Thanks, szabolcs From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 09:38:36 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Garbage displayed when trying to run X11 on my Retina From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm having difficulties running X11 on my Retina card. I've installed te binaries from 15th of Jun and the kernel is 0.9C #30. When I run X, my monitor goes wild and just displays some running lines and other garbage. Does the server maybe try to open a screen with a very very high frequency ? Anybody else have this problem or am I alone on this one ? John Vrolijk From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 11:25:47 1994 Subject: Re: oops..crypt is from .au To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-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: 663 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Sorry, my memory failed me when I mentioned libcrypt being european... > It's being used in Europe but the author David Burren is naturally from > Australia. (davidb@werj.com.au) Something has recently been brought to my attention RE crypto stuff exporting from australia - the Australian laws _may_ be as harsh as the US laws regarding export. I haven't received an official confirmation of this though. [It's ironic, isn't it. If the US gov. passed the clipper laws, I read that the Aussie gov. would have pushed it through pretty fast too (and the dutch gov. too I also read.) BUT, I doubt we'd change our crypto export laws if the US relaxed theres...] From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 7 12:09:23 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: kernel doesn't link Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu 060794: 1:20am PDT was the last SUP I did. grfabs_cc.c: function cc_init_ntsc_aga - no member called beamcon0 line 1711 and 1860 -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Jul 7 12:12:49 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Status of Picasso support?" (Jul 6, 5:42pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Alan Bair , amiga-x@sun-lamp.cs.berkeley.edu (Amiga NetBSD - X) Subject: Re: Status of Picasso support? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Jul 6, 5:42pm, Alan Bair wrote: > Does the person(s) involved, or anyone else have any idea on the status of > this project? If I was to try doing this on my own, would having the Picasso > AmigaDOS development code provide any help? It's just that i don't have enough time (exams and such things which keeps you occupied). The other 'problem' is, that i must make a LKM out of the stuff due to some restrictions from VT. I hope i can find some time from next week on (Semester finished), can't promise anything though. No, the ADos-Stuff will not help you at all. There is a lot of stuff inside the libraries, which must be implemented as IOCTL which is not documented at all (that's why i must make an LKM out of it, or provide the stuff as .o file). I am sorry, but i can't provide any more help, all help would immediatly go into correspondancy work for other Gfx Boards, which are direct concurrents to Picasso. (What a joke :-/ ) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 7 12:53:14 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: GRF_AGA Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I had GRF_AGA and GRF_NTSC defined.. the other commented out. When I removed the GRF_AGA and enabled GRF_ECS, the error went away. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 15:39:44 1994 From: svelu@kuai.se (Sven Lundblad) To: amiga@sun-lamp.cs.berkeley.edu Subject: getty and parity for console Sender: owner-amiga@sun-lamp.cs.berkeley.edu getty and parity for console Hi! To get the system identification message and login prompt from getty to work properbly (at /dev/ttye0(I changed the default entry in /etc/gettytab (rootfs-940615) as shown below: in /etc/gettytab.old: default:\ :ap:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: #ap=any parity in /etc/gettytab default:\ :np:fd#1000:im=\r\n%s/%m (%h) (%t)\r\n\r\n:sp#1200: #np=no parity What is the proper fix to this? /Sven From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 16:16:09 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: Running the SUP scanner: SUP Scan for current starting at Thu Jul 7 04:07:40 1994 SUP Scan for current completed at Thu Jul 7 04:10:33 1994 SUP Scan for mirror starting at Thu Jul 7 04:10:34 1994 SUP Scan for mirror completed at Thu Jul 7 04:13:05 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 7 16:18:13 1994 From: rhealey@aggregate.com Subject: Re: compiling netbsd.940704 To: niklas@appli.se (Niklas Hallqvist) 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: 310 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > BTW, Rob, thank you very much for revealing the stack underflow fix, > I was going mad... > By the way, the CORRECT fix is to fix the line in locore.s that stores the AGA flag on to tmpstk. You need to add a - after the sp@ like the following lines. It might be fixed in today's sup anyhow... -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 7 16:49:37 1994 From: rhealey@aggregate.com Subject: locore.s in 0708 sup still broken for non-040 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: 319 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The stack underflow fix didn't get in for todays sup so watch out if you use it on a non-040. The fix is to add a - after the sp@ on AGA flag store on the tmpstk area. Look for the string AGA and make that line look like the ones that follow it, i.e. add a -. Hopefully the fix will be in tomorrows sup. -Rob From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 17:07:33 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga@sun-lamp.cs.berkeley.edu Subject: RDB problems Sender: owner-amiga@sun-lamp.cs.berkeley.edu I made a bad thing last night, an are now seeking help. What I did was the BSD? -> NB?? partition name change using HDToolBox. I also added BFFSFileSystem as FS for the new FS type values. Not a big deal, but... afterwards HDToolBox won't recognize my drive. Well, on a virgin disk it usually doesn't as HDToolBox don't work very well with gvpscsi.device, normally one has to describe the disk in the "change drive type" dialog. The thing is, that my renaming removed my old drive description silently, and if I'd go on to remake I have to repartition my drive, as far as HDToolBox is concerned. I *know* the partitioning is still correct as FaaastPrep manages to parse it without problems. So what I want is a RDB editor which allows me to fix just the corrupted fields of the RDB. Are there any such editors? Otherwise I have to pick out some disk editor and do it by hand with all the risks that means. So, does anyone know of a *good* RDB-editing utility? I need it desperately! Niklas PS. Something must've gone wrong when I changed the FS types, as NetBSD now will panic in swap_init. I think this is due to me setting a bad value in the RDB so sd5b won't exist (yes, I'm not using swap on generic, as I want several swap partitions, taking the advantage of interleaved paging activity). Hmm... maybe it is possible to at least boot on GENERIC kernel? Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 7 18:12:20 1994 From: niklas@appli.se (Niklas Hallqvist) To: rhealey@aggregate.com Cc: Hubert.Feyrer@rz.uni-regensburg.de, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: compiling netbsd.940704 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >>>>> "Rob" == rhealey writes: >> In order to compile the kernel with the sources from 940704, I had >> to add the following files to SRCS in the libkern's Makefile: >> >> strncpy.c strcmp.c strcpy.c strncmp.c min.c strcat.c __main.c max.c >> Rob> Hmmm, I didn't have to do this either with my original July 4 Rob> tree or the one I restored from work to try to isolate the Rob> problem with the MMU trap. Maybe Hubert does what I do, keep NetBSD in CVS and imports the tree every now and then, merging the updates into his own branch. This works great, with the exception that one has to be observant wrt changes in the directory tree layout. A new hierarchy was introduced lately, namely sys/lib/libkern/arch. If this was missed when merging baseline code with private, you'll see the problem above. I'm not saying this is what happened, I'm saying it happened to me. BTW, Rob, thank you very much for revealing the stack underflow fix, I was going mad... Niklas PS. I know about "cvs update -d" but you see, I don't want all directories always, thus I cannot use that switch. Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 19:24:46 1994 From: newsham@uhunix.uhcc.Hawaii.Edu Subject: tape drive To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi, I'm getting ready to buy a tape drive (finally). The main purpose of the drive will be to backup my bsd stuff between upgrades and in case of data loss during normal use. I would also like to use the tape drive from amigados and later down the road from future systems I own. It will be a scsi unit. Any advice on what to look for, what to get, what not to get? Ideally it should work right out of the box w/ NetBSD, hopefully even my NetBSD 744 kernel (which needs backing up before I venture on to -current :) Tim N. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 19:28:46 1994 Disclaimer: "The National Aerospace Laboratory NLR DOES NOT ACCEPT ANY FINANCIAL COMMITMENT derived from this message." From: Gerard J van der Grinten Subject: small glitch in bin/sh/mkbuiltins To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 642 Sender: owner-current-users@sun-lamp.cs.berkeley.edu After the "new" test ([) the call from sys/arch/i386/floppy/sh to bin/sh/mkbuiltins -h obje_dir strands on the test: if [ "$1" = "-h" ] ; then .... with: test: unknown -h. suggestion : change line to if [ "X$1" = "X-h" ] ; then so that when a shell is build without history the script also works. Regards, Gerard. PS, this is with current -current 9c. -- 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 Jul 7 19:31:19 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: number for buslogic tech support 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 Sorry to bug y'all with this, but does anyone have the number for BusLogic technical support? I can't find it anywhere in my card documentation, and it's not anywhere I can find on their BBS. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 19:39:16 1994 To: Ken Hornstein Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: number for buslogic tech support <9407071520.AA18300@entropic.com> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Sorry to bug y'all with this, but does anyone have the number for BusLogic >technical support? I can't find it anywhere in my card documentation, and it's >not anywhere I can find on their BBS. > >--Ken 408-492-9090 ----------------------------------------------------------------------------- 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 Jul 7 20:09:53 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: small glitch in bin/sh/mkbuiltins To: gvdg@nlr.nl (Gerard J van der Grinten) 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: 388 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > After the "new" test ([) the call from sys/arch/i386/floppy/sh to > bin/sh/mkbuiltins -h obje_dir strands on the test: > > suggestion : change line to if [ "X$1" = "X-h" ] ; then > so that when a shell is build without history the script also works. No, it's a test(1) bug that has to be fixed before the 1.0 release. I'm on it, and will have the fix to chris real soon now. --jtc From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 20:16:36 1994 From: chopps@emunix.emich.edu To: svelu@kuai.se (Sven Lundblad) Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: getty and parity for console X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I made the proper change in etc/etc.amiga/ttys so it will go into the release. Basically change std.9600 to Pc for ttye0 and ttye1 and console. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 7 21:03:44 1994 Subject: ISO protocols 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: 67 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is anybody using the ISO network protocols with -current? Martin From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 23:41:33 1994 From: niklas@appli.se (Niklas Hallqvist) To: dsnjvro@etmsun.ericsson.se Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Garbage displayed when trying to run X11 on my Retina Sender: owner-amiga@sun-lamp.cs.berkeley.edu >>>>> "John" == John Vrolijk writes: John> I'm having difficulties running X11 on my Retina card. John> I've installed te binaries from 15th of Jun and the kernel is John> 0.9C #30. I don't know what date that kernel was compiled, but I had a similar result on a kernel which hadn't got the Retina fix the readme talked about. Niklas From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 23:42:13 1994 From: Sven Lundblad Subject: Compiling bash-1.14 To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! I have just tried to compile bash-1.14 for NetBSD-Amiga-940615. After some changes to machines.h and siglist.h it compiled. But when I exit bash I get this: bash$ exit Bad jump 34136668 Tell bug-bash@prep.ai.mit.edu to fix this someday. Stopping myself... Process shell abort trap (core dumped) Has anyone compiled a working bash-1.14 for NetBSD-Amiga and if so what changes was necessary to do? /Sven From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 7 23:47:50 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Sven Lundblad , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Compiling bash-1.14 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 7, 9:38pm, Sven Lundblad wrote: > I have just tried to compile bash-1.14 for NetBSD-Amiga-940615. > After some changes to machines.h and siglist.h it compiled. > But when I exit bash I get this: > > bash$ exit > Bad jump 34136668 I'll bet you built bash with the shared libraries (i.e. you didn't specify -static on the ld command). There is a bug in longjump in the shared library version. [34136668 == 0x0208E25C, which I'll bet is the address of _sigreturn in the libc shared image.] > Has anyone compiled a working bash-1.14 for NetBSD-Amiga and > if so what changes was necessary to do? If you change the ld command to include the -static option, it should work. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 00:05:23 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: Floppy problem From: Bryan Ford Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi everyone! Just a few days ago I finally got around to upgrading the incredibly old version of NetBSD-Amiga I had installed on my A3000. (I had an interesting time tracking down this list and the archive; the last I knew everything was still on ftp.eunet.ch. :-) BTW, Markus, you might want to put a file named OBSOLETE or something in the old NetBSD-Amiga directory there, pointing to the new location - the old directory still has a full set of sources and binaries, which for a while I mistook the latest version.) Well, for the most part everything worked wonderfully; great work! There was just one slight hitch... Some time ago I obtained a THIRD internal hard drive for my A3000, and as you other A3000 owners know this is not possible without removing the internal floppy drive(s). I've been running completely floppy-free for quite a while, and that configuration worked fine under AmigaDOS for the most part, and of course the old version of NetBSD didn't know the difference because it didn't support floppy drives. But when I tried to boot the latest version, it just hung during floppy detection, because it's expecting to see a floppy drive that isn't there. I solved this problem without too much trouble by ripping my A3000 apart, putting the floppy drive back in temporarily to get NetBSD to boot, and recompiling the kernel with the floppy driver disabled; then it worked just fine. Anyway, I don't know if this is something worth bothering to fix, since admittedly an Amiga with no floppy drive at all is a somewhat unusual configuration. :-) But I thought I'd mention it anyway. Cheers... Bryan From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 00:15:05 1994 From: mycroft@gnu.ai.mit.edu To: brad@fcr.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Subject: gas Sender: owner-current-users@sun-lamp.cs.berkeley.edu Um, `that's weird'. I just built it last night. Are you sure something in your system isn't hosed? Those symbols normally come from obj-aout.h, which is symlinked to {obj,obj.$(ARCH)}/obj-format.h. Try `rm obj/*'; there might be a stranded copy of the file in there. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 00:30:12 1994 From: Sven Lundblad Subject: Re: Compiling bash-1.14 To: "Michael L. Hitch" 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 Thu, 7 Jul 1994, Michael L. Hitch wrote: > If you change the ld command to include the -static option, it should > work. Yes, that did it. Thanx! /Sven From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 00:33:01 1994 From: Brian Moore To: current-users@sun-lamp.cs.berkeley.edu Subject: Problems building -current Sender: owner-current-users@sun-lamp.cs.berkeley.edu Just tried to upgrade from June 6 sources to July 6 sources, and ran into a wierd problem ( outside of the pax and pppd snafus ). When I make install in stopped in /usr/src/share/doc/psd/05.sysman with the error that it could find the Makefile. The line it was choking on is install -c -o root -g wheel -m 644 Makefile 0.t ... I tried to edit the bsd.doc.mk file to leave out the Makefile, but it now complains about the 0.t file. It obviously is being executed in the wrong directory, but for the life of me I can't figure out what to change. It did install /usr/src/usr.bin/make/PSD.doc fine. I even tried to copy over the Makefile from the make/PSD.doc directory, but with no luck. Has anyone else ran into this or even knows how to fix this. Thanks, Brian Moore ziff@eecs.umich.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 00:33:54 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: gas from current sup won't build Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm (finally) running a current kernel, and attempting to do a full build from the current sup. All the libs build fine and I can build new kernels. rebuilding everything in /us/src I ran into the problem with pppd, which was easy to fix, and not the next snag seems to be gas. gas won't build due to compile errors in obj-aout.c /usr/src/gnu/usr.bin/gas/config/obj-aout.c:43: `N_REGISTER' undeclared here (no\ t in a function) /usr/src/gnu/usr.bin/gas/config/obj-aout.c: In function `obj_crawl_symbol_chain\ ': /usr/src/gnu/usr.bin/gas/config/obj-aout.c:509: `N_REGISTER' undeclared (first \ use this function) /usr/src/gnu/usr.bin/gas/config/obj-aout.c:509: (Each undeclared identifier is \ reported only once /usr/src/gnu/usr.bin/gas/config/obj-aout.c:509: for each function it appears in\ .) /usr/src/gnu/usr.bin/gas/config/obj-aout.c: In function `obj_pre_write_hook': /usr/src/gnu/usr.bin/gas/config/obj-aout.c:633: `AOUT_FLAGS' undeclared (first \ use this function) /usr/src/gnu/usr.bin/gas/config/obj-aout.c:634: `AOUT_VERSION' undeclared (firs\ t use this function) anyone know if gas should/shouldnot build from the current sup? -brad From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 00:35:26 1994 From: Yeng-Chee Su Subject: lfs_cleanerd To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 608 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've noticed libexec/lfs_cleanerd isn't built in Makefile. Is there any special reason for compiling newlfs/mount_lfs without lfs_cleanerd? -- ________________________________________________________________________ / 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 Jul 8 01:24:22 1994 To: Jason Thorpe Cc: Brian Moore , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current <9407072135.AA11659@research.CS.ORST.EDU> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Just tried to upgrade from June 6 sources to July 6 sources, and ran into a > > wierd problem ( outside of the pax and pppd snafus ). When I make install in > > stopped in /usr/src/share/doc/psd/05.sysman with the error that it could find > > the Makefile. The line it was choking on is Delete /usr/src/share/doc/psd/05.sysman/obj This will happen for other directories too; just delete the obj directories or links. They are no longer needed (or desirable). From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 02:26:03 1994 To: Theo de Raadt Cc: Brian Moore , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 07 Jul 1994 15:41:50 -0600 Theo de Raadt wrote: > Delete /usr/src/share/doc/psd/05.sysman/obj > > This will happen for other directories too; just delete the obj directories > or links. They are no longer needed (or desirable). Worked...Thanx... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Jul 8 02:50:04 1994 To: Jason Thorpe Cc: Brian Moore , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current <9407072135.AA11659@research.CS.ORST.EDU> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > whatever I find, I'm going to do a send-pr...I'll just make sure to do > the compile from my xterminal so I can grab the error :-) a little send-pr-happy, are we? 100-to-1 says the problem is that you've got a bogus 'obj' dir or link sitting around in that directory... cgd From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 02:51:56 1994 To: Brian Moore Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 7 Jul 1994 16:35:09 -0400 Brian Moore wrote: > > Just tried to upgrade from June 6 sources to July 6 sources, and ran into a > wierd problem ( outside of the pax and pppd snafus ). When I make install in > stopped in /usr/src/share/doc/psd/05.sysman with the error that it could find > the Makefile. The line it was choking on is > > install -c -o root -g wheel -m 644 Makefile 0.t ... Yeah...I saw it too...I haven't gotten a chance to look at it yet... whatever I find, I'm going to do a send-pr...I'll just make sure to do the compile from my xterminal so I can grab the error :-) > > I tried to edit the bsd.doc.mk file to leave out the Makefile, but it now > complains about the 0.t file. It obviously is being executed in the wrong > directory, but for the life of me I can't figure out what to change. It did > install /usr/src/usr.bin/make/PSD.doc fine. I even tried to copy over the > Makefile from the make/PSD.doc directory, but with no luck. Has anyone else > ran into this or even knows how to fix this. > > Thanks, > Brian Moore > ziff@eecs.umich.edu ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Jul 8 03:06:06 1994 From: Dave Burgess Subject: MSDOS File System woes... To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 604 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I looked in the "ALL" kernel config file and the MSDOSFS option is not commented out any longer. Is anyone but me have problems building a kernel that actually compiles using this option? I wouldn't ask, especially with the imminent release of whatever is coming out next, but I need to have the ability to read and write MSDOS floppies from NetBSD. The errors that I am getting are 'member does not exist in structure' messages for the 'ni' structure (things like 'ni->isdotdot' and the like). As always, it may have been something that I did or am doing wrong. Suggestions will be gladly accepted. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 03:11:38 1994 To: Theo de Raadt Cc: Jason Thorpe , Brian Moore , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Problems building -current <9407072141.AA02592@fsa.ca> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > This will happen for other directories too; just delete the obj directories > or links. They are no longer needed (or desirable). to clarify this a bit: they are no longer needed or desirable _FOR THE DOCS_. that's it. everything else still wants them, or can live with them. basically, the 'doc' dirs will never create them, anymore, so if they're in doc dirs, they're either left-over from times past, or were hand-created... chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 03:18:20 1994 From: Dave Burgess Subject: Re: Problems building -current To: deraadt@fsa.ca (Theo de Raadt) Cc: thorpej@cs.orst.edu, ziff@eecs.umich.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1214 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > > Just tried to upgrade from June 6 sources to July 6 sources, and ran into a > > > wierd problem ( outside of the pax and pppd snafus ). When I make install in > > > stopped in /usr/src/share/doc/psd/05.sysman with the error that it could find > > > the Makefile. The line it was choking on is > > Delete /usr/src/share/doc/psd/05.sysman/obj > > This will happen for other directories too; just delete the obj directories > or links. They are no longer needed (or desirable). > > This is one of those times when 'sup -msv &' sure works well. I check the E-Mail that I get back from sup and look at whatever directories it was unable to delete. I then delete them straight out of elm. Just a thought; since sup is already mucking about deleting files and all, would there be a BIG problem with changing the 'rm -f' or 'rmdir' that is currently used to an 'rm -fr'. The problem seems to be a fairly consistent one (symlink to /usr/obj/* and CVS directories) and I end up using a recursive 'rm' to get rid of them anyway... Of course, if I was a REAL programmer (TM), I would make the change myself and just mail it up to the core team. Maybe I'll be a REAL programmer (TM) this week-end. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 03:19:58 1994 From: Dave Burgess Subject: MSDOS File System prob workaround found. To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 690 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I love having direct Internet access... mtools works just fine. I grabbed the one from ftp.std.com. The only warnings from the system were for lseek() and memcpy() redeclarations, and I just wrapped them in an #ifndef NetBSD and then declared NetBSD. It reads and writes the DOS floppies that I needed to get loaded, so I am in hog heaven again. I am going to take ten minutes this weekend and make up a list of the drive names and their configurations for the FAQ. Of course, I will also include a pointer on how to find out the info yourself in case their is a problem. The ones I needed were fd0a (1.4M 3.5) and fd0f (720K 3.5). They are both drive 'A' and they work just fine. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri Jul 8 07:26:05 1994 From: Herb Peyerl Subject: Re: anyone got netbsd tarballs for usr/bin and friends for hp300 or sun3 To: rminnich@descartes.super.org (Ronald G Minnich) 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: 879 Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu : we've got a need here for /usr/bin and /usr/lib and other such tarballs. : we can create 'em, we're just looking to save some time. we've got the : /sbin and /sbin tars from sun-lamp. Any help anyone can give would really : be appreciated. The application is a 64-node 68030-based network testbed. : Chuck Cranor started from the DA30 tree and we've managed to get up to : single-user shell, and now it's time to build programs ... If 4K LDPGSZ executables will work for you; then you can grab the hp300 ones off lamp (and presumably any of the mirrors). I can't remember the directory offhand but it's where all the binary snapshots are located. hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri Jul 8 07:28:00 1994 From: Ronald G Minnich Subject: anyone got netbsd tarballs for usr/bin and friends for hp300 or sun3 To: netbsd-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu we've got a need here for /usr/bin and /usr/lib and other such tarballs. we can create 'em, we're just looking to save some time. we've got the /sbin and /sbin tars from sun-lamp. Any help anyone can give would really be appreciated. The application is a 64-node 68030-based network testbed. Chuck Cranor started from the DA30 tree and we've managed to get up to single-user shell, and now it's time to build programs ... (the card is heurikon HK68/V30 if anyone cares ... horrible card. ) thanks ron rminnich@super.org | Error message of the week: (301)-805-7451 or 7312 | **Error: vhdlsim,1: | Array subscript out of bounds. | (null)((null)): (null) From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 08:06:57 1994 From: Scott Reynolds Subject: Re: Problems building -current To: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 7 Jul 1994, Chris G. Demetriou wrote: > > This will happen for other directories too; just delete the obj directories > > or links. They are no longer needed (or desirable). > > to clarify this a bit: > > they are no longer needed or desirable _FOR THE DOCS_. that's > it. everything else still wants them, or can live with them. My .02 on the subject, for what it's worth: I haven't used an obj directory since I started compiling NetBSD-current last fall (well, actually, I haven't even seen one since my 386bsd-0.1 days). --scott From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 10:45:29 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, scottr@plexus.com Subject: Re: Problems building -current Sender: owner-current-users@sun-lamp.cs.berkeley.edu I haven't used an obj directory since I started compiling NetBSD- current last fall [...] `Whatever floats your boat.' But I can tell you from personal experience that obj.$(ARCH) directories come in really handy when compiling for two architectures. From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri Jul 8 11:41:38 1994 To: Herb Peyerl Cc: rminnich@descartes.super.org (Ronald G Minnich), netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: anyone got netbsd tarballs for usr/bin and friends for hp300 or sun3 <199407080314.VAA21538@sidney.novatel.ca> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu > If 4K LDPGSZ executables will work for you; then you can grab the > hp300 ones off lamp (and presumably any of the mirrors). hp300 bins at: sun-lamp.cs.berkeley.edu:pub/NetBSD/arch/hp300 amiga bins (8K LDPGSIZE) at: sun-lamp.cs.berkeley.edu:pub/NetBSD/arch/amiga I think they're also mirrored on ftp.iastate.edu. have a ball, and i'm _very_ glad to hear that somebody used the da30 port. We put it in the tree to help people who needed a quick and dirty shell to port from. 8-) chris From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 12:28:17 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Floppy problem" (Jul 7, 1:44pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Bryan Ford , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Floppy problem Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 7, 1:44pm, Bryan Ford wrote: > BTW, Markus, you might want to put a file named OBSOLETE or something > in the old NetBSD-Amiga directory there, pointing to the new location - > the old directory still has a full set of sources and binaries, > which for a while I mistook the latest version.) The interesting thing is, that Markus won't do that, because in his eyes our recent stuff is obsolete :) [...] Funny that Floppy-Bug :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 15:25:52 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: Floppy problem To: baford@schirf.cs.utah.edu (Bryan Ford) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 589 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Anyway, I don't know if this is something worth bothering to fix, > since admittedly an Amiga with no floppy drive at all is a somewhat > unusual configuration. :-) But I thought I'd mention it anyway. Not at all that unusual :-) It is my configuration too! My plan was to add my otherwise unused 100M Quantum as a third internal drive but I didn't have power cable nor correct scsi cable for that purpose. Unfortunately I have been unable to get the internal floppy back alive... The open floppy door is a bit ugly too, I closed it by stamping a Post-It over it :-) Cheers, Tero From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 15:34:26 1994 From: tero.manninen@oulu.fi (Tero Manninen) Subject: Re: Floppy problem To: baford@schirf.cs.utah.edu (Bryan Ford) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD-Amiga) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 589 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Anyway, I don't know if this is something worth bothering to fix, > since admittedly an Amiga with no floppy drive at all is a somewhat > unusual configuration. :-) But I thought I'd mention it anyway. Not at all that unusual :-) It is my configuration too! My plan was to add my otherwise unused 100M Quantum as a third internal drive but I didn't have power cable nor correct scsi cable for that purpose. Unfortunately I have been unable to get the internal floppy back alive... The open floppy door is a bit ugly too, I closed it by stamping a Post-It over it :-) Cheers, Tero From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 15:51:17 1994 Subject: Problems sync'ing fs properly before reboot. From: Thomas Lopatic 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: 902 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, since I've compiled the -current sources of 6/18 and 6/25, my file systems don't get sync'ed properly when I halt or reboot the machine. After inserting a 'sleep (5);' after the sync () in reboot and halt respectively, everything works fine now. Apparently the sync returns before it actually writes the data back to disk. This results in the usual errors which are corrected when restarting the system. Does anyone know why this happens? I've experienced these problems running the GENERICAHA kernel on an ISA 486DX-50, 1542CF w/ Quantum Empire 1080S, no-name IDE adapter w/ IO-ports and a Quantum LPS240AT and an ET4000 graphics adapter. I've set the SCSI host adapter's BIOS and the system BIOS to conservative settings, i. e. no fast scsi, no return immediately after seek, etc. Any pointers on how to solve this problem more elegantly would be greatly appreciated! Thank you, -Thomas From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 16:55:40 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: can't sup Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>> I haven't been able to sup since yesterday; I get "connection >>>> timed out" when trying to connect to sun-lamp, but sun-lamp is >>>> obviously up (I can ping/telnet to it fine from my machine) >> FTP, SMTP, ping all seem to work okay, just not sup :-( > Me too. > for example: > sraihb.sra.co.jp% telnet sup.netbsd.org smtp [works] > sraihb.sra.co.jp% telnet sup.netbsd.org supfilesrv > Trying... > telnet: connect: Connection timed out > "Connection timed out" is something strange, because if supfilesrv > dies, It should be "Connection refused". This usually indicates that the daemon serving new connections (the one doing the accept(2)s) is hung, and the socket's queue of new connections is full. (This queue's size is the parameter to listen(2), and the kernel usually silently puts a hard maximum, typically 10, on it.) Really old kernels (such as, I think, pre-Tahoe 4.3) will refuse the connection when this happens; newer ones just ignore the packet and hope that some pending connection will have been accepted by the time the retransmit arrives. Of course, since supfilesrv is completely wedged, it's never going to accept any new connections, so all retransmits are also dropped, and you get ETIMEDOUT. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 17:29:12 1994 To: mycroft@gnu.ai.mit.edu Cc: brad@fcr.com, current-users@sun-lamp.cs.berkeley.edu From: "Louis A. Mamakos" Subject: Re: Subject: gas <9407071905.AA03763@goldman.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Um, `that's weird'. I just built it last night. Are you sure something > in your system isn't hosed? Those symbols normally come from obj-aout.h, > which is symlinked to {obj,obj.$(ARCH)}/obj-format.h. I had this very same problem.. > Try `rm obj/*'; there might be a stranded copy of the file in there. ..and this seemed to fix it. I noticed that this wasn't caught by doing a 'make depend' prior to building it. Must just be one of those things.. louie From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 17:33:01 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, scottr@plexus.com, mycroft@gnu.ai.mit.edu Subject: Re: Problems building -current X-Sun-Charset: US-ASCII Content-Length: 622 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I haven't used an obj directory since I started compiling NetBSD- > current last fall [...] > > `Whatever floats your boat.' But I can tell you from personal > experience that obj.$(ARCH) directories come in really handy when > compiling for two architectures. I also like pointing the obj dirs at a /usr/obj. Then it's easy to leave /usr/obj out of any backups if you're squeezed for tape space, which is easy for anyone not using something like a DAT or Exebyte drive. You also don't need a bunch of obj.arch dirs/links cluttering your source dirs since /usr/obj will/can be arch unique at one level. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 17:52:42 1994 From: Dave Cornejo Subject: wuarchive ftpd patches? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 258 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone have the patches or instructions on how to get wuarchive ftpd running? Thanks -- Dave Cornejo There is nothing so subtle Dogwood Media as the obvious Fremont, California From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 8 20:16:10 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 --------------------------------- briggs Sat Jul 2 06:11:11 PDT 1994 Update of /b/source/CVS/src/sys/arch/mac68k In directory sun-lamp.cs.berkeley.edu:/f/users/briggs/src/sys/arch/mac68k Added Files: Makefile Log Message: Scam from amiga and update a little for the current tree. May need some more work. --------------------------------- chopps Sat Jul 2 08:53:58 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 Log Message: remove exec_aout.h --------------------------------- chopps Sat Jul 2 14:15:15 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: atzsc.c grfabs_ccglb.c Log Message: couple fixes from Michael. 2091 now uses 24bit only dma (oops) chopps Sat Jul 2 14:16:37 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: vmparam.h Log Message: increase SYSPTSIZE to 2 to accommodate zthreebus devices. --------------------------------- mycroft Sun Jul 3 03:23:32 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Removed Files: fpspnull.s Log Message: Remove bogon. mycroft Sun Jul 3 03:24:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/conf In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/conf Modified Files: files.m68k files.m68k.newconf Log Message: Remove bogon. --------------------------------- deraadt Mon Jul 4 12:30:26 PDT 1994 Update of /b/source/CVS/src/usr.sbin/pppd In directory sun-lamp.cs.berkeley.edu:/c/users/deraadt/norm/src/usr.sbin/pppd Modified Files: auth.c ipcp.c main.c options.c Log Message: devname repair chopps Mon Jul 4 12:38:11 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: disksubr.c swapgeneric.c Log Message: move to new disk minor encoding (parts have lowest 4 bits instead of 3) chopps Mon Jul 4 12:39:15 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/dev Modified Files: fd.c Log Message: move to new disk minor encoding (parts have lowest 4 bits instead of 3) --------------------------------- chopps Mon Jul 4 12:40:14 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: disklabel.h varargs.h Log Message: move to new disk minor encoding (parts have lowest 4 bits instead of 3) remove multiple inclusions protection from varargs.h cgd Mon Jul 4 12:46:47 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/ld/ns32k In directory sun-lamp.cs.berkeley.edu:/usr/src/gnu/usr.bin/ld/ns32k Modified Files: md.c Log Message: fix typo; from phil chopps Mon Jul 4 12:49:10 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: MAKEDEV fstab.tmp Log Message: update for new disk minor encoding, also add example ados to fstab.tmp --------------------------------- cgd Mon Jul 4 13:23:14 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/conf Modified Files: ALL GENERICAHA GENERICBT KICKME PAIN SUN_LAMP Log Message: ISOFS -> CD9660 cgd Mon Jul 4 13:27:20 PDT 1994 Update of /b/source/CVS/src/sys/kern In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/kern Modified Files: kern_acct.c Log Message: minor style nits, change VBAD handling chopps Mon Jul 4 13:28: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: locore.s Log Message: conditional FPSP stuff. --------------------------------- chopps Mon Jul 4 16:16:07 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: MAKEDEV Log Message: add sd7 sd8 and sd9 mycroft Mon Jul 4 16:19:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/i386 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/i386/i386 Modified Files: trap.c Log Message: Fix some profiling stuff. --------------------------------- chopps Mon Jul 4 20:16:18 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: fstab.tmp Log Message: remove blanks. --------------------------------- chopps Mon Jul 4 21:16:12 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: ttys Log Message: change std.9600 to Pc for local ite's (ttye?) --------------------------------- mycroft Tue Jul 5 10:11:27 PDT 1994 Update of /b/source/CVS/src/sys/arch/hp300/conf In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/hp300/conf Modified Files: DUALITY Makefile.hp300 Log Message: Add FPSP magic. mycroft Tue Jul 5 10:12:48 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/conf In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/conf Modified Files: files.m68k files.m68k.newconf Log Message: Remove fpsp.U. --------------------------------- mycroft Tue Jul 5 10:50:35 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp/t Revision/Branch: 1.1.1 Log Message: Import the Motorola 68040 Floaring Point Software Package. Status: Vendor Tag: Motorola Release Tags: fpsp_08_93 N src/sys/arch/m68k/fpsp/DYADIC.CI5 N src/sys/arch/m68k/fpsp/DYADIC.GEN N src/sys/arch/m68k/fpsp/DYADIC.R3V6 N src/sys/arch/m68k/fpsp/FPSP.sa N src/sys/arch/m68k/fpsp/L_ENTRY.AWK N src/sys/arch/m68k/fpsp/L_LIST N src/sys/arch/m68k/fpsp/MONADIC.CI5 N src/sys/arch/m68k/fpsp/MONADIC.GEN N src/sys/arch/m68k/fpsp/MONADIC.R3V6 N src/sys/arch/m68k/fpsp/Makefile N src/sys/arch/m68k/fpsp/bindec.sa N src/sys/arch/m68k/fpsp/binstr.sa N src/sys/arch/m68k/fpsp/bugfix.sa N src/sys/arch/m68k/fpsp/decbin.sa N src/sys/arch/m68k/fpsp/do_func.sa N src/sys/arch/m68k/fpsp/fpsp.h N src/sys/arch/m68k/fpsp/gen_except.sa N src/sys/arch/m68k/fpsp/get_op.sa N src/sys/arch/m68k/fpsp/kernel_ex.sa N src/sys/arch/m68k/fpsp/l_entry.sa N src/sys/arch/m68k/fpsp/l_fpsp.h N src/sys/arch/m68k/fpsp/l_support.sa N src/sys/arch/m68k/fpsp/res_func.sa N src/sys/arch/m68k/fpsp/round.sa N src/sys/arch/m68k/fpsp/sacos.sa N src/sys/arch/m68k/fpsp/sasin.sa N src/sys/arch/m68k/fpsp/satan.sa N src/sys/arch/m68k/fpsp/satanh.sa N src/sys/arch/m68k/fpsp/scale.sa N src/sys/arch/m68k/fpsp/scosh.sa N src/sys/arch/m68k/fpsp/setox.sa N src/sys/arch/m68k/fpsp/sgetem.sa N src/sys/arch/m68k/fpsp/sint.sa N src/sys/arch/m68k/fpsp/skeleton.sa N src/sys/arch/m68k/fpsp/slog2.sa N src/sys/arch/m68k/fpsp/slogn.sa N src/sys/arch/m68k/fpsp/smovecr.sa N src/sys/arch/m68k/fpsp/srem_mod.sa N src/sys/arch/m68k/fpsp/ssin.sa N src/sys/arch/m68k/fpsp/ssinh.sa N src/sys/arch/m68k/fpsp/stan.sa N src/sys/arch/m68k/fpsp/stanh.sa N src/sys/arch/m68k/fpsp/sto_res.sa N src/sys/arch/m68k/fpsp/stwotox.sa N src/sys/arch/m68k/fpsp/tbldo.sa N src/sys/arch/m68k/fpsp/util.sa N src/sys/arch/m68k/fpsp/x_bsun.sa N src/sys/arch/m68k/fpsp/x_fline.sa N src/sys/arch/m68k/fpsp/x_operr.sa N src/sys/arch/m68k/fpsp/x_ovfl.sa N src/sys/arch/m68k/fpsp/x_snan.sa N src/sys/arch/m68k/fpsp/x_store.sa N src/sys/arch/m68k/fpsp/x_unfl.sa N src/sys/arch/m68k/fpsp/x_unimp.sa N src/sys/arch/m68k/fpsp/x_unsupp.sa No conflicts created by this import mycroft Tue Jul 5 10:56:20 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Removed Files: l_entry.sa Log Message: This is generated automagically. mycroft Tue Jul 5 10:58:25 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Modified Files: MONADIC.GEN Makefile bindec.sa binstr.sa bugfix.sa gen_except.sa get_op.sa l_support.sa res_func.sa round.sa sacos.sa satan.sa scale.sa setox.sa skeleton.sa slogn.sa srem_mod.sa ssin.sa ssinh.sa stan.sa stanh.sa sto_res.sa stwotox.sa util.sa x_operr.sa x_snan.sa x_store.sa x_unfl.sa Added Files: DYADIC.GCC MONADIC.GCC Makefile.inc asm2gas netbsd.sa Log Message: Port to NetBSD, with some bug fixes and minor performance tweaks. --------------------------------- chopps Tue Jul 5 20:56:48 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: Makefile.amiga Log Message: update for FPSP changes (taken from hp300) --------------------------------- chopps Tue Jul 5 21:33: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: locore.s vectors.s Log Message: similar changes as the hp300 for FPSP. --------------------------------- chopps Tue Jul 5 22:25:30 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: vectors.s Log Message: remove stranded .globl's --------------------------------- chopps Wed Jul 6 13:51:16 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: disksubr.c Log Message: make disklabel code more sane --------------------------------- chopps Wed Jul 6 14:06:32 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/etc/etc.amiga Modified Files: fstab.tmp Log Message: fix very incorrect comment about partition order in disklabel. --------------------------------- briggs Wed Jul 6 18:46:48 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: locore.s Log Message: Whoops. Forgot to make rei globl in this copy. mycroft Wed Jul 6 18:49:13 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/gas/config In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/gnu/usr.bin/gas/config Modified Files: tc-m68k.c Log Message: Implement `#:' syntax for literal binary representations of floating point numbers. mycroft Wed Jul 6 18:49:59 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Modified Files: x_operr.sa Log Message: Rewrite an odd instruction. --------------------------------- mycroft Wed Jul 6 18:51:19 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Modified Files: asm2gas Log Message: Simplify, speed it up, and do the right thing for floating point constants. --------------------------------- mycroft Thu Jul 7 00:28:50 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Added Files: copyright.s Log Message: .ascii'd version of the copyright. mycroft Thu Jul 7 00:29:08 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/fpsp In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/arch/m68k/fpsp Modified Files: Makefile Log Message: Add copyright; clean up a bit. --------------------------------- chopps Thu Jul 7 09:56:24 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/trees/src/sys/arch/amiga/amiga Modified Files: locore.s Log Message: fix typo that was blowing away MMU table root pointer on A3000's :) --------------------------------- cgd Thu Jul 7 12:16:17 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/b.c/src/sys/arch/amiga/amiga Revision/Branch: netbsd-1-0 Modified Files: locore.s Log Message: from trunk: fix typo that was blowing away MMU table root pointer on A3000's mycroft Thu Jul 7 12:17:28 PDT 1994 Update of /b/source/CVS/src/libexec In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/libexec Modified Files: Makefile Log Message: Add lfs_cleanerd. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 22:24:19 1994 To: Dave Cornejo Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: wuarchive ftpd patches? <199407081355.GAA14393@white.dogwood.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does anyone have the patches or instructions on how to get wuarchive > ftpd running? I sent him the diffs. Note that they're also in the current-users mail archives (i think). chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 22:50:27 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Binaries... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu To all those interested: I have made a binary snapshot from July 5 source for the i386. It is available via anon ftp from: ftp.csos.orst.edu:/pub/NetBSD/NetBSD-current/local_binaries/i386 PLEASE NOTE: This is not an 'official' NetBSD binary snapshot. However, I've seen enough people sending mail about a -current snapshot, I thought I'd make one. Enjoy... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Jul 8 23:11:45 1994 To: Jason Thorpe Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Binaries... <9407081845.AA25823@research.CS.ORST.EDU> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > PLEASE NOTE: This is not an 'official' NetBSD binary snapshot. However, > I've seen enough people sending mail about a -current snapshot, I thought > I'd make one. Also note, i'm planning to kick a snapshot for the i386 out RSN. chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 8 23:18:08 1994 From: Herb Peyerl Subject: Re: Binaries... To: cgd@alpha.bostic.com (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: 513 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : Also note, i'm planning to kick a snapshot for the i386 out RSN. And before anyone else gets ansi (pun intended), I plan to dump an hp300 one onto lamp along with a rootimage RSN. (ie: this wk/end if all goes well and the wind stays low enough to make my windsurfer look unappealing). hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 08:27:39 1994 From: rhealey@aggregate.com Subject: Floppy boot no longer works? 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: 148 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu OK, since updating to July 7th I can no longer do a floppy boot, the kernel panics with panic: pagemove 3 Anybody know what's up here? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 9 09:37:36 1994 From: David Langford Subject: Mosaic binaries? To: current-users@sun-lamp.cs.berkeley.edu X-Blank-Line: This space intentionaly left blank. X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 434 Sender: owner-current-users@sun-lamp.cs.berkeley.edu As long as the subject of binaries is floating around, does anyone have a version of NCSA Mosaic for NetBSD 0.9C? Again thanks. -- /--------------------------------------------------------------------\ | David Langford - Kihei, Maui, Hawaii - langfod@maui.com | | >>>> "Rob" == rhealey writes: Rob> OK, since updating to July 7th I can no longer do a floppy Rob> boot, the kernel panics with panic: pagemove 3 I don't know but maybe you forgot to change your /dev entries on the floppy to match the new 4-bit partitioning scheme. You ought to have the new MAKEDEV in etc/etc.amiga, or else it passwed on amiga-dev some days ago... Just a guess... If it is not a correct one, you'll have to provide more info on when the panic occurs. Good luck! Niklas From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 14:37:10 1994 From: Arthur Hoffmann Subject: NetBSD-current & Term 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: 2078 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hi I already posted about the problem iam having with term since I updated to the latest binaries to NetBSD -current. finally I got term to work again, but I had to set the line to sevenbit and escape the XOn, XOff characters (17, 19). the performance is miserable, I get about 14 - 120 cps on a 9600baud connection. I goyt around 1100 cps with the old system on the same line. using kermit by itself doesn't seem to be any faster. I really would like to know what could cause this behaviour. I didn't need to set term to sevenbit mode before. What has changed in the new rootfs, that might influence the serial line performance. One more thing I found is that when using th e linecheck proram the output on the local (netbsd) machine is clear, nothing needs to be escaped, but on the remote end of the line (Sun4) not even one character comes throug that is valid, they all arrive as invalid packets. eg. Also linecheck hangs at the end and needs to be stopped by typeing it 5 0s. (This is the output of linecheck on the remote machine) Handshaking Handshaking sucessful 0 sending char invalid packet: 0<160>A 1 sending char invalid packet: <177><160>A<129>B<17><195> 2 sending char invalid packet: <178><160>A<130>B<17><195> 3 sending char invalid packet: 3<160>A<3>B<17><195> 4 sending char invalid packet: <180><160>A<132>B<17><195> 5 sending char invalid packet: 5<160>A<5>B<17><195> 6 sending char invalid packet: 6<160>A<6>B<17><195> 7 sending char From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 9 14:57:19 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/parser.c U src/bin/test/test.c U src/libexec/Makefile U src/sys/arch/amiga/amiga/locore.s U src/usr.sbin/config.new/mkswap.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/sup: 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 Sat Jul 9 04:21:12 1994 SUP Scan for current completed at Sat Jul 9 04:23:50 1994 SUP Scan for mirror starting at Sat Jul 9 04:23:51 1994 SUP Scan for mirror completed at Sat Jul 9 04:26:17 1994 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 16:22:50 1994 From: chopps@emunix.emich.edu To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Floppy boot no longer works? <9407090523.AA02165@sirius.aggregate.com> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Yes this is a problem with ffs basically. I would bet that your floppy is formated with ffs using 4k file system blocks and 512 byte fragments. Try formatting a brand new floppy. The problem is that the ffs wants to shuffle blocks, however a bad assumption was made and that was that the fs block would be evenly divisible by the machine page size. People know abou this and are working on it (or will be, I think cgd). Anyway nothing could be done for release. I did however change fd.c to not allow writing of a disklabel with fs blocks that were not a multiple of NBPG. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 16:53:48 1994 From: rhealey@aggregate.com Subject: Re: Floppy boot no longer works? To: niklas@appli.se (Niklas Hallqvist) 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: 727 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Rob> OK, since updating to July 7th I can no longer do a floppy > Rob> boot, the kernel panics with panic: pagemove 3 > > I don't know but maybe you forgot to change your /dev entries on the > floppy to match the new 4-bit partitioning scheme. You ought to have > the new MAKEDEV in etc/etc.amiga, or else it passwed on amiga-dev some > days ago... > Nope! Something much more insideous: The filesystem blocksize MUST match the OS pagesize or KA-BLAMMMMMMO! When I reformatted the floppys to 8k/1k programs ran just fine off of them. So, don't try to run programs off of 4k/512 formatted floppys on the newer kernels or your kernel will go south REAL quick. B^(. 4k/512 still work fine as data disks. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 9 16:59:22 1994 From: niklas@appli.se (Niklas Hallqvist) To: current-users@sun-lamp.cs.berkeley.edu Subject: Strange place for cc's specs file Sender: owner-current-users@sun-lamp.cs.berkeley.edu It's not important but I thought I should ask anyway: Is it intentional that cc looks for a specs file in /2.4.5? Yes, that's a directory directly beneath root! It would be more natural to look in /usr/lib or something, don't you think so? Normally I use FSF's original gcc and then I know where things are, but this time I had to use the sup(plied) :-) version of cc, and I had to ktrace it to know where it looked for it. Well, as I said it's not important, I'll almost never use NetBSD's cc anyway... Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 17:24:09 1994 From: niklas@appli.se (Niklas Hallqvist) To: hoffmann@it.ntu.edu.au Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD-current & Term Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu It's obvious that you get parity on your characters transmitted from your NetBSD system (every digit with an odd number of ones, get a value above 128 printed after the in the linecheck output). You should see to that you have set your line to 8-bit no-parity before you dialup your Sun. Also be sure to not strip the 8th bit. How to do that? It depends on how you dial up your system... I always use kermit and haven't seen the behaviour you describe, maybe you use something else to dialup with, or have another version of kermit than I have. I hope you don't quit your dialer before starting term, but rather stop it. Quitting closes the port thus resets the line to defaults, which I think is the braindead 7bit even parity mode which I hate more than anything. Why would anyone want to waste 12.5% of comm throughput just to get a per-char error detected these days? File transfers are normally transferred in packets with CRC checks and usual terminal conversation are as nice with garbled chars as with a special error symbol shown on the screen. And then there's international character sets which *require* eight bits, but do people care in the US? No. But they ought to care that they lose meta-chars in emacs, of course... Oops, I'm going out of line here, it seems... I hope you get some ideas from this, but if you don't get it to work, feel free to contact me. You shoul know, however, that I am leaving for holiday in one or two days time. Niklas PS. The remote configuration haven't changed, I hope? Maybe your hunting bugs at home, while the real problem is at the other end? Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 19:02:22 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: billc@iceCuBE.cryogenic.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: FPSP errors during compile! Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 9, 12:15am, William J Coldwell wrote: > as: res_func.s:1522: Error: Ignoring junk after expression > 1525 ... > > fcmpd #:0x41dfffffffc000000,fp0 > ^ - is the colon supposed to be here??? Yes. That syntax is used to tell gas that the constant it to be used literally. Otherwise, it will convert the integer value to floating, which isn't what it wanted. This "bug" has been in the fpsp.o file that I orginally built way back when, and was also in the latest fpsp.o that was provided prior to importing the FPSP sources. You need to update as before assembling the FPSP code. [I had used gas 2.0 to create the previous fpsp.o. I started poking around in the cosh() function when it was reported to not be working and found that the hex constants weren't being generated as expected. The same time that Charles fixed the NetBSD gas to use the #: to specify a literal constant, I built gas 2.2. Gas 2.2 assembled the original gas FPSP sources correctl (without the #: format). > If not, asm2gas must be puking.. this is with the latest sup on 0708. Asm2gas is working correctly, gas isn't Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 9 21:58:03 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Question about A3000 kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm working with today's sup (0709) and while building the kernel, I see that fpsp is being assembled with "as -m68040". [I don't have an '040] Is this a problem? -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 9 22:39:04 1994 From: Lammi Jani Subject: top 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: 345 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Has anyone managed to compile top uon current-ish systems? I get a screenful of errors when compiling machine.c -- under older snapshots it compiled fine. -- ------------------------------------------------ Jani Lammi -+*+- l150649@cc.tut.fi ------------------------------------------------ From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 9 23:06:26 1994 Newsgroups: culist.netbsd.amiga Path: rmcormon From: rmcormon@superior.ccs.carleton.ca (Russell McOrmond) Subject: Previous message from myself about TALK/UUCP Organization: Carleton University, Ottawa, Canada Lines: 30 Sender: owner-amiga@sun-lamp.cs.berkeley.edu It always happens this way - as soon as I post a message asking for help, I manage to figure something out myself. The reason why 'talk' did not work was that my address was set up incorrectly in the /etc/hosts file. I had 'localhost' set up correctly, but not my real address. Once I changed it so that all the various addresses for my machine were all 127.0.0.1, then all worked fine. As to UUCP, it is not the binaries that I am missing. Once I got the sources, I found out out where they were supposed to be going, and found out that they were already there. It is configuration files I am missing. The man pages talk about /usr/lib/uucp (files: config, passwd), but that directory did not exist in the snapshot. There is a /etc/uucp, but that directory is empty. Is there a place that I can go to get sample config files for various programs? Thanks! --- Russell McOrmond, Ottawa Ontario, Canada. Work: Array Development Standard Disclaimer applies: I didn't do it, it was an accident! Russell's Home Page From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 9 23:07:47 1994 Newsgroups: culist.netbsd.amiga Path: rmcormon From: rmcormon@superior.ccs.carleton.ca (Russell McOrmond) Subject: 'talk' command/daemon/etc Organization: Carleton University, Ottawa, Canada Distribution: culist Lines: 29 Sender: owner-amiga@sun-lamp.cs.berkeley.edu (Newbie question, sorry ;-) I am slowly trying to get familiar commands up and running. I am today installing UUCP (I tried to compile TaylorUUCP 1.05, but it barfed on one of the include files. I then found out that Taylor 1.04 was included in the NetBSD sources, and that I just need to get the right sources to create the binaries - BTW, I am curious why the complete UUCP binaries were not included in the last snapshot (IE: uux, uuxqt, cu, etc are included, but uucico, etc is not - at least that I could find) I am now wanting to get 'talk' running on my machine. When I do 'talk user' it gives me an error saying that it cannot bind to the port, and gives the number 79 in brackets. I assume the 79 is an error number, and not the port number, as the '/etc/services' file gives a different number for ntalk. Any ideas for setting this up? Thanks. --- Russell McOrmond, Ottawa Ontario, Canada. Work: Array Development Standard Disclaimer applies: I didn't do it, it was an accident! Russell's Home Page From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 9 23:54:56 1994 To: David Langford Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Mosaic binaries? From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Fri, 8 Jul 1994 19:49:18 -1000 (HST) David Langford wrote: > As long as the subject of binaries is floating around, does anyone > have a version of NCSA Mosaic for NetBSD 0.9C? > > Again thanks. Dave...I'm running a BSDI binary of Mosiac...I think it's 2.1...??? Anyway, it works great for me...It's not the one that comes with the BSDI 1.1 cdrom...That one really didn't work to well :-( I got this particular one from ftp.bsdi.com...But it's probably not there anymore... If you'd like a copy of it, let me know... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Sun Jul 10 00:10:56 1994 From: "Stephen J. Roznowski" To: current-users@sun-lamp.cs.berkeley.edu Subject: Relocation of floppy subdirectory? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm curious as to why the code to make floppy-based versions of the 'booting' commands is still buried under sys/arch/i386/floppy. Can/Should this be relocated to ??? (top-level?) since it appears to be useful for more that "just the 386s"? Additionally, it would probably be useful to set up a structure (under /floppy) that allows for architecture specific Makefile.inc's for actually creating the floppies on the specific machines. Thanks, -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 00:47:10 1994 To: "Stephen J. Roznowski" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Relocation of floppy subdirectory? <199407092103.RAA28687@zombie.ncsc.mil> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm curious as to why the code to make floppy-based versions of > the 'booting' commands is still buried under sys/arch/i386/floppy. because: (1) that's where it was in net/2 and Lite, (2) there has been little interest by the other port maintainers in doing the same thing for their ports eventually, there might be something called /usr/src/distrib, or something like that, which will contain things like this, and other distribution tools. "not today." 8-) chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 10 02:49:34 1994 From: chopps@emunix.emich.edu To: "Stephen J. Roznowski" Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Question about A3000 kernel <199407091658.MAA23868@zombie.ncsc.mil> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The FPSP is the floatin gpoint software emulation for the 040. It does not effect the 030 based machines. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 03:22:04 1994 From: kim@dde.dk (Kim Andersen) Subject: Please educate me 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 keep having problems in making a bootable floppy. Even using the script Christos mailed earlier this week, this scripts also has misc. errors as to working on -current. According to a note from Chris disklabelling a floppy is unsupported, but putting boot info onto floppy should work ok. If I do this: dd if=/dev/zero of=/tmp/Junk count=2880 vnconfig -c /dev/vnd0a /tmp/Junk disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/vnd0a floppy I get this message: disklabel: ioctl DIOCSDINFO: Device not configured But the last line of my kernel config reads: pseudo-device vn 4 and I have these devices: crw-r----- 1 root operator 41, 0 Jul 9 18:06 /dev/rvnd0a brw-r----- 1 root operator 14, 0 Jul 7 02:18 /dev/vnd0a Next I do vnconfig -u /dev/vnd0a /tmp/Junk and then dd if=/tmp/Junk of=/dev/fd0a Trying to boot with this floppy is a no-go, it seems as there is no boot information. Trying to do: disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/fd0a floppy just gives lines like: fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 blkno 1 skip 0 cylin 0 status 40 fd0: seek failed st0 c1 cyl 0 fd0: read failed st0 40 st1 1 st2 0 cyl 0 head 0 sec 2 ........ My question is: How do I make a bootable floppy ? (This procedure has worked earlier) The system is updated with the tarballs made on 7/7. Any help much appreciated. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 04:26:28 1994 From: Dave Burgess Subject: The list of floppy devices and a suggestion... To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2354 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Once upon a time, someone asked if the list of the new floppy devices was documented anywhere but the soure code in fd.c. The answer was NO until just a minute ago. I added the list for these devices to the FAQ (in section 6) so that anyone that wanted to use mtools (until MSDOSFS support is repaired) wouldn't have to wade through the source. Here is the entry and the list: 6.5 How can I use mtools with the 'new' floppy naming convention? With the adoption of BSD 4.4, there is a new way of accessing the floppy disk drive types. The method uses the minor device number to specify different media sizes and densities. These densities are established by a table from the file /usr/src/sys/arch/i386/isa/fd.c (in NetBSD, your mileage may vary). The table in FreeBSD's fd.c is likely to be slightly different. The order of the entries defines the order of the minor numbers, so the table below has the following characteristics: /dev/fd0a 1 /* 1.44MB diskette */ /dev/fd0b 2 /* 1.2 MB AT-diskettes */ /dev/fd0c 3 /* 360kB in 1.2MB drive */ /dev/fd0d 4 /* 360kB PC diskettes */ /dev/fd0e 5 /* 3.5" 720kB diskette */ /dev/fd0f 6 /* 720kB in 1.2MB drive */ /dev/fd0g 7 /* 360kB in 720kB drive */ struct fd_type fd_types[] = { { 18,2,0xff,0xcf,0x1b,0x6c,80,2880,1,FDC_500KBPS,2,"1.44MB" }, { 15,2,0xff,0xdf,0x1b,0x54,80,2400,1,FDC_500KBPS,2,"1.2MB" }, { 9,2,0xff,0xdf,0x23,0x50,40, 720,2,FDC_300KBPS,2,"360KB/AT"}, { 9,2,0xff,0xdf,0x2a,0x50,40, 720,1,FDC_250KBPS,2,"360KB/PC"}, { 9,2,0xff,0xdf,0x2a,0x50,80,1440,1,FDC_250KBPS,2,"720KB" }, { 9,2,0xff,0xdf,0x23,0x50,80,1440,1,FDC_300KBPS,2,"720KB/x" }, { 9,2,0xff,0xdf,0x2a,0x50,40, 720,2,FDC_250KBPS,2,"360KB/x" }, }; In order to add a new device (such as a 2.44 Meg floppy) new tables entries are theoretically all that would be needed. As new entries are created, the minor device numbers would increase and the associated device names would be added. ---------------------------- Now that we have adopted this method, would it be appropriate to add a more logical naming convention to our device directory. Something along the lines of Sun or SCO naming would be kind of nice, and would take the voodoo out of figuring out the method.... Just a thought. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 06:31:51 1994 From: William J Coldwell To: current-users@sun-lamp.cs.berkeley.edu Subject: lfs_cksum.c missing in /sbin/dumplfs Sender: owner-current-users@sun-lamp.cs.berkeley.edu If this was discussed already, my apologies. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 07:02:11 1994 To: billc@icecube.cryogenic.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: lfs_cksum.c missing in /sbin/dumplfs <9407100314.AA21187@icecube.cryogenic.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > If this was discussed already, my apologies. It's not been, that i'm aware of... However, you'll note the: .PATH: ${DESTDIR}/sys/ufs/lfs in the dumplfs Makefile, which pulls the file in from the right place.... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 10 07:14:16 1994 From: chopps@emunix.emich.edu (Chris Hopps) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Pre-release binaries. Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have just put a new snapshot on sun-lamp. This is a pre-release snapshot it would be very nice if as many people as possible could test them. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 07:33:36 1994 From: chopps@emunix.emich.edu (Chris Hopps) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Pre-release binaries. Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have just put a new snapshot on sun-lamp. This is a pre-release snapshot it would be very nice if as many people as possible could test them. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 08:30:59 1994 To: "Chris G. Demetriou" Cc: billc@icecube.cryogenic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: lfs_cksum.c missing in /sbin/dumplfs <9407100346.AA24957@alpha.bostic.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > .PATH: ${DESTDIR}/sys/ufs/lfs > > in the dumplfs Makefile, which pulls the file in from the > right place.... Hm, should it be using ${DESTDIR} to pull in source? Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 10:41:46 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: reboot 'n' sync From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu is there a proper fix in the works for the sync problem w/ reboot, yet? this is biting me incredibly hard... a five second delay doesn't even seem long enough... it makes life difficult when it loses the kernel upon reboot. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html "what i used to think was me is just a fading memory..." -- NiN/PHM From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 12:34:54 1994 From: gregc@edi.com (Greg Cronau) Subject: Info request on swapinfo 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: 860 Sender: owner-current-users@sun-lamp.cs.berkeley.edu This isn't specifically a netbsd question, but I was hoping somebody here could point me towards what I need. I saw a comment on the list a few days ago about the "swapinfo" program. I had not been aware of that program, so I took a look at the manpage. This program is perfect for a problem I'm having on another system. I help administer a large, open access, Unix system that is currently running on a Sun 3/260 with SunOS 4.1.1. We are having alot of problems with swap space usage and getting acurate statistics. The swapinfo program is just what I need. Unfortunately, it looks like it might be non-trivial to port it. Before I dove in and reinvented the wheel, I wanted to see if anyone knew of a version of this prog for SunOS, or a program that might give similiar info. vmstat just doesn't give me what I need. Thanks for any help. gregc@edi.com From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 13:53:12 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/etc/etc.amiga/Makefile.inc U src/sys/conf/newvers.sh U src/sys/kern/vfs_subr.c U src/sys/sys/param.h U src/usr.sbin/pppd/options.c Running the SUP scanner: SUP Scan for current starting at Sun Jul 10 03:35:16 1994 SUP Scan for current completed at Sun Jul 10 03:37:35 1994 SUP Scan for mirror starting at Sun Jul 10 03:37:36 1994 SUP Scan for mirror completed at Sun Jul 10 03:40:36 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 17:47:48 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: amiga@sun-lamp.cs.berkeley.edu Subject: Installing NetBSD from scratch Sender: owner-amiga@sun-lamp.cs.berkeley.edu I have just trashed my NetBSD installation while trying to upgrade to a new kernel. I had to run the new MAKEDEV and reboot. I also changed the BSD type FS types to the new NBU type ones. BUT, the new MAKEDEV doesn't create the sd?i -> sd?p device nodes and the way my partitions are arranged on the disk the root filesystem is probably going to be sd6i (I have a lot of ADOS partitions at the start of the disk). Anyway, I think it is too late for me to repair the damage as I am now in a chicken and egg situation ! My question is, what is the recommended method to install NetBSD from scratch (surely not still that old rootfs_720 ?!) I have the boot floppies that were just uploaded to uni-regensburg so I could use these to start the install. I also have a tape drive so I guess it shouldn't be too difficult? TIA, John +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAi3utxYAAAEEAK7VSevj5fswEy8Ooz7BoMgR5AwOUUrR5yWZvCiE7dB7ds/K Y7zMDvU7qDpInWeJouMJkP5G3zD6x+3Uv4s62RmDOBskled4UZbsLYwOtQn2aZxA 6tNDPy7NnuJDJdnuwJnncmJASED8ttz6G9y01tYUe/JCbhhh/ujrAAF+E35dAAUR tCtKb2huIEouIFNoYXJkbG93IDxqb2huQGljZWJlcmcuZGVtb24uY28udWs+ =Qz1o -----END PGP PUBLIC KEY BLOCK----- From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 19:10:02 1994 From: Andrew Cherry To: amiga@sun-lamp.cs.berkeley.edu Subject: Emacs and system crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've been having a problem with Emacs in NetBSD. Bascially, some operations in Emacs will cause my system to freeze up. This happens whether I am running Emacs on the console or under X11R5. I was wondering if anyone is having similar problems. Here is one way I have found of replicating the problem in a fairly consistent manner. M-x gdb Just hit return when it asks for the command-line arguments. Kill the current buffer with C-x k Now repeat the above procedure. On my system, everything freezes after I hit RETURN at the "Kill buffer:" prompt. It might take more tries on another system (or, if you're lucky, it will never happen!) This problem occurs both when using the emacs 19.22 binary from ftp.uni-regensburg.de and when using emacs 19.25 compiled out of the box (using config m68k-hp-netbsd --with-x11). I did some traces with gdb, and found that the last line executed before the crash is a bzero call in relocate() [in ralloc.c]. But since this is not gnu.emacs.bug, I won't provide more detail unless asked (I know nothing about emacs internals anyway :) ). I am running the 6-19-94 GENERIC kernel and the 6-15-94 binary snapshot (the kernel I am using is the one that came with the snapshot). Here is my hardware setup: A2000 GVP G-Force 040 33MHz 12MB RAM (all 32-bit on the G-Force), 1MB CHIP Seagate ST31200N 1 gig SCSI-2 drive Quantum PD105S 100 meg SCSI-1 drive (only used for AmigaDOS filesystems) GVP IOExtender (obviously, not in use in NetBSD). I'm particularly interested if anyone can replicate this problem with a G-Force 040. Right now, I'm not certain if it is a bug in Emacs as configured, a bug in NetBSD, a problem with the hardware, or any combination of the above. -Andrew Cherry (cherry@mcs.anl.gov) From owner-netbsd-users@sun-lamp.cs.berkeley.edu Sun Jul 10 19:17:02 1994 From: Todd.Williamson@cs.cmu.edu To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: SCSI questions Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I'm new to these lists (though I've been running a NetBSD 0.9 system for almost a year now), so please bear with me any of these things have been discussed to death already. I. When I got my computer, it came with a Bustek 542I SCSI controller. I'm considering whether I should upgrade to a VL-bus controller. Questions: 1. Would I expect to see a drastic increase in performance if I did so? 2. The VL-bus controllers that I'm aware of at the BT445 and the Ultrastor 34F. Do both of these work well with NetBSD? Does Adaptec make a VL-bus controller that works with NetBSD? Are there others that work? II. I've been having some trouble with errors on my Quantum LPS240 drive. These usually show up as "medium error." Is there anything I can do about it? Do I have to do something special to get the drive to map the blocks for me? I thought most SCSI drives automatically did bad-block remapping. III. I'm considering getting a 270 MB Syquest removable drive, both as a backup solution and to use as additional storage for stuff that I don't use so often (the X source, for instance). Does anyone here have experience with using a removable drive like this on a UNIX system? How is the performance? Can I just mount/umount the drive, or do I have to do something in software to eject the disk? Thanks, -Todd. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 19:30:32 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Andrew Cherry , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Emacs and system crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 10, 11:22am, Andrew Cherry wrote: > I've been having a problem with Emacs in NetBSD. Bascially, some operations > in Emacs will cause my system to freeze up. This happens whether I am ... > I am running the 6-19-94 GENERIC kernel and the 6-15-94 binary snapshot > (the kernel I am using is the one that came with the snapshot). ... > A2000 > GVP G-Force 040 33MHz ... > I'm particularly interested if anyone can replicate this problem with > a G-Force 040. Right now, I'm not certain if it is a bug in Emacs as > configured, a bug in NetBSD, a problem with the hardware, or any > combination of the above. This looks very much like a problem the 68040 had with the originally distributed /bin/bash and later easily duplicated in gdb by Chris Hopps. There was an error in the writeback code for the 68040 which was fixed around June 22nd, so the 6-19-94 kernel would still have this bug. If this is the case, you will need to update the kernel in one fashion or another. [I still have a 6-20-94 version of the kernel that I think has this fix in it, if you want to just get a fixed kernel. Otherwise you will have to update to a current kernel and all the updated binaries.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 19:41:53 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: john@iceberg.demon.co.uk, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installing NetBSD from scratch Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 10, 4:01pm, John Shardlow wrote: > BUT, the new MAKEDEV doesn't create the sd?i -> sd?p device nodes and > the way my partitions are arranged on the disk the root filesystem is > probably going to be sd6i (I have a lot of ADOS partitions at the > start of the disk). The root partition is always going to be /dev/sd?a. I don't think NetBSD will run with the root partition elsewhere. > Anyway, I think it is too late for me to repair the damage as I am > now in a chicken and egg situation ! You should be OK, if you set the root partition to NBR\7, it will be configured as /dev/sd6a and you should be able to boot up single user. You should then be able to mount the root writable and create the sd?i -> sd?p devices manually. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 19:42:26 1994 From: Tim Chase Subject: pppd & carrier detect 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: 1208 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, I decided to try running pppd it recently and discovered that it would not communicate with a modem that wasn't asserting CD. Looking at the main.c file, I noticed that the O_NDELAY flag was commented out of the open call. It seemed to me that it ought to be there. The only other change required to make it work was to turn off the O_NONBLOCK (using fcntl) following the two calls to set_up_tty. Was I missing something? Was there supposed to be some way that it would have worked if CD wasn't present? It seems to me, since the previously mentioned open call seems was the only place the port was opened that it couldn't have worked. I'd stick a real patch with my changed in this message, but I don't have a good way to paste them into this mail message right now. I just stuck in a bit of code following each of the calls to set_up_tty: /* set line speed, flow control, etc.; clear CLOCAL kf modeo option */ set_up_tty(fd, 0); + { + int i; + i = fcntl(fd, F_GETFL); + i &= ~O_NONBLOCK; + fcntl(fd, F_SETFL, i); + } Also, I uncommented the flag in the open call. Is it a Bad Thing (tm) to use the O_NDELAY open flag? - Tim Chase tim@introl.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 10 21:37:56 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Finally. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I am up and running with the latest kernel and binaries and every #@(#$!#@$ other thing that need to be compiled to make this all work. I did learn a lot... of what you aren't supposed to do ;-). I thank all of those who helped. Oooh.. (shiver).. time to try to install X. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 21:40:37 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: Bill's Helpful Hints Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, I finally compiled a kernel and all of the binaries and installed them! Now this might not seem like a momentous occasion to you. But if you went through what I did, you'll appreciate the following helpful hints. 1) You upgrade to a newer kernel and start getting mount spewing out "device not configured" errors and a bazillion "read-only filesystem" warnings. Solution: You need to update your /dev directory. MAKEDEV all is the answer, though the one Chris sent to the list is now older, but should work for most things. 2) You have your NetBSD partitions on SCSI ID 0, and have an IDE drive in your A4000 with a -current kernel - but you can't seem to get your root dir / from a read-only mode (and you get "Device not configured" errors). Solution: The IDE is reall sd0x and your SCSI drive is now sd7x. You will need to create the /dev/[r]sd7x files using either the MAKEDEV that Chris posted (supposedly, but in practice, this didn't work), or by hand. This means that you will have to boot off of a floppy kernel image that has mknod on it. mknod /mnt/dev/sd7a b 4 112 (sd7a) ... mknod /mnt/dev/sd7h b 4 119 (sd7h) ... mknod /mnt/dev/rsd7a c 8 112 (rsd7a) ... mknod /mnt/dev/rsd7h c 8 112 (rsd7h) ... Use disklabel to find out what your partitions are being mapped to. 3) You get garbage on your console during the login prompt. Solution: edit /etc/ttys and change the :ap: to :np: in the default line. (fixed in latest binaries) 4) You have a Retina and the startup appears on it, but the login appears on the ECS/AGA side. Solution: edit gettytab to turn "on" the #Retina, or console, and turn off the #Amiga line. (fixed in latest binaries) 5) mount complains of problems with the fstab file. Solution: Remove the blank lines from the fstab file. This will require BFFS or a floppy kernel boot disk since you will not be able to edit the file when the filesystem is read-only - unless you fixed the fstab file for your partitions already. (the blank lines have been removed in the latest binaries) COMMENTS: Keep your binaries up to date with your kernels! I got bit severely by this out of my own laziness. Once I got the new kernel compiled, I compiled the binaries and all of the problems (so far) have gone away. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 10 21:53:10 1994 From: Andrew Cherry To: amiga@sun-lamp.cs.berkeley.edu (Michael L. Hitch) Subject: Re: Emacs and system crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Michael L. Hitch writes: > This looks very much like a problem the 68040 had with the originally > distributed /bin/bash and later easily duplicated in gdb by Chris Hopps. > There was an error in the writeback code for the 68040 which was fixed > around June 22nd, so the 6-19-94 kernel would still have this bug. If Thanks; I changed to a more recently built kernel (from sup'ed sources around Jul 2), and the problems went away. I wasn't using this kernel because of what I suspect is a configuration problem; savecore prints this during the boot procedure: Jul 10 13:36:46 crunk savecore: can't find device 0/0 I'm not sure what is causing this problem; device 0/0 does exist (/dev/console, no? Assuming the 0/0 are major/minor numbers). At any rate, I am going to install the lastest snapshot as soon as I've finished downloading it, so this is probably not much of an issue. On an unrelated note, is anyone working on GVP IOExtender support, or is that just on the wish list? I have considered the possibility of writing a driver (Since I have never written a UNIX device driver, it is bound to be an educational experience. :) ), but I would guess it would be a real pain to obtain the necessary hardware information from GVP, considering the results other people have had with them. Some brave soul could try toreverse-engineer GVP's AmigaDOS driver, but that brave soul would not be me. :-) -Andrew Cherry (cherry@mcs.anl.gov) From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 10 22:31:41 1994 From: sverre@lars.nrel.gov (Sverre Froyen) Subject: Cannot mount root rw To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 926 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm trying to upgrade my pc532 from sources compiled late May to the current version and I'm having trouble getting root mounted read/write. Here are the symptoms: bash# mount -u / /dev/sd0a on /: Specified device does not match mounted device bash# df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 16062 15390 -132 101% / /dev/sd0d 220974 200498 9426 96% /usr /dev/sd1e 197342 160902 26572 86% /mnt /dev/sd1d 65758 1328 61142 2% /var bash# As you can see, other partitions mount just fine, but / fails. Root is on /dev/sd0a if it makes any difference. I suspect this is a stupid oversight on my part, but if someone could point me in the right direction I'd be grateful. Sverre -- Sverre Froyen (+1-303-231-1782; FAX: +1-303-231-1271) NREL (National Renewable Energy Laboratory), Golden, CO 80401 email: sverre_froyen@nrel.gov From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 11 01:35:07 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Emacs and system crashes" (Jul 10, 11:22am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Andrew Cherry , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Emacs and system crashes Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 10, 11:22am, Andrew Cherry wrote: > Subject: Emacs and system crashes > > I've been having a problem with Emacs in NetBSD. Bascially, some operations > in Emacs will cause my system to freeze up. This happens whether I am > running Emacs on the console or under X11R5. I was wondering if anyone > is having similar problems. Here is one way I have found of replicating > the problem in a fairly consistent manner. another bites the dust :-) Guess why i've been using vi for years --- (Sorry, couldn't resist, and no, i can't help). -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 11 01:44:05 1994 Subject: SLIP compression 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 How do I enable SLIP header compression? Ifconfig sl0 shows IFF_LINK2 capability set. The manual indicates that this type of flag is useful for turning on compression, but I don't have the man page for sl, so I'm not sure what LINK2 does. -- 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 Mon Jul 11 03:17:02 1994 Subject: Swap on IDE-drives To: amiga-dev@sun-lamp.cs.berkeley.edu From: Jan Roger Wilkens Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm having problems getting NetBSD to recognise my swap-partition. I'm booting from a partition on a SCSI-disk, but the swap-partition is on one of the IDE-disks. NetBSD recognizes the IDE-drive with the swap-partition on when booting up, but it reports "No swap partition found" even though the partition has the right idenntifier. If I mount the swap-partition with mount_mfs, the right size is displayed by 'mount', but the IDE drive-light never blinks. If I mount it on /tmp, everything written to /tmp really goes to RAM, so the system hangs if I copy in 3-5MB. This fstab entry together with 'mount -av' yields the same result: /dev/sd0b /tmp mfs rw Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/sd2a 9823 9054 277 97% / adosfs 1 1 0 100% /ados/dh1 mfs:30 14894 2 14147 0% /tmp etc.. If I change the identifier to NBU\1 and use it as a normal NetBSD- partition (with swap on a SCSI-drive), everything works fine. Could somebody fix this so that swap-partitions on IDE drives is reconized even though the system is booted from a partition on a SCSI-drive? (Search the SCSI-drives for boot-partitions first, then the IDE-drives or something.) Here is what disklabel reports for the IDE-disk that the swap-partition is on: # /dev/sd0c: type: unknown disk: label: SWAP flags: bytes/sector: 512 sectors/track: 35 tracks/cylinder: 15 sectors/cylinder: 525 cylinders: 937 rpm: 3600 interleave: 1 trackskew: 0 cylinderskew: 0 headswitch: 0 # milliseconds track-to-track seek: 0 # milliseconds drivedata: 0 7 partitions: # size offset fstype [fsize bsize cpg] b: 30975 460950 swap # (Cyl. 878 - 936) c: 491925 0 unused 0 0 # (Cyl. 0 - 936) d: 165375 1050 ADOS # (Cyl. 2 - 316) e: 241500 166425 ADOS # (Cyl. 317 - 776) f: 21525 407925 ADOS # (Cyl. 777 - 817) g: 31500 429450 ADOS # (Cyl. 818 - 877) From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 03:42:20 1994 From: Brian Leonard To: current-users@sun-lamp.cs.berkeley.edu Subject: serial weirdness Sender: owner-current-users@sun-lamp.cs.berkeley.edu Up until kernels >4/17, my serial stuff worked great. As soon as I upgraded to 5/2, the serial ports died. I get stuff like: % cu -l /dev/tty00 Connected. (first key I hit...) cu: write: Input/output error Disconnected. % Now, I've already checked for conflicting IRQ's and all that; msdos sees the serial devices just fine, and this same exact setup worked up until 5/2, so I doubt it's the hardware. I've also tried every program I have that uses a serial line and get the same thing every time. Any Ideas? -- While one person hesitates because Brian Leonard he feels inferior, the other is busy paranoid@ccwf.cc.utexas.edu making mistakes and becoming superior. -- Henry C Link From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 06:01:03 1994 From: ivan@darwin.bu.edu (Ivan Vazquez) To: Brian Leonard Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Indeed, Ho! serial weirdness Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Sun, 10 Jul 1994 18:52:09 -0500, Brian Leonard said: > Up until kernels >4/17, my serial stuff worked great. As soon > as I upgraded to 5/2, the serial ports died. I get stuff like: > % cu -l /dev/tty00 > Connected. > (first key I hit...) > cu: write: Input/output error > Disconnected. > % I got the same thing until I forced Carrier Detect on on my modem. I'm running the 5/2/94 binary. Good luck! Ivan From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 06:16:29 1994 From: ivan@darwin.bu.edu (Ivan Vazquez) To: current-users@sun-lamp.cs.berkeley.edu Subject: Source code tarballs with binary snapshots Sender: owner-current-users@sun-lamp.cs.berkeley.edu After having tried to build current from a 5/2 release (never again thank you) I found that the binary snapshots are not so useful without having the source snapshot that corresponds. I can imagine that disk space is probably an issue, but perhaps these new mirror sites would be willing to store them? Just an issue I feel is very important and would help NetBSD flourish. Ivan From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 07:04:41 1994 To: ivan@darwin.bu.edu (Ivan Vazquez) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code tarballs with binary snapshots <9407110231.AA17129@haldane> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > After having tried to build current from a 5/2 release (never again > thank you) I found that the binary snapshots are not so useful > without having the source snapshot that corresponds. The problem with that is that there _is_ no source snapshot that any given binary snapshot corresponds to. It's probably safe to grab the source tarball that happens on the following saturday, but that's as close as you'll get. It's impractical to hope that there must be some source snapshot associated with every binary shnapshot. Consider that there are N architectures which occasionally do binary snapshots and that each source snapshot takes 22M... that's 22N Megabytes of source, about 170M worth, given the number of architectures for which snapshots of various types are made, 90%+ of which will be completely identical... Considering that the following weekend, a mostly-correct set of source tarballs is made... chris From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 07:47:33 1994 To: gregc@edi.com (Greg Cronau) Cc: current-users@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: Info request on swapinfo From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message , Greg Cronau writes: > > [...] Before I dove in and reinvented the wheel, I >wanted to see if anyone knew of a version of this prog for SunOS, or >a program that might give similiar info. vmstat just doesn't give me >what I need. > try: pstat -s -wps From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 08:42:35 1994 Subject: 1.0 alpha, beta? To: current-users@sun-lamp.cs.berkeley.edu From: mmead@vt.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 922 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I administer cray-ymp.acm.stuorg.vt.edu, and have been recently pointed to this list to tune into by Allen Briggs, in the hope that sometime soon it will be possible to test out some 1.0 beta or alpha floppies on our machine. Currently we run a NetBSD 0.9 system, and have been having numerous problems with it; one of which is the ne2000 drivers. I hope I haven't jumped the gun on posting to this list when I should have posted to the newsgroups. If so, I hope someone will excuse my ignorance and help me out the same. I'm planning on upgrading cray-ymp as soon as 1.0 comes out, as well as my home system which currently runs Linux. Thanks for any advice! -matt -- Matthew C. Mead -- System/Network Administration, User Support, Software Devel. Virginia Tech Center for Transportation Research Work Related: mmead@hq.ctr.vt.edu | All Other: mmead@vt.edu WWW: http://thumbtack.bevc.blacksburg.va.us:/~mmead From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 09:50:35 1994 Subject: Re: pppd & carrier detect To: tim@introl.introl.com (Tim Chase) From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 518 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Is it a Bad Thing (tm) to use the O_NDELAY open flag? Does it work for you? I didn't try lately but ran into serious problems some time ago with another project when using O_NDELAY (all IO was blocked some random time after reconfiguring to blocking IO). Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 09:53:51 1994 Subject: Can't make boot floppies 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: 1176 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I played around with Christos' version of the mkboot script, but am unable to build a working set of disks. I'm using -current from yesterday (July 9). The images generated by the script when dd'd to disk won't boot. So I tried disklabel to make a bootable disk myself - but this failed: > [/tmp] root > disklabel -w -B -b /usr/mdec/fdboot -s /usr/mdec/bootfd /dev/fd0a floppy3 > disklabel: ioctl DIOCSDINFO: Input/output error and a bunch of kernel messages. I didn't care, since cgd told us, disklabel won't work on floppies, but they would be usable anyway. So I tried to boot from the floppy - nothing happend. (This has worked before, I made my 0.9a boot disk this way...) I was in doubt, so I used brute force: > cd /usr/mdec; cat fdboot bootfd | dd conv=sync of=/dev/fd0a bs=512 This gave me a bootable disk without a disklabel. I booted from it and the bootstrap loader appeared. While it asked for the kernel to boot, I replaced the floppy with the kernel-copy disk generated by Christos' Script (kernel.fs). The bootstrap loader rejected it because of a missing disklabel :-( So I don't see any way to get a working set of boot disks right now... Martin From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 09:59:19 1994 Subject: Re: Info request on swapinfo To: gregc@edi.com (Greg Cronau) From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Organization: The Other Site - Martin's Museum of Muses X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 481 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I saw a comment on the list a few days ago about the "swapinfo" program. > I had not been aware of that program, so I took a look at the manpage. Just a note: swapinfo isn't there anymore, "pstat -s" now does it's job. Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 11 11:09:55 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: identd probs Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Anyone else getting identd to immediately exit with Error 0x1? What does telnet localhost 113 do on your sites? E-mail please. Cheers -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 14:27:59 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: 3com 3c507's Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a chance to swap out my 8-bit wd8003e's and replace them with 3c507's. However, some things I've noticed concern me. The main thing is that I have to configure the card for ``standard'' mode using the DOS configuration utility. If I set it for ``turbo'' (16-bit) mode it doesn't work under NetBSD, but all the diagnostics under DOS pass From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 11 14:55:37 1994 From: niklas@appli.se (Niklas Hallqvist) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: [srcmastr@sun-lamp.cs.berkeley.edu: sun-lamp CVS commits] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Today on source-changes: > chopps > Sun Jul 10 22:07:43 PDT 1994 > Update of /b/source/CVS/src/sys/adosfs > In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/adosfs > > Modified Files: > adosfs.h advfsops.c advnops.c > Log Message: > fix a `bug' actually just an interface issue, cache last indirect block > to avoid geometrically increasing access time when reading files. Maybe I should share my ideas from the "old" adosfs. I planned on making a mount option flag saying that the adosfs should steal blocks from the swap area building an ufs-like tree of indirect blocks on the fly in order to cut down the access times for randomly accessed files. I had other thoughts as well on the performance tuning topic. Does anybody want to hack adosfs a bit, and like to see a higher performance, contact me and I'll let you know my thoughts. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 15:06:25 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/expr/expr.y U src/sys/arch/amiga/dev/Zeus.script U src/sys/arch/pc532/dev/ncr.c Running the SUP scanner: SUP Scan for current starting at Mon Jul 11 03:45:56 1994 SUP Scan for current completed at Mon Jul 11 03:49:04 1994 SUP Scan for mirror starting at Mon Jul 11 03:49:05 1994 SUP Scan for mirror completed at Mon Jul 11 03:51:39 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 16:12:21 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: fdesc & msdosfs Sender: owner-current-users@sun-lamp.cs.berkeley.edu Will these be working in the near future? I could be doing something awfully wrong, but as far as I can see msdosfs doesn't compile (I think this was discussed, it's not compatible with the new vnode interface yet), and fdesc gives some strange results, like a panic when opening /dev/fd/. I reported this one before, but it seems to happen now under slightly different circumstances (did not have much time to look at it yet), does anyone else have these problems? I was wondering if I am doing something wrong here, because both options are enabled in the i386 ALL config file, which would indicate that they are available and working. - Frank From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 16:21:49 1994 From: Robert Shady Subject: Re: Source code tarballs with binary snapshots To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: ivan@darwin.bu.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 645 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > It's impractical to hope that there must be some source snapshot > associated with every binary shnapshot. Consider that there > are N architectures which occasionally do binary snapshots > and that each source snapshot takes 22M... that's 22N Megabytes > of source, about 170M worth, given the number of architectures > for which snapshots of various types are made, 90%+ of which > will be completely identical... Huh? I think I've missed something here. Did someone say you have to make a seperate source tarball for each platform? I don't think so... Just do a general source tarball like the one that is created on the weekend... From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 16:35:11 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: "Robert L. Shady" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code tarballs with binary snapshots Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Robert Shady writes: > Huh? I think I've missed something here. Did someone say you > have to make a seperate source tarball for each platform? I > don't think so... Just do a general source tarball like the one > that is created on the weekend... if every platform does a binary set on a different day, every platform needs a src set as well, all from different days. -bri From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 11 17:04:38 1994 From: chopps@emunix.emich.edu To: john@iceberg.demon.co.uk Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installing NetBSD from scratch <9407101601.AA003kz@iceberg.demon.co.uk> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > BUT, the new MAKEDEV doesn't create the sd?i -> sd?p device nodes and > the way my partitions are arranged on the disk the root filesystem is > probably going to be sd6i (I have a lot of ADOS partitions at the > start of the disk). > > Anyway, I think it is too late for me to repair the damage as I am > now in a chicken and egg situation ! No your fine. You should have you root partition using dostype NBR\7 right? That will *always* show up as sd6a. However you are correct. I forgot to add more partitions to the sdUp in MAKEDEV. Even in the latest snapshot. [sigh]. Anyway you should be able to boot your system and manually create your extra partitions. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 17:16:10 1994 From: sverre@lars.nrel.gov (Sverre Froyen) Subject: Re: Cannot mount root rw To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 453 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Vax writes: > > possibly a stupid question: > what does your /etc/fstab say? #bash: cat /etc/fstab /dev/sd0a / ufs rw 1 1 /dev/sd0d /usr ufs rw 1 2 > Also, have you tried the full syntax for mount? > e.g. mount -u /dev/sd0a / > > or just: mount -u /dev/sd0a Yes, both give the same error. Sverre -- Sverre Froyen (+1-303-384-6612; FAX: +1-303-384-6531) NREL (National Renewable Energy Laboratory), Golden, CO 80401 email: sverre_froyen@nrel.gov From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 18:10:05 1994 From: Tim Chase Subject: Re: pppd & carrier detect To: martin@euterpe.owl.de (Martin Husemann) 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: 502 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Regarding my question: > > > > Is it a Bad Thing (tm) to use the O_NDELAY open flag? And the response: > > Does it work for you? I didn't try lately but ran into serious problems > some time ago with another project when using O_NDELAY (all IO was > blocked some random time after reconfiguring to blocking IO). Yes, with the simple hax to pppd's main.c I described, it works like a charm with a current sources & kernel. Maybe there was a bug and that's why it is commented out? - Tim From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 20:27:03 1994 To: sverre@lars.nrel.gov (Sverre Froyen) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Cannot mount root rw From: "Gary D. Duzan" Sender: owner-current-users@sun-lamp.cs.berkeley.edu In Message <9407111329.AA25986@lars.nrel.gov> , sverre@lars.nrel.gov (Sverre Froyen) wrote: =>Vax writes: =>> =>> possibly a stupid question: =>> what does your /etc/fstab say? => =>#bash: cat /etc/fstab =>/dev/sd0a / ufs rw 1 1 =>/dev/sd0d /usr ufs rw 1 2 => =>> Also, have you tried the full syntax for mount? =>> e.g. mount -u /dev/sd0a / =>> =>> or just: mount -u /dev/sd0a => =>Yes, both give the same error. => Would you happen to have an inactive IDE in the system? I had a similar problem when I was moving from IDE to SCSI. If so, try pulling the IDE card and see what happens. Or maybe try the latest boot blocks and see if they help. Gary D. Duzan Humble Practitioner of the Computer Arts From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 11 20:31:19 1994 From: Hubert Feyrer Subject: floppy?.dms 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: 1734 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've tried the floppy?.dms-floppies on a friend's Amiga 2000 (6MB RAM, A2091, Picasso plugged in). After loading the kernel (from floppy), we got the usual black font on grey backround, supposedly giving the usual information during boot. Only drawback: you can barely read anything, as the whole text flickers from left to right and back very fast, making it VERY hard to read anything! This seems like a software-failure to me, as it appeared also when we used the output of the display enhancer (surpassing the Picasso). Then, it stops while scanning all disks. The 2nd last line says something about 'dmamask', but it's hard reading anything else, especially the last line printed. After that, the SCSI-bus is locked (light stays on), and the system is stuck. I know this problem can be handled by patching _sbic_inhibit_sync (in dev/sbic.c), but this should be handled somehow by the kernel. It's stupid to use two kernels just for handling differend sync-negotiation when one disk needs it, and others not. And now for something completely different ;) While playing around with the discs, I came about some other thing: The resolution NetBSD uses for booting. Wouldn't it be possible to use the same resolution in NetBSD that was used on the Amiga-OS side when booting NetBSD? CU, 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 Jul 11 20:32:12 1994 From: Scott Reynolds Subject: Re: Mosaic binaries? To: Jason Thorpe Cc: David Langford , 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 Sat, 9 Jul 1994, Jason Thorpe wrote: > Dave...I'm running a BSDI binary of Mosiac...I think it's 2.1...??? > [...] > I got this particular one from ftp.bsdi.com...But it's probably not there > anymore... FYI, there is a copy of Mosaic 2.4 on ftp.bsdi.com, and it runs under -current as of 07 Jul. I've still got to work out a little bit of flakiness wrt XKeysymDB and the proxy stuff (which most people don't need anyway), but it does come up... --scott From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 20:34:08 1994 To: Scott Reynolds Cc: David Langford , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Mosaic binaries? From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Mon, 11 Jul 1994 10:29:24 -0500 (CDT") Scott Reynolds wrote: > On Sat, 9 Jul 1994, Jason Thorpe wrote: > > > Dave...I'm running a BSDI binary of Mosiac...I think it's 2.1...??? > > [...] > > I got this particular one from ftp.bsdi.com...But it's probably not there > > anymore... > > FYI, there is a copy of Mosaic 2.4 on ftp.bsdi.com, and it runs under > -current as of 07 Jul. I've still got to work out a little bit of > flakiness wrt XKeysymDB and the proxy stuff (which most people don't need > anyway), but it does come up... Thanx for the pointer... BTW...I fixed the XKeysymDB problem with the following... ln -s /usr/X386 /usr/X11 BSDI uses /usr/X11...once it can find the file, the problem goes away... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Mon Jul 11 21:07:16 1994 From: gregc@edi.com (Greg Cronau) Subject: Re: Info request on swapinfo To: martin@euterpe.owl.de (Martin Husemann) 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: 1202 Sender: owner-current-users@sun-lamp.cs.berkeley.edu A couple of days ago I put out a request on this list for information on the "swapinfo" program. I was looking for a version that runs under SunOS. At least a dozen people wrote back saying I could use "pstat -s" or "pstat -T" on SunOS. Thanks for the info, however, "pstat" doesn't give me all the info that swapinfo does. Specifically, swapinfo will dump out a list of all the allocated swap blocks and their sizes. So pstat isn't an acceptable substitute. Now today this item showed up on the list: Martin Husemann >> I saw a comment on the list a few days ago about the "swapinfo" program. >> I had not been aware of that program, so I took a look at the manpage. > >Just a note: >swapinfo isn't there anymore, "pstat -s" now does it's job. I am running -current from 4/03. pstat didn't exist at that point. Does the current version of pstat do everything that swapinfo does, or are we loosing functionallity? Speciffically, can pstat produce the output that "swapinfo -m" does? BTW, swapinfo.c says that it was "written by Chris Torek, converted to NetBSD by cgd, and based on a program by Kevin Lahey". Does anyone know on what platforms the Torek & Lahey versions ran? Thanks gregc@edi.com From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 11 21:33:40 1994 Newsgroups: culist.netbsd.amiga Path: rmcormon From: rmcormon@superior.ccs.carleton.ca (Russell McOrmond) Subject: Interlocking tty devices for Indial/Outdial on serial port. Organization: Carleton University, Ottawa, Canada Distribution: culist Lines: 16 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I am curious if anyone has any details on being able to set up NetBSD so that one can dial out of the serial port at the same time as GETTY is waiting for a connect. I know that this type of thing can be done using interlocking devices (Different device names for getty and uucico dialing out), but have no real idea how to set this up. Is this something supported in the distributed kernel? Thanks. --- Russell McOrmond, Ottawa Ontario, Canada. Work: Array Development Standard Disclaimer applies: I didn't do it, it was an accident! Russell's Home Page From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 21:46:40 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, vdlinden@fwi.uva.nl Subject: Re: fdesc & msdosfs Sender: owner-current-users@sun-lamp.cs.berkeley.edu msdosfs should be working `soon'. I can't reproduce your problem with fdesc. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 22:46:53 1994 To: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: pppd & carrier detect 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 it a Bad Thing (tm) to use the O_NDELAY open flag? > >Does it work for you? I didn't try lately but ran into serious problems >some time ago with another project when using O_NDELAY (all IO was >blocked some random time after reconfiguring to blocking IO). It works great for me; in fact it was the only way I could get pppd to talk over the serial line and respect CD. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 23:09:15 1994 To: Robert Shady Cc: cgd@alpha.bostic.com (Chris G. Demetriou), ivan@darwin.bu.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code tarballs with binary snapshots <199407111332.JAA14671@zeus.id.net> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Huh? I think I've missed something here. Did someone say you have to make > a seperate source tarball for each platform? I don't think so... Just do > a general source tarball like the one that is created on the weekend... It was said that the binary snapshots should have attendant source snapshots... Given that, you need one per binary snapshot... cgd From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 23:27:37 1994 To: Dave Burgess Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: The list of floppy devices and a suggestion... <199407092231.RAA03087@s069.infonet.net> 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 > /dev/fd0a 1 /* 1.44MB diskette */ > /dev/fd0b 2 /* 1.2 MB AT-diskettes */ > /dev/fd0c 3 /* 360kB in 1.2MB drive */ > /dev/fd0d 4 /* 360kB PC diskettes */ > /dev/fd0e 5 /* 3.5" 720kB diskette */ > /dev/fd0f 6 /* 720kB in 1.2MB drive */ > /dev/fd0g 7 /* 360kB in 720kB drive */ Please correct me if I'm wrong, but I don't think this is quite right. From fd.c: fd_dev_to_type(fd, dev) struct fd_softc *fd; dev_t dev; { int type = FDTYPE(dev); return type ? &fd_types[type - 1] : fd->sc_deftype; } This would imply that fd0a is the "default" type determined from the probe, and the rest follow the above densities, exept moved down by one. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 11 23:28:37 1994 To: "John F. Woods" Cc: "Chris G. Demetriou" , Robert Shady , ivan@darwin.bu.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code tarballs with binary snapshots <9407111940.AA06530@kaos.ksr.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Well, if binary snapshots always came from the weekend source tarball, then > the same source snapshot would do for all the binary snapshots. Except that a binary snapshot for each architecture isn't made every week -- so even if they were "weekend aligned", you'd still need several weekends of source snapshots. (As for the thought of including diffs from the previous source tarball in the snapshot: (1) not too easy, (2) then you _still_ need several of weekends- worth of source tarballs around...) > But I was under the impression that, handy though they are, the occasional > binary snapshots weren't an official goal, so I don't see any justification > for a lot of fuss. Quite right. The point is to kick out something that 'random people' can install occasionally. It's _not_ meant to supplant sup or the weekly tar-balls, for normal use. It's not a "supported service," and it was stated a while ago that the binary snapshots have no direct relation to the source tarballs -- in general, the tarballs from the following weekend are "safe" to use with a snapshot but that's not guaranteed. I'm not concerned at all that they don't match up with the source tarballs. chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 00:30:21 1994 To: "Chris G. Demetriou" Cc: Robert Shady , ivan@darwin.bu.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Source code tarballs with binary snapshots <9407111922.AA20239@alpha.bostic.com> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Huh? I think I've missed something here. Did someone say you have to make > > a seperate source tarball for each platform? I don't think so... Just do > > a general source tarball like the one that is created on the weekend... > It was said that the binary snapshots should have attendant > source snapshots... Given that, you need one per binary > snapshot... Well, if binary snapshots always came from the weekend source tarball, then the same source snapshot would do for all the binary snapshots. Of course, a weekend source snapshot that works fine on one architecture may not work on another (or any other), which is why the issue really came up in the first place. If it were an important goal to provide these snapshots on a regular basis as easily-reconstructible systems, one could perhaps combine a weekly source tarball with a tar of those source files that *had* to be fixed for a given architecture's weekly build. But I was under the impression that, handy though they are, the occasional binary snapshots weren't an official goal, so I don't see any justification for a lot of fuss. For anyone who wishes to provide weekly binary snapshots without storing a full corresponding source tree, I offer the above method. (Actually, since weekly binary snapshots are a lot of work, perhaps some central archive could store the first weekly source snapshot of each month, and the delta souce tars would be relative to that.) For anyone who feels providing binary snapshots with such rigor isn't worth quite that much effort -- you're probably right, and thanks for whatever you can manage. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 02:42:18 1994 From: banshee@resort.com (John Vinopal) To: current-users@sun-lamp.cs.berkeley.edu Subject: i386 XFree 2.1.1 binaries? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone have a recent compile available? iastate, laas, and hulk.sfsu have March-May builds which are looking for libc.so.4.0 which I just don't have (though I do still have 3, 8, and 9 ;) -john From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 12 03:21:54 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: how about... Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Ok, yell at me. I don't want the sdXx IDs to match their SCSI IDs at all now, since the number of IDE drives messes with it anyways. So, how about having them just increment from sd0? On my NeXT, I have an ID 0 and an ID 6, they may to sd0 and sd1 respectively. Basically the same way that rst0 always maps to the 1st tape drive regardless of its SCSI ID. Alternatively, mapping IDE0 and IDE1 to sd8 and sd9 might not be so bad, if the other suggestion goes down in flames... Cheers -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 04:52:53 1994 From: Olaf Seibert To: kenh@wrl.epi.com, burgess@s069.infonet.net Subject: Re: The list of floppy devices and a suggestion... Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > /dev/fd0a 1 /* 1.44MB diskette */ > /dev/fd0b 2 /* 1.2 MB AT-diskettes */ > /dev/fd0c 3 /* 360kB in 1.2MB drive */ > /dev/fd0d 4 /* 360kB PC diskettes */ > /dev/fd0e 5 /* 3.5" 720kB diskette */ > /dev/fd0f 6 /* 720kB in 1.2MB drive */ > /dev/fd0g 7 /* 360kB in 720kB drive */ Would it not be a Good Thing(tm) to have at least one auto-detecting pseudo-partition? And an Even Better Thing(tm) to have support for disks with extra sectors per track? (In fact, support for the one virtually implies support for the other, in both directions.) To indicate that this is not totally ridiculous: my device driver for the Amiga to handle pc format disks (messydisk.device) does just that. The only divine guidance it needs is for 40-track disks in 80-track drives, i.e. it assumes that the number of tracks on the disk normally matches that of the drive. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl Ooey-Gooey-Fluffy-Barfie \X/ I'm not weird, I'm differently percepted. D787B44DFC896063 4CBB95A5BD1DAA96 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 12 06:40:52 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: Perl bombs unless linked statically To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 152 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Another datapoint for the longjump problem. Perl 4.036 dies almost immediately in the tests with a longjump error unless linked statically. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 12 07:45:56 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: rhealey@kas.helios.mn.org (Rob Healey), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Perl bombs unless linked statically Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 11, 10:58pm, Rob Healey wrote: > Another datapoint for the longjump problem. Perl 4.036 dies almost > immediately in the tests with a longjump error unless linked > statically. I think if you use _setjmp and _longjmp instead, it should work. The _longjmp() doesn't call sigreturn() at the end, which is what longjmp() does. Since sigreturn() is another shared library entry, I think the first call to it requires a jump table to be updated. That update process destroys the return value in D0. After the first call, the jump table has the proper address and longjmp should return with the correct value in D0. I haven't figured out a clean way to correct this problem yet. D0 is supposed to be a scratch register, and is treated that way in the binder_entry() routine in ld.so [which is where I think the longjmp return value is getting clobbered]. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 12 08:03:36 1994 From: chopps@emunix.emich.edu To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: how about... <9407120025.AA00299@icecube.cryogenic.com> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Ok, yell at me. I don't want the sdXx IDs to match their SCSI IDs at all > now, since the number of IDE drives messes with it anyways. So, how about > having them just increment from sd0? I would love to however I don't think everyone else will `getit'. My personal kernel says: sd0 at scsibus0 target 0 lun 0 sd* at scsibus? target ? lun ? and thats it. When the bernoulli is turned on (at id 5) it shows up at sd1. > On my NeXT, I have an ID 0 and an ID 6, they may to sd0 and sd1 respectively. > Basically the same way that rst0 always maps to the 1st tape drive regardless > of its SCSI ID. > right. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 09:12:12 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rhialto@mbfys.kun.nl Subject: Re: The list of floppy devices and a suggestion... Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...] my device driver for the Amiga to handle pc format disks (messydisk.device) does just that. It might be easy to deal with any oddball disk format when you're essentially reading raw data from the detection circuitry on the drive (as is my understanding of the Amiga floppy drive), but on the PC we have a not-so-pretty interface in the way. It could be done, but it's a pain, and I'm not sure it's worth the effort. Perhaps a way to program the parameters at run time would be simpler and satisfy people's needs. The short answer is that if you're going to use an oddball disk format, you should expect to have to pay for it. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 09:12:15 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rhialto@mbfys.kun.nl Subject: Re: The list of floppy devices and a suggestion... Sender: owner-current-users@sun-lamp.cs.berkeley.edu BTW, I should add that I'm all for someone else going off and doing it. I just can't justify spending any time on it at the moment. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 10:10:23 1994 From: Yeng-Chee Su Subject: bootable floppy To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 751 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does there anyone successfully make a bootable floppy? The kernel refused to boot on floopy and always got a vm fault in supervisor mode. The same runs fine by booting from hard disk. Also, I can't disklabel a bootable floppy too. I finally install the loader by an old machine. -- ________________________________________________________________________ / 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 Tue Jul 12 13:16:13 1994 From: Yeng-Chee Su Subject: floppy boot failed To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1547 Sender: owner-current-users@sun-lamp.cs.berkeley.edu As I stated in the previous mail, the kernl can't be booted by floppy. I compiled another GENERICAHA with DDB and save its output below. ie0: unknown AT&T board type code 0 ie0: can't map 3C507 RAM in high memory npx0 at isa0 port 0xf0-0xff: using exception 16 biomask 4040 netmask 1a ttymask 1a changing root device to fd0a vm_fault(f8194690, 0, 1, 0) -> 5 kernel: page fault trap, code=0 Stopped at _tsleep+0x149: incl 0x40(%eax) db> trace _tsleep(f822a004,4,f8159cad,0) at _tsleep+0x149 _thread_sleep(f822a004,f822a004,0) at _thread_sleep+0x35 _lock_write(f822a004,f8194714,f8195fb0,f818f204,4c) at _loca_write+0x53 _kmem_alloc(f822a000,1000,3,f7bfff80,f810a8d6) at _kmem_alloc+0x2a _pmap_pinit(f8194714,1affac,1be000,1be000,f8229000) at _pmap_pinit+0x17 _main(f7bfff8c) at _main+0x202 db> From the stack trace, it seems the problem is caused by pmap initialization failed. But I can't see anything different between floppy and hard drive. The kernel is most up to date on July 10 (plus timezone difference). The machine is VL/IDE,486DX2-66 with 16Mb main memory. -- ________________________________________________________________________ / 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 Tue Jul 12 15:17:47 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: Running the SUP scanner: SUP Scan for current starting at Tue Jul 12 03:36:27 1994 SUP Scan for current completed at Tue Jul 12 03:38:53 1994 SUP Scan for mirror starting at Tue Jul 12 03:38:54 1994 SUP Scan for mirror completed at Tue Jul 12 03:41:32 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 16:58:09 1994 From: Alan Barrett Subject: ENOTTY vs. EOPNOTSUPP vs. ENXIO 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 trying to figure out why disklabel doesn't like vnd* devices, and discovered that the vnode disk driver in sys/dev/vn.c doesn't support the DIOC* ioctl's used by disklabel, and returns ENXIO for unsupported ioctl() calls. Most of the other drivers I looked at return ENOTTY for unrecognised ioctl() calls, but kernfs returns EOPNOTSUPP. Is there a good reason for these differences, or is it a bug? --apb (Alan Barrett) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 17:28:13 1994 From: Dave Burgess Subject: AHA-1522 reminder... To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 74 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could someone remind about why we can't use Adaptec 1522 controllers? iCo From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 17:32:47 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu, rhialto@mbfys.kun.nl Subject: Re: The list of floppy devices and a suggestion... <9407120528.AA26607@goldman.gnu.ai.mit.edu> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > BTW, I should add that I'm all for someone else going off and doing it. > I just can't justify spending any time on it at the moment. I actually have a stock of floppies in odd formats (if I remember correctly, 9 512-byte sectors on 5.25" media), so if someone can suggest a good reference work on PC floppy hardware (hahahahahahaha), I'd be motivated to look into it. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 18:24:32 1994 From: Dave Burgess Subject: Re: AHA-1522 reminder... To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 647 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > Could someone remind about why we can't use Adaptec 1522 controllers? > > Long ago, in the dark ages, there was no driver for the 1520 and 1522. > However, the `aic6360' driver is supposed to work with the 6260 chip > that is on those boards. When I asked around, nobody claimed to have > tested it, though. I just bought 4 of these for $10. I will be getting to it this week. I need to compile a new kernel with 6360 support in, but t will be happening shortly. > > So, the short answer is that it's supposed to work, and it's a bug if > > > it doesn't, but we're not actually sure until someone pipes up and tells > us. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 18:25:02 1994 From: mycroft@gnu.ai.mit.edu To: burgess@s069.infonet.net, current-users@sun-lamp.cs.berkeley.edu Subject: Re: AHA-1522 reminder... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could someone remind about why we can't use Adaptec 1522 controllers? Long ago, in the dark ages, there was no driver for the 1520 and 1522. However, the `aic6360' driver is supposed to work with the 6260 chip that is on those boards. When I asked around, nobody claimed to have tested it, though. So, the short answer is that it's supposed to work, and it's a bug if it doesn't, but we're not actually sure until someone pipes up and tells us. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 18:28:57 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, burgess@s069.infonet.net Subject: Re: AHA-1522 reminder... X-Sun-Charset: US-ASCII Content-Length: 1034 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Could someone remind about why we can't use Adaptec 1522 controllers? > iCo > Maybe we can. I've asked this question, Charles Hannum has asked this question. The aic6360 driver *may* work for an AIC-6260 as well (what is used in the 1522 controller). However, I and he haven't heard from anyone using this driver with anything other than a AIC-6360. Jarle Greipsland wrote this driver. I made one minor change that let the probe maybe work with a 6260 (it used a register only available on the 6360) and cooexist with some DOS device drivers for this same board (that left the board in a somewhat odd state that the original probe didn't like). Charles Hannum did some further cleanup and it's now really in the NetBSD source tree. However, we'd really like to know: Has anyone used the aic6360 driver with anything other than an AIC-6360, like an Adaptec 1520/1522 adapter? The 6360 is found on some motherboard embedded SCSI controllers as well as some multi-media boards including the SoundBlaster SCSI-2. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 18:32:28 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, yenchee@zeus.csie.nctu.edu.tw` Subject: Re: bootable floppy X-Sun-Charset: US-ASCII Content-Length: 951 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've kind of fudged. I was able to successfully create some floppies back in April and I've been reusing them. I just dd the disk image to the new floppy, rm the old files and copy in new ones. I have a bootable kernel and seperate very complete rootfs (courtesy of crunch, works great, less filling). At the time I used disklabel and newfs w/o too many problems. I ended up having to create a disktab entry for a 1.44M floppy and using that for disklabel. The entry I created was slightly different than the default one. This works with a June 2 current as well, can't say for present. # Marks Additions ufloppy|3.5in High Density Floppy for Unix:\ :ty=floppy:se#512:nt#2:rm#300:ns#18:nc#80:\ :pa#2880:oa#0:ba#4096:fa#512:ta=4.2BSD: \ :pb#2880:ob#0:\ :pc#2880:oc#0: This is identical to the floppy entry except for the ta item on partition0. For current you may have to delete the b and c entries. -Mark From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 12 20:55:09 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: top To: l150649@proffa.cc.tut.fi (Lammi Jani) 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: 413 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Lammi Jani wrote: > Has anyone managed to compile top uon current-ish > systems? I get a screenful of errors when compiling > machine.c -- under older snapshots it compiled fine. I am working on getting the bsd4.4 version to work. What happened is that some of the necessary defines got renamed. I am working on finding out those changes. Ron Roskens From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 12 22:04:51 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: i386 com no CD? Sender: owner-current-users@sun-lamp.cs.berkeley.edu July 11th kernel; X works, ati busmouse works. tip com0 produced "link down". kermit connects if the modem is powercycled. CD never goes high. I recall a patch for something akin to this a week or so back. Could someone mail me the patch or more info? Thanks. -john From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 00:04:56 1994 To: Alan Barrett Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: ENOTTY vs. EOPNOTSUPP vs. ENXIO X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I was trying to figure out why disklabel doesn't like vnd* devices, and > discovered that the vnode disk driver in sys/dev/vn.c doesn't support > the DIOC* ioctl's used by disklabel, and returns ENXIO for unsupported > ioctl() calls. Most of the other drivers I looked at return ENOTTY for > unrecognised ioctl() calls, but kernfs returns EOPNOTSUPP. Is there a > good reason for these differences, or is it a bug? Actually, it's a bit unclear what the appropriate behaviour is... ENOTTY means "Inappropriate ioctl for device." What if an ioctl() _is_ appropriate, just isn't supported by that device (e.g. disklabels on the vn devices). ENOTTY should probably occur for things like TIOCSCTTY on a vn device -- it's just not appropriate to try to set a disk to be your controlling terminal. 8-) EOPNOTSUPP is "Operation not supported," but it only recently started (i.e. in kernfs, et al.) to be used for non-networking code. It was originally meant for "operation not supported on socket." ENXIO is the traditional error return for unsupported ioctls()... It should probably be cleaned up and made consistent, but it could actually be difficult to distinguish between cases where ENOTTY and EOPNOTSUPP (or ENXIO) should be returned. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 00:08:13 1994 From: pdokas@pms988.pms.ford.com (Paul Dokas) Subject: 4.4 manuals + CDROM from ORA To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 319 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Just FYI; I just got off of the phone with O'Reilly & Assoc. apparently, all of the 4.4 manuals and the US-only CDROM are now available. Sorry, the non-US CDROM is NOT ready yet, it'll be a couple more weeks. My copy is now on it's way. 8-P~~ (yes, drooling. I can't wait!) Paul Dokas pdokas@pms988.pms.ford.com From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 01:35:59 1994 From: Alan Barrett Subject: Re: ENOTTY vs. EOPNOTSUPP vs. ENXIO To: "Chris G. Demetriou" 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 > Actually, it's a bit unclear what the appropriate behaviour is... Here's my suggestion: ENXIO "Device not configured". The device major/minor number doesn't make sense (e.g. driver not configured in kernel, too few minor numbers configured in kernel, vnd device not yet attached to a file). EOPNOTSUPP "Operation not supported". We know what is wanted, it is appropriate for this device, but it's not supported yet (e.g. disk labels on vnd devices, file locking in NFS). ENOTTY "Inappropriate ioctl for device". Either we know what this request is for and so know that it's inappropriate, or we don't know what it's for and so assume that it's inappropriate for this class of device. The above can easily be implemented in the device driver ioctl switches by having the default case return ENOTTY and having certain specific cases return EOPNOTSUPP. > ENXIO is the traditional error return for unsupported > ioctls()... My (limited) experience is that ENOTTY is usually used for unsupported ioctls. --apb (Alan Barrett) From owner-tech-kern@sun-lamp.cs.berkeley.edu Wed Jul 13 01:47:26 1994 From: cagney@highland.oz.au (Andrew Cagney) To: tech-kern@sun-lamp.cs.berkeley.edu Subject: How many programs are a.out specific? Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu Hello, How many programs in NetBSD are a.out specific? There are the obivious ones like the gcc-as-ld-nm-gdb-ar how many others are there? And how dependant is the kernel on this? Andrew From owner-tech-kern@sun-lamp.cs.berkeley.edu Wed Jul 13 02:09:51 1994 To: cagney@highland.oz.au (Andrew Cagney) Cc: tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: How many programs are a.out specific? <9407121454.AA10386@highland.oz.au> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu > How many programs in NetBSD are a.out specific? > > There are the obivious ones like the gcc-as-ld-nm-gdb-ar how many > others are there? unknown... (at least to me.) I think the shared library support has a fair bit of a.out specific stuff, but you might consider it 'part of ld'... > And how dependant is the kernel on this? most of the boot blocks boot kernels that are in a.out format. Other than that, it's pretty easy to write an exec module to do the right thing -- ones have been written for a.out, shell scripts, coff, elf, etc. chris From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 02:33:38 1994 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Special Circumstances From: John Shardlow To: osymh@gemini.oscs.montana.edu Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installing NetBSD from scratch Sender: owner-amiga@sun-lamp.cs.berkeley.edu > The root partition is always going to be /dev/sd?a. I don't think > NetBSD will run with the root partition elsewhere. > > > Anyway, I think it is too late for me to repair the damage as I am > > now in a chicken and egg situation ! > > You should be OK, if you set the root partition to NBR\7, it will be > configured as /dev/sd6a and you should be able to boot up single user. > You should then be able to mount the root writable and create the sd?i > -> sd?p devices manually. I thought I was OK too but when I try to mount -u /dev/sd5a / to create the device nodes I get: /dev/sd5a on /: Specified device does not match mounted device This is part of the single user bootup: warning found rdb->secpercyl(1098) != rdb->nsectors(74) * rdb->nheads(15) warning lp->d_sparespercyl(12) not multiple of lp->d_ntracks(15) 2 mice configured 10 views configured # # df Filesystem 512-blocks Used Avail Capacity Mounted on root_device 21904 12932 6780 66% / # mount -u / /dev/sd5a on /: Specified device does not match mounted device # mount /tmp mfs: /dev/sd5b: Device not configured Any other ideas ? If not then how about an answer to my original question: Whats the current best method of re-installing from scratch ? Thanks, John +----------------------------------+--------------------------+ ! John Shardlow | "I seem to be having ! ! john@iceberg.demon.co.uk | tremendous difficulty ! ! jshardlow@london.micrognosis.com | with my lifestyle" ! ! | - Arthur Dent ! +----------------------------------+--------------------------+ -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.1 mQCNAi3utxYAAAEEAK7VSevj5fswEy8Ooz7BoMgR5AwOUUrR5yWZvCiE7dB7ds/K Y7zMDvU7qDpInWeJouMJkP5G3zD6x+3Uv4s62RmDOBskled4UZbsLYwOtQn2aZxA 6tNDPy7NnuJDJdnuwJnncmJASED8ttz6G9y01tYUe/JCbhhh/ujrAAF+E35dAAUR tCtKb2huIEouIFNoYXJkbG93IDxqb2huQGljZWJlcmcuZGVtb24uY28udWs+ =Qz1o -----END PGP PUBLIC KEY BLOCK----- From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 04:15:55 1994 From: Olaf Seibert To: current-users@sun-lamp.cs.berkeley.edu, mycroft@gnu.ai.mit.edu, rhialto@mbfys.kun.nl Subject: Re: The list of floppy devices and a suggestion... Sender: owner-current-users@sun-lamp.cs.berkeley.edu > BTW, I should add that I'm all for someone else going off and doing it. > I just can't justify spending any time on it at the moment. Ok, that's fair, and on different architectures it will require different effort. As you said, on the Amiga it will be easier than on a pclone. However, the device level interface should allow odd disk formats as an option, so that if it is supported it will be supported in some standard way. -Olaf. -- ___ Olaf 'Rhialto' Seibert rhialto@mbfys.kun.nl Ooey-Gooey-Fluffy-Barfie \X/ I'm not weird, I'm differently percepted. D787B44DFC896063 4CBB95A5BD1DAA96 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 04:35:50 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: cgd@alpha.bostic.com Cc: barrett@daisy.ee.und.ac.za, current-users@sun-lamp.cs.berkeley.edu Subject: ENOTTY vs. EOPNOTSUPP vs. ENXIO Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Date: Tue, 12 Jul 1994 15:35:31 -0400 > From: "Chris G. Demetriou" > Actually, it's a bit unclear what the appropriate behaviour is... Agreed. P1003.1 describes the error codes, but a much more useful presentation of "what error code should I use for this" is given in the recommendation 1003.1 N327 by Paul Rabin (3/16/93). Relevant parts: (sorry, I only have it on paper) ENOTSUP "Not supported" Use [it] to indicate that the requested operation, though supported in general, is not supported by teh implementation for the requested object or the requested argument. ENOSYS "Function not implemented" Use [it] to indicate that the requested operation is not supported by the implementation for any object or argument. ENOTTY "Inappropriate I/O control operation" Use [it] to indicate that an attempt was made to apply an operation that is meaningful only on tty devices to an object that is not a tty device. ENXIO "No such device or address" Use [it] to indicate taht a referenced hardware device does not exist or is unavailable, or that the request is out of range for the device. Based on these recommendations, I would suggest that the vnode "disk" driver should return ENOTSUP for the DIOC* ioctls, because the ioctls indeed are sometimes supported, just not for this object. Gordon W. Ross Internet: Mercury Computer Systems Voice mail: 508-256-0052x295 199 Riverneck Road Front desk: 508-256-1300 Chelmsford, MA 01824-2820 Facsimile: 508-256-3599 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 04:54:17 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: ep0 woes with 3c579 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: 1177 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am *trying* to get a 3c579 working in a Dell EISA machine. It's a Dell 466SE if that makes any difference. My kernel config has: device ep0 at isa? port ? irq ? My bootup probe looks like: ep0 at isa0 port 0x6000-0x600f irq 10: aui/utp address 00:20:af:0b:e0:e9 I am using the AUI port, so a ifconfig ep0 link0 -link1 should set the correct port right? (per the 'man ep') Basically the problem is that any attempt to use the ep0 results in a 'unable to send' or similar. i.e. ping looks like this: ghost# ping 158.52.19.1 PING 158.52.19.1 (158.52.19.1): 56 data bytes ping: sendto: Host is down ping: wrote 158.52.19.1 64 chars, ret=-1 ...repeats... The host *isn't* down, and the 3c579 works fine from DOS. Ifconfig says: ghost# ifconfig ep0 ep0: flags=9863(UP,BROADCAST,NOTRAILERS,RUNNING,SIMPLEX,LINK0,MULTICAST) inet 158.52.19.7 netmask 0xffffff00 broadcast 158.52.19.255 I have the very latest code, as of right now, and have everything recompiled. If anyone has any brilliant ideas, please e-mail me! I've been trying to get this 3c579 to work for several weeks, and end up switching back to the old faithful 8-bit WD8003... :-( Thanks! -Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 05:57:28 1994 Subject: getting ld to issue link-time warnings 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: 1055 Sender: owner-current-users@sun-lamp.cs.berkeley.edu A while ago there was a comment that ld should issue a warning when gets() is linked in instead of using a run-time warning. I think setreuid() is that category too. How do I get ld to do this? I would like to flag a few calls like this (e.g, bcopy, bzero, index, rindex) that aren't really ANSI (or whatever) standard, and hack the code to use the appropriate memmove,memset,strchr,strrchr instead. It's easier to find stuff with link time warnings in other situations. (I want to make the code more portable to other systems) PS: I think the man page for memcpy() induces Bad Karma by recommending that people code with bcopy() instead, since it's not compatible. bcopy() should be implemented with memmove, and memcpy should probably be implemented as non-overlapping, so people get what the ANSI standard asks for :) -- ``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-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 06:10:15 1994 Sender: owner-amiga@sun-lamp.cs.berkeley.edu id m0qNuUu-0001eJC; Tue, 12 Jul 94 21:56 CDT Message-Id: From: spcmilo@hydra.spc.uchicago.edu (David Champion) Subject: X install FAQ? To: amiga@sun-lamp.cs.berkeley.edu Date: Tue, 12 Jul 1994 21:56:36 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 902 Status: RO Is there a guide to installing X under NetBSD? I thought I saw one once, but I've lost it. (Trying to use the 19Jun X binaries and libs, with xxMay fonts. I assumed that Xamiga+retina included ite support if no retina was detected, but in the chance that this was false, I also tried using theold XamigaMono server. EIther way, I get an X crosshatch and pointer, then my disk starts thrashing endlessly until I salute the beast anywhere up to half an hour later - should be time enough for an X server to complete on any 6502 machine. My .xinitrc (and lib/X11/xinit/xinitrc) do: xterm & twm for what that matters. It shouldn't, though, unless xinit is endlessly looking for something to launch. Am I missing some setup item? Links in /usr/bin/X11 and /usr/lib/X11 have been made. Same results with either some mid-June kernel/binary set or the 10Jul set.) Any pointers or help appreciated. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 06:50:20 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Motif on NetBSD - Do you want it? From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu Xinside (Thomas Roell and friends) is poised to begin distribution of their very fast Accelerated-X server with Motif development environment and window manager for the BSDI operating system. I also hear rumour that they anticipate a Linux version. Who on this list would be willing to pay $200.00 to have the same for NetBSD? Disclaimer - I am not connected with Xinside other than I plan to be Beta-testing their BSDI release RSN. I would like to have the same for my home machine. I will report my count to Xinside... -- Randy Terbush INET: randy%sierra%dsndata@sparky.sterling.com UUCP: sierra!randy From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 10:53:22 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: getting ld to issue link-time warnings 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: 1023 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > A while ago there was a comment that ld should issue a warning when > gets() is linked in instead of using a run-time warning. I think > setreuid() is that category too. > > How do I get ld to do this? You use inline assembly to insert a .stabs directive in the object file. I've been playing with the feature by adding the following macro to : /* * The __warn_symbol macro is used to instruct the linker to print * warning message "msg" if symbol "sym" is referenced. */ #ifdef __STDC__ #define __warn_symbol(sym,msg) \ __asm__(".stabs \"" msg "\",30,0,0,0\n.stabs \"_" #sym "\",1,0,0,0") #else #define __warn_symbol(sym,msg) \ __asm__(".stabs msg,30,0,0,0\n.stabs \"_/**/sym\",1,0,0,0") #endif The link time warnings work fine as long as the object files aren't incrementaly linked as our library files are. The "ld -r -x" in the standard make rules seems to strip out the stabs. I haven't figured out how to keep them perform the incremental link at the same time. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 11:09:16 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: st12400n disktab Sender: owner-current-users@sun-lamp.cs.berkeley.edu does anyone out there have a disktab for seagate st12400n drives? we have a few of them and been having a lot of fun getting them to run with anything other than dos, which is pretty disgusting... there is dispute b/w what the manual says and what netbsd (and for that matter nextstep) say for the parameters. netbsd and nextstep agree, but give larger numbers. neither set of numbers works, but a smaller tracks per sector does. its all very weird and makes me nervous putting any data on the drive didnt there used to be a disktab archive from the 386bsd era? where did it go to? -bri From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 12:15:36 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Anyone want a native Mosaic binary? 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 just compiled Mosaic 2.4 under NetBSD-current as of about two weeks ago; anyone interested in the binary? I have a fully static version and a "semi-static" version (only has the Motif library linked in statically). If someone can name a place I can stuff it for anonymous ftp, that would be cool as well. If you want some extra stuff compiled into your Mosaic binary, like SOCKS support for example, give me a holler; I'll see what I can do. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 12:22:59 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@alpha.bostic.com X-Notice: Do not redistribute in any form without prior explicit consent of the author. Subject: new i386 binary snapshot... From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu i've put a new binary snapshot for the i386 up for FTP. it's of the sources that are in the NetBSD 1.0 release branch, so please do try it out... chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 12:58:20 1994 Subject: From: jorngi@fo20.fo.mil.no Default-Recipient-Options: report nonreceipt, no reply, return content To: amiga-dev@sun-lamp.cs.berkeley.edu Sensitivity: personal Importance: normal Priority: non-urgent Delivery-Options: allow alternate recipients, return content, allow conversion, mask P1 recipients Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Sorry if this is a FAQ (but I haven't read anything about it before): Is there support for the A4091 board in NetBSD? If not, would it be possible to use: NCR 53c810 PCI SCSI driver for FreeBSD (just released) as a foundation to write a driver? The A4091 has an NCR 53c610 on it. Jorn From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 13:11:54 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "X install FAQ?" (Jul 12, 9:56pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: spcmilo@hydra.spc.uchicago.edu (David Champion), amiga@sun-lamp.cs.berkeley.edu Subject: Re: X install FAQ? Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 12, 9:56pm, David Champion wrote: > Subject: X install FAQ? > Is there a guide to installing X under NetBSD? I thought I saw one > once, but I've lost it. There is a FAQ for X, it does indeed cover the installation and the upcoming FAQs for that purpose. > for what that matters. It shouldn't, though, unless xinit is > endlessly looking for something to launch. Am I missing some setup > item? Links in /usr/bin/X11 and /usr/lib/X11 have been made. Same > results with either some mid-June kernel/binary set or the 10Jul set.) Maybe the kernel is in a dead-end, dunno. Had no time to check the new X11R5 yet. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 14:27:52 1994 To: gillham@andrews.edu (Andrew Gillham) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: ep0 woes with 3c579 <9407130024.AA14251@edmund> From: "Simon J. Gerraty" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > My bootup probe looks like: > ep0 at isa0 port 0x6000-0x600f irq 10: aui/utp address 00:20:af:0b:e0:e9 > > I am using the AUI port, so a ifconfig ep0 link0 -link1 should > set the correct port right? (per the 'man ep') > > Basically the problem is that any attempt to use the ep0 results > in a 'unable to send' or similar. i.e. ping looks like this: This looks a _lot_ like the problem I had with ep0 and a 3c509 card on a 386 at work. The machine sat there for ages, until I scrounged an SMC card and switched to ed0 - as I've been using if_ed here for about a year without problems. It didn't work!!! After checking the jumpers on the card and trying a few different kernels, I _eventually_ had the bright idea of looking at the CMOS setup... sure enough it had all sorts of shadow ram enabled. I disabled everything along those lines and hey, ed0 fired up ok. I now believe though I have not yet tested it, that if_ep would have worked fine... Just today I installed a kernel with the bsdi ipfirewall code added in, it works fine, so I might try putting the 3c509 back into it, and see if I can get it to work. Anyway, have a look at your cmos setup. --sjg From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 14:35:43 1994 From: Robert Shady Subject: Re: Anyone want a native Mosaic binary? To: kenh@wrl.epi.com (Ken Hornstein) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 689 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just compiled Mosaic 2.4 under NetBSD-current as of about two weeks ago; > anyone interested in the binary? I have a fully static version and a > "semi-static" version (only has the Motif library linked in statically). If > someone can name a place I can stuff it for anonymous ftp, that would be cool > as well. > > If you want some extra stuff compiled into your Mosaic binary, like SOCKS > support for example, give me a holler; I'll see what I can do. I'd definately be interested in grabbing a copy of this. If it's not too big, you could whip it over to my site, or just let me know where you put it. I'm on a 14.4k SLIP connection to the net. ftp.id.net is the address. From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 14:44:02 1994 Sender: owner-amiga@sun-lamp.cs.berkeley.edu id m0qO2bp-0001eJC; Wed, 13 Jul 94 06:36 CDT Message-Id: From: spcmilo@hydra.spc.uchicago.edu (David Champion) Subject: Keeping time To: amiga@sun-lamp.cs.berkeley.edu Date: Wed, 13 Jul 1994 06:36:16 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1542 Status: RO Not knowing of any such utility already existing, I came up with this braindead rexx program to reset system time under ADOS to local so that I can keep the battmem time in GMT for BSD's sake. (Well, I like keeping GMT.) I call it from s:User-Startup, right after loading rexxmast: sys:rexxc/rx rexx:warpdate.rexx Obviously, there's much room for improvement, but it does the job well enough. Even without going into detail, it should probably take the GMT offset on the command line, and my offset should probably be negative, not positive. Oh well. Anyway, thought someone might want it. /* warpdate.rexx */ /* adjust current time so battclock can keep GMT */ /* CONFIGURE HERE */ /* number of minutes short of GMT */ off = 300 /* STOP CONFIGURING */ /* do not change day by default */ changeday = '' /* find minutes after midnight */ mins = time('m') /* adjust minutes */ mins = mins - off /* if we go back a day, adjust minutes and changeday flag */ if mins < 0 then do mins = 1440 + mins changeday = 'yesterday' end /* if we go ahead a day, adjust minutes and changeday flag */ if mins > 1439 then do mins = 1440 - mins changeday = 'tomorrow' end /* extract new hour from minutes; set minutes to minutes since hour */ hour = trunc(mins / 60) mins = mins - (hour * 60) /* update seconds */ tmp = time('m') secs = time('s') secs = secs - (tmp * 60) /* create an amigados 'date' command */ datestr = 'date 'changeday' 'hour':'mins':'secs /* and change the clock */ address command datestr From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 14:54:25 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/etc/etc.amiga/MAKEDEV U src/etc/etc.mac68k/disktab U src/etc/etc.sun3/MAKEDEV U src/etc/etc.sun3/ttys U src/gnu/usr.bin/gcc2/common/cse.c U src/gnu/usr.bin/gcc2/common/expr.c U src/gnu/usr.bin/gcc2/common/function.c U src/gnu/usr.bin/gcc2/common/local-alloc.c U src/gnu/usr.bin/rcs/lib/conf.h U src/libexec/rpc.rusersd/rusersd.c Running the SUP scanner: SUP Scan for current starting at Wed Jul 13 03:30:35 1994 SUP Scan for current completed at Wed Jul 13 03:33:18 1994 SUP Scan for mirror starting at Wed Jul 13 03:33:18 1994 SUP Scan for mirror completed at Wed Jul 13 03:36:01 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 17:05:24 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Top V3.3 To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) 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: 1779 Sender: owner-amiga@sun-lamp.cs.berkeley.edu A few days ago someone posted asking why top wouldn't compile. I've got a patch that will allow you to compile top. It runs, but there is a segmentation fault that occurs when you quit. System: NetBSD reality 0.9C NetBSD 0.9C (GENERIC) #9: Tue Jun 21 01:21:46 EDT 1994 chopps@burbclave.emich.edu:/usr/src/sys/arch/amiga/compile/GENERIC amiga Binaries are the one cut by chris. I created a file called m_netbsd.c in the machine sub-directory. diff m_netbsd.c m_bsd44.c 28c28 < #include --- > /* #include */ 45c45 < #define VMUNIX "/netbsd" --- > #define VMUNIX "/vmunix" 68c68 < /* #define weighted_cpu(pct, pp) (PP((pp), p_time) == 0 ? 0.0 : \ --- > #define weighted_cpu(pct, pp) (PP((pp), p_time) == 0 ? 0.0 : \ 70,71d69 < * Hack for the current time... */ < #define weighted_cpu(pct,pp) ( 0.0 ) 378c376 < (show_system || ((PP(pp, p_flag) & P_SYSTEM) == 0))) --- > (show_system || ((PP(pp, p_flag) & SSYS) == 0))) 429c427 < if ((PP(pp, p_flag) & P_INMEM) == 0) { --- > if ((PP(pp, p_flag) & SLOAD) == 0) { 458c456 < PP(pp, p_priority) - PZERO, --- > PP(pp, p_pri) - PZERO, 594c592 < if ((result = PP(p2, p_priority) - PP(p1, p_priority)) == 0) --- > if ((result = PP(p2, p_pri) - PP(p1, p_pri)) == 0) Output from gdb when top was run then quit: Program received signal SIGSEGV (11), Segmentation fault 0xa302 in __do_global_dtors () (gdb) bt #0 0xa302 in __do_global_dtors () #1 0x1c322 in exit () #2 0x374c in quit (status=0) at top.c:911 #3 0x3256 in main (argc=1, argv=0xdfffcd0) at top.c:656 Apparently, this function __do_global_dtors() is located in the libgcc.a. Does anyone have any clues as where to go further?? Thanks, Ron Roskens From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 17:13:49 1994 From: "Szigeti Szabolcs 4. mikro PinkPanther" Subject: fdesc panic To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 810 Sender: owner-current-users@sun-lamp.cs.berkeley.edu This is from a kernel around jul 7. It came to me when I ran mtree, and it looked into /dev/fd. Fdesc filesystem is mounted on /dev/fd. catfish:> cd /dev/fd catfish:> sync; sync catfish:> ls -l vm_fault(f86a9ff00,0,1,0)->1 kernel: page fault trap, code = 0 stopped at _fdesc_allocvp+0x1f: cmpl %ecx,0x18(%ebx) db> trace _fdesc_allocvp(1,3,f8639200,f7bff80) at _fdesc_allocvp+0x1f _fdesc_lookup(f7bffdbc,0,f7bffe74,f7bffe50,f7bfda0c) at _fdesc_lookup+0xc1 _lookup(f7bffe50,f7bfda0c,f86a9900,f7bfda08,0) at _lookup+0x24f _namei(f7bffe50,f7bfda0c,f86a9900,f7bfda08,2423c) at _namei+0x102 _lstat(f86a9900,f7bfff94,f7bfff8c) at _lstat+0x4a _syscall() at _syscall+0xfa --- syscall (number 190) --- db> This always happens, when ls -l /dev/fd or cd /dev/fd/fd. Machine is an AMD486DX2/66 with 8 Meg. szabolcs From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 17:14:48 1994 From: pdokas@pms988.pms.ford.com (Paul Dokas) Subject: Re: 4.4 manuals + CDROM from ORA To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2074 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Just FYI; I just got off of the phone with O'Reilly & Assoc. > apparently, all of the 4.4 manuals and the US-only CDROM are > now available. Sorry, the non-US CDROM is NOT ready yet, it'll > be a couple more weeks. Ok, sorry about the lack of details. Here's what the latest ORA.COM has to say about the books. BOOKS ----- 4.4BSD System Manager's Manual, 646 pages, ISBN 1-56592-080-5, $30 Man pages for system administration commands and files, plus papers on system administration. 4.4BSD User's Reference Manual, 898 pages, ISBN 1-56592-075-9, $30 The famous "man pages" for over 500 utilities. 4.4BSD User's Supplementary Documents, 686 pages, ISBN 1-56592-076-7, $30 Papers providing in-depth documentation of complex programs such as the shell, editors, and word processing utilites. 4.4BSD Programmer's Reference Manual, 868 pages, ISBN 1-56592-078-3, $30 Man pages for system calls, libraries, and file formats. 4.4BSD Programmer's Supplementary Documents, 606 pages, ISBN 1-56592-079-1, $30 The original Bell and BSD research papers providing in-depth documentation of the programming environment. 4.4BSD-Lite CD Companion, 64 pages (est.) plus CD-ROM disk, ISBN 1-56592-081-3, $40 This CD is a copy of the University of California, Berkeley's, 4.4BSD-Lite release, with additional documentation and enhancements. [lots more description removed] SETS ---- Volumes 1-5 only, ISBN 1-56592-077-5, $120 All five manuals. No CDROM. Volumes 1-5 plus CDROM, ISBN 1-56592-082-1, $150 All five manuals and the CDROM. For ordering in US/Canada, call 1(800)8898969. Local/Overseas, call 1(7078290515. For inquiries, call 1(800)9989938. Ordering is also available by FAX at 1(707)8290104, or via email at order@ora.com Their open weekdays 6am - 6pm PST. Hope that's enough detail ;-) Paul Dokas pdokas@pms988.pms.ford.com PS, I have nothing to do with O'Reilly & Assoc., I just buy books from them. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 17:16:45 1994 To: Luke Mewburn Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: getting ld to issue link-time warnings <199407130129.LAA04747@goanna.cs.rmit.oz.au> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > How do I get ld to do this? I would like to flag a few calls like this > (e.g, bcopy, bzero, index, rindex) that aren't really ANSI (or whatever) > standard, and hack the code to use the appropriate > memmove,memset,strchr,strrchr instead. It's easier to find stuff with > link time warnings in other situations. (I want to make the code more > portable to other systems) Well, in this case, the most obvious way to arrange it is to make use of the warnings that are already in ld, and to link against a library that only contains ansi functions (assuming one is already built, my NetBSD is at home). > PS: I think the man page for memcpy() induces Bad Karma by > recommending that people code with bcopy() instead, since it's not > compatible. Agreed; there is no reason for memcpy() to be less efficient than bcopy(), so it shouldn't recommend bcopy(). At most it should recommend memmove(). > bcopy() should be implemented with memmove, and memcpy > should probably be implemented as non-overlapping, so people get what > the ANSI standard asks for :) The Standard explicitly permits memcpy() of overlapping objects to screw up. It is memmove() that must handle overlapping objects correctly. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 17:19:48 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Top V3.3 To: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) 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: 1779 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu A few days ago someone posted asking why top wouldn't compile. I've got a patch that will allow you to compile top. It runs, but there is a segmentation fault that occurs when you quit. System: NetBSD reality 0.9C NetBSD 0.9C (GENERIC) #9: Tue Jun 21 01:21:46 EDT 1994 chopps@burbclave.emich.edu:/usr/src/sys/arch/amiga/compile/GENERIC amiga Binaries are the one cut by chris. I created a file called m_netbsd.c in the machine sub-directory. diff m_netbsd.c m_bsd44.c 28c28 < #include --- > /* #include */ 45c45 < #define VMUNIX "/netbsd" --- > #define VMUNIX "/vmunix" 68c68 < /* #define weighted_cpu(pct, pp) (PP((pp), p_time) == 0 ? 0.0 : \ --- > #define weighted_cpu(pct, pp) (PP((pp), p_time) == 0 ? 0.0 : \ 70,71d69 < * Hack for the current time... */ < #define weighted_cpu(pct,pp) ( 0.0 ) 378c376 < (show_system || ((PP(pp, p_flag) & P_SYSTEM) == 0))) --- > (show_system || ((PP(pp, p_flag) & SSYS) == 0))) 429c427 < if ((PP(pp, p_flag) & P_INMEM) == 0) { --- > if ((PP(pp, p_flag) & SLOAD) == 0) { 458c456 < PP(pp, p_priority) - PZERO, --- > PP(pp, p_pri) - PZERO, 594c592 < if ((result = PP(p2, p_priority) - PP(p1, p_priority)) == 0) --- > if ((result = PP(p2, p_pri) - PP(p1, p_pri)) == 0) Output from gdb when top was run then quit: Program received signal SIGSEGV (11), Segmentation fault 0xa302 in __do_global_dtors () (gdb) bt #0 0xa302 in __do_global_dtors () #1 0x1c322 in exit () #2 0x374c in quit (status=0) at top.c:911 #3 0x3256 in main (argc=1, argv=0xdfffcd0) at top.c:656 Apparently, this function __do_global_dtors() is located in the libgcc.a. Does anyone have any clues as where to go further?? Thanks, Ron Roskens From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 19:02:40 1994 From: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld) To: current-users@sun-lamp.cs.berkeley.edu Subject: SQOD: is -current 1.0 or post 1.0? Sender: owner-current-users@sun-lamp.cs.berkeley.edu (SQOD==stupid question of the day) Now that the 1.0 end-game work has moved off to a release branch, does the "sup" of NetBSD-current contain the mainline, post 1.0 code, or the 1.0 release branch? - Bill From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 19:39:52 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SQOD: is -current 1.0 or post 1.0? <199407131354.JAA00495@orchard.medford.ma.us> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > (SQOD==stupid question of the day) > > Now that the 1.0 end-game work has moved off to a release branch, does > the "sup" of NetBSD-current contain the mainline, post 1.0 code, or > the 1.0 release branch? > > - Bill The NetBSD-current sup is tied to the 1.0 release branch, and has been since July 8th. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 19:40:29 1994 From: sommerfeld@orchard.medford.ma.us (Bill Sommerfeld) To: current-users@sun-lamp.cs.berkeley.edu Subject: turd alert in -current source tree Sender: owner-current-users@sun-lamp.cs.berkeley.edu cvs/share/me/cvs.core exists and is more than 1.4MB (well, I'm sup'ing it now over a 14.4 link and there's still more of it coming..) Maybe the nightly sup update script should include a: "find ... -name '*.core' -print | xargs rm -f" to avoid manual intervention in this case.. - Bill From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 20:09:13 1994 To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... From: "Gary D. Duzan" Sender: owner-current-users@sun-lamp.cs.berkeley.edu In Message <9407130734.AA01498@alpha.bostic.com> , "Chris G. Demetriou" wrote: =>i've put a new binary snapshot for the i386 up for FTP. => =>it's of the sources that are in the NetBSD 1.0 release branch, so =>please do try it out... => Any idea when this will get to an FTP mirror so that I can actuall get a hold of it? Thanks. Gary D. Duzan Network Administrator Delaware State Hospital (Until July 15, when I leave for Mass.) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 20:09:23 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SQOD: is -current 1.0 or post 1.0? <199407131507.RAA00629@wipux2.wifo.uni-mannheim.de> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > The NetBSD-current sup is tied to the 1.0 release branch, and has been > > since July 8th. > So whats the new supfile entry ? > Cheerio > There isn't one. just use the 'current' one that you are using now. Once 1.0 is released, then 'current' will reflect non-release changes again. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 20:16:23 1994 From: rhealey@aggregate.com Subject: Watch out for lseek and stat struct st_size fields! 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: 550 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've been bit hard in the last two days due to the 64 bit size of files in NetBSD. Make sure you cast references to file size in lseek to off_t and to cast references to the st_size field of the stat structure to int. You'll also run in to problems with sys_errlist's declaration under NetBSD, usually its safe to just wrap it in #if !defined(__NetBSD__) in programs. FYI, -Rob p.s. The tex/dvi/xdvi tools from ftp.cs.umb.edu work wonderfully and texinfo 3.1 does too. tex had the lseek syndrome, texinfo gobs of st_size references. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 20:22:57 1994 Subject: Re: Pre-release binaries. To: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 435 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Chris Hopps writes: >I have just put a new snapshot on sun-lamp. This is a pre-release >snapshot it would be very nice if as many people as possible could >test them. Thank you for this new snapshot. iOnly two problems apears when I try it today: 1. Could you please put a kernel in the rootfs ? 2. Add a note that when there is no retina, then the ttye1 should be removed, or putting a # before in the /etc/ttys file. Bernd From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 20:51:37 1994 From: Brian Moore To: gary@dragon.dsh.org Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, if you are talking about the binaries in arch/i386 that were created 7/13/94, they've been up on ftp.eecs.umich.edu, in BSD/NetBSD/arch/i386 since about 7:15AM EST today. ---Brian From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 13 20:53:14 1994 From: Matthew Aldous Subject: About to install... To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL0] Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm about to install netbsd-amiga, and I want to make sure I'm doing the right thing... I have a 20 meg scsi, and 100 meg scsi, and a 540 about to arrive. division... Name --------------------------------------------- 8 meg of the 20 = amiga dos Work: 12 meg of the 20 = netbsd root NBR\7 10 meg of the 100 = netbsd swap NBS\7 90 meg of the 100 = netbsd user NBU\7 I've got the two floppy disks, but that's where the hassle is. The kernel image there is NTSC, and I'm a PAL machine. I have a Commodore 1930 VGA monitor, and a 2320 Flicker Fixer. When NTSC images come up, the screen just wobbles too much to read. Is there a PAL kernel around? Is there an amiga binpatch? What do I binpatch in the kernel, and where, to change screen modes, etc? Given my drive configuration, what should I download (serial) and in what order? ( I'm going to download under AmigaDOS to the 100, format the 20 around, install root there, make the 8 auto start NetBSD on the remaining 12. From there, parition the 100 meg about, and then add the 540 later. ) Does this seem sensible? Also, there are kernel images on ftp.uni-regensburg.de called "vmunix" and "netbsd" , what's happening here? (The top level README is a little wacko as well) (I've gathered from the short time I've been on this list, there's no current README-INSTALL - is this right?) Thanks in advance. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 20:56:21 1994 Subject: Re: Pre-release binaries. To: chopps@emunix.emich.edu Cc: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 279 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >> 1. Could you please put a kernel in the rootfs ? > >Which one? I am leaving them off becuase it just increases I do that after I get some error when there is no kernel in / Do you compille this kernel with the AGA modes ? I can not boot this kernel in an AGA mode. Bernd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 20:56:41 1994 From: chopps@emunix.emich.edu To: erbe0011@fh-karlsruhe.de (Bernd Ernesti) Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Pre-release binaries. X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > 1. Could you please put a kernel in the rootfs ? Which one? I am leaving them off becuase it just increases the size. You already grabbed the kenrel, just copy it there yourself. (mount_ados) > 2. Add a note that when there is no retina, then the ttye1 should > be removed, or putting a # before in the /etc/ttys file. Someone doing docs should note this. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 21:01:03 1994 To: "Gary D. Duzan" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >In Message <9407130734.AA01498@alpha.bostic.com> , > "Chris G. Demetriou" wrote: >=>i've put a new binary snapshot for the i386 up for FTP. >=> >=>it's of the sources that are in the NetBSD 1.0 release branch, so >=>please do try it out... >=> > Any idea when this will get to an FTP mirror so that I can >actuall get a hold of it? Thanks. If nothing crashes or breaks, ftp.iastate.edu should pick it up just after noon CDT today. --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 Jul 13 21:01:11 1994 From: Tim Chase Subject: The pppd blocking thing... softcar works. 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: 657 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, Regarding my recent comments that the pppd program ought to open the port with a nonblocking open, I was pointed to the softcar feature of /etc/ttys. I had tried that in the past and it didn't work, but I discovered that I had a typo in the file. I had been using a flag "crtscts" which appears to really be "rtscts". Following that flag, I had the "softcar". It seems that flags following an error are ignored. I fixed it and setting the softcar flag from /etc/ttys works just fine and is obviously the proper solution to using pppd, tip or whatever for outgoing calls (if the program in question doesn't use a nonblocking open). - Tim From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 21:05:29 1994 X-Face: $~>2-+Ez55@B0~l{%2@BA5y&-1*6%[r o+\a[g#~JPkHluj=4vVJ2emqJ(d%/<"y-hob6tY'oR~+2>(jjy15lY+9hnkrujb Sender: owner-current-users@sun-lamp.cs.berkeley.edu SUP 8.26 (4.3 BSD) for file supfile at Jul 13 12:36:24 SUP Upgrade of current-allsrc at Wed Jul 13 12:36:25 1994 SUP Fileserver 7.13 (4.3 BSD) 10546 on sun-lamp.cs.berkeley.edu at 12:36:25 SUP Requesting changes since Jul 12 06:36:27 1994 [...] SUP Receiving file src/share/me/cvs.core I presume that this is a core dump of some form form the looks of it... - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 21:11:39 1994 From: Patrick Rougeau To: current-users@sun-lamp.cs.berkeley.edu Subject: pentium pci box and ethernet Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am just trying a pentium PCI box with Netbsd(a3months old current version) and am getting into trouble with some ethernet cards. with the wd8003e compatible cards the kernel complains that it cannot clear the share memory same message with the 3com 3c503 the 3c509 goes further but the ifconfig produdes some stray interrupt number 10 the ne2000 cards just work fine as it is the first pci card i am using , does i miss a point with it ? has anybody experienced the same behavior(and got the workarounds) \thank you for your help Patrick From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 13 21:23:12 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, rougeau@ensta.fr Subject: Re: pentium pci box and ethernet Sender: owner-current-users@sun-lamp.cs.berkeley.edu It sounds like you haven't bothered to configure the IRQs and/or shared memory addresses so that the cards and the kernel match. You can't just plug in a card and expect it to work; at least not ISA cards. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 23:34:49 1994 From: chopps@emunix.emich.edu To: mw@eunet.ch Cc: rhealey@aggregate.com, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Watch out for lseek and stat struct st_size fields! <199407131923.VAA01816@eunet.ch> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > I've been bit hard in the last two days due to the 64 bit size of files > > in NetBSD. Make sure you cast references to file size in lseek > > to off_t and to cast references to the st_size field of the stat > > structure to int. You'll also run in to problems with sys_errlist's > > *soap box on* > _GRIN_ So, how many people had benefits so far from having a 64bit off_t OS, > and how many suffer from the mess it caused? > *soap box off* lseek is prototyped in unistd.h if programs break rules.. well.. > Sorry, couldn't resist:-) BTW, what would happen if I'd compile -current with > THAT typedef in reset to long? Its really just not that important. Is your personal system tracking current? Whats important is that NetBSD is *visibally* faster than it used to be. 040's don't flush caches ever (excepting dma selective cache pushes, and shared libs), pmaps flush the ATC much more selectively now, users have 15/13 partitions they can use. CD, tape and scsi direct support are simple and straightforward, et al. Chris. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 23:37:13 1994 From: mw@eunet.ch Subject: Re: Watch out for lseek and stat struct st_size fields! To: rhealey@aggregate.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1236 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > I've been bit hard in the last two days due to the 64 bit size of files > in NetBSD. Make sure you cast references to file size in lseek > to off_t and to cast references to the st_size field of the stat > structure to int. You'll also run in to problems with sys_errlist's *soap box on* _GRIN_ So, how many people had benefits so far from having a 64bit off_t OS, and how many suffer from the mess it caused? *soap box off* Sorry, couldn't resist:-) BTW, what would happen if I'd compile -current with THAT typedef in reset to long? Could you do "#if sizeof(off_t) == sizeof(long)" ? Else we could get the same result by using something like __QUAD_OFF_T__ along with the typedef, and change the very few structs that contain off_t (just remember stat) to include padding like in old times (:-)) iff __QUAD_OFF_T__ is not defined? I just can hardly believe that it would be such an impossible task to have a kernel that can be both compilable for 32 and 64 bit... Well, enough whining again for a while :-) Ciao, -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 13 23:51:28 1994 From: rhealey@aggregate.com Subject: Re: Watch out for lseek and stat struct st_size fields! To: chopps@emunix.emich.edu 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: 1286 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > *soap box on* > > _GRIN_ So, how many people had benefits so far from having a 64bit off_t OS, > > and how many suffer from the mess it caused? > > *soap box off* > > lseek is prototyped in unistd.h if programs break rules.. well.. > Agreed. > > Sorry, couldn't resist:-) BTW, what would happen if I'd compile -current with > > THAT typedef in reset to long? > > Its really just not that important. Is your personal system tracking > current? Whats important is that NetBSD is *visibally* faster than > it used to be. 040's don't flush caches ever (excepting dma selective > cache pushes, and shared libs), pmaps flush the ATC much more selectively > now, users have 15/13 partitions they can use. CD, tape and scsi direct > support are simple and straightforward, et al. > Not to mention NetBSD is now basically BSD 4.4; the UNIX(tm) sandbox of the 90's. We will soon be seeing monster files due to multimedia apps, huge drives > 4G and mainstream CPU's with fundemental integer size of 64 bits. Alpha is there today, MIPS, SPARC, Power, HP and others are sure to follow soon. BSD 4.4 was a little ahead of the curve by going to 64 bit but not by much. That some apps cut corners is no reason to knock the forsight of the BSD designers. -Rob From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 14 00:13:49 1994 From: rhealey@aggregate.com Subject: Re: Watch out for lseek and stat struct st_size fields! 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: 1849 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > *soap box on* > _GRIN_ So, how many people had benefits so far from having a 64bit off_t OS, > and how many suffer from the mess it caused? > *soap box off* > My soapbox response: I've lived through: All the worlds an 8 bit Z80 All the worlds a 16 8086 All the world's a VAX All the world's a Sun 3 All the workd's a SPARC All the world's a 32 bit machine with ints and pointers of the same size... And now all the world uses 32 bit filesystem with int == pointer and NOBODY will ever need to use 64 bit quantitys... That current coding practices of PD/Freely redistributable programs are poor isn't a reason to know the PROPER decision was to move to 64 bits NOW in 4.4 BSD. We'll be ahead of the others who will benifit from our finding their sloppy code. I went through this using SVR4 from '90 to present. Interestingly enough, it was PD and GNU code that caused the most headaches for SVR4, ANSI C and POSIX functionality. X programs came in a close 2nd. People blamed it on SVR4 being "braindead". Well now those same sorts of programs are hurling on BSD 4.4, NOT just NetBSD by the way, and so what do way say now? That BSD 4.4 is braindead? I prefer to blame the proper partys: The sloppy programmers who assumed all the world's a 32 bit int and that filesystems will always be limited to 32 bit sized files, or even UNIX type filesystems... In the next year MIPS, SPARC, Power and probably even Intel will start going 64 bit. Alpha is already there. It was a GOOD decision to change to 64 bits, and boost the other fields to 32 and 16. So far X11R5, tex and texinfo are the only applications I've been bitten hard on. The exact same ones that bit me hard when I first started dealing with SVR4 in '90.... My how some things change over the years... End smart ass/soapbox reply mode. -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 00:20:01 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Marc@synergytics.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: This files doesn't belong in the sup area (IMHO) <199407131647.MAA18983@Synergytics.Com> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu fixed. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 00:28:03 1994 From: Christos Zoulas "thanks for help on ep0 problems." (Jul 13, 2:21pm) 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: gillham@andrews.edu (Andrew Gillham), current-users@sun-lamp.cs.berkeley.edu Subject: Re: thanks for help on ep0 problems. Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 13, 2:21pm, gillham@andrews.edu (Andrew Gillham) wrote: -- Subject: thanks for help on ep0 problems. | | Thanks for the help with the ep0 problems I was having! | Several people suggested I needed a default route, but as I had | pulled a wd8003e and put in the 3c579 (changing hostname.ed0 to ep0) | Also, my CMOS settings were mentioned. As I eventually got it working | on UTP, they must be ok. Funny thing is though, I have 24MB, boot | recognizes 24MB, but the kernel only sees 16MB... and it reads it from | the CMOS.. hmm... Maybe I'll zap the CMOS and EISA NVRAM and start over. | Anyway, to shorten a short story... I finally checked in 'if_ep.c' | and the man page for ep was wrong as far as the 'link0 link1' stuff. | I *still* can't get the AUI port to work, but the UTP port works | fine with 'link0 link1'. | | Anyway, thanks for the help! I'll live with the UTP port! | Yes the man page is incorrect. The aui port will work with I need to look at the source to make a final decision on that, but I've experimented with aui and utp and I know that the following combinations work: link0 -link1 = aui link0 link1 = utp christos From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 00:31:36 1994 To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu, port-sparc@sun-lamp.cs.berkeley.edu Subject: Re: -current kernel on a SPARC <199407132036.QAA08222@Collatz.McRCIM.McGill.EDU> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > ../../../../arch/sparc/sparc/pmap.c: In function `PMPID': > ../../../../arch/sparc/sparc/pmap.c:781: warning: assignment discards `volatile' from pointer target type This has been fixed. In ANY CASE, it is simply a warning and doesn't matter in the least. > echo 'building rem.S from divrem.m4' > building rem.S from divrem.m4 > (echo "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')"; cat divrem.m4) | m4 > rem.S > cat: divrem.m4: No such file or directory You needed to reinstall /usr/share/mk before building your kernel. > and this time I got a kernel. It appears to work fine, except that > it's not compatible with a few user-level programs like route(8); I'm No kidding. Your userland must be quite old. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 00:36:10 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu, port-sparc@sun-lamp.cs.berkeley.edu Subject: -current kernel on a SPARC Sender: owner-current-users@sun-lamp.cs.berkeley.edu I took a freshly supped source tree (as of last night) and tried to build a SPARC kernel. The user level I'm working from is somewhat old; it corresponds to the binary snapshot before the most recent one. Starting with the freshly supped source tree, I rebuilt config.new (well, first I did a false start that ended with ufs_mountroot undefined, and I discovered that config.new was the reason, so I carefully threw it away and started over with a config.new from the same sup run as the kernel source I was using). Then I did cd /sys/arch/sparc/conf config.new TDR2 cd ../compile/TDR2 ( std ; make depend && make -k ) where "std" is an alias that removes all the customizations from my path and environment. The output is of course large (the file is 105067 bytes), but the relevant portions are fairly small: .... cc -c -I. -I../../../../arch -I../../../.. -I../../../../sys -DSUN4C -DTIMEZONE="0x1e0" -DDST="1" -DSWAPPAGER -DVNODEPAGER -DDEVPAGER -DKTRACE -DGDB -DKGDBDEV="0xc01" -DKGDBRATE="0x9600" -DRCONSOLE -DSYSVMSG -DSYSVSEM -DCOMPAT_09 -DFFS -DNFSSERVER -DNFSCLIENT -DINET -DTCP_COMPAT_42 -DCOMPAT_43 -DLKM -DCOMPAT_SUNOS -DKERNEL -DMAXUSERS=8 ../../../../arch/sparc/sparc/pmap.c ../../../../arch/sparc/sparc/pmap.c: In function `PMPID': ../../../../arch/sparc/sparc/pmap.c:781: warning: assignment discards `volatile' from pointer target type .... making sure the kern library is up to date... .... echo 'building rem.S from divrem.m4' building rem.S from divrem.m4 (echo "define(NAME,\`.rem')define(OP,\`rem')define(S,\`true')"; cat divrem.m4) | m4 > rem.S cat: divrem.m4: No such file or directory chmod 444 rem.S cpp -E -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc rem.S | as -o rem.o ld: bad string table size in rem.o *** Error code 1 (continuing) echo 'building sdiv.S from divrem.m4' building sdiv.S from divrem.m4 (echo "define(NAME,\`.div')define(OP,\`div')define(S,\`true')"; cat divrem.m4) | m4 > sdiv.S cat: divrem.m4: No such file or directory chmod 444 sdiv.S cpp -E -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc sdiv.S | as -o sdiv.o ld: bad string table size in sdiv.o building udiv.S from divrem.m4 cat: divrem.m4: No such file or directory *** Error code 1 (continuing) cpp -E -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc udiv.S | as -o udiv.o ld: bad string table size in udiv.o building urem.S from divrem.m4 cat: divrem.m4: No such file or directory *** Error code 1 (continuing) cpp -E -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc urem.S | as -o urem.o ld: bad string table size in urem.o *** Error code 1 (continuing) .... cpp -E -DPROF -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc rem.S | as -o rem.po ld: bad string table size in rem.po *** Error code 1 (continuing) cpp -E -DPROF -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc sdiv.S | as -o sdiv.po ld: bad string table size in sdiv.po *** Error code 1 (continuing) cpp -E -DPROF -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc udiv.S | as -o udiv.po ld: bad string table size in udiv.po *** Error code 1 (continuing) cpp -E -DPROF -I/sources/working-usr-src/sys/lib/libkern -Imachine/.. -I. -I/sources/working-usr-src/sys/lib/libkern/../.. -I/sources/working-usr-src/sys/lib/libkern/arch/sparc -I/sources/working-usr-src/sys/lib/libkern/../../../lib/libc/arch/sparc urem.S | as -o urem.po ld: bad string table size in urem.po *** Error code 1 (continuing) .... cp mcount.o mcount.po `all' not remade because of errors. .... loading netbsd ld: No such file or directory for /sources/working-usr-src/sys/lib/libkern/libkern.a *** Error code 1 (continuing) `all' not remade because of errors. So I went poking around, and found divrem.m4 in sys/lib/libkern/arch/sparc. So I then did: cd /sys/lib/libkern ln -s arch/sparc/divrem.m4 . rm {rem,sdiv,urem,udiv}.{S,o,po} cd /sys/arch/sparc/compile/TDR2 make -k and this time I got a kernel. It appears to work fine, except that it's not compatible with a few user-level programs like route(8); I'm now doing a full make in /usr/src to get user-level binaries from the same source tree. I'll report on any problems I encounter. In the meantime, someone who knows the philosophy behind the make setup might want to figure out what lib/libkern should do about divrem.m4. It might also be good to fix arch/sparc/sparc/pmap.c so the compiler doesn't whine about volatile. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 00:55:17 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: thanks for help on ep0 problems. 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: 768 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Thanks for the help with the ep0 problems I was having! Several people suggested I needed a default route, but as I had pulled a wd8003e and put in the 3c579 (changing hostname.ed0 to ep0) Also, my CMOS settings were mentioned. As I eventually got it working on UTP, they must be ok. Funny thing is though, I have 24MB, boot recognizes 24MB, but the kernel only sees 16MB... and it reads it from the CMOS.. hmm... Maybe I'll zap the CMOS and EISA NVRAM and start over. Anyway, to shorten a short story... I finally checked in 'if_ep.c' and the man page for ep was wrong as far as the 'link0 link1' stuff. I *still* can't get the AUI port to work, but the UTP port works fine with 'link0 link1'. Anyway, thanks for the help! I'll live with the UTP port! -Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 01:35:09 1994 From: Herb Peyerl Subject: Re: thanks for help on ep0 problems. To: gillham@andrews.edu (Andrew Gillham) 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: 709 Sender: owner-current-users@sun-lamp.cs.berkeley.edu : Anyway, to shorten a short story... I finally checked in 'if_ep.c' : and the man page for ep was wrong as far as the 'link0 link1' stuff. : I *still* can't get the AUI port to work, but the UTP port works : fine with 'link0 link1'. Yeah; I know the manpage is wrong. I noticed that yesterday. In actual fact; the manpage was right at one time; but the code changed and the person who changed the code didn't change the manpage. And that person wasn't me incidentally. (HI THEO!) hpeyerl@novatel.ca | NovAtel Commnications Ltd. hpeyerl@fsa.ca | "A sucking chest wound is nature's way of telling you to slow down." From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 14 03:09:20 1994 From: "Scott B. Anderson" Subject: su wierdness To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 251 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I upgraded to the latest binary snapshot sunday night, and all the sudden today su stops working with a bus error. I compiled an equally new su, and it fails in a call to initgroup. Any ideas? If not, I move to the binaries from cgd tomorrow. Scott From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 14 04:08:36 1994 From: "Stephen J. Roznowski" To: aldous@mame.mu.OZ.AU, amiga@sun-lamp.cs.berkeley.edu Subject: Re: About to install... Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: Matthew Aldous > > I'm about to install netbsd-amiga, and I want to make > sure I'm doing the right thing... > > [ . . . ] > > Also, there are kernel images on ftp.uni-regensburg.de > called "vmunix" and "netbsd" , what's happening here? (The > top level README is a little wacko as well) (I've gathered > from the short time I've been on this list, there's no current > README-INSTALL - is this right?) The "old" kernels were called "vmunix", the new ones are called "netbsd". -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 00:52:43 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: tunefs Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu What are the optimum parameters to pass this to get our disks to not interrupt on every sector transferred (at least that's what I believe it's doing). I swear I have a bad ass 2.1G Barracuda that's acting like a big slow floppy (and I don't believe it's the driver). Then again.. maybe I've been spoiled by AmigaDOS ;-). -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 00:57:00 1994 To: mw@eunet.ch Cc: deraadt@fsa.ca (Theo de Raadt), rhealey@aggregate.com, chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Watch out for lseek and stat struct st_size fields! <199407150657.IAA14283@eunet.ch> From: Theo de Raadt Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > processors either) -- you can consider us too lazy to put in a > > backwards compatibility hack that requires a completely seperately > > compiled kernel and userland. > > > > Besides all the hoopla about how this change breaks everything, note > > that SunOS binaries still continue to run. > > Interesting.. if SunOS binaries can be made to run sooo easily, it should > be trivial to run and support 32bit NetBSD binaries, right?:-) 32bit off_t NetBSD binaries run TODAY. They never stopped working. They call the backwards-compat system calls provided. I think you are off base. I suspect that you are not running current, and as a result do not know any of the relevant facts. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 01:03:42 1994 To: mw@eunet.ch Cc: rhealey@aggregate.com, chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Watch out for lseek and stat struct st_size fields! <199407140733.JAA06237@eunet.ch> From: Theo de Raadt Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Sorry but I can't stop getting the > impression you two feel some sort of missionary "task" to convert the > whole uncivilized world to The Right Thing, in this case a truely > POSIX compatible, 64bit OS. Sorry, Markus, but I can't stop getting the impression that you feel some sort of missionary "task" to keep the whole civilized world in the dark ages. :-) This change is worthwhile, for the reasons stated, and also if you own a Seagate 9G disk. If you're too lazy to make sure that your code calls lseek() correct (and for PD code, send those fixes to the authors, because such code won't work on an alpha or other 64-bit processors either) -- you can consider us too lazy to put in a backwards compatibility hack that requires a completely seperately compiled kernel and userland. Besides all the hoopla about how this change breaks everything, note that SunOS binaries still continue to run. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 01:09:29 1994 From: mw@eunet.ch Subject: Re: Watch out for lseek and stat struct st_size fields! To: rhealey@aggregate.com Cc: chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 869 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Well Rob and Chris.. you both gave more or less convincing arguments why one might want to offer 64bit support in a BSD kernel (I don't consider just the fact that BSD4.4 has "it" to be a convincing argument though). What you did not answer at all was the question whether it would be a big deal to include the *option* of going for 32bit (no big deal in my eyes IMHO). I did *not* ask to remove 64bit capabilities from .*BSD.*, I was just asking to make it an *option*. Sorry but I can't stop getting the impression you two feel some sort of missionary "task" to convert the whole uncivilized world to The Right Thing, in this case a truely POSIX compatible, 64bit OS. -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 01:19:12 1994 From: mw@eunet.ch Subject: Re: Watch out for lseek and stat struct st_size fields! To: deraadt@fsa.ca (Theo de Raadt) Cc: mw@eunet.ch, rhealey@aggregate.com, chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 621 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > processors either) -- you can consider us too lazy to put in a > backwards compatibility hack that requires a completely seperately > compiled kernel and userland. > > Besides all the hoopla about how this change breaks everything, note > that SunOS binaries still continue to run. Interesting.. if SunOS binaries can be made to run sooo easily, it should be trivial to run and support 32bit NetBSD binaries, right?:-) -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 01:24:36 1994 From: Tim Chase Subject: hp300 rootimage on 9000-425 - does it work 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: 487 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, I recently tried the new hp300 rootimage on a 425. The monitor apparently found a system to boot (id of 1Z, I think) but after the next boot step the screen just went blank & the system appeared to be hung. Does anyone know if this rootimage and/or boot loader is known to work on a 425? I downloaded it from ftp.iastate.edu yesterday. Maybe I'll try re- writing the file system and try again in the mean time. Thanks for any tips, Tim Chase tim@introl.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 01:25:10 1994 From: Christos Zoulas "problem with recent make" (Jul 14, 2:03pm) 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: der Mouse Subject: Re: problem with recent make Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 14, 2:03pm, mouse@Collatz.McRCIM.McGill.EDU (der Mouse) wrote: -- Subject: problem with recent make | I pulled over the latest binary snapshots (for the SPARC, though I | suspect it doesn't matter) and replaced my previous binary system. | Upon rebooting, I discovered that all my old executables now printed | "No ld.so" and died; this puzzles me because the compiled-in path to | ld.so in the old binaries is /usr/libexec/ld.so (verified with | "strings - oldbinary | egrep ld.so"), which is the same as the path | found the same way in a new executable (and the same as the path in | -current src/lib/csu/sparc/crt0.c as of an evening or two ago) - though | /usr/libexec/ld.so does not exist, so I'm not sure what's going on. | But relinking cures it, so it's not important, just odd. | | More important is something make does. I have a Makefile that reads, | in part, | | abspath.prs.fsm.c: abspath.prs.fsm | fsm < abspath.prs.fsm > abspath.prs.fsm.c | abspath.cpt.fsm.c: abspath.cpt.fsm | fsm < abspath.cpt.fsm > abspath.cpt.fsm.c | | For the sake of brevity below, I will write "foo" to mean either | "abspath.prs.fsm" or "abspath.cpt.fsm", depending. Thus, we can think | of the Makefile as containing | | foo.c: foo | fsm < foo > foo.c | | On 4.3 (pre-Reno, pre-Tahoe - the old stuff), this worked fine; it | obeyed what I wrote, running "fsm < foo > foo.c" exactly when foo was | newer than foo.c. SunOS 3.5 make produced a cryptic message "$! | nulled, predecessor circle" and otherwise behaved the same. SunOS 4.x | make exhibits catastrophic misbehavior; it complains that either "foo | depends on itself" or "foo.c depends on itself" and then either | executes the command given or runs "cc foo.c -o foo", thereby | destroying the input file. (Successive runs alternate between the two | behaviors; I think the messages alternate too but I'm not sure.) | | The make binary in the previous SPARC snapshot worked fine; it did what | the Makefile says to do and didn't get upset. The current make says | "Graph cycles through foo.c" and treats this as a failure for the | targets that depend on those files. (Mercifully, it doesn't try to run | "cc -o foo foo.c", but it doesn't execute the specified command either, | and it treats it as a build error, which makes it hard to work around | it by carefully touching the appropriate files.) | | How can I teach make to do what I tell it to? Default rules are all | very well in the absence of explicit instructions to the contrary, but | when (as here) there _are_ explicit instructions, I maintain they | should be obeyed. I'm prepared to dive into make if I have to to fix | this, but since someone must have added something that caused this | relatively recently, it seems a bit silly for me to go looking de novo. | | der Mouse The make source code has not changed in that respect, but the ``shuttle'' rule from the .c to .NULL suffix was added in the default rules. I agree with you that explicit instructions should be obeyed, but even if we fix it to work in the NetBSD make, it will not work anywhere else. I don't think that it is very easy to fix either. christos From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 01:28:56 1994 From: mw@eunet.ch Subject: Re: Watch out for lseek and stat struct st_size fields! To: deraadt@fsa.ca (Theo de Raadt) Cc: mw@eunet.ch, deraadt@fsa.ca, rhealey@aggregate.com, chopps@emunix.emich.edu, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 779 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > Interesting.. if SunOS binaries can be made to run sooo easily, it should > > be trivial to run and support 32bit NetBSD binaries, right?:-) > > 32bit off_t NetBSD binaries run TODAY. They never stopped working. > They call the backwards-compat system calls provided. > > I think you are off base. I suspect that you are not running current, > and as a result do not know any of the relevant facts. Reread the above statement, I want to run AND SUPPORT them, I want to be able to compile/link sources and want 32bit behavior for them. You don't tell me this works, do you? -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 01:48:38 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- cgd Sat Jul 9 20:53:52 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/usr/src/etc/etc.amiga Revision/Branch: netbsd-1-0 Modified Files: Makefile.inc Log Message: move the correctly-named kernel. from chopps cgd Sat Jul 9 20:55:56 PDT 1994 Update of /b/source/CVS/src/usr.sbin/pppd In directory sun-lamp.cs.berkeley.edu:/usr/src/usr.sbin/pppd Revision/Branch: netbsd-1-0 Modified Files: options.c Log Message: don't core. from trunk. --------------------------------- chopps Sun Jul 10 16:00:31 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/amiga/dev Modified Files: Zeus.script Log Message: bring up to date with siop.c --------------------------------- cgd Sun Jul 10 16:51:13 PDT 1994 Update of /b/source/CVS/src/bin/expr In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/expr Modified Files: expr.y Log Message: don't forget a cast, and thereby fix the regexp problems on big-endian machines cgd Sun Jul 10 16:51:37 PDT 1994 Update of /b/source/CVS/src/bin/expr In directory sun-lamp.cs.berkeley.edu:/usr/src/bin/expr Revision/Branch: netbsd-1-0 Modified Files: expr.y Log Message: fix regexp problems. from trunk. cgd Sun Jul 10 16:53:01 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: Zeus.script Log Message: from trunk, at chopps request --------------------------------- chopps Mon Jul 11 07:12:44 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/etc/etc.amiga Modified Files: MAKEDEV Log Message: add extra special files for newly available partitions. --------------------------------- cgd Tue Jul 12 14:00:18 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/rcs/lib In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/rcs/lib Modified Files: conf.h Log Message: don't define exit() here. in fact, none of these should be here, but... cgd Tue Jul 12 14:00:22 PDT 1994 Update of /b/source/CVS/src/gnu/usr.bin/rcs/lib In directory sun-lamp.cs.berkeley.edu:/usr/src/gnu/usr.bin/rcs/lib Revision/Branch: netbsd-1-0 Modified Files: conf.h Log Message: update from trunk, for phil cgd Tue Jul 12 14:03:15 PDT 1994 Update of /users/srcmastr/CVS/src/sys/nfs In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/nfs Modified Files: nfs_bio.c Log Message: minor cache consistency fix cgd Tue Jul 12 14:04:17 PDT 1994 Update of /b/source/CVS/src/sys/nfs In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/nfs Revision/Branch: netbsd-1-0 Modified Files: nfs_bio.c Log Message: consistency fix, from trunk cgd Tue Jul 12 14:06:57 PDT 1994 Update of /b/source/CVS/src/sys/adosfs In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/adosfs Revision/Branch: netbsd-1-0 Modified Files: adosfs.h advfsops.c advnops.c Log Message: fixes from trunk, per chopps cgd Tue Jul 12 14:08:14 PDT 1994 Update of /b/source/CVS/src/etc/etc.amiga In directory sun-lamp.cs.berkeley.edu:/usr/src/etc/etc.amiga Revision/Branch: netbsd-1-0 Modified Files: MAKEDEV Log Message: more units! from trunk, per chopps. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 01:50:54 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: kerberos? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu What's the word on porting kerberos (v4) to NetBSD-current? Has it been done? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 01:57:22 1994 From: Duncan McEwan To: current-users@sun-lamp.cs.berkeley.edu Subject: COM_SW_SOFTCAR handling (Was: Re: The pppd blocking thing...) <199407131629.LAA17961@introl.introl.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From: Tim Chase > Subject: The pppd blocking thing... softcar works. > Date: Wed, 13 Jul 1994 11:29:34 -0500 (CDT) > > ... > > setting the softcar flag from /etc/ttys works just fine and is obviously the > proper solution to using pppd, tip or whatever for outgoing calls (if the > program in question doesn't use a nonblocking open). Perhaps. But Tim's message reminded me to investigate something that had occured to me back when the ttyflags stuff was first added to /etc/ttys. The way the COM_SW_SOFTCAR flag is currently handled means that while it is set, DTR is held high even if no process has the tty open. This seems wrong to me, since that flag should only be affecting whether a process thinks a carrier signal is present, and should have nothing to do with the presence or absence of a DTR signal. It means that when your tip, cu, pppd, or whatever exits, your modem won't hang up even if it is configured with a "hang up on loss of DTR" option. This is explicitly controlled by the following code in isa/com.c if (tp->t_cflag & HUPCL && (sc->sc_swflags & COM_SW_SOFTCAR) == 0) /* XXX perhaps only clear DTR */ outb(iobase + com_mcr, 0); Removing the COM_SW_SOFTCAR test causes the flag to behave as I think it should wrt DTR. However, if this change is made, I think it gives the COM_SW_SOFTCAR flag the same semantics as COM_SW_CLOCAL (although they are implemented in different ways). COM_SW_CLOCAL can be set by the "local" keyword in "/etc/ttys", so the question then becomes: why have both? It occurred to me that since CLOCAL could be interpreted as saying that the tty is not connected to a modem, it's semantics could be changed to make it not alter DTR at all. But I'm not sure if Posix allows this, and anyway, I can't think of any reason why it would be useful :-) If COM_SW_SOFTCAR stays as it is, I guess people wanting correct handling of DTR, can use COM_SW_CLOCAL, but I think the semantics of "softcar" vs "local" should be documented somewhere. Comments, anyone? Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:04:25 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... X-Sun-Charset: US-ASCII Content-Length: 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is msdosfs working yet? Is it in the snapshot? I'd love to test but certain system requirements for me require me to be able suck some things on and off msdos disks once a day. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:05:15 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: i386 binary snapshot seems fine; other q's X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu (a) I picked up the i386 binary snapshot Chris laid down yesterday---seems to work fine, as much as I can tell. (b) I'm trying to get an XFree86 running on this version, with near success. I need (1) an old shared libc (libc.so.4.0) for the user programs---anybody have one they can uuencode or make FTP'able? (2) a working pms driver for the lousy microsoft mouse that came with this machine (not mine--a student group's). I can't sup the latest bits, but the logs didn't indicate anything changing recently in this arena. What's the word on the pms driver (shall I try to fix it and mail changes?) (c) the ddb option seems busted in last week's source snapshot--again, is this fixed by the stuff I would sup if I could? Thanks, ==John From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:20:13 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, tim@introl.introl.com Subject: Re: hp300 rootimage on 9000-425 - does it work Sender: owner-current-users@sun-lamp.cs.berkeley.edu It depends on exactly which model of 425 you are trying to boot. Later ones have different video hardware that we do not have a driver for (yet). From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:20:18 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... <9407141435.AA28446@aggregate.com> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Is msdosfs working yet? Is it in the snapshot? I'd love to test but certain > system requirements for me require me to be able suck some things on and off > msdos disks once a day. > > -Mark > No. No. A fix is in the works. later Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:23:31 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: FTP stuff... From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu In case anyone cares... You can get Ken Hornstien's Mosaic-2.4 (both static and quasi-dynamic) on ftp.csos.orst.edu:/pub/NetBSD/misc/i386 Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Sat Jul 16 02:24:46 1994 From: Scott Anderson Subject: accton and lastcomm 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: 191 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Lastcomm segfaults with quite some regularity on the Binary set that CGD relased a couple days ago and with the very latest binaries (I don't think they changed at all). Any ideas ? Scott From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:37:48 1994 To: Duncan McEwan Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_SOFTCAR handling (Was: Re: The pppd blocking thing...) <199407142246.KAA27876@bats.comp.vuw.ac.nz> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > question then becomes: why have both? 'clocal' and 'softcar' are supposed to be used by different things. the former is when you want the line to "default" to seeming like carrier is detected, but want it to be able to be disabled. i.e. you could e.g. tip out then stty -clocal that line. softcar is supposed to be used _only_ for hardwired terminals that don't provide DCD themselves. it is _NOT_ meant to be used with modems. it cannot be disabled for an open line. the SW flags are settable only by root, and provide a default for the line, on open. 'softcar' can't be disabled by the user of the line, while the 'clocal' (and the other flags, 'crtscts' and 'mdmbuf' can be). cgd From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:42:58 1994 Subject: key program missing from s/key? 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: 463 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I tried to generate a s/key sequence with more than the default 99 entries. If I read the man right, I should use "skeyinit -s", but then I need a "key" program, which is missing. What am I doing wrong? Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:44:34 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: problems with tcsh. From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu hi, i've had this problem intermitantly with various netbsd's. i've been unable to build a tcsh (i've tried 6.03, 6.04, 6.05, and then 6.03 in `othersrc') that doesn't have problems with losing carriage returns now and then. eg: whaite ~/tcsh-6.03> echo $tcsh 6.03.00 whaite ~/tcsh-6.03> there is one thing that does worry me. the output of stty -g seems to be very strange when running tcsh. sh $ stty -g gfmt1:cflag=5a00:iflag=2b22:lflag=dcb:oflag=7:discard=f: dsusp=1a:eof=4:eol=ff:eol2=ff:erase=8:intr=3:kill=15: lnext=16:min=1:quit=1c:reprint=12:start=11:status=ff: stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600 whaite ~/tcsh-6.03> stty -g gfmt1:cflag=5a00:iflag=2b22:lflag=20000dcb:oflag=7:discard=f: dsusp=1a:eof=4:eol=ff:eol2=ff:erase=8:intr=3:kill=15: lnext=16:min=1:quit=1c:reprint=12:start=11:status=ff: stop=13:susp=1a:time=0:werase=17:ispeed=9600:ospeed=9600 (i've inserted newlines myself - it's supposed to be all one line) that 'lflag=20000dcb' seems to be corrupted somehow, and only happens with i run `stty -g' from tcsh. the above line is from sh. neither sh or csh have this problem, incidentally. if anybody knows what is wrong, or how to fix it, please let me know. 'ta, .mrg. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:45:15 1994 To: "Craig M. Chase" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... <199407141509.KAA06487@orac.ece.utexas.edu> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > BTW: what is the status of the NIS server implementation? I've been tracking it. It still needs work. I still have concerns about it being a single-threaded style RPC program, but as the author gets closer to having it solid I'll probably jump in and help him with that. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:49:54 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mouse@Collatz.McRCIM.McGill.EDU Subject: Re: problem with recent make Sender: owner-current-users@sun-lamp.cs.berkeley.edu foo.c: foo fsm < foo > foo.c Your problem here is that in addition to your explicit rule, there is also an implicit suffix rule for `foo: foo.c', thus causing a loop. You need to disable the suffix rule. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:55:54 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, jtk@kolvir.blrc.ma.us Subject: Re: i386 binary snapshot seems fine; other q's Sender: owner-current-users@sun-lamp.cs.berkeley.edu (2) a working pms driver for the lousy microsoft mouse [...] I'm working on that right now. (c) the ddb option seems busted in last week's source snapshot [...] What do you mean by `busted'? It works fine on my i386 and hp300. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 02:59:20 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: problem with 1.0-alpha man(1) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just updated my netbsd to the latest SPARC binary snapshot, and I find that man still has a problem it had before the update (and hence it's probably long-standing). Specifically, if I ask for a man page that exists in more than one section (crontab, say, which exists in both (1) and (5)), then I always get the same one, even if I explicitly specify the other. In this example, "man 5 crontab" still shows me crontab(1), rather than crontab(5). Rebuilding man from -current source of last time I supped it (a couple of nights ago) didn't help. I haven't touched any man.conf files since unpacking the binary tarball. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:09:39 1994 From: mycroft@gnu.ai.mit.edu (Charles Hannum) To: current-users@sun-lamp.cs.berkeley.edu Subject: fdesc and nullfs problems Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just committed a patch that fixes a fencepost error in the fdesc file system. This should fix the problems a couple of people reported with it crashing, and will likely also fix the nullfs problem someone reported (since if both are enabled, it would clobber nullfs's memory). Let me know if either of the problems persist after tonight's update. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:10:50 1994 From: Vax Subject: FAQ: upgrading after sup To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 869 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I found a bit of a catch-22 zip201 needs new stdio package in libc (0.9's is buggy) new libc needs new include files Makefile for include files needs new options to find, and pax which, probably, needs new include files 1) Suggestions? Better way to upgrade? Moreover, I got some i386 binaries and put them on a floppy... to try booting from. I created the fs from within 0.9.. and copied the bins over... but it panics.. in swfree (errno 6) 2) Am I doing something wrong? Is there a way to get part of the files from a collection in sup? E.G. the stdio stuff in libc. I am low on diskspace. 3) How to do that? Thanks (a not-quite kernel hacker) -- "God protect me from my friends, I can protect myself from my enemies" Voltaire "What was heresy yesterday is commonplace today; heresy does not exist to him who sees tomorrow" me VaX#n8 vax@ccwf.cc.utexas.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:16:30 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mouse@Collatz.McRCIM.McGill.EDU Subject: Re: problem with 1.0-alpha man(1) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Specifically, if I ask for a man page that exists in more than one section (crontab, say, which exists in both (1) and (5)), then I always get the same one, even if I explicitly specify the other. This only happens if you have `MANPATH' set. Please report it through GNATS and it will eventually get fixed. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:19:39 1994 To: jtk@atria.com, jtk@kolvir.blrc.ma.us Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? <199407141153.HAA06163@kolvir.blrc.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <9027.774316286.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > What's the word on porting kerberos (v4) to NetBSD-current? Has it been > done? I have ported most of it and contributed it to the core people. I hope to see them put it in after finishing the 1.0 release. Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:25:52 1994 X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu, port-hp300@sun-lamp.cs.berkeley.edu Subject: network performance Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: David Carrel Sender: owner-current-users@sun-lamp.cs.berkeley.edu Can anyone explain why I am seeing different throughput rates on network traffic depending on the direction. I started out testing throughput on my slip link. I am using ttcp (a tcp test program). When sending data TO my machine over a 28.8 modem with DTE set to 38.4 (the max on the hp300), I see transfer rates of around 3.62KBytes/s (~=36Kbaud). Pretty nice! (Obviously I am getting good compression in the modem.) But when I tried reversing the direction (sending FROM my NetBSD machine) my transfer rate dropped to .97KB/s (close to one fourth). I tried varying the packet lengths and the socket buffer sizes (socket buffer sizes have an amazing affect on SunOS) but I saw no appreciable effects under NetBSD. I tried a similar test over my ethernet, and I noticed about a 10% drop when sending versus receiving. Over the slip link, things happen slowly enough that you can watch TCP "as it happens" by watching the modem lights (you can count the ACKs). When sending from NetBSD, there are large periods where nothing is being sent. It almost appears that TCP is backing too far off. Seems like a tuning problem, but I am not a TCP wiz. My box is an hp375 running NetBSD 1.0-alpha. (sources from 12 July 94) Dave From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:27:10 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Scott Anderson Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: accton and lastcomm <199407141901.OAA01170@rush.cc.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Lastcomm segfaults with quite some > regularity on the Binary set that > CGD relased a couple days ago and with the > very latest binaries (I don't think they changed > at all). Any ideas ? > > Scott Yeah. I think the accounting database got hit by the changes to the size of uid_t and gid_t. If you move the database aside, and use a matched kernel and binary pair, then i think things will work fine. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:28:11 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: problem with recent make Sender: owner-current-users@sun-lamp.cs.berkeley.edu I pulled over the latest binary snapshots (for the SPARC, though I suspect it doesn't matter) and replaced my previous binary system. Upon rebooting, I discovered that all my old executables now printed "No ld.so" and died; this puzzles me because the compiled-in path to ld.so in the old binaries is /usr/libexec/ld.so (verified with "strings - oldbinary | egrep ld.so"), which is the same as the path found the same way in a new executable (and the same as the path in -current src/lib/csu/sparc/crt0.c as of an evening or two ago) - though /usr/libexec/ld.so does not exist, so I'm not sure what's going on. But relinking cures it, so it's not important, just odd. More important is something make does. I have a Makefile that reads, in part, abspath.prs.fsm.c: abspath.prs.fsm fsm < abspath.prs.fsm > abspath.prs.fsm.c abspath.cpt.fsm.c: abspath.cpt.fsm fsm < abspath.cpt.fsm > abspath.cpt.fsm.c For the sake of brevity below, I will write "foo" to mean either "abspath.prs.fsm" or "abspath.cpt.fsm", depending. Thus, we can think of the Makefile as containing foo.c: foo fsm < foo > foo.c On 4.3 (pre-Reno, pre-Tahoe - the old stuff), this worked fine; it obeyed what I wrote, running "fsm < foo > foo.c" exactly when foo was newer than foo.c. SunOS 3.5 make produced a cryptic message "$! nulled, predecessor circle" and otherwise behaved the same. SunOS 4.x make exhibits catastrophic misbehavior; it complains that either "foo depends on itself" or "foo.c depends on itself" and then either executes the command given or runs "cc foo.c -o foo", thereby destroying the input file. (Successive runs alternate between the two behaviors; I think the messages alternate too but I'm not sure.) The make binary in the previous SPARC snapshot worked fine; it did what the Makefile says to do and didn't get upset. The current make says "Graph cycles through foo.c" and treats this as a failure for the targets that depend on those files. (Mercifully, it doesn't try to run "cc -o foo foo.c", but it doesn't execute the specified command either, and it treats it as a build error, which makes it hard to work around it by carefully touching the appropriate files.) How can I teach make to do what I tell it to? Default rules are all very well in the absence of explicit instructions to the contrary, but when (as here) there _are_ explicit instructions, I maintain they should be obeyed. I'm prepared to dive into make if I have to to fix this, but since someone must have added something that caused this relatively recently, it seems a bit silly for me to go looking de novo. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:39:25 1994 X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: grantham@netcom.com (Brad "ADB Guy" Grantham) Cc: current-users@sun-lamp.cs.berkeley.edu, port-hp300@sun-lamp.cs.berkeley.edu Subject: Re: network performance <199407142332.QAA14375@netcom5.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: David Carrel Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I had a similar problem under NetBSD/Mac68k, and I discovered that my modem > was set for XON/XOFF, although the serial connection was configured for > hardware flow control. I forget what the command was on my modem, but once > I configured it for RTS/CTS (or whatever that is), SL/IP started working > wonderfully. Nope, I have the modem set up correctly. Good thought though. Dave From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:43:37 1994 From: "Craig M. Chase" Subject: Re: new i386 binary snapshot... To: current-users@sun-lamp.cs.berkeley.edu Organization: Department of Electrical and Computer Engineering X-Address: The University of Texas at Austin, Austin, TX 78712 X-Phone: (512) 471 7457 X-Fax: (512) 471 5907 X-Mailer: ELM [version 2.4 PL23beta2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2087 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Chris G. Demetriou writes: > > i've put a new binary snapshot for the i386 up for FTP. > > it's of the sources that are in the NetBSD 1.0 release branch, so > please do try it out... 3 (probably FAQ) things. 0) Uh... speaking of FAQs, would it be a good idea to periodically post a standard form to this mailing list that explains a) what the list is for b) where the archives of the mailing list can be found c) other useful bits of info for new folk, and for those (like me) with very short memories. 1) The behavior of ypbind has changed since my last upgrade (May 2, 94) if you issue "ypset " the binding only lasts for a couple of minutes. Due to political wierdness, I can not put my NetBSD machine on the same subnet as our ypserver, and since the broadcasts don't propagate across subnet boundaries, I've been using ypset. Currently, I have a cron job issuing ypset once a minute. This terrible kludge seems to allow me to log in. BTW: what is the status of the NIS server implementation? 2) During the upgrade, I found that old (May 2) binaries would not run with the new kernel. I got the "Cannot map ld.so" error. I'm sure this question clearly illustrates to the world my naivete, (but what the heck, I'm not proud), what does this message really mean? Why do I still get it when I run "elm"? How can I (short of recompiling everything in /usr/local/bin) get my programs to work again? 3) and speaking of recompiling /usr/local/bin.... ranlib seems to be behaving strangely: e.g. # cd /usr/src/local/elm-2.4/lib # ranlib ./libutil.a ranlib: ./libutil.a: Undefined error: 0 # which ranlib /usr/bin/ranlib # ls -l /usr/bin/ranlib -r-xr-xr-x 1 bin bin 20480 Jul 12 18:55 /usr/bin/ranlib* # cksum /usr/bin/ranlib 2803660188 20480 /usr/bin/ranlib # cksum /usr/lib/libc.so.12.0 3763713561 396429 /usr/lib/libc.so.12.0 Any thoughts? -- Craig Chase --- Assistant Professor Electrical and Computer Engineering The University of Texas at Austin Austin, TX 78721 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 03:59:46 1994 X-Authentication-Warning: large.cisco.com: Host localhost.cisco.com didn't use HELO protocol To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problem with 1.0-alpha man(1) <199407141855.OAA10543@Collatz.McRCIM.McGill.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" From: David Carrel Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just updated my netbsd to the latest SPARC binary snapshot, and I > find that man still has a problem it had before the update (and hence > it's probably long-standing). Specifically, if I ask for a man page > that exists in more than one section (crontab, say, which exists in > both (1) and (5)), then I always get the same one, even if I explicitly > specify the other. In this example, "man 5 crontab" still shows me > crontab(1), rather than crontab(5). The problem will go away if you unset your MANPATH variable. Yes, I think it's still a bug. The man pages implies that it should work the way that you and I expect, but the comments in the code say that if MANPATH is set, then the chapter argument will be ignored. I've been meaning to dredge up a patch and mail it in, but I haven't found the time for that one yet. Dave From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:02:14 1994 Subject: Re: problem with 1.0-alpha man(1) To: mouse@Collatz.McRCIM.McGill.EDU (der Mouse) 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: 885 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just updated my netbsd to the latest SPARC binary snapshot, and I > find that man still has a problem it had before the update (and hence > it's probably long-standing). Specifically, if I ask for a man page > that exists in more than one section (crontab, say, which exists in > both (1) and (5)), then I always get the same one, even if I explicitly > specify the other. In this example, "man 5 crontab" still shows me > crontab(1), rather than crontab(5). > Rebuilding man from -current source of last time I supped it (a couple > of nights ago) didn't help. I haven't touched any man.conf files since > unpacking the binary tarball. I remember people posting on the list earlier with man(1) problems and they seem to boil down to having MANPATH set. I don't have it set and I haven't had problems with man since I unset it when the new version was included into the tree. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:06:27 1994 X-Authentication-Warning: mtc064.mtc.telcom.oki.co.jp: Host localhost.mtc.telcom.oki.co.jp didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: not booting from my wd0... From: Kawahara Taro Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have one IDE drive (wd0) and two SCSI drive thru adaptec1542b. I try new boot block (disklabel -B wd0), but it not boots. It is showing [/] mark, ... not spinning. I am using ftp.iastate.edu's binary snapshot last night. (usr.misc.tar.gz;/usr/mdec/*) 0.9 is working well. thank you -- kawahara taro From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:08:22 1994 From: Scott Reynolds Subject: A proposal to aid in building i386 boot floppies To: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since it's necessary to have static binaries for a boot floppy, I'd like to propose that two directories be added to ...i386/floppy: ftp and more. All we need is a Makefile in each and a corresponding change to the Makefile in the i386/floppy directory. This was a 3 minute job to create and test, and since it takes up virtually no space in the source tree, it seems well worth it. Oh, and thanks to Christos for the mkboot script, which is a wonderful tool for putting things together! Scott Reynolds Assistant System Administrator Technology Group, Inc. # This is a shell archive. Save it in a file, remove anything before # this line, and then unpack it by entering "sh file". Note, it may # create directories; files and directories will be owned by you and # have default permissions. # # This archive contains: # # floppy.makefile.pch # ftp/Makefile # more/Makefile # echo x - floppy.makefile.pch sed 's/^X//' >floppy.makefile.pch << 'END-of-floppy.makefile.pch' X*** Makefile.ORIG Mon Apr 18 03:45:53 1994 X--- Makefile Thu Jul 14 18:24:24 1994 X*************** X*** 1,7 **** X # $Id: Makefile,v 1.3 1994/06/14 04:19:43 cgd Exp $ X X .ifnmake install X! SUBDIR= fsck ftp init more mount reboot sh tar test umount X .endif X X .include X--- 1,7 ---- X # $Id: Makefile,v 1.3 1994/06/14 04:19:43 cgd Exp $ X X .ifnmake install X! SUBDIR= fsck init mount reboot sh tar test umount X .endif X X .include END-of-floppy.makefile.pch echo x - ftp/Makefile mkdir ftp sed 's/^X//' >ftp/Makefile << 'END-of-ftp/Makefile' X# from: @(#)Makefile 5.11 (Berkeley) 5/11/90 X# $Id: Makefile,v 1.2 1993/07/31 15:22:29 mycroft Exp $ X XSRCDIR= ${.CURDIR}/../../../../../usr.bin/ftp X XPROG= ftp XSRCS= cmds.c cmdtab.c ftp.c glob.c main.c ruserpass.c domacro.c X X.PATH: ${SRCDIR} XNOMAN=noman X X.include END-of-ftp/Makefile echo x - more/Makefile mkdir more sed 's/^X//' >more/Makefile << 'END-of-more/Makefile' X# from: @(#)Makefile 5.6 (Berkeley) 3/12/91 X# $Id: Makefile,v 1.6 1994/04/16 08:14:50 andrew Exp $ X XSRCDIR= ${.CURDIR}/../../../../../usr.bin/more X XPROG= more XCFLAGS+=-I${SRCDIR} -DREGEX -DTERMIOS XSRCS= ch.c command.c decode.c filename.c help.c input.c line.c \ X linenum.c main.c option.c os.c output.c position.c prim.c \ X screen.c signal.c tags.c ttyin.c XLDADD+= -ltermcap XDPADD+= ${LIBTERM} X X.PATH: ${SRCDIR} XNOMAN=noman X X.include END-of-more/Makefile exit From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:12:14 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: what to do with improvements? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've made some changes to the kernel that I believe are improvements. What should I do with the changes? One of them is SPARC-specific, which I could just send to port-sparc (or maybe deraadt :-), but the other two are changes to the diskless support, and I'm not sure what to do with those. If it matters, the changes are: - "options RCONS_WONB" makes the framebuffer console come up white-on-black rather than black-on-white. Five lines added to arch/sparc/rcons/rcons_kern.c. - "options NFS_BOOTSERV_GATE" makes the kernel use its boot server as its default gateway, rather than the server-supplied gateway that the comment claims is usually bogus. (I also discovered while doing this that NFS_BOOT_GATEWAY will not work if turned on; I didn't fix it.) About 30 lines added to nfs/nfs_boot.c. - "options NFS_ROOT_OPTIONS=xxx", if defined, supplies xxx as options in nfs_mount_diskless. In our environment, I needed NFSMNT_NOCONN here, and it seemed cleaner to do it this way than to hardwire NFSMNT_NOCONN into nfs_mount_diskless under control of a special option. (Why is it necessary? The boot server is also the NFS server, but in the bootparams exchange it returns its "remote" address, and NFS requests go to the "remote" address, but the replies come from the "local" address. I suppose I could have added interface-specific names and used those in the bootparams database, but the kernel should be configurable to tolerate this.) Three lines added to nfs/nfs_vfsops.c. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:19:40 1994 From: der Mouse To: christos@deshaw.com Subject: Re: problem with recent make Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> foo.c: foo >> fsm < foo > foo.c >> Default rules are all very well in the absence of explicit >> instructions to the contrary, but when (as here) there _are_ >> explicit instructions, I maintain they should be obeyed. > The make source code has not changed in that respect, but the > ``shuttle'' rule from the .c to .NULL suffix was added in the default > rules. Ah, okay, so that's the critical change. > I agree with you that explicit instructions should be obeyed, but > even if we fix it to work in the NetBSD make, it will not work > anywhere else. It'll work everywhere I need it to, if necessary by my carrying the netbsd make with me. :-) (I also am a strong believer in "if it's broken, make it obvious that it's broken", because brokenness that isn't obvious and blatant usually never gets fixed. Anywhere I find a make that misbehaves on such constructs in the Makefile, I report it to whatever bug channel is available.) > I don't think that it is very easy to fix either. It seems conceptually easy to me to fix: when a loop occurs that involves both explicit transformations and transformations derived from suffix rules, disable the suffix rules for the duration. Since it seems to be either diking out the suffix rule or doing something of the sort, I suppose I'll try to find the time to implement this and see how it works.... der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:19:59 1994 To: Scott Anderson Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: accton and lastcomm <199407141901.OAA01170@rush.cc.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Lastcomm segfaults with quite some > regularity on the Binary set that > CGD relased a couple days ago and with the > very latest binaries (I don't think they changed > at all). Any ideas ? It probably needs to be recompiled... dev_t changed type the other day, and it didn't affect many things, but it did cause the user-land accounting programs to get confused... chris From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:34:53 1994 From: grantham@netcom.com (Brad "ADB Guy" Grantham) Subject: Re: network performance To: carrel@cisco.com (David Carrel) Cc: current-users@sun-lamp.cs.berkeley.edu, port-hp300@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: 1272 Sender: owner-current-users@sun-lamp.cs.berkeley.edu David Carrel writes: > I started out testing throughput on my slip link. I am using ttcp (a tcp > test program). When sending data TO my machine over a 28.8 modem with DTE > set to 38.4 (the max on the hp300), I see transfer rates of around > 3.62KBytes/s (~=36Kbaud). Pretty nice! (Obviously I am getting good > compression in the modem.) But when I tried reversing the direction > (sending FROM my NetBSD machine) my transfer rate dropped to .97KB/s (close > to one fourth). I had a similar problem under NetBSD/Mac68k, and I discovered that my modem was set for XON/XOFF, although the serial connection was configured for hardware flow control. I forget what the command was on my modem, but once I configured it for RTS/CTS (or whatever that is), SL/IP started working wonderfully. > I tried a similar test over my ethernet, and I noticed about a 10% drop > when sending versus receiving. But then, of course, my problem may have nothing to do with yours... -Brad -- '1' means a BLACK pixel, '1' means button UP, what will Apple think of next? Brad Grantham, grantham@netcom.com >+------+< Happily slaved to NetBSD/Mac68k! I thought I would have to go without dinner tonight until I remembered the container of chocolate frosting in the fridge! From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 04:36:42 1994 To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problem with 1.0-alpha man(1) <199407141855.OAA10543@Collatz.McRCIM.McGill.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <10335.774320870.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just updated my netbsd to the latest SPARC binary snapshot, and I > find that man still has a problem it had before the update (and hence > it's probably long-standing). Specifically, if I ask for a man page > that exists in more than one section (crontab, say, which exists in > both (1) and (5)), then I always get the same one, even if I explicitly > specify the other. In this example, "man 5 crontab" still shows me > crontab(1), rather than crontab(5). Chances are you have MANPATH in your environment. Try without it. Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 05:23:37 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: key program missing from s/key? Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article "Martin Husemann" writes: > I tried to generate a s/key sequence with more than the default > 99 entries. If I read the man right, I should use "skeyinit -s", > but then I need a "key" program, which is missing. > > What am I doing wrong? The original S/Key distribution was terribly schitzophrenic over what the correct names for programs were. Some places suggested they start with "key" (key, keyinit, keyinfo, ...), some place suggested they started with "skey". We went with the latter scheme, and I tried to hunt down all the incorrect references and fix them. If something is still referring you to key instead of skey, it needs to be fixed. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 07:06:18 1994 Subject: WWW server 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 Is there a NetBSD/Amiga Web server out there? If not, then I may be able to host one off the local Web server. In this case, mail your pages to me! -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@freenet.toronto.on.ca for latest Toronto Free-Net information From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 07:13:10 1994 From: Mark_Weaver@brown.edu To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: new i386 binary snapshot... Sender: owner-current-users@sun-lamp.cs.berkeley.edu mark@aggregate.com (Mark P. Gooderum) writes: > Is msdosfs working yet? Is it in the snapshot? I'd love to test but certain > system requirements for me require me to be able suck some things on and off > msdos disks once a day. You can always use mtools in the future. It doesn't allow you to mount an msdos disk, but you can use its commands to copy files either way, rename, list, and delete files. You can find it in prep.ai.mit.edu:pub/gnu 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 Sat Jul 16 07:15:23 1994 From: Mark_Weaver@brown.edu To: David Carrel Cc: current-users@sun-lamp.cs.berkeley.edu, port-hp300@sun-lamp.cs.berkeley.edu Subject: Hardware handshaking with slip (was Re: network performance) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I get the same problem with my 486 box -- it's because hardware handshaking isn't working with slip for some reason. Perhaps it is something in the device-independent code. I'm giving the "-link2" option to ifconfig, which should enable hardware handshaking, although that wasn't documented in any man page the last I checked (I sent a pr on it). I know it's not a modem problem, because hardware handshaking works on this machine with both Linux and FreeBSD. I can see the "CS" (CTS) light go on and off on my USR Courier, but the "SD" (Send) light keeps going anyway. With Linux or FreeBSD, the lights go on and off together as they should. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science David Carrel writes: > I started out testing throughput on my slip link. I am using ttcp (a tcp > test program). When sending data TO my machine over a 28.8 modem with DTE > set to 38.4 (the max on the hp300), I see transfer rates of around > 3.62KBytes/s (~=36Kbaud). Pretty nice! (Obviously I am getting good > compression in the modem.) But when I tried reversing the direction > (sending FROM my NetBSD machine) my transfer rate dropped to .97KB/s (close > to one fourth). I tried varying the packet lengths and the socket buffer > sizes (socket buffer sizes have an amazing affect on SunOS) but I saw no > appreciable effects under NetBSD. > [...] > Over the slip link, things happen slowly enough that you can watch TCP "as > it happens" by watching the modem lights (you can count the ACKs). When > sending from NetBSD, there are large periods where nothing is being sent. > It almost appears that TCP is backing too far off. Seems like a tuning > problem, but I am not a TCP wiz. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 07:45:44 1994 From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: mfs broken? Sender: owner-current-users@sun-lamp.cs.berkeley.edu mfs seems to have broken for me some time during June. Now, the command: mount_mfs -s 16384 /dev/sd0b /tmp says "cg 0: bad magic number" and exits. /dev/sd0b is my only swap device. Any ideas what's wrong? 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 Sat Jul 16 08:30:18 1994 From: Tim Chase Subject: [i386] disklabel snafu 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: 675 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, It seems that there's a little problem in disklabel for i386 machines. There's some conditional code that finds the proper BIOS partition and seeks to it. The code is: (void)lseek(f, (off_t)(lbl_off * lp->d_secsize), L_SET); on line 412 of disklabel.c. Only problem is that a few lines later, it does: (void)lseek(f, (off_t)0, SEEK_SET); which causes the stuff to clobber the beginning of the disk. It seems that the second lseek ought to be enlosed in an #ifndef i386/#endif pair. I discovered this after trying to change my partition table an finding out that the BIOS partition table was always being overwritten. - Tim Chase tim@introl.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 08:43:06 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Tim Chase Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: [i386] disklabel snafu Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Tim Chase writes: > I discovered this after trying to change my partition table an > finding out that the BIOS partition table was always being > overwritten. so that explains it... why is it everytime i want to put in new boot blocks, its at a point that either them or disklabel is acting up =) -bri From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 10:18:13 1994 From: "Timothy F. Lee" Subject: Re: WWW server 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 Please send all responses either to me or to the list. I am also interested... Thanks.... --tim --------------------------------------- Timothy F. Lee Lead ACC Lab Assistant, Client Services University of Washington E-mail: koolkid@cac.washington.edu timlee@u.washington.edu Consulting: (206)543-5227 On Sat, 16 Jul 1994, David Jones wrote: > Is there a NetBSD/Amiga Web server out there? If not, then I may be > able to host one off the local Web server. In this case, mail your > pages to me! > > -- > David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto > email: dej@eecg.toronto.edu, finger for PGP public key > finger dej@freenet.toronto.on.ca for latest Toronto Free-Net information > From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 10:25:52 1994 From: Brian Leonard To: current-users@sun-lamp.cs.berkeley.edu Subject: ufs_mountroot Sender: owner-current-users@sun-lamp.cs.berkeley.edu I may be missing something obvious here, but I've tried to compile the 7/9 tarball using the most recent bin snapshot, and it doesn't link with: swapnetbsd.o: Undefined symbol `_ufs_mountroot' referenced from data segment I've grepped the whole source, and didn't find it anywhere...clues? thanks... -- While one person hesitates because Brian Leonard he feels inferior, the other is busy paranoid@ccwf.cc.utexas.edu making mistakes and becoming superior. -- Henry C Link From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 10:55:06 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Thorsten Lockert Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Thorsten Lockert writes: >> What's the word on porting kerberos (v4) to NetBSD-current? Has >> it been done? > I have ported most of it and contributed it to the core people. > I hope to see them put it in after finishing the 1.0 release. huh? i've been using stuff from tbird.cc.iastate.edu for ages now if all you want is kerb4... -bri From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 12:27:17 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Poor performance with 3c507's (i386) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm still getting rotten performance between a 486 with a 3c507 using 64k ram size and a 386 with a 16k wd8003e. If the 507 sends, I get 5 to 8k/sec, when the wd sends, I get 300+ k/sec. This sucks rocks. The card is in ``standard'' mode, since that's the only one where it works under NetBSD, but it passes all diagnostics under DOS even in ``turbo'' mode. --Michael From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 13:07:52 1994 From: Matthew Aldous Subject: newfs fault To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL0] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Having grabbed the most recent stuff from ftp.uni-regensburg.de I tried to newfs my usr partition.. It created info on the blocks, but died trying to disklabel it (I think) -- "newfs: ioctl(WDINFO): Invalid argument." -- Also, the install FAQ (bill?) should mention that the system will boot in single user mode, and that you need to do a mount -u /dev/sd0a / (gosh that was fun) (and reminder that gvpscsi.device (series II)) won't let you access non Amiga dos devices (during installtion) - and that a Mountlist entry needs to be created to access it (for dcp, etc) From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 14:39:08 1994 Subject: Re: new i386 binary snapshot... To: Mark_Weaver@brown.edu Cc: mark@aggregate.com, current-users@sun-lamp.cs.berkeley.edu From: Luke Mewburn X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1737 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > mark@aggregate.com (Mark P. Gooderum) writes: >> Is msdosfs working yet? Is it in the snapshot? I'd love to test but >> certain system requirements for me require me to be able suck some >> things on and off msdos disks once a day. > You can always use mtools in the future. It doesn't allow you to > mount an msdos disk, but you can use its commands to copy files either > way, rename, list, and delete files. mtools-2.0.7 has problems with partitions > 32MB, often with dodgy or empty files resulting on the unix side. I looked into the code a big way, and even by bumping up the internal mtools limit on the assumed size of a directory, I still had problems on large partitions or large directories (e.g, my windoze directory with a couple of extra TT fonts in it.) I did clean up a lot of the code (in an unofficial 2.1 version), but since I couldn't 100% guarantee a working product, I never released it. Note that the same directories that caused problems on mtools caused msdosfs to crash (on mid march kernels), so I suspect it is something the way that dos 6.2 orders stuff slightly against the defacto standard that Microsloth set in earlier versions. If I had a DECENT reference for post Dos3.3 filesystems I'd re-write mtools from scratch (as the current version is really crap code) I might have another look at my attempt to clean up the code, and release it with a disclaimer that it MAY have problems with partitions > 32MB with large directories. If there's enuf interest that is. -- ``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 Sat Jul 16 14:42:23 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/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/conf/files.amiga.newconf U src/sys/arch/amiga/dev/if_ed.c U src/sys/arch/amiga/dev/if_edreg.h U src/sys/arch/amiga/dev/ztwobus.c U src/sys/arch/hp300/dev/rd_compat.c U src/sys/arch/hp300/dev/sd_compat.c U src/sys/arch/hp300/hp300/machdep.c U src/sys/net/if_sl.c U src/sys/net/if_slvar.h U src/sys/sys/exec.h Killing core files: 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/sup: 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 Sat Jul 16 04:22:29 1994 SUP Scan for current completed at Sat Jul 16 04:25:05 1994 SUP Scan for mirror starting at Sat Jul 16 04:25:05 1994 SUP Scan for mirror completed at Sat Jul 16 04:27:41 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 15:34:45 1994 From: Duncan McEwan To: mycroft@gnu.ai.mit.edu (Charles Hannum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: fdesc and nullfs problems <9407142053.AA27131@duality.gnu.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just committed a patch that fixes a fencepost error in the fdesc > file system ... and will likely also fix the nullfs problem someone > reported If you're refering to the "kern/337: rename can cause kernel panic on a nullfs" problem that I submitted last week, it still occurs in exactly the same way in a kernel compiled with "fdesc_vnops.c,v 1.15.2.1 1994/07/15 21:42:51". I'm sure the problem is caused by the rename call passing a NULL vnode to the nullfs. Initially I wasn't sure whether it was a bug in the rename call in that it shouldn't do that, or in the nullfs in that it should expect it. But now I'm tending towards the latter. When renaming to a non-existent file, it doesn't seem unreasonable that the rename system call will pass a NULL vnode pointer for the target file to the lower layer. Certainly the ufs_rename code seems to expect that, so presumably the nullfs layer should too. Duncan From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 16 15:34:56 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Profiling the kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm interested in running a profiled kernel to attempt to determine places where performance improvements could be made. Does anyone have the info on how to do this? Thanks, -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 15:38:44 1994 From: der Mouse To: paranoid@ccwf.cc.utexas.edu Subject: Re: ufs_mountroot Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I may be missing something obvious here, but I've tried to compile [the kernel with] > the 7/9 tarball using the most recent bin snapshot, and it doesn't > link with: > swapnetbsd.o: Undefined symbol `_ufs_mountroot' referenced from data segment > I've grepped the whole source, and didn't find it anywhere...clues? Your config.new binary is out of date with respect to your kernel source. Rebuild and reinstall config.new and do a reconfig and rebuild (you may need to completely destroy the compile/xxx directory). I had the same problem when using a recent source tree with an older binary tree. (It's not ufs_mountroot any longer; it's ffs_mountroot. The reference is generated by config.new, which is why you need a new config.new to make the problem go away.) der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 15:49:07 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: Missing prototype for madvise(). To: current-users@sun-lamp.cs.berkeley.edu, cgd@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 446 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I already sent a bug-report a month ago but I believe it got lost. is missing a prototype for madvise(), here's a diff: *** mman.h~ Fri Jul 15 18:07:29 1994 --- mman.h Fri Jul 15 18:08:56 1994 *************** *** 86,91 **** --- 86,92 ---- int msync __P((caddr_t, size_t)); int mlock __P((caddr_t, size_t)); int munlock __P((caddr_t, size_t)); + int madvise __P((caddr_t, size_t, int)); __END_DECLS #endif /* !KERNEL */ From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 16:20:31 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, paranoid@ccwf.cc.utexas.edu Subject: Re: ufs_mountroot Sender: owner-current-users@sun-lamp.cs.berkeley.edu You need to be using a more recent version of config(8). From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 16:53:05 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, explorer@vorpal.com Subject: Re: Poor performance with 3c507's (i386) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Somewhere deep in my mail, I have patches from Rafal Boni to improve the if_ie driver. One of these days I'll get to it... From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 17:53:29 1994 To: bdc@ai.mit.edu (Brian D. Carlstrom) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? <9407160715.AA29234@blackjack> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <12486.774369393.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I have ported most of it and contributed it to the core people. > > I hope to see them put it in after finishing the 1.0 release. > > huh? i've been using stuff from tbird.cc.iastate.edu for ages now if all > you want is kerb4... Is that integrated into the existing tools like it originally was in Net/2 and 4.4BSD? Eg. in mount_nfs/nfsd? rcp/rlogin/rsh/login/passwd/etc? Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 16 19:40:58 1994 To: Brian Leonard Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: ufs_mountroot From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Sat, 16 Jul 1994 01:59:21 -0500 Brian Leonard wrote: > > I may be missing something obvious here, but I've tried to > compile the 7/9 tarball using the most recent bin snapshot, and it > doesn't link with: > > swapnetbsd.o: Undefined symbol `_ufs_mountroot' referenced from data ufs_mountroot -> ffs_mountroot. I know this was fixed on the hp300... > segment > I've grepped the whole source, and didn't find it anywhere...clues? > thanks... > -- > While one person hesitates because > Brian Leonard he feels inferior, the other is busy > paranoid@ccwf.cc.utexas.edu making mistakes and becoming superior. > -- Henry C Link ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 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 Sat Jul 16 19:57:22 1994 From: Ryutaroh Matsumoto To: Mark_Weaver@brown.edu Cc: current-users@sun-lamp.cs.berkeley.edu, port-i386@sun-lamp.cs.berkeley.edu Subject: Re: Hardware handshaking with slip (was Re: network performance) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> On Thu, 14 Jul 1994 23:53:03 -0400, Mark_Weaver@brown.edu said: Mark> I get the same problem with my 486 box -- it's because hardware Mark> handshaking isn't working with slip for some reason. Perhaps it is Mark> something in the device-independent code. Mark> I'm giving the "-link2" option to ifconfig, which should enable Mark> hardware handshaking, although that wasn't documented in any man page Mark> the last I checked (I sent a pr on it). Mark> I know it's not a modem problem, because hardware handshaking works on Mark> this machine with both Linux and FreeBSD. I can see the "CS" (CTS) Mark> light go on and off on my USR Courier, but the "SD" (Send) light keeps Mark> going anyway. With Linux or FreeBSD, the lights go on and off Mark> together as they should. Hello everyone, let me say my guess about hardware handshaking. comstart() in i386/isa/com.c uses tp->t_state&TS_TTSTOP to know whether the serial port can receive data. commint() maintain TS_TTSTOP according to CTS and ttyinput() in kern/tty.c always turns off TS_TTSTOP when IXANY is on. So NetBSD can start to send data against CTS. But I think this might have nothing to do with slip. ttstart() should not be called directly. It is specific to tty discipline and not appropriate for ppp or slip discipline. Following expression at the end of comparam() is always false because t_cflag is assigned to c_cflag before this. /* * If DCD is off and MDMBUF is changed, we must toggle TS_TTSTOP. * XXX should be done at tty layer. */ if ((sc->sc_swflags & COM_SW_SOFTCAR) == 0 && (sc->sc_msr & MSR_DCD) == 0 && (tp->t_cflag & MDMBUF) != (t->c_cflag & MDMBUF)) { if ((t->c_cflag & MDMBUF) == 0) { Following is my fix to these problems. Currently I don't use NetBSD and I cannot examine whether my guess and fix are right. com.c is "$Id: com.c,v 1.31 1994/04/10 10:29:06 cgd Exp $". --- com.c.~1~ Sat Jul 16 23:31:22 1994 +++ com.c Sun Jul 17 01:04:35 1994 @@ -557,11 +557,6 @@ s = spltty(); - /* and copy to tty */ - tp->t_ispeed = t->c_ispeed; - tp->t_ospeed = t->c_ospeed; - tp->t_cflag = t->c_cflag; - if (ospeed == 0) outb(iobase + com_mcr, sc->sc_mcr &= ~MCR_DTR); else @@ -584,32 +579,32 @@ } /* - * If CTS is off and CRTSCTS is changed, we must toggle TS_TTSTOP. - * XXX should be done at tty layer. + * If CTS is off and CRTSCTS is turned off, we start output. */ if ((sc->sc_msr & MSR_CTS) == 0 && - (tp->t_cflag & CRTSCTS) != (t->c_cflag & CRTSCTS)) { - if ((t->c_cflag & CRTSCTS) == 0) { - tp->t_state &= ~TS_TTSTOP; - ttstart(tp); - } else - tp->t_state |= TS_TTSTOP; + (tp->t_cflag & CRTSCTS) && + (t->c_cflag & CRTSCTS) == 0) { + tp->t_cflag = t->c_cflag; /* We must turn off CRTSCTS to + send data. */ + (*linesw[tp->t_line].l_start)(tp); } /* - * If DCD is off and MDMBUF is changed, we must toggle TS_TTSTOP. - * XXX should be done at tty layer. + * If DCD is off and MDMBUF is turned off, we start output. */ if ((sc->sc_swflags & COM_SW_SOFTCAR) == 0 && (sc->sc_msr & MSR_DCD) == 0 && - (tp->t_cflag & MDMBUF) != (t->c_cflag & MDMBUF)) { - if ((t->c_cflag & MDMBUF) == 0) { - tp->t_state &= ~TS_TTSTOP; - ttstart(tp); - } else - tp->t_state |= TS_TTSTOP; + (tp->t_cflag & MDMBUF) && + (t->c_cflag & MDMBUF) == 0) { + tp->t_cflag = t->c_cflag; + (*linesw[tp->t_line].l_start)(tp); } + /* and copy to tty */ + tp->t_ispeed = t->c_ispeed; + tp->t_ospeed = t->c_ospeed; + tp->t_cflag = t->c_cflag; + splx(s); return 0; } @@ -625,10 +620,8 @@ s = spltty(); if (tp->t_state & (TS_TTSTOP | TS_BUSY)) goto out; -#if 0 /* XXXX I think this is handled adequately by commint() and comparam(). */ if (tp->t_cflag & CRTSCTS && (sc->sc_mcr & MSR_CTS) == 0) goto out; -#endif if (tp->t_outq.c_cc <= tp->t_lowat) { if (tp->t_state & TS_ASLEEP) { tp->t_state &= ~TS_ASLEEP; @@ -718,14 +711,9 @@ outb(iobase + com_mcr, sc->sc_mcr &= ~(MCR_DTR | MCR_RTS)); } - if (delta & MSR_CTS && tp->t_cflag & CRTSCTS) { - /* the line is up and we want to do rts/cts flow control */ - if (msr & MSR_CTS) { - tp->t_state &= ~TS_TTSTOP; - ttstart(tp); - } else - tp->t_state |= TS_TTSTOP; - } + /* the line is up and we want to do cts flow control */ + if (delta & MSR_CTS && tp->t_cflag & CRTSCTS && msr & MSR_CTS) + (*linesw[tp->t_line].l_start)(tp); } int PS. I send this to port-i386 instead of port-hp300, since apparently it has nothing to do with hp300. --- Ryutaroh Matsumoto From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 21:02:31 1994 From: chopps@emunix.emich.edu To: Alan Bair Cc: amiga@sun-lamp.cs.berkeley.edu (Amiga NetBSD - General) Subject: Re: loadbsd -b ignoring device name? <9406272103.AA06284@amcu-tx.sps.mot.com> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu no its not sd0b has never been supported to my knowledge. I just went and looked at revision 1.1 of swapgeneric.c and it handles this the same way as it still does. If you want root to mount on swap you use `sd0*' swapgeneric doesn't try to parse partitions. I have never tested this though. Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 21:45:52 1994 From: klei0001@Uni-Trier.de (Klaus Klein) Subject: crippled getty prompt on ttye0 To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Just a short one - it's a question that came up some times recently: when I start NetBSD in multi user mode, getty prompts me NetBSDi (olco(tte0 loi: on ttye0. Before my complete upgrade to 940615 (A3000, from scratch!), this one has never occured to me. Sorry that I'm asking this - I know that this one has been discussed, but my mailing-list archive got itself killed some days ago. -- Klaus Klein From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 16 21:53:25 1994 From: chopps@emunix.emich.edu To: klei0001@Uni-Trier.de (Klaus Klein) Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: crippled getty prompt on ttye0 <9407161906.AA07892@Uni-Trier.De> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu This has been fixed, if its not in the current snapshot it will be in the next one (and the release) Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 17 01:02:09 1994 To: bdc@ai.mit.edu (Brian D. Carlstrom) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? <9407162136.AA29413@blackjack> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <801.774394973.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Is that integrated into the existing tools like it originally was > > in Net/2 and 4.4BSD? Eg. in mount_nfs/nfsd? > > rcp/rlogin/rsh/login/passwd/etc? > > its the net/2 kerb4 setup with berkeley makefiles etc Including integration with all the pertaining user-space stuff? Including NFS? That is what I have given to core, except for the utilities that has not yet been upgraded to their 4.4Lite versions (although I have those on my local system). I also have available a non-US DES library on ftp.sigmasoft.com that has been set up for use with Kerberos (and no, sigmasoft.com is not situated in US). Thorsten -- Thorsten Lockert | postmaster@bbb.no | Postbox 435 | hostmaster@bbb.no | Universe, n.: N-5001 Bergen | tholo@bbb.no | The problem. Norway | tholo@sigmasoft.com | From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 17 01:17:36 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Thorsten Lockert Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Thorsten Lockert writes: >> huh? i've been using stuff from tbird.cc.iastate.edu for ages now >> if all you want is kerb4... > Is that integrated into the existing tools like it originally was > in Net/2 and 4.4BSD? Eg. in mount_nfs/nfsd? > rcp/rlogin/rsh/login/passwd/etc? its the net/2 kerb4 setup with berkeley makefiles etc -bri From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 17 01:56:24 1994 From: Sam Noonan Subject: 744 kernal to latest To: BSD Amiga Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sorry if this has been asked before, but I am new to this group. I was trying to upgrade from the 744 kernal to the latest one available. It gives me the following errors on my partitions. found dostype: 0x42534452 which is deprecated using: 0x4e425207 instead found dostype: 0x42534453 which is deprecated using: 0x4e425301 instead found dostype: 0x42534444 which is deprecated using: 0x4e425507 instead found dostype: 0x42534445 which is deprecated using: 0x4e425507 instead I haven't been able to find any information on this. And kernal.744 still works just fine. Thank you for any sugguestions you may have. Sam Noonan From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 17 02:03:14 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: WWW server To: koolkid@u.washington.edu (Timothy F. Lee) Cc: dej@eecg.toronto.edu, 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: 820 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Timothy F. Lee wrote: > On Sat, 16 Jul 1994, David Jones wrote: > > > Is there a NetBSD/Amiga Web server out there? If not, then I may be > > able to host one off the local Web server. In this case, mail your > > pages to me! A few NetBSD-Amiga WWW servers do exist. The Main one is done by Matthias Kirschnick and includes links to other NetBSD information sites. Matthias Kirschnick's NetBSD-Amiga-page Ron Roskens U of MN - Undergrad CS Major | garion@mermaid.micro.umn.edu U of MN - ACM Chapter SysAdmin | rosk0001@gold.tc.umn.edu Life is a simulation of reality. | garion@reality.cs.umn.edu Ron Roskens From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 17 02:23:53 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: 744 kernal to latest To: snoonan@netcom.com (Sam Noonan) Cc: amiga@sun-lamp.cs.berkeley.edu (NetBSD - Amiga) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1136 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Sam Noonan wrote: > Sorry if this has been asked before, but I am new to this group. > > I was trying to upgrade from the 744 kernal to the latest one > available. > > It gives me the following errors on my partitions. > > found dostype: 0x42534452 which is deprecated using: 0x4e425207 instead This is the B S D R partition now called --->: N B R\7 > found dostype: 0x42534453 which is deprecated using: 0x4e425301 instead This was the B S D S swap partition now called: N B S\1 > found dostype: 0x42534444 which is deprecated using: 0x4e425507 instead > found dostype: 0x42534445 which is deprecated using: 0x4e425507 instead All others are the user partitions now called : N B U\7 > I haven't been able to find any information on this. And kernal.744 > still works just fine. > > Thank you for any sugguestions you may have. It would be best to change to the newer disklabels as soon as possible, however remember that in doing so you will be using HDUtils which could possibly cause data loss on the drives. I changed them without any problems. Ron Roskens From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 17 03:02:55 1994 X-Authentication-Warning: packrat.vorpal.com: Host localhost didn't use HELO protocol To: Thorsten Lockert Cc: bdc@ai.mit.edu (Brian D. Carlstrom), current-users@sun-lamp.cs.berkeley.edu, explorer@vorpal.com Subject: Re: kerberos? <199407162142.XAA00806@gandalf.bbb.no> From: "Michael Graff" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Including integration with all the pertaining user-space stuff? I mailed in patches for rlogin, rsh, rlogind, rshd, passwd, etc. I watched as they were dropped because of time considerations, but s/key was added. The Kerberos diffs I sent in should have patched cleanly or near-cleanly. >Including NFS? That is what I have given to core, except for the I never did NFS though. --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 Jul 17 03:15:20 1994 To: "Michael Graff" Cc: bdc@ai.mit.edu (Brian D. Carlstrom), current-users@sun-lamp.cs.berkeley.edu Subject: Re: kerberos? <199407162340.SAA01610@packrat.vorpal.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1113.774402340.1@gandalf.bbb.no> From: Thorsten Lockert Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I mailed in patches for rlogin, rsh, rlogind, rshd, passwd, etc. I watched > as they were dropped because of time considerations, but s/key was added. > The Kerberos diffs I sent in should have patched cleanly or near-cleanly. All my stuff patches cleanly against current as of today as well. I have sent in patches for all but rsh, rlogin, passwd, login and ftp. This because these haven't had the 4.4-Lite versions integrated yet. > >Including NFS? That is what I have given to core, except for the > > I never did NFS though. nfsd and mount_nfs has also been integrated in the patches I've made. And the rest of user-land will be integrated as soon as 4.4-Lite is put into the tree for those utilities. 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 Sun Jul 17 12:21:14 1994 Subject: Problems with configure scripts To: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 441 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello, I tried to use the configure script of elm2.4pl24, but the script wants to know some details and should wait for the return, but it decieded to insert the return so I can not make some changes. Oh and the script didn't found /usr/local/bin, why that ? I have this dir. I use the snapshot from 950709 on an A4000/040 with the tcsh and an link from bash to sh (I tried it also with the normal sh, but the same problem appears) Bernd From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 17 14:13: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/sbin/mount_msdos/Makefile U src/sbin/mount_msdos/mount_msdos.8 U src/sbin/mount_msdos/mount_msdos.c U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/dev/atzsc.c U src/sys/arch/i386/conf/BOAT_ANCHOR U src/sys/arch/i386/conf/GENERICAHA U src/sys/arch/i386/conf/GENERICBT U src/sys/arch/i386/conf/KICKME U src/sys/arch/i386/conf/PAIN U src/sys/miscfs/specfs/spec_vnops.c U src/sys/msdosfs/denode.h U src/sys/msdosfs/direntry.h U src/sys/msdosfs/msdosfs_denode.c U src/sys/msdosfs/msdosfs_fat.c U src/sys/msdosfs/msdosfs_lookup.c U src/sys/msdosfs/msdosfs_vfsops.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/msdosfs/msdosfsmount.h U src/sys/nfs/nfs_boot.c U src/usr.sbin/ypbind/ypbind.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun Jul 17 03:36:32 1994 SUP Scan for current completed at Sun Jul 17 03:38:55 1994 SUP Scan for mirror starting at Sun Jul 17 03:38:55 1994 SUP Scan for mirror completed at Sun Jul 17 03:41:16 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 17 18:33:08 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, dej@eecg.toronto.edu Subject: Re: WWW server Sender: owner-amiga@sun-lamp.cs.berkeley.edu > Is there a NetBSD/Amiga Web server out there? If not, then I may be Try http://dusk.rz.uni-regensburg.de/. This is a A2000 running NetBSD, and there's also a section on NetBSD on this machine. 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 Jul 17 22:57:50 1994 Subject: From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could someone test this and tell me whether or not it works? I don't have a PS/2 mouse. You should tell XFree86 that it's a Logitech mouse. The idea is that all the mouse drivers are supposed to export the same interface. Also, make sure the minor device number for /dev/pms0 is 0, not 1. The old device numbering was because the person who originally implemented non-blocking I/O didn't know about IO_NDELAY. -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- /*- * Copyright (c) 1994 Charles Hannum. * Copyright (c) 1992, 1993 Erik Forsberg. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * * THIS SOFTWARE IS PROVIDED BY ``AS IS'' AND ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN * NO EVENT SHALL I BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR * PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * * $Id: pms.c,v 1.9 1993/12/20 09:06:39 mycroft Exp $ */ /* * XXXX * This is a hack. This driver should really be combined with the * keyboard driver, since they go through the same buffer and use the * same I/O ports. Frobbing the mouse and keyboard at the same time * may result in dropped characters and/or corrupted mouse events. */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define PMS_DATA 0 /* offset for data port, read-write */ #define PMS_CNTRL 4 /* offset for control port, write-only */ #define PMS_STATUS 4 /* offset for status port, read-only */ /* status bits */ #define PMS_OBUF_FULL 0x01 #define PMS_IBUF_FULL 0x02 /* controller commands */ #define PMS_INT_ENABLE 0x47 /* enable controller interrupts */ #define PMS_INT_DISABLE 0x65 /* disable controller interrupts */ #define PMS_AUX_ENABLE 0xa7 /* enable auxiliary port */ #define PMS_AUX_DISABLE 0xa8 /* disable auxiliary port */ #define PMS_MAGIC_1 0xa9 /* XXX */ #define PMS_MAGIC_2 0xaa /* XXX */ #define PMS_8042_CMD 0x65 /* mouse commands */ #define PMS_SET_SCALE11 0xe6 /* set scaling 1:1 */ #define PMS_SET_SCALE21 0xe7 /* set scaling 2:1 */ #define PMS_SET_RES 0xe8 /* set resolution */ #define PMS_GET_SCALE 0xe9 /* get scaling factor */ #define PMS_SET_STREAM 0xea /* set streaming mode */ #define PMS_SET_SAMPLE 0xf3 /* set sampling rate */ #define PMS_DEV_ENABLE 0xf4 /* mouse on */ #define PMS_DEV_DISABLE 0xf5 /* mouse off */ #define PMS_RESET 0xff /* reset */ #define PMS_CHUNK 128 /* chunk size for read */ #define PMS_BSIZE 1020 /* buffer size */ struct pms_softc { /* driver status information */ struct device sc_dev; struct intrhand sc_ih; struct clist sc_q; struct selinfo sc_rsel; u_short sc_iobase; /* I/O port base */ u_char sc_state; /* mouse driver state */ #define PMS_OPEN 0x01 /* device is open */ #define PMS_ASLP 0x02 /* waiting for mouse data */ u_char sc_status; /* mouse button status */ int sc_x, sc_y; /* accumulated motion in the X,Y axis */ }; int pmsprobe(); void pmsattach(); int pmsintr __P((struct pms_softc *)); struct cfdriver pmscd = {\ NULL, "pms", pmsprobe, pmsattach, DV_TTY, sizeof(struct pms_softc) }; #define PMSUNIT(dev) (minor(dev)) static inline void pms_flush(int ioport) { u_char c; while (c = inb(ioport+PMS_STATUS) & 0x03) if ((c & PMS_OBUF_FULL) == PMS_OBUF_FULL) { /* XXX - delay is needed to prevent some keyboards from wedging when the system boots */ delay(6); (void) inb(ioport+PMS_DATA); } } static inline void pms_dev_cmd(int ioport, u_char value) { pms_flush(ioport); outb(ioport+PMS_CNTRL, 0xd4); pms_flush(ioport); outb(ioport+PMS_DATA, value); } static inline void pms_aux_cmd(int ioport, u_char value) { pms_flush(ioport); outb(ioport+PMS_CNTRL, value); } static inline void pms_pit_cmd(int ioport, u_char value) { pms_flush(ioport); outb(ioport+PMS_CNTRL, 0x60); pms_flush(ioport); outb(ioport+PMS_DATA, value); } int pmsprobe(parent, self, aux) struct device *parent, *self; void *aux; { struct isa_attach_args *ia = aux; u_short iobase = ia->ia_iobase,c; pms_dev_cmd(iobase, PMS_RESET); pms_aux_cmd(iobase, PMS_MAGIC_1); pms_aux_cmd(iobase, PMS_MAGIC_2); c = inb(iobase+PMS_DATA); pms_pit_cmd(iobase, PMS_INT_DISABLE); if (c & 0x04) return 0; ia->ia_msize = 0; ia->ia_iosize = 8; return 1; } void pmsattach(parent, self, aux) struct device *parent, *self; void *aux; { struct pms_softc *sc = (void *)self; struct isa_attach_args *ia = aux; u_short iobase = ia->ia_iobase; printf("\n"); /* Save I/O base address. */ sc->sc_iobase = iobase; sc->sc_state = 0; sc->sc_ih.ih_fun = pmsintr; sc->sc_ih.ih_arg = sc; sc->sc_ih.ih_level = IPL_NONE; intr_establish(ia->ia_irq, &sc->sc_ih); } int pmsopen(dev, flag) dev_t dev; int flag; { int unit = PMSUNIT(dev); struct pms_softc *sc; if (unit >= pmscd.cd_ndevs) return ENXIO; sc = pmscd.cd_devs[unit]; if (!sc) return ENXIO; if (sc->sc_state & PMS_OPEN) return EBUSY; if (clalloc(&sc->sc_q, PMS_BSIZE, 0) == -1) return ENOMEM; sc->sc_state |= PMS_OPEN; sc->sc_status = 0; sc->sc_x = sc->sc_y = 0; /* Enable interrupts. */ pms_dev_cmd(sc->sc_iobase, PMS_DEV_ENABLE); pms_aux_cmd(sc->sc_iobase, PMS_AUX_ENABLE); #if 0 pms_dev_cmd(sc->sc_iobase, PMS_SET_RES); pms_dev_cmd(sc->sc_iobase, 3); /* 8 counts/mm */ pms_dev_cmd(sc->sc_iobase, PMS_SET_SCALE21); pms_dev_cmd(sc->sc_iobase, PMS_SET_SAMPLE); pms_dev_cmd(sc->sc_iobase, 100); /* 100 samples/sec */ pms_dev_cmd(sc->sc_iobase, PMS_SET_STREAM); #endif pms_pit_cmd(sc->sc_iobase, PMS_INT_ENABLE); return 0; } int pmsclose(dev, flag) dev_t dev; int flag; { struct pms_softc *sc = pmscd.cd_devs[PMSUNIT(dev)]; /* Disable interrupts. */ pms_pit_cmd(sc->sc_iobase, PMS_INT_DISABLE); pms_aux_cmd(sc->sc_iobase, PMS_AUX_DISABLE); pms_dev_cmd(sc->sc_iobase, PMS_DEV_DISABLE); sc->sc_state &= ~PMS_OPEN; clfree(&sc->sc_q); return 0; } int pmsread(dev, uio, flag) dev_t dev; struct uio *uio; int flag; { struct pms_softc *sc = pmscd.cd_devs[PMSUNIT(dev)]; int s; int error; size_t length; u_char buffer[PMS_CHUNK]; /* Block until mouse activity occured. */ s = spltty(); while (sc->sc_q.c_cc == 0) { if (flag & IO_NDELAY) { splx(s); return EWOULDBLOCK; } sc->sc_state |= PMS_ASLP; if (error = tsleep((caddr_t)sc, PZERO | PCATCH, "pmsrea", 0)) { sc->sc_state &= ~PMS_ASLP; splx(s); return error; } } splx(s); /* Transfer as many chunks as possible. */ while (sc->sc_q.c_cc > 0 && uio->uio_resid > 0) { length = min(sc->sc_q.c_cc, uio->uio_resid); if (length > sizeof(buffer)) length = sizeof(buffer); /* Remove a small chunk from input queue. */ (void) q_to_b(&sc->sc_q, buffer, length); /* Copy data to user process. */ if (error = uiomove(buffer, length, uio)) break; } return error; } int pmsioctl(dev, cmd, addr, flag) dev_t dev; int cmd; caddr_t addr; int flag; { struct pms_softc *sc = pmscd.cd_devs[PMSUNIT(dev)]; struct mouseinfo info; int s; int error; switch (cmd) { case MOUSEIOCREAD: s = spltty(); info.status = sc->sc_status; if (sc->sc_x || sc->sc_y) info.status |= MOVEMENT; if (sc->sc_x > 127) info.xmotion = 127; else if (sc->sc_x < -127) /* Bounding at -127 avoids a bug in XFree86. */ info.xmotion = -127; else info.xmotion = sc->sc_x; if (sc->sc_y > 127) info.ymotion = 127; else if (sc->sc_y < -128) info.ymotion = -128; else info.ymotion = sc->sc_y; /* Reset historical information. */ sc->sc_x = sc->sc_y = 0; sc->sc_status &= ~BUTCHNGMASK; ndflush(&sc->sc_q, sc->sc_q.c_cc); splx(s); error = copyout(&info, addr, sizeof(struct mouseinfo)); break; default: error = EINVAL; break; } return error; } /* Masks for the first byte of a packet */ #define PS2LBUTMASK 0x01 #define PS2RBUTMASK 0x02 #define PS2MBUTMASK 0x04 int pmsintr(sc) struct pms_softc *sc; { u_short iobase = sc->sc_iobase; static int state = 0; u_char buttons, changed; char dx, dy; static u_char buffer[5]; if ((sc->sc_state & PMS_OPEN) == 0) /* Interrupts are not expected. */ return 0; switch (state) { case 0: buffer[0] = inb(iobase + PMS_DATA); if ((buffer[0] & 0xc0) == 0) ++state; break; case 1: buffer[1] = inb(iobase + PMS_DATA); ++state; break; case 2: buffer[2] = inb(iobase + PMS_DATA); state = 0; dx = (buffer[0] & 0x10) ? buffer[1]-256 : buffer[1]; /* Bounding at -127 avoids a bug in XFree86. */ dx = (dx == -128) ? -127 : dx; dy = (buffer[0] & 0x20) ? buffer[2]-256 : buffer[2]; dy = (dy == -128) ? 127 : -dy; buttons = ~(((buffer[0] & PS2LBUTMASK) << 2) | ((buffer[0] & (PS2RBUTMASK | PS2MBUTMASK)) >> 1)); changed = ((buttons ^ sc->sc_status) & BUTSTATMASK) << 3; sc->sc_status = buttons | (sc->sc_status & ~BUTSTATMASK) | changed; if (dx || dy || changed) { /* Update accumulated movements. */ sc->sc_x += dx; sc->sc_y += dy; /* Add this event to the queue. */ buffer[0] = 0x80 | (buttons ^ BUTSTATMASK); buffer[1] = dx; buffer[2] = dy; buffer[3] = buffer[4] = 0; (void) b_to_q(buffer, sizeof buffer, &sc->sc_q); if (sc->sc_state & PMS_ASLP) { sc->sc_state &= ~PMS_ASLP; wakeup((caddr_t)sc); } selwakeup(&sc->sc_rsel); } break; } return -1; } int pmsselect(dev, rw, p) dev_t dev; int rw; struct proc *p; { struct pms_softc *sc = pmscd.cd_devs[PMSUNIT(dev)]; int s; int ret; if (rw == FWRITE) return 0; s = spltty(); if (!sc->sc_q.c_cc) { selrecord(p, &sc->sc_rsel); ret = 0; } else ret = 1; splx(s); return ret; } -----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<----- From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 00:24:12 1994 From: Dave Burgess Subject: Midwest NetBSD Users Group Barbeque To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 364 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, Now that we actually have a half dozen (more or less) Midwestern NetBSD users, how would you all like to come out to Eastern Nebraska for a BBQ? My place, burgers, hot dogs, soda, etc... Wives and kids are expected. I am looking towards the last week-end in August (the one before Labor Day; I will be out of town LD). Drop me a line and let me know. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 18 00:38:06 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: Compiling GCC 2.6.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Has anyone been successful in compiling GCC2.6.0 on the Amiga (running 1.0alpha)? I get the following error: _floatditf __gcc_bcmp ./libgcc2.c: In function `__gcc_bcmp': ./libgcc2.c:1146: parse error before `size_t' *** Error code 1 But don't seen any error. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 18 01:49:17 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: floppies & a few Q's. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Whomever created the boot floppies, email the installation procedure that you had in mind. I've had 3 people on IRC give up trying to do an install because things were missing, like mount_ados, newfs and disklabel. If you could throw together something quick, I'll add it into my installation doc, otherwise, we need to see if a new set can be burned to ease these poor people's problems. I ended up having them get the rootfs and dcp it. I need education on copying a superblock from a valid partition to a new one, and not have it be the same size as the old partition. Thanks! -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 18 02:53:39 1994 From: "Stephen J. Roznowski" To: billc@iceCuBE.cryogenic.com Subject: Re: floppies & a few Q's. Cc: amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: William J Coldwell > > Whomever created the boot floppies, email the installation procedure that you > had in mind. I've had 3 people on IRC give up trying to do an install > because things were missing, like mount_ados, newfs and disklabel. If you > could throw together something quick, I'll add it into my installation doc, > otherwise, we need to see if a new set can be burned to ease these poor > people's problems. I ended up having them get the rootfs and dcp it. That would be me. I was planning on throwing an installation document together, but never got around to it. Also, as someone pointed out, I forgot newfs on it. Alas, I never attempted to do an install with these, just make sure that they worked..... I'm in the process of building a new set of boot floppies, I'll see what I can squeeze onto them. -SR From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 04:24:20 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: SLIP/PPP problems with May 1 sources From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu I know current is way past me right now. But I thought I'd throw this out as a data point, and see if anyone else had seen this. I'm running sources/binaryes/kernel from roughly April 30 or May 1 (self-built; not the ones on the ftp sites). I just got a dedicated line installed at the university this weekend, and I've had some problems with SLIP and PPP. It seems that if I push the connection too hard, after awhile my machine will hang solid. PPP seems to be a bit more robust, as it dies a lot more often in SLIP, and takes a lot more abuse before hanging under PPP. Since I'm running under X, which is running under pcvt, I can't see if it dropped into the kernel debugger and displayed anything or not. I could try beating on the line hard on vt0 and see if I get dropped into the debugger with an informational message or not, if it needs to be done. But since my stuff is so old, I was just looking more for if anyone had heard of this happening elsewhere. And, if so, if the problem has been addressed. I know my office-mate has been running SLIP with no problems for months, and the machine we're using as the SLIP/PPP router/gateway in the office had an uptime of 73 days before we rebooted it to install a new kernel and update binaries, and a new serial board. So, I'm sure this is an isolated problem. I'd just appreciate it if anyone could tell me for sure this doesn't happen in current current, and if this was a known problem in the vintage source I'm running, what the problem/fix was. As I write this, I'm downloading current binaries. Next I'll get the latest source and I'll see if I can get my system updated successfully. Incidenatally, I had 32 days of solid uptime before these SLIP/PPP hangs, running term through the same serial port almost the entire time, so I know it's not my system in general. Thanks for any feedback. ----------------------------------------------------------------------------- Michael L. VanLoon Iowa State University Computation Center michaelv@iastate.edu Project Vincent Systems Staff Free your mind and your machine -- NetBSD free Un*x for PC/Mac/Amiga/etc. ----------------------------------------------------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 18 05:26:15 1994 From: garion@mermaid.micro.umn.edu (Ron Roskens) Subject: Re: Compiling GCC 2.6.0 To: amiga@sun-lamp.cs.berkeley.edu Cc: sjr@zombie.ncsc.mil X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 530 Sender: owner-amiga@sun-lamp.cs.berkeley.edu >From the reaches of cyberspace, Stephen J. Roznowski wrote: > Has anyone been successful in compiling GCC2.6.0 on the > Amiga (running 1.0alpha)? I get the following error: > > _floatditf > __gcc_bcmp > ./libgcc2.c: In function `__gcc_bcmp': > ./libgcc2.c:1146: parse error before `size_t' > *** Error code 1 Running the same setup. It apparently is not finding size_t. If you change it to unsigned int which size_t is it works then... I'm gonna check into this more tomorrow afternoon. After I get done with work... Ron From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 11:22:10 1994 From: "Per A. Amundsen" To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree exits. Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have just upgraded to current with gcd's latest binaries and sys-sources supped on July 11. Everythings seems to work, except that Xfree.2.0 (xinit) immediately exits with: XIO: fatal IO error 32 (Broken pipe) on server 0:0 after 0 requests ... It did work for a while during installation with the new GENERICAHA kernel and binaries till about the time I did a 'MAKEDEV all'. The old trick of linking /dev/console to /dev/vga doesn't seem to work any more, neither does compiling a kernel with securitylevel = -1. My Xfree is the binary 2.0-distribution from grasp.insa-lyon.fr from about February 11. Has anyone an idea what I may have overlooked? By the way, I am a happy NetBSD user for more than a year now. Keep up the good work! Per A. -- Per Amund Amundsen Email: per-am@hsr.no Institutt for matematikk og naturvitenskap amundsen@hsr.no HSR, P.O.Box 2557 Ullandhaug Tlf.: (+47) 51874477 N-4004 Stavanger, Norway Fax: (+47) 51874300 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 12:56:23 1994 From: matthieu@laas.fr (Matthieu Herrb) To: "Per A. Amundsen" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: XFree exits. X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 682 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Mon 18) > > I have just upgraded to current with gcd's latest binaries and sys-sources > supped on July 11. Everythings seems to work, except that Xfree.2.0 > (xinit) immediately exits with: > > XIO: fatal IO error 32 (Broken pipe) on server 0:0 after 0 requests ... > Since XFree86 looses some console messages that are printed immediatly after startup, please run: xinit >& xinit.log to get full error messages when you get an error. I think that looking at xinit.log after that should point you to the right direction of your problem. Matthieu [A side note to Dave Burgess: could you include this topic in the FAQ ?] From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 13:45:18 1994 From: "Per A. Amundsen" To: Matthieu.Herrb@laas.fr Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree exits. Sender: owner-current-users@sun-lamp.cs.berkeley.edu matthieu@laas.fr (Matthieu Herrb) wrote > > You wrote (in your message from Mon 18) > > [ X exits ] > > Since XFree86 looses some console messages that are printed immediatly > after startup, please run: > > xinit >& xinit.log > > to get full error messages when you get an error. I think that looking > at xinit.log after that should point you to the right direction of > your problem. > > > Matthieu > > > [A side note to Dave Burgess: could you include this topic in the FAQ > ?] > Thanks. I immediately learned that I had lost my mouse (/dev/com0) due to the new (and improved) naming scheme for the devices. By the way, the text in MAKEDEV still indicates that it is possible to make /dev/com* devices, but mknod refuses. Of course, symbolic links works |-). Also thanks to bdc@ai.mit.edu (Brian D. Carlstrom) and Michael Graff I will upgarde to 2.1.1 , but at least with securitylevel = -1 XFree 2.0 works. -- Per Amund Amundsen Email: per-am@hsr.no Institutt for matematikk og naturvitenskap amundsen@hsr.no HSR, P.O.Box 2557 Ullandhaug Tlf.: (+47) 51874477 N-4004 Stavanger, Norway Fax: (+47) 51874300 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 16:01:04 1994 From: Charlie Root To: source@sun-lamp.cs.berkeley.edu Subject: daily CVS update output Sender: owner-current-users@sun-lamp.cs.berkeley.edu Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/etc/etc.i386/MAKEDEV U src/etc/etc.i386/Makefile.kc U src/sys/arch/amiga/amiga/machdep.c U src/sys/arch/amiga/conf/GENERIC U src/sys/arch/amiga/dev/fd.c U src/sys/arch/amiga/dev/siop.c U src/sys/arch/hp300/conf/GENERIC U src/sys/arch/hp300/conf/LINT U src/sys/arch/hp300/conf/Makefile.hp300 U src/sys/arch/hp300/stand/Makefile U src/sys/arch/i386/Makefile U src/sys/arch/i386/isa/pms.c U src/sys/isofs/cd9660/cd9660_vnops.c U src/sys/kern/init_main.c U src/sys/kern/tty_subr.c U src/usr.bin/find/find.1 U src/usr.bin/find/find.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Jul 18 04:00:52 1994 SUP Scan for current completed at Mon Jul 18 04:03:27 1994 SUP Scan for mirror starting at Mon Jul 18 04:03:28 1994 SUP Scan for mirror completed at Mon Jul 18 04:06:01 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 16:41:43 1994 Subject: From: Duncan McEwan To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu <9407171915.AA21772@goldman.gnu.ai.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Could someone test this and tell me whether or not it works? I don't > have a PS/2 mouse. > It's not quite right yet. As posted, the driver always locks up my keyboard when a process reading from /dev/pms0 exits (on two different PC's with different keyboards). I noticed a difference between this new driver and the one from Shoji Yuen that I've been using up til now is that in the pmsclose routine the order the various pms_*_cmd routines were called is different. By reverting to the order used by Shoji, that problem went away. Ie, the code in pmsclose now looks like: /* Disable interrupts. */ pms_dev_cmd(sc->sc_iobase, PMS_DEV_DISABLE); pms_pit_cmd(sc->sc_iobase, PMS_INT_DISABLE); pms_aux_cmd(sc->sc_iobase, PMS_AUX_DISABLE); Unfortunately, I still can't make it work under X (v2.1.1), specifying both "busmouse" and "logitech". The mouse just doesn't move at all. Interestingly, doing a "cat -u -v /dev/pms0" seems to show the correct byte sequences are being generated (certainly different from the sequences generated by Shoji's driver, and they seem to match with what the lms driver produces). If no one else solves this before tomorrow (my time!) I'll dig a little deeper, but it's late now, and I've got to build an X server binary with debugging before I can see what's going on... Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 16:55:39 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: X11R6,i386 Makefile probs. To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 1181 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've just been messing with X11R6 to try and get it to compile under NetBSD-current, anyway it's failing at the point of making a main Makefile. It seems to be including tabs in front of variable declarations due to there being a tab in the Imake.rules line which ConCat's the variable lines together (about line 1092). It also is not replacing the XCOMMS with pounds i.e. CppSedMagic isn't used. It seems to create a functioning Makefile and then in the Area after line 650 where makedepend is supposed to being messing about it includes the complete Imakefile plus empty lines etc. again thus there are two make-labels all the time. If one corrects the main-Makefile and calls up 'make Makefiles' it just ruins the others instead. It doesn't seem to work with either gnumake nor bsdmake. Did it actually work with the old NetBSD 0.9 ? Have you got a hint as to what it might be ? Do you need more information to solve it ? Thx in advance. Cheerio -- The cost of living hasn't affected it's popularity. (unknown) current release=doc host=wipux2.wifo.uni-mannheim.de hostbase=/src base=/usr \ prefix=/usr backup delete use-rel-suffix ; updated midday MET NetBSD-current From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 17:34:25 1994 From: kim@dde.dk (Kim Andersen) Subject: Re: X11R6,i386 Makefile probs. To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) 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've just been messing with X11R6 to try and get it to compile under > NetBSD-current, anyway it's failing at the point of making a main > Makefile. > Disclaimer: I've only done minimal work on getting X11R6 to compile on NetBSD-current. You need to add a cast to ftruncate in config/imake/imake.c . This problem also existed in X11R5's imake. regards kim From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 18:58:36 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: ftpd/Makefile Sender: owner-current-users@sun-lamp.cs.berkeley.edu The .if defined(KERBEROS) conditional needs SRCS+= klogin.c added to make it go with Kerberos. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 18 19:50:25 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "newfs fault" (Jul 16, 8:28pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Matthew Aldous , amiga@sun-lamp.cs.berkeley.edu Subject: Re: newfs fault Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 16, 8:28pm, Matthew Aldous wrote: > "newfs: ioctl(WDINFO): Invalid argument." Nothing serious. NetBSD-Amiga doesn't support disklabel yet. That's what the RDB is for. Another reminder for the FAQ should be, that BFFS for ADOS doesn't work with the most recent ROOTFS snapshot due to changements in the ufs-code. Needs to be updated. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 18 20:42:38 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: status Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Are there any Amiga specific bugs that must be handled before 1.0 Beta? My understanding is that they must have to deal with : kernel compilation, kernel crashes and hangs, and machine-dependent release-preparation stuff. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 21:55:09 1994 From: toor@wipux2.wifo.uni-mannheim.de (Peppermint Lucy) Subject: maxcontig for newfs To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 524 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Reading tunefs.8 as directed to do so from newfs it says that the parameter '-a maxcontig' can be set to the amount of chained buffers that the driver can do in a single transfer. What is the maximum chain length for the - wd - sd drivers ? Is anybody using this parameter ? Cheerio -- Bankers do it with interest (penalty for early withdrawal). Intelligence is the capability of receiving, decrypting information and then transferring it in usable form. Stupidity is the interuption of this process at any given point. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 18 22:21:37 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: status Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9407181733.AA01501@icecube.cryogenic.com> billc@iceCuBE.cryogenic.com writes: > Are there any Amiga specific bugs that must be handled before 1.0 Beta? My > understanding is that they must have to deal with : kernel compilation, > kernel crashes and hangs, and machine-dependent release-preparation stuff. I just found a nasty bug... reading the character special device for a cdrom hangs my system with the famous old "dmanext at end!" message, which has otherwise disapeared. I have the new SuperDMAC (-04 I think), which seems to be the trigger for the problem. I don't grok the sbic code enough to be able to track it down myself :-( Also, I suggest the "dmanext at end!" message be converted to a panic. It's invariably fatal anyway, and at least having the system panic allows for automated reboots instead of hangs, or for debugging with DDB if it's enabled. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 18 22:24:00 1994 From: Hubert Feyrer To: amiga-dev@sun-lamp.cs.berkeley.edu, billc@iceCuBE.cryogenic.com Subject: re: status Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > Are there any Amiga specific bugs that must be handled before 1.0 Beta? My > understanding is that they must have to deal with : kernel compilation, > kernel crashes and hangs, and machine-dependent release-preparation stuff. ^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I hope this includes switching on/off synchronous SCSI-transfers when the bus hangs? This is what usually happens when new kernels probe my bus and detect my two Fujitsu-drives... I've to grab binpatch then and disable (enable???) sync then by hand. Not very nice! :-( 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 Jul 18 22:44:41 1994 From: rhealey@aggregate.com Subject: Testing executables across all m68k ports 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: 453 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm curious: Since the m68k port has 4 implementations, hp300, Amiga, Mac and Sun 3, has anybody checked to see if executables created on one will work on the other 3? That would be quite a feather in the NetBSD cap if it really does work! Especially if things like X clients could be swapped back and forth! In theory all executables except X servers should be exchangable between the above 4 implementations yes? Just wondering, -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 22:59:18 1994 To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Testing executables across all m68k ports From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Mon, 18 Jul 1994 11:57:50 -0500 (CDT) rhealey@aggregate.com wrote: > Since the m68k port has 4 implementations, hp300, Amiga, Mac and Sun 3, > has anybody checked to see if executables created on one will work > on the other 3? A binary compiled on an hp300 will not run on an amiga and vice-versa... ./more: Exec format error. Wrong Architecture. Amiga binary: ./more: NetBSD/m68k demand paged dynamically linked executable hp300 binary: /usr/bin/more: NetBSD/m68k4k demand paged dynamically linked executable I do know that hp300 binaries will run on the sun3 (same type), considering how we compiled a kernel for a sun3 on an hp300 and it worked...:-) Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 23:43:52 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Testing executables across all m68k ports Sender: owner-current-users@sun-lamp.cs.berkeley.edu > From: rhealey@aggregate.com > Date: Mon, 18 Jul 1994 11:57:50 -0500 (CDT) > I'm curious: > > Since the m68k port has 4 implementations, hp300, Amiga, Mac and Sun 3, > has anybody checked to see if executables created on one will work > on the other 3? Yes to some extent. Amiga and Sun3 (and Mac68k?) are m68k8k (8k page size) and hp300 is m68k4k (4k page size). The Sun3 runs Amiga binaries very nicely. Thanks to Chris Hopps, I don't have to build many Sun3 user programs. Nice eh? > That would be quite a feather in the NetBSD cap if it really does > work! Especially if things like X clients could be swapped back > and forth! In theory all executables except X servers should be > exchangable between the above 4 implementations yes? > > Just wondering, I too have wondered: would m68k4k executables work on an m68k8k arch? And the other way too? What would break? (maybe mmap code?) Theoretically, things that call pagesize() instead of hard-coding it should be able to run on machines with varying page sizes (like SunOS). Gordon Ross From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 18 23:53:15 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: MAP_FILE in /usr/include/sys/mman.h To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 382 Sender: owner-current-users@sun-lamp.cs.berkeley.edu MAP_FILE is mentioned in the comment for the definition of MAP_NOEXTEND, but MAP_FILE itself is never defined. What is the correct value for MAP_FILE ? Cheerio -- The cost of living hasn't affected it's popularity. (unknown) current release=doc host=wipux2.wifo.uni-mannheim.de hostbase=/src base=/usr \ prefix=/usr backup delete use-rel-suffix ; updated midday MET NetBSD-current From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:02:18 1994 From: Paul Kranenburg To: rhealey@aggregate.com, gwr@mc.com Subject: Re: Testing executables across all m68k ports Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I too have wondered: would m68k4k executables work on an m68k8k arch? > And the other way too? What would break? (maybe mmap code?) > Given the hardware demands on page size, you'll have trouble mapping most 4k executables on 8k hardware. The other way round should be fine. > Theoretically, things that call pagesize() instead of hard-coding it > should be able to run on machines with varying page sizes (like SunOS). > Historically (read: Sun's strategy) all sparc executables are based on 8k page sizes, although most models have a 4k (hardware) page size. This is still the case in the NetBSD sparc port, although we don't even have a port for an 8k sun4. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 19 00:02:19 1994 From: Matthew Aldous Subject: Gollies, a long one. To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL0] Sender: owner-amiga@sun-lamp.cs.berkeley.edu Woop woop. I now have X running on my amiga. (thanks guys!), and was wondering if there were any color servers that will run under ECS. I'm using Xmono at the moment... Also, someone who was logged into the machine whilst compmiling said they saw that gcc was building 68020 binaries.. This was building term2.0.0 - and it autodetected everything itself.. Do Netbsdian amigans prefer binaries to be sent anywhere? Also, on ftp.uni-regensburg.de , the X fonts are in the OLD directory.. A tad confusing for a newbie.. :) Also, below are some hassles/faults I've had with the 940709 bin-dist from ftp.uni-regensburg.de o xload uses /vmunix (not /netbsd) o newfs: ioctl (WDINFO) : Invalid arg o 68k types.h has "long long" (ANSI?) o "panic: pmap_remove: PA not in pv_tab" o ps cpu% mem% listing are nearly always 0, or -0 o savecore: can't find device 0/6 o swap_pager_io: wait on swbuf for ... (lots) o netstat: kvm_read kvm_read: Bad address o pstat: panic: nswapmap goof o /netbsd: ser0: silo overflow o /netbsd: Connot set battery backed clock Is there an easy way to ask it to boot in PAL, instead of NTSC? What's the biggest, most severe overscan I can do with iteconfig ? On booting, it says "2 mice configured, 10 views configured." are there virtual consoles? How does one change between them? Is there a system info dump hotkey combinations (ala linux), to show mem/processes, etc? My trackball's 3rd button is a "hold" button. Who should be nudged to impliment hpux/linux "both" buttons to emulate a 3rd button? *phew* Thanks heaps. Oh , a litte more.. I'm about to buy a biggish drive, and a few cdroms (tax time is lurvely) - is there anything I should look out for with the cdroms, or the disk formats? What is/isn't supported ? Ta muchly. (Is someone keeping a list of Amiga NetBSD machines on the net? elegia.apana.org.au 192.188.107.92 will be alive soon, when I get my routing working..) woop woop. ltr. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:02:37 1994 To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Testing executables across all m68k ports <9407181657.AA11387@sirius.aggregate.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Since the m68k port has 4 implementations, hp300, Amiga, Mac and Sun 3, > has anybody checked to see if executables created on one will work > on the other 3? (don't forget the da30! 8-) with the possible exception of the hp300, they should all be "mostly interoperable." I.e. all binaries that aren't kernel-dependent should be OK. I've personally used i think it was amiga binaries on the mac, and believe the sun3's being worked on, with an amiga binary set... > That would be quite a feather in the NetBSD cap if it really does > work! It does. It's just a matter of getting things set up so that they share them, "in real life." Part of that is determining what the machine dependent binaries are. I'm working on something related (but not closely) now, for the release. > Especially if things like X clients could be swapped back > and forth! In theory it should work. if other binaries do (and they do) there's no reason X clients shouldn't. > In theory all executables except X servers should be > exchangable between the above 4 implementations yes? with the exception of things that deal with machine-specific features -- there are a few for each architecture, and i'm honestly not sure if programs that use the kvm lib will work. chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:16:18 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: SLIP/PPP problems with May 1 sources <9407180028.AA00522@ponderous.cc.iastate.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu "Michael L. VanLoon -- Iowa State University" writes: > I'm running sources/binaryes/kernel from roughly April 30 or May 1 > (self-built; not the ones on the ftp sites). I just got a dedicated > line installed at the university this weekend, and I've had some > problems with SLIP and PPP. It seems that if I push the connection > too hard, after awhile my machine will hang solid. [...] I also experienced some SLIP hang problems around then, but the problem has gone away, at least for me. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:20:20 1994 To: Paul Kranenburg Cc: rhealey@aggregate.com, gwr@mc.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Testing executables across all m68k ports <9407181942.AA00274@neon.cs.few.eur.nl> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Historically (read: Sun's strategy) all sparc executables are based on 8k > page sizes, although most models have a 4k (hardware) page size. This is > still the case in the NetBSD sparc port, although we don't even have a > port for an 8k sun4. The mac68k and da30 ports do the same thing: NBPG is 4096, but __LDPGSZ is 8192. The kernel's pagesize needs to be <= the userland pagesize. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:31:58 1994 To: rhealey@aggregate.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Testing executables across all m68k ports <9407181657.AA11387@sirius.aggregate.com> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Since the m68k port has 4 implementations, hp300, Amiga, Mac and Sun 3, 5: hp300, amiga, mac, sun3, da30. > has anybody checked to see if executables created on one will work > on the other 3? except for the hp300 (which uses a 4K linker pagesize), they do. In fact, the sun3 port at the moment is using amiga-compiled binaries. the only difficulty comes from the kvm library; it is different for all architectures at the moment. > That would be quite a feather in the NetBSD cap if it really does > work! Especially if things like X clients could be swapped back > and forth! In theory all executables except X servers should be > exchangable between the above 4 implementations yes? While the clients are usable, it is probably not worth it adding support for all the different X device drivers to one server that runs everywhere. There's some wide variation in frame buffers. @sun-lamp.cs.berkeley.edu Precedence: bulk Suicide, Accident or Homicide? - A Forensic Puzzle For those of you who were unable to attend the Awards Dinner during the Annual Meeting in San Diego, you missed a tall tale on complex forensics presented by AAFS President Don Harper Mills in his opening remarks. The following is a recount of Dr. Mills' story... "On March 23 the medical examiner viewed the body of Ronald Opus and concluded that he died from a gunshot wound of the head caused by a shotgun. Investigation to that point had revealed that the decedent had jumped from the top of a ten story building with the intent to commit suicide (he left a note indicating his despondency). As he passed the 9th floor on the way down, his life was interrupted by a shotgun blast through a window, killing him instantly. Neither the shooter nor the decedent was aware that a safety net had been erected at the 8th floor level to protect some window washers and that the decedent would not have been able to complete his intent to commit suicide because of this. Ordinarily, a person who starts into motion the events with a suicide intent ultimately commits suicide even though the mechanism might be not what he intended. That he was shot on the way to certain death nine stories below probably would not change his mode of death from suicide to homicide. But the fact that his suicide intent would not have been achieved under any circumstance caused the medical examiner to feel that he had homicide on his hands. Further investigation led to the discovery that the room on the 9th floor from whence the shotgun blast emanated was occupied by an elderly man and his wife. He was threatening her with the shotgun because of an interspousal spat and became so upset that he could not hold the shotgun straight. Therefore, when he pulled the trigger, he completely missed his wife and the pellets went through the window striking the decedent. When one intends to kill subject A, but kills subject B in the attempt, one is guilty of the murder of subject B. The old man was confronted with this conclusion, but both he and his wife were adamant in stating that neither knew that the shotgun was loaded. It was the longtime habit of the old man to threaten his wife with an unloaded shotgun. He had no intent to murder her; therefore, the killing of the decedent appeared then to be accident. That is, the gun had been accidentally loaded. But *further* investigation turned up a witness that their son was seen loading the shotgun approximately six weeks prior to the fatal accident. That investigation showed that the mother (the old lady) had cut off her son's financial support and her son, knowing the propensity of his father to use the shotgun threateningly, loaded the gun with the expectation that the father would shoot his mother. The case now becomes one of murder on the part of the son for the death of Ronald Opus. Further investigation revealed that the son became increasingly despondent over the failure of his attempt to get his mother murdered. This led him to jump off the ten story building on March 23, only to be killed by a shotgun blast through a 9th story window. The medical examiner closed the case as a suicide." ------- End of Forwarded Message From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:33:45 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Per A. Amundsen" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: XFree exits. <199407180659.AA09467@johanna6.hsr.no> Sender: owner-current-users@sun-lamp.cs.berkeley.edu "Per A. Amundsen" writes: > I have just upgraded to current with gcd's latest binaries and sys-sources > supped on July 11. Everythings seems to work, except that Xfree.2.0 > (xinit) immediately exits with: > [...] > The old trick of linking > /dev/console to /dev/vga doesn't seem to work any more, neither does compilin > g > a kernel with securitylevel = -1. First of all, it's possible that binaries made for current in February will no longer work, although I'm really not sure. Second, you shouldn't link /dev/console to /dev/vga. Instead, modify your /etc/ttys so that the getty runs on vga instead of console. Here are the relevant lines: console "/usr/libexec/getty Pc" pc3 off secure vga "/usr/libexec/getty Pc" pc3 on secure Also, make sure that the console and vga nodes are correct: crw------- 1 root tty 0, 0 Jul 18 16:01 /dev/console crw------- 1 root tty 12, 0 Jul 18 16:01 /dev/vga Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 00:37:27 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: X11R6,i386 Makefile probs. <199407181227.OAA09133@wipux2.wifo.uni-mannheim.de> Sender: owner-current-users@sun-lamp.cs.berkeley.edu andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) writes: > I've just been messing with X11R6 to try and get it to compile under > NetBSD-current, anyway it's failing at the point of making a main > Makefile. The version of XFree86 that comes with X11R6 is pretty useless, since many of our patches weren't integrated in time for release. I don't encourage you to try to fix it -- Even if you can get everything running, the servers are slow and unstable. Until XFree86 3.1 is released, I strongly recommend sticking with R5. That being said, you can fix the current problem you're having by changing: ftruncate(fileno(tmpfd), 0); to: ftruncate(fileno(tmpfd), (off_t)0); in xc/config/imake/imake.c. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 01:06:58 1994 To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: MAP_FILE in /usr/include/sys/mman.h <199407181937.VAA07767@wipux2.wifo.uni-mannheim.de> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > MAP_FILE is mentioned in the comment for the definition of > MAP_NOEXTEND, but MAP_FILE itself is never defined. > What is the correct value for MAP_FILE ? MAP_FILE shouldn't be used; it's been deprecated. mmap() now considers things files, unless specified otherwise. chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 02:18:35 1994 To: Jason Thorpe Cc: rhealey@aggregate.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Testing executables across all m68k ports <9407181832.AA15437@research.CS.ORST.EDU> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I do know that hp300 binaries will run on the sun3 (same type), I don't believe you. > considering how we compiled a kernel for a sun3 on an hp300 and it > worked...:-) If it did work, that would only tell you things about the Sun bootblocks. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 04:53:55 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, billc@iceCuBE.cryogenic.com Subject: Re: status Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: William J Coldwell > > Are there any Amiga specific bugs that must be handled before 1.0 Beta? My > understanding is that they must have to deal with : kernel compilation, > kernel crashes and hangs, and machine-dependent release-preparation stuff. I've noticed (while attempting to build boot floppies) that the machine will lock up under heavy floppy load. [This is running 1.0ALPHA] -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 05:27:32 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: 80 column console Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I seem to remember that someone has posted some patches to ite_cc.c(?) that recalculated "boldsmear" and a couple of other values to allow for an 80 column console (vice 79 characters). Are there plans to get these mods into the current distribution? Thanks, -SR From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 06:49:38 1994 From: chopps@emunix.emich.edu To: "Stephen J. Roznowski" Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: 80 column console <199407190243.WAA12748@zombie.ncsc.mil> X-Mts: smtp Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu No the 80 col. display required overscan which I will not enable fby default. A hack could be done, but I'd rather just let the user iteconfig themseleves Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 07:02:27 1994 From: netbsd@vcsun2.tamu.edu (NetBSD hackers) Subject: multicast & mrouted To: current-users@sun-lamp.cs.berkeley.edu (NETBSD) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 201 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi fellows, I am wondering if someone has done some work on IP multicast extension and mrouted. Just a newbie, could someone point me where to get a FAQ or the source ? thanks, Franklin. From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 19 07:17:06 1994 From: chopps@emunix.emich.edu To: Matthew Aldous Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Gollies, a long one. <199407182103.HAA15168@dynamo.mame.mu.OZ.AU> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu > o xload uses /vmunix (not /netbsd) its outdated. /netbsd is what it should be. > o newfs: ioctl (WDINFO) : Invalid arg not a prob. I can't decide if I want to kill this or not.. The problem is its bogus to let programs think they succeeded when they didn't. In the case of newfs its ok that it failed. > o 68k types.h has "long long" (ANSI?) This is fine. > o "panic: pmap_remove: PA not in pv_tab" > o pstat: panic: nswapmap goof I *really* need more info. These may be serious bugs. those panics, where you tossed into ddb? Can you type `trace' and send the output to me, also can you use dmesg to dump your config and any crash info too? > o swap_pager_io: wait on swbuf for ... (lots) I believe this will be cleared up when I put a new snapshot up (1.0beta) > o ps cpu% mem% listing are nearly always 0, or -0 > o savecore: can't find device 0/6 > o netstat: kvm_read kvm_read: Bad address these are non fatal and are probably caused by out of date binaries. > o /netbsd: ser0: silo overflow > o /netbsd: Connot set battery backed clock standard. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 07:33:49 1994 From: netbsd@vcsun2.tamu.edu (NetBSD hackers) Subject: NetBSD/FreeBSD To: current-users@sun-lamp.cs.berkeley.edu (NETBSD) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 138 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could anyone point me what's the main difference between NetBSD and FreeBSD? Are they aimed to different audiences ? thanks, Franklin. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 08:02:04 1994 From: Andrew Cherry To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: unexpected trap and 7/18 kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I recently (yesterday) sup'ed and compiled the current kernel. Things seem to work up until the kernel recognizes the Z2 boards (my IO-Extender, and the IO-Extender hardware on the G-Force). [Just before where it would normally configure the mice and views]. After this, I repeatedly get unexpected trap (vector offset 2) from 8000 Unfortunately, this happens before I can enter the debugger (i.e. L-Amiga Alt F10 doesn't work). Also, doing loadbsd -SD doesn't work; everything freezes after printing the debugger prompt. My setup is: A2000 G-Force 040, 12MB 32-bit RAM IO-Extender Any idea what is happening here? The next most recent kernel I have was compiled from 7/14/94 sources; it works fine. (oh, both of these kernels are compiled using the GENERIC configuration). Any idea what is happening here? -Andrew Cherry (cherry@mcs.anl.gov) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 08:33:11 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, netbsd@vcsun2.tamu.edu Subject: Re: multicast & mrouted Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am wondering if someone has done some work on IP multicast extension and mrouted. Your question doesn't really make sense. We have both in our source tree, if that's what you mean. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 09:10:52 1994 From: gillham@andrews.edu (Andrew Gillham) Subject: Reverse DNS problems on Internet 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: 1540 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I know this isn't the place to ask this, but our News is down (local problem) and I don't know where else to ask this.. (besides, my NetBSD machine's affected also..) Does anyone know what's the deal with the reverse DNS mapping? Or who to e-mail/call about it? My DNS table shows this: $ORIGIN ARPA. IN-ADDR 544910 IN NS ird.scitex.com. But traceroute/ping says: edmund:~> traceroute ird.scitex.com traceroute to ird.scitex.com (149.115.100.3), 30 hops max, 40 byte packets 1 csh-sgw.andrews.edu (143.207.1.1) 11 ms 18 ms 2 ms 2 au-merit-gw.andrews.edu (143.207.8.2) 3 ms 3 ms 3 ms 3 ser1.wmu.mich.net (35.125.224.1) 469 ms 348 ms 173 ms 4 ser3.michnet1.mich.net (35.127.48.1) 117 ms 38 ms 37 ms 5 fd-0.enss131.t3.ans.net (192.203.195.1) 36 ms !H 36 ms !H 36 ms !H edmund:~> ping ird.scitex.com ICMP Host Unreachable from gateway fd-0.enss131.t3.ans.net (192.203.195.1) for icmp from edmund.cs.andrews.edu (143.207.1.7) to 149.115.100.3 Anyway, it looks like 'ird.scitex.com' is the DNS master for in-addr.arpa. which is kinda crucial for reverse mappings.. :-) It seems to have been down at least since 6:00pm EST. This isn't *that* big of a deal, but it is sure slowing down telnet connections, ftp's to sites that require reverse maps, even Mosaic seems fubar.. If anyone can tell me whats up, where to check on this, who to call, or to shut up and mind my own business, any info would be appreciated! Thanks! And again, I do apologize for posting here, I'm a little desparate... :-( -Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 09:11:49 1994 Subject: From: John Kohl To: duncan@comp.vuw.ac.nz Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu The pms driver generates what appears to be MouseSystems mouse output :) After doing that I ended up with a driver that got the Y direction inverted---this seems strange, but it's a genuine Microsoft mouse so it must be right and the driver must be wrong :) Here are my diffs vs. the one that cgd checked in yesterday (you can ignore the #if 0/#endif around the interrupts if the reordering that Duncan posted makes it work OK). Note that because of the statics in pmsintr, you can't have more than one mouse configured---not that you'd want to, but I made it explicitly give an #error. *** 1.3 1994/07/18 23:31:07 --- pms.c 1994/07/19 01:00:16 *************** *** 20,26 **** * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ! * $Id: pms.c,v 1.3 1994/07/18 23:31:07 jtkohl Exp $ */ /* --- 20,26 ---- * NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. * ! * $Id: pms.c,v 1.4 1994/07/19 01:00:15 jtkohl Exp $ */ /* *************** *** 31,36 **** --- 31,41 ---- * may result in dropped characters and/or corrupted mouse events. */ + #include "pms.h" + #if NPMS > 1 + #error Only one PS/2 style mouse may be configured into your system. + #endif + #include #include #include *************** *** 242,251 **** --- 247,259 ---- { struct pms_softc *sc = pmscd.cd_devs[PMSUNIT(dev)]; + #if 0 /* Disable interrupts. */ + /* disabling interrupts seems to turn off the keyboard too, urk! */ pms_pit_cmd(sc->sc_iobase, PMS_INT_DISABLE); pms_aux_cmd(sc->sc_iobase, PMS_AUX_DISABLE); pms_dev_cmd(sc->sc_iobase, PMS_DEV_DISABLE); + #endif sc->sc_state &= ~PMS_OPEN; *************** *** 369,378 **** static char dx, dy; u_char buffer[5]; ! if ((sc->sc_state & PMS_OPEN) == 0) /* Interrupts are not expected. */ return 0; ! switch (state) { case 0: --- 377,388 ---- static char dx, dy; u_char buffer[5]; ! if ((sc->sc_state & PMS_OPEN) == 0) { /* Interrupts are not expected. */ + /* just discard an input byte */ + (void) inb(iobase + PMS_DATA); return 0; ! } switch (state) { case 0: *************** *** 390,396 **** case 2: dy = inb(iobase + PMS_DATA); ! dy = (dy == -128) ? 127 : -dy; state = 0; buttons = ((buttons & PS2LBUTMASK) << 2) | --- 400,407 ---- case 2: dy = inb(iobase + PMS_DATA); ! /* hmm, seems to give Y inverted? --jtk */ ! dy = (dy == -128) ? -127 : dy; state = 0; buttons = ((buttons & PS2LBUTMASK) << 2) | From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 10:13:41 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: umount error status wrong? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu umount(8) currently exits with status 1 if it was successful unmounting a filesystem. Shouldn't it exit with status 0? ==John =================================================================== RCS file: RCS/umount.c,v retrieving revision 1.1 diff -c -r1.1 umount.c *** 1.1 1994/07/16 20:57:07 --- umount.c 1994/07/16 20:57:00 *************** *** 129,135 **** errs = umountall(); } else for (errs = 0; *argv != NULL; ++argv) ! if (umountfs(*argv) == 0) errs = 1; exit(errs); } --- 129,135 ---- errs = umountall(); } else for (errs = 0; *argv != NULL; ++argv) ! if (umountfs(*argv) != 0) errs = 1; exit(errs); } From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 10:23:29 1994 From: Mail Delivery Subsystem Subject: Returned mail: User unknown To: burgess@s069.infonet.net Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="AAB07090.774596255/s069.infonet.net" Sender: owner-current-users@sun-lamp.cs.berkeley.edu This is a MIME-encapsulated message --AAB07090.774596255/s069.infonet.net The original message was received at Tue, 19 Jul 1994 00:37:34 -0500 from burgess@localhost ----- The following addresses had delivery problems ----- sun-lamp.cs.berkeley.edu (unrecoverable error) ----- Transcript of session follows ----- 550 sun-lamp.cs.berkeley.edu... User unknown ----- Original message follows ----- --AAB07090.774596255/s069.infonet.net Content-Type: message/rfc822 Return-Path: burgess Received: (from burgess@localhost) by s069.infonet.net (8.6.9/8.6.9) id AAA07090 for sun-lamp.cs.berkeley.edu; Tue, 19 Jul 1994 00:37:34 -0500 From: Dave Burgess Message-Id: <199407190537.AAA07090@s069.infonet.net> Subject: AIC6360 driver woes... To: sun-lamp.cs.berkeley.edu Date: Tue, 19 Jul 1994 00:37:30 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1129 Charles etal.... I just thought I'd drop a public line to let everyone know that the AIC6360 driver probes SCSI drives correctly with an Adaptec 1522A controller. That is the only thing that it does right, however. I have just spent the better part of all my off time getting back after the driver corrupted the root dir on my wd0a drive. The symptoms are that whenver an attempt to access one of the SCSI devices on the aic bus is made, the system wedges tight. There is no responce from anything. If you try and read anything from the drives, the root partition inode table gets hosed so bad that fsck will not fix it. Of course, this could all be a coincidence, since the only way to recover from trying to access one of the drives was a hard reset. My sources are current as of Saturday. Charles should be able to test the driver shortly (like by Priority Mail this morning). Good luck and happy hunting. -- TSgt Dave Burgess | Dave Burgess NCOIC, USSTRATCOM/J6844 | *BSD FAQ Maintainer Offutt AFB, NE | Burgess@cynjut.infonet.net or ...@s069.infonet... --AAB07090.774596255/s069.infonet.net-- From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 12:08:45 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: status" (Jul 18, 9:55pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: "Stephen J. Roznowski" , amiga-dev@sun-lamp.cs.berkeley.edu, billc@iceCuBE.cryogenic.com Subject: Re: status Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 18, 9:55pm, "Stephen J. Roznowski" wrote: > I've noticed (while attempting to build boot floppies) that the machine will > lock up under heavy floppy load. [This is running 1.0ALPHA] I encountered the same problems, although i thought it was my mistake. I couldn't umount the floppy several times after a deadlock, means, the floppy didn't stopped to be active even if i didn't accessed it. -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 19 12:50:57 1994 From: mw@eunet.ch Subject: Re: 80 column console To: chopps@emunix.emich.edu Cc: sjr@zombie.ncsc.mil, amiga-dev@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: 1426 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > No the 80 col. display required overscan which I will not enable fby default. > > A hack could be done, but I'd rather just let the user iteconfig themseleves Hm, you do know that the A2024 can do a very limited range of overscan, right? I think 8 or 16 pixels should work, wouldn't that be enough to allow for the 80 character console? BTW: I *am* looking at -current sources:-) Besides a lot of nice (!) cleanup one thing I found to be a step backwards: why did the symbolic definition of product/manufacturer codes disappear? I don't find it particularly elegant to find compares in several device drivers against some obscure absolute numbers.. Just personal taste? Oh, since the kernel seems to be able to run my sunos /bin/sh (first thing it has to when booting:-)) I'll try to get it to be as compatible as possible to 0.9 (for example, reenable the previous meaning of the BSD[D-H] partitions, should be integratable easily with the new types, just preallocate those partition slots, and fill remaining slots with whatever is on the disk and marked as allocate-sequentially). However I don't think due to religious reasons such changes would make it into main sources eh?:-)) Anyway, on to sd minor encoding :-) -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 14:09:43 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: ftruncate Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm having trouble with ftruncate with current sources on i386 in both shared and -static modes. Basically, ftruncate() doesn't work with files opened as "a" or "r+" (which may be as designed, the man page is vague). It also fails to work when the file has had data written to it. Finally, it always (even when it works) returns an error and sets errno = 27 I sent a bug report on this in earlier this evening. #include #include extern int errno; main() { FILE *fp; fp = fopen("foo","w"); fprintf(fp,"Mom loves you"); fflush(fp); printf("%d\n", errno); printf("trunc: %d\n",ftruncate(fileno(fp),10)); printf("%d\n", errno); } From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 14:14:44 1994 From: mycroft@gnu.ai.mit.edu To: banshee@gabriella.resort.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: ftruncate Sender: owner-current-users@sun-lamp.cs.berkeley.edu As I pointed out in reply to your `bug' report: This is a bug in your program. You either need to #include , or cast the second argument of ftruncate(2) to `off_t'. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 16:41:04 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/sys/isofs/cd9660/cd9660_lookup.c U src/sys/isofs/cd9660/cd9660_node.c U src/sys/isofs/cd9660/cd9660_node.h U src/sys/isofs/cd9660/cd9660_vfsops.c U src/sys/isofs/cd9660/iso.h U src/sys/msdosfs/denode.h U src/sys/msdosfs/direntry.h U src/sys/msdosfs/fat.h U src/sys/msdosfs/msdosfs_denode.c U src/sys/msdosfs/msdosfs_fat.c U src/sys/msdosfs/msdosfs_lookup.c U src/sys/msdosfs/msdosfs_vfsops.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/msdosfs/msdosfsmount.h Killing core files: Running the SUP scanner: SUP Scan for current starting at Tue Jul 19 03:42:46 1994 SUP Scan for current completed at Tue Jul 19 03:45:16 1994 SUP Scan for mirror starting at Tue Jul 19 03:45:16 1994 SUP Scan for mirror completed at Tue Jul 19 03:47:48 1994 From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 19 17:01:32 1994 From: ledl@dax1.w7.ipp-garching.mpg.de (Ledl Ludwig 2686) To: amiga@sun-lamp.cs.berkeley.edu Subject: Installation problems with 940709 snapshot Sender: owner-amiga@sun-lamp.cs.berkeley.edu Sorry for a somewhat trivial question, but after approx. 12 hours of fruitless work I am running out of ideas and also patience. Problem abstract: NetBSD finds a Root partition (on which I think I have copied a rootfs correctly) but then panics with "panic: cannot mount root stopped at 0x84928 unlk a6" and I dont know what NetBSD is willing to tell me herewith :-( Hardware: A4000/040 6Meg (ok, I know thats not too much) Seagate ST3144 120Mb scsi.device unit 0 Seagate ST???? 240Mb scsi.device unit 1 (Masoboshi Mastercard with Quantum 50 Mb) (oMniBus graphic system (you dont have to know this product :-)) Software: The latest binary snapshots from sun-lamp as mirrored to ftp.uni-regensburg.de in bin-dist/940709 Loadbsd-2.9 I tested different kernels: - netbsd-generic from bin-dist/940709 - netbsd-generic940620 and others What have I done so far ? The ST3144 IDE drive has to be big enough for my first tries with NetBSD. So I partitioned it as described in the (old) installation docs for VMUNIX.7xx (from dcc@dcs.ed.ac.uk, notes by Alain Bair): Blocks Reserved = 0, PreAlloc = 0, Custom File System, no Auto mount approx. 12Mb Swap (blocks 0- 99), approx. 10Mb Root (blocks 100-190), rest for Usr/Data, exept that I used the new DosType values "NBR\7", "NBS\1", "NBU\7" (as advised in the README file). Copying the rootfs via "dcp -v -ds 100 -m 20880 rootfs scsi.device,0" seems to work without any problem. Soft reboot with "Loadbsd-2.9 netbsd-generic" tells me: " ... idesc0 at mainbus0 scsibus at idesc0 idesc0 targ 0 lun 0: scsi2 direct fixed sd0 at scisbus9: 124MB, 1001 cyl, 15 head, 17sec, 512 bytes/sec ... 2 mice configured 10 views configured panic: cannot mount root Stopped at 0x84928 unlk a6 " Could somebody tell me whats going wrong ??? Sorry for this lengthy mail (I didnt want to miss the point) and for my crude english (I didnt polish it for years). Thanx Ludwig From owner-amiga@sun-lamp.cs.berkeley.edu Tue Jul 19 19:03:42 1994 To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: Matthew Aldous , amiga@sun-lamp.cs.berkeley.edu, mehlhaff@crl.com Subject: WARNING: BFFS IS BROKEN! ( was Re: newfs fault ) of Mon, 18 Jul 1994 18:28:07 +0700 <9407181628.AA15292@aidec504.TechFak.Uni-Bielefeld.DE> From: "'Most Excellent' Eric Mehlhaff" Sender: owner-amiga@sun-lamp.cs.berkeley.edu markus@techfak.uni-bielefeld.de (Markus Illenseer) recently wrote: >On Jul 16, 8:28pm, Matthew Aldous wrote: >> "newfs: ioctl(WDINFO): Invalid argument." > > Another reminder for the FAQ should be, that BFFS for ADOS doesn't >work with the most recent ROOTFS snapshot due to changements in >the ufs-code. Needs to be updated. > And now it comes up. I just totally trashed my rootfs with a simple attempt to rename a file under BFFS. I think we need to seriously WARN people that BFFS should be treated as read-only (at best) until this gets fixed... (fortunately I keep a spare root partition, for just such an emergency, so reconstruction wasn't so bad). BTW, is it me, or is it just really annoying that when fsck dumps things in lost+found, the filenames start out with a '#' character. This makes reconstruction that much more annoying as you have to carefully quote all the filenames. Eric Mehlhaff, mehlhaff@crl.com From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 19:30:20 1994 From: mark@aggregate.com (Mark P. Gooderum) To: Matthieu.Herrb@laas.fr, per-am@hsr.no Subject: Re: XFree exits. Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 268 Sender: owner-current-users@sun-lamp.cs.berkeley.edu As mentioned earlier, I just moved to current current. I've been running stock (dynamic) XFree 2.1.1 without problems. I don't have a buff VGA board so the security level problem doesn't seem to be hitting me (I run just the vanilla VGA16 and SVGA servers). -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 19:30:21 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Current Report X-Sun-Charset: US-ASCII Content-Length: 2089 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just moved to mostly current from June 2nd sources. The kernel is as of yesterdays sup, userland is still from Chris's i386 binary snapshot of the 13th (?). I'll be up to home built current userland some time later this week. With June 2nds current things were rock solid except for: -halt would often reboot before halting -/ would always fail (minor) fsck and have to reboot, but always came up -sh problems which were solved by tracking just sh fixes until mid-June I had no problems. Because of comments on make changes and having to worry about the do this then that I just used the binary snapshot, without problems. I had one minor panic when FlexFax didn't want to come up, but then checked and found the GENERIC kernels don't have FIFO support, fixed of course when I built my own kernel. As for "real" problems, I also got a "ie0: can't map 3C507 in high memory" with the GENERICAHA kernel. I found this interesting because my ethernet was an an NE2000 clone at 0x300 and I don't have any devices at 0x360. Also, my Ne2000 got recoginized as ed2 since that is where it's I/O ports are but the irq entry for GENERIC didn't match what the card was soft-configured at. Things didn't work until I built the kernel to match the irq (I'd get "ed2: device timeout" errors). Since these card's softconfig and it's possible to find out their irq, I though the driver was supposed to either match what's the card was and blow off the config...I could be wrong though. The biggest problem is I have random SEGV core dumps again. I've only got 8M of RAM and it hits when compiling anything serious with X running. The cores have been from everything, make, sed, gcc, and ccp. These behave like the cores from the pmap problems way back when (March?April?). Re-run things and it works. I have a 486DLC and get the problems with and without notyet_cyrix toggled. (My motherboard supports the DLC and I had no problems with Cyrix cacheing for six weeks with the June 2 current). I can look into the cores more...pointers on what to try would be appreciated. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 21:07:35 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: functioning 'resize' for pcvt ? To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 576 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anybody know why 'resize' (R5 and R6) fail to resolve the size of the terminal when one is sitting at the console of a NetBSD-current.i386 machine ? It used to fail with pccons, and it continues to fail with pcvt, while other programs such as elm/vi have no problem finding th correct screen size. Does anybody have a fix to 'resize.c' ? Cheerio -- The cost of living hasn't affected it's popularity. (unknown) current release=doc host=wipux2.wifo.uni-mannheim.de hostbase=/src base=/usr \ prefix=/usr backup delete use-rel-suffix ; updated midday MET NetBSD-current From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 21:08:36 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: Current Report To: mark@aggregate.com (Mark P. Gooderum) 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: 2036 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I just moved to mostly current from June 2nd sources. The kernel is as of > yesterdays sup, userland is still from Chris's i386 binary snapshot of the > 13th (?). I'll be up to home built current userland some time later this > week. > > With June 2nds current things were rock solid except for: > > -halt would often reboot before halting > -/ would always fail (minor) fsck and have to reboot, but always > came up > -sh problems which were solved by tracking just sh fixes until mid-June Much as I hate to sound like Charles Hannum, this isn't my experience. >From June 2nd, I've had 0 problems with disc turds, and halt has NEVER rebooted before halting. I'm just a very happy (albeit quiet) bunny. Indeed, from about July 2nd, if fsck found problems on /, it hasn't even necessitated a reboot. > I had no problems. Because of comments on make changes and having to worry > about the do this then that I just used the binary snapshot, without problems. > I had one minor panic when FlexFax didn't want to come up, but then checked > and found the GENERIC kernels don't have FIFO support, fixed of course when > I built my own kernel. >From early April, it's been quite easy - just install the new includes, (if pax dumps on you, then change bsd.own.mk to use a symlink), make a new config, config your kernel, reboot on the new kernel, and then do lib, bin, sbin, usr.bin, usr.sbin etc. > As for "real" problems, I also got a "ie0: can't map 3C507 in high > memory" with the GENERICAHA kernel. I found this interesting because > my ethernet was an an NE2000 clone at 0x300 and I don't have any > devices at 0x360. This is just a warning message from the ie driver - it hasn't found anything during autoconfig, and so can't map it. Ignore it. Alistair PS. Anyone fancy Snapshot Reports again? -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. [These are only my opinions, and certainly not those of Amdahl Corporation] From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 21:10:51 1994 To: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Anyone has a HPPA port? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can get a hp 825s for cheap, is there a possibility to get NetBSD running on it. Currently the machine runs hpux 7.0, 9.04 is far too slow with only 8 MB. Cheers Oskar ============================================================================== Jan-Hinrich Fessel , Systemverwaltung Quantum Gesellschaft fuer Software mbH, D-4600 Dortmund, Germany Jan-Hinrich.Fessel@quantum.de oskar@un.maus.ruhr.de ============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 21:28:35 1994 From: mark@aggregate.com (Mark P. Gooderum) To: mark@aggregate.com, agc@uts.amdahl.com Subject: Re: Current Report Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 2208 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > With June 2nds current things were rock solid except for: > > > > -halt would often reboot before halting > > -/ would always fail (minor) fsck and have to reboot, but always > > came up > > -sh problems which were solved by tracking just sh fixes until mid-June > > Much as I hate to sound like Charles Hannum, this isn't my experience. > From June 2nd, I've had 0 problems with disc turds, and halt has NEVER > rebooted before halting. I'm just a very happy (albeit quiet) bunny. > Indeed, from about July 2nd, if fsck found problems on /, it hasn't > even necessitated a reboot. I did have these problems with a June 2 current. They are gone with July 13/18 current (/ usally passes, except on unclean shutdown, but yes, fsck doesn't reboot). The only current problems I've had are those explictly mentioned as current, earlier problems are gone. I missed one other problem that seems to be gone, portmapper would routinely dump core. By the time I got around to building a debuggable one, I was ready to upgrade to current current. That problem I'll look at more closely since I don't believe portmap has changed in the last six weeks? > From early April, it's been quite easy - just install the new includes, > (if pax dumps on you, then change bsd.own.mk to use a symlink), make a > new config, config your kernel, reboot on the new kernel, and then do > lib, bin, sbin, usr.bin, usr.sbin etc. >From what I'd read I needed make and config changes. I needed pax, which my June 2 current didn't have, etc. I'm sure it wouldn't have been too hard, but upgrading with a binary snapshot works, is easy, and only takes about 30 minutes, then I can "know" I can rebuild userland from that. > This is just a warning message from the ie driver - it hasn't found > anything during autoconfig, and so can't map it. Ignore it. Since all of the other drivers are silent if they don't find their hardware the ie driver probably should be too, especially since this message looks very similar to some messages in other drivers that indicate a real problem. The random SEGV's are a much more serious problem, but I really don't have much of a clue at where to look at more closely. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:06:45 1994 To: andrew@wipux2.wifo.uni-mannheim.de Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: functioning 'resize' for pcvt ? <199407191639.SAA02566@wipux2.wifo.uni-mannheim.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 >Does anybody know why 'resize' (R5 and R6) fail to resolve the size of the >terminal when one is sitting at the console of a NetBSD-current.i386 >machine ? >It used to fail with pccons, and it continues to fail with pcvt, while >other programs such as elm/vi have no problem finding th correct screen >size. Ummm, 'resize' is only supposed to be run from an xterm (as the man page explains, which also curiously explains why it's bundled with X :-) ). I assume that elm/vi/more/whatever get the screen size from the rows and columns settings of the tty. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:20:50 1994 To: Jan-Hinrich Fessel Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Anyone has a HPPA port? From: Jason Thorpe Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Tue, 19 Jul 94 17:07:17 +0200 Jan-Hinrich Fessel wrote: > I can get a hp 825s for cheap, is there a possibility > to get NetBSD running on it. > Currently the machine runs hpux 7.0, 9.04 is far too slow > with only 8 MB. I have an 835 and an 845 that I'd like to run a decent OS on as well...(They both have plenty of memory to run 9.05, so they are...) However, I don't have the time to really get down and work on another port... Later... ----------------------------------------------------------------------------- Jason R. Thorpe thorpej@cs.orst.edu 754-1554 OSU CS Support CSWest Room 12 737-5567 CSOS NetBSD/Symmetry Project From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:27:55 1994 Subject: Re: functioning 'resize' for pcvt ? From: Brian de Alwis To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-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: 833 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does anybody know why 'resize' (R5 and R6) fail to resolve the size of the > terminal when one is sitting at the console of a NetBSD-current.i386 > machine ? > It used to fail with pccons, and it continues to fail with pcvt, while > other programs such as elm/vi have no problem finding th correct screen > size. resize is xterm-specific (which is why the source is stored with xterm) and should only be used from an xterm. It sounds like you are trying to run it from the console while _out_ of X. > Does anybody have a fix to 'resize.c' ? Nope, and -- if I understand you correctly -- there won't be a fix. -- Brian de Alwis - University of Waterloo: bsdealwis@math.uwaterloo.ca `How extraordinarily lucky Minta is! She is marrying a man who has a gold watch in a wash-leather bag!' - _To_the_Lighthouse_, Virginia Woolf. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:29:11 1994 From: Michael Graff To: current-users@sun-lamp.cs.berkeley.edu Subject: Root name servers (forgot original title) Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've just been told that there are supposed to be NO name servers at the in-addr.arpa level, just .arpa and xxx.in-addr.arpa. The fact that your servers are likely finding some bogus server irc.scitex.com is a bad setup on someone's part, not yours. >From iastate.edu, I can't even get TO that server... --Michael From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:49:38 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: Re: functioning 'resize' for non-xterm ? To: Mike.Long@analog.wipux2.wifo.uni-mannheim.de, bsdealwi@math.waterloo.ca, ken@wrl.epi.com Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 662 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Ok, as a few people correctly pointed out, resize is only for xterm. Is there a program which one can use to correctly guess the size of the terminal on is logging in from. i.e. Something which will recognise: I'm on a 50lin 132col pcvt or, a hpux text-screen 149 col, a 24line Dos-telnet session, a 25line Dos-telnet session, etc.. Or how do other people solve the problem of allways logging in from differently sized screens ? Cheerio -- The cost of living hasn't affected it's popularity. (unknown) current release=doc host=wipux2.wifo.uni-mannheim.de hostbase=/src base=/usr \ prefix=/usr backup delete use-rel-suffix ; updated midday MET NetBSD-current From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 22:50:11 1994 To: agc@uts.amdahl.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Current Report 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 >PS. Anyone fancy Snapshot Reports again? I think that -current has become stable enough that they aren't as necessary as they once were. But they'd always be useful. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 23:02:57 1994 To: Michael Graff Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Root name servers (forgot original title) <199407191814.NAA13979@packrat.vorpal.com> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I've just been told that there are supposed to be NO name servers > at the in-addr.arpa level, just .arpa and xxx.in-addr.arpa. The > fact that your servers are likely finding some bogus server irc.scitex.com > is a bad setup on someone's part, not yours. That bogon is awfully popular. It's infecting our local name server AND uunet's name server, and was probably at the root of some trouble I was having yesterday with ftp.apple.com as well. It's time for the protocol police to send the SWAT team. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 23:22:53 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost.Berkeley.EDU didn't use HELO protocol To: Jan-Hinrich Fessel Cc: current-users@sun-lamp.cs.berkeley.edu, hibler@sun-lamp.cs.berkeley.edu Subject: Re: Anyone has a HPPA port? <9407191507.AA05102@quando.quantum.de> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I can get a hp 825s for cheap, is there a possibility > to get NetBSD running on it. > Currently the machine runs hpux 7.0, 9.04 is far too slow > with only 8 MB. > > Cheers > Oskar > There is no NetBSD/HPPA port, nor is there one in development at this time. However recent happenings suggest that there will be one in the future. later, Adam Glass ps. There is the Utah BSD HPPA stuff, but I'm unfamiliar with their exact distribution terms. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 23:23:47 1994 To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: Mike.Long@analog.wipux2.wifo.uni-mannheim.de, bsdealwi@math.waterloo.ca, ken@wrl.epi.com, netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: functioning 'resize' for non-xterm ? <199407191833.UAA02876@wipux2.wifo.uni-mannheim.de> X-Mailer: exmh version 1.4 6/24/94 From: Marc Evans - Contract Software Hacker Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Ok, as a few people correctly pointed out, resize is only for xterm. > > Is there a program which one can use to correctly guess the size of > the terminal on is logging in from. Look at tset(1). - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 23:27:31 1994 From: mike@cs.utah.edu (Mike Hibler) To: Jan-Hinrich.Fessel@quantum.de, glass@sun-lamp.cs.berkeley.edu Subject: Re: Anyone has a HPPA port? Cc: current-users@sun-lamp.cs.berkeley.edu, hibler@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu We have a 4.3 BSD that runs on the 834/835 (I don't think the 825 was that different). However, it has HP proprietary code and would require your signing a NDA with HP. On another front, there is hope that we will be able to release nearly complete kernel source for Mach 3.0 on the hp700 soon. That would contain most of what you need. I cannot give you a date when this will happen however. Anyway, this Mach used to run on the 835 but has atrophied over time. It would have most of what you need, including some rudimentary CIO drivers for the HP-IB disk, 6-port MUX, and LAN (the drivers we use in BSD for these devices are not the same, we use old HP-UX drivers there). From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 19 23:32:47 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Subject: Re: functioning 'resize' for pcvt ? <199407191639.SAA02566@wipux2.wifo.uni-mannheim.de> Sender: owner-current-users@sun-lamp.cs.berkeley.edu andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) writes: > Does anybody know why 'resize' (R5 and R6) fail to resolve the size of the > terminal when one is sitting at the console of a NetBSD-current.i386 > machine ? > It used to fail with pccons, and it continues to fail with pcvt, while > other programs such as elm/vi have no problem finding th correct screen > size. resize is only designed to work with xterms. Mark From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 00:24:18 1994 To: "John F. Woods" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Root name servers (forgot original title) <9407191839.AA06013@kaos.ksr.com> X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4 WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d gD\SW #]iN_U0 KUmOR.P<|um5yPkEpSD@*e` From: Ken Hornstein Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> I've just been told that there are supposed to be NO name servers >> at the in-addr.arpa level, just .arpa and xxx.in-addr.arpa. The >> fact that your servers are likely finding some bogus server irc.scitex.com >> is a bad setup on someone's part, not yours. > >That bogon is awfully popular. It's infecting our local name server AND >uunet's name server, and was probably at the root of some trouble I was >having yesterday with ftp.apple.com as well. I think why this one is particulary evil is that there is no other records at the "in-addr.arpa" level; if you want to do a PTR query for a zone that you don't have any other records for, you end up always querying that record, as all the root servers are at the "arpa" level. So all these helpful nameservers are giving this out as the most specific nameserver available. Even worse, this entry has an obnoxiously long TTL (5-6 days, I believe). >It's time for the protocol police to send the SWAT team. Well, you can look up the phone number of the system admin using "whois scitex.com" (once you wait past the PTR query timeout, of course :-) ). --Ken From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 20 00:42:53 1994 To: chopps@emunix.emich.edu Cc: Matthew Aldous , amiga@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: Gollies, a long one. <9407190414.AA24229@emunix.emich.edu> From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu In message <9407190414.AA24229@emunix.emich.edu>, chopps@emunix.emich.edu writes: >> o ps cpu% mem% listing are nearly always 0, or -0 >these are non fatal and are probably caused by out of date binaries. No, I get the same thing building current from the 17 Jul sup. Order of build was: 1) Make and install new kernel, reboot with it. 2) Make and install /usr/include 3) Make and install /usr/share/mk 4) Make and install libs 5) Make and install gas, ld, gcc2 6) Make and install all. Since I was coming from a relatively recent kernel/binary pair, that may have been overkill, but I did it anyway. I still get wacky stuff reported by 'vmstat' (16000+ vm used, when only base utils are running, and tallying the RSZ/VSZ columns of 'ps' doesn't even come close, nor is swap if 1% used.) And, 'ps' reports bad CPU% and MEM% columns. One more thing: As is just starting to be discussed on 'current-users', I am suffering a strange spurious SIGSEGV during large compiles. Normally, cpp get creamed with it, but other utilities have been known to die at completely unpredictable times during a compile. Simply restart the compile, and it works. (until the next random SIGSEGV). Someone on current mentioned that it sounds a lot like a strange pmap() bug that happened around April/May. Since they're quite easy to come by (cd /usr/src ; make clean ; make :-) ), I'll re-ulimit myself and see if I can't get some resonable backtrace out of gdb. -wps From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 01:11:02 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu Subject: Re: Current Report <9407191415.AA13410@aggregate.com> From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <9407191415.AA13410@aggregate.com>, Mark P. Gooderum writes: > >I just moved to mostly current from June 2nd sources. The kernel is as of >yesterdays sup, userland is still from Chris's i386 binary snapshot of the >13th (?). I'll be up to home built current userland some time later this >week. >The biggest problem is I have random SEGV core dumps again. I've only got >8M of RAM and it hits when compiling anything serious with X running. The >cores have been from everything, make, sed, gcc, and ccp. These behave like >the cores from the pmap problems way back when (March?April?). Re-run things >and it works. This is the exact RAM size and symptoms that occur on my Amiga ('030) running NetBSD-current (Jul-17 sup). However, I don't even need X running. Compiles run for what seems to be a random length of time, and then-- spurious SIGSEGV. My 24MB i486/DX2 has been ROCK SOLID forever now. Pointers? Types of things you'd like to see for more info? -wps From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 01:12:50 1994 From: ddzehr@telecom.ksu.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Root name servers (forgot original title) Cc: ddzehr@telecom.ksu.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Michael Graff writes: > >I've just been told that there are supposed to be NO name servers >at the in-addr.arpa level, just .arpa and xxx.in-addr.arpa. The >fact that your servers are likely finding some bogus server irc.scitex.com >is a bad setup on someone's part, not yours. > >>From iastate.edu, I can't even get TO that server... > >--Michael There seems to be a rather wide spread problem on the net of bogus nameserver records for in-addr.arpa. At this point in time there aren't suppsosed to be records for it. People are working on getting it fixed, from the mail I've been getting it looks like it could be a bit of a mess :-) -- Dylan D Zehr UNIX Systems Admin. Dept. Telecommunications, Kansas State University, Manhattan KS 66506 vox 913.532.4505 fax 913.532.7114 email ddzehr@telecom.ksu.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 01:25:31 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: those annoying "set*uid is deprecated" messages X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu In the process of porting some software to NetBSD, I'm getting run-time messages of the sort "foo: This program uses setreuid() which is deprecated". I recall the tail end of a discussion about this when I joined current-users, but don't recall. Are these messages going to be tossed in favor of program load time messages? [In particular, I consider them evil because they cause me protocol problems on an RPC service which had stderr connected to the socket] On a related topic, is there some way to do this: be running as ruid=euid=0 (some authentication program) set one of the uid's to a user, then run some functions which fetch kerberos tickets for that user, giving the file his/her UID set them both back to root to complete other login stuff set them both to the user's UID, and exec his/her shell No combination I've tried of seteuid(), setruid(), setuid() or setreuid() seems to make this happen, and some combinations that don't return system call errors don't actually affect the UIDs. Suggestions (besides forking---too much state needs to be passed unless I toss the code and rewrite it, which I'd rather not do, as I want to feed changes back to the maintainers)? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 01:42:35 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: make rules bug Sender: owner-current-users@sun-lamp.cs.berkeley.edu The prog rules were supposed to work with shell scripts too, but they don't anymore. Try making genclass in the libg++ subdirectory... Here's a fix to the rules file: *** bsd.prog.mk.dist Thu Jul 7 04:22:10 1994 --- bsd.prog.mk Tue Jul 19 17:18:34 1994 *************** *** 58,73 **** OBJS+= ${SRCS:N*.h:N*.sh:R:S/$/.o/g} .endif ! .if defined(DESTDIR) ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} -nostdlib -L${DESTDIR}/usr/lib ${LIBCRT0} ${OBJS} ${LDADD} -lgcc -lc -lgcc ! .else ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} ${OBJS} ${LDADD} .endif .if !defined(MAN1) && !defined(MAN2) && !defined(MAN3) && \ --- 58,77 ---- OBJS+= ${SRCS:N*.h:N*.sh:R:S/$/.o/g} .endif ! SHSRCS ?= ${SRCS:M*.sh} ! ! .if !empty(SHSRCS) ! . if defined(DESTDIR) ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} -nostdlib -L${DESTDIR}/usr/lib ${LIBCRT0} ${OBJS} ${LDADD} -lgcc -lc -lgcc ! . else ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} ${OBJS} ${LDADD} + . endif .endif .if !defined(MAN1) && !defined(MAN2) && !defined(MAN3) && \ From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 02:04:08 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: Better fix for make rules Sender: owner-current-users@sun-lamp.cs.berkeley.edu The previous one was not entirely correct, and it introduced an extra variable where there is no need for that. *** bsd.prog.mk.dist Thu Jul 7 04:22:10 1994 --- bsd.prog.mk Tue Jul 19 17:39:47 1994 *************** *** 58,73 **** OBJS+= ${SRCS:N*.h:N*.sh:R:S/$/.o/g} .endif ! .if defined(DESTDIR) ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} -nostdlib -L${DESTDIR}/usr/lib ${LIBCRT0} ${OBJS} ${LDADD} -lgcc -lc -lgcc ! .else ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} ${OBJS} ${LDADD} .endif .if !defined(MAN1) && !defined(MAN2) && !defined(MAN3) && \ --- 58,75 ---- OBJS+= ${SRCS:N*.h:N*.sh:R:S/$/.o/g} .endif ! .if defined(OBJS) && !empty(OBJS) ! . if defined(DESTDIR) ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} -nostdlib -L${DESTDIR}/usr/lib ${LIBCRT0} ${OBJS} ${LDADD} -lgcc -lc -lgcc ! . else ${PROG}: ${LIBCRT0} ${OBJS} ${LIBC} ${DPADD} ${CC} ${LDFLAGS} ${LDSTATIC} -o ${.TARGET} ${OBJS} ${LDADD} + . endif .endif .if !defined(MAN1) && !defined(MAN2) && !defined(MAN3) && \ From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 02:35:47 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <9407192115.AA02460@banana> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I recall the tail end of a discussion about this when I joined > current-users, but don't recall. Are these messages going to be tossed > in favor of program load time messages? [In particular, I consider them > evil because they cause me protocol problems on an RPC service which had > stderr connected to the socket] i believe the goal was to make them load-time. "not done yet, though." > On a related topic, is there some way to do this: > (1) > be running as ruid=euid=0 (some authentication program) > (2) > set one of the uid's to a user, then run some functions which fetch > kerberos tickets for that user, giving the file his/her UID > (3) > set them both back to root to complete other login stuff > (4) > set them both to the user's UID, and exec his/her shell i think the following would work: setuid(0); /* gets you (1), assuming a suid-exec program. * otherwise, you're ruid == euid, anyway. * also sets saved uid. */ ... seteuid(uid); /* sets effective uid to uid; gets you (2) */ ... setuid(0); /* sets effective/real/saved id's back to 0. (3) */ ... setuid(uid); /* irrevocably become uid (sets e/r/s id's). (4) */ exec shell the similar thing works for gid's, but you've gotta be careful to set.*gid at the correct times, so you still have perms... chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 03:01:10 1994 To: Christos Zoulas Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: make rules bug <199407192122.AA23951@cs4.deshaw.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The prog rules were supposed to work with shell scripts too, but they > don't anymore. Try making genclass in the libg++ subdirectory... 248 [sun-lamp] genclass % pwd /usr/src/gnu/lib/libg++/genclass 249 [sun-lamp] genclass % ls -la obj/. total 2 drwxrwxr-x 2 cgd source 512 Jul 19 15:21 ./ drwxrwxr-x 4 cgd source 512 Jul 16 16:57 ../ 250 [sun-lamp] genclass % make sed -e 's|^PROTODIR=.*|PROTODIR=/users/cgd/940718/usr/include/g++/gen|' -e 's||2.4|' /usr/src/gnu/lib/libg++/genclass/genclass.sh /usr/lib/crt0.o /usr/lib/libc.a > genclass 251 [sun-lamp] genclass % ls -la obj/. total 42 drwxrwxr-x 2 cgd source 512 Jul 19 15:21 ./ drwxrwxr-x 4 cgd source 512 Jul 16 16:57 ../ -rw-rw-r-- 1 cgd source 40543 Jul 19 15:21 genclass 'make genclass' also works fine from src/lib/libg++ there was a problem with this, but i fixed it a while ago... are you using the latest make rules? the fix for the problem that _i_ had with them is included below... basically, the ${SRCS:N*.h:N*.sh:R:S/$/.o/g} was yeilding "", i.e. an empty string, which was being added to OBJS for the libg++... thoughts? chris =================================================================== RCS file: /b/source/CVS/src/share/mk/bsd.prog.mk,v retrieving revision 1.44 retrieving revision 1.45 diff -c -r1.44 -r1.45 *** 1.44 1994/06/30 05:31:21 --- 1.45 1994/06/30 06:35:50 *************** *** 1,4 **** ! # $NetBSD: bsd.prog.mk,v 1.44 1994/06/30 05:31:21 cgd Exp $ # @(#)bsd.prog.mk 5.26 (Berkeley) 6/25/91 .if exists(${.CURDIR}/../Makefile.inc) --- 1,4 ---- ! # $NetBSD: bsd.prog.mk,v 1.45 1994/06/30 06:35:50 cgd Exp $ # @(#)bsd.prog.mk 5.26 (Berkeley) 6/25/91 .if exists(${.CURDIR}/../Makefile.inc) *************** *** 53,59 **** --- 53,61 ---- .if defined(PROG) SRCS?= ${PROG}.c + .if !empty(SRCS:N*.h:N*.sh) OBJS+= ${SRCS:N*.h:N*.sh:R:S/$/.o/g} + .endif .if defined(LDONLY) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 03:03:57 1994 To: Christos Zoulas Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Better fix for make rules <199407192142.AA24098@cs4.deshaw.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The previous one was not entirely correct, and it introduced an extra > variable where there is no need for that. i'm still not clear on what problem you're trying to _fix_... could you please explain? chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 05:22:21 1994 From: David Langford To: current-users@sun-lamp.cs.berkeley.edu Subject: mount_msdos question Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a 170MB IDE drive with a single MS-DOG partition that I need to get data off of (108MB file). Actually all I need to do is copy the file off and then I can newfs the drive and put a Real(tm) filesystem on it. I spent a few minutes with mtools but that got ./mdir: Cannot initialize 'C:' (I beleive devices.c was redone correctly) I am running with current sources as of Wed Jul 20. Jul 19 23:26:53 dali /netbsd: wd3 at wdc1 drive 1: 162MB 903 cyl, 8 head, 46 sec Am I wrong in thinking that "mount_msdos /dev/wd3c /mnt" should mount it? I get, as my error message: msdos: mount: Invalid argument Is something still amiss or am I being a total dunce? Thank you, -David Langford langfod@maui.com From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 20 05:50:05 1994 To: amiga-dev@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga.devel From: tsarna@endicor.com (Ty Sarna) Subject: Re: 80 column console Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu In article <9407190403.AA24043@emunix.emich.edu> chopps@emunix.emich.edu writes: > No the 80 col. display required overscan which I will not enable fby default. > > A hack could be done, but I'd rather just let the user iteconfig themseleves > > Chris. It's still wrong to assume that boldsmear will always be 1, though. You should at least apply the patch hunk(s) that fix that. Anyway, I don't think 1 pixel of overscan (for the normal case) is going to hurt anyway, even on the A2024 which is the pickiest monitor I've ever seen. Certainly it's less likely to hurt things than a <80 column display is. There is at least one program in NetBSD that requires at least 80 columns. Probably more than just that one program, too... -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 06:16:22 1994 To: David Langford Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: mount_msdos question <199407200015.OAA11303@waena.maui.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have a 170MB IDE drive with a single MS-DOG partition that I need to get > data off of (108MB file). Actually all I need to do is copy the file off and > then I can newfs the drive and put a Real(tm) filesystem on it. unfortunately, if the driver doesn't have a NetBSD disklabel, you can't access dos partitions on it via mount_msdos... (at least, that was the case the last time i checked, and i've heard no changes re: that...) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 06:39:46 1994 From: John Kohl To: cgd@alpha.bostic.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sadly, it's not possible to do what I want to do with the existing syscalls. The process in question starts out running as root. Thus r=e=svuid=0 The ruid can only be set to an unprivileged user if we drop all privileges with setuid(x). Here's the comment from kern_prot.c: /* * we assume that the intent of setting ruid is to be able to get * back ruid priviledge. So we make sure that we will be able to * do so, but do not actually set the ruid. */ The net result is that if you start out with ruid=x, euid=y, then setreuid(y,x) ends up with ruid=euid=x, which seems not quite ideal. The failure to set ruid is the crux of the problems I've seen. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 07:30:23 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <9407200136.AA02710@banana> 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 >Sadly, it's not possible to do what I want to do with the existing >syscalls. > >The process in question starts out running as root. Thus r=e=svuid=0 > >The ruid can only be set to an unprivileged user if we drop all >privileges with setuid(x). Here's the comment from kern_prot.c: > /* > * we assume that the intent of setting ruid is to be able to get > * back ruid priviledge. So we make sure that we will be able to > * do so, but do not actually set the ruid. > */ > >The net result is that if you start out with ruid=x, euid=y, then >setreuid(y,x) ends up with ruid=euid=x, which seems not quite ideal. My understanding is that this is the way it's supposed to be, according to POSIX. But what I don't understand is, what's wrong with keeping ruid=0 and just setting euid back and forth? (This should work, right?) And then when you want to give up privs totally, just use setuid(). If you want to read and write files as a particular user, then euid should be the one that does that. In fact, the following program, run as root, generates "foo1" with an owner of 100 and "foo2" with an owner of 0, which I believe is what you want. main() { FILE *f; seteuid(100); f = fopen("foo1","w+"); fprintf(f, "bar 1\n"); fclose(f); seteuid(0); f = fopen("foo2","w+"); fprintf(f, "bar 2\n"); fclose(f); exit(0); } --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 07:31:39 1994 To: John Kohl Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <9407200136.AA02710@banana> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The failure to set ruid is the crux of the problems I've seen. As i mentioned in private mail: (1) we don't define _POSIX_SAVED_IDS, (2) because of that, you can't switch back and forth between real uid's. (3) there is NO posix interface that allows you to just set the real uid. given that, your only options are the BSD extensions to POSIX, which allow you to swap the effective UID... why are you so keen to have the _real_ uid set, in any case? for everything except access(), the effective UID is used for determining stuff like permissions... chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 07:41:12 1994 From: Daniel Carosone To: "Chris G. Demetriou" Cc: Christos Zoulas , current-users@sun-lamp.cs.berkeley.edu Subject: Re: make rules bug <9407192227.AA02044@alpha.bostic.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Chris G. Demetriou writes: > 250 [sun-lamp] genclass % make > sed -e 's|^PROTODIR=.*|PROTODIR=/users/cgd/940718/usr/include/g++/gen|' -e 's||2.4|' /usr/src/gnu/lib/libg++/genclass/genclass.sh /usr/lib/crt0.o /usr/lib/libc.a > genclass > 251 [sun-lamp] genclass % ls -la obj/. > total 42 > drwxrwxr-x 2 cgd source 512 Jul 19 15:21 ./ > drwxrwxr-x 4 cgd source 512 Jul 16 16:57 ../ > -rw-rw-r-- 1 cgd source 40543 Jul 19 15:21 genclass > > i'm still not clear on what problem you're trying to _fix_... >could you please explain? Take a closer look in the file. Do you really want /usr/lib/crt0.o and /usr/lib/libc.a appended to the shell script? It makes a genclass, but not the right one :) -- Dan. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 07:56:55 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: 4.4 Lite programs From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu a few programs missing from NetBSD can be found in: ftp.CSOS.ORST.EDU:/pub/NetBSD/Lite/usr.bin these currently consist of: apply, bdes, gcore, lam, rs and systat. if i find more, i will add them. if any get incorporated, they will be deleted. no, i won't put Lite up for ftp, so don't ask. of particular interest are gcore and systat, which appear to function fine. bdes requires a working crypt library, obviously. all have only been tested on the hp300. your mileage may vary, etc. (gcore is missing many machine specific modules...) -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 08:05:10 1994 From: John Kohl To: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>>> "Chris" == Chris G Demetriou writes: Chris> why are you so keen to have the _real_ uid set, in any case? Chris> for everything except access(), the effective UID is used Chris> for determining stuff like permissions... The Kerberos library creates ticket files, which we want to be owned by the user. It assumes if it sees getuid() != geteuid() that it's a setuid program, and it temporarily swaps the two so that the user's UID is on the ticket file. When login-type programs can't set the ruid and desire to do other stuff as root later, and don't want to fork, they have to do other gross things like understanding ticket files and chown()ing them. ick. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 09:32:37 1994 To: John Kohl Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <9407200330.AA02811@banana> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >>>>> "Chris" == Chris G Demetriou writes: > > Chris> why are you so keen to have the _real_ uid set, in any case? > Chris> for everything except access(), the effective UID is used > Chris> for determining stuff like permissions... > > The Kerberos library creates ticket files, which we want to be owned by > the user. It assumes if it sees getuid() != geteuid() that it's a > setuid program, and it temporarily swaps the two so that the user's UID > is on the ticket file. what i've been trying to get you to understand, in previous mail, was that you should not do that with setreuid() any more! You should be using seteuid(), in every 4.4-Lite-ish BSD system. It's been this way since a while ago, in 4.4... if you replace the swaps with appropriate 'seteuid' calls, things should work just fine, i'd _think_... i.e. instead of doing: setuid(rootuid); /* perhaps implied */ setreuid(rootuid, useruid); /* do stuff to file */ setreuid(useruid, rootuid); setuid(userid); /* run shell */ do: setuid(rootuid); /* perhaps implied */ seteuid(userid); /* do stuff to file */ seteuid(rootuid); setuid(rootuid); /* run shell */ in general, a reasonable approximation is: :g/setreuid/s/setreuid(\([^,]*\),\([^)]*\))/setreuid(\2)/g 8-) setreuid(x,y); ... ; setreuid(y,x); as setreuid is currently emulated, will do the exact same thing as seteuid(y); ... ; seteuid(x); if your real and effective uid's were the same to start with. maybe i'm missing something here, but... look at this: boat-anchor# rm * boat-anchor# cat > foo.c #include main() { int oldeff; printf("real = %d, eff = %d\n", getuid(), oldeff = geteuid()); open("owned_by_eff1", O_CREAT, 0600); seteuid(getuid()); open("owned_by_real", O_CREAT, 0600); seteuid(oldeff); open("owned_by_eff2", O_CREAT, 0600); } boat-anchor# cc foo.c ; chmod u+s a.out boat-anchor# exit 232 [boat-anchor] tmp % ls -la a.out -rwsr-xr-x 1 root bin 13974 Jul 19 20:56 a.out* 233 [boat-anchor] tmp % id uid=2200(cgd) gid=15 groups=15, 0(wheel), 5(operator), 20(staff), 117(dialer), 500(source), 501(bugs), 502(i386-bsd), 503(other-bsd), 504(mac-bsd), 505(mailman), 507(ftp-incoming), 600(ksrc), 601(usrc) 234 [boat-anchor] tmp % ls -l owned* ls: No match. 235 [boat-anchor] tmp % a.out real = 2200, eff = 0 236 [boat-anchor] tmp % ls -l owned* -rw------- 1 root bin 0 Jul 19 20:56 owned_by_eff1 -rw------- 1 root bin 0 Jul 19 20:56 owned_by_eff2 -rw------- 1 cgd bin 0 Jul 19 20:56 owned_by_real what's different there than what you want to do? you'll note that: (1) the files were created with uid == the euid of the process. (2) [not demonstrated] if your euid == 0, you can chown. (1) follows from the fact that i mentioned to you earlier (i forget whether it was here, or in mail), that ALL FILE SYSTEM OPERATIONS EXCEPT FOR access() ARE DONE USING THE EFFECTIVE UID OF THE PROCESS. how about this: if that knowledge doesn't solve your problems, what, exactly, are you trying to do? chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 09:42:19 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <9407200330.AA02811@banana> 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 >>>>>> "Chris" == Chris G Demetriou writes: > >Chris> why are you so keen to have the _real_ uid set, in any case? >Chris> for everything except access(), the effective UID is used >Chris> for determining stuff like permissions... > >The Kerberos library creates ticket files, which we want to be owned by >the user. It assumes if it sees getuid() != geteuid() that it's a >setuid program, and it temporarily swaps the two so that the user's UID >is on the ticket file. Won't changing the code at that point that calls setreuid() just to call seteuid() fix this problem? Then after you've created the ticket file you can just seteuid(0) back ... --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 20 09:58:50 1994 From: William Coldwell Subject: GMT vs Amiga time To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 199 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Do we have a solution for being able to really set the time to what your timezone is, or are we stuck with GMT (which is still wrong) for 1.0? I just need to know for the install thingy I'm doing. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 20 10:00:08 1994 To: Daniel Carosone Cc: "Chris G. Demetriou" , Christos Zoulas , current-users@sun-lamp.cs.berkeley.edu Subject: Re: make rules bug <199407200129.LAA07443@anarres> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Take a closer look in the file. Do you really want /usr/lib/crt0.o and > /usr/lib/libc.a appended to the shell script? > > It makes a genclass, but not the right one :) yup, as a couple of you pointed out, i was wrong on this... However, Christos (The Keeper of the Make 8-) pointed out that it also points out a more serious bug in make... "hmm." "this'll do for now..." chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 20 23:31:49 1994 From: Andrew Cherry To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Son of unexpected trap Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Recently, I sent a message to amiga-dev about getting an unexpected trap while trying to boot a recent kernel (from sources sup'ed on Monday). I put a call to panic() in straytrap() in order to enter the debugger (L-Amiga Alt F10 wouldn't work), so now I can provide more information. Here is the trace: unexpected trap (vector offset 2) from 8000 panic: foo Stopped at _Debugger + 0x6: unlk a6 db> trace _Debugger(1fdb8,a39ab,fffffeb8,0,fffffec4) + 6 _panic(a39a6,a397a,2,80000,fffffeb8,0,fffffef4) + 34 _straytrap(80000,2) + 28 _badtrap(?) _edintr(0) + e _intrhand(2200) + da _lev4intr(?) _setroot(ffffff6c,a2e38,0,0,aec85) + 1a _configure(0,0,aec85,8,0) + 4c _cpu_startup(af460,0,0,aec85,8) + 4dc _main(ffffffb0) + 38 Hopefully there are no typos up there. :) Anyway, it's enough to tell you something bad is happening when it tries to mount root. Again, my set up is A2000, GVP G-Force 040 with 12MB RAM. The only other card is the IOExtender. Also, a kernel compiled from 7/13/94 sources (possibly 7/12) boots fine. -Andrew Cherry (cherry@mcs.anl.gov) From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 20 23:45:13 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: More investigation into SIGSEGV wierdness. From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu I did some further investigation (building debugging versions of as and cc1 for starters). The failures seem to be at completely random points. Sometimes during indirections, sometimes during mem allocs. Occasionally, no signals, just 'as' will report "ignoring junk after expression" on several lines of the temp file-- rebuilding works. So now I begin to suspect a hardware problem. Theo de Raadt suggested it may possibly have some connection with scsi DMA. Any debugging options that would be useful in this case? I'm going to try to get the SCSI controller and GVP accel swapped out and see if the problem persists, but that will take a few days. Meanwhile, any pointers on where else to look is appreciated. -wps From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 20 23:47:14 1994 From: Danny Lepage Subject: Booting problem, kernel freeze before det. HD To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 993 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi everybody. I've got some problem booting with the newest kernels. The system freeze (with the HD led On) after the lines: ... fd0 at ... ztwobus0 at mainbus0 ahsc0 at mainbus0 scsibus1 at ahsc0 It looks like the kernel have a bad time finding my HDs. I'm experiencing this problem with the Jul 9 kernel from sun-lamp, and the one on the floppies from uni-regensburg. Could this be caused by the fact that my unit 0 disk need sync. to be enable (I had to enable sync. for sd0 with earlier kernel) ? If so, how do I binpath the newer kernel to enable sync. ? (I've tryed binpatch -s _inhibit_sync ..., but it seems that this label is not valid anymore) My setup, in case that it matters: A3000 16MHz 68030, 16Meg Fast, 2Meg Chip Fujitsu M2624FA (520 Meg) , unit 0 (Needs sync. to be enable). Quantum LPS52 (50Meg), unit 6 (Must disable sync., else I've got timeouts). Thanks in advance. Danny Lepage dlepage@CAM.ORG poutine@M3iSystems.QC.CA From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:10:52 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu Subject: What's the right way to set the file flags? Sender: owner-current-users@sun-lamp.cs.berkeley.edu See the subject line. chmod won't do it (which makes sense, since chmod sets the file _mode_), and I can't seem to find any other command that will. I wrote my own, but it seems to me that there must be some CSRG-blessed Official Way to do this, and since I can't find it in the 4.4-Lite source, either, I assume I'm just not looking in the right place. Would someone please let me in on how this is supposed to be done? Incidentally, is the sticky bit going to be moved into the file flags where it belongs, instead of staying in the file modes, where it doesn't, or would that break too much existing code? (I can't think of anything it would break, can you? I can't think of anything but chmod that touches the sticky bit anyway.) From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:11:21 1994 From: Keith Moore To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu, moore@cs.utk.edu Subject: Re: functioning 'resize' for non-xterm ? <199407191833.UAA02876@wipux2.wifo.uni-mannheim.de> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Ok, as a few people correctly pointed out, resize is only for xterm. Actually, resize works on quite a few ANSI terminals, just not on everything. If memory serves, it moves the cursor to some ridiculous coordinates that are way down and to the right, and then asks for a cursor position report to find where the bottom right of the screen *really* is. So what you really need is support in the console driver for a cursor position report. On the other hand, the netbsd maintainers may feel that they have more important things to do than add this feature... Keith From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:37:47 1994 From: Andrew Cagney To: current-users@sun-lamp.cs.berkeley.edu Subject: Kernel `plug and play'? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, A short while ago there were problems with trying to plug-and-play new kernels on old file systems. Has this been resolved (if there was ever a problem). Is it now `safe' for me to plug a netbsd-current kernel into an older file system and set of binaries. For instance: current-kernel on 0.9 fs and approx-april binaries current-kernel on true 0.9 Or even (sicker): current-kernel on FreeBSD file system/binaries ... Please mail replies direct to me, I'll summarize (1). If someone is doing an FAQ or if it is already in there (oops), let me know. Andrew (Wearing rose tinted glasses looking out at an ideal world :-) (1) Please include a note indicating that this is acceptable From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:38:47 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, duncan@comp.vuw.ac.nz, jtk@kolvir.blrc.ma.us Subject: Re: pms mouse driver Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...] (and remade the change in order the interupts were turned off and fixed the reversed dy bug), [...] I put those changes in yesterday. If you could try the latest version (1.9.2.2) and make sure it works, that would help. Of course, if I had the hardware to test it with, it would have worked the first time... From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:39:07 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: sys/cdio.h has no copyright header. To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 10 Sender: owner-current-users@sun-lamp.cs.berkeley.edu just FYI. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:42:45 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: I NEED INFORMATION ON THE AST MULTIPORT SERIAL MULTIPLEX DRIVER Cc: buhrow@cats.ucsc.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I am trying to get an AST multiport serial board working with NetBSD-current. My current is real old, (February) and predates the ast0 driver which exists today. Asside from the flames about trying to move drivers back in time, can someone tell me how the board should be configured for today's driver? According to the documentation that came supplied with the board, you can only put the board in enhanced mode if you plan to use it with their ScO Xenix driver. Otherwise, you should run it in compatible mode. I assume that the NetBSD driver that supports the AST supports it in enhanced mode? I notice that the configuration from the sys-current tree which contains a sample config line for the ast board assumes that the devices com0 through com3 are slaves to this board. Is it legal to put two standard serial ports in a machine, labeling them com0 and com1 and then putting the ast in and calling the ports it has com2-com5? Finally, I notice that the sample configuration line for the AST board has it using irq 3. If the board is set to use a different interrupt, can you change the config line to match and expect it to work? Also, should sharing of interrupts be enabled or disabled? -thanks P.S. Anyone who has written a device driver for NetBSD and who would be willing to explain to me the intricacies of getting an interrupt handler to work, please feel free to send me private e-mail. My back-ported driver seems pretty close, but I'm having trouble with the interrupt routines which are ttys. -thanks -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:43:08 1994 From: Scott Reynolds Subject: Re: MAP_FILE in /usr/include/sys/mman.h To: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu cgd> MAP_FILE shouldn't be used; it's been deprecated. mmap() now cgd> considers things files, unless specified otherwise. Well, OK, I'll buy this, but there are two things that point to the need for MAP_FILE... in /usr/include/sys/mman.h there *is* a reference to the non-existent MAP_FILE value, and in mmap(2) it's explicitly named. If the default behavior is MAP_FILE, then it seems that both the .h and manpage need to be changed. Also it's not very clear exactly what should be used in place of something like this: base = (pointer)mmap(..., MAP_FILE, ...); >From looking at mman.h I would suspect that it's now "proper" to specify one of MAP_SHARED, MAP_PRIVATE, or MAP_COPY. Is this correct? If none of these is specified, which, if any, is the default? Not being very familiar with the internals of the vm system, things got pretty hairy when I tried to figure out for myself in vm/vm_mmap.c... --scott From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:43:27 1994 From: der Mouse To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages Sender: owner-current-users@sun-lamp.cs.berkeley.edu [comment in setreuid() kernel implementation] >> /* >> * we assume that the intent of setting ruid is to be able to get >> * back ruid priviledge. So we make sure that we will be able to >> * do so, but do not actually set the ruid. >> */ > My understanding is that this is the way it's supposed to be, > according to POSIX. Does POSIX specify a setreuid() with this (mis)behavior? der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:43:41 1994 From: Duncan McEwan To: John Kohl Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: pms mouse driver <199407190441.AAA26878@kolvir.blrc.ma.us> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The pms driver generates what appears to be MouseSystems mouse output :) That wasn't the reason it wasn't working for me. The version I was using, which was the one Charles initially posted to the mailing list was generating completely bogus output (the top 5 bits of the first byte of every packet were always all set, so XFree86 didn't recognise any packet as valid). Once I switched to the newer version off sun-lamp (and remade the change in order the interupts were turned off and fixed the reversed dy bug), it worked fine. I just checked the XFree86 sources, and it appears that the protocol used by both mousesystems and busmouse mice are identical except that the mousesystems protocol makes use of bytes 3 and 5 of each 5 byte package in calculating dx and dy, whereas the busmouse ignores them. Since the pms driver always sets bytes 3 and 5 to zero, I figured "busmouse" was more accurate! I have made another minor modification to the driver, although I'm no longer convinced that it is such a good idea ... :-) The current pms driver uses the low order two bits of the first byte from each mouse packet to map into three bits representing the state of three mouse buttons as follows: 00 => 111 no buttons down 01 => 011 left button down 10 => 110 right button down 11 => 010 left and right button down This means that if you want pressing both buttons to signifying the middle button, you have to use XFree86's "Emulate3Buttons" flag, which is irritatingly broken in that it causes presses of just the left or right buttons to not be acted on until another mouse event occurs. I modified the driver to produce '101' for the '11' case above. When used with the busmouse mouse type, this gives an "emulated middle button" behaviour without resorting to the Emulate3buttons flag. A patch for this is enclosed below... This may not be such a good idea, since it means the driver is lying about the true capabilities of the mouse. It also means that it is not possible to generate a "left and right button down" with this being interpreted as a "middle down" event by X (does this matter?). Finally, if you don't hit both buttons simultaneously (or close enough together) you get the left or right down event, closely followed by a middle down event. At least with my window manager (fvwm), this causes non-intuitive behaviour... I guess the problem should be fixed in XFree86, but from a quick look at the way mouse events are handled, I'm not sure that is possible... Anyway, here is the patch... *** pms.c.orig Wed Jul 20 15:22:37 1994 --- pms.c Wed Jul 20 15:21:25 1994 *************** *** 353,362 **** return error; } ! /* Masks for the first byte of a packet */ ! #define PS2LBUTMASK 0x01 ! #define PS2RBUTMASK 0x02 ! #define PS2MBUTMASK 0x04 int pmsintr(sc) --- 353,359 ---- return error; } ! int buttonmap[] = {0, BUT1STAT, BUT3STAT, BUT2STAT}; int pmsintr(sc) *************** *** 393,400 **** dy = (dy == -128) ? -127 : dy; state = 0; ! buttons = ((buttons & PS2LBUTMASK) << 2) | ! ((buttons & (PS2RBUTMASK | PS2MBUTMASK)) >> 1); changed = ((buttons ^ sc->sc_status) & BUTSTATMASK) << 3; sc->sc_status = buttons | (sc->sc_status & ~BUTSTATMASK) | changed; --- 390,397 ---- dy = (dy == -128) ? -127 : dy; state = 0; ! buttons = buttonmap[buttons & BUTSTATMASK]; ! changed = ((buttons ^ sc->sc_status) & BUTSTATMASK) << 3; sc->sc_status = buttons | (sc->sc_status & ~BUTSTATMASK) | changed; From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:45:08 1994 From: ejh@slueas.slu.edu (Eric J. Haug) To: current-users@sun-lamp.cs.berkeley.edu Subject: problem with page fault trap on i386 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a very recent current Jul-19. I have been abusing it by trying to compile X11R5. The sources are on a Sun, NFS mounted to the netbsd box. At seemingly random places the kernel was rebooting. I compiled again with ddb and obtained a trace The panic was a vm_fault, page fault trap code=0 nfs_timer+030 A trace command to the debugger yielded: nfs_timer() softclock() Xsoftclock() Xsoftnet() nfs_readrpc() nfs_doio() nfssvc_iod() nfssvc() syscall (number 155) Anyone have any thoughts? The computer is still in the debugger and will be left there for a bit if someone has some thoughts about the problem. This hardware setup has compiled the source tree several times The source is also nfs mounted. Hardware is a 486-33, wd0, ne2000, 32Mb memory, com0,1 lpt0, et4000 clone Swap is only 24 megs or so. eric From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:45:28 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Please help a new NetBSD wannabe hacker upgrade to current... 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 know, I know, all of you out there are thinking: "Goddamnit!! Why the hell is some idiot asking this same question? It's in some FAQ somewhere, somehow, why doesn't he just read something for once?" Well, I am very sorry, but these are questions that I have been wanting to ask for a long time, but was afraid that the heat of the flames I would receive would scar me for life. But, after many, many weeks of pondering, I am in a deadlock. I heartily apologize if this is not the correct place to lay my questions, but here goes: Please keep in mind that I have an intermediate knowledge of UNIX and sys admin stuff, so I am not a complete idiot, and I have read every single FAQ to death about BSD, and have followed the newsgroups, yet still have some questions to ask: 1. In one thing I read, it says to get a current system from scratch, you must first get a "mini-NetBSD" system running using just the three install floppies from NetBSD-0.9, and then get the latest binary snapshot onto the computer. Question is: HOW DO I GET THE DAMN FILES (WHICH ARE HUGE!!) ONTO MY COMPUTER, EXACTLY, WHAT WAY?? Everyone assumes that one has a T1 connection to the internet, which I don't have. I have a modem connection, which makes it impossible to get the binaries onto my mini-NetBSD system. First of all, when you install from scratch JUST FROM THE INSTALL FLOPPIES FROM -0.9, com 4 is not configured into the kernel, the /dev file for tty03 does not even exist, and you cannot MAKEDEV one since chown does not come on the disks. Thus, my modem cannot be accessed since it is on comm 4. I can't even tip to it, since I don't have an /etc/remote file, and no vi to make one up, which doesn't matter anyway, since there is no possible way to connect to my modem. Secondly, you cannot access a dos partition from NetBSD-0.9, so that elimnates downloading it through dos and then cp'ing it to my NetBSD system. Thus, how do you even get the binaries onto the computer if you can't ftp or access the modem?? There must be some way to do this! 2. What is the EXACT route to getting current installed once the binaries for the current snapshot are in place on the system? Which ones do I unpack first and how do I do it? How do I write the new bootblocks and all that? I hope to God that someone answers this with some halfway detailed info. I've been wanting to run a NetBSD-current system for months on end, but never was able to overcome these problems. I've already run FreeBSD (all versions) for some time now, and just feel the need to switch to something new (and anyways, a highly esteemed friend of mine who works at Sun recommended NetBSD over FreeBSD!!!) I would like to thank anyone who can spare the time to read this LONG message, and will personally give them a kiss on the cheek for my heartfelt thanks. ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:46:33 1994 From: John Kohl To: cgd@alpha.bostic.com Cc: cgd@alpha.bostic.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu OK, OK, I get it now. My assumption was that I could fix it _without diddling the Kerberos library_. My conclusion now is that I must change the Kerberos library. I'm sure I can get it right now :( ==John From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:50:11 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: porting AFS (Andrew File System) to current (1.0-ALPHA)? X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anybody done prior work to port AFS to NetBSD-current (either an old current or a current current)? I'm probably going to start doing it, but don't want to duplicate work. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 00:54:47 1994 To: Mark Steven de Sagun-Tamola Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Please help a new NetBSD wannabe hacker upgrade to current... From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Calm down. I get the binaries and sources loaded either by writing them on dozens of floppies, or by writing them to QIC-150 tapes (since my home system now has a tape drive). If there isn't even one single system at the UW with both an Internet connection and a floppy drive, perhaps you can get someone to make up a set of floppies (IF you can manage to ask more politely than your message did). I'm months behind on -current, and probably won't upgrade till I get my next disk drive, so don't ask me. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:00:51 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: porting AFS (Andrew File System) to current (1.0-ALPHA)? <9407202014.AA03598@banana> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Has anybody done prior work to port AFS to NetBSD-current (either an old > current or a current current)? > Nope. > I'm probably going to start doing it, but don't want to duplicate work. > > ==John Cool. I gather this would be using the pre-Transarc AFS source? What are the distribution restrictions on that? later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:10:41 1994 From: danfuzz@wastelands.kaleida.com (Dan Bornstein) To: current-users@sun-lamp.cs.berkeley.edu Subject: New kernel and an old filesystem Content-Length: 709 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I was using the 5/3 build and decided to move on to the 1.0-alpha. Everything went smoothly, until I went to rebuild the kernel for my particular needs (gateway option mainly); the build seemed to do fine until I rebooted...at which point my /usr partition seems to have gotten screwed up. I had to do a manual fsck, and even after that, every reboot seems to mess up more files. Since I haven't heard about any other such reports, I assume I have a funky configuration; the obvious weirdness is that my disks are still in the old format. They won't be for long though--I'll be reformatting them in the hopes that it'll solve my problem. But, whatever the case, there *is* a bug of some sort in there. -dan From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:16:57 1994 To: der Mouse Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages <199407201152.HAA02252@Collatz.McRCIM.McGill.EDU> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does POSIX specify a setreuid() with this (mis)behavior? No, POSIX doesn't specify a setreuid() at all, because the entire concept of setreuid() goes against one of the basic tenets of either POSIX security model: you can't set the real uid w/o also setting the effective uid. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:17:58 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: no com ports in GENERIC* kernels?? From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu It looks like both the GENERICBT and GENERICAHA kernels have slip interfaces configured into them, but no com ports?! Is this an accident? I'm trying to currentize my system from the May 1 sources, and it's becoming a real pain in the ass, since the source tarballs from this past weekend won't build a kernel (lots of symbols like P_BACK are referenced in genassym.c, but are defined nowhere that I can find). I can't build a new kernel, and the supplied one in the binary dist has no serial ports. And my old (May 1st) kernel hangs whenever I try to push slip or ppp thru it too hard. And "term" sucks rocks through a straw (it dies with even moderate traffic [114 does; 118 won't let me run sup to a priv'd port anymore]). So, I have no way to sup. So, can someone look at the GENERIC kernels and put a serial port or two back in them? And, hopefully the source tarballs this weekend will get made without any problems, and maybe I'll be able to build a kernel with them. (I already unpacked all the userland binaries.) --Michael P.S. Current (July 12) fsck also freaked out on my SCSI /usr partition, which had been working fine on the May 1 system, after it had been working under the July 12 kernel fine for a few hours and I rebooted. It complained about a corrupted directory, but only gave the name as "DIR=?" (it also complained about lost+found being corrupted). Then, after complaining about these two dirs, each time it promptly proceeded to get a segmentation violation. I rmdir'd the lost+found dir, which made it happy, but I couldn't even tell what the other dir was that it was talking about. And every time it hit that dir it died with a segv. I was only able to get that drive to pass fsck clean by fsck'ing it a couple times under my alternate IDE boot drive running the May 1 kernel and binaries (including fsck). The older fsck called that "DIR=". It seems the 4.4 version of fsck has a null pointer dereferenced somewhere if it gets strange dir entries, that didn't happen under the older fsck. Sorry I can't provide any more detailed debugging info since the machine wasn't exactly in a stable state at the time. Is this a known problem, or is my machine just screwey? ----------------------------------------------------------------------------- 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 Jul 21 01:20:18 1994 To: ejh@slueas.slu.edu (Eric J. Haug) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problem with page fault trap on i386 <9407201835.AA22965@slueas.slu.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > nfs_timer() > softclock() > Xsoftclock() > Xsoftnet() > nfs_readrpc() > nfs_doio() > nfssvc_iod() > nfssvc() > syscall (number 155) I've seen this identical trace, here on my 386-20... umm, could you do something with it: look at the offset into nfs_readrpc(). examine/i nfs_readrpc+(that offset minus a instructions) and hit return until you get to that offset. what's the last thing _before_ the instruction at that offset? (my personal bet is a call to nfs_request().) thanks. chris From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:30:20 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: "Michael L. VanLoon" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: no com ports in GENERIC* kernels?? Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Michael L VanLoon writes: > P.S. Current (July 12) fsck also freaked out on my SCSI /usr > partition, which had been working fine on the May 1 system, after > it had been working under the July 12 kernel fine for a few hours > and I rebooted. It complained about a corrupted directory, but > only gave the name as "DIR=?" (it also complained about > lost+found being corrupted). Then, after complaining about these > two dirs, each time it promptly proceeded to get a segmentation > violation. I rmdir'd the lost+found dir, which made it happy, > but I couldn't even tell what the other dir was that it was > talking about. And every time it hit that dir it died with a > segv. I was only able to get that drive to pass fsck clean by > fsck'ing it a couple times under my alternate IDE boot drive > running the May 1 kernel and binaries (including fsck). The > older fsck called that "DIR=". It seems the 4.4 version of fsck > has a null pointer dereferenced somewhere if it gets strange dir > entries, that didn't happen under the older fsck. Sorry I can't > provide any more detailed debugging info since the machine wasn't > exactly in a stable state at the time. Is this a known problem, > or is my machine just screwey? i have the exact same problem... so its not just me? i havent hunted it down yet since a.) for a while i was screwed by the disklabel thing and b.) i've been recently trying to use my system for work, so dont want to tinker and lose everything. -bri From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 01:36:31 1994 To: Mark Steven de Sagun-Tamola Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Please help a new NetBSD wannabe hacker upgrade to current... 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 >1. In one thing I read, it says to get a current system from scratch, >you must first get a "mini-NetBSD" system running using just the three >install floppies from NetBSD-0.9, and then get the latest binary snapshot >onto the computer. Question is: HOW DO I GET THE DAMN FILES (WHICH ARE >HUGE!!) ONTO MY COMPUTER, EXACTLY, WHAT WAY?? Everyone assumes that one >has a T1 connection to the internet, which I don't have. I have a modem >connection, which makes it impossible to get the binaries onto my >mini-NetBSD system. First of all, when you install from scratch JUST >FROM THE INSTALL FLOPPIES FROM -0.9, com 4 is not configured into the >kernel, the /dev file for tty03 does not even exist, and you cannot >MAKEDEV one since chown does not come on the disks. Thus, my modem >cannot be accessed since it is on comm 4. I can't even tip to it, since >I don't have an /etc/remote file, and no vi to make one up, which doesn't >matter anyway, since there is no possible way to connect to my modem. >Secondly, you cannot access a dos partition from NetBSD-0.9, so that >elimnates downloading it through dos and then cp'ing it to my NetBSD >system. Well, you can enable com4 by recompiling the kernel (if you don't have enough space to recompile the kernel, then you probably don't have enough space to to run -current). You can also access a msdos partition by using the msdos filesystem (surprise :-) ), but it's not well documented. Basically, you have to add a new parition using disklabel that has the same geometry as your MS-DOS parition (which you can determine by running the NetBSD fdisk), configure msdosfs into your kernel (if it wasn't already) and then mount it. I did it all the time under 0.9, so I know it works. E-mail me if you want more specific info. >2. What is the EXACT route to getting current installed once the >binaries for the current snapshot are in place on the system? Which ones >do I unpack first and how do I do it? How do I write the new bootblocks >and all that? You don't have to install new boot blocks to run -current. I posted what I felt was a fairly complete set of instructions to upgrade using the binary snapshots to this list a little while back; you can either get it out of the archives or send me mail if you want another copy. (If you do want to install new bootblocks, I believe it's "cd /usr/mdec; make install"). --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 02:12:34 1994 From: Mike Long To: buckwild@u.washington.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Please help a new NetBSD wannabe hacker upgrade to current... Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Wed, 20 Jul 1994 01:35:57 -0700 (PDT) >From: Mark Steven de Sagun-Tamola >1. In one thing I read, it says to get a current system from scratch, >you must first get a "mini-NetBSD" system running using just the three >install floppies from NetBSD-0.9, and then get the latest binary snapshot >onto the computer. Question is: HOW DO I GET THE DAMN FILES (WHICH ARE >HUGE!!) ONTO MY COMPUTER, EXACTLY, WHAT WAY?? Everyone assumes that one If I remember correctly, both 'mread' (part of mtools) and 'kermit' (command-line interface only) are stashed in that mini-NetBSD system somewhere. On further thought, mread HAS to be there, or the load_fd shell function would never work. Look at the install scripts to see where these binaries are. Why can't you move your modem to COM1 or COM2 for the install process? >2. What is the EXACT route to getting current installed once the >binaries for the current snapshot are in place on the system? Which ones >do I unpack first and how do I do it? How do I write the new bootblocks >and all that? I can't give you "EXACT" directions, since it's been 10 months since I installed 0.9; but try the following: 1) Create a directory under /usr, e.g. /usr/new. Unpack (tar zxf) the snapshot files under there. 2) Use 'shutdown' to enter single-user mode. 3) Copy /bin/sh, /bin/mv, /sbin/sync, /sbin/umount, and /sbin/reboot (possibly /bin/cp and others, too, I dunno) to /tmp. 4) exec /tmp/sh. 5) /tmp/mv /netbsd /onetbsd;/tmp/mv /usr/new/netbsd-* /netbsd 6) /tmp/mv /usr/new/bin/* /bin;/tmp/mv /usr/new/sbin/* /sbin; &c. (move them ALL to their proper location, but NOT /etc) 7) /tmp/sync;/tmp/umount /usr;/tmp/reboot 8) tell bootblock to boot single-user with -s 9) cross fingers, hold breath, etc. A) update /etc file-by-file B) reboot multi-user. ...or something like that. Supposedly -current can run with 0.9 bootblocks, so don't bother with them until you get your system up and running. This is the procedure I plan to try if I ever go through this process. I'm sure someone will let me know if it's grossly wrong. >I would like to thank anyone who can spare the time to read this LONG >message, and will personally give them a kiss on the cheek for my >heartfelt thanks. I can do without the kiss, thanks anyway. [egotistical .sig deleted] -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 02:36:27 1994 To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: no com ports in GENERIC* kernels?? <9407200737.AA04721@ponderous.cc.iastate.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I'm trying to currentize my system from the May 1 sources, > and it's becoming a real pain in the ass, since the source tarballs > from this past weekend won't build a kernel (lots of symbols like > P_BACK are referenced in genassym.c, but are defined nowhere that I > can find). It sounds like thre's something seriously wrong with the copy of the tarballs you got (or maybe the tarballs themselves). genassym builds just fine for me, and has for months... > So, can someone look at the GENERIC kernels and put a serial port or > two back in them? And, hopefully the source tarballs this weekend > will get made without any problems, and maybe I'll be able to build a > kernel with them. (I already unpacked all the userland binaries.) there are already plenty: /sys/arch/i386/conf/GENERICAHA: device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 5 /sys/arch/i386/conf/GENERICBT: device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 5 i dunno why they don't work for you -- they definitely work for me: NetBSD 1.0-ALPHA (GENERICAHA) #1: Tue Jul 12 18:17:26 PDT 1994 cgd@sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/compile/GENERICAHA CPU: i386DX (386-class CPU) real mem = 4194304 avail mem = 3031040 using 76 buffers containing 311296 bytes of memory pc0 at isa0 port 0x60-0x6f irq 1: color com0 at isa0 port 0x3f8-0x3ff irq 4: ns82450 or ns16450, no fifo lpt0 at isa0 port 0x378-0x37f irq 7 wdc0 at isa0 port 0x1f0-0x1f7 irq 14 wd0 at wdc0 drive 0: 100MB 776 cyl, 8 head, 33 sec fdc0 at isa0 port 0x3f0-0x3f7 i 6 dE 2 fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec ed0 at isa0 port 0x280-0x29f iomem 0xd0000-0xd1fff irq 9: address 00:00:c0:21:20:14, type WD8003E (8-bit) ie0: unknown AT&T board type code 0 ie0: can't map 3C507 RAM in high memory npx0 at isa0 port 0xf0-0xff irq 13 biomask 4040 netmask 212 ttymask 12 it's only got one serial port, and that one's detected just fine. chris From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 02:37:32 1994 From: Andrew Cherry To: David Jones Subject: Re: Son of unexpected trap <94Jul20.165953edt.19149@picton.eecg.toronto.edu> Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu David Jones writes: > > Again, my set up is A2000, GVP G-Force 040 with 12MB RAM. The only other > > card is the IOExtender. Also, a kernel compiled from 7/13/94 sources > > (possibly 7/12) boots fine. > > What happens if you remove the IOExtender? Same thing happens with or without the IOExtender. While I had the box open, I tried a bunch of different configs. My complete hardware configuration is: Boards: G-Force 68040 w/12MB RAM, IOExtender, Flicer-Free Video 2 Drives: Seagate ST31200N (1 gig, SCSI ID 0) Quantum PD105S (100 meg, SCSI ID 1) 1MB CHIP (No, I didn't forget to mention my tape drive. That's my next purchase. Until then, I'm living dangerously.) I have tried removing the IOExtender. I've tried swapping the G-Force with a GVP 22MHz 030 Combo (5MB RAM), and taking out the IOExtender. I have also tried going without the Seagate and without the Quantum (but not without both!). The only thing I haven't done is remove the Flicker Free Video 2 (it's a pain). I don't think it is very likely that the FFV2 is the problem, since the Amiga doesn't actually see it; it just sits between the Denise and its socket, and taps the signals. Anyway, all of the above setups result in an unexpected trap. It always occurs somewhere in configure(), but in some of the setups above, it didn't happen in setroot(). Well, I'll keep trying. :-) Perhaps something is going wrong during compilation? I don't get any compile errors, but it is possible that something is being munged. Is anyone else with an A2000 and a GVP accelerator running a currrent kernel? -Andrew Cherry (cherry@mcs.anl.gov) From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 04:21:47 1994 From: John Kohl To: cgd@alpha.bostic.com Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: those annoying "set*uid is deprecated" messages X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu FYI, I am able to do just about everything I wanted to just using seteuid(), so I'm basically happy with the way things stand. [I even got to rewrite some code to drop root privs earlier than it used to :] ==John From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 04:22:54 1994 From: Dave Burgess Subject: Re: no com ports in GENERIC* kernels?? To: michaelv@iastate.edu (Michael L. VanLoon -- Iowa State University) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2988 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > It looks like both the GENERICBT and GENERICAHA kernels have slip > interfaces configured into them, but no com ports?! Is this an > accident? I'm trying to currentize my system from the May 1 sources, > and it's becoming a real pain in the ass, since the source tarballs > from this past weekend won't build a kernel (lots of symbols like > P_BACK are referenced in genassym.c, but are defined nowhere that I > can find). > > I can't build a new kernel, and the supplied one in the binary dist > has no serial ports. And my old (May 1st) kernel hangs whenever I try > to push slip or ppp thru it too hard. And "term" sucks rocks through > a straw (it dies with even moderate traffic [114 does; 118 won't let > me run sup to a priv'd port anymore]). So, I have no way to sup. > I had no problems building a new kernel from Friday Night. Drop by this weekend and I'll give you a tape with everything you want, or a floppy with your very own CUSTOM kernel on it (bring a config file). > So, can someone look at the GENERIC kernels and put a serial port or > two back in them? And, hopefully the source tarballs this weekend > will get made without any problems, and maybe I'll be able to build a > kernel with them. (I already unpacked all the userland binaries.) > > --Michael > > P.S. Current (July 12) fsck also freaked out on my SCSI /usr > partition, which had been working fine on the May 1 system, after it > had been working under the July 12 kernel fine for a few hours and I > rebooted. It complained about a corrupted directory, but only gave > the name as "DIR=?" (it also complained about lost+found being > corrupted). Then, after complaining about these two dirs, each time > it promptly proceeded to get a segmentation violation. I rmdir'd the > lost+found dir, which made it happy, but I couldn't even tell what the > other dir was that it was talking about. And every time it hit that > dir it died with a segv. I was only able to get that drive to pass > fsck clean by fsck'ing it a couple times under my alternate IDE boot > drive running the May 1 kernel and binaries (including fsck). The > older fsck called that "DIR=". It seems the 4.4 version of fsck has a > null pointer dereferenced somewhere if it gets strange dir entries, > that didn't happen under the older fsck. Sorry I can't provide any > more detailed debugging info since the machine wasn't exactly in a > stable state at the time. Is this a known problem, or is my machine > just screwey? > I had the same thing happen to my root partition; I thought it was from the 1522 SCSI controller experiment. I eventually had to newfs the root partition and start over from scratch. I also didn't have an older fsk to fix the disk with, so I was really stuck. Other than that, the segfault, etc. sounds precisely like the symptoms that I was experiencing. I tried everything else I could think of and the goofy thing would not clear the bad spot nor complete reliably. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 05:59:21 1994 X-Authentication-Warning: buchanan07.res.iastate.edu: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu From: gendalia@buchanan07.res.iastate.edu (Tracy J. Di Marco) Subject: ftpd/Makefile Sender: owner-current-users@sun-lamp.cs.berkeley.edu This is broken, and has been for a while, as ftpd doesn't compile without my modifying the Makefile. The fix for this was sent in a while ago, could someone please add it to the standard source so that I don't have to re-edit the Makefile every time I sup new sources? explorer@vorpal.com sent in: |The .if defined(KERBEROS) conditional needs |SRCS+= klogin.c |added to make it go with Kerberos. Thanks Tracy gendalia@buchanan07.res.iastate.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 06:24:54 1994 From: haggerty@acf2.NYU.EDU (Bruce Haggerty) To: current-users@sun-lamp.cs.berkeley.edu Subject: -current boot blocks wanted Sender: owner-current-users@sun-lamp.cs.berkeley.edu Could someone please send me a binary copy of the current boot blocks? Oh, while I'm on the topic -- what would be the appropriate dd command to install them? Many Thanks -b. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 07:42:56 1994 From: chopps@emunix.emich.edu To: Bill Squier Cc: amiga@sun-lamp.cs.berkeley.edu Subject: Re: More investigation into SIGSEGV wierdness. <94Jul20.131901edt.5155@menger.eecs.stevens-tech.edu> X-Mts: smtp Sender: owner-amiga@sun-lamp.cs.berkeley.edu I bet you have a GVP acclerator and another expansion board. Keep the accelerator toss any expansion boards (with ram) and it will work fine. Oh and if you have external scsi that is trying to DMA into the GVP accelerator's memory that loses too. All in all GVP loses. I discovered this. I have 2 of them here. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 08:00:48 1994 From: mycroft@gnu.ai.mit.edu (Charles M. Hannum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Mysterious lossage fixed Sender: owner-current-users@sun-lamp.cs.berkeley.edu If you've been experiencing what could best be termed as `mysterious lossage' with recent kernels, you may have been bitten by a bug that I tracked down earlier today to the epprobe() routine. Basically, it was trying to write to a port in each EISA slot before identifying the card, which is wrong, and which, on an ISA-only machine, ended up wrapping around to one of the registers on the first DMA controller. This could likely cause a variety of problems; the one I saw was a vm_fault() panic in tsleep() right after configuring root. If you think you might have run into this, please try again, and sorry for the inconvenience (though I'm not responsible for that code). From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 08:50:27 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Setreuid in perl-4.036 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anyone done a proper job of fixing suidperl for NetBSD current? If not, I'll do it. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 08:51:17 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: NetBSD and X on Mac PB 170? Sender: owner-current-users@sun-lamp.cs.berkeley.edu A friend of mine has a Mac Powerbook 170 with 8mb of RAM. Will NetBSD/Mac run on this machine? Also, is there a port of X11 available which will run on it? Thanks, Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 09:07:07 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: 0.9 -> current upgrade instructions (repost) 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 A number of people have asked me for these, so I'm sending 'em again. Comments are welcome. Enjoy! UPGRADING TO NETBSD-CURRENT FROM 0.9 (tested under i386 ONLY) BACK UP YOUR DATA FIRST (unless you like living on the edge) Download the latest binary snapshot, available off of your favorite NetBSD ftp site, and put the resulting files on your hard drive somewhere (if you don't have enough space to hold them all, you shouldn't be running -current). You should get all the *.gz files and the generic kernels (you only need the generic kernel appropriate for your system). Copy the -current generic kernel into root, calling it "netbsd.new" or something similar. Also copy the zcat and tar binaries into another location (I personally used /var/tmp). It would also be a good idea to back up all the files you've changed in /etc, if you haven't already done so. Boot the machine using this kernel into single-user mode (using the "-s" switch at the boot prompt). The machine should come up with no problems. If it doesn't come up normally, then you've got a serious problem, and should probably not try to upgrade. Commands that look in the kernel like "ps" won't work, but things like "ls" and "tar" should be fine. If you're paranoid, you might want to spend a few minutes browsing around the system making sure everything works reasonably well (but most importantly that zcat and tar work). NOTE: Since you booted single-user, you'll need to remount root read-write (mount -u /) and mount the rest of the filesystems (mount -a, or whatever is appropriate for you). YOU ARE ON THE BRINK OF NO RETURN!! Ok, ready? Sitting in root, use the copies of gzip and tar you saved to extract out the binaries distributions over the current system binaries. Use something like: cd / /var/tmp/zcat /your/gzip/file/here | /var/tmp/tar --extract --verbose \ --unlink --file - In case you're wondering, the --unlink is necessary to make sure binaries that are being used get replaced and that symlinks get updated correctly. The order that you do this stuff in really isn't important, but I would do bin and sbin, then lib, libexec, usr/bin, usr/sbin, and then the rest. If you want to reassure yourself that things are working, you can see if the binaries in /bin and /sbin work; again, things that use the kernel will NOT work, but other binaries should work fine. The shared binaries in /usr/bin and /usr/sbin will NOT work until you have extracted /usr/lib and /usr/libexec. After you've extracted everything, run sync a few times, unmount all your filesystems (except /, obviously) and reboot. Hold your breath ... The system should boot fine. If it didn't, well, you're fucked. Get out your backup and try again (you DID make a backup and still have the installation floppies, right?). You'll probably need to merge the changes you made in /etc with what's there now. Go ahead and do that now. Now, you're running current. You can either live with the binary distribution you have and be happy, or upgrade to the latest source tree. You'll need to upgrade to the latest source tree if you want to compile a new kernel. I can't give you a well-defined procedure because it's a lot trickier, but here is a general guideline: extract all the sources (the are done relative to /usr). first off, install the include files (cd /usr/src/include; make install). It's a good idea to remove the ENTIRE /usr/include hiearchy, otherwise you'll have weird problems when it comes time to build groff. Try building a new kernel; you might need to install a new config to do this (I didn't have to). You also might need to install other utilities to get this to work; I had to install a new /bin/sh, since the old one had a bug that was tickled by the kernel compile. Assuming this works, boot using your new kernel (but SAVE THE OLD ONE!). You might have to boot single user (lpd from the binary snapshot caused my new kernel to panic; go figure :-) ). Compile new libraries out of /lib and install them. See if you can compile programs using your new shared and static libraries. Compile and install a new gcc, gas, and ld. Compile and install everything else. (Note: don't attempt the above unless you really know what the hell you are doing. Save backup copies of the kernel and the tar and zcat binaries so you can undo any screwups that you do) These above instructions have worked for me; I can't guarantee that they will work for you. But I'd like to hear about it if you have problems. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 09:12:36 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: latest boot blocks don't like old root partitions X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I finally got the machine I'm working on set up with the latest boot blocks. If you put up the new blocks and then boot and end up with a hung machine after the twiddling ended with the "-" character, you most likely don't have a 4.4BSD boot partition. The bootblocks only understand the new file system format, and wegde with other file system formats. To find out what you have, use the "dumpfs" command: dumpfs /dev/wd0a |head and it'll say on the second line either "4.2/4.3BSD" or "4.4BSD". It must be the latter. If there's room in the boot code, perhaps it can check the difference and spit out an error message...I'll give that a try with a floppy and see if it works. ==John From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 09:12:37 1994 To: chopps@emunix.emich.edu Cc: Bill Squier , amiga@sun-lamp.cs.berkeley.edu Subject: Re: More investigation into SIGSEGV wierdness. <9407210424.AA15357@emunix.emich.edu> From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu In message <9407210424.AA15357@emunix.emich.edu>, chopps@emunix.emich.edu writes: >I bet you have a GVP acclerator and another expansion board. >Keep the accelerator toss any expansion boards (with ram) and >it will work fine. Oh and if you have external scsi that is >trying to DMA into the GVP accelerator's memory that loses >too. All in all GVP loses. I discovered this. I have 2 of them >here. Well surprise, surprise-- that's exactly what I do have :-) Older GVP accel (IDE available on it, no SCSI) @33Mhz, 8MB of 1x8 GVP SIMMs. GVP Series II SCSI/8 (with NO ram installed) Originally, with RAM, and that bit me _HARD_. Internal drives: Quantum 240MB, Seagate 80MB (ST296N :-) ) External drive: Seagate 500MB (forget model) DMA enabled. However, I ran a memtester under AmigaDOS, and it started coming up with bad memory at one particular point (about 4MB in). So I reversed the SIMMs (actually, took 1-4, and put them in banks 5-8, and put 5-8 in 1-4) and blew the dust out, and made sure the contacts were spiffy-- and the mem failures went away (10 memtests in a row produced no problems). So, now I sit rebuilding the world under NetBSD. We shall see. If it turns out that this still sucks, can you recommend something nice for a 2000 that allows >8MB (preferably up to 32MB) of REAL honest to goodness 72-pin industry standard SIMMs and has a supported SCSI adapter? (ie, what are _YOU_ using? ;-) ) > >Chris. > From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 09:48:46 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: serial stuff Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Imagine, if you will, tty00 being used for something other than a (C)SLIP/PPP link, but as an actual dial in. Granted it took me a while to figure out to strap the modem into "dumb" mode, otherwise it would hang up the moment there was a 'RING'. So, I figure, ok... I have a BBS you can telnet/rlogin to, so I can now offer a NetBSD login: with a script login for doing an rlogin -8 -E bbsmachine. This works wonderfully. So, I try a Zmodem upload to the BBS (via the NetBSD dialin).. works beautifully.. getting ~3800cps on a reasonably compressed file, with the serial port at 57600. Now, the bad news... I downloaded, and found that I was getting errors... to the point that the xfer was giving up. I noticed that the NetBSD machine had buffered a whole bunch of stuff, and was just spewing it, even though my terminal was requesting a block resend. So, I noticed that we have a pretty hefty buffer being setup for the serial port... has anyone played with it for doing high speed xfers, and if so, please tell me what I have set up wrong. On the converse, has anyone changed the buffer sizes to see what the differences are? Cheers. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 10:22:13 1994 From: ivan@darwin.bu.edu (Ivan Vazquez) To: bdc@ai.mit.edu (Brian D. Carlstrom) Cc: "Michael L. VanLoon" , current-users@sun-lamp.cs.berkeley.edu Subject: Current fsck trashes old filesystems <9407201539.AA04286@blackjack> Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>>> Michael L VanLoon writes: > > P.S. Current (July 12) fsck also freaked out on my SCSI /usr > > partition, which had been working fine on the May 1 system, after > > it had been working under the July 12 kernel fine for a few hours > > and I rebooted. It complained about a corrupted directory, but > > only gave the name as "DIR=?" (it also complained about > > lost+found being corrupted). Then, after complaining about these > > two dirs, each time it promptly proceeded to get a segmentation > > violation. I rmdir'd the lost+found dir, which made it happy, > > but I couldn't even tell what the other dir was that it was > > talking about. And every time it hit that dir it died with a > > segv. I was only able to get that drive to pass fsck clean by > > fsck'ing it a couple times under my alternate IDE boot drive > > running the May 1 kernel and binaries (including fsck). The > > older fsck called that "DIR=". It seems the 4.4 version of fsck > > has a null pointer dereferenced somewhere if it gets strange dir > > entries, that didn't happen under the older fsck. Sorry I can't > > provide any more detailed debugging info since the machine wasn't > > exactly in a stable state at the time. Is this a known problem, > > or is my machine just screwey? The pattern I have gone through is: - Bring a machine up to 0.9a (May 2) using floppies, - Download and extract all the current binaries, - reboot - during initial fsck it goes into the " DIR=?" problem and starts corrupting the fs. This current problem makes it require extraordinary measures to bring a new machine up to current because the only existing floppy images are 0.9. Would someone in the know care to make some new ones available? They would allow people to install Current (and test it). People running Current may be able to test this by booting off of the distributed (0.9) floppies and newfs'ing a partition, then doing lots of file writing and fscks on that partition under Current. I hope this tickles the bug. Thanks! Ivan From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 10:47:08 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Setreuid in perl-4.036 <199407210446.AAA28721@cis-ts3-slip4.cis.brown.edu> From: matthew green Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Has anyone done a proper job of fixing suidperl for NetBSD current? > >If not, I'll do it. it may not be worth it - perl5 is almost beta, and from the looks of it, it's not going to be beta for very long. there won't be another perl4 release, so unless your fixed version goes in to the othersrc tree, it may not be worth it. on another note: whats the proper way to deal with perl's use of semctl() that conflicts with the netbsd header files? (i don't have the error message handy, something about the last argument perl passes not being a union semun or soemthing). .mrg. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 11:18:02 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: Byteorder bogon in netiso/tp_tpdu.h To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1333 Sender: owner-current-users@sun-lamp.cs.berkeley.edu tp_tpdu.h messes 'round with BYTE_ORDER if it is not defined. a) if BYTE_ORDER is not defined, tp_tpdu.h will #define it wrong in nearly all cases. b) I think BYTE_ORDER will always be defined because netiso-sources #include sys/types.h and stuff. I cannot test it at the moment. If they don't do it, tp_tpdu.h should include . a + b => we do not need this ugly stuff: *** /usr/NetBSD-current/usr/src/sys/netiso/tp_tpdu.h~ Wed Jul 20 00:09:09 1994 --- /usr/NetBSD-current/usr/src/sys/netiso/tp_tpdu.h Wed Jul 20 00:09:25 1994 *************** *** 69,90 **** #ifndef _NETISO_TP_TPDU_H_ #define _NETISO_TP_TPDU_H_ - #ifndef BYTE_ORDER - /* - * Definitions for byte order, - * according to byte significance from low address to high. - */ - #define LITTLE_ENDIAN 1234 /* least-significant byte first (vax) */ - #define BIG_ENDIAN 4321 /* most-significant byte first (IBM, net) */ - #define PDP_ENDIAN 3412 /* LSB first in word, MSW first in long (pdp) */ - - #ifdef vax - #define BYTE_ORDER LITTLE_ENDIAN - #else - #define BYTE_ORDER BIG_ENDIAN /* mc68000, tahoe, most others */ - #endif - #endif /* BYTE_ORDER */ - /* This much of a tpdu is the same for all types of tpdus (except * DT tpdus in class 0; their exceptions are handled by the data * structure below --- 69,74 ---- jan From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 11:18:07 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: Are you in touch with the XFree-Core-Team ? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 284 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello Core-Team, it think it is a good idea to info David Wexeblatt et al of the upcoming NetBSD-1.0 release so that they can put proper support for it in XFree-3.1. I don't know how far they are with it but it would be bad if XFree-3.1 has no proper NetBSD-1.0 support. Jan From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 11:27:04 1994 From: mycroft@gnu.ai.mit.edu To: jan@encap.hanse.de Subject: Re: Byteorder bogon in netiso/tp_tpdu.h Cc: cgd@sun-lamp.cs.berkeley.edu, current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu b) I think BYTE_ORDER will always be defined because netiso-sources #include If it's already defined, then the stuff in tp_tpdu.h wouldn't matter. I think it's pretty clear that stuff should be removed, but I'll have to make sure it still compiles. Are you trying to use netiso? Have you had any success? From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 13:21:07 1994 From: ledl@dax1.w7.ipp-garching.mpg.de (Ledl Ludwig 2686) To: amiga@sun-lamp.cs.berkeley.edu Subject: Installation problems with 940709 snapshot: SOLVED Sender: owner-amiga@sun-lamp.cs.berkeley.edu My fear proved to be true: just gimme a hard reboot (= sleep on it) and I recognize my mistake: NEVER EVER MIX UP BLOCK NUMBERS WITH START CYLINDER NUMBERS !!! ('dcp -ds 25500' instead of 'dcp -ds 100' !) Sorry for the misused bandwidth. My second problem (not even posted) with "statistical" 'unsuitable root' errors is solved too: for security I sometimes disconnected during installations my second IDE drive (it is jumpered as slave) so that it will be timed out by the controller. Even if there is a correct rootfs on the master IDE drive on sd0a, NetBSD then has problems with recognizing it and stops with 'no suitable root'. Thanx for all who tried to help a foolish man ! Ludwig From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 14:05:25 1994 From: matthieu@laas.fr (Matthieu Herrb) To: jan@encap.hanse.de Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Are you in touch with the XFree-Core-Team ? X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 556 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Wed 20) > > Hello Core-Team, > > it think it is a good idea to info David Wexeblatt et al of the upcoming > NetBSD-1.0 release so that they can put proper support for it in XFree-3.1. > I don't know how far they are with it but it would be bad if XFree-3.1 > has no proper NetBSD-1.0 support. > > Jan Don't worry. we are in contact. People involved there are (at least - please forgive me if I forgot someone) Mark Weaver, Christos Zoulas and myself. XFree86-3.1 will support NetBSD 1.0. Matthieu From owner-amiga-x@sun-lamp.cs.berkeley.edu Thu Jul 21 14:12:27 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: X-Servers under development?" (Jul 20, 8:46pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: X-Servers under development? Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Jul 20, 8:46pm, David Jones wrote: [ECS X] > Where? xbsdcc2 and xbsdcc4.. > A very beta version was made available on March 18; this version has some > OBVIOUS bugs. I haven't seen anything newer since. There is no newer version. > Also, will it run on NetBSD 1.0? Yes - if you keep the old libaries :) -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 14:27:11 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Sorry about this one... From: Jan-Hinrich Fessel Sender: owner-current-users@sun-lamp.cs.berkeley.edu This one didn't get through, please, randy, make sure to include a valid return-address. Oskar ------- Forwarded Message Received: from aligator.quantum.de by quando.quantum.de (5.51/QUANDO-S.5.3) id AA17321; Wed, 20 Jul 94 20:27:10 +0200 Received: from unido.UUCP by aligator.quantum.de (5.65c8/QUANDO-X.5.2) id AA09456; Wed, 20 Jul 1994 20:27:06 +0200 From: Mail Delivery Subsystem Date: Wed, 20 Jul 1994 20:24:59 +0200 Message-Id: <199407201824.UAA21120@mail.Germany.EU.net> Received: by mail.Germany.EU.net with internal (8.6.5:29/EUnetD-2.4.3.g) via EUnet id UAA21120; Wed, 20 Jul 1994 20:24:59 +0200 To: fessel@quantum.de Subject: Returned mail: Host unknown (Name server: sierra.weeville.com: host not found) The original message was received at Wed, 20 Jul 1994 20:24:58 +0200 from root@localhost ----- The following addresses had delivery problems ----- sierra.weeville.com!randy (unrecoverable error) ----- Transcript of session follows ----- 501 sierra.weeville.com!randy... 550 Host unknown (Name server: sierra.weeville.com: host not found) ----- Original message follows ----- Received: by mail.Germany.EU.net with UUCP (8.6.5:29/EUnetD-2.4.3.g) via EUnet id UAA21118; Wed, 20 Jul 1994 20:24:58 +0200 Received: from quando.quantum.de by aligator.quantum.de (5.65c8/QUANDO-X.5.2) id AA08918; Wed, 20 Jul 1994 18:54:21 +0200 Received: from quando.quantum.de by quando.quantum.de (5.51/QUANDO-S.5.3) id AA16864; Wed, 20 Jul 94 18:54:20 +0200 Message-Id: <9407201654.AA16864@quando.quantum.de> To: Randy Terbush Cc: Jan-Hinrich Fessel From: Jan-Hinrich Fessel Subject: Re: Anyone has a HPPA port? In-Reply-To: Deine Nachricht vom Wed, 20 Jul 94 06:59:36 CDT. <199407201159.GAB10973@sierra.weeville.com> Date: Wed, 20 Jul 94 18:54:19 +0200 Sender: quantum.de!fessel In message <199407201159.GAB10973@sierra.weeville.com> you write: - -> - -> - ->> - ->> I can get a hp 825s for cheap, is there a possibility - ->> to get NetBSD running on it. - ->> Currently the machine runs hpux 7.0, 9.04 is far too slow - ->> with only 8 MB. - -> - ->How cheap, and where? The port is doable... 500 DM, around 300 US$. Including 6xMUX, 2x 7937 Disks, 7980 1/2" Tape and 9144A QIC Tape. Location is Germany, so shipping would be expensive, and I would like to get it back if NetBSD is running on it ;-) Possibly I can connect it directly to the Internet, so you are invited to do some work on it... Regards Oskar Please configure your mailing system, the From-line had the domain name missing. ------- End of Forwarded Message From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 14:34:01 1994 To: current-users@sun-lamp.cs.berkeley.edu From: Jan-Hinrich Fessel Subject: Adaptec 1742 Problems with -current 16. July Sender: owner-current-users@sun-lamp.cs.berkeley.edu I upgraded my EISA Box from an AHA1542 to an 1742 and consequently use now the ahb-driver. Now I cannot use my Exabyte anymore. I probes incorrect as drive empty, and read or write attempts fail sometimes, often I get 0 bytes with no error when there is definitely data on the tape. The same configuraton worked with the 1542 with no flaws. The 1742 runs in enhanced mode. Oskar ============================================================================== Jan-Hinrich Fessel , Systemverwaltung Quantum Gesellschaft fuer Software mbH, D-4600 Dortmund, Germany Jan-Hinrich.Fessel@quantum.de oskar@zappa.unna.ping.de ============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 14:56:24 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: this is probably a FAQ, but...NE2000? X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu is there an NE2000 driver available for NetBSD? Do I need to snarf one from another free operating system ? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 14:59:35 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, jtk@kolvir.blrc.ma Subject: Re: this is probably a FAQ, but...NE2000? Sender: owner-current-users@sun-lamp.cs.berkeley.edu is there an NE2000 driver available for NetBSD? It's called `ed'. Look in the TRINITY config file for an example of how to configure one. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 15:00:26 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 2.1.1 binaries for 1.0 ALPHA available X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 921 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've updated the binary distribution of XFree86 2.1.1 on ftp.laas.fr. All the binaries are dynamically linked against -current of July 18. The servers are built with shared memory support. They don't include support for my aperture driver yet. I'll make a different set of binaries with it in a couple of days. If you have a VLB card and want to use linear framebuffer mapping, you'll need those servers. The distribution is available from ftp.laas.fr:/pub/NetBSD/XFree86-2.1.1. Only the following files have changed: XFree86-2.1.1-bin.tar.gz XFree86-2.1.1-S3.tar.gz XFree86-2.1.1-lib.tar.gz XFree86-2.1.1-xdm.tar.gz XFree86-2.1.1-8514.tar.gz XFree86-2.1.1-Mach32.tar.gz XFree86-2.1.1-Mach8.tar.gz XFree86-2.1.1-Mono.tar.gz XFree86-2.1.1-SVGA.tar.gz XFree86-2.1.1-VGA16.tar.gz CHECKSUMS There's also a statically linked version of XFree86 2.1.1 that works in pub/NetBSD/XFree86-2.1.1/static. Matthieu From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 15:29:16 1994 From: Hubert Feyrer To: amiga@sun-lamp.cs.berkeley.edu, ledl@dax1.w7.ipp-garching.mpg.de Subject: Re: Installation problems with 940709 snapshot: SOLVED Sender: owner-amiga@sun-lamp.cs.berkeley.edu > NEVER EVER MIX UP BLOCK NUMBERS WITH START CYLINDER NUMBERS !!! > ('dcp -ds 25500' instead of 'dcp -ds 100' !) Why the hell would you use block/cylinder numbers with dcp?!? Just give it the partition's name, and it will calculate all necessary things by itself. You'll have to switch automounting to "yes" in Hdtoolbox in order to get the rootpartition mounted unter AmigaOS. 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 Jul 21 16:05:26 1994 From: Christos Zoulas "Are you in touch with the XFree-Core-Team ?" (Jul 20, 10:54pm) Organization: D. E. Shaw & Co. X-Address: Tower 45, 120 West 45th St., 39th Floor, New York, N.Y. 10036 X-Phone: (212) 478 0000 X-Fax: (212) 478 0101 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: jan@encap.hanse.de Subject: Re: Are you in touch with the XFree-Core-Team ? Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 20, 10:54pm, jan@encap.hanse.de (Jan-Oliver Neumann) wrote: -- Subject: Are you in touch with the XFree-Core-Team ? | | Hello Core-Team, | | it think it is a good idea to info David Wexeblatt et al of the upcoming | NetBSD-1.0 release so that they can put proper support for it in XFree-3.1. | I don't know how far they are with it but it would be bad if XFree-3.1 | has no proper NetBSD-1.0 support. | The current beta of XFree86 compiled under NetBSD-0.9C and runs under 1.0A. There will be another beta this weekend, and I'll compile and install it as soon as it becomes available. christos From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 16:11:35 1994 To: jan@encap.hanse.de Cc: current-users@sun-lamp.cs.berkeley.edu, xfree86-core@xfree86.org Subject: Re: Are you in touch with the XFree-Core-Team ? X-Mailer: exmh version 1.4 6/24/94 From: Marc Evans - Contract Software Hacker Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have forwarded your message verbatum to the rest of the core team members. As others have indicated, we do have regular netBSD users working with the new release of code, so there shouldn't be too much of a problem. We do appreciate knowing when official version updates are goign to occur, so that we can plan around that when possible. - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 16:42:57 1994 From: Alan Barrett Subject: Re: this is probably a FAQ, but...NE2000? To: mycroft@gnu.ai.mit.edu 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 > is there an NE2000 driver available for NetBSD? > > It's called `ed'. Look in the TRINITY config file for an example of > how to configure one. It would be nice if the config files were better commented. For example, # NE1000, NE2000 or similar device ed0 at isa? port 0x300 irq 9 instead of just device ed0 at isa? port 0x300 irq 9 --apb (Alan Barrett) From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 16:49:01 1994 From: Hubert Feyrer Subject: strange effect with VGA-monitor 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: 1463 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Yesterday I tried to install NetBSD (940709 with generic kernel) on a A2000 with a Picasso II and Commodore's display enhancer and a VGA-monitor. When booting the kernel, the whole display was flickering left-right, but all the colors were ok. After attaching a 1084S, everything was just fine: no flickering! Next we installed the rest of the system to get iteconfig to work (which should be *really* incorporated into the rootfs!!!). And after playing around with it, we discovered what was wrong: After switching the resolution from the default NTSC-interlaced to PAL-interlaced, the VGA-monitor (which we didn't unplug) worked well, no more flickering! This raises two questions: 1.) Which component is responsible for the flickering in NTSC-mode: Amiga-Hardware (Agnus), Picasso II, display enhancer, VGA-monitor or NetBSD? 2.) What do I have to binpatch to get a PAL-hires-interalaced screen when booting a kernel? (also, what's responsible for the colors? ;) Hubert P.S.: The VGA-monitor is a 14" ACER View 33LR =============== 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 Thu Jul 21 17:04:51 1994 From: Hubert Feyrer Subject: notes on 940709 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: 1915 Sender: owner-amiga@sun-lamp.cs.berkeley.edu OK, yesterday I made a snapshot of ftp.un-regensburg.de on CD, and tried to install the 940709 snapshot from it, using the netbsd-generic-kernel. Here are some remarks: - There's no /dev/par on the rootfs, only /dev/par0. A symlink would be quite nice here. - mount looks for unknown fs-types in /usr/sbin, rather than /sbin. - iteconfig would be _very_ useful on the rootfs!!! (See my other posting). - bash would be quite nice to have on the rootfs. :-> Then some serious things about the netbsd-generic-kernel: - First, we had to patch _sbic_inhibit_sync to 0 to get the Fujitsu harddisk working. (hd-controller is A2091, btw) - Those "swapper-pager-io"-debug messages do still appear. (OK, that's not _that_ serious, but it's annoying) - There seems to be no ethernet support in the kernel (neither "netstat -ina" nor "ifconfig le0" did show anything). Is there really no ethernet support, or is it just because the machine didn't have a ethernet board? - I was _not_ able to mount the CD!!! "mount -r -t cd9660 /dev/cd0a /cdrom" always gave me "Operation not supported by device", but I was able reading /dev/cd0a (using cat ;). The CD-ROM is recognized as "SONY CD-ROM CDU-8003A1.9a", a Apple CD300. So my question: is it possible there's no CD9660-fs in that generic(!) kernel?!? Mounting AmigaOS-partition worked well, but it's rather dull first copying from CD to disk under AmigaOS, then booting NetBSD to read the archives via ados-fs. Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 17:05:19 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Generic kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu As for a matter of fact: I dislike the current release of the GENERIC kernel. It's not GENERIC at all. It lacks of ISO-FS, ethernet support and other (important) stuff. I don't believe that trying to leave the kernels size below 1MB is a reason to disable (ie. not compile) that stuff. I think it is more reasonable to distribute 4 kinds of kernels: one GENERIC kernel with _everything_ intus. an A3000 kernel w/o any of the other SCSI drivers, no SUN, HP, etc. an A4000/1200 only kernel, with IDE, no SCSI (needs to be discussed), no Sun, HP support, etc. an GENERIC-lite, with all SCSI and IDE drivers, no ethernet, no ISO, no ADOS, no nothing :-) On your marks... -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 17:05:52 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "Re: Installation problems with 940709 snapshot: SOLVED" (Jul 21, 1:45pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Installation problems with 940709 snapshot: SOLVED Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 21, 1:45pm, Hubert Feyrer wrote: > Why the hell would you use block/cylinder numbers with dcp?!? Just > give it the partition's name, and it will calculate all necessary > things by itself. You'll have to switch automounting to "yes" in > Hdtoolbox in order to get the rootpartition mounted unter AmigaOS. To be more concrete: dcp rootfs BSD_ROOT: (if your partition is named BSD_ROOT). That's what dcp is for, and why we love it :-) -- Markus Illenseer From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 17:30:40 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: How can I add more swap space without repartitioning ? From: John Vrolijk Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm running the kernel from 9th of july and the binaries from around the same date. Now, I need more swap space, currently I've got 16 MB but that is not enough. According to the manpage from swapon it should be possible to add swap space on a different device. So, I configured an extra 16MB on sd0b, but I cannot add this to my swap swapon says '/dev/sd0b device not configured' Doesn't the generic kernel support swap on different disks ? John Vrolijk From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 17:41:37 1994 Subject: From: chopps@emunix.emich.edu (Chris Hopps) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Getting very close now. New snapshot is on lamp please test. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 18:12:57 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Cc: sander@carroll1.cc.edu Subject: Re: latest boot blocks don't like old root partitions X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu In private mail, Scott Anderson asked about how you can update your root partition to the new style inode format. Briefly, here's roughly what I did. BE CAREFUL. You need some extra space. I did it by putting together a -current kernel-copy boot floppy and putting -current binaries (you'll need the new mkfs at least) on an inst-1 floppy, copying dump and restore to some scratch dir on /usr, then dumping the root partition to a file in that scratch dir on /usr. Then boot the kernel from floppy, and mount /usr. You should then be able to newfs the root partition, mount it, and restore the image from the file on /usr. Be careful, as usual. ==John From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 18:34:25 1994 From: mw@eunet.ch Subject: Re: notes on 940709 To: Hubert.Feyrer@rz.uni-regensburg.de (Hubert Feyrer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1597 Sender: owner-amiga@sun-lamp.cs.berkeley.edu > - mount looks for unknown fs-types in /usr/sbin, rather than /sbin. Reminds me of some COMPAT_09 problems I had: - mount order of filesystems in kernel is wrong, easiest visible with LFS, which was certainly not available on 0.9. - route-sockets don't work at all with 0.9 compat binaries! - the vfs getdirentries compat support is wrong for big-endian. (From memory, sorrry no diff..) remove that special test for if byteorder!=little-endian and if the filesystem doesn't do symlinks, skip a bunch. Cut that #if, and /proc and /kern don't show 255 "?" as filename... > - iteconfig would be _very_ useful on the rootfs!!! (See my other > posting). And videomode for Retina users. First thing I had to do was get rid of that flickering default mode... > - I was _not_ able to mount the CD!!! "mount -r -t cd9660 /dev/cd0a > /cdrom" always gave me "Operation not supported by device", but I > was able reading /dev/cd0a (using cat ;). The CD-ROM is recognized > as "SONY CD-ROM CDU-8003A1.9a", a Apple CD300. Found that as well, problem seems to be that GENERIC includes option ISOFS, but the filesystem has been renamed to CD9660. > So my question: is it possible there's no CD9660-fs in that > generic(!) kernel?!? Very likely that there is none. Oh, and while you're at it, throw back the bpf driver and the tunnel driver in, over all, it's a GENERIC kernel :-) -Markus -- EUnet Switzerland Tel: +41 1 291 45 80 Markus Wild Zweierstrasse 35 Hotline: +41 1 291 45 60 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 18:56:57 1994 From: mark@aggregate.com (Mark P. Gooderum) To: cgd@alpha.bostic.com Subject: Re: no com ports in GENERIC* kernels?? Cc: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 864 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I'm trying to currentize my system from the May 1 sources, > > and it's becoming a real pain in the ass, since the source tarballs > > from this past weekend won't build a kernel (lots of symbols like > > P_BACK are referenced in genassym.c, but are defined nowhere that I > > can find). This is strange. I upgraded this weekend with binary tarballs from ftp.iastate.edu. The netbsd-aha kernel boots find and even gives me com0-com2. The source though came from sup though, but has built several kernels for me as of the July 18th sup. BTW, I haven't seen the fsck problems that other people have seen, but I haven't tried to "convert" yet either (I'll update and test my boot floppies and level 0 dump first before I try anything like that). I still get the random SEGVs, the last victim was init which of course me the kernel very unhappy. -Mark From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 19:05:05 1994 From: Matthew Aldous Subject: X11 distribution config change To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL0] Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've had to make a small config change to the X distribution.. Who do I need to tell ? /usr/X11R5/lib/X11/config/imakemdep.h: Change - #define DEFAULT_CPP "/usr/lib/cpp" to #define DEFAULT_CPP "/usr/bin/cpp" Also, I've got term2.0.0 binaries etc. Are amiga netbsd'ers wanting binaries put up? It builds out of the box, (as with slap - but that's still in development) - is there a site for this? Also, has anyone recently compiled tcsh6.04 ? It dies all over the place.. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 19:10:57 1994 Subject: From: markus@techfak.uni-bielefeld.de (Markus Illenseer) "" (Jul 21, 10:16am) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: chopps@emunix.emich.edu (Chris Hopps), amiga-dev@sun-lamp.cs.berkeley.edu Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 21, 10:16am, Chris Hopps wrote: > Subject: > Getting very close now. New snapshot is on lamp please test. Gna, you're too fast, i had not even the time to check out the latest :-) -- Markus Illenseer From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 19:13:28 1994 From: markus@techfak.uni-bielefeld.de (Markus Illenseer) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Strange loadbsd problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu We've encountered a magic bug of loadbsd. A friend of mine has an A3000 with 2MB Chip and 3MB (!) Fast. It depends on when he starts loadbsd (after booting ADos fully into WB, or disabling startup-seq) whether he is able to successfully boot into netbsd. W/o startup-seq loadbsd/netbsd recognize his maschine correctly as A3000 and successfully boots. Otherwise his machine pretends to be an A500/A2000 and doesn't boot at all (no SCSI/rootfs found). This is using latest loadbsd and latest kernel from snapshot. -- Markus Illenseer From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 19:13:55 1994 From: Scott Reynolds Subject: Source tree not updated? To: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did something happen to sun-lamp that the source tree didn't get updated last night? I'm looking for a few things, particularly the fixed disklabel code for i386... --scott From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 19:27:56 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Booting problem, kernel freeze before det. HD To: Danny Lepage Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Wed, 20 Jul 1994, Danny Lepage wrote: > > Hi everybody. > > I've got some problem booting with the newest kernels. The system > freeze (with the HD led On) after the lines: > ... > fd0 at ... > ztwobus0 at mainbus0 > ahsc0 at mainbus0 > scsibus1 at ahsc0 > > It looks like the kernel have a bad time finding my HDs. > > I'm experiencing this problem with the Jul 9 kernel from sun-lamp, > and the one on the floppies from uni-regensburg. > > Could this be caused by the fact that my unit 0 disk need sync. to > be enable (I had to enable sync. for sd0 with earlier kernel) ? > > If so, how do I binpath the newer kernel to enable sync. ? (I've > tryed binpatch -s _inhibit_sync ..., but it seems that this > label is not valid anymore) Yes, that is precisely what's happening. > My setup, in case that it matters: > A3000 16MHz 68030, 16Meg Fast, 2Meg Chip > Fujitsu M2624FA (520 Meg) , unit 0 (Needs sync. to be enable). ^^^^^^^^^^^^^^^^^^^^^^^^^ This guy need sync. > Quantum LPS52 (50Meg), unit 6 (Must disable sync., else I've got > timeouts). ^^^^^^^^^^^^^^^^^^^^^^^^ This guy has problems with sync negotiation. It violates the SCSI spec. Get an old kernel, the sources to the latest kernel, and the patch I posted a few months ago, and apply it reversed. Should fix you right up. BTW, Chris, I am beginning to think that that patch I posted will solve the sync negotiation problem on most of the systems that now have problems with it. Try it out for a while. It may save everybody the hassle of dealing with inhibit_sync. > > Thanks in advance. > > Danny Lepage > dlepage@CAM.ORG > poutine@M3iSystems.QC.CA > ========================================================================= 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 Jul 21 19:29:29 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, mrg@mame.mu.oz.au Subject: Re: Setreuid in perl-4.036 X-Sun-Charset: US-ASCII Content-Length: 1425 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >Has anyone done a proper job of fixing suidperl for NetBSD current? > > > >If not, I'll do it. > > it may not be worth it - perl5 is almost beta, and from the > looks of it, it's not going to be beta for very long. there > won't be another perl4 release, so unless your fixed version > goes in to the othersrc tree, it may not be worth it. I originally built suidperl, but the last time I rebuilt it I just left it out. Curious thought...could NetBSD use the fdesc fs to have more secure setuid scripts like SVR4 does? Ala, kernel runs setuid script. If the /dev/fd is available it puts the opens script on fd 3 (or whatever is available), and then passes in /dev/fd/3 as the argument to the script. If /dev/fd isn't available it does it the old way. > on another note: whats the proper way to deal with perl's > use of semctl() that conflicts with the netbsd header files? > (i don't have the error message handy, something about the > last argument perl passes not being a union semun or > soemthing). I fixed this. I don't remember what I did exactly (I just moved my modem to a different com dev and I can't login back to home), but I think it involved just adding the proper typecast (if you look at what its doing it's correct, the problem is older versus newer types/protos and Classic versus ANSI C). I also ended up just manually editing all the AF_LOCAL's to AF_PLOCAL or something like that. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 19:30:58 1994 To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: latest boot blocks don't like old root partitions <9407211326.AA04324@banana> 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 >You need some extra space. I did it by putting together a -current >kernel-copy boot floppy and putting -current binaries (you'll need the >new mkfs at least) on an inst-1 floppy, copying dump and restore to some >scratch dir on /usr, then dumping the root partition to a file in that >scratch dir on /usr. > >Then boot the kernel from floppy, and mount /usr. You should then be >able to newfs the root partition, mount it, and restore the image from >the file on /usr. By this I am to assume that "fsck -c2" doesn't work anymore? (I would assume that you'd need to boot from a floppy to do it on /, anyway). I remember that there were some problems with fsck corrupting partitions on IDE drives, but I thought they had all been fixed. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 19:34:09 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: Current Report To: Bill Squier 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 Tue, 19 Jul 1994, Bill Squier wrote: > In message <9407191415.AA13410@aggregate.com>, Mark P. Gooderum writes: > > >The biggest problem is I have random SEGV core dumps again. I've only got > >8M of RAM and it hits when compiling anything serious with X running. The > >cores have been from everything, make, sed, gcc, and ccp. These behave like > >the cores from the pmap problems way back when (March?April?). Re-run things > >and it works. > > This is the exact RAM size and symptoms that occur on my Amiga ('030) running > NetBSD-current (Jul-17 sup). However, I don't even need X running. > Compiles run for what seems to be a random length of time, and then-- > spurious SIGSEGV. > I used to have the same problems on my 4MB '030 A2500. It was occuring consistently and quite randomly. That was before I learned about the little problem with mfs if you don't specify a max size. Sounds to me like you might be running out of swap space. This is probably caused by the fork-and-swap bug, where if a page is swapped out right after a fork, it's never de-allocated until the parent process dies. How much swap space do you have on that system? How much is allocated to mfs? You might want to try disabling mfs for a while and see if that alleviates the problem somewhat. You might also try increasing swap space if you can. I'm runnning at 10-1 at the moment (40MB Swap-4MB RAM). ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 19:36:18 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: How can I add more swap space without repartitioning ? To: John Vrolijk 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 Thu, 21 Jul 1994, John Vrolijk wrote: > > I'm running the kernel from 9th of july and the binaries from around the same date. > Now, I need more swap space, currently I've got 16 MB but that is not enough. > > According to the manpage from swapon it should be possible to add swap space on > a different device. > > So, I configured an extra 16MB on sd0b, but I cannot add this to my swap > swapon says '/dev/sd0b device not configured' > Doesn't the generic kernel support swap on different disks ? You need to go to your kernel config file and: 1) remove GENERIC 2) Change 'swap on generic' to 'swap on sd0b [and ...]' 3) Recompile and install the new kernel 4) Add the new swap partition to /etc/fstab 5) do a `swapon -a' DISCLAIMER: This should work assuming multiple swap partitions are supported. There is no reason to doubt that they are, but I have not tested that in NetBSD. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 19:54:55 1994 From: Matthew Aldous Subject: Re: Installation problems with 940709 snapshot: SOLVED To: owner-amiga@sun-lamp.cs.berkeley.edu (Markus Illenseer) Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL0] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > On Jul 21, 1:45pm, Hubert Feyrer wrote: > > Why the hell would you use block/cylinder numbers with dcp?!? Just > > give it the partition's name, and it will calculate all necessary > > things by itself. You'll have to switch automounting to "yes" in > > Hdtoolbox in order to get the rootpartition mounted unter AmigaOS. > > To be more concrete: > dcp rootfs BSD_ROOT: > (if your partition is named BSD_ROOT). That's what dcp is for, and why > we love it :-) It's going in the installation FAQ, but GVP SeriesII drives won't let you use BSD_ROOT: unless it's mounted from a mountlist.. Took me a while to work out what as going on.. From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 20:10:40 1994 To: Bill Squier Cc: chopps@emunix.emich.edu, amiga@sun-lamp.cs.berkeley.edu Subject: Re: More investigation into SIGSEGV wierdness. <94Jul21.012501edt.5157@menger.eecs.stevens-tech.edu> From: Bill Squier Sender: owner-amiga@sun-lamp.cs.berkeley.edu In message <94Jul21.012501edt.5157@menger.eecs.stevens-tech.edu>, Bill Squier writes: >In message <9407210424.AA15357@emunix.emich.edu>, chopps@emunix.emich.edu writes: >>I bet you have a GVP acclerator and another expansion board. >>Keep the accelerator toss any expansion boards (with ram) and >> [...] >Well surprise, surprise-- that's exactly what I do have :-) > >Older GVP accel (IDE available on it, no SCSI) @33Mhz, 8MB of 1x8 GVP >SIMMs. GVP Series II SCSI/8 (with NO ram installed) Originally, with >RAM, and that bit me _HARD_. > >Internal drives: Quantum 240MB, Seagate 80MB (ST296N :-) ) >External drive: Seagate 500MB (forget model) > >DMA enabled. > > [...reversed the SIMMs, and...] >So, now I sit rebuilding the world under NetBSD. We shall see. ...and it's been building for just under 24 hours now, with no fails. Before it would barely last 1/2 an hour. As I said on `current-users', I suspect GVP PAL wierdness-- Hell, I've ALWAYS suspected just plain GVP wierdness :-) Of course, it could also have been the massive amount of dust in the machine... Now, a question: Should there be any problem with adding a Hydra board to this setup? Or is GVP generally only possessed by Satan with other SCSI controllers? -wps From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 20:13:58 1994 Subject: Making boot disks 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: 460 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is anyone able to make a set of -current 3.5" boot disks and set them up for ftp somewhere? I cannot get disklabel to work on my disks and the boot blocks won't load a kernel from an unlabled disk... Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 20:24:19 1994 To: "Eduardo E. Horvath eeh@btr.com" Cc: Bill Squier , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Current Report From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message , "Eduardo E. Horvath eeh@btr.com" writes: > >On Tue, 19 Jul 1994, Bill Squier wrote: > >> In message <9407191415.AA13410@aggregate.com>, Mark P. Gooderum writes: >> >> >The biggest problem is I have random SEGV core dumps again. I've only got >> [...] >> This is the exact RAM size and symptoms that occur on my Amiga ('030) running >> NetBSD-current (Jul-17 sup). However, I don't even need X running. >> Compiles run for what seems to be a random length of time, and then-- >> spurious SIGSEGV. >> >I used to have the same problems on my 4MB '030 A2500. It was occuring >consistently and quite randomly. That was before I learned about the >little problem with mfs if you don't specify a max size. Sounds to me > [...] That problem bit me a long time ago, and I've been running without mfs for quite a while (with so little RAM, even limiting mfs seemed like a poor use of resources, so I took it out, and performance is still good.) However, the above problem was solved (just last night @ 2:00am :-) ) GVP '030 had some SIMM wierdness. Swapped 1-4 positions with 5-8 positions and everything works like a charm. Could have been a badly seated one, or could be some GVP PAL logic wierdness, who knows. I'll post a little something over on the `amiga' list too. -wps From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 20:27:13 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, jtk@atria.com Subject: Re: latest boot blocks don't like old root partitions Sender: owner-current-users@sun-lamp.cs.berkeley.edu Last time I tried it, `fsck -c2' did the entire job of updating my file systems Just Fine (tm). I even modified ffs_reload() so you shouldn't even have to reboot after running it, if you do it with the parititions unmounted or mounted read-only. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 20:31:26 1994 Subject: Re: I NEED INFORMATION ON THE AST MULTIPORT SERIAL MULTIPLEX DRIVER To: buhrow@cats.ucsc.edu (Brian Buhrow) From: "Martin Husemann" Cc: current-users@sun-lamp.cs.berkeley.edu, buhrow@cats.ucsc.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: 1074 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > only put the board in enhanced mode if you plan to use it with their ScO > Xenix driver. Otherwise, you should run it in compatible mode. I assume > that the NetBSD driver that supports the AST supports it in enhanced mode? Yes. > through com3 are slaves to this board. Is it legal to put two standard > serial ports in a machine, labeling them com0 and com1 and then putting the > ast in and calling the ports it has com2-com5? Yes. > it using irq 3. If the board is set to use a different interrupt, can you > change the config line to match and expect it to work? Also, should > sharing of interrupts be enabled or disabled? Yes. Share the interrupts on your four-port card, but don't share any interrupts generated from multiple cards! My four-port clone has worked fine for me since early April... Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 20:36:24 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Setreuid in perl-4.036 <9407211446.AA29650@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 >> >Has anyone done a proper job of fixing suidperl for NetBSD current? >> > >> >If not, I'll do it. >> >> it may not be worth it - perl5 is almost beta, and from the >> looks of it, it's not going to be beta for very long. there >> won't be another perl4 release, so unless your fixed version >> goes in to the othersrc tree, it may not be worth it. > >I originally built suidperl, but the last time I rebuilt it I just >left it out. > >Curious thought...could NetBSD use the fdesc fs to have more secure >setuid scripts like SVR4 does? Last time I looked, there was some support for this; If I remember correctly, you had to use "option SUIDSCRIPTS" or something similar to get it to work. I forget what kernel module it was in, or whether or not it's ready for prime time. --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 22:12:05 1994 From: Andrew Cherry To: amiga-dev@sun-lamp.cs.berkeley.edu (Chris Hopps) Subject: New snapshot Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Chris Hopps writes: > Getting very close now. New snapshot is on lamp please test. For the record, I'm having the same problems (unexpected trap) with the kernel from the snapshot, so apparently it has nothing to do with my compilation. I haven't downloaded the entire snapshot yet, but that shouldn't make a difference, since it isn't getting far enough to mount root. Any suggestions? (For details, see my earlier postings :) ) -Andrew Cherry From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 22:18:26 1994 From: mark@aggregate.com (Mark P. Gooderum) To: kenh@wrl.epi.com Subject: Re: Setreuid in perl-4.036 Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 4381 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Last time I looked, there was some support for this; If I remember correctly, > you had to use "option SUIDSCRIPTS" or something similar to get it to work. > I forget what kernel module it was in, or whether or not it's ready for > prime time. Hmmm. I looked into this and found an oddity and a minor bug. The kernel module in question is ...src/sys/kerne/exec_script.c. There are two defines, FDSCRIPTS and SUIDSCRIPTS. FDSCRIPTS effectively says to try to use /dev/fd to exec a script that isn't readable or is setuid, the check is about line 162: #ifdef FDSCRIPTS /* * if the script isn't readable, or it's set-id, then we've * gotta supply a "/dev/fd/..." for the shell to read. * Note that stupid shells (csh) do the wrong thing, and * close all open fd's when the start. That kills this * method of implementing "safe" set-id and x-only scripts. */ if (VOP_ACCESS(epp->ep_vp, VREAD, p->p_ucred, p) == EACCES || script_sbits) { struct file *fp; extern struct fileops vnops; At the top of the module, if SUIDSCRIPTS is set and FDSCRIPTS is not, set FDSCRIPTS. The reverse is not true. Near the top of exec_script(), some variables are defined if SETUIDSCRIPTS is set: #ifdef SETUIDSCRIPTS uid_t script_uid; gid_t script_gid; u_short script_sbits; #endif Then if SETUIDSCRIPTS is set, script_bits is set (along with script_uid and script_gid): #ifdef SETUIDSCRIPTS /* * MNT_NOSUID and STRC are already taken care of by check_exec, * so we don't need to worry about them now or later. */ script_sbits = epp->ep_vap->va_mode & (VSUID | VSGID); if (script_sbits != 0) { script_uid = epp->ep_vap->va_uid; script_gid = epp->ep_vap->va_gid; } #endif But if FDSCRIPTS is defined and SETUIDSCRIPTS isn't, script_bits isn't defined and you get a compile error in the FDSCRIPTS if given first. Finally, script_uid and script_gid are only used to assign back into the same fields farther down: #ifdef SETUIDSCRIPTS /* * set thing up so that set-id scripts will be * handled appropriately */ epp->ep_vap->va_mode |= script_sbits; if (script_sbits & VSUID) epp->ep_vap->va_uid = script_uid; if (script_sbits & VSGID) epp->ep_vap->va_gid = script_gid; #endif These fields aren't modified in between, so the variables xxxid aren't needed and the resetting of va_mode isn't required. One possible patch follows. Note that none of these problems are run time bugs, but ones a compile bug and the other is some confusing and effectively dead code. The netbsd csh source does appear to have the problem mentioned in the comments about closing everything (before the scripts are opened, initdesc() is called which calls closem() which closes everything except the std stuff. I'm not sure how hard a fix would be...special casing it to the /dev/fd case would probably be easy. I haven't looked at tcsh yet. My editor munged some tabs, so this is a diff -w, it may take a patch -l to get it to apply. -Mark -------------------------------------------------------- --- exec_script.c Wed Jun 29 05:28:54 1994 +++ exec_script.c.patched Thu Jul 21 12:48:44 1994 @@ -72,8 +72,6 @@ struct vnode *scriptvp; #ifdef SETUIDSCRIPTS uid_t script_uid; - gid_t script_gid; - u_short script_sbits; #endif /* @@ -146,10 +144,6 @@ * so we don't need to worry about them now or later. */ script_sbits = epp->ep_vap->va_mode & (VSUID | VSGID); - if (script_sbits != 0) { - script_uid = epp->ep_vap->va_uid; - script_gid = epp->ep_vap->va_gid; - } #endif #ifdef FDSCRIPTS /* @@ -159,8 +153,12 @@ * close all open fd's when the start. That kills this * method of implementing "safe" set-id and x-only scripts. */ - if (VOP_ACCESS(epp->ep_vp, VREAD, p->p_ucred, p) == EACCES || - script_sbits) { + if (VOP_ACCESS(epp->ep_vp, VREAD, p->p_ucred, p) == EACCES +#ifdef SETUIDSCRIPTS +|| + script_sbits +#endif +) { struct file *fp; extern struct fileops vnops; @@ -243,17 +241,6 @@ epp->ep_flags |= (EXEC_HASARGL | EXEC_SKIPARG); epp->ep_fa = shellargp; -#ifdef SETUIDSCRIPTS - /* - * set thing up so that set-id scripts will be - * handled appropriately - */ - epp->ep_vap->va_mode |= script_sbits; - if (script_sbits & VSUID) - epp->ep_vap->va_uid = script_uid; - if (script_sbits & VSGID) - epp->ep_vap->va_gid = script_gid; -#endif return (0); } From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 22:26:24 1994 Subject: How does NetBSD search disks? From: David Jones To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I have a Maxtor 340MB disk with BSDR, BSDS and BSDD partitions. Once 1.0 becomes stable and I have time, I'd like to test-install NetBSD on a spare Quantum 105S before nuking the existing stuff on the Maxtor. I plan to use the proper NBR\7, NBS\1 and NBU\7 partition IDs when I prepare the Quantum. What do I need to do to ensure that the Maxtor's partitions are not accessed by my test install? Unplugging the Maxtor would work, except that the 100M ADOS partition on it is likely to be useful during the install process :-) -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@freenet.toronto.on.ca for latest Toronto Free-Net information Click me! From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 21 22:34:38 1994 To: "Eduardo E. Horvath eeh@btr.com" Cc: John Vrolijk , amiga@sun-lamp.cs.berkeley.edu, mehlhaff@crl.com Subject: Re: How can I add more swap space without repartitioning ? of Thu, 21 Jul 1994 08:34:57 -0700 From: "'Most Excellent' Eric Mehlhaff" Sender: owner-amiga@sun-lamp.cs.berkeley.edu "Eduardo E. Horvath eeh@btr.com" recently wrote: >On Thu, 21 Jul 1994, John Vrolijk wrote: >You need to go to your kernel config file and: > >1) remove GENERIC > >2) Change 'swap on generic' to 'swap on sd0b [and ...]' You also need to specify which partition root is supposed to be on when you do this. >3) Recompile and install the new kernel > >4) Add the new swap partition to /etc/fstab > >5) do a `swapon -a' > >DISCLAIMER: This should work assuming multiple swap partitions are >supported. There is no reason to doubt that they are, but I have not >tested that in NetBSD. They are, I've been using them for a while. Having multiple swap is the primary reason I've been compiling my own kernels... Eric Mehlhaff, mehlhaff@crl.com From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 22:35:01 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Random timeouts in 1.0-ALPHA... 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 Well, this is the same guy who so desperately wanted to get a -current system running, and now, with much tinkering around, I have one running! Now all I have to do is download the latest sources to build a new kernel!! Anyway, I would like to thank everyone who responded and took time to read my message, you now have a devoted follower! However, the real reason I'm mailing is because I'm having a little quibble over the new wdc driver in 1.0-ALPHA. For some stupid reason, I'm getting random timeouts and lost interrupts whenever disk access gets heavy. The error message reads as follows: wdc0: lost interrupt: status 58 error 0 wd: wdcstart: timeout waiting for drq: status 0 error 0 This message just repeats itself over and over until I do a ^C to stop disk access. I was really pissed off because this also happens in the latest version of FreeBSD, which is one of the small things that prompted me to try something new. I think it may be the bounce buffer code in the new wd driver that may be causing this, but I'm not so sure. I was hoping that someone had wd and wdreg files from an old -current kernel to give to me so that I could see what has changed and where it went wrong. By the way, I'm using a Western Digital Caviar 244 MB drive, and I guess a `generic' ISA IDE controller. It seems that I'm the only one in the world who is experiencing this problem, since no one on either the FreeBSD or NetBSD has commented on these timeout problems. Anyway, some help on this would be greatly appreciated. Sincerely, ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 22:37:26 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: kenh@wrl.epi.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Setreuid in perl-4.036 <9407211800.AA00848@aggregate.com> From: "John F. Woods" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > The netbsd csh source does appear to have the problem mentioned in the > comments about closing everything (before the scripts are opened, > initdesc() is called which calls closem() which closes everything except the > std stuff. This is a feature; it further discourages people from writing csh scripts. :-) From owner-netbsd-users@sun-lamp.cs.berkeley.edu Thu Jul 21 22:46:59 1994 To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: DC users group, anyone? 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-netbsd-users@sun-lamp.cs.berkeley.edu Is anyone out there interested in forming a DC area NetBSD user's group? By "DC area" I mean the greater metropolitan area (I live in Virginia myself). --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 21 22:49:14 1994 From: Wolfgang Solfrank To: kenh@wrl.epi.com, mark@aggregate.com Subject: Re: Setreuid in perl-4.036 Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Finally, script_uid and script_gid are only used to assign back into the > same fields farther down: > > #ifdef SETUIDSCRIPTS > /* > * set thing up so that set-id scripts will be > * handled appropriately > */ > epp->ep_vap->va_mode |= script_sbits; > if (script_sbits & VSUID) > epp->ep_vap->va_uid = script_uid; > if (script_sbits & VSGID) > epp->ep_vap->va_gid = script_gid; > #endif > > These fields aren't modified in between, so the variables xxxid aren't needed > and the resetting of va_mode isn't required. Sorry, this isn't correct. The attributes ARE modified between the saving and what you call resetting. Note that there is a recursice call to check_exec about 20 lines above the code mentioned above. This routine changes the attributes from that of the script to that of the interpreter. The intent of this so-called reset is that the original caller of the check_exec gets attributes that describe the intended effective uid and gid of the exec. You are correct though with your first bug report regarding the script_sbits variable. -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 23:03:07 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: markus@techfak.uni-bielefeld.de (Markus Illenseer), amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Strange loadbsd problems Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 21, 5:07pm, Markus Illenseer wrote: > W/o startup-seq loadbsd/netbsd recognize his maschine correctly as > A3000 and successfully boots. Otherwise his machine pretends to be > an A500/A2000 and doesn't boot at all (no SCSI/rootfs found). Loadbsd now tries to determine what machine it is running on and passes that machine type to the kernel. The kernel assumes that value is correct and configures based on that. If loadbsd says it's running on an A2000/A500, then the kernel won't try to configure the A3000 scsi and it's not suprising it doesn't find the SCSI device. The test for the A3000 is if there is a module named either "A3000 bonus" or "A3000 Bonus" in the Exec Resident Module list. It looks like something in the startup-sequence must be modifying this in some fashion. You can force the machine type with the -c 3000 option on loadbsd - this will override the attempt to automagically determine the machine type (which certainly isn't fool proof). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 21 23:11:31 1994 From: Hubert Feyrer Subject: errors in cd9660_vnops.c 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: 701 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu When trying to compile a -current kernel on a 940709-system (current includes installed), I discovered several undefined symbols in sys/isofs/cd9660/cd9660_vnops.c: line 287 : IACC should be: IN_ACCESS lines 813 & 829: ILOCKED IN_LOCKED 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 Jul 21 23:56:27 1994 To: Mark Steven de Sagun-Tamola Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Random timeouts in 1.0-ALPHA... From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I'm getting random timeouts and lost interrupts whenever disk access gets >heavy. The error message reads as follows: > >wdc0: lost interrupt: status 58 error 0 >wd: wdcstart: timeout waiting for drq: status 0 error 0 > >This message just repeats itself over and over until I do a ^C to stop This sounds like you may have a bad spot on your hard drive, and the drive is trying to recalibrate or move the spot, while in the mean time the wd driver is timing out waiting for the drive. You can verify this by 1) borrowing an IDE drive from a friend who'll let you reformat it to put NetBSD on it, and see if that drive works better, or 2) get a DOS exhaustive low-level formatter like SpinRite, or the one in PC Tools, and let it run all night on your drive. It will tell you if you have bad, or even marginal, spots on your drive. Either way, the problems aren't caused by software -- the problems are due to the low quality of much of the IDE hardware on the market (IDE is an extremely loosely defined "standard"). I suspect it's your drive that's giving you fits. >I think it may be the bounce buffer code in the new wd driver that may be >causing this, but I'm not so sure. IDE drives don't use DMA (at least under the wd driver), so they don't have bounce buffers. --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-dev@sun-lamp.cs.berkeley.edu Fri Jul 22 00:23:48 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu, markus@techfak.uni-bielefeld.de Subject: Re: Generic kernel Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) > > As for a matter of fact: I dislike the current release of the GENERIC > kernel. It's not GENERIC at all. It lacks of ISO-FS, ethernet support > and other (important) stuff. I don't believe that trying to leave the > kernels size below 1MB is a reason to disable (ie. not compile) that stuff. > > I think it is more reasonable to distribute 4 kinds of kernels: > > one GENERIC kernel with _everything_ intus. > an A3000 kernel w/o any of the other SCSI drivers, no SUN, HP, etc. > an A4000/1200 only kernel, with IDE, no SCSI (needs to be discussed), no Sun, > HP support, etc. > an GENERIC-lite, with all SCSI and IDE drivers, no ethernet, no ISO, > no ADOS, no nothing :-) > > On your marks... This sounds good to me. I'll see if I can't get around to creating commented versions of these over the weekend. How do these names sound: GENERIC - truly generic A3000 - as we all know and love IDE - IDE kernel for A4000/A1200 SMALL - smaller version of GENERIC -SR nd love IDE - IDE kernel for A4000/A1200 SMALL - smaller version of GENERIC -SR From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 00:38:02 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Re: Random timeouts in 1.0-ALPHA... To: "Michael L. VanLoon -- Iowa State University" 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 > >I'm getting random timeouts and lost interrupts whenever disk access gets > >heavy. The error message reads as follows: > > > >wdc0: lost interrupt: status 58 error 0 > >wd: wdcstart: timeout waiting for drq: status 0 error 0 > > > >This message just repeats itself over and over until I do a ^C to stop > > This sounds like you may have a bad spot on your hard drive, and the > drive is trying to recalibrate or move the spot, while in the mean > time the wd driver is timing out waiting for the drive. You can [some stuff deleted...] > Either way, the problems aren't caused by software -- the problems are > due to the low quality of much of the IDE hardware on the market (IDE > is an extremely loosely defined "standard"). I suspect it's your > drive that's giving you fits. Yes, I did consider this fact, and did think about throwing away the IDE drive for a SCSI, since it was about time to upgrade, but I beg to differ. It's not so much the fact the new drive would cost me much, but that my drive worked perfectly and completely stable when I used NetBSD-0.9 back in fall of '93 for about 3 months, then another five or six months running FreeBSD-1.0.2, and then another month and a half of running FreeBSD-1.1!! Not once have these random timeouts ever occurred, and not once have I even had the slightest quibble with disk access or disk problems of any kind, even when running X on only 4megs of memory while compiling new FreeBSD sources, an app or two, and then downloading new stuff all at the same time. Then, when I upgraded to FreeBSD-1.1.5.1, I start getting a bunch of random timeouts. Naturally, I got pissed, since these have never popped up with my drive before. I then thought of switching to NetBSD-current, as it has been something I've been wanting to do for about six months now. So I switch, and I get the same blasted timeouts. Then, I think, well, maybe I screwed up my hard drive somehow (and I don't even remember screwing with it) at the time of installing FreeBSD-1.1.5.1, and that has now caused these problems. No again, since I reinstalled ALL FreeBSD-1.1, FreeBSD-1.0.2, and NetBSD-0.9 on my drive, only to find that my disk is happily stable, with no timeouts whatsoever, even under extensive disk access testing. Thus, it can't be purely a hardware problem, and has to do with the new wd drivers in the new kernels for both Free and Net BSD. Maybe the new drivers are so much incredibly improved that it is finding some minute problem with the disk, and keeps panicing over it, I don't know. But whatever it is, it has caused me a lot of trouble. Sincerely, ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 00:47:46 1994 To: Jan-Hinrich Fessel Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 Problems with -current 16. July <9407210818.AA05574@quando.quantum.de> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I upgraded my EISA Box from an AHA1542 to an 1742 and > consequently use now the ahb-driver. Now I cannot use my > Exabyte anymore. I probes incorrect as drive empty, and read > or write attempts fail sometimes, often I get 0 bytes with no error > when there is definitely data on the tape. The same configuraton > worked with the 1542 with no flaws. Hmm. I've never tried the 1742 with an exabyte, but i know it works fine on, e.g. the DAT on sun-lamp... I could believe it doesn't work -- Exabytes are weird... "i've got no clue" as to what could be wrong, though, and can't test it because, now that i've got an exabyte around, my 1742's aren't local anymore... heh. chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 00:50:43 1994 From: jan@encap.hanse.de (Jan-Oliver Neumann) Subject: Seperated i386-specific stuff out of . To: current-users@sun-lamp.cs.berkeley.edu Cc: cgd@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 6994 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, contains '#ifdef i386' for some specific things to deal with disklabels hidden in DOS partitions. I followed the example of the amiga port and sorted things out to . I left the flag D_DOSPART in to ensure that nobody uses that value accidently. I also deleted one of the last references to 386BSD by renaming DOSPTYP_ 386BSD to DOSPTYP_NETBSD. I do not supply diffs for all references to this, I only name affected files: * sbin/disklabel/disklabel.c * sbin/fdisk/fdisk.c * sys/arch/i386/boot/disk.c * sys/arch/i386/i386/disksubr.c * sys/arch/i386/include/pc/msdos.h (does this thing live ?) this is the diff for : *** /usr/NetBSD-current/usr/src/sys/sys/disklabel.h~ Thu Jul 21 00:21:17 1994 --- /usr/NetBSD-current/usr/src/sys/sys/disklabel.h Thu Jul 21 00:46:23 1994 *************** *** 42,47 **** --- 42,51 ---- #include #endif + #ifdef i386 + #include + #endif + /* * Disk description table, see disktab(5) */ *************** *** 188,195 **** #define DTYPE_FLOPPY 10 /* floppy */ /* d_subtype values: */ - #define DSTYPE_INDOSPART 0x8 /* is inside dos partition */ - #define DSTYPE_DOSPART(s) ((s) & 3) /* dos partition number */ #define DSTYPE_GEOMETRY 0x10 /* drive params in label */ #ifdef DKTYPENAMES --- 192,197 ---- *************** *** 310,347 **** struct partition *part; }; ! #ifdef i386 ! /* DOS partition table -- located in boot block */ ! ! #define DOSBBSECTOR 0 /* DOS boot block relative sector number */ ! #define DOSPARTOFF 446 ! #define NDOSPART 4 ! ! struct dos_partition { ! unsigned char dp_flag; /* bootstrap flags */ ! unsigned char dp_shd; /* starting head */ ! unsigned char dp_ssect; /* starting sector */ ! unsigned char dp_scyl; /* starting cylinder */ ! unsigned char dp_typ; /* partition type */ ! #define DOSPTYP_386BSD 0xa5 /* 386BSD partition type */ ! unsigned char dp_ehd; /* end head */ ! unsigned char dp_esect; /* end sector */ ! unsigned char dp_ecyl; /* end cylinder */ ! unsigned long dp_start; /* absolute starting sector number */ ! unsigned long dp_size; /* partition size in sectors */ ! } dos_partitions[NDOSPART]; ! ! #include ! struct cpu_disklabel { ! struct dos_partition dosparts[NDOSPART]; ! struct dkbad bad; ! }; ! ! #endif /* i386 */ ! #if defined(hp300) || defined(mac68k) || defined(vax) || defined(pc532) || \ ! defined(sun3) || defined(sparc) || defined(da30) || defined(pmax) || \ ! defined(alpha) struct cpu_disklabel { int cd_dummy; /* must have one element. */ }; --- 312,323 ---- struct partition *part; }; ! /* ! * The i386- and Amiga-ports define their own cpu_disklabels in ! * . ! */ ! #if !defined(i386) && !defined(amiga) /* both define different ones */ struct cpu_disklabel { int cd_dummy; /* must have one element. */ }; *************** *** 370,378 **** #define DIOCSBAD _IOW('d', 110, struct dkbad) /* set kernel dkbad */ #ifdef KERNEL - #ifdef i386 - int bounds_check_with_label __P((struct buf *, struct disklabel *, int)); - #endif void diskerr __P((struct buf *, char *, char *, int, int, struct disklabel *)); void disksort __P((struct buf *, struct buf *)); --- 346,351 ---- ------------------------------------------------------------------------------ This is the new /usr/src/sys/arch/i386/include/disklabel.h: ------------------------------------------------------------------------------ /* * Copyright (c) 1987, 1988 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 3. All advertising materials mentioning features or use of this software * must display the following acknowledgement: * This product includes software developed by the University of * California, Berkeley and its contributors. * 4. Neither the name of the University nor the names of its contributors * may be used to endorse or promote products derived from this software * without specific prior written permission. * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * * @(#)disklabel.h 7.19 (Berkeley) 5/7/91 */ #ifndef _I386_DISKLABEL_H_ #define _I386_DISKLABEL_H_ /* * This file contains i386 specific additions to to * let the i386-port hide disklabels inside DOS/BIOS-partitions. */ /* d_subtype values: */ #define DSTYPE_INDOSPART 0x8 /* is inside dos partition */ #define DSTYPE_DOSPART(s) ((s) & 3) /* dos partition number */ #ifndef LOCORE /* DOS partition table -- located in boot block */ #define DOSBBSECTOR 0 /* DOS boot block relative sector number */ #define DOSPARTOFF 446 #define NDOSPART 4 struct dos_partition { unsigned char dp_flag; /* bootstrap flags */ unsigned char dp_shd; /* starting head */ unsigned char dp_ssect; /* starting sector */ unsigned char dp_scyl; /* starting cylinder */ unsigned char dp_typ; /* partition type */ #define DOSPTYP_NETBSD 0xa5 /* NETBSD partition type */ unsigned char dp_ehd; /* end head */ unsigned char dp_esect; /* end sector */ unsigned char dp_ecyl; /* end cylinder */ unsigned long dp_start; /* absolute starting sector number */ unsigned long dp_size; /* partition size in sectors */ } dos_partitions[NDOSPART]; #include struct cpu_disklabel { struct dos_partition dosparts[NDOSPART]; struct dkbad bad; }; #ifdef KERNEL int bounds_check_with_label __P((struct buf *, struct disklabel *, int)); #endif #endif /* !LOCORE */ #endif /* !_I386_DISKLABEL_H_ */ ---------------------------------------------------------------------------- I hope this changes are worthwile and ok; I can't compile a kernel at the moment. Jan From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 00:58:53 1994 From: mark@aggregate.com (Mark P. Gooderum) To: kenh@wrl.epi.com, mark@aggregate.com, ws@tools.de Subject: Re: Setreuid in perl-4.036 Cc: current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1439 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Sorry, this isn't correct. > > The attributes ARE modified between the saving and what you call resetting. > > Note that there is a recursice call to check_exec about 20 lines above the > code mentioned above. This routine changes the attributes from that of the > script to that of the interpreter. The intent of this so-called reset is that > the original caller of the check_exec gets attributes that describe the > intended effective uid and gid of the exec. I missed this. I had scanned check_exec() once but hadn't looked closely enough. This raises an interesting issue. Unless SETUIDSCRIPTS is set for the kernel, setuid scripts don't setuid at all. There are good reasons for this but it seems a major deviation from common Unix to be undocumented (the code comments don't mention this, no man page does, it doesn't even show up in ALL (maybe should be LOTS anyways...it's certainly not ALL)). Another interesting check might be that maybe there should be an error if FDSCRIPTS is set and FDESCFS isn't, since you certainly can't pass a valid /dev/fd/N if you don't have FDESCFS. Does anybody have any kind of documentation on all the kernel options? There seem to be some pretty major ones that don't even get mentioned in ALL, like DIAGNOSTICS. Also, I noticed some references to old options when I started browsing the source in more detail (for instance there are still lots of refs to LFS and AFS around). -Mark From owner-netbsd-users@sun-lamp.cs.berkeley.edu Fri Jul 22 01:13:28 1994 To: Ken Hornstein Cc: netbsd-users@sun-lamp.cs.berkeley.edu From: "Louis A. Mamakos" Subject: Re: DC users group, anyone? <9407211817.AA10888@entropic.com> Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu I'd be interested in a local NetBSD user's group. I live in Maryland, but work in Falls Church, so somewhere in between might be interested. Perhaps just a periodic gathering a some watering hole/food place? Louis Mamakos From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:06:54 1994 From: Scott Reynolds Subject: Re: latest boot blocks don't like old root partitions To: John Kohl 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, 21 Jul 1994, John Kohl wrote: > You need some extra space. I did it by putting together a -current > kernel-copy boot floppy [...] Doing this part is quite a trick, at least for me at the moment. I can get new bootblocks on floppies only to have them tell me "bad disklabel" when I try to boot them. What I did was pretty nasty, but it works: I have a set of kern, inst-1, and inst-2 disks with the original 0.9 bootblocks (v1.8) and -current everything else. They appear to work fine. Does anybody want to donate ftp space so that I can make them available? --scott From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:07:17 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mark@aggregate.com Subject: Re: Setreuid in perl-4.036 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Another interesting check might be that maybe there should be an error if FDSCRIPTS is set and FDESCFS isn't, since you certainly can't pass a valid /dev/fd/N if you don't have FDESCFS. That's not true. `MAKEDEV std' creates a /dev/fd populated with device nodes that sort-of do the right thing. FDESC is better, but optional. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:37:20 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: syslogd core dump Sender: owner-current-users@sun-lamp.cs.berkeley.edu I had a problem with syslogd core dumping and determined it was due to spaces used in the /etc/syslog.conf file in the place of tabs. Is there a reason the selector and action fields must be tab delimited? Is there anywhere in the /etc/syslog.conf file where spaces have significance? I have a patch which allows either tabs or spaces (or both) to syslogd.c, but I want to be certain that I'm not breaking something by disallowing space characters in the selector field. -john From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:43:11 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 (continue) Subject: sun-lamp CVS update output Updating src and othersrc trees: U src/etc/mtree/4.4BSD.dist U src/include/Makefile U src/sbin/disklabel/disklabel.c U src/sbin/mountd/mountd.c U src/sbin/newfs/mkfs.c U src/sbin/newfs/newfs.8 U src/share/lkm/Makefile U src/share/mk/bsd.prog.mk U src/sys/arch/i386/i386/machdep.c U src/sys/arch/i386/include/types.h U src/sys/arch/i386/isa/if_ep.c U src/sys/arch/i386/isa/if_epreg.h U src/sys/arch/i386/isa/pms.c U src/sys/arch/i386/isa/pcvt/pcvt_hdr.h U src/sys/arch/m68k/include/types.h U src/sys/arch/pc532/include/types.h U src/sys/arch/pc532/pc532/machdep.c U src/sys/arch/pmax/include/types.h U src/sys/arch/sparc/conf/Makefile.sparc U src/sys/arch/sparc/include/types.h U src/sys/arch/sun3/conf/Makefile.sun3 U src/sys/arch/sun3/sun3/delay.s U src/sys/arch/sun3/sun3/pmap.c U src/sys/arch/sun3/sun3/trap.c U src/sys/isofs/cd9660/TODO U src/sys/isofs/cd9660/TODO.hibler U src/sys/isofs/cd9660/cd9660_bmap.c U src/sys/isofs/cd9660/cd9660_lookup.c U src/sys/isofs/cd9660/cd9660_node.c U src/sys/isofs/cd9660/cd9660_node.h U src/sys/isofs/cd9660/cd9660_rrip.c U src/sys/isofs/cd9660/cd9660_vfsops.c U src/sys/isofs/cd9660/cd9660_vnops.c U src/sys/isofs/cd9660/iso.h U src/sys/lib/libsa/ufs.c U src/sys/miscfs/nullfs/null_vnops.c U src/sys/msdosfs/denode.h U src/sys/msdosfs/msdosfs_denode.c U src/sys/msdosfs/msdosfs_fat.c U src/sys/msdosfs/msdosfs_lookup.c U src/sys/msdosfs/msdosfs_vfsops.c U src/sys/msdosfs/msdosfs_vnops.c U src/sys/net/if_ppp.c U src/sys/netiso/tp_tpdu.h U src/sys/nfs/nfs_bio.c U src/sys/nfs/nfs_boot.c U src/sys/vm/vm_swap.c U doc/CHANGES Killing core files: Running the SUP scanner: SUP Scan for current starting at Thu Jul 21 15:31:08 1994 SUP Scan for current completed at Thu Jul 21 15:34:43 1994 SUP Scan for mirror starting at Thu Jul 21 15:34:43 1994 SUP Scan for mirror completed at Thu Jul 21 15:37:57 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:45:32 1994 From: mark@aggregate.com (Mark P. Gooderum) To: cgd@alpha.bostic.com Subject: Re: Setreuid in perl-4.036 Cc: kenh@wrl.epi.com, ws@tools.de, current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1132 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > umm, i can't quite parse this... > > "it seems a major deviation from common Unix" -- what is "it"? > SETUIDSCRIPTS? or the fact that setuid scripts don't setuid at all? The fact that it doesn't setuid at all. > the former probably should be documented, but i'd really rather that > anybody who wants to use it have to look over the code, anyway. You could document SETUIDSCRIPTS but not FDSCRIPTS and remove the automatic contingent reply so that people can find the info easily, but then they get a compile error and *have* to go look at the code, then you get both ;-). > the latter is 100% standard UN*X -- normally, the set-id bits for > scripts are ignored, because (since most un*xes don't have /dev/fd/*) > there's no safe way to do set-id scripts. I'm not arguing about the merits of setuid scripts, however, SunOS, HP/UX, and Solaris (if /dev/fd isn't mounted) happily run setuid scripts the old fashioned way. There's a lot of holes true, but it can be done securely-if the file and dir permissions are correct and you use the "break" arugment list processing option, or am I missing something else? -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:49:17 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: kenh@wrl.epi.com, ws@tools.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Setreuid in perl-4.036 <9407212104.AA02640@aggregate.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > This raises an interesting issue. Unless SETUIDSCRIPTS is set for the > kernel, setuid scripts don't setuid at all. There are good reasons for > this but it seems a major deviation from common Unix to be undocumented > (the code comments don't mention this, no man page does, it doesn't > even show up in ALL (maybe should be LOTS anyways...it's certainly not > ALL)). umm, i can't quite parse this... "it seems a major deviation from common Unix" -- what is "it"? SETUIDSCRIPTS? or the fact that setuid scripts don't setuid at all? the former probably should be documented, but i'd really rather that anybody who wants to use it have to look over the code, anyway. the latter is 100% standard UN*X -- normally, the set-id bits for scripts are ignored, because (since most un*xes don't have /dev/fd/*) there's no safe way to do set-id scripts. chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:50:37 1994 From: Wolfgang Solfrank To: mark@aggregate.com Subject: Re: Setreuid in perl-4.036 Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > This raises an interesting issue. Unless SETUIDSCRIPTS is set for the > kernel, setuid scripts don't setuid at all. There are good reasons for > this but it seems a major deviation from common Unix to be undocumented > (the code comments don't mention this, no man page does, it doesn't > even show up in ALL (maybe should be LOTS anyways...it's certainly not > ALL)). Yes, this is the reason I named this flag thusly :-) (you want to have scripts that honor setuid). Note, that apart from the mangling of defines at the start of exec_script.c, the two flags SETUIDSCRIPTS and FDSCRIPTS are pretty much orthogonal. You could have one without the other, which would have the following effects: SETUIDSCRIPTS FDSCRIPTS effect on scripts undefined undefined no setuid no exec if exec-only defined undefined setuid with the wellknown security hole no exec if exec-only undefined defined no setuid can execute exec-only scripts defined defined safer setuid scripts can execute exec-only scripts Note, that with FDSCRIPTS defined, scripts using this feature, i.e. setuid and/or exec-only scripts, loose the ability to get at their filename ($0 in the shell). -- ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800 From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:53:08 1994 To: mark@aggregate.com (Mark P. Gooderum) Cc: cgd@alpha.bostic.com, kenh@wrl.epi.com, ws@tools.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Setreuid in perl-4.036 <9407212207.AA03945@aggregate.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > the latter is 100% standard UN*X -- normally, the set-id bits for > > scripts are ignored, because (since most un*xes don't have /dev/fd/*) > > there's no safe way to do set-id scripts. > > I'm not arguing about the merits of setuid scripts, however, SunOS, > HP/UX, and Solaris (if /dev/fd isn't mounted) happily run setuid scripts > the old fashioned way. Hmm, the last time i checked this, this wasn't the case... however... > There's a lot of holes true, but it can be > done securely-if the file and dir permissions are correct and you use the > "break" arugment list processing option, or am I missing something else? no matter where your s-uid script is, if you link to it (soft or hard), execute the link'd version, remove the link, and replace it with your own script between the time the kernel getattr's the script and the time that the shell opens it, you'll have a set-uid shell running your own script. It's a standard race condition. Nothing you can do about it (short of disallowing all types of links to setuid scripts, and that's not possible, because what if the links were there before it was made set-uid?) short of /dev/fd (or equivalent) will kill that race condition. chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:53:32 1994 From: mycroft@gnu.ai.mit.edu To: bachesta@angst.tera.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Drivers for Adaptec 2742 or 2842. Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does NetBSD-current support the Adaptec 2742 or 2842 SCSI disk contollers. Currently, no, and I don't think anyone is actively working on it. From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 02:55:23 1994 From: bachesta@angst.tera.com To: current-users@sun-lamp.cs.berkeley.edu Subject: Drivers for Adaptec 2742 or 2842. Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm asking this on behalf of a friend of mine who is not on the net. Does NetBSD-current support the Adaptec 2742 or 2842 SCSI disk contollers. I looked through the code and I didn't see any drivers. Is anyone working on a driver? I apologize if this was discussed previously. Thanks, Jim Bachesta bachesta@tera.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 03:01:49 1994 From: Mike Halderman Subject: Re: Adaptec 1742 Problems with -current 16. July 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 don't want to take this to far off topic, but where can you get 1742's these days? I can't find them locally anywhere. Does Buslogic make a EISA controller? Mike Halderman mrh@nosc.mil From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 03:17:31 1994 To: Mike Halderman Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 Problems with -current 16. July <199407212221.PAA07942@io.nosc.mil> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I don't want to take this to far off topic, but where can you get 1742's > these days? I can't find them locally anywhere. Does Buslogic make a EISA > controller? they make two, the 742 and the 747, both of which are supported by NetBSD's 'bt' driver. If i remember the specs right, the 747 is a fair bit faster than the 1742, and the 742 slightly faster, for some types of transfers, or something like that... One of the SCSI controllers in sun-lamp is a 747. chris From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 03:40:49 1994 From: hvozda@apache.raynet.com (Eric Hvozda - API) Subject: IDE sector remap (was Re: Random timeouts in 1.0-ALPHA...) To: michaelv@iastate.edu (Michael L. VanLoon -- Iowa State University) Cc: buckwild@u.washington.edu, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1495 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > >I'm getting random timeouts and lost interrupts whenever disk access gets > >heavy. The error message reads as follows: > > > >wdc0: lost interrupt: status 58 error 0 > >wd: wdcstart: timeout waiting for drq: status 0 error 0 > > > >This message just repeats itself over and over until I do a ^C to stop > > This sounds like you may have a bad spot on your hard drive, and the > drive is trying to recalibrate or move the spot, while in the mean > time the wd driver is timing out waiting for the drive. You can > verify this by 1) borrowing an IDE drive from a friend who'll let you > reformat it to put NetBSD on it, and see if that drive works better, > or 2) get a DOS exhaustive low-level formatter like SpinRite, or the > one in PC Tools, and let it run all night on your drive. It will tell > you if you have bad, or even marginal, spots on your drive. I had a Maxtor 7345AT do this on occasion after I moved it from a 486 to a 386. It was quite annoying to say the least. I was under the impression: 1 Maxtor is a `decent` drive far as IDE disks go 2 sector remap is transparent to the software Given a good/proper IDE implementation, shouldn't #2 be true and you shouldn't see error messages of the sort above unless you run out of remap space as well? The 386 I had moved the disk to had the same geometery in BIOS (AMI BIOS as a matter of fact). Don't recall if it was an Intel or chip of other Mgr. Does it really matter if its a AMD or Cyrix per se? From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 03:41:13 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Re: IDE sector remap (was Re: Random timeouts in 1.0-ALPHA...) To: Eric Hvozda - API Cc: "Michael L. VanLoon -- Iowa State University" , 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 had a Maxtor 7345AT do this on occasion after I moved it from a 486 > to a 386. It was quite annoying to say the least. I was under the impression: > > 1 Maxtor is a `decent` drive far as IDE disks go > 2 sector remap is transparent to the software > > Given a good/proper IDE implementation, shouldn't #2 be true and you shouldn't > see error messages of the sort above unless you run out of remap space as well? > > The 386 I had moved the disk to had the same geometery in BIOS (AMI BIOS > as a matter of fact). Don't recall if it was an Intel or chip of other > Mgr. Does it really matter if its a AMD or Cyrix per se? I don't know if chip manufacturer has anything to do with the way it handles hard drives, but my computer does have a 486DLC40 Cyrix chip in it if anyone can relate that to my hard drive problems. Then again, like I said previously, my hard drive worked perfectly with all previous versions of both *BSD's, before NetBSD-1.0A and FreeBSD-1.1.5.1. ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 03:44:47 1994 To: Mike Halderman Cc: current-users@sun-lamp.cs.berkeley.edu From: "Louis A. Mamakos" Subject: Re: Adaptec 1742 Problems with -current 16. July <199407212221.PAA07942@io.nosc.mil> Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I don't want to take this to far off topic, but where can you get 1742's > these days? I can't find them locally anywhere. Does Buslogic make a EISA > controller? You can get 1742 controllers from DEC. They still sell them for their Alpha based systems which include EISA bus slots. They will sell them seperate from the actual systems. louie From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 04:44:17 1994 From: Open Carefully -- Contents Under Pressure X-Disclaimer: No way are these anyone else's opinions but mine. X-Real-Name: James Graham (*NOT* "Jim" -- that's my dad) X-Extension: 4219 X-Room-Number: 3308 X-Window-System: Release 5 X-No-Relation-To: greywolf@netcom.com, greywolf@blkhole.resun.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Chris G. Demetriou" , Jan-Hinrich Fessel Subject: Re: Adaptec 1742 Problems with -current 16. July Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu For what it's worth: We have Exabytes here, and we figured Exabytes are Exabytes and SCSI is SCSI. 'Tain't so, I'm afraid -- we needed to have several Exabyte PROMs changed out in order to make the Exabytes which were on our Suns (UNIX) work on our PCs (NT, Windows). I'm not sure whether it's a hardware or software in- compatibility (i.e. byte order or OS drivers). >From what you're describing, it almost seems to be an OS-centric problem. #define AUTHOR "cgd@alpha.bostic.com ("Chris G. Demetriou")" /* * > I upgraded my EISA Box from an AHA1542 to an 1742 and * > consequently use now the ahb-driver. Now I cannot use my * > Exabyte anymore. I probes incorrect as drive empty, and read * > or write attempts fail sometimes, often I get 0 bytes with no error * > when there is definitely data on the tape. The same configuraton * > worked with the 1542 with no flaws. * * Hmm. I've never tried the 1742 with an exabyte, but i know it works * fine on, e.g. the DAT on sun-lamp... * * I could believe it doesn't work -- Exabytes are weird... * * "i've got no clue" as to what could be wrong, though, * and can't test it because, now that i've got an exabyte around, * my 1742's aren't local anymore... heh. * * * * chris * * * * * */ #undef AUTHOR /* "cgd@alpha.bostic.com ("Chris G. Demetriou")" */ -- _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so) / ___\ _ \ __\ V / \ / /__ \| | __/WHAT: UNIX System Mangler...er, Admin \ \| | < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc. 3 Harbor Dr. \___|_|\_\__\|_| \/\/ \__/___/_| Sausalito, CA 94965 (415) 332-2344 x4219 see also: gandalf@netcom.com From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 04:51:18 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Christos Zoulas Cc: jan@encap.hanse.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Are you in touch with the XFree-Core-Team ? <199407210838.AA11044@cs4.deshaw.com> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Christos Zoulas writes: > | it think it is a good idea to info David Wexeblatt et al of the upcoming > | NetBSD-1.0 release so that they can put proper support for it in XFree-3.1. > > | I don't know how far they are with it but it would be bad if XFree-3.1 > | has no proper NetBSD-1.0 support. > | > > The current beta of XFree86 compiled under NetBSD-0.9C and runs under > 1.0A. There will be another beta this weekend, and I'll compile and install > it as soon as it becomes available. I'm running NetBSD 1.0-ALPHA (20-July-1994) with the latest alpha of XFree86 (from a couple of days ago), and it compiles and runs without a hitch. Don't worry, I stay VERY up-to-date on both systems. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 22 05:45:23 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: Mark Steven de Sagun-Tamola Cc: "Michael L. VanLoon -- Iowa State University" , current-users@sun-lamp.cs.berkeley.edu Subject: Re: Random timeouts in 1.0-ALPHA... Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mark Steven de Sagun-Tamola writes: > [...] > Thus, it can't be purely a hardware problem, and has to do with the new > wd drivers in the new kernels for both Free and Net BSD. Maybe the new > drivers are so much incredibly improved that it is finding some minute > problem with the disk, and keeps panicing over it, I don't know. But > whatever it is, it has caused me a lot of trouble. Is it actually causing your system to crash, or is it just printing out warning messages? 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 Fri Jul 22 07:18:58 1994 From: Andrew Cherry To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Son of unexpected trap Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Andrew Cherry writes: > Recently, I sent a message to amiga-dev about getting an unexpected > trap while trying to boot a recent kernel (from sources sup'ed on > Monday). I put a call to panic() in straytrap() in order to enter the > debugger (L-Amiga Alt F10 wouldn't work), so now I can provide more > information. Here is the trace: > > unexpected trap (vector offset 2) from 8000 > panic: foo > Stopped at _Debugger + 0x6: unlk a6 > db> trace > _Debugger(1fdb8,a39ab,fffffeb8,0,fffffec4) + 6 > _panic(a39a6,a397a,2,80000,fffffeb8,0,fffffef4) + 34 > _straytrap(80000,2) + 28 > _badtrap(?) > _edintr(0) + e > _intrhand(2200) + da > _lev4intr(?) > _setroot(ffffff6c,a2e38,0,0,aec85) + 1a > _configure(0,0,aec85,8,0) + 4c > _cpu_startup(af460,0,0,aec85,8) + 4dc > _main(ffffffb0) + 38 > > Hopefully there are no typos up there. :) Anyway, it's enough to tell you > something bad is happening when it tries to mount root. > > Again, my set up is A2000, GVP G-Force 040 with 12MB RAM. The only other > card is the IOExtender. Also, a kernel compiled from 7/13/94 sources > (possibly 7/12) boots fine. After further investigation, I have found how to avoid this. Removing "ed0 at ztwobus0 # dp8390 ethernet" from the GENERIC config file fixed the problem (yes, it was a pain to find this out). My kernel now boots properly. I don't own a dp8390 ethernet card, so I have no idea why this is happening! Is this a recent addition to the kernel, or has it been changed recently? The removal of that line was the only change from vanilla GENERIC needed to get the kernel working on my machine. -Andrew Cherry (cherry@mcs.anl.gov) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 23 00:43:36 1994 Subject: New kernel didn't work To: amiga-dev@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 146 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu The kernel from the new snapshot didn't work: unexpected trap (vector offset 2) from 10080000 I have an A4000/040 and use the IDE drive. Bernd From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 23 00:58:54 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: Son of unexpected trap Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu On Jul 21, 11:23pm, Andrew Cherry wrote: > Andrew Cherry writes: > > Recently, I sent a message to amiga-dev about getting an unexpected > > trap while trying to boot a recent kernel (from sources sup'ed on > > Monday). I put a call to panic() in straytrap() in order to enter the > > debugger (L-Amiga Alt F10 wouldn't work), so now I can provide more > > information. Here is the trace: ... > After further investigation, I have found how to avoid this. Removing > > "ed0 at ztwobus0 # dp8390 ethernet" > > from the GENERIC config file fixed the problem (yes, it was a pain > to find this out). My kernel now boots properly. I don't own > a dp8390 ethernet card, so I have no idea why this is happening! > Is this a recent addition to the kernel, or has it been changed > recently? The ed0 device was recently added - it supports the Hydra Ethernet card if I remember correctly. I think what is happening is that when the interrupt routine is called to see if the interrupt is from the ed0 device, it doesn't check correctly to see if the device was even configured. I ran into the same problem with the IDE driver. The check in if_ed.c is: if ((sc = edcd.cd_devs[unit]) == NULL) return (0); This check isn't quite correct, as edcd.cd_devs is a pointer to a table of pointers. That pointer should initially be NULL, but the above check is really testing to see if the contents at address 0 is NULL, which it won't be - it's a jump to a panic routine (for any kernel calls to a NULL address). If this is the case, that value is going to be used as the address of the device structure for ed0 and certainly isn't going to work. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 23 01:04:25 1994 From: Danny Lepage Subject: Broken ldd on Jul 9 snapshot? To: amiga-dev@sun-lamp.cs.berkeley.edu (amiga-dev mailing list) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 376 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Is ldd is broken on the Jul 9 snapshot? I've tryed ldd on binaries that are supposed to be dynamically linked (tar,tcsh...), but it reports something like: '..../binname not dynamically linked' instead of printing the list of dyn. libraries this binary depends on. Anybody else seen this behavior or am I broken ? :) Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 01:15:46 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Re: Random timeouts in 1.0-ALPHA... To: Mark_Weaver@brown.edu Cc: "Michael L. VanLoon -- Iowa State University" , 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 > > Thus, it can't be purely a hardware problem, and has to do with the new > > wd drivers in the new kernels for both Free and Net BSD. Maybe the new > > drivers are so much incredibly improved that it is finding some minute > > problem with the disk, and keeps panicing over it, I don't know. But > > whatever it is, it has caused me a lot of trouble. > > Is it actually causing your system to crash, or is it just printing > out warning messages? > > Mark > -------------------------------------------------------------------- > Email: Mark_Weaver@brown.edu | Brown University > PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science No, it does not make my computer crash at all. The only thing it does is make the system pause at random times to print out the error message I noted previously, and it is impossible to get any real work done, as the timeouts come up more and more frequently the more the disk gets used, thus causing the computer to continuously stop. Surprisingly, nothing gets ruined though...yet. ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 23 01:24:58 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- chopps Fri Jul 15 19:26:09 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/amiga Modified Files: machdep.c Log Message: ed driver for 8390 based ethernet boards (currently only hydra supported) original code from Timo Rossi , some major style changes (KNF, pull i386 comments in, et al.) plus converting to config.new by me. chopps Fri Jul 15 19:26:22 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/conf Modified Files: files.amiga.newconf Log Message: ed driver for 8390 based ethernet boards (currently only hydra supported) original code from Timo Rossi , some major style changes (KNF, pull i386 comments in, et al.) plus converting to config.new by me. chopps Fri Jul 15 19:26:31 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: ztwobus.c Log Message: ed driver for 8390 based ethernet boards (currently only hydra supported) original code from Timo Rossi , some major style changes (KNF, pull i386 comments in, et al.) plus converting to config.new by me. chopps Fri Jul 15 19:27:47 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Added Files: if_ed.c if_edreg.h Log Message: ed driver for 8390 based ethernet boards (currently only hydra supported) original code from Timo Rossi , some major style changes (KNF, pull i386 comments in, et al.) plus converting to config.new by me. chopps Fri Jul 15 19:29:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/conf Modified Files: GENERIC Log Message: add ed0 to GENERIC config. --------------------------------- cgd Fri Jul 15 20:32:37 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/amiga Revision/Branch: netbsd-1-0 Modified Files: machdep.c Log Message: update from trunk, per chopps cgd Fri Jul 15 20:32:48 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/conf Revision/Branch: netbsd-1-0 Modified Files: GENERIC files.amiga.newconf Log Message: update from trunk, per chopps cgd Fri Jul 15 20:32:58 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: ztwobus.c Log Message: update from trunk, per chopps --------------------------------- chopps Sat Jul 16 12:45:34 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/amiga Modified Files: machdep.c Log Message: fix a couple things pointed out from Michael. chopps Sat Jul 16 12:45:45 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: atzsc.c Log Message: fix a couple things pointed out from Michael. --------------------------------- cgd Sat Jul 16 14:15:17 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/amiga Revision/Branch: netbsd-1-0 Modified Files: machdep.c Log Message: from trunk, per chopps cgd Sat Jul 16 14:15:22 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: atzsc.c Log Message: from trunk, per chopps --------------------------------- chopps Sun Jul 17 18:37:52 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: fd.c Log Message: don't hang if no floppy in system. --------------------------------- cgd Sun Jul 17 19:06:18 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: fd.c Log Message: from trunk; fix a hang. from chopps --------------------------------- cgd Mon Jul 18 01:02:31 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386 In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386 Revision/Branch: netbsd-1-0 Modified Files: Makefile Log Message: update from trunk. cgd Mon Jul 18 01:03:24 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386 In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/i386 Modified Files: Makefile Log Message: deal properly with 'obj' dirs, when making boot blocks, etc. chopps Mon Jul 18 01:04:39 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/amiga Modified Files: machdep.c Log Message: increase nswbuf to 3/4 nbuf instead of 1/2 nbuf. chopps Mon Jul 18 01:05:42 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/conf Modified Files: GENERIC Log Message: enable CD9660, and remove DEBUG. chopps Mon Jul 18 01:06:45 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: siop.c Log Message: fix so it compiles without DEBUG. mycroft Mon Jul 18 01:07:53 PDT 1994 Update of /b/source/CVS/src/sys/isofs/cd9660 In directory sun-lamp.cs.berkeley.edu:/d/users/mycroft/src/sys/isofs/cd9660 Modified Files: cd9660_vfsops.c Log Message: For VOP_VGET(), pretend that relocated directories don't exist, for now. --------------------------------- cgd Mon Jul 18 01:25:13 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/amiga In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/amiga Revision/Branch: netbsd-1-0 Modified Files: machdep.c Log Message: update from trunk, per chopps cgd Mon Jul 18 01:25:17 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/conf In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/conf Revision/Branch: netbsd-1-0 Modified Files: GENERIC Log Message: update from trunk, per chopps cgd Mon Jul 18 01:25:24 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: siop.c Log Message: update from trunk, per chopps --------------------------------- cgd Tue Jul 19 22:44:22 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/i386/include Modified Files: types.h Log Message: define __BIT_TYPES_DEFINED__ for compatibility with things like BIND and nvi cgd Tue Jul 19 22:44:24 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/m68k/include Modified Files: types.h Log Message: define __BIT_TYPES_DEFINED__ for compatibility with things like BIND and nvi cgd Tue Jul 19 22:44:26 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/pc532/include Modified Files: types.h Log Message: define __BIT_TYPES_DEFINED__ for compatibility with things like BIND and nvi cgd Tue Jul 19 22:44:28 PDT 1994 Update of /b/source/CVS/src/sys/arch/pmax/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/pmax/include Modified Files: types.h Log Message: define __BIT_TYPES_DEFINED__ for compatibility with things like BIND and nvi cgd Tue Jul 19 22:44:30 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/include In directory sun-lamp.cs.berkeley.edu:/e/users/cgd/trees/kernels/sys/arch/sparc/include Modified Files: types.h Log Message: define __BIT_TYPES_DEFINED__ for compatibility with things like BIND and nvi cgd Tue Jul 19 22:48:47 PDT 1994 Update of /b/source/CVS/src/sys/arch/i386/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/i386/include Revision/Branch: netbsd-1-0 Modified Files: types.h Log Message: update from trunk. cgd Tue Jul 19 22:48:51 PDT 1994 Update of /b/source/CVS/src/sys/arch/m68k/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/m68k/include Revision/Branch: netbsd-1-0 Modified Files: types.h Log Message: update from trunk. cgd Tue Jul 19 22:48:55 PDT 1994 Update of /b/source/CVS/src/sys/arch/pc532/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/pc532/include Revision/Branch: netbsd-1-0 Modified Files: types.h Log Message: update from trunk. cgd Tue Jul 19 22:49:00 PDT 1994 Update of /b/source/CVS/src/sys/arch/pmax/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/pmax/include Revision/Branch: netbsd-1-0 Modified Files: types.h Log Message: update from trunk. cgd Tue Jul 19 22:49:07 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/include In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/sparc/include Revision/Branch: netbsd-1-0 Modified Files: types.h Log Message: update from trunk. --------------------------------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 01:34:00 1994 From: Dave Burgess Subject: Kermit is weird.... To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1199 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I think I have found an oddness that I had not seen before either in the system or in the mailing list... When I fire up kermit, the systems waits for something to happen right before it connects to the /dev/tty02 port. The sure fire way to make it connect is to ^Z and then 'fg' the job. When the 'fg' restarts the process, the port is connected and the SLIP connection script (user-id stuff notwithstanding) to establish my SLIP connection runs. I have tried several other signals (^C for example) and they all have the same effect. Whatever event kermit seems to be waiting for is suddenly satisfied and the program jaunts of merrily connecting my to the outside world. I find it just the least bit spooky. I am running a kernel with -current from about the 15th (although my sources are actaully up to about the minute). Here is the compile info banner: NetBSD 1.0-ALPHA (CYNJUT.TEST) #3: Mon Jul 18 23:25:37 PDT 1994 root@:/usr/src/sys/arch/i386/compile/CYNJUT.TEST CPU: i386DX (386-class CPU) The kermit is from the last time that kermit was in 'othersrc'. BTW, I haven't looked real hard, but I thought I saw kermit getting deleted and not replaced in the sup mail I got.... From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 01:43:00 1994 From: "Harry Schreurs" To: gwr@mc.com (Gordon W. Ross) Subject: Re: more on the swstrategy panic Cc: port-sun3@sun-lamp.cs.berkeley.edu X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v3.1 (R1a) Sender: owner-current-users@sun-lamp.cs.berkeley.edu Gordon, I think, I have NetBSD/sun3 almost running :-) > This is most likely caused by using an old config program that still > thinks dev_t is a short (it recently became a long). This could cause > the code at nfs_vfsopt.c:258 to think swap is already configured. > Other places that care about dev_t could have similar problems... > (Look out for dev_t pitfalls!) I don't think this was the cause of my problem! I was using, and still are, 'config.new' that is dated Feb. 4 1994. This program was part of Adam's binary distribution and still it can be found on 'sun-lamp'. It's runs without any problems on my sun 3/E ( SUNOS 4.1.1_U1 ). I also tried a newer config program, but that gave me some problems! It didn't like the line: config netbsd swap nfs It gave the following error messages: HILTON:44: netbsd: no root device specified HILTON has no configurations! *** stop The swapping problem disappeared when I replaced some files by newer ones: current ver. previous ver. Makefile.sun3 ver. 1.20.2.1 ( ver. 1.20 ) delay.s ver. 1.1.2.1 ( ver. 1.1 ) pmap.c ver. 1.28.2.3 ( ver. 1.28 ) trap.c ver. 1.25.2.2 ( ver. 1.25 ) nfs_bio.c ver. 1.15.2.2 ( ver. 1.13 ) nfs_boot.c ver. 1.6.2.2 ( ver. 1.4 ) vm_swap.c ver. 1.23.2.1 ( ver. 1.20 ) This cured the 'swstrategy' panic. But, I think I found another problem. I'am not sure what is happening. It has something to do with the value of the option SYMTAB_SPACE in the config file. This is what I get with SYMTAB_SPACE set to 85000: Boot: vmunix Size: 535440+111752+62832 bytes console on zs0 (ttya) DDB: found symbols [38724 + 41209 bytes] Stopped at _Debugger+0x6: unlk a6 db> cont Copyright (c) .... ... Model: Sun 3/50 real mem = 4145152 avail mem = 3088384 using 25 buffers containing 204800 bytes of memory ... kd0 at mainbus0 nfs_boot: using network interface 'le0' nfs_boot: client=0x86bc4514, server=0x86bc450b nfs_boot: hostname=hilton root on tempest:/mnt/export/hilton/root swap on tempest:/mnt/export/hilton/swap WARNING: real-time clock reports a time earlier than last write to root filesystem. Trusting filesystem... Enter pathname of shell or RETURN for sh: sh: warning: running as root with dot in PATH # mount -u / # mount /usr # exit pa_to_pvp: bad pa=0x3f4000 Stopped at _Debugger+0x6: unlk a6 db> cont panic: save_modified_bits: bad pa=3f4000 Stopped at _Debugger+0x6: unlk a6 db> Setting SYMTAB_SPACE to 00001 does give the following: Boot: vmunix Size: 535440+26760+62832 bytes console on zs0 (ttya) DDB: no symbols Stopped at 0xe0711aa: unlk a6 db> cont Copyright (c) .... ... Model: Sun 3/50 real mem = 4145152 avail mem = 31662112 using 25 buffers containing 204800 bytes of memory ... kd0 at mainbus0 nfs_boot: using network interface 'le0' nfs_boot: client=0x86bc4514, server=0x86bc450b nfs_boot: hostname=hilton root on tempest:/mnt/export/hilton/root swap on tempest:/mnt/export/hilton/swap WARNING: real-time clock reports a time earlier than last write to root filesystem. Trusting filesystem... Enter pathname of shell or RETURN for sh: sh: warning: running as root with dot in PATH # mount -u / # mount /usr # exit setting tty flags starting network add host hilton.oce.nl: gateway localhost starting rpc daemons: portmap. starting system logger, time daemon. checking for core dump... done. building databases... clearing /tmp standard daemons: update cron. starting network daemons: routed printer inetd. >>> Process got killing signal b starting local daemon:. runtime link editor directory cache >>> Process got killing signal b Fri Jul 22 12:50:12 1994 Jul 22 12:50:14 hilton init: kernel security level changed from 0 to 1 NetBSD/sun3 (hilton.oce.nl) (console) login: >>> Jul 22 12:52:01 hilton inetd[69]: pmap_set: 10001 1 17 1041: Address already in use >>> Jul 22 12:54:01 hilton inetd[69]: pmap_set: 10001 2 17 1041: Address already in use >>> Jul 22 12:56:01 hilton inetd[69]: pmap_set: 10001 3 17 1041: Address already in use >>> Jul 22 12:58:01 hilton inetd[69]: pmap_set: 10002 2 17 1042: Address already in use >>> Jul 22 13:00:01 hilton inetd[69]: pmap_set: 10002 3 17 1042: Address already in use >>> Jul 22 13:02:01 hilton inetd[69]: pmap_set: 10008 1 17 1043: Address already in use Question 1: Why does the value of SYMTAB_SPACE has such an influence? Question 2: Where are these signals coming from? Question 3: What's inetd trying to say? Question 4: What should go into my `config' file to satisfy newer config.new executables? Question 5: The login message appears garbled on the console. Where can I tell 'login' to use 8 bits, no parity. Remember that getty isn't running at that moment, so /etc/ttys isn't of any use! I almost forgot to tell you, that I succesfully used gcc-2.6.0 to cross- compile the sun3 kernel sources. By the way, instead of typing "mount -u /" I once typed "mount u /". I must admit this wasn't what I wanted to type. But after this the system was completely f... up ;-) # mount u / Bus error # mount /usr mount: error 43 # ps ps: error 43 # sh sh: error 43 Members of the Core-Team, are you listening? This doesn't seem OK to me! Kind Regards, Harry ------------------------------------------------------------------------------ H.L Schreurs Email: hls@oce.nl Business Unit Printing Systems Phone: +31 77 593775 Oce Nederland B.V. Fax: +31 77 595434 The Netherlands ------------------------------------------------------------------------------ ########################################################### # This note does not necessarily represent the position # # of Oce-Nederland B.V. Therefore no liability or # # responsibility for whatever will be accepted. # ########################################################### From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 01:55:08 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problems with source tarballs <9407222056.AA08828@ponderous.cc.iastate.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu ignore that last suggestion. adam is lost in space. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 01:57:42 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: problems with source tarballs From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I've been trying to build kernels with the source tarballs from this past weekend with poor results. I'm using the binaries from the latest binary dist tarballs, with the GENERIC-BT kernel out of that set. I did rebuilt config before doing kernels, from the sources with the rest of the source tarballs. First, I had that problem that I posted about a few days ago where some symbols were undefined (P_BACK, P_FORW, and P_PRIORITY). It turns out that this was because I had a genassym binary in that dir that didn't get removed by make clean, and didn't get rebuilt by the makefile. Once I removed that by hand, I was able to get a kernel to link. However, every kernel I've made so far, no matter what options I enable or disable in my config file, doesn't get past the setting the root partitions stage. Also, a kernel made for me on someone else's machine with sources from this week does exactly the same thing. The binary dist GENERIC-BT kernel does boot up ok, but doesn't have support for all my devices. What happens on the kernels I build is this: it goes through all the autoconfiguration stuff, and everything looks like it's working ok. Then it finally gets to the part at the end where it prints the ttymask, biomask, etc. stuff. Right there it just sits forever, and never goes any further. The hard drive doesn't flutter or anything. It's not hung, though, because the keycap/numlock buttons turn the lights on and off when I press them. If I break into the kernel debugger at this point and do a trace, here's what I get: _Debugger... _sgetc... _pcrint... _Xintr1... _configure(f8185b13, be, be000, f8185b03, ad0000) at _configure+0x8 _cpu_startup(f81a7f04, 1dcfac, 1eb000, 1eb000, f8256000) at _cpu_startup+0x2a6 _main(f7bfff8c) at _main+0x3b I built my kernel with these options: -O6 -m486 -pipe. I don't know what the other guy used for options, but his kernel behaves the same way. As I said, the GENERIC-BT kernel boots fine, and my old kernel (from May 1) was booting fine on this hardware. I have a 486DLC (in a 386 motherboard), 13MB of RAM, a bt747s SCSI controller at the default address/IRQ, trying to boot off a Quantum Q425s SCSI drive, I also have a Logitech bus mouse at IRQ 5, 2 serial ports at the default com1/com2 addresses and IRQ's, a Mitsumi CDROM at IRQ 2/9, an ATI VGA card, and an ATI 8514/Ultra (Mach8) card. I don't currently have my ethernet card in the machine. Can anyone give me a clue as to what the heck is going on??? If you want me to do anything in the debugger, I can repeat this at will. All I have to do is try to boot one of my current kernels and break into the debugger. Just for kicks, here's my current config file. I've tried enabling and disabling various things, so some options commented/uncommented here may have been different in one of my builds... # original config file: # GENERICAHBBT -- Generic machine w/ahb and bt drivers -- distribution floppy # # STINGRAY -- Config for Michael VanLoon's i386 box stingray.cc.iastate.edu # MINDBENDER -- modified for change to MindBender.HeadCandy.com # machine "i386" cpu "I386_CPU" # Cyrix 486DLC obviates need for this cpu "I486_CPU" cpu "I586_CPU" ident MINDBENDER timezone 6 dst maxusers 64 #maxfdescs 1024 options DUMMY_NOPS, MACHINE_NONCONTIG, "COMPAT_09" options SWAPPAGER, VNODEPAGER, DEVPAGER options KTRACE, FIFO options SCSI, FFS options FDESC, KERNFS, PROCFS #, PORTAL, ISOFS #options NULLFS, "CD9660" #options QUOTA, LOFS, MFS, MSDOSFS options INET, NFSCLIENT, NFSSERVER, GATEWAY, MULTICAST #options HDLC, CCITT #options NS, ISO, TPIP, EON, CCITT options "COMPAT_43", "TCP_COMPAT_42", "COMPAT_NOMID", "USER_LDT" options XSERVER, UCONSOLE options FASTLINKS, LKM options COM_BIDIR # is this needed? #options MATH_EMULATE # Cyrix 387 obviates need for this options SYSVMSG # System V message queues; see msg.h options SYSVSEM # System V semaphores; see sem.h options SYSVSHM # System V shared memory options SHMMAXPGS=1024 options DDB options DIAGNOSTIC options PCVT_NSCREENS=8 config netbsd root on sd0 swap on sd0 and wd0 # Bus interface: controller isa0 # ISA/EISA # Console drivers: #device pc0 at isa? port "IO_KBD" tty irq 1 device vt0 at isa? port "IO_KBD" tty irq 1 # SCSI controllers and devices: controller bt0 at isa? port "IO_BT0" bio irq 11 master scsibus0 at bt0 drive sd0 at scsibus0 slave ? drive sd1 at scsibus0 slave ? drive sd2 at scsibus0 slave ? tape st0 at scsibus0 slave ? drive cd0 at scsibus0 slave ? #drive ch0 at scsibus0 slave ? # AT ST506 (IDE/MFM/RLL) hard drives: controller wdc0 at isa? port "IO_WD1" bio irq 14 disk wd0 at wdc0 drive ? disk wd1 at wdc0 drive ? #controller wdc1 at isa? port "IO_WD2" bio irq 15 #disk wd2 at wdc1 drive ? #disk wd3 at wdc1 drive ? # Floppy drives: controller fdc0 at isa? port "IO_FD1" bio irq 6 drq 2 disk fd0 at fdc0 drive ? #disk fd1 at fdc0 drive ? # Mitsumi CD-ROM: #device mcd0 at isa? port 0x300 bio irq 9 # Floppy controller tape support: #device wt0 at isa? port 0x300 bio irq 5 drq 1 # "standard" PeeCee com ports: device com0 at isa? port "IO_COM1" tty irq 4 device com1 at isa? port "IO_COM2" tty irq 3 #device com2 at isa? port "IO_COM3" tty irq 9 #device com3 at isa? port "IO_COM4" tty irq 9 # BocaBoard quad-16550 with custom com driver: #device com4 at isa? port 0x100 tty irq 12 #device com1 at isa? port 0x108 tty #device com2 at isa? port 0x110 tty #device com3 at isa? port 0x118 tty # Logitech bus mouse: device lms0 at isa? port "IO_BMS1" tty irq 5 # Parallel ports: device lpt0 at isa? port "IO_LPT1" tty irq 7 device lpt1 at isa? port "IO_LPT2" tty #device lpt2 at isa? port "IO_LPT3" tty # Sound Blaster: #device sb0 at isa? port 0x220 bio irq 7 drq 1 # Ethernet drivers: device ed0 at isa? port 0x280 net irq 10 iomem 0xd0000 #device ep0 at isa? port ? irq ? # Math coprocessor/emulation support: device npx0 at isa? port "IO_NPX" irq 13 # Pseudo devices: pseudo-device ether 1 # ethernet device pseudo-device log # system logger pseudo-device loop # loopback device pseudo-device pty 64 # pseudo terminals pseudo-device sl 1 # slip device pseudo-device ppp 1 # ppp device pseudo-device speaker # simple speaker driver pseudo-device bpfilter 4 # berkeley packet filter pseudo-device vn 4 # v-nodes #pseudo-device audio # audio device (Sound Blaster) ----------------------------------------------------------------------------- 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 Jul 23 01:58:18 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problems with source tarballs <9407222056.AA08828@ponderous.cc.iastate.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu Michael, One idea: remove 'ep' from your kernel config and see if that eliminates the problem. Since the weekly source snapshot we disconvered some autoconfig bugs in that driver that tended to cause all sorts of interesting havoc. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:09:37 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, llunch@knuth.cba.csuohio.edu Subject: Re: reset on boot Sender: owner-current-users@sun-lamp.cs.berkeley.edu The line "text=..." finishes and poof. This sounds like a symptom of using a new kernel with DDB with an old boot block. Try updating your boot block and let me know whether or not the problem persists. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:16:54 1994 Subject: From: llunch@knuth.cba.csuohio.edu (Jason Baker) To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2229 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hello, I started using NetBSD early in June. This week, I have been trying to build a current kernel without success. No matter what I do, the machine will always reset as soon as the kernel is loaded. The line "text=..." finishes and poof. I had been running the May 2 binaries, and I have slowly replace the following with July 16 binaries: config, make, cc, cpp, cc1, as, ld, /usr/include. None of these changes have had any effect. I am completely at my wits end. Perhaps someone can spot something I am doing wrong. My config file looks like this: # # HASSAN -- you liquifactionalist bitch, never darken my rumpus room again # machine "i386" cpu "I386_CPU" ident HASSAN timezone 4 dst maxusers 10 options SWAPPAGER,VNODEPAGER,DEVPAGER options FFS #options INET, NFSCLIENT, NFSSERVER #NFSCLIENT pulls in nfs_boot.c which requires ether #options INET, NFSSERVER options INET options "CD9660" options "COMPAT_43" options "TCP_COMPAT_42" options XSERVER,UCONSOLE options MSDOSFS options KERNFS options SCSI options "MATH_EMULATE" options "COMPAT_NOMID" options "COMPAT_09" options "MACHINE_NONCONTIG" options KTRACE options DDB options DIAGNOSTIC options LKM config netbsd root on wd0 swap on wd0 controller isa0 device pc0 at isa? port "IO_KBD" irq 1 device com0 at isa? port "IO_COM1" irq 4 device com1 at isa? port "IO_COM2" irq 3 device com2 at isa? port "IO_COM3" irq 5 device lpt0 at isa? port "IO_LPT1" irq 7 device lpt1 at isa? port "IO_LPT2" #device lpt2 at isa? port "IO_LPT3" controller wdc0 at isa? port "IO_WD1" irq 14 disk wd0 at wdc0 drive ? disk wd1 at wdc0 drive ? controller fdc0 at isa? port "IO_FD1" irq 6 drq 2 disk fd0 at fdc0 drive ? disk fd1 at fdc0 drive ? controller aic0 at isa? port 0x340 irq 11 drq 6 master scsibus0 at aic0 disk sd0 at scsibus0 slave ? disk sd1 at scsibus0 slave ? disk sd2 at scsibus0 slave ? disk sd3 at scsibus0 slave ? tape st0 at scsibus0 slave ? tape st1 at scsibus0 slave ? disk cd0 at scsibus0 slave ? disk cd1 at scsibus0 slave ? device npx0 at isa? port "IO_NPX" irq 13 #pseudo-device ether pseudo-device log pseudo-device loop pseudo-device pty 32 pseudo-device sl 2 pseudo-device speaker thanks, Jason From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:17:06 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: panic ffs_clusteralloc: lost block Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can get this consistently on a Dell Pentium/90 dumping from wd0a and restoring to sd0a. Here's the traceback: _ffs_blkpref(f871e100,3,2c1,10) _ffs_blkpref(f871e100,3,8058,2,f8164e88) _ffs_reallocblocks(f7bffe20,f871e100,f8ed1000,f86c2000,101000) _ffs_cluster_write(f8c928c8,101000,0) _ffs_write(f7bffee4,f871dec0,1000,f7bfff94,0) _vn_write(f871dec0,f7bfff30,f86fe280,f7bf9388,f86ff300) _write(f86ff300,f7bfff94,f7bfff8c,0,f7bf97b8) _syscall I hope that helps. christos From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:18:12 1994 From: mycroft@gnu.ai.mit.edu (Charles M. Hannum) To: current-users@sun-lamp.cs.berkeley.edu Subject: FYI, GCC 2.6.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just compiled a NetBSD/i386 kernel with GCC 2.6.0, and it seems to work just fine. There was a small change to machdep.c required, which I've checked in. Should you desire to compile GCC 2.6.0, I did get all of the relevant changes for the i386 and hp300 ports (and in the next release, all of the m68k ports) in right before the release. However, there's a slight bogon in the Makefile; you'll need to edit `Makefile.in' before configuring, and either remove the definition of `USER_H', or move it above the `####target overrides' line so that x-netbsd call nullify it. If you build things with GCC 2.6.0 and later report bugs in them, please make sure to specify that you are not using the compiler we supply. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:21:46 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, llunch@knuth.cba.csuohio.edu Subject: Re: reset on boot Sender: owner-current-users@sun-lamp.cs.berkeley.edu Try updating your boot block [...] Um, before you do this, make sure you have the latest sources. For a while, the boot block would not work correctly with an old file system if you rebuilt it. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 02:47:11 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: (in)secure /bin/sh scripts Sender: owner-current-users@sun-lamp.cs.berkeley.edu When /bin/sh starts up, it reads in the file named in the environment variable "ENV". I don't see any option that can turn this off, from looking at both the man page and the source. This seems like a gaping security hole to me. Assuming I read the source correctly, can I suggest making sh ignore ENV by default if uid!=euid? *** src/bin/sh/main.c.mhw1 Sun Jun 12 06:01:35 1994 --- src/bin/sh/main.c Fri Jul 22 13:30:47 1994 *************** *** 159,166 **** } state2: state = 3; ! if ((shinit = lookupvar("ENV")) != NULL && ! *shinit != '\0') { state = 3; read_profile(shinit); } --- 159,167 ---- } state2: state = 3; ! if (getuid() == geteuid() && ! (shinit = lookupvar("ENV")) != NULL && ! *shinit != '\0') { state = 3; read_profile(shinit); } I haven't extensively looked for other possible security holes, but as long as sh isn't a login shell, I don't think it loads any other files. Of course, always make sure you set your PATH at the beginning of the script. 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 Sat Jul 23 02:52:08 1994 From: Mike Halderman Subject: Re: Kermit is weird.... To: burgess@s069.infonet.net (Dave Burgess) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Dave Burgess writes: > > I think I have found an oddness that I had not seen before either in > the system or in the mailing list... > > When I fire up kermit, the systems waits for something to happen right > before it connects to the /dev/tty02 port. The sure fire way to make > it connect is to ^Z and then 'fg' the job. When the 'fg' restarts the > process, the port is connected and the SLIP connection script (user-id > stuff notwithstanding) to establish my SLIP connection runs. > > I have tried several other signals (^C for example) and they all have > the same effect. Whatever event kermit seems to be waiting for is > suddenly satisfied and the program jaunts of merrily connecting my to > the outside world. > > I find it just the least bit spooky. > > ... > I think there is some weirdness with sigblock(). I had some problems with 'xv' sleeping forever. I reconfigured it to use usleep() and it is fine now. I haven't had time to trace down the problem yet. Is kermit doing anything like this? -Mike From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 08:35:21 1994 From: Todd.Williamson@cs.cmu.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: swap on sd1b? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I decided I'd finally try out NetBSD 1.0a. Since I need to have a stable system running here, I figured "Hey, I'll just clear off a hard disk, install 1.0a on it, and then I can boot whichever system I need." So I cleared off my 270 MB sd1 drive, partitioned it so that it had its own swap space, downloaded the July 13 binary snapshot, and installed it. Whenever I try to boot off that drive, I get a panic right after it says "changing root device to sd1a". The error message is "swfree error 6" I think - it reboots too fast for me to be sure. The funny thing is, if I copy my 0.9 kernel onto that disk, it boots fine until it can't load 1.0a's /bin/sh. On a hunch, I swapped the SCSI id's of the first two drives, and it turns out that 1.0a will boot fine if the drive is sd0. So, am I doing something wrong, or is this a bug? The system: 486DX266, Bustek 542B, 16MB RAM, a bunch of SCSI devices (three 270 MB disks and a CDROM). Thanks, -Todd. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 23 10:18:32 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Todd.Williamson@cs.cmu.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: swap on sd1b? From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Whenever I try to boot off that drive, I get a panic right after it says > "changing root device to sd1a". > The error message is "swfree error 6" I think - it reboots too fast for > me to be sure. > this is caused by a bug in vm_swap.c fixed since that snapshot. Basically it is intolerant of not finding the primary swap partition as configured in the kernel. > The funny thing is, if I copy my 0.9 kernel onto that disk, it boots > fine until it can't load 1.0a's /bin/sh. > > On a hunch, I swapped the SCSI id's of the first two drives, and it > turns out that 1.0a will boot fine if the drive is sd0. > > So, am I doing something wrong, or is this a bug? > this is a bug, and it has been fixed. if you want to run the kernel of off sd1, you should rebuild the kernel to reflect that. > The system: 486DX266, Bustek 542B, 16MB RAM, a bunch of SCSI devices > (three 270 MB disks and a CDROM). > > Thanks, > > -Todd. > The fix is in the current sources. If you can't upgrade due to bootstrapping problems or somesuch grab 'vm_swap.c' via ftp from lamp. later, Adam Glass From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 24 03:48:34 1994 Subject: Re: 80 column console From: Tim Newsham To: chopps@emunix.emich.edu Cc: sjr@zombie.ncsc.mil, amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > No the 80 col. display required overscan which I will not enable fby default. How about a smaller font that could do 80x24 or better in a non-interlaced resolution? What are the disadvantages of overscan? Does it eat up more cpu or memory bandwidth? > Chris. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 03:56:08 1994 Subject: Re: Gollies, a long one. From: Tim Newsham To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Cc: chopps@emunix.emich.edu, aldous@mame.mu.oz.au, amiga@sun-lamp.cs.berkeley.edu, groo@menger.eecs.stevens-tech.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu > > One more thing: As is just starting to be discussed on > 'current-users', I am suffering a strange spurious SIGSEGV during > large compiles. Normally, cpp get creamed with it, but other > utilities have been known to die at completely unpredictable > times during a compile. Simply restart the compile, and it works. > (until the next random SIGSEGV). > > Someone on current mentioned that it sounds a lot like a strange > pmap() bug that happened around April/May. Are you running on a GVP board with 16 bit ram? Could this be the hardare bug with GVP 16-bit ram? > -wps From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 04:02:50 1994 From: Alan Bair Subject: Problems with adosfs & tapes To: amiga@sun-lamp.cs.berkeley.edu (Amiga NetBSD - General) X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu I was trying to install the lastest snapshot this weekend and ran into several problems. I installed the rootfs with no problems, but booting the "netbsd" generated a contiuous set of error messages. I didn't get the exact text, but I read a posting from someone else that had the text. To get past that problem, I booted with the "netbsd-a3000" kernel. This boots OK, but I cannot get my tape drive or adosfs to work so I can install the new binaries. I checked with disklabel and found the path for my ADOS partition with the NetBSD binaries; /dev/sd0g. Then I tried; mount -t ados /dev/sd0g /mnt. It fails with the message; ados: mount: Operation not supported on device. For the tape drive, I used l:tape-handler (dtape) to copy the binary tar.gz files onto the tape on the ADOS side. I can gzip -d | tar from the tape and read everything on the ADOS side. Under NetBSD, any read attempt comes back with a premature EOF like there was no data on the tape. As test, I tared some files to tape under NetBSD and tried to untar it under ADOS. This failed in a similar manner. Any hints would be appreciated, espcially on using the adosfs. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 04:09:25 1994 From: "Stephen J. Roznowski" To: abair@sol-tx.sps.mot.com, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Problems with adosfs & tapes Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: Alan Bair > > I was trying to install the lastest snapshot this weekend > and ran into several problems. I installed the rootfs with > no problems, but booting the "netbsd" generated a contiuous > set of error messages. I didn't get the exact text, but > I read a posting from someone else that had the text. > > To get past that problem, I booted with the "netbsd-a3000" > kernel. This boots OK, but I cannot get my tape drive or > adosfs to work so I can install the new binaries. Don't know about the tapedrive, but the current A3000 kernel does NOT have adosfs support in it. I'm planning on fixing this when I generate the "4" different kernels as previously discussed. > I checked with disklabel and found the path for my ADOS > partition with the NetBSD binaries; /dev/sd0g. Then I > tried; mount -t ados /dev/sd0g /mnt. It fails with the > message; ados: mount: Operation not supported on device. > > For the tape drive, I used l:tape-handler (dtape) to copy > the binary tar.gz files onto the tape on the ADOS side. > I can gzip -d | tar from the tape and read everything on > the ADOS side. Under NetBSD, any read attempt comes back > with a premature EOF like there was no data on the tape. > As test, I tared some files to tape under NetBSD and > tried to untar it under ADOS. This failed in a similar > manner. > > Any hints would be appreciated, espcially on using the > adosfs. -SR From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 04:39:25 1994 From: mycroft@gnu.ai.mit.edu To: Todd.Williamson@CS.CMU.EDU, current-users@sun-lamp.cs.berkeley.edu Subject: Re: swap on sd1b? Sender: owner-current-users@sun-lamp.cs.berkeley.edu The error message is "swfree error 6" I think - [...] This is generally caused by a combination of two things. 1) If you have `swap on sd0b' in your kernel config, then it will always try to get swap from there. If you use `swap generic', it should switch to the `b' partition of whatever drive you booted from. 2) If the primary (first) swap partition is not configured (i.e. the device doesn't exist, or the partition is unavailable), then the kernel would panic. The latter problem has been fixed. The former is really a bug in your config file. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 04:39:27 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: top machine.c for NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've ported the 4.4 machine.c for top-3.2 to NetBSD. machine.c can be ftped from resort.com://pub/machine.c The rest of top can be grabbed from iastate or any ports mirror site. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 04:39:42 1994 To: Dave Burgess Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Kermit is weird.... <199407222139.QAA00545@s069.infonet.net> From: Hannes Deeken Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199407222139.QAA00545@s069.infonet.net>, Dave Burgess writes: > I think I have found an oddness that I had not seen before either in > the system or in the mailing list... > > When I fire up kermit, the systems waits for something to happen right > before it connects to the /dev/tty02 port. The sure fire way to make > it connect is to ^Z and then 'fg' the job. When the 'fg' restarts the > process, the port is connected and the SLIP connection script (user-id > stuff notwithstanding) to establish my SLIP connection runs. > > I have tried several other signals (^C for example) and they all have > the same effect. Whatever event kermit seems to be waiting for is > suddenly satisfied and the program jaunts of merrily connecting my to > the outside world. > > I find it just the least bit spooky. It would have helped if you mentioned the state of the com port (e.g. stty output) and the settings you use in kermit. I guess your port has clocal cleared, and kermit is configured to assume that there is no carrier on that port present. In this case, kermit hangs in ttopen(), line 1597 (at least in edit 189): 1595: #ifndef NOCOTFMC /* = NO Close(Open()) To Force Mode Change */ 1596: /* Reportedly lets uugetty grab the device in SCO UNIX 3.2 / XENIX 2.3 */ 1597: close( priv_opn(ttname, O_RDWR) ); /* Magic to force change. */ 1598: #endif /* NOCOTFMC */ priv_opn() calls open(), and this blocks, waiting for carrier. Just compile kermit with -DNOCOTFMC, and your problem should go away. At least, it did for me :) Ciao, Hannes -- Hans-Christoph Deeken | hannes@flinx.{RoBIN.de,hotb.sub.org} (home) Paul-Wagner-Str. 58 | deeken@iti.informatik.th-darmstadt.de (university) 64285 Darmstadt | IRC: Glenlivet | "Tuuut." -- Karate Kid 2 From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 04:55:29 1994 To: Mike Halderman Cc: "Chris G. Demetriou" , current-users@sun-lamp.cs.berkeley.edu, kapela@sirius.poly.edu Subject: Re: Buslogic controllers of "Thu, 21 Jul 94 19:20:31 EDT."<9407212320.AA07680@alpha.bostic.com> From: "Theodore S. Kapela" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> I don't want to take this to far off topic, but where can you get 1742's >> these days? I can't find them locally anywhere. Does Buslogic make a EISA >> controller? > >they make two, the 742 and the 747, both of which are supported by >NetBSD's 'bt' driver. If i remember the specs right, the 747 is a >fair bit faster than the 1742, and the 742 slightly faster, for some >types of transfers, or something like that... The 742 is an EISA bus master SCSI-2 controller with dual floopy. It uses single-ended passive termination. (Max 5MB/sec sync/async, 33MB/sec burst) The 747S is an EISA bus master FAST SCSI-2 controller with dual floppy (including 2.88 MB support). It uses single-ended active termination. (Max 10MB/sec sync, 7MB/sec async, 33MB/sec burst) The 747D is an EISA bus master FAST SCSI-2 controller with dual floppy (including 2.88 MB support). It uses differential termination. (Max 10MB/sec sync, 7MB/sec async, 33MB/sec burst) The 747 can offer a bit better performance than the 742 since it is a FAST SCSI controller, but only with devices that support FAST SCSI. The differential controller has a max SCSI bus length of 25 meters (standard), while the single-ended controllers have a max bus length of 6 meters (standard) Take note, though, that in practice single-ended FAST SCSI controllers have a limitation of more like 2-3 meters, though with good cables and devices you could probably stretch it further. I have a 747S and am very happy with it. -Ted -- Theodore S. Kapela Polytechnic University kapela@sirius.poly.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 05:10:25 1994 X-Sender: buckwild@stein3.u.washington.edu From: Mark Steven de Sagun-Tamola Subject: Need old wd driver files before change...PLEASE HELP! 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 Well, since everyone seems to be stumped as to why my hard drive keeps coming up with these random timouts, I guess the only way to fix it is to be able to run a -current kernel using the old wd driver files. Is this possible, or have too many things changed to make it not runnable under the new system? My system is just unusable since accessing the disk almost always brings repeated timeouts. Can someone out there that has the sources be able to give me the files I need to change the wd driver in the new kernel? Furthermore to clarify things up a bit, what files would need to be changed in order to do this, and would I need to do anything different? What I was really hoping for would be for someone who has these files to just compile me up a kernel with the old wd driver, as I cannot compile anything on my system. My system is an extraction of the binary snapshot as of July 13, so if some kind soul could just replace the needed files and compile me a kernel that would run on a July 13 system, it would be a God-blessing. If this doesn't work, then I don't know what will!! Thanks to anyone who responds to this, the help is greatly appreciated. ---> Mark Steven de Sagun Tamola ---> buckwild@u.washington.edu ---> And God said: "Let there be man...", and then I appeared... From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 09:27:07 1994 Subject: Re: 80 column console 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 > How about a smaller font that could do 80x24 or better in a non-interlaced > resolution? I am using a 6x9 font which gives me 106x47 in NTSC hires interlace. It does not support the international characters, which is why it was rejected for inclusion in the standard distribution. Neverless, I can give it to you if you want it. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.toronto.edu, finger for PGP public key finger dej@freenet.toronto.on.ca for latest Toronto Free-Net information Click me! 14:24:12 1994 Date: Sun, 24 Jul 94 14:24:11 +0200 From: Ingo Reckziegel To: Hubert.Feyrer@rrzc1.rz.uni-regensburg.de Subject: So nachmittag Status: O da du noch nicht da bist, werd ich erst mal an den see fahren. ... mit meiner schwester, die grad zu besuch ist. ich melde mich heut abend (nacht) bei dir wegen der installation, ansonsten koennen wir das Mo machen ? ein CD habe ich immer noch nicht... ingo. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 22:18:59 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: multiple X servers under pcvt? X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've tried running two X servers on separate virtual consoles under pcvt, to do some debugging. However, when I do so, I end up with a keyboard in the wrong mode when I switch between X servers (I don't recall exactly when the keyboard mode gets lost, but it's real easy to do). Has anybody else run into this, and what did you do to fix it? XFree86-2.1.1 on SVGA server, if it matters. ==John From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:28:36 1994 To: amiga@sun-lamp.cs.berkeley.edu Subject: SCSI lockups in current kernel source? From: "'Most Excellent' Eric Mehlhaff" Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've been running my own kernels compiled from this week's kernel source, and have been having my system totally seize up quite a number of times. It looks like its disk related -- one time it happened right when I unmounted an adosfs drive. This hasn't happened on me in any of the kernels I've compiled before, over the last several months. What changed in this last weeks' kernel code to cause this? Actually, I remember this having come up in the last few days -- what was it that could be binpatched to make the kernel less likely to lock up on disk accesses? For what its worth, I'm on a 10 meg A3000, with 3 drives, and a CD-rom. I've been compiling my own kernels chiefly to use multiple swap partitions. Eric From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:28:38 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu Subject: Updated boot floppies uploaded Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've just finished uploading some updated floppies to ftp.uni-regensburg.de. I hope to have some preliminary install documents (using floppies) to upload RSN. Remember, these are currently "expert friendly" (read "not well documented!" :-) -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:28:49 1994 From: "Alan Bair" "Re: Problems with adosfs & tapes" (Jul 24, 11:06am) X-Mailer: Z-Mail Lite (3.2.0 07jul94) To: amiga@sun-lamp.cs.berkeley.edu Subject: Re: Problems with adosfs & tapes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 24, 11:06am, Alan Bair wrote: > Subject: Re: Problems with adosfs & tapes > > Using the netbsd-generic kernel solved both the adosfs support and > my tape drive problems. I'll check more on my tape drive to > see if it may have been something I did. Someone else asked about > my drive, its a WangTek 5150ES, which I think is one of the originally > supported models. I found that the problem with my tape drive is the drive itself. I can write and read a tape until the drive is reset or the tape is removed and reinserted. After that the drive only detects a blank tape :( I guess its time for some maintenace or a new drive. The problem may not be permenant though, since after using the generic kernel I was able to put the kernel onto the NetBSD side using the tape drive. Oh well, since I can use adosfs, I don't need to use the tape. > > By the way, what are the erst0 and enrst0 devices for? They were in > the rootfs /dev directory. > >-- End of excerpt from Alan Bair I also did some more testing on the kernels and found the following. I booted all these with loadbsd 2.9 with options "-b -c 3000". netbsd kernel 1.0-ALPHA (GENERIC) Jul 21 This booted up to the point it printed the zthreebus0 message and then it continuosly printed the following. unexpected trap(vector offset 2) from 80000 netbsd-a3000 and netbsd-generic 0.9C (A3000) and (GENERIC) Jul 9 These booted OK. From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:29:25 1994 From: "Alan Bair" "Re: Problems with adosfs & tapes" (Jul 23, 9:23pm) X-Mailer: Z-Mail Lite (3.2.0 07jul94) To: "Stephen J. Roznowski" , abair@sol.sps.mot.com, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Problems with adosfs & tapes Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 23, 9:23pm, Stephen J. Roznowski wrote: > Subject: Re: Problems with adosfs & tapes > > From: Alan Bair > > > > I was trying to install the lastest snapshot this weekend > > and ran into several problems. I installed the rootfs with > > no problems, but booting the "netbsd" generated a contiuous > > set of error messages. I didn't get the exact text, but > > I read a posting from someone else that had the text. > > > > To get past that problem, I booted with the "netbsd-a3000" > > kernel. This boots OK, but I cannot get my tape drive or > > adosfs to work so I can install the new binaries. > > Don't know about the tapedrive, but the current A3000 kernel does > NOT have adosfs support in it. I'm planning on fixing this when > I generate the "4" different kernels as previously discussed. Using the netbsd-generic kernel solved both the adosfs support and my tape drive problems. I'll check more on my tape drive to see if it may have been something I did. Someone else asked about my drive, its a WangTek 5150ES, which I think is one of the originally supported models. By the way, what are the erst0 and enrst0 devices for? They were in the rootfs /dev directory. > > > I checked with disklabel and found the path for my ADOS > > partition with the NetBSD binaries; /dev/sd0g. Then I > > tried; mount -t ados /dev/sd0g /mnt. It fails with the > > message; ados: mount: Operation not supported on device. > > > > For the tape drive, I used l:tape-handler (dtape) to copy > > the binary tar.gz files onto the tape on the ADOS side. > > I can gzip -d | tar from the tape and read everything on > > the ADOS side. Under NetBSD, any read attempt comes back > > with a premature EOF like there was no data on the tape. > > As test, I tared some files to tape under NetBSD and > > tried to untar it under ADOS. This failed in a similar > > manner. > > > > Any hints would be appreciated, espcially on using the > > adosfs. > > -SR >-- End of excerpt from Stephen J. Roznowski From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 22:29:47 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: grass on NetBSD? From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu A while back, someone on this list mentioned that they had, or were trying to port the grass GIS system to NetBSD. Please get in touch with me if you are still on this list. I'm frustrated.... -- Randy From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:45:32 1994 From: Mike Lorant Subject: Latest snapshot problems To: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-amiga@sun-lamp.cs.berkeley.edu NetBSD Gurus, Ive just started reinstalling NetBSD from scratch using the latest kernel and binaries. Ive stumbled onto one big problem with the 07/21 kernel. When i try to load it in i get after the 2nd line after it finds the drives a message saying: unexpected trap (vector offset 2) from 10080000 this streams along for about 30 lines or so, and then everything stops. My system is a A4000/040 with 10megs of memory. No other hardware added. I know im not the only person to experience this as my friend who is also on a standard A4000/040 but with only 6 meg of memory has the same problem. The problem does not appear on the kernel dated 07/09 and that works perfectly. The problem however does occur on the -current sources as a friend tried compiling me a generic to use and it still failed. He tried also taking out the ed0 (or whatever the new driver is) support to see if that made a difference. It didnt :( Anyone know what is going on? And any possible fixes? Michael Lorant +----------------+================================+-----------------------+ |*Michael Lorant | X-Comm Development Team | Nick : Dense | | Edward Lawford | mikel@extro.ucc.su.OZ.AU | Channel : Amiga | | William Waring | http://www.usyd.edu.au/~mikel/ | : Aussies | +----------------+================================+-----------------------+ From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 22:46:34 1994 From: Hubert Feyrer Subject: netbsd-almostgeneric.940721.gz 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: 601 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've put a kernel with the sources from 0721 and a sys/isofs from 0722 and WITHOUT the Hydra-ethernet-support into /pub/NetBSD-Amiga/kernel on ftp.uni-regensburg.de. Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 24 23:09:14 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Largest tape blocksize on st From: Bakul Shah Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have some DATs with 512K byte blocks that I can't seem to read with the st driver. Read/write of 64K blocks works fine. Is this a limitation of the driver/firmware/controller or am I forgetting some magic incantations? Many thanks for any help! Bakul Shah From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 24 23:29:53 1994 From: "Stephen J. Roznowski" To: amiga@sun-lamp.cs.berkeley.edu, mikel@extro.ucc.su.OZ.AU Subject: Re: Latest snapshot problems Sender: owner-amiga@sun-lamp.cs.berkeley.edu > From: Mike Lorant > > Ive just started reinstalling NetBSD from scratch using the latest kernel > and binaries. Ive stumbled onto one big problem with the 07/21 kernel. > When i try to load it in i get after the 2nd line after it finds the > drives a message saying: > > unexpected trap (vector offset 2) from 10080000 > > this streams along for about 30 lines or so, and then everything stops. > My system is a A4000/040 with 10megs of memory. No other hardware added. > I know im not the only person to experience this as my friend who is also > on a standard A4000/040 but with only 6 meg of memory has the same problem. > > The problem does not appear on the kernel dated 07/09 and that works > perfectly. The problem however does occur on the -current sources as a > friend tried compiling me a generic to use and it still failed. > > He tried also taking out the ed0 (or whatever the new driver is) support > to see if that made a difference. It didnt :( Anyone know what is going > on? And any possible fixes? That's strange... I just commented out this line and now the GENERIC kernel works for me. If you are *really* desperate, you might try using the floppies that I just uploaded to ftp.uni-regensburg.de (or make a floppy from file "1" and try booting using that GENERIC kernel.) -SR From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 00:18:36 1994 From: John Kohl To: current-users@sun-lamp.cs.berkeley.edu Subject: disklabel vs. floppy drives X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Since -current now makes the partition number of a floppy significant for selecting density, I can't write a disklabel to the disk anymore, since fd0d is not the right density :( Any suggestions for a clean fix other than a custom hacked disklabel (which I have done)? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 00:28:25 1994 From: mycroft@gnu.ai.mit.edu To: bakul@netcom.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Largest tape blocksize on st Sender: owner-current-users@sun-lamp.cs.berkeley.edu Many of the `smart' PC SCSI controllers cannot DMA more than 64k at a time. From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 00:34:40 1994 Subject: WD7000-FASST anyone? 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: 381 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Anyone out there got a WD7000-FASST SCSI controller ? Please drop me a note if you can help debug/test a driver for it... Martin -- UNIX - An operationg system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 00:52:41 1994 Subject: From: aod@beretta.ramp.com To: current-users@sun-lamp.cs.berkeley.edu Content-Length: 1231 Content-Type: text Sender: owner-current-users@sun-lamp.cs.berkeley.edu Once again I must make a plea for help to this mailing list, considering my last one was all but ignored. I cannot get my com ports to work with ANY current utilities. cu gives me the cu: write input/output error if i try to use that.. I KNOW the kludge about sleep 4000 Sender: owner-current-users@sun-lamp.cs.berkeley.edu aod@beretta.ramp.com writes: > I cannot get my com ports to work with ANY current utilities. > > cu gives me the cu: write input/output error if i try to use that.. > I KNOW the kludge about sleep 4000 supposed to NORMALLY interface the com ports with this program?? Ordinarily, when the com port is opened, it blocks until the DCD line is high on the serial port. This is intended for dial-in use, so a getty isn't spawned until a call comes in, and so the connection is closed if the carrier is lost. To use the port for dial-out use, add the "softcar" flag to the appropriate line in /etc/ttys (see the tty(5) man page). For example: tty00 "/usr/libexec/getty std.9600" unknown off softcar That makes the driver pretend that DCD is always high. > #2 > Getty is completly useless. It ignores everything the modem does, sends > absolutely nothing TO the modem, accepts no input FROM the modem, and general > ly > just sits there like a lump. Iv'e tried my old gettytab configs which used > to work, the new ones supplied with the bins, and spent OVER 12 hours hacking > at various things to get it to do SOMETHING.. If dial-in isn't working, then the DCD line is probably not going high. Maybe your modem is not configured correctly, or your cable doesn't have the DCD line connected. > would someone PLEASE explain to me HOW to set this thing up. This makes > no sense to me, considering it all worked just peachy before you "fixed" it. Before, the driver essentially ALWAYS had "softcar" on. This worked well for dial-out, and sort-of worked for dial-in, although if a dialed-in user lost carrier, the connection would not be terminated and the next caller would be wherever the first person left off. Major security hole. 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 Jul 25 07:25:18 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: banshee@gabriella.resort.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: top machine.c for NetBSD Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've ported the 4.4 machine.c for top-3.2 to NetBSD. machine.c can be ftped from resort.com://pub/machine.c The rest of top can be grabbed from iastate or any ports mirror site. And now the perms are even correct .... I should stop drinking and driving on the super highway. -john From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 25 10:25:15 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: tty00, modems, and hell - what they have in common. Sender: owner-amiga@sun-lamp.cs.berkeley.edu Is _ANYONE_ using this for dial-in? If so, tell me what I'm doing wrong... My understanding is that tty00 will not fire up getty until a "CONNECT" is seen from the modem.. I have &c1 (follow carrier detect), and &D2 (disconnect and enter command state if DTR is pulled) on the modem. I have tty00 on in the ttys files, and set for std.57600, which should be fine. So what happens is that the modem and computer get in a loop talking/listening. When DTR is active, the modem prints OK, this causes the computer to print out the banner, which the modem faithfully echos back, which the computer takes as input for the login name... and so on.. and so on.. So I thought I would be smart and put the modem in "dumb" mode, but then for some reason, the computer isn't detecting CD, and a person can lose a connecting in the middle of doing something, and the next person logins where the first left off... this is unacceptable. So, PLEASE, tell me what I'm configuring wrong, because I can't believe the serial device driver could have gone over a year without someone noticing this. Thanks! -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 12:20:13 1994 From: J Wunsch Subject: Re: multiple X servers under pcvt? To: XFree86-beta@xfree86.org Cc: current-users@sun-lamp.cs.berkeley.edu X-Phone: +49-351-5965 137 X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1020 Sender: owner-current-users@sun-lamp.cs.berkeley.edu As John Kohl wrote: | | I've tried running two X servers on separate virtual consoles under | pcvt, to do some debugging. However, when I do so, I end up with a | keyboard in the wrong mode when I switch between X servers (I don't | recall exactly when the keyboard mode gets lost, but it's real easy to | do). (Hellmuth Michaelis has also forwarded me this.) I never had problems with running multiple servers under pcvt. This is with FreeBSD ~ 1.1. Last time i did this in order to answer David W's ``Please do a test for me'' request, and i've extensively tested the XFree86 2.1.1 versus 3.0C servers, running them on two different vty's and comparing the results of `xgc'. Can you gimme a hint on how to reproduce the phenomenon? -- cheers, J"org work: joerg_wunsch@tcd-dresden.de private: joerg_wunsch@uriah.sax.de Steinbach's Guideline for Systems Programming: Never test for an error condition you don't know how to handle. From owner-amiga@sun-lamp.cs.berkeley.edu Mon Jul 25 13:11:43 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: SOLVED Re: tty00, modems, and hell - what they have in common. Sender: owner-amiga@sun-lamp.cs.berkeley.edu Whom would have ever thought that I'm supposed to use ttym0? -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 20:32:35 1994 From: Duncan McEwan To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) <9407152312.AA08887@alpha.bostic.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu A week or so ago I asked about the need for both the COM_SW_SOFTCAR and COM_SW_CLOCAL flags in the com driver, since they both seemed to accomplish the same thing, particularly if what I considered to be a bug relating to the COM_SW_SOFTCAR handling of DTR got fixed. cgd replied: > 'clocal' and 'softcar' are supposed to be used by different things. > > the former is when you want the line to "default" to seeming like > carrier is detected, but want it to be able to be disabled. > ... > softcar is supposed to be used _only_ for hardwired terminals > that don't provide DCD themselves. I still think it's a bug that setting COM_SW_SOFTCAR via ttyflags leaves DTR on all the time. But if it's only used with hardwired terminals, I guess it doesn't hurt. It does mean that the correct response to something like ... |> From: Tim Chase |> Subject: The pppd blocking thing... softcar works. |> Date: Wed, 13 Jul 1994 11:29:34 -0500 (CDT) |> |> ... |> |> setting the softcar flag from /etc/ttys works just fine and is obviously the |> proper solution to using pppd, tip or whatever for outgoing calls (if the |> program in question doesn't use a nonblocking open). ... should be: "Use softcar when your tty line is not connected to a modem. Otherwise use the "local" flag, which sets the CLOCAL bit if you want DTR to work correctly with your modem." Unfortunately people who use "cu" rather than "tip" won't like this advice since it doesn't work :-) If you do a "cu -l /dev/tty01" where tty01 has had the COM_SW_CLOCAL bit set by ttyflags, the open succeeds. But when you try to type anything you get cu: write: input/output error I've looked at the "cu" code, but it's a little hard to figure out what is going on. I think the sequence of opening the tty ends up with fsserial_open in libunix/serial.c being called with the fwait parameter set to false. This causes "cu" to open the line in non-blocking mode (not strictly needed here since CLOCAL is on), but it then turns CLOCAL off a little further on in the routine. Presumably the error occurs because the bsd tty driver won't let you write to a device that has no carrier if neither SOFTCAR or CLOCAL are switched on. This seems to be sensible behaviour. I'm not sure how "cu" works on other systems. Do they only care about the presence or absence of carrier at the time the port is opened? Duncan From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 21:36:50 1994 Subject: Q's on 4.4-lite userland integration 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: 1110 Sender: owner-current-users@sun-lamp.cs.berkeley.edu After spending the better part of the last hour reading flames on why bsd vs bsd vs linux (pick a combo), and having a chuckle here and there, I thought about a recurring point. Does netbsd-current use lots of net/2.untainted code in userland? If so, are there any plans to integrate 4.4-lite userland stuff, especially stuff that hasn't had netbsd-local changes? If yes, can we get an approximate timeframe? The reason why I'm interested is because I was going to (in my Infinite Spare Time :) compile a lot of the userland tree with -Wall or whatever, as well as with ld warnings for some non-ansi functions (bcopy, rindex), so I could make the code more portable. Not much use doing this on net/2 derived stuff if it's gunna be replaced by 4.4-lite stuff (which I have the source to locally as well.) Luke. & maintainer of Australasian netbsd-current sup & ftp archives & -- ``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-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 25 21:44:19 1994 From: Hubert Feyrer Subject: undefines symbols in minimal-kernel 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: 7774 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu When trying to build a minimal kernel for a A2091-equipped A2k, I got the following linker errors: init_sysent.o: Undefined symbol _nfssvc referenced from data segment init_sysent.o: Undefined symbol _getfh referenced from data segment kern_acct.o: Undefined symbol _lease_check referenced from text segment kern_sig.o: Undefined symbol _lease_check referenced from text segment kern_time.o: Undefined symbol _lease_updatetime referenced from text segment uipc_usrreq.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: Undefined symbol _lease_check referenced from text segment vfs_syscalls.o: More undefined symbol _lease_check refs follow sbic.o: Undefined symbol _DCFL referenced from text segment sbic.o: Undefined symbol _DCFL referenced from text segment Occurently, NFSSERVER needs to be defined, don't know about the other symbols. Here's are the changes that I did to the GENERIC-file: *** DOOM Sun Jul 24 19:44:02 1994 --- GENERIC Mon Jul 18 10:49:17 1994 *************** *** 8,23 **** include "std.amiga" ! maxusers 2 options TIMEZONE=300, DST=1 # # processors this kernel should support # ! #options "M68040" # support for 040 ! #options FPSP # MC68040 floating point support options "M68030" # support for 030 ! #options "M68020" # support for 020/851 options FPCOPROC # Support for MC6888[12] (Required) options SWAPPAGER # Pager for processes (Required) --- 8,23 ---- include "std.amiga" ! maxusers 8 options TIMEZONE=300, DST=1 # # processors this kernel should support # ! options "M68040" # support for 040 ! options FPSP # MC68040 floating point support options "M68030" # support for 030 ! options "M68020" # support for 020/851 options FPCOPROC # Support for MC6888[12] (Required) options SWAPPAGER # Pager for processes (Required) *************** *** 33,48 **** #options CCITT # CCITT X.25 #options NS # Xerox XNS #options EON # ISO CLNL over IP ! options GATEWAY # Packet forwarding #options DIRECTED_BROADCAST # Broadcast across subnets #options NSIP # XNS over IP # # File system related options # ! #options QUOTA # Disk quotas for local disks ! #options NFSSERVER # Network File System server side code ! #options NFSCLIENT # Network File System client side code # # File systems --- 33,48 ---- #options CCITT # CCITT X.25 #options NS # Xerox XNS #options EON # ISO CLNL over IP ! #options GATEWAY # Packet forwarding #options DIRECTED_BROADCAST # Broadcast across subnets #options NSIP # XNS over IP # # File system related options # ! options QUOTA # Disk quotas for local disks ! options NFSSERVER # Network File System server side code ! options NFSCLIENT # Network File System client side code # # File systems *************** *** 63,73 **** # # Compatability options for various existing systems # ! #options "COMPAT_09" # compatability with older NetBSD release ! #options "COMPAT_43" # 4.3 BSD compatible system calls ! #options COMPAT_SUNOS # Support to run Sun (m68k) executables ! #options "TCP_COMPAT_42" # Use 4.2 BSD style TCP ! #options "COMPAT_NOMID" # allow nonvalid machine id executables #options COMPAT_HPUX # HP300 compatability # --- 63,73 ---- # # Compatability options for various existing systems # ! options "COMPAT_09" # compatability with older NetBSD release ! options "COMPAT_43" # 4.3 BSD compatible system calls ! options COMPAT_SUNOS # Support to run Sun (m68k) executables ! options "TCP_COMPAT_42" # Use 4.2 BSD style TCP ! options "COMPAT_NOMID" # allow nonvalid machine id executables #options COMPAT_HPUX # HP300 compatability # *************** *** 100,106 **** # # Amiga specific options # ! #options RETINACONSOLE # enable code to allow retina to be console options GRF_ECS # Enhanced Chip Set options GRF_NTSC # NTSC options GRF_PAL # PAL --- 100,106 ---- # # Amiga specific options # ! options RETINACONSOLE # enable code to allow retina to be console options GRF_ECS # Enhanced Chip Set options GRF_NTSC # NTSC options GRF_PAL # PAL *************** *** 109,153 **** #options "KFONT_8X11" # 8x11 font grfcc0 at mainbus0 # custom chips ! #grfrt0 at ztwobus0 # retina II ! #grfrh0 at zthreebus0 # retina III grf0 at grfcc0 ! #grf1 at grfrt0 ! #grf2 at grfrh0 ite0 at grf0 # terminal emulators for grf's ! #ite1 at grf1 # terminal emulators for grf's ! #ite2 at grf2 # terminal emulators for grf's ! #le0 at ztwobus0 # Lance ethernet. ! #ed0 at ztwobus0 # dp8390 ethernet # scsi stuff, all possible ! #gvpbus0 at ztwobus0 ! #gtsc0 at gvpbus0 # GVP series II scsi ! #ahsc0 at mainbus0 # A3000 scsi atzsc0 at ztwobus0 ! #wstsc0 at ztwobus0 # Wordsync II scsi ! #ivsc0 at ztwobus0 # IVS scsi ! #mlhsc0 at ztwobus0 # Hacker scsi ! #otgsc0 at ztwobus0 # 12 gauge scsi ! #zssc0 at ztwobus0 # Zeus scsi ! #mgnsc0 at ztwobus0 # Magnum scsi ! #wesc0 at zthreebus0 # Warp Engine scsi ! #idesc0 at mainbus0 # A4000(A1200?) IDE ! #scsibus0 at gtsc0 ! #scsibus1 at ahsc0 scsibus2 at atzsc0 ! #scsibus2 at wstsc0 ! #scsibus3 at ivsc0 ! #scsibus4 at mlhsc0 ! #scsibus5 at otgsc0 ! #scsibus6 at zssc0 ! #scsibus7 at mgnsc0 ! #scsibus8 at wesc0 ! #scsibus9 at idesc0 # # compat. --- 109,153 ---- #options "KFONT_8X11" # 8x11 font grfcc0 at mainbus0 # custom chips ! grfrt0 at ztwobus0 # retina II ! grfrh0 at zthreebus0 # retina III grf0 at grfcc0 ! grf1 at grfrt0 ! grf2 at grfrh0 ite0 at grf0 # terminal emulators for grf's ! ite1 at grf1 # terminal emulators for grf's ! ite2 at grf2 # terminal emulators for grf's ! le0 at ztwobus0 # Lance ethernet. ! ed0 at ztwobus0 # dp8390 ethernet # scsi stuff, all possible ! gvpbus0 at ztwobus0 ! gtsc0 at gvpbus0 # GVP series II scsi ! ahsc0 at mainbus0 # A3000 scsi atzsc0 at ztwobus0 ! wstsc0 at ztwobus0 # Wordsync II scsi ! ivsc0 at ztwobus0 # IVS scsi ! mlhsc0 at ztwobus0 # Hacker scsi ! otgsc0 at ztwobus0 # 12 gauge scsi ! zssc0 at ztwobus0 # Zeus scsi ! mgnsc0 at ztwobus0 # Magnum scsi ! wesc0 at zthreebus0 # Warp Engine scsi ! idesc0 at mainbus0 # A4000(A1200?) IDE ! scsibus0 at gtsc0 ! scsibus1 at ahsc0 scsibus2 at atzsc0 ! scsibus2 at wstsc0 ! scsibus3 at ivsc0 ! scsibus4 at mlhsc0 ! scsibus5 at otgsc0 ! scsibus6 at zssc0 ! scsibus7 at mgnsc0 ! scsibus8 at wesc0 ! scsibus9 at idesc0 # # compat. *************** *** 173,179 **** pseudo-device sl # slip pseudo-device ppp # ppp ! pseudo-device view 5 # views pseudo-device pty 16 # pseudo terminals pseudo-device loop # network loopback --- 173,179 ---- pseudo-device sl # slip pseudo-device ppp # ppp ! pseudo-device view 10 # views pseudo-device pty 16 # pseudo terminals pseudo-device loop # network loopback Can anyone resolve this? :-> Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-dev@sun-lamp.cs.berkeley.edu Mon Jul 25 21:51:06 1994 From: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: ADOSFS To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 948 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Hello! After a long period of leaving NetBSD alone, I updated last weekend to the 090794 distribution. Nice piece of work! Just one little bug that I have encountered: if you try to mount an ADos partition which has been set to something else but 512 bytes per block, the filesystem will not be visible. So, the setting in the RDB for that partition (not the RDSK but the PART) has to be looked at. I didn't have the time yet to look into the sources but I hope this is not too hard to achieve. If I get my own kernel compiled, I may have a look at it on my own. One more! :-) Why does df say that there are only two blocks on the ADos-partition? Bye, \|/ Tobias @ @ +-------------------oOO-(_)-OOo---------------+ | Tobias Abt | | email: zcjc1121@rpool1.rus.uni-stuttgart.de | | irc: tabt@#AmigaGer | +---------------------------------------------+ From owner-netbsd-users@sun-lamp.cs.berkeley.edu Mon Jul 25 22:59:21 1994 From: klee@rdcclink.rd.qms.com To: netbsd-users@sun-lamp.cs.berkeley.edu Subject: NetBSD 1.0 ??? Where? Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu Hi! This morning, I have read somebody's broadcast on emacs for NetBSD 1.0. I, then, figured that NetBSD 1.0 is out. When I looked at comp.os.386bsd.announcement, I did not see any announce about NetBSD 1.0. I could not ftp to sun-lamp.cs.berkeley.edu, so I ftp-ed to ftp.iastate.edu, but they did not have it. Where is this NetBSD 1.0? or is it out yet? Thanks Kang From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 23:00:23 1994 From: Scott Reynolds Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) To: Duncan McEwan Cc: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Mon, 25 Jul 1994, Duncan McEwan wrote: > I'm not sure how "cu" works on other systems. While I can't answer the questions posed, I think it's worthwhile to note that this is a (hacked?) version of Taylor UUCP 1.04, and that someone who has time might want to check to see if any of the myriad configuration and/or policy options might be used to solve this problem. I've noticed that cu doesn't work quite that way I'd like, too, but I "solved" that problem with C-Kermit 189 (see /usr/othersrc/README). --scott From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 23:00:28 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Why build libc_sa and libnetboot ? X-Mailer: exmh version 1.3 4/7/94 From: John Brezak Sender: owner-current-users@sun-lamp.cs.berkeley.edu Why is sys/lib/{libnetboot,libc_sa} built with the toplevel make ? It seems that most boot progs will use the associated Makefile.inc to build what it needs anyway. The same for kernels with libkern. Also who uses libnetboot and libc_sa now ? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5122 From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 23:10:01 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: 4.4BSD contrib Sender: owner-current-users@sun-lamp.cs.berkeley.edu could someone give me a list of what is in the 4.4BSD-Lite /usr/src/contrib directory (i think thats the path) just curious -bri From owner-current-users@sun-lamp.cs.berkeley.edu Mon Jul 25 23:44:53 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: bdc@ai.mit.edu (Brian D. Carlstrom) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: 4.4BSD contrib <9407251921.AA12039@blackjack> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu Per your request. A lot of this is archaic, and incomplete. total 116 -r--r--r-- 1 bin 9 305 Apr 18 16:19 Makefile -r--r--r-- 1 bin 9 98 Jun 9 1993 Makefile.inc lrwxrwxr-x 1 bin 9 14 Apr 20 16:28 X11R5@ -> ../local/X11R5 -r--r--r-- 1 bin 9 565 Jun 13 1993 X11R5-README drwxrwxr-x 3 bin 9 512 Jun 8 1993 X11R5-hp300/ drwxrwxr-x 5 bin 9 512 Jun 13 1993 X11R5-lib/ drwxrwxr-x 3 bin 9 512 Jun 9 1993 X11R5-luna68k/ drwxrwxr-x 2 bin 9 512 Apr 4 12:18 ansi/ drwxrwxr-x 2 bin 9 512 Jan 4 1994 awk.research/ drwxrwxr-x 6 bin 9 512 Jun 7 1993 bib/ drwxrwxr-x 9 bin 9 512 Feb 17 12:55 bind-4.9.2/ drwxrwxr-x 4 bin 9 1536 Apr 4 12:28 calc-2.9.3t6/ drwxrwxr-x 9 bin 9 512 Feb 10 1993 connectd/ drwxrwxr-x 10 bin 9 512 Apr 4 1990 dipress/ drwxrwxr-x 2 bin 9 512 May 17 1993 diskless.nfs/ drwxrwxr-x 2 bin 9 1536 Jun 26 1990 dungeon/ drwxrwxr-x 2 bin 9 1024 Jun 11 1993 ed/ drwxrwxr-x 10 bin 9 512 May 26 1993 emacs-18.57/ drwxrwxr-x 3 bin 9 512 Nov 6 1993 file-3.12/ drwxrwxr-x 3 bin 9 1024 Apr 19 11:59 flex-2.4.6/ drwxrwxr-x 4 bin 9 1024 Apr 19 09:35 gas-1.38/ drwxrwxr-x 2 bin 9 512 May 29 1993 gated/ drwxrwxr-x 9 bin 9 1536 Apr 19 09:36 gawk-2.15.2/ drwxrwxr-x 4 bin 9 6144 Apr 4 12:18 gcc-2.3.3/ drwxrwxr-x 12 bin 9 512 Apr 4 15:20 gdb-4.7.LBL/ drwxrwxr-x 39 bin 9 1536 Feb 19 10:39 groff-1.08/ drwxrwxr-x 10 bin 9 1536 Apr 4 12:20 gzip-1.2.4/ drwxrwxr-x 2 bin 9 512 Apr 4 12:20 hunt/ drwxrwxr-x 4 bin 9 2048 Apr 4 12:20 jove-4.14.6/ drwxrwxr-x 2 bin 9 1024 Apr 4 12:20 kermit-5A.188/ drwxrwxr-x 7 bin 9 512 Apr 4 12:20 libg++-2.3/ drwxrwxr-x 14 bin 9 512 Apr 18 14:21 mh-6.8.3a/ drwxrwxr-x 6 bin 9 512 May 31 1993 mkmf/ drwxrwxr-x 2 bin 9 512 May 20 1993 mprof/ drwxrwxr-x 5 bin 9 512 Jun 7 1993 news/ drwxrwxr-x 10 bin 9 1024 Apr 22 09:47 nvi.1.14/ drwxrwxr-x 14 bin 9 2048 Apr 4 12:21 perl-4.036/ drwxrwxr-x 3 bin 9 1024 May 3 1993 rc-1.4/ drwxrwxr-x 5 bin 9 512 Aug 14 1993 rcs-V5.6/ -r--r--r-- 1 bin 9 849 Jun 14 1993 rdist.README drwxrwxr-x 2 bin 9 512 Jun 1 1993 sc/ drwxrwxr-x 3 bin 9 512 Jun 10 1993 sort/ drwxrwxr-x 7 bin 9 512 Apr 4 13:20 sun.sharedlib/ drwxrwxr-x 10 bin 9 512 May 28 1993 usr.x25/ drwxrwxr-x 2 bin 9 512 Jun 1 1993 vmsprep/ drwxrwxr-x 15 bin 9 512 May 25 1993 xns/ From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 00:12:34 1994 From: Peter Galbavy Subject: libsa/saerrno.h To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 442 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is it my problem, or do the errno values in sys/errno.h and libsa/saerrno.h have lots of conflicting values/defn ? I am trying to build the new SPARC boot blocks and libsa is not happening for me. libsa/strerror.c is breaking. Help, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 00:20:35 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: Clipper news Sender: owner-current-users@sun-lamp.cs.berkeley.edu Although this isn't NetBSD related, I thought many people here would be interested. This is a news flash only, please don't discuss this here. Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From: mech@eff.org (Stanton McCandlish) Newsgroups: alt.2600,alt.activism,alt.activism.d,alt.politics.datahighway,alt.politics.org.nsa,alt.privacy,alt.privacy.clipper,alt.security.pgp,alt.society.resistance,alt.wired,comp.org.cpsr.talk,comp.org.eff.news,comp.org.eff.talk,misc.legal,sci.crypt,talk.politics.crypto Subject: White House retreats on Clipper Date: 21 Jul 1994 13:04:03 -0500 Organization: UTexas Mail-to-News Gateway Distribution: inet NNTP-Posting-Host: news.cs.utexas.edu Yesterday, the Clinton Administration announced that it is taking several large, quick steps back in its efforts to push EES or Clipper encryption technology. Vice-President Gore stated in a letter to Rep. Maria Cantwell, whose encryption export legislation is today being debated on the House floor, that EES is being limited to voice communications only. The EES (Escrowed Encryption Standard using the Skipjack algorithm, and including the Clipper and Capstone microchips) is a Federal Information Processing Standard (FIPS) designed by the National Security Agency, and approved, despite a stunningly high percentage anti-EES public comments on the proposal) by the National Institute of Standards and Technology. Since the very day of the announcement of Clipper in 1993, public outcry against the key "escrow" system has been strong, unwavering and growing rapidly. What's changed? The most immediate alteration in the White House's previously hardline path is an expressed willingness to abandon the EES for computer applications (the Capstone chip and Tessera card), and push for its deployment only in telephone technology (Clipper). The most immediate effect this will have is a reduction in the threat to the encryption software market that Skipjack/EES plans posed. Additionally, Gore's letter indicates that deployment for even the telephone application of Clipper has been put off for months of studies, perhaps partly in response to a draft bill from Sens. Patrick Leahy and Ernest Hollings that would block appropriation for EES development until many detailed conditions had been met. And according to observers such as Brock Meeks (Cyberwire Dispatch) and Mark Voorhees (Voorhees Reports/Information Law Alert), even Clipper is headed for a fall, due to a variety of factors including failure in attempts to get other countries to adopt the scheme, at least one state bill banning use of EES for medical records, loss of NSA credibility after a flaw in the "escrowed" key system was discovered by Dr. Matt Blaze of Bell Labs, a patent infringement lawsuit threat (dealt with by buying off the claimant), condemnation of the scheme by a former Canadian Defense Minister, world wide opposition to Clipper and the presumptions behind it, skeptical back-to-back House and Senate hearings on the details of the Administration's plan, and pointed questions from lawmakers regarding monopolism and accountability. One of the most signigicant concessions in the letter is that upcoming encryption standards will be "voluntary," unclassified, and exportable, according to Gore, who also says there will be no moves to tighten export controls. Though Gore hints at private, rather than governmental, key "escrow," the Administration does still maintain that key "escrow" is an important part of its future cryptography policy. EFF would like to extend thanks to all who've participated in our online campaigns to sink Clipper. This retreat on the part of the Executive Branch is due not just to discussions with Congresspersons, or letters from industry leaders, but in large measure to the overwhelming response from users of computer-mediated communication - members of virtual communities who stand a lot to gain or lose by the outcome of the interrelated cryptography debates. Your participation and activism has played a key role, if not the key role, in the outcome thus far, and will be vitally important to the end game! Below is the public letter sent from VP Gore to Rep. Cantwell. ****** July 20, 1994 The Honorable Maria Cantwell House of Representatives Washington, D.C., 20515 Dear Representative Cantwell: I write to express my sincere appreciation for your efforts to move the national debate forward on the issue of information security and export controls. I share your strong conviction for the need to develop a comprehensive policy regarding encryption, incorporating an export policy that does not disadvantage American software companies in world markets while preserving our law enforcement and national security goals. As you know, the Administration disagrees with you on the extent to which existing controls are harming U.S. industry in the short run and the extent to which their immediate relaxation would affect national security. For that reason we have supported a five-month Presidential study. In conducting this study, I want to assure you that the Administration will use the best available resources of the federal government. This will include the active participation of the National Economic Council and the Department of Commerce. In addition, consistent with the Senate-passed language, the first study will be completed within 150 days of passage of the Export Administration Act reauthorization bill, with the second study to be completed within one year after the completion of the first. I want to personally assure you that we will reassess our existing export controls based on the results of these studies. Moreover, all programs with encryption that can be exported today will continue to be exportable. On the other hand, we agree that we need to take action this year to assure that over time American companies are able to include information security features in their programs in order to maintain their admirable international competitiveness. We can achieve this by entering into an new phase of cooperation among government, industry representatives and privacy advocates with a goal of trying to develop a key escrow encryption system that will provide strong encryption, be acceptable to computer users worldwide, and address our national needs as well. Key escrow encryption offers a very effective way to accomplish our national goals, That is why the Administration adopted key escrow encryption in the "Clipper Chip" to provide very secure encryption for telephone communications while preserving the ability for law enforcement and national security. But the Clipper Chip is an approved federal standard for telephone communications and not for computer networks and video networks. For that reason, we are working with industry to investigate other technologies for those applications. The Administration understands the concerns that industry has regarding the Clipper Chip. We welcome the opportunity to work with industry to design a more versatile, less expensive system. Such a key escrow system would be implementable in software, firmware, hardware, or any combination thereof, would not rely upon a classified algorithm, would be voluntary, and would be exportable. While there are many severe challenges to developing such a system, we are committed to a diligent effort with industry and academia to create such a system. We welcome your offer to assist us in furthering this effort. We also want to assure users of key escrow encryption products that they will not be subject to unauthorized electronic surveillance. As we have done with the Clipper Chip, future key escrow systems must contain safeguards to provide for key disclosure only under legal authorization and should have audit procedures to ensure the integrity of the system. Escrow holders should be strictly liable for releasing keys without legal authorization. We also recognize that a new key escrow encryption system must permit the use of private-sector key escrow agents as one option. It is also possible that as key escrow encryption technology spreads, companies may established layered escrowing services for their own products. Having a number of escrow agents would give individuals and businesses more choices and flexibility in meeting their needs for secure communications. I assure you the President and I are acutely aware of the need to balance economic an privacy needs with law enforcement and national security. This is not an easy task, but I think that our approach offers the best opportunity to strike an appropriate balance. I am looking forward to working with you and others who share our interest in developing a comprehensive national policy on encryption. I am convinced that our cooperative endeavors will open new creative solutions to this critical problem. Sincerely, Al Gore AG/gcs ****** -- Stanton McCandlish * mech@eff.org * Electronic Frontier Found. OnlineActivist F O R M O R E I N F O, E - M A I L T O: I N F O @ E F F . O R G O P E N P L A T F O R M O N L I N E R I G H T S V I R T U A L C U L T U R E C R Y P T O From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 01:00:44 1994 To: current-users@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.current-users From: tsarna@endicor.com (Ty Sarna) Subject: Re: Q's on 4.4-lite userland integration Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article <199407251228.WAA16595@goanna.cs.rmit.oz.au> Luke Mewburn writes: > Does netbsd-current use lots of net/2.untainted code in userland? > If so, are there any plans to integrate 4.4-lite userland stuff, > especially stuff that hasn't had netbsd-local changes? > If yes, can we get an approximate timeframe? I assume if this was going to be in 1.0 it would have happened long ago so I guess it'll be in 1.1/2.0/whatever. Speaking of which, since we're getting close to 1.0, what are the goals for the next release (1.1 or 2.0 or whatever) in terms of new features, ports, etc? This was probably discussed at the NetBSD BOF, but for those of us who couldn't make it and didn't see the report on the BOF (was it ever posted?), it'd be nice to have a list of things we can look forward to/work towards. :-) And, on an unrelated question, what's wrong with lamp? It seems to be down more often than not lately. Is it down for testing, or hardware problems/upgrades or something? Please say it isn't crashing :-( -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 01:15:31 1994 From: "Steve M. Acheson" "4.4BSD contrib" (Jul 25, 3:21pm) X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: bdc@ai.mit.edu (Brian D. Carlstrom), current-users@sun-lamp.cs.berkeley.edu Subject: Re: 4.4BSD contrib Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Here's the listing hot off of my CDROM... nothing 128> ls usr/src/contrib Makefile bind-4.9.2/ gas-1.38/ libg++-2.3/ sc/ Makefile.inc calc-2.9.3t6/ gated/ mh-6.8.3a/ sort/ X11R5@ connectd/ gawk-2.15.2/ mkmf/ sun.sharedlib/ X11R5-README dipress/ gcc-2.3.3/ mprof/ usr.x25/ X11R5-hp300/ diskless.nfs/ gdb-4.7.LBL/ news/ vmsprep/ X11R5-lib/ dungeon/ groff-1.08/ nvi.1.14/ xns/ X11R5-luna68k/ ed/ gzip-1.2.4/ perl-4.036/ ansi/ emacs-18.57/ hunt/ rc-1.4/ awk.research/ file-3.12/ jove-4.14.6/ rcs-V5.6/ bib/ flex-2.4.6/ kermit-5A.188/ rdist.README Steve -- ====================================================== Steve Acheson (415) 604-6555 Sterling Software sma@nas.nasa.gov NASA Ames Moffett Field, Ca 94035-1000 From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 02:24:48 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: summer bof slides/notes From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu are ftpable from sun-lamp (and tomorrow from it's mirror sites) pub/NetBSD/misc/usenix-94summer don't take them too literally. They became severely outdated within hours... later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 02:29:05 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <9407252252.AA01834@ponderous.cc.iastate.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu re: bof actually it was written up, but relatively late, and then the edits were late, etc. i'll put the stuff in lamp:pub/NetBSD/misc next to the older slides. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 02:31:56 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu tsarna@endicor.com (Ty Sarna) writes: >Speaking of which, since we're getting close to 1.0, what are the goals >for the next release (1.1 or 2.0 or whatever) in terms of new features, >ports, etc? Out of curiosity, is it going to be another year and a half before the next release? :-) It has been kind of a pain the last few months, telling people how great NetBSD has become, but when they ask how to install the good stuff, having to give them complicated, and ever- more-impossible to achieve, destructions on how to get upgraded to current. I really want to be able to point my friends and associates at a stable release as great as 1.0, and being able to let them just go at it. So, I guess what I'm saying is, can we make the next major release a little less ambitious, and, say, not more than six months from the previous release (1.0)? I'm not asking you to lower your sites -- simply to take the leaps in small increments. I think it would really help make it usable for the people who can't quit grasp upgrading to current, especially in the later stages. This has really been my only beef with the NetBSD development, thus far. That said, please understand, overall, I think NetBSD-1.0 is the best small-system unix available, bar none. You guys have done one helluva job! Thanks for all your dedication. >This was probably discussed at the NetBSD BOF, but for those >of us who couldn't make it and didn't see the report on the BOF (was it >ever posted?), it'd be nice to have a list of things we can look forward >to/work towards. :-) Yes, we've heard about all these people who went to see the eleet BOF, but nobody posted a detailed summary!! Inquiring minds still want to know! Would someone please be so kind as to take a couple hours and sit down and write us up a report of the event? We'd all appreciate it, I'm sure. :-) --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-dev@sun-lamp.cs.berkeley.edu Tue Jul 26 02:40:13 1994 From: pepersb@cuug.ab.ca (Brad Pepers) Subject: Problems still existing... To: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1534 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I've been using the latest NetBSD and it looks great! There are still some really old problems though that are still around. The first is the modem locking up. This happens when the computer is sent a control-S from the remote system without a control-Q. If you try to close the serial device, it hangs. From what I understand you can hook up a terminal to the modem line and type control-Q and it will be fixed but I don't have a terminal. The line is locked up so I have to reboot to use it again. As it happens, when I disconnect from a lot of systems I get spurious junk and it very often contains control-S (I'm just lucky I guess!). The other problem is still to do with the vt100/200/??? emulation on the console. I think it still screws up drawing on the last lines on the screen. I see this when in emacs and editing at the last lines on the screen. I'm almost positive I've seen this in the latest load - I'm so used to it I don't even notice it anymore... Can anyone confirm that it is still around? Thats it for my known problems. Pretty good if you ask me! +----------------------------Ren & Stimpy--------------------------------+ | "Psst. Hey Guido. It's all so clear to me now. I'm the keeper of the | | cheese. And you're the lemon merchant. Get it? And he knows it. That's | | why he's gonna kill us. So we gotta beat it. Yeah. Before he lets | | loose the marmosets on us! Don't worry, little missy! I'll save you!" | +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 03:38:08 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: current-users@sun-lamp.cs.berkeley.edu Subject: the next release From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu To answer some questions: 1) will the interval between releases decrease? Yes. A large # of factors led to large window between 0.9 and the soon to arrive 1.0. These factors include legalities, and manpower. However we believe these problems are largely resolved. We have also invested time in tools to make future releases easier. 2) what will be in the next release? short answer: What we, and our contributors get done. long answer: What we, and our contributors get done. real answer: We don't know exactly. Will be in next release almost for sure: integration of 4.4-Lite user-level Possibilities for the next release: changes to accomodate the alpha port a few more ports become complete networking: rfc compliance interoperability security upgrade of gcc and gas performance improvements Thats my list....and only my list. Other core members, and our contributors each have their own. Feel free to send us your list. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 03:51:45 1994 From: buhrow@cats.ucsc.edu (Brian Buhrow) "the next release" (Jul 25, 4:28pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Adam Glass , current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release Sender: owner-current-users@sun-lamp.cs.berkeley.edu I believe the next release should have SCO binary compatibility in it. I know someone is working on it right now, does that person think it will be in a testable state soon and, perhaps, ready for the next release? -Brian From owner-amiga-dev@sun-lamp.cs.berkeley.edu Tue Jul 26 04:08:43 1994 Subject: Re: Problems still existing... From: Tim Newsham To: pepersb@cuug.ab.ca (Brad Pepers) Cc: amiga-dev@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu > > The first is the modem locking up. This happens when the computer > is sent a control-S from the remote system without a control-Q. If > you try to close the serial device, it hangs. From what I understand > you can hook up a terminal to the modem line and type control-Q and > it will be fixed but I don't have a terminal. The line is locked up > so I have to reboot to use it again. As it happens, when I disconnect > from a lot of systems I get spurious junk and it very often contains > control-S (I'm just lucky I guess!). I really wish this would get fixed. There is a work around though. In kermit (if thats what you use to dial up) set flow-control none after setting your line. This puts the tty into a mode that ignores those ixon/ixoff characters (-ixon -ixany from stty). > +------------------ Brad Pepers -- pepersb@cuug.ab.ca -------------------+ From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 04:11:08 1994 Subject: From: aod@beretta.ramp.com To: current-users@sun-lamp.cs.berkeley.edu Content-Length: 1147 Content-Type: text Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just wanted to apologize if my previous note sounded harsh. It was (hindsight is allways 20/20) a bad idea to write a plea for help after spending 4 hours of getting nowhere with getty and about 5 hours reading all the current-users archives and finding nothing. I dont mean to put the guys at netbsd down in any way. Quite honestly, If I didnt think it was the best OS.. i wouldnt have been using it since 0.8 and i definately wouldnt be trying to figure it out rather than just "install something else". Though I may not agree with certain portions of what you guys are coding, (and who doesnt?) I overall like the OS.. I guess what Im saying is... I fear change. ;) Thanx to the people who replied.. Hopefully the ttyflags wil fix this.. perhaps it would be a good idea to include a small "recipie" for setting up cu/tip/getty and whatnot for thier various functions included in the 1.0 release. I do remeber having a conniption or two when I originally got things working with 0.8. again. sorry if my note upset anyone.. I didnt mean for it to.. but we all know what 9 hours of consistant "bsd rejection" can do to someone. :) From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 21:01:33 1994 From: banshee@gabriella.resort.com (Robert Dobbs) To: current-users@sun-lamp.cs.berkeley.edu Subject: top-3.2 machine.c for -current Sender: owner-current-users@sun-lamp.cs.berkeley.edu Found and fixed a problem with process state. No more crash on exit. The virtual memory high water mark looks a bit fishy but I'm probally interpreting it wrong. ftp://resort.com/pub/machine.c  From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 21:50:28 1994 To: Scott Reynolds Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu > On Mon, 25 Jul 1994, Duncan McEwan wrote: > > > I'm not sure how "cu" works on other systems. > > While I can't answer the questions posed, I think it's worthwhile to note > that this is a (hacked?) version of Taylor UUCP 1.04, and that someone > who has time might want to check to see if any of the myriad > configuration and/or policy options might be used to solve this problem. > I've noticed that cu doesn't work quite that way I'd like, too, but I > "solved" that problem with C-Kermit 189 (see /usr/othersrc/README). On that same topic... Has anyone looked at merging the changes from Taylor 1.05 into the NetBSD tree? How much "hacking" has been done on the NetBSD version? --Randy From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:06:16 1994 From: rhealey@kas.helios.mn.org (Rob Healey) Subject: tickadj for xntp; how do you set it? To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 247 Sender: owner-current-users@sun-lamp.cs.berkeley.edu How do you set tickadj in NetBSD 1.0, it appears the kmem device is read-only once the security mode is set on multiuser startup. It also appears sysctl can't be used to access it either. How do you go about adjusting it for xntp? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:07:46 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: XFree86 2.1.1 binary distribution with aperture driver X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 423 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've made a set of pre-compiled XFree86 2.1.1 X servers with my patches to use my aperture driver to access linear framebuffers with VLB or PCI cards with NetBSD 1.0 alpha. They are available from ftp.laas.fr:/pub/NetBSD/XFree86-2.1.1/aperture/ You'll need apNetBSD.shar and the server corresponding to your hardware. Installation instructions are in the README in apNetBSD.shar. Comments are welcome. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:08:38 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu Subject: Kermit Problems X-Sun-Charset: US-ASCII Content-Length: 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've been using various versions of the Kermit 1.90 alpha/beta here with FlexFax 2.2.2. With June 1 current FlexFax and kermit both worked fine to a point, only lossage was kermit didn't quite do UUCP locking right and didn't work in a setuid mode. With July 22nd current, the kermit started showing the hang in open, ^C, and then it worked, but that of course wreaked havoc with my automatic scripts. I just crabbed the current 1.90 tar from kermit.cs.columbia.edu and built it. The only changes I needed were a netbsd: target that was a copy of the bsd44c: target with -DSAVEDUIDS added (to get setuid behavior working right). It works fine, doesn't hang, and even interacts properly with flexfax via UUCP locking, something it never did before. Yeah, I know, it's not the release kermit, but hey, it works. Older kermits don't seem to always get all the modem bit's right on newer BSDish systems. (We've had similar problems 1.89 versus 1.90 kermit on our SunOS 4 machines). -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:09:38 1994 From: John Nemeth "the next release" (Jul 25, 4:28pm) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Adam Glass , current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release Sender: owner-current-users@sun-lamp.cs.berkeley.edu Speaking of the next release, does anybody know when (even an approximate timeframe) 1.0 with be out? I'm trying to get several people, including myself, setup and it would be kind of silly to bring up a system, only to have the next release come out the next day. I know this question has been asked a couple of times recently, but I haven't seen any kind of answer yet, except that 1.0 ALPHA is available by SUP. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:11:01 1994 From: matthieu@laas.fr (Matthieu Herrb) To: John Kohl Cc: current-users@sun-lamp.cs.berkeley.edu Subject: multiple X servers under pcvt? X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 850 Sender: owner-current-users@sun-lamp.cs.berkeley.edu You wrote (in your message from Sat 23) > I've tried running two X servers on separate virtual consoles under > pcvt, to do some debugging. However, when I do so, I end up with a > keyboard in the wrong mode when I switch between X servers (I don't > recall exactly when the keyboard mode gets lost, but it's real easy to > do). > > Has anybody else run into this, and what did you do to fix it? > > XFree86-2.1.1 on SVGA server, if it matters. I has this problem once, when I started X on the wrong virtual console (Eg on ttyv3 I started xinit -- /usr/X386/bin/XF86_S3 vt01) ^ ^ +------------ mismatch -----------------------+ I normally don't use pcvt. I just run it sometimes to test that it still works with the XFree86 version under developpement. Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:11:36 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: Emacs terminal setup for pccons console (TERM=pc3) Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu It was in the course of creating this that I found that small problem with termcap. It's mostly a copy of AT386.el, but nonetheless I'd appreciate it if any changes made their way back to me. Install it somewhere in your Emacs load-path as term/pc3.el : ;; pc3.el --- terminal support package for *BSD console (based on AT386.el) ;; Author: Eric S. Raymond ;; Maintainer: Mike Long ;; Keywords: terminals ;; Copyright (C) 1992 Free Software Foundation, Inc. ;; Copyright (C) 1994 Mike Long. ;; This file is (not yet) part of GNU Emacs. ;; GNU Emacs is free software; you can redistribute it and/or modify ;; it under the terms of the GNU General Public License as published by ;; the Free Software Foundation; either version 2, or (at your option) ;; any later version. ;; GNU Emacs is distributed in the hope that it will be useful, ;; but WITHOUT ANY WARRANTY; without even the implied warranty of ;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the ;; GNU General Public License for more details. ;; You should have received a copy of the GNU General Public License ;; along with GNU Emacs; see the file COPYING. If not, write to ;; the Free Software Foundation, 675 Mass Ave, Cambridge, MA 02139, USA. ;;; Commentary: ;;; Uses the Emacs 19 terminal initialization features --- won't work with 18. ;;; Code: (if (boundp 'pc3-keypad-map) nil ;; The terminal initialization should already have set up some keys (let ((map (lookup-key function-key-map "\e["))) (if (not (keymapp map)) (error "No termcap/terminfo entry for pc3 nor ibmpc3.")) ;; These are not normally set up by termcap (define-key map "H" [home]) (define-key map "F" [end]) (define-key map "L" [insert]) (define-key map "W" [f11]) (define-key map "X" [f12]) ;; I don't know what to do with S-F1, C-F1, C-S-F1, &c. map)) (defvar pc3-keypad-map nil "Keymap for *BSD pccons console.") (define-key function-key-map "\e[" pc3-keypad-map) ;;; end of pc3.el -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:17:09 1994 From: John Nemeth X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: current-users@sun-lamp.cs.berkeley.edu Subject: sound stuff Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm going to setup a friend with NetBSD soon and she wants to know what kind of support there is for sound. I know there are sound board drivers, but I don't know what kind of utilities there are. I seem to recall Amancio doing something with Internet Talk Radio, but I haven't seen much else. So, what kind of stuff is there for sound (keeping in mind that the system probably won't be big enough to run X Windows)? From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:21:53 1994 From: "Szigeti Szabolcs 4. mikro PinkPanther" Subject: Re: Random timeouts in 1.0-ALPHA... To: buckwild@u.washington.edu (Mark Steven de Sagun-Tamola) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2269 Sender: owner-current-users@sun-lamp.cs.berkeley.edu [ ... ] > However, the real reason I'm mailing is because I'm having a little > quibble over the new wdc driver in 1.0-ALPHA. For some stupid reason, > I'm getting random timeouts and lost interrupts whenever disk access gets > heavy. The error message reads as follows: > > wdc0: lost interrupt: status 58 error 0 > wd: wdcstart: timeout waiting for drq: status 0 error 0 > > This message just repeats itself over and over until I do a ^C to stop > disk access. I was really pissed off because this also happens in the > latest version of FreeBSD, which is one of the small things that prompted > me to try something new. [ ... ] > By the way, I'm using a Western Digital Caviar 244 MB drive, and I guess > a `generic' ISA IDE controller. It seems that I'm the only one in the > world who is experiencing this problem, since no one on either the > FreeBSD or NetBSD has commented on these timeout problems. Anyway, some > help on this would be greatly appreciated. I had exactly the same problem with a WD Caviar drive (405M) a couple of months ago. (Anyone with Caviars?) The strange thing was that a similar drive works perfectly in my other machine. These lost intr messages came up sometimes right after boot, sometimes only after hours of operation. First I was thinking about the drive doing bad sector remapping, or thermal recalibration, but that won't explain why the other drive works in an other machine. I should have tried to swap them, but instead first tried to change the controller. (The faulty drive had a VL-bus ctrl in the 486 the other one in the 386 has a normal ISA-bus ctrl). So I changed the local bus ctrl with normal ISA and I don't have any problems since that. But as you use an ISA controller this is surely not the case, and the controller might very well has nothing to do with it. I'm staying with the ISA device, because it has a better serial I/O, and the disk speed is only 150K/s slower. Maybe try another controller? I suspect that because this disk was new then, it discovered the bad sectors, and did a remap. (But this should have been done in the factory) Now that all bad sectors are remapped, it doesn't do this any more. Other explanations: cosmic rays, ozone hole etc. :-). szabolcs From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:23:31 1994 From: John Kohl To: Matthieu.Herrb@laas.fr Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: multiple X servers under pcvt? X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I reproduced the problem last night, in some cases :) The case that seems to be bad is starting an xinit session _from within an xterm_. Starting a session on a separate vt that starts out in text mode seems to work just fine to have two X servers--except that xinit always wants to connect to :0 before starting the client program. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:37:17 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Taylor UUCP 1.05 To: randy%sierra%dsndata@sterling.com (Randy Terbush) Cc: scottr@plexus.com, 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: 525 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > On that same topic... > > Has anyone looked at merging the changes from Taylor 1.05 into the > NetBSD tree? How much "hacking" has been done on the NetBSD version? I've looked. I have a script (mostly works) that copies files from a Taylor UUCP distribution to the NetBSD directory hierarchy. I haven't had much reason to follow up on it, as 1.04 works fine for me. I don't think much hacking was done on the NetBSD version, but that's something I'd want to check before blindly integrating 1.05. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:47:33 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: John Nemeth Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release <199407260622.XAA21292@cue.bc.ca> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Speaking of the next release, does anybody know when (even an > approximate timeframe) 1.0 with be out? I'm trying to get several > people, including myself, setup and it would be kind of silly to > bring up a system, only to have the next release come out the next > day. I know this question has been asked a couple of times recently, > but I haven't seen any kind of answer yet, except that 1.0 ALPHA is > available by SUP. end of the month. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:50:53 1994 From: Ron Stanions Subject: Re: modem setup To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 1796 Sender: owner-current-users@sun-lamp.cs.berkeley.edu According to aod@beretta.ramp.com: > > I cannot get my com ports to work with ANY current utilities. I've spent many an hour trying to get my modems working. I have 3 com ports now, one with a dedicated in-house slip, one to a modem for dialout, and another to a modem for dialin. For the slip connection, I had to add 'stty clocal < /dev/tty00' to get it to NOT get hung up if I rebooted the computer it talked to. other than that I have nothing special to that line. For the dialout I have softcar set in ttys for the dialin I have rtscts set in ttys and have absolutely mangled my gettytab file trying to get the thing to work in 8N1 mode for ALL levels of input (bbs callers know 8n1), the pertinant information is: /etc/ttys: tty00 "/usr/libexec/getty std.38400" unknown off secure tty01 "/usr/libexec/getty std.115200" unknown off softcar tty02 "/usr/libexec/getty std.115200" vt100 on rtscts and the std.115200 entry in /etc/gettytab is: std.115200|115200-baud:\ :sp#115200:\tt=vt100:np:\ :i0#0x00002926:i1#0x00002926:i2#0x00002926:\ :o0#0x0000000B:o1#0x0000000B:o2#0x0000000B:\ :c0#0x00014B00:c1#0x00014B00:c2#0x00014B00:\ :l0#0x0000058B:l1#0x0000058B:l2#0x0000058B:\ :im=\r\n\r\n\Welcome\,\ to the Dragon's Weyr!\r\n\r\nType 'bbs' to log in to the BBS.\r\n\r\n:lm=(%t@%h) login\72 : The important things for the dialin line needed to have clocal off so it would send the HUP signal on carrier loss. for dialout clocal should be set high, and softcar should be set in the ttys file to cause the driver to not 'hang' when there's no carrier detected. also, dialin modems should be configured to auto-answer, and be entirely 'dumb'. (ATQ0E0S0=1) Hope this helps some. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 22:52:52 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Generic audio driver. From: Bill Squier Sender: owner-current-users@sun-lamp.cs.berkeley.edu A while ago there was some talk of developing a hardware independant audio library. Since my roommate and I are about to embark on a driver for the Windows Sound System (retch) I thought it a good idea to figure out the status of this (if any). Thanks, -wps From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 23:07:05 1994 From: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Snapshot Report - July 24th tar_files To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9047 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Snapshot report. ================ Me: agc@uts.amdahl.com (Alistair G. Crooks) Source: tar_files, 23rd July 1994, from ftp.iastate.edu Base version of NetBSD: 0.9. Upgrade from previous -current: yes, 16th July sources from ftp.iastate.edu Machine specifics: 386DX/40+387, 16MB RAM, 540 MB SCSI (Quantum), VGA card Other software: Matthieu Herrb's XFree86 2.1.1, built July 21 1994. Tar files integrity: good. Additional things to do during upgrade: None Any warnings during compilation: None noted. Any problems during make: None Changes from previous snapshot report: (This is taken from the CHANGES file on sun-lamp - last update on 21 July 94) amiga: changed internal serial port driver to use much smaller buffers (16k -> 256 and 24k ->3k) (chopps) amiga: added 2 non-copyright fonts for console- default to using them and not a possibly non-existant (c) user supplied one (chopps) amiga: disklabel support re-written to be more functional also added a machine/disklabel.h (chopps) amiga: added delay() an accurate useq delay uses last two free 16 bit countdown timers (chopps) amiga: added SYSCALL_DEBUG support (chopps) incorporate new version of lpd. (cgd) incorporate new version of libc's rcmd() and related functions. (cgd) add new pstat(8) program, which obsoletes swapinfo. (cgd) roll in a new sysv shared-memory module. (hpeyerl) introduce new core dump format. (pk) kernel debugging support in gdb. (pk) pc532: added the boot from ufs program. (phil) adosfs added (ro version) along with mount_ados (chopps) amiga: added new floppy, much cleaner (chopps) update rlogind, rshd, and telnetd to 4.4-Lite versions. (cgd) make fixes from Christos Zoulas which eliminate memory leaks and improper memory accesses (jtc) sh fix from Christos Zoulas which elimintes core dump when compiled w/out history support (for install floppies). (jtc) ip multicast mrouting fixes. Bring in previous version of mrouting code. Apply bug fix for igmp.c cksum errors from Steve McCanne. Fix mrouted (and friends) to fill in ip hdr fields that 4.4 no longer does for you. (brezak) updated chown/chgrp to 4.4-Lite versions. (cgd) replaced ipcs with version written by Thorsten Lockert . (cgd) updated src/share/doc tree to work like 4.4-Lite's. (cgd) added bm(3) functions from Keith Bostic. (cgd) replaced test with version from pdksh, with enhancements and cleanup by me. (jtc) rename cd.c to ccd.c and update to 4.4Lite version in /sys/dev. (concatenated disk driver). (hpeyerl) i386: fix disklabel clobbering MBR on disks shared with DOS. (brezak) [However, the only change from the previous week was brezak's i386 disklabel fix - agc] Notes: 0. Apologies for the three-month absence of these things. The truth is that I was snowed under, and didn't have the time to write the reports, although I've been keeping -current. The general feeling that I got last week was that these things were quite useful to have, and so I'll try to make the time. In the meantime, the 486 motherboard on pumpy died, so I'm back to the 386, and I'm now using SCSI peripherals hanging off an AHA 1542 - I know, but it's all I had, and it works. 1. Could the core team please update the CHANGES file when changes are made? For instance, this week the msdosfs was fixed, and some changes were made to the cd9660 file system. 2. msdosfs has been fixed. Thank you. 3. Michael VanLoon reported problems with the July 23rd (I think) tar_files. This isn't my experience, although I'm running with old bootblocks (1.19), and I'm only going to go to 4.4 inodes when I absolutely have to. In fact, I had absolutely no trouble upgrading this week. 4. Thanks to Matthieu Herrb's XFree86 2.1.1 for NetBSD 1.0 Alpha, available from ftp.laas.fr:/pub/NetBSD/XFree86-2.1.1 5. Could people please read the back copies of the mailing lists before they start porting software, please, to avoid duplicating effort? (I'm using tholo's patches with top-3.3beta3, and they're working very well, although I was surprised to find I had 329 Megabytes of Virtual memory, when I thought I only had 40-ish Meg :-)). 6. There still seems to be a strange combination of pax and tar in the /usr/src/include makefile. 7. To port things to -current these days, I find that I'm making sure that the lseek is properly prototyped, or that the second argument to it is cast to an off_t. If I don't do this, then strange core dumps ensue, especially on little-endian boxes. 8. I'm aware that these reports are highly i386-specific. Could the people working with other architectures please mail me, as I'd like to include a cross-platform bit here? 9. Last time I produced one of these reports, this was the i386 supported SCSI device list. Could someone please update me with any changes? aha1542b isa aha1542.c mycroft@gnu.ai.mit.edu aha1542c/cf isa aha1542.c hpeyerl@novatel.ca aha1742 eisa aha1742.c cgd@postgres.berkeley.edu aha1742 eisa aha1742.c mycroft@gnu.ai.mit.edu bt445 vlb bt742a.c dhess@cs.stanford.edu bt542 isa (mod'd driver) aha1542.c tim@introl.introl.com bt545 isa (old ones only) aha1542.c tim@introl.introl.com bt742 eisa bt742a.c deraadt@fsa.ca bt747 eisa bt742a.c michaelv@iastate.edu ultra34f vlb ultra14f.c jkreska@hpmail2.fwrdc.rtsg.mot.com ultra14f isa ultra14f.c mycroft@gnu.ai.mit.edu [The Adaptec 2742 is not supported, and may not be in future due to Adaptec's refusal to release "proprietary information" about the board.] (There has been some discussion over the best SCSI board to purchase. General reasoning was that Adaptec support wasn't good for non-DOS problems, and re the 2742 issue. The Ultrastore has jumpers for everything, which can be a pain. The Bustek boards have had favourable reports. Please note that I'm just condensing other people's opinions here, all you lawyers out there.) [I'm pretty sure the above information is well out of date - agc] 10. Likewise, the i386 Ethernet device list. 3c501 isa if_el (kimmel@cs.umass.edu) 3c503 (and probably 3C507, but I can't actually test it) (mycroft) 3c509 isa if_ep bnc/aui/utp. (tdr) 3c579 eisa doesn't work yet. (tdr) WD 8390-based cards isa if_ed (mycroft) SMC 8390-based cards isa if_ed (mycroft) NE1000, NE2000 isa if_ed (mycroft) NE2100 isa if_is (mycroft) AT&T StarLAN (82586-based cards) (mycroft) BICC Isolan (mycroft) If anyone has any more to add to this list, please contact me. [I'm pretty sure the above information is well out of date - agc] 11. If anyone doubts how overworked I am, I was out in California in June, and bought a SCSI-2 MO disk there. It's still in the box. If anyone wants to converse with me about such beasts, you know where I am. (BTW, 650MB SCSI-2, 65ms av. seek, $695, $100 for media - all prices retail, sure beats DAT tape for me). 12. On a recent perusal of the *BSD home page on the WWW, I saw that BSDi have their own hypertext manual page browser, called plexus. It's available from earth.com:plexus/3.0-beta/prerelease/Plexus-3.0m.tar.Z for anyone who wants to try this under NetBSD - I don't have the time, sorry. Note that you'll need some form of hypertext viewer, though. 13. For anyone a trifle nervous, having seen stories of not being able to boot their root filesystem etc, I'm taking quite a conservative line on this - I'm still using the 1.19 bootblocks, I've got 4.3 style inodes, and I'm running on SCSI disks. I repeat that I've had no problems this week upgrading. The problems that I have seen over the last few months (and which have all been fixed) are: a) pax was missing, and then core-dumped. Change /usr/share/mk/bsd.own.mk about line 35, and uncomment the "#SYS_INCLUDES= symlinks" line. b) I got a strange /var/run/utmp: No such file or directory from /etc/rc when I booted up, having updated my /etc/rc. This was because the line that creates that directory was trying to install it under a group which didn't exist in /etc/group (wsrc:*:83:). [I don't upgrade /etc every week, and I usually keep my own /etc/group files, which was why this one bit me - not badly, though.] c) msdosfs didn't compile 14. I'm looking for an 8-bit Ethernet (WD8003 or somesuch), and am willing to pay. It must be 8-bit, though, not 8/16-bit switching. 15. Finally, a very big thank you to all involved in making NetBSD 1.0_BETA. Over the last few months, I've found it to be very stable, and I'm continually impressed by the new things I see when booting up a new kernel, or making various sources. Well done, guys - almost there... Cheers, Alistair -- Alistair G. Crooks (agc@uts.amdahl.com) +44 252 346377 Amdahl European HQ, Dogmersfield Park, Hartley Wintney, Hants RG27 8TE, UK. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 23:23:57 1994 To: agc@uts.amdahl.com (Alistair G. Crooks) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Snapshot Report - July 24th tar_files X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 5. Could people please read the back copies of the mailing lists > before they start porting software, please, to avoid duplicating > effort? (I'm using tholo's patches with top-3.3beta3, and they're > working very well, although I was surprised to find I had 329 > Megabytes of Virtual memory, when I thought I only had 40-ish Meg > :-)). Actually, non-intuitive as it may seem, this number is actually, by the literal wording of the description of the data, correct. Note that the description is "active virtual memory", not "physical memory used for active virtual memory". Basically what that means is that it's the sum of the sizes of the memory objects that have been used in the last N seconds, multiplied by the number of times that object is mapped in different processes. Actually, it's not 100% correct; it's still a little on the high side, but not nearly so much as you'd guess. In any event, it's definitely non-intuitive, and not too useful, either, and eventually i'd like to get around to "fixing" it, but "not today." This is a case where broken, but sensible, software is better than working software. 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 23:44:38 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, jtk@atria.com Subject: Re: multiple X servers under pcvt? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I always found that: xinit -- :0 xinit -- :1 worked fine for me. From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 23:45:55 1994 From: Mike Long To: groo@menger.eecs.stevens-tech.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Tue, 26 Jul 1994 12:31:36 -0400 >From: Bill Squier >A while ago there was some talk of developing a hardware independant >audio library. Since my roommate and I are about to embark on a >driver for the Windows Sound System (retch) I thought it a good idea >to figure out the status of this (if any). I made noises about a WSS and/or PSS (Cardinal, Orchid, &c.) driver, but I didn't do anything. I may do something when 1.0 arrives, and I have a stable platform to work with. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Tue Jul 26 23:48:18 1994 From: "Charles M. Hannum" To: current-users@sun-lamp.cs.berkeley.edu Subject: i386 bogons fixed Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just fixed two major bugs: * The boot block was accidentally getting compiled with some 486-specific instructions, and would thus not work on 386 machines. * The disklabel code was munging the device number handed to it by the device driver, and causing havoc with the floppy driver. Actually, most of the bugs people have reported here recently have been fixed now. If you're not sure, or you know your bug hasn't been fixed, send me (private) mail. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 01:14:49 1994 From: Alan Barrett Subject: Re: tickadj for xntp; how do you set it? To: Rob Healey 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 > How do you set tickadj in NetBSD 1.0, it appears the kmem > device is read-only once the security mode is set on multiuser > startup. I run tickadj and xntpd from /etc/rc.local, while the security level still permits it. --apb (Alan Barrett) From owner-tech-kern@sun-lamp.cs.berkeley.edu Wed Jul 27 01:22:02 1994 From: gwr@jericho.mc.com (Gordon W. Ross) To: tech-kern@sun-lamp.cs.berkeley.edu Cc: core@sun-lamp.cs.berkeley.edu Subject: src/sys/vm/vm_swap.c: sw_nblks Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu How is sw_nblks supposed to be set? When I boot a kernel configured for root on sd0a swap on sd0b the value of swdevt[0].sw_nblks stays at zero. Confused... Gordon Ross From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 01:57:13 1994 From: rhealey@aggregate.com Subject: current boot floppy set? 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: 72 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is there a boot floppy set for current like there is for 0.9? -Rob From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 02:12:26 1994 To: Bill Squier Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. From: Havard Eidnes Sender: owner-current-users@sun-lamp.cs.berkeley.edu > A while ago there was some talk of developing a hardware independant > audio library. Since my roommate and I are about to embark on a > driver for the Windows Sound System (retch) I thought it a good idea > to figure out the status of this (if any). I have the start of a generic audio pseudo-device driver. It is a transformation of the bsd_audio.c/sb.c drivers in the current system. I did this so that I could start developing a device driver for my own audio hardware -- that part has been slow going so far (still trying to get my programmed loopback tests to work). I have not been able to test the transformed bsd_audio/sb driver pair, since I do not have a SoundBlaster. This driver still basically presents the same interface to the user, i.e. basically /dev/audio. I have some thoughts on how a /dev/audioctl interface could be implemented. As for libraries and user programs that is uncharted territory for me for the time being -- I've thought of a simple play/record pair of tools. My changes are available on request -- if you want them contact me before friday this week (I'm out travelling right now and will be unavailable next week). - Havard From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 02:33:20 1994 From: John Kohl To: groo@menger.eecs.stevens-tech.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Sender: owner-current-users@sun-lamp.cs.berkeley.edu There is the AudioFile system from DEC's Cambridge Research Lab; it is to audio what X11 is to graphics. FTP to crl.dec.com and poke around. There aren't drivers yet for the common PC sound cards, but that is just a SMOP :) ==John From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 02:34:10 1994 To: Havard Eidnes Cc: groo@menger.eecs.stevens-tech.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. <9407261957.AA23025@ravn> 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 >> A while ago there was some talk of developing a hardware independant >> audio library. Since my roommate and I are about to embark on a >> driver for the Windows Sound System (retch) I thought it a good idea >> to figure out the status of this (if any). > >I have the start of a generic audio pseudo-device driver. It is a >transformation of the bsd_audio.c/sb.c drivers in the current system. I >did this so that I could start developing a device driver for my own audio >hardware -- that part has been slow going so far (still trying to get my >programmed loopback tests to work). I have not been able to test the >transformed bsd_audio/sb driver pair, since I do not have a SoundBlaster. > >This driver still basically presents the same interface to the user, i.e. >basically /dev/audio. I have some thoughts on how a /dev/audioctl >interface could be implemented. For what it's worth, I've started using Havard's code as a base to get my 0.9 Ultrasound driver working. I think it's a good start (there are still some things I would like to add), and I recommend everyone who wants to write a sound driver to use it. Who all is interested in doing this? Is there enough interest to form a separate mailing list? Maybe this should move to the i386 list. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 02:41:27 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: the next release Sender: owner-current-users@sun-lamp.cs.berkeley.edu >> Speaking of the next release, does anybody know when (even an >> approximate timeframe) 1.0 with be out? > >end of the month. I believe that was the "deadline" agreed to with USL but is the core team happy that it really will be genuinely production quality release by then? For all architectures? (I don't really expect them to be equally good, but "just the facts, maam") cheers, Danny Thomas who's glad he didn't have volunteer for the hassles in keeping up with current on his production 0.9 systems, particularly since no information seems to have been made public about goals for 1.0, approx release schedules (until cgd's announcment a few months ago), etc. Then again maybe I should have kept following the news groups. I'll ftp the summer bof soon and that's probably what I've been looking for for a long time (even though it was "out of date a few hours later"). OR have I missed an FAQ (Dave?). From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 02:43:32 1994 From: Mike Long To: brezak@apollo.hp.com Cc: Havard.Eidnes@runit.sintef.no, groo@menger.eecs.stevens-tech.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu I probably don't have time to write a driver before the rest of you do, but I can answer questions any of you may have on the WSS, PSS, the AD1848 codec, &c. I'm also willing to alpha-test anything you come up with; I have a Cardinal DSP-16 with the wavetable ROM. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 03:00:46 1994 To: Havard Eidnes Cc: Bill Squier , current-users@sun-lamp.cs.berkeley.edu, Mike Long Subject: Re: Generic audio driver. <9407261957.AA23025@ravn> X-Mailer: exmh version 1.3 4/7/94 From: John Brezak Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > A while ago there was some talk of developing a hardware independant > > audio library. Since my roommate and I are about to embark on a > > driver for the Windows Sound System (retch) I thought it a good idea > > to figure out the status of this (if any). > > I have the start of a generic audio pseudo-device driver. It is a > transformation of the bsd_audio.c/sb.c drivers in the current system. I > did this so that I could start developing a device driver for my own audio > hardware -- that part has been slow going so far (still trying to get my > programmed loopback tests to work). I have not been able to test the > transformed bsd_audio/sb driver pair, since I do not have a SoundBlaster. > > This driver still basically presents the same interface to the user, i.e. > basically /dev/audio. I have some thoughts on how a /dev/audioctl > interface could be implemented. > > As for libraries and user programs that is uncharted territory for me for > the time being -- I've thought of a simple play/record pair of tools. > > My changes are available on request -- if you want them contact me before > friday this week (I'm out travelling right now and will be unavailable > next week). > > - Havard I got a copy of a PSS (Cardinal DSP-16) audio driver for the Linux VoxWare. I want to shape this into a driver in the BSD framework. I'm willing to send this code to those trying to build a driver for the WSS. I'm also interested in getting the generic audio driver code. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5122 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 03:10:09 1994 From: Dave Burgess Subject: Re: Kermit Problems To: mark@aggregate.com (Mark P. Gooderum) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 519 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > > I just crabbed the current 1.90 tar from kermit.cs.columbia.edu and built > it. The only changes I needed were a netbsd: target that was a copy of the > bsd44c: target with -DSAVEDUIDS added (to get setuid behavior working right). > It works fine, doesn't hang, and even interacts properly with flexfax via > UUCP locking, something it never did before. > 1. kermit.columbia.edu 2. In the kermit/test/bin subdir (cku190.tar.gz is 880K) Just thought you'd all like to know that someone reads this stuff. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 03:45:06 1994 From: Dave Burgess Subject: Compiling Kermit straight out of the box... To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 245 Sender: owner-current-users@sun-lamp.cs.berkeley.edu n the past half hour, I ftped the source for kermit-190. Instead of changing the Makefile, I used the 'make bsd44c -KFLAGS=-DSAVEUIDS' options and it worked just fine. This may solve some of the problems some of us are having with com ports. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 04:36:35 1994 From: Arthur Hoffmann Subject: Ada for NetBSD, what's the status? 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: 259 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, Someone was working on a port of Gnu Ada for NetBSD. What is the status on the port so far? Thanks. Arthur. __ Arthur Hoffmann 58/1 Dickward Drive Fannie Bay N.T. 0820 Darwin - Australia. hoffmann@it.ntu.edu.au Tel.:(0061/)89/818926 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:00:05 1994 From: Mike Long To: burgess@s069.infonet.net Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Compiling Kermit straight out of the box... Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From: Dave Burgess >Date: Tue, 26 Jul 1994 19:11:44 -0500 (CDT) > >n the past half hour, I ftped the source for kermit-190. > >Instead of changing the Makefile, I used the 'make bsd44c >-KFLAGS=-DSAVEUIDS' options and it worked just fine. This may solve >some of the problems some of us are having with com ports. I find these reports interesting, considering the fact that an examination of ckutio.c shows that -DSAVEDUID does nothing unless -DSETREUID is also used. If you use both of them, then you get that irritating warning from setreuid(). Are you running it setuid root? I've had to use the patch below ever since the setreuid() warning was put in. I'll have to try submitting my prettied-up version of it to C-Kermit's author again. My kermit binary is setuid to uucp, and my /etc/ttys sets the clocal flag on /dev/tty00 (my modem's com port). diff -u ckutio.c\~ ckutio.c --- ckutio.c~ Sun Jul 10 18:51:42 1994 +++ ckutio.c Tue Jul 26 22:16:05 1994 @@ -7176,8 +7176,8 @@ * 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) +#define switchuid(hidden,active) seteuid(active) +#define switchgid(hidden,active) setegid(active) #endif /* SETREUID */ -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:04:26 1994 To: Danny Thomas Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release <199407262244.IAA00837@xroads.vthrc.uq.oz.au> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I believe that was the "deadline" agreed to with USL but is the core team > happy that it really will be genuinely production quality release by then? I think the answer is 'yes'. We've been finding 'loose ends' for a while now, and are pretty much done getting them taped down. (duct tape is a hacker's friend. 8-) My guess on when 1.0 will ship is "just before 8/3, or just after 8/9." > For all architectures? (I don't really expect them to be equally good, > but "just the facts, maam") Not all. "lots." A notable couple probably won't be "production quality." Anyway, 1.0 is expected to include "production quality" binaries for (in alphabetical order): amiga hp300 i386 hp300 pc532 sparc > who's glad he didn't have volunteer for the hassles in keeping up with > current on his production 0.9 systems, particularly since no information > seems to have been made public about goals for 1.0, approx release > schedules (until cgd's announcment a few months ago), etc. We were actually gearing up to do another release back around February. However, while that was in progess, i received a Very Nice Letter from one Burt Levine, whose job title happens to be "Senior Corporate Counsel" for this teensy company named "Novell." That got resolved around March, and requires us to pull any 'tainted' binaries by 7/31. So, theoretically, we could have gotten on with the release, and kicked it out the door, and done another one once we got the 4.4-Lite code. Unfortunately, that was no longer practical, because of other demands on our time. (for me, it was bad timing, because i was a student, gearing up for the end of the semester...) We also thought it was impractical to do a release, then do another two months later, mostly because the release cycle is several weeks long itself. So the release was put off until we got the 4.4-Lite tape, integrated it, and got the system back to "normal." After this was done -- around the end of May -- we could have gotten the release cycle going again, but i had the problem of having to move across the country, and for various other reasons, that, too, was a bad time for people. So we started gearing up for a release at about the beginning of July -- a full 4 months after we wanted to have the release out the door. My goal is to get a release out once every six months; any more is too much of a drain on the development cycle. Because of the legal issues that had to be resolved, we more of less had to skip the 'assigned time slot' for the last release cycle. Our original goals for 1.0 were along the lines of: [general] more supported architectures/unified multi-architecture release [general] shared libs [i386] better device, autoconfiguration, and interrupt support. a couple of things that i've forgotten by now, and, of course, as many bugs fixed as possible. In reality, "4.4-Lite" integration had to be added to that list as well, and that's been a _very_ large part of our work over the last couple of months. We've sent CSRG on the order of half a meg of diffs to fix bugs in the 4.4-Lite code we've integrated so far, which is more or less _only_ the kernel and a few user programs! It's _not_ been easy going. I actually hope that the next release (1.1) will happen sooner than six months from now. Some of the goals for it include complete 4.4-Lite integration, more device support (for all architectures), more stability, more uniformity across the architectures, and better install tools. There are obviously more things that are on the todo list than that, but those are what pop into my mind immediately. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:04:56 1994 From: Mike Long To: kenh@wrl.epi.com Cc: Havard.Eidnes@runit.sintef.no, groo@menger.eecs.stevens-tech.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Tue, 26 Jul 1994 17:48:09 -0400 >From: Ken Hornstein >Who all is interested in doing this? Is there enough interest to form a >separate mailing list? Maybe this should move to the i386 list. I'd definitely like to be on any mailing list that is formed; I can't set one up myself, though. You all may want to check out the BSD audio driver in the sparc port. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:05:56 1994 To: gt@prosun.first.gmd.de (Gerd Truschinski) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Find a way for a monthly distribution <9407270120.AA05946@prosun.first.gmd.de> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu [ I've been letting these pile up for a day. now i'm goign to answer them in reverse order. ] > > I really want to be able to point my friends and associates > > at a stable release as great as 1.0, and being able to let them just > > go at it. So, I guess what I'm saying is, can we make the next major > > release a little less ambitious, and, say, not more than six months > > from the previous release (1.0)? I'm not asking you to lower your > > sites -- simply to take the leaps in small increments. I think it > > would really help make it usable for the people who can't quit grasp > > upgrading to current, especially in the later stages. This has really > > been my only beef with the NetBSD development, thus far. > > Please excuse my bad english, but isn't it possible to give a > ''current' - monday tree' to someone who could build a distribution? > Someone who is building a set of floppies for someone who wants to > establish a new system? This may be a '1.001' and a '1.002' system. > A system wich is not 'correct' but running. In a word: NO. If an auto manufacturer were designing a new car, and there was great public demand for that car, would you rather the automobile manufacturer start building and shipping them in quantity before the safety analyses were complete, or would you rather they wait? There's a _hell_ of a lot to do to build a 'distribution'. First of all, you have to coordinate between the various ports that are going to be a _part_ of the distribution. Then you have to branch the tree, and start having the people responsible for the ports have people alpha test them. You kill bugs, eventually it becomes beta-testing. You kill more bugs, and tag it as "final." you have everybody build binaries and kick them out the door. You _must_ have a release be as well-tested as possible. Why? because it will persist nearly _forever_. Almost a year after it was released, people are still installing 0.9. It'll be the only thing available on some FTP sites for several months after 1.0 is released. Who gets the bug reports for these releases? In general, it's _not_ the people who made the release, it's netbsd-bugs@lamp. It's a _lot_ of work to create a release, it _shouldn't_ be done without testing, and it shouldn't be done too _often_, because that's a revision management nightmare. What you release today isn't worth a whit if it isn't a viable platform _tomorrow_, because people are going to run it _then_. > BTW. why is the sender of the mail-list e-mail a personal account and > not the LIST? It is easier for me to save the mails to 'current' if > the sender also is 'current' or how the list is named today. > It may be that 'you' only save the messages of some people from > the list and then under their names. But I want to save the messages > under the list name. Who is the sender of the message? is it the mailing list, or the person who sent the message? (obviously, it's the latter; it gets sent _to_ the mailing list.) There's also the fact that if the message is "From:" the mailing list, it's bloody difficult to reply to the real sender! I certainly hope you believe that not every reply should be made to the mailing list... 8-) Besides, if you're using a 'reasonable' mail system, it's just as easy to sort on 'To:' as it is on 'From:'. In general, i sort mail that i consider 'bulk' by To primarily, then Cc, then From. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:13:00 1994 To: Adam Glass Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release <199407252328.QAA08169@sun-lamp.cs.berkeley.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > 1) will the interval between releases decrease? > > Yes. A large # of factors led to large window between 0.9 and the > soon to arrive 1.0. These factors include legalities, and manpower. > However we believe these problems are largely resolved. We have > also invested time in tools to make future releases easier. Actually, the latter sentence needs more emphasis: we've invested a _LOT_ of time in tools to make future releases easier. With the advent of the 'binary snapshots', it became an automated process. Unfortunately, that's not quite the right way to build a release, but we've been working on _that_ too, and now have a simple set of tools to build a set of 'binary sets' for any architecture in an automated way. > Will be in next release almost for sure: > integration of 4.4-Lite user-level > > Possibilities for the next release: > changes to accomodate the alpha port ACtually, more generally, "changes to accomodate ports to 64-bit architectures." The NetBSD core team and the various people working on ports of NetBSD are gaining more experience (literally) daily regarding portability issues. Also, once again, if any of you out there are interested in working on ports, and have the time, hardware, docs, and patience, please get in touch with core@sun-lamp.cs.berkeley.edu. > Feel free to send us your list. Let me reiterate that, in a slightly different manner: PLEASE send us your list, or at least please send _me_ your list, especially if you are working on it, or willing to. Also please remember that our priorities are almost guaranteed to be different than yours -- for instance, i know a _lot_ of you would like good sound support, and, while i'd like it too, it won't ever be _that_ important to me, because i won't use it. So you've gotta be willing to put a bit of sweat into it to. (That's just an example; i'm _very_ glad to see that people are seriously working on sound support with a uniform interface. That's what we've been waiting for! 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:13:24 1994 To: Luke Mewburn Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <199407251228.WAA16595@goanna.cs.rmit.oz.au> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Does netbsd-current use lots of net/2.untainted code in userland? yes. > If so, are there any plans to integrate 4.4-lite userland stuff, yes. > especially stuff that hasn't had netbsd-local changes? yes, and even the stuff that has. > If yes, can we get an approximate timeframe? "hopefully by the time the next release is out the door." Can't really say more than that. > The reason why I'm interested is because I was going to (in my > Infinite Spare Time :) compile a lot of the userland tree with > -Wall or whatever, as well as with ld warnings for some non-ansi > functions (bcopy, rindex), so I could make the code more portable. > Not much use doing this on net/2 derived stuff if it's gunna be > replaced by 4.4-lite stuff (which I have the source to locally as > well.) yah. a lot of people have had similar needs, etc., and all i can say is "we're getting to it as soon as we can." priority one right now is getting 1.0 out the door. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:14:54 1994 From: Drew Hess Subject: Re: Generic audio driver. To: Mike.Long@analog.com Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 576 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > >Who all is interested in doing this? Is there enough interest to form a > >separate mailing list? Maybe this should move to the i386 list. > > I'd definitely like to be on any mailing list that is formed; I can't > set one up myself, though. Me too. > > You all may want to check out the BSD audio driver in the sparc port. > Hmm, I thought that the i386 port already had the BSD audio driver (in /sys/arch/i386/isa/bsd-audio.c or something like that; don't have access to my machine right now). Or is this entirely different? -dwh- dhess@cs.stanford.edu From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:24:24 1994 To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <9407252252.AA01834@ponderous.cc.iastate.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Out of curiosity, is it going to be another year and a half before the > next release? :-) It hasn't been a year and a half, though if you'd like us to wait that long, i don't think we'd be willing to accomodate you. NetBSD 0.9 was released on 8/23/1993. I know that date very well, because it also happened to be the start of the Fall '93 semester at UCB... 8-) That's not even a year ago. > It has been kind of a pain the last few months, > telling people how great NetBSD has become, but when they ask how to > install the good stuff, having to give them complicated, and ever- > more-impossible to achieve, destructions on how to get upgraded to > current. I really want to be able to point my friends and associates > at a stable release as great as 1.0, and being able to let them just > go at it. So, I guess what I'm saying is, can we make the next major > release a little less ambitious, and, say, not more than six months > from the previous release (1.0)? The reasons that this release have taken so long _aren't_ really 'ambitious goals' -- as i've explained before (i.e. "before today," and "before, today"), the main reason for this release taking so long to get out was that we didn't want to rush a release out, around april or may, then have to get another one out _not_, and, for various reasons, it was impractical to do. > I'm not asking you to lower your > sites -- simply to take the leaps in small increments. The big problem with getting this release out the door was upgrading the "tainted" code in Net/2 to the "free" code in 4.4-Lite. That was no small undertaking, and one we _had_ to do. > I think it > would really help make it usable for the people who can't quit grasp > upgrading to current, especially in the later stages. This has really > been my only beef with the NetBSD development, thus far. This is the reason i started doing binary snapshots -- to make life easier for people upgrading to -current. As you know, however, that's _not_ a substitute for a new release, because: (1) it's hard to install (2) it can be a maintenance nightmare. I started doing binary snapshots for the i386 because i _knew_ we had little choice about getting a release done immediately, but i wanted to make life easier for those upgrading. *sigh* "there are only 36 hours in a day." 8-) > That said, please understand, overall, I think NetBSD-1.0 is the best > small-system unix available, bar none. You guys have done one helluva > job! Thanks for all your dedication. thank you. 8-) we're not done yet. it's still beta. 8-) > >This was probably discussed at the NetBSD BOF, but for those > >of us who couldn't make it and didn't see the report on the BOF (was it > >ever posted?), it'd be nice to have a list of things we can look forward > >to/work towards. :-) > > Yes, we've heard about all these people who went to see the eleet BOF, > but nobody posted a detailed summary!! Inquiring minds still want to > know! Would someone please be so kind as to take a couple hours and > sit down and write us up a report of the event? We'd all appreciate > it, I'm sure. :-) the summary has made it out the door now, i guess; it was actually done a bit ago, but we wanted to review it, make sure everything was correct, etc. unfortunately, there were more pressing things to do, so it got delayed a while, then finally kicked out with little review. "c'est la vie." If you can't prioritize your inputs, you'll always freeze when you see the headlights... 8-) chris From owner-netbsd-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:32:45 1994 To: klee@rdcclink.rd.qms.com Cc: netbsd-users@sun-lamp.cs.berkeley.edu Subject: Re: NetBSD 1.0 ??? Where? <9406257751.AA775153974@rdcclink.rd.qms.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-netbsd-users@sun-lamp.cs.berkeley.edu >This morning, I have read somebody's broadcast on emacs for NetBSD >1.0. I, then, figured that NetBSD 1.0 is out. Nope, it's not out yet. It's currently in "beta-test", and i'm hoping to kick another set of beta binaries for the i386 out tonight. >When I looked at >comp.os.386bsd.announcement, I did not see any announce about NetBSD >1.0. Don't worry, it'll be widely announced when it happens. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:35:00 1994 To: tsarna@endicor.com (Ty Sarna) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > In article <199407251228.WAA16595@goanna.cs.rmit.oz.au> Luke Mewburn writes: > > Does netbsd-current use lots of net/2.untainted code in userland? > > If so, are there any plans to integrate 4.4-lite userland stuff, > > especially stuff that hasn't had netbsd-local changes? > > If yes, can we get an approximate timeframe? > > I assume if this was going to be in 1.0 it would have happened long ago > so I guess it'll be in 1.1/2.0/whatever. right. we're not finishing killing whatever bugs we see, and wrapping things up, to kick them out the door. > Speaking of which, since we're getting close to 1.0, what are the goals > for the next release (1.1 or 2.0 or whatever) in terms of new features, > ports, etc? it'll be 1.1, i hope. 8-) I think at least a few of the new features have already been outlined. AS for "in terms of ports": you just can't really have goals about ports, because porting is, while very important to the NetBSD project, mostly done by "individuals." I.e. they do it when they can, and get it done when they get it done, and you don't make any assumptions about when those things may occur. 8-) One of the goals of the next release will be more "support" for 64-bit architectures, i.e. the kernel will get a little bit cleaner here and there so they won't be such a pain in the butt. > And, on an unrelated question, what's wrong with lamp? unclear; it's crashing occasionally, but the majority of the time it's down, something else is happening entirely, and we have _no_ clue what. The big problem is that i'm not in Berkeley any more to watch it, and there's typically nobody around at all, let alone somebody who could investigate what's wrong with it. > It seems to be > down more often than not lately. Is it down for testing, or hardware > problems/upgrades or something? The big problem is, it's in an office where there are people once ever 24-36 hours, and they're only there for a few hours, at most. We're in the process of getting things set up so that these problems will change in the near future. (change to what? hopefully something less severe. 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 06:58:55 1994 To: Peter Galbavy Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: libsa/saerrno.h <199407251950.UAA00250@alice.wonderland.org> From: John Brezak Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Is it my problem, or do the errno values in sys/errno.h and libsa/saerrno.h > have lots of conflicting values/defn ? > > I am trying to build the new SPARC boot blocks and libsa is not happening > for me. libsa/strerror.c is breaking. > > Help, It used to compile... The error codes in saerrno.h were pruned to not conflict with the existing ones in errno.h. The saerrno.h errno's are just for the standalones and represent unique errors of this environment. Now one could argue that these errno's shouldn't exist and one should just use the "standard" errno's. But this destroys compatability with old standalones (of AT&T vintage). Now it seems to have been reverted to the 4.4 original version. Why ? I suggest that libsa be added to the sys/lib Makefile to help catch these errors in the future. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= John Brezak UUCP: uunet!apollo.hp!brezak Hewlett Packard/Apollo Internet: brezak@ch.hp.com 300 Apollo Drive Phone: (508) 436-4915 Chelmsford, Massachusetts Fax: (508) 436-5122 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 07:00:14 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Thanks Chris! From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Thanks Chris for the excellent report on the status of NetBSD, and background on timing of the releases. It makes everything much clearer. (Now if only all the other things in my life were so clear...) Once again, thanks Chris, Theo, Charles, Adam, JTC (James?), and all the supporting cast (hope I didn't forget a core member) for such an awesome system. You guys are unreal. Who pays your bills? Surely you guys don't have real jobs, too. ;-) If you guys were all female, I'd give you all a big kiss... 'course, I'd probably get charged with multiple counts of rape... Next time you're in Iowa, stop by and I'll buy you guys a pitcher of beer, each. Boy won't that be a party! ;-) --Michael P.S. I only wish I could contribute more. Unfortunately, I *do* have a real job -- three of them, in fact -- and my days are 48 hours long, but still not long enough. C'est la vie... ----------------------------------------------------------------------------- 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 Jul 27 07:10:39 1994 To: Drew Hess Cc: Mike.Long@analog.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. <9407270246.AA29622@Xenon.Stanford.EDU> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Me too. use port-i386@sun-lamp; that's what it's there for. [Replies redirected there.] > Hmm, I thought that the i386 port already had the BSD audio driver (in > /sys/arch/i386/isa/bsd-audio.c or something like that; don't have access > to my machine right now). Or is this entirely different? The problem with the current bsd-audio.c it should (theoretically) be hardware independent. If you'll notice, right now it's _very_ closely tied to the SB. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 07:25:18 1994 To: "Chris G. Demetriou" Cc: tsarna@endicor.com (Ty Sarna), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <9407270255.AA00320@alpha.bostic.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > In article <199407251228.WAA16595@goanna.cs.rmit.oz.au> Luke Mewburn writes: > > > Does netbsd-current use lots of net/2.untainted code in userland? > > > If so, are there any plans to integrate 4.4-lite userland stuff, > > > especially stuff that hasn't had netbsd-local changes? > > > If yes, can we get an approximate timeframe? > > > > I assume if this was going to be in 1.0 it would have happened long ago > > so I guess it'll be in 1.1/2.0/whatever. > > right. we're not finishing killing whatever bugs we see, and wrapping > things up, to kick them out the door. s/not// "and maybe my brain will one day connect to my fingers..." chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 07:30:29 1994 From: Mike Long To: dhess@CS.Stanford.EDU Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Generic audio driver. Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From: Drew Hess >Date: Tue, 26 Jul 1994 19:46:01 -0700 (PDT) >> You all may want to check out the BSD audio driver in the sparc port. > >Hmm, I thought that the i386 port already had the BSD audio driver (in >/sys/arch/i386/isa/bsd-audio.c or something like that; don't have access >to my machine right now). Or is this entirely different? BSD audio drivers exist in both the i386 and the sparc ports; they both have the same ancestry, but also both have been heavily modified. If I remember correctly the original bsd-audio driver can be FTPed from ftp.ee.lbl.gov. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 07:34:13 1994 To: "Chris G. Demetriou" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: the next release <9407270223.AA29794@alpha.bostic.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Not all. "lots." A notable couple probably won't be "production > quality." Anyway, 1.0 is expected to include "production quality" > binaries for (in alphabetical order): > amiga > hp300 > i386 > hp300 > pc532 > sparc No, there aren't two hp300 ports, nor did i forget a port, nor did the Gods of Alphabetization change the rules while i was making that list... 8-) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 07:39:07 1994 To: John Brezak Cc: Peter Galbavy , current-users@sun-lamp.cs.berkeley.edu Subject: Re: libsa/saerrno.h <9407270311.AA18390@relay.hp.com> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I suggest that libsa be added to the sys/lib Makefile to help catch these > errors in the future. Actuallly, i'm going to send some mail out about 'libsa' to the 'appropriate' parties this evening. libsa, as it currently stands, is a pile of junk that, and many of the files contain redefinitions that makes them invalid C. (i'm beginning to _seriously_ hate gcc's lousy syntax and semantic checking, and its 'extensions'...) chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 12:59:31 1994 To: Peter Galbavy Cc: "Chris G. Demetriou" , tsarna@endicor.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <199407270600.HAA03311@alice.wonderland.org> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Please make one of the design aims for the next release a cross- > compilation environment, so that we (I) can build for (say) sparc > on an Intel and visa-versa. This way I could have a single "developement" > system and many running systems of deifferent arch's. can't promise anything, but i hope to be able to take a couple of steps in the right direction. One of those will be replacing 'obj' directories with a more useful mechanism of keeping /usr/src read-only and keeping arch. binaries seperate... "just a teaser..." chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 13:05:12 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Release mechanisms (Was: "Re: Find a way for a monthly distribution") <9407270204.AA29532@alpha.bostic.com> From: - Greg Earle Sender: owner-current-users@sun-lamp.cs.berkeley.edu >There's a _hell_ of a lot to do to build a 'distribution'. First of all, you >have to coordinate between the various ports that are going to be a _part_ of >the distribution. Then you have to branch the tree, and start having the >people responsible for the ports have people alpha test them. You kill bugs, >eventually it becomes beta-testing. You kill more bugs, and tag it as "final." >You have everybody build binaries and kick them out the door. > >You _must_ have a release be as well-tested as possible. Why? Because it will >persist nearly _forever_. Almost a year after it was released, people are >still installing 0.9. It'll be the only thing available on some FTP sites for >several months after 1.0 is released. Perhaps Chris (or someone else) could clear up something for me. Chris talks about a release cycle in the above quoted text in terms that I am familiar with. Declare an Alpha, code freeze it, test it out, then make changes/fixes and at some point, declare a beta, code freeze it, test it out, etc. all over again, and at some point declare an FCS (First Customer Ship) release. It hasn't been clear to me what is going on with NetBSD that parallels the above paradigm. Pardon any unintentional naivete and/or stupidity on my part, but I've been sitting back, letting "sup" do its nightly thing, hopefully keeping my source tree up-to-date by doing so; on the other hand, suddenly and without much fanfare I'm seeing mumblings of "Oh, btw, it's now 1.0-Alpha" when describing some unnamed version of -current. I can't recall seeing an official "If you've sup'ped up through to today, or if you've started from scratch and downloaded some src tarballs and unbundled them, you've got an Official NetBSD 1.0-Alpha system (with Secret Decoder Ring (-: )". I've seen mentions of 0.9c instead. I certainly haven't seen any "If you've sup'ped up through to today, ... dot dot dot, you've got an Official code-frozen NetBSD 1.0-Beta system". And now all of a sudden, Chris and Adam are saying "1.0 - not Alpha, not Beta, (not even Vons or Ralphs (-: ) but the Real Thing" is coming out in a couple of weeks. I guess I'm confused by this, especially since I've read every piece of current-users mail that comes through my mail spool since 'way back (-: I would appreciate it if someone could straighten this out for me and anyone else that might be confused by how things stand. Thanks, - Greg From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 13:12:09 1994 From: Alan Barrett Subject: fsck problems To: current-users@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have been having trouble with fsck for several weeks now. My root partition is in a state that the current fsck is unable to fix, and I don't like that. Sometimes fsck core dumps with SIGSEGV, and sometimes it doesn't. On the occasions that it doesn't coredump, it leaves the disk in an inconsistent state, which sometimes leads to kernel panics (something about "mangled directory"). An old fsck from -0.9 also SIGSEGV's. I am not sure, but it looks somewhat as though, when fsck reconnects an unreferenced file and/or directory to lost+found, it leaves lost+found and/or the root directory in a bad state. I tried running fsck under gdb, and at the point where the SIGSEGV occurs, gdb becomes unable to display a traceback, which leads me to suspect that the stack is getting clobbered. I tried compiling fsck with CFLAGS= "-g -ansi -pedantic -Wall -Wtraditional -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Wredundant-decls", and I fixed averything it complained about (except a few things that I judged to be harmless). That didn't help. I append a transcript illustrating the problem. Help! What do I do now? --apb (Alan Barrett) # ./fsck /dev/rsd0a ** /dev/rsd0a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity UNREF DIR I=80648 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 13:31 1994 RECONNECT? [yn] y [*** note: inode 80648 was a previous incarnation of /lost+found, *** which I zapped with clri because it was bad and was causing kernel *** panics.] NO lost+found DIRECTORY CREATE? [yn] y DIR I=80648 CONNECTED. PARENT WAS I=2886 UNREF DIR I=72002 OWNER=cschle MODE=40777 SIZE=512 MTIME=Jul 5 13:10 1994 RECONNECT? [yn] y DIRECTORY CORRUPTED I=15 OWNER=barrett MODE=41777 SIZE=1024 MTIME=Jul 25 21:42 1994 DIR=? SALVAGE? [yn] y Segmentation fault - core dumped # ./fsck /dev/rsd0a ** /dev/rsd0a ** Last Mounted on / ** Root file system ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames DIRECTORY CORRUPTED I=2 OWNER=root MODE=40755 SIZE=1024 MTIME=Jul 24 14:14 1994 DIR=/ SALVAGE? [yn] y ** Phase 3 - Check Connectivity UNREF DIR I=80648 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 13:31 1994 RECONNECT? [yn] n UNREF DIR I=80648 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 13:31 1994 RECONNECT? [yn] n UNREF DIR I=72002 OWNER=cschle MODE=40777 SIZE=512 MTIME=Jul 5 13:10 1994 RECONNECT? [yn] n UNREF DIR I=72002 OWNER=cschle MODE=40777 SIZE=512 MTIME=Jul 5 13:10 1994 RECONNECT? [yn] n UNREF DIR I=69151 OWNER=root MODE=40755 SIZE=1024 MTIME=Feb 14 11:31 1994 RECONNECT? [yn] n UNREF DIR I=66252 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 12:04 1994 RECONNECT? [yn] n UNREF DIR I=66252 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 12:04 1994 RECONNECT? [yn] n UNREF DIR I=51842 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 11:15 1994 RECONNECT? [yn] n UNREF DIR I=60480 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 02:14 1994 RECONNECT? [yn] n UNREF DIR I=51842 OWNER=barrett MODE=40777 SIZE=512 MTIME=Jul 5 11:15 1994 RECONNECT? [yn] n UNREF DIR I=48962 OWNER=root MODE=40755 SIZE=512 MTIME=Jul 15 01:41 1994 RECONNECT? [yn] n UNREF DIR I=34562 OWNER=barrett MODE=40700 SIZE=512 MTIME=Jul 4 10:32 1994 RECONNECT? [yn] q RECONNECT? [yn] q RECONNECT? [yn] ^C# From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 13:33:08 1994 To: Ty Sarna Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Q's on 4.4-lite userland integration <199407270402.AA27981@fezzik.endicor.com> From: jason downs Sender: owner-current-users@sun-lamp.cs.berkeley.edu In message <199407270402.AA27981@fezzik.endicor.com>, Ty Sarna writes: >What a joke. NetBSD is quite a bit more stable than SunOS in my >experience. not to mention more secure. -- ---------------------------------------- -------------------// jason downs // downsj@CSOS.ORST.EDU //------------------ ---------------------------------------- JD105 http://www.CSOS.ORST.EDU/downsj/index.html have you fed your sysadmin today? From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 13:42:37 1994 From: Ty Sarna Subject: Re: Q's on 4.4-lite userland integration To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: tsarna@endicor.com, current-users@sun-lamp.cs.berkeley.edu Organization: Endicor Technologies, Inc., San Antonio, Texas X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1103 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Chris G. Demetriou wrote: > > And, on an unrelated question, what's wrong with lamp? > > The big problem is, it's in an office where there are people once > ever 24-36 hours, and they're only there for a few hours, at most. You can find cheap (<$30 I think) watchdog timers for PC clones in BBS magazines. You'd have to port the software to NetBSD, but that shouldn't be hard. At least then when it crashes unattended it won't be down for long. > We're in the process of getting things set up so that these problems > will change in the near future. (change to what? hopefully something > less severe. 8-) As Neil McRae would probably say, "Hey, why don't you losers run a *REAL* system, like SunOS?" What a joke. NetBSD is quite a bit more stable than SunOS in my experience. I get better support as well. Sun wants big bucks for the same marginal support you give for free. :-) ObPlug: NetBSD is worth every penny I paid for SunOS. SunOS is worth every penny I paid for NetBSD. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!! From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 13:59:16 1994 To: Greg Earle Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Release mechanisms (Was: "Re: Find a way for a monthly distribution") <9407270433.AA12073@isolar.Tujunga.CA.US> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Perhaps Chris (or someone else) could clear up something for me. Chris talks >about a release cycle in the above quoted text in terms that I am familiar >with. Declare an Alpha, code freeze it, test it out, then make changes/fixes >and at some point, declare a beta, code freeze it, test it out, etc. all over >again, and at some point declare an FCS (First Customer Ship) release. For NetBSD, the release cycle is the following: (1) "normal development" of NetBSD-current, and people running it, is pre-alpha. (2) at some point, it's decided that the code should be frozen for a release. At that point: a) the source tree is branched and tagged b) the tree in ~ftp starts to mirror the branch c) the "only" changes that go into the tree are "serious bug fixes." no new features. d) people working on ports are encouraged to make binary 'snapshots' of the code at that point, and get them out to their users. The last binary snapshot i made for the i386 is an example of that. (3) as people find bugs, bug fixes go in. more snapshots are made, as necessary, etc. (4) once the system is determined to be "pretty much there", it's made beta. another snapshot is made, and people start building "real release" binaries. After this, the only changes that go into the branch are for "show-stoppers" -- i things that cause the system to croak in a miserable and unacceptable way, cause serious data loss, etc. (5) "pre-release" binaries and installation methods are created and tested, and released to the users for testing. (6) after the pre-release binaries and installation methods have been tested, one more set of binaries -- the final set -- is prepared, tested for simple things like basic installation and runnability (which is all that's necessary, because they're ideally identical to those in (5)). (7) finally, the release is shipped. >It hasn't been clear to me what is going on with NetBSD that parallels the >above paradigm. basically, we've gotten to about stage (4) now, and are in the process of building the binary snapshots for 1.0-beta, for you to test. It's a relatively quiet process, because people who keep up with -current will end up running the 'latest' beta code. basically, it's sort-of like there are N alpha and M beta test releases, one for each day that the 'alpha' or 'beta' tag appears in the newvers.sh file... There's no real announcement (nor a need for one) until it gets to be time to teast the "pre-release" binaries, because there are people running every day's -current, and so there _are_ people running the code and testing it. >I can't recall seeing an official >"If you've sup'ped up through to today, or if you've started from scratch and >downloaded some src tarballs and unbundled them, you've got an Official NetBSD >1.0-Alpha system (with Secret Decoder Ring (-: )". That's becasue we don't consider 'alpha' very much different than normal NetBSD-current. i do believe after i made the last binary snapshot for the i386, i went out of my way to encourage people to use it... >And now all of a sudden, Chris and Adam are saying "1.0 - not Alpha, not Beta, > [ ... ] Not all of a sudden -- there've been a large number of hints for a while that we were, in fact, getting into the release process... It's not as formal as it could be, but we're not here to do formal releases, we're here to improve the software, and make it available in the most convenient form possible. Releases are a side-effect, albeit a necessary and important one, of the process of software development and distribution. If we were here to make money off of this, you could damn well bet that we'd have very well-defined rules about the release process, and very-well-announced stages. We'd also have several people doing nothing but release engineering all of the time, because for a multi-architecture system like NetBSD, 'commercial quality' release engineering could very well be a non-stop job. Our release engineering ins't quite 'commercial quality,' but we don't see the most important aspects of NetBSD to be the releases themselves. chris From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 14:14:13 1994 From: Peter Galbavy Subject: Re: Q's on 4.4-lite userland integration To: "Chris G. Demetriou" Cc: tsarna@endicor.com, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 777 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Speaking of which, since we're getting close to 1.0, what are the goals > > for the next release (1.1 or 2.0 or whatever) in terms of new features, > > ports, etc? > > it'll be 1.1, i hope. 8-) > I think at least a few of the new features have already been outlined. Please make one of the design aims for the next release a cross- compilation environment, so that we (I) can build for (say) sparc on an Intel and visa-versa. This way I could have a single "developement" system and many running systems of deifferent arch's. Just my wish-for-the-day. Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 14:14:48 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: scsi crash dump 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 was wondering what the what the status is of the crash dump code for SCSI disk drives. Right now, I see a bunch of code #ifdef'd out in sd.c. I have no qualms about trying to get it working myself, but I was wondering if anyone else knows what's going on with it, it would help me out a lot. --Ken From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 14:52:13 1994 To: Jan-Hinrich Fessel Cc: cgd@alpha.bostic.com (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Which Release for DEC <199407271022.MAA16333@zappa.unna.Ping.DE> From: Theo de Raadt Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Which release is going to run on a DEC 5400 Server, aside > from ultrix;-) the next NetBSD release is (pretty much) gauranteed to work on the decstations. > Are the things under the pmax directory intended for this > kind of machine? yup. well, at least some decstations. > And how do I bootstrap NetBSDEC? It is really called NetBSD/pmax. by hacking together a userland environment under ultrix, you shouldn't have too much trouble building the kernel. As for the userland, things are a bit more problematic. The pmax port is being held back by exactly this: no userland binaries yet (basically, the problem is linker and assembler support). From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 15:08:36 1994 From: Jan-Hinrich Fessel Subject: Which Release for DEC To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 427 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Not all. "lots." A notable couple probably won't be "production > quality." Anyway, 1.0 is expected to include "production quality" > binaries for (in alphabetical order): > amiga > hp300 > i386 > hp300 > pc532 > sparc Which release is going to run on a DEC 5400 Server, aside from ultrix;-) Are the things under the pmax directory intended for this kind of machine? And how do I bootstrap NetBSDEC? Cheers Oskar From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 15:18:29 1994 To: Jan-Hinrich Fessel Cc: cgd@alpha.bostic.com (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Which Release for DEC <199407271022.MAA16333@zappa.unna.Ping.DE> X-Mailer: exmh version 1.4.1 7/21/94 From: Marc Evans - Contract Software Hacker Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Which release is going to run on a DEC 5400 Server, aside > from ultrix;-) > Are the things under the pmax directory intended for this > kind of machine? > And how do I bootstrap NetBSDEC? THe DEC 5400, 5500 and 5800 machines have never had device information released to net community, so my guess is that they will not be provided without some fairly heafty reverse engineering... The "pmax" area in the current netbsd tree is only capable of supporting "workstations", e.g., things that sit on your desk and have a graphics head. - Marc =============================================================================== Marc Evans, Software Consultant WB1GRH Synergytics E-Mail: Marc@Synergytics.Com 21 Hinds Lane, Suite 23L URL: http://WWW.Synergytics.Com/~marc Pelham, NH, USA 03076-3013 PGP-2.6 key available upon request +1 603 635 3857 (voice/fax) MIME-1.0 & Enriched-Text mail accepted Unix & X11 internals/apps =============================================================================== From owner-amiga@sun-lamp.cs.berkeley.edu Wed Jul 27 16:19:47 1994 Newsgroups: culist.netbsd.amiga Path: rmcormon From: rmcormon@superior.ccs.carleton.ca (Russell McOrmond) Subject: Re: tty00, modems, and hell - what they have in common. Organization: Carleton University, Ottawa, Canada Distribution: culist Lines: 36 Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <9407250655.AA00253@icecube.cryogenic.com>, William J Coldwell wrote: >Is _ANYONE_ using this for dial-in? If so, tell me what I'm doing wrong... > >My understanding is that tty00 will not fire up getty until a "CONNECT" is >seen from the modem.. I have &c1 (follow carrier detect), and &D2 >(disconnect and enter command state if DTR is pulled) on the modem. I only wish we were running UUGetty or Mgetty - It's actually just a very old dumb getty that we are running with the standard binaries at the moment. You have to turn off all result codes, and the getty just sits there waiting for you to hit return a few times after connecting. BTW: Careful with the 'np' vs 'ap' with the line settings - the console requires np, and the modem line would much prefer ap (Unless you know that any calls will always be 8 bits, no parity - something that has caused me problems). Hope this helps. I will, in the future (When I get time) be compilling mgetty+sendfax/etc on my machine (Likely after I upgrade to NetBSD 1.0), and I'll put up the compiled binaries for NetBSD. For those of us using phone lines, I do wish that this were something that would be put into the standard distributions. --- Russell McOrmond, Ottawa Ontario, Canada. Work: Array Development Standard Disclaimer applies: I didn't do it, it was an accident! Russell's Home Page From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 27 16:25:49 1994 From: heinz@igd.fhg.de Subject: gdb 4.11 won't compile 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: 730 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Yesterday, i tried to compile gdb 4.11 on an A3000/25 with 12MB fast ram, running netbsd-940709. In solib.c, the compiler (gcc2.4.5) complains about missing structures (link_dynamic, link_dynamic_2,...). /usr/include/link.h contains the structures dealing with dynamic linking , but with different names than gdb expects. Since i'm not a unix expert i'm stuck here. Where should i get the new link.h ? Or is gdb 4.11 outdated, so that a new gdb archive will know the NetBSD implementation of shared libraries ? -- Klaus Heinz * * The amount of intelligence on heinz@igd.fhg.de * * this planet is a constant ; Kamar@IRC * * the population grows From owner-amiga-dev@sun-lamp.cs.berkeley.edu Wed Jul 27 17:17:27 1994 From: Danny Lepage Subject: Broken sh 'expr' ? To: current-user@sun-lamp.cs.berkeley.edu (current-user mailing list) Cc: amiga-dev@sun-lamp.cs.berkeley.edu (amiga-dev mailing list) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 782 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu It seems that sh is in someway broken. 'expr' don't seem to work as expected. I've tryed examples from the man pages without success, and this cause some problem with the configure script of Elm2.4 (the script don't wait for the user answers, just assume the default...). [See UU/myread] Also, cuserid(), sigsetjmp(), siglongjmp() are documented in the man pages but seem to be missing from libc. (Had this problem compiling Elm). I'm running NetBSD-Amiga 0.9C snapshots. Anybody else having this problem ? Is it just a NetBSD-Amiga problem or other ports have these too ? Is this fix in 1.0a (assuming I'm not the only one having those problems) ? Beside, did'nt somebody managed to get a working Elm on Netbsd ? Thanks Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 17:36:57 1994 From: Peter Galbavy Subject: ep0 not found today To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 414 Sender: owner-current-users@sun-lamp.cs.berkeley.edu A kernel built from todays sup, with just ed0 and ep0 defined (from GENERICAHA) does not detect the card, but the netbsd-aha kernel from the last i386 snapshot does. Something has changed. Help :( Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 17:38:54 1994 From: Kim Toms To: current-users@sun-lamp.cs.berkeley.edu Subject: Booting on Sparcs Sender: owner-current-users@sun-lamp.cs.berkeley.edu I have a SparcStation 1 that has recently had NetBSD installed on it. I have rebuilt the kernel, and when it works, it is fine. However, when attempting to bootstrap itself, it often comes partway up and just after the 'bwtwo0' line in the messages below, it begins printing the prompt from the boot PROM, namely: type b (boot), c (continue), or n (new command mode) continously, and L1-A has no effect - it must be powered off in order to stop it. While trying to reproduce this problem, I have noticed that it does not happen as often if I go into 'new command mode' before booting. Is this a known problem? memreg0 at mainbus0 ioaddr 0xf4000000 clock0 at mainbus0 ioaddr 0xf2000000: mk48t02 (eeprom) timer0 at mainbus0 ioaddr 0xf3000000 zs0 at mainbus0 ioaddr 0xf1000000 pri 12, softpri 6 zs1 at mainbus0 ioaddr 0xf0000000 pri 12, softpri 6 fd at mainbus0 ioaddr 0xf7200000 not configured audio0 at mainbus0 ioaddr 0xf7201000 pri 13, softpri 4 sbus0 at mainbus0 ioaddr 0xf8000000: clock = 25 MHz dma0 at sbus0 slot 0 offset 0x400000: rev 1 esp0 at sbus0 slot 0 offset 0x800000 pri 3: ESP100, clock = 25 MHz, ID = 7 tg2 at esp0 target 2 sd2 at tg2 unit 0: MST SnapLink 0001, 1048576 512 byte blocks sd2: tg0 at esp0 target 3 sd0 at tg0 unit 0: FUJITSU M2263S-512 01A5, 1315658 512 byte blocks sd0: le0 at sbus0 slot 0 offset 0xc00000 pri 5: hardware address 08:00:20:08:52:4e bwtwo0 at sbus0 slot 3 offset 0x0: SUNW,501-1455, 1152 x 900 (console) auxreg0 at mainbus0 ioaddr 0xf7400000 Found boot device sd0 From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 17:49:13 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, peter@alice.wonderland.org Subject: Re: ep0 not found today Sender: owner-current-users@sun-lamp.cs.berkeley.edu Did you do a warm or cold boot? The driver is known to not find cards after a warm boot on some machines. (Yes, this is a lose.) From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 18:26:05 1994 From: "Charles M. Hannum" To: current-users@sun-lamp.cs.berkeley.edu Subject: IRQ and DRQ autoconfiguration Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've just enabled some old code I had written in the aha, ahb, bt, and uha drivers, to use the IRQ and DRQ read off the board at boot time, rather than statically configuring the info into the kernel. Basically, if you have something like: controller aha0 at isa? port "IO_AHA0" irq 11 drq 5 then the settings will be checked against those on the card, and if they don't match, the probe will fail. However, if you do: controller aha0 at isa? port "IO_AHA0" irq ? drq ? then the driver will simply use whatever settings it finds on the card. I also fixed some bogons related to how DMA channels were configured, that have been around since Julian. Some of this probably showed up in the FTP area last night; the rest will show up tonight. It would be good if people with these types of SCSI controllers would test the code and let me know ASAP if it doesn't work. (It's been tested on all the standard card types, but not on random Adaptec clones.) Note that EISA and VLB cards don't actually use the ISA DMA controller, but BusLogic cards may show up as `drq 5' if you use `drq ?' (or don't specify). Apparently the boards by default claim to be DRQ 5 in order to be compatible with some old ISA drivers, and this `feature' can be turned off (at least for the EISA boards, using the EISA configuration utility). I didn't consider this very important, and didn't want to risk modifying the driver right now to ignore the DRQ for these boards. P.S. Eventually, all drivers which can read this type of information off the controller should, and as little as possible of the info should be statically configured. It turns out, however, that trying to divine IRQ information (for boards which won't tell you) doesn't actually work in practice; some <> stupid devices power up in a state where they are generating interrupts, and confuse the IRQ discovery process. From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 18:26:45 1994 From: Danny Lepage Subject: Broken sh 'expr' ?? To: current-users@sun-lamp.cs.berkeley.edu (current-users mailing list) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 784 Sender: owner-current-users@sun-lamp.cs.berkeley.edu It seems that sh is in someway broken. 'expr' don't seem to work as expected. I've tryed examples from the man pages without success, and this cause some problem with the configure script of Elm2.4 (the script don't wait for the user answers, just assume the default...). [See UU/myread] Also, cuserid(), sigsetjmp(), siglongjmp() are documented in the man pages but seem to be missing from libc. (Had this problem compiling Elm). I'm running NetBSD-Amiga 0.9C snapshots. Anybody else having this problem ? Is it just a NetBSD-Amiga problem or other ports have these too ? Is this fix in 1.0a (assuming I'm not the only one having those problems) ? Beside, did'nt somebody managed to get a working Elm on Netbsd ? Thanks Danny Lepage poutine@M3iSystems.QC.CA dlepage@CAM.ORG From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 18:39:03 1994 From: Peter Galbavy Subject: Re: ep0 not found today To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 432 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Did you do a warm or cold boot? The driver is known to not find cards > after a warm boot on some machines. (Yes, this is a lose.) Finds it after a hard reset. sigh. Sorry for watsing evryones mail- bandwidth. Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 19:20:14 1994 From: ejh@slueas.slu.edu (Eric J. Haug) To: current-users@sun-lamp.cs.berkeley.edu Subject: src/bin/sh histedit.h missing Sender: owner-current-users@sun-lamp.cs.berkeley.edu Seems src/bin/sh/histedit.h is missing. eric From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 19:34:29 1994 From: Nate Williams "Re: Release mechanisms (Was: "Re: Find a way for a monthly distribution")" (Jul 27, 1:38am) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Chris G. Demetriou" Subject: Re: Release mechanisms (Was: "Re: Find a way for a monthly distribution") Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > If we were here to make money off of this, you could damn well bet > that we'd have very well-defined rules about the release process, > and very-well-announced stages. We'd also have several people doing > nothing but release engineering all of the time, because for a > multi-architecture system like NetBSD, 'commercial quality' release > engineering could very well be a non-stop job. Our release > engineering ins't quite 'commercial quality,' but we don't see the > most important aspects of NetBSD to be the releases themselves. Hear hear! As a member of the *evil* competition, I'd like to commend Chris and *ALL* the rest of the NetBSD-core team on a job well done. We may disagree on certain issues, but for the most part I appreciate all the work they do. Good job folks, and I hope that 1.0 is the best NetBSD yet! Nate From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 20:07:32 1994 To: apana-lists-os-netbsd-general@apana.org.au Path: news From: andrew@werple.apana.org.au (Andrew Herbert) Newsgroups: apana.lists.os.netbsd.general Subject: Re: fsck problems Organization: werple public-access unix, Melbourne Lines: 29 Sender: owner-current-users@sun-lamp.cs.berkeley.edu barrett@daisy.ee.und.ac.za (Alan Barrett) writes: >I have been having trouble with fsck for several weeks now. My root >partition is in a state that the current fsck is unable to fix, and I ... >I tried running fsck under gdb, and at the point where the SIGSEGV >occurs, gdb becomes unable to display a traceback, which leads me to >suspect that the stack is getting clobbered. I was having some fun with a segfaulting fsck a week ago. The stack was being clobbered as you note above. I tracked down the bug for my particular flavour of mangled filesystem to be in dirscan(): dirscan(idesc) register struct inodesc *idesc; { ... char dbuf[DIRBLKSIZ]; ... for (dp = fsck_readdir(idesc); dp != NULL; dp = fsck_readdir(idesc)) { dsize = dp->d_reclen; bcopy((char *)dp, dbuf, (size_t)dsize); As dsize is not being bounds checked, and particularly nasty mangling can result in dsize > DIRBLKSIZE, there is a problem. Any comments on what the correct return value or other action would be for this out-of-bounds condition? return (SKIP), perhaps? Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 20:40:10 1994 X-Authentication-Warning: kurt.Tools.DE: Host kurt.TooLs.DE didn't use HELO protocol From: jk@tools.de (Juergen Keil) Subject: Re: fsck problems To: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu In article barrett@daisy.ee.und.ac.za (Alan Barrett) writes: > I have been having trouble with fsck for several weeks now. My root > partition is in a state that the current fsck is unable to fix, and I > don't like that. Sometimes fsck core dumps with SIGSEGV, and sometimes > it doesn't. On the occasions that it doesn't coredump, it leaves the > disk in an inconsistent state, which sometimes leads to kernel panics > (something about "mangled directory"). An old fsck from -0.9 also > SIGSEGV's. I've had similar problems when upgrading to current last week. The affected filesystem still uses the old inode format. I've found two bugs in fsck: 1. On a filesystem using the old inode format, fsck always generates new directory entries (i.e. in lost+found) in the new directory record format! 2. If a directory is corrupted exactly after the '..' entry (e.g. because of 1.), fsck crashes with a segmentation violation. Reason is a directory record with d_reclen > DIRBLKSIZE. This crashes in dirscan, where the damaged directory record is copied into a local variable of exactly DIRBLKSIZE bytes. The record with d_reclen > DIRBLKSIZE is produced in 'fsck_readdir', which can be called recursively via dofix->direrror->fileerror-> getpathname->... fsck_readdir increments the '..' entry's d_reclen field twice by the amount of bogus data contained in the directory block following after the '..' entry. I suggest the following patch, which should fix both problems. =================================================================== RCS file: /home/cvs.kurt/NetBSD/sbin/fsck/dir.c,v retrieving revision 1.1.1.3 diff -c -r1.1.1.3 dir.c *** 1.1.1.3 1994/07/14 12:28:45 --- dir.c 1994/07/21 19:11:32 *************** *** 190,202 **** --- 190,214 ---- ndp = (struct direct *)(bp->b_un.b_buf + idesc->id_loc); if (idesc->id_loc < blksiz && idesc->id_filesize > 0 && dircheck(idesc, ndp) == 0) { + long fixed_reclen; + size = DIRBLKSIZ - (idesc->id_loc % DIRBLKSIZ); idesc->id_loc += size; idesc->id_filesize -= size; + fixed_reclen = dp->d_reclen + size; fix = dofix(idesc, "DIRECTORY CORRUPTED"); bp = getdirblk(idesc->id_blkno, blksiz); dp = (struct direct *)(bp->b_un.b_buf + dploc); + #if 0 dp->d_reclen += size; + #else + /* + * dofix above might scan over our broken directory record + * and fix it's size, too. The old code increments + * dp->d_reclen twice. + */ + dp->d_reclen = fixed_reclen; + #endif if (fix) dirty(bp); } *************** *** 336,341 **** --- 348,367 ---- dirp->d_reclen = newent.d_reclen; dirp->d_namlen = newent.d_namlen; bcopy(idesc->id_name, dirp->d_name, (size_t)dirp->d_namlen + 1); + + /* + * 'dirscan' will eventually swap the original dirp back to the + * old inode format. Handle the new dirent here. + */ + # if (BYTE_ORDER == LITTLE_ENDIAN) + if (!newinofmt) { + u_char tmp; + + tmp = dirp->d_namlen; + dirp->d_namlen = dirp->d_type; + dirp->d_type = tmp; + } + # endif return (ALTERED|STOP); } -- Juergen Keil jk@tools.de ...!{uunet,mcsun}!unido!tools!jk From owner-current-users@sun-lamp.cs.berkeley.edu Wed Jul 27 21:53:33 1994 From: jconklin@netcom.com (J.T. Conklin) Subject: Re: Broken sh 'expr' ?? To: poutine@M3iSystems.QC.CA (Danny Lepage) 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: 761 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > It seems that sh is in someway broken. 'expr' don't seem to work as > expected. I've tryed examples from the man pages without success, and > this cause some problem with the configure script of Elm2.4 (the script > don't wait for the user answers, just assume the default...). Yes. There was a bug with expr(1) on big-endian machines. The fix was checked in, and will be there in 1.0. > Also, cuserid(), sigsetjmp(), siglongjmp() are documented in the man pages > but seem to be missing from libc. (Had this problem compiling Elm). cuserid() is in -lcompat (But it shouldn't ever be used since it means different things on different systems, see the manpage). I did the i386 sigsetjmp & siglongjmp() --- a m68k user needs to do the same. --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 03:22:05 1994 From: Julian Howard Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: /sys/doc/options.doc Sender: owner-current-users@sun-lamp.cs.berkeley.edu I suggest NetBSD might like to adopt something like FreeBSD's /sys/doc/options.doc (by Garrett A. Wollman) While referencing my NetBSD-pc532 options (FASTLINKS etc), I had to fall back to my i486-Freebsd /sys/doc/options.doc Luckily I have both BSDs, but some pc532 owners (& other NetBSD users) dont, so those folk might appreciate /sys/doc/options.doc. PS I run PC532-NetBSD & i486-FreeBSD. I have previously received unsolicited biased mail suggesting I abandon xBSD in favour of yBSD: such suggestions are unwelcome, hopefully folk retaining a foot in each camp can encorage BSD co-operation :-) -- Julian Stacey Alternates: , Tel. +49 89 268616 TZ=GMT+1 Munich, Germany From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 03:40:41 1994 Subject: Re: COM_SW_CLOCAL and "cu" (was: COM_SW_SOFTCAR handling) To: duncan@comp.vuw.ac.nz (Duncan McEwan) From: "Martin Husemann" Cc: cgd@alpha.bostic.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: 667 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > If you do a "cu -l /dev/tty01" where tty01 has had the COM_SW_CLOCAL bit set by > ttyflags, the open succeeds. But when you try to type anything you get > > cu: write: input/output error I don't know what version you are using, but with -current from 26 July it works fine for me on i386. My /etc/ttys line is: # modem under control of mgetty: tty01 "/usr/libexec/mgetty tty01" vt100 off local rtscts Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 04:03:29 1994 From: Julian Howard Stacey To: current-users@sun-lamp.cs.berkeley.edu Subject: /sys/doc/options.doc Sender: owner-current-users@sun-lamp.cs.berkeley.edu I suggest NetBSD might like to adopt something like FreeBSD's /sys/doc/options.doc (by Garrett A. Wollman) While referencing my NetBSD-pc532 options (FASTLINKS etc), I had to fall back to my i486-Freebsd /sys/doc/options.doc Luckily I have both BSDs, but some pc532 owners (& other NetBSD users) dont, so those folk might appreciate /sys/doc/options.doc. PS I run PC532-NetBSD & i486-FreeBSD. I have previously received unsolicited biased mail suggesting I abandon xBSD in favour of yBSD: such suggestions are unwelcome, hopefully folk retaining a foot in each camp can encorage BSD co-operation :-) -- Julian Stacey Alternates: , Tel. +49 89 268616 TZ=GMT+1 Munich, Germany From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 04:31:30 1994 From: der Mouse To: kim@morningstar.com Subject: Re: Booting on Sparcs Cc: current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I have a SparcStation 1 that has recently had NetBSD installed on it. > [...] [W]hen attempting to bootstrap itself, it often comes partway > up and just after the 'bwtwo0' line in the messages below, it begins > printing the prompt from the boot PROM, namely: > type b (boot), c (continue), or n (new command mode) > continously, and L1-A has no effect - it must be powered off in order > to stop it. While trying to reproduce this problem, I have noticed > that it does not happen as often if I go into 'new command mode' > before booting. Is this a known problem? Close. From the README file for the latest SPARC binary snapshot I have, which is the one of July 14th: |6. your rom may need some setup. make sure you boot from `new command mode'. | If your machine comes up and gives you a `>' prompt instead of `ok', type: | >n | ok setenv sunmon-compat? false | ok | this is needed because netbsd cannot handle the old-mode yet, | and will firework on you. | | you cannot use the security modes of the sparc rom. sorry, same | problem as above. | ok setenv security-mode none Now, it doesn't specify precisely what "firework on you" means, but what you describe certainly seems to me to be a likely candidate. Whoever installed NetBSD on your SS1 should have done these already, but I guess not.... Try setting security-mode and sunmon-compat? as described, and see if it helps things any. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 04:47:23 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Peter Galbavy Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: ep0 not found today Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Peter Galbavy writes: >> Did you do a warm or cold boot? The driver is known to not find >> cards after a warm boot on some machines. (Yes, this is a lose.) > Finds it after a hard reset. sigh. Sorry for watsing evryones > mail- bandwidth. I don't think it is a waste of bandwidth. This used to work find around 0.9a. What has changed? -bri From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 04:58:41 1994 From: "Charles M. Hannum" To: lm@rmit.edu.au Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: /sys/doc/options.doc Sender: owner-current-users@sun-lamp.cs.berkeley.edu Actually, some of your info is wrong and/or outdated. Specifically: 'VNODEPAGER', 'caching of vnodes; REQUIRED', 'DEVPAGER', 'caching of devices; REQUIRED', These are actually for mmap() of vnodes and/or devices. 'FASTLINKS', 'store short symlinks in the inode instead of the filesystem', This is deprecated. (It's always done on new file systems, and old file systems with them can be read.) 'XSERVER', 'machine is an X server', This is deprecated, unless you're using pcvt. 'UCONSOLE', 'use console as X server', Actually, this controls whether a non-root user is allowed to acquire the console device with TIOCCONS. 'NFSSERVER', 'Sun\'s Network File System - server', 'NFSCLIENT', 'Sun\'s Network File System - client', Sun does not own our code. B-) 'MSDOSFS', 'MS-DOS file system', There's a deprecated version of this called `PCFS'. 'IMP', 'XXX: some network protocol', That was the host-to-IMP protocol used many years ago when the ARPAnet was started. We don't have the IMP code in our tree, and I doubt anyone would want it. 'TPIP', 'XXX: some network protocol', That's the connection-based protocol in OSI; it's to CLNP as TCP is to IP, except that it was invented by ISO. 'EON', 'XXX: some network protocol', That's for CLNP tunneling over IP, I think. 'MULTICAST', 'multicast networking', Multicast is always included now. (It's small, and it avoids a mass of #ifdefs.) The option is deprecated. 'is0', 'isolan ethernet', You might want to note that this has been renamed to `le'. 'tun', 'XXX: unknown', That's the network tunnel line discipline. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 05:08:57 1994 To: ejh@slueas.slu.edu (Eric J. Haug) Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: src/bin/sh histedit.h missing <9407271449.AA25332@slueas.slu.edu> X-Notice: Do not redistribute in any form without prior explicit consent of the author. From: "Chris G. Demetriou" Sender: owner-current-users@sun-lamp.cs.berkeley.edu > Seems src/bin/sh/histedit.h is missing. 3 [sun-lamp] cgd % ls /usr/src/lib/libedit/histedit.h /usr/src/lib/libedit/histedit.h and it gets installed in /usr/include. cgd From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 05:26:14 1994 Subject: Re: /sys/doc/options.doc To: Julian.H.Stacey@regent.e-technik.tu-muenchen.de (Julian Howard Stacey) 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: 10841 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I suggest NetBSD might like to adopt something like > FreeBSD's /sys/doc/options.doc (by Garrett A. Wollman) > > While referencing my NetBSD-pc532 options (FASTLINKS etc), > I had to fall back to my i486-Freebsd /sys/doc/options.doc > > Luckily I have both BSDs, but some pc532 owners (& other NetBSD users) dont, > so those folk might appreciate /sys/doc/options.doc. Whilst trying to keep uptodate with such options, I wrote the following (pretty crud, I admit) perl script which you run on a config file and it tells you what each option does. For options that it doesn't know about, or that have been made obsolete, it will tell you. It doesn't check the validity of devices right now, and I've only setup the arrays for the i386 port, but it's a start that you could use. --- cut here --- file: unix/netbsd/checkconf #!/usr/bin/perl # # checkconf -- # check the validity of netbsd kernel config files # # Version 1.4, 940716. Luke Mewburn # 940518 simplistic script first whipped up # 940521 cleaned up output, updated tables, enhanced device checking. # 940522 tagged maxfdescs as obsolete # 940705 ISOFS is obsolete, use CD9660. added le0. # 940716 fixed up handling of whitespace between options # # constants # $MAX_COLS = 80; %machines = ( 'i386', 'Intel 386 or higher', ); %cpus = ( 'I386_CPU', '80386', 'I486_CPU', 'i486', 'I586_CPU', 'pentium', ); %options = ( 'MATH_EMULATE', 'floating point emulation', 'DUMMY_NOPS', 'make the kernel a little faster; will break on some machines', 'MACHINE_NONCONTIG','temporary kluge while adding support for non-contiguous physical memory', 'SWAPPAGER', 'paging of processes; REQUIRED', 'VNODEPAGER', 'caching of vnodes; REQUIRED', 'DEVPAGER', 'caching of devices; REQUIRED', 'DIAGNOSTIC', 'kernel diagnostics', 'KTRACE', 'system call tracing, a la ktrace(1)', 'FASTLINKS', 'store short symlinks in the inode instead of the filesystem', 'FIFO', 'FIFOs', 'SYSVMSG', 'System V-like message queues', 'SYSVSEM', 'System V-like semaphores', 'SYSVSHM', 'System V-like memory sharing', 'SHMMAXPGS', 'maximum pages for SYSVSHM, default = 1024 pages', 'SCSI', 'generic SCSI system', 'FFS', 'UFS', 'LKM', 'loadable kernel modules', 'XSERVER', 'machine is an X server', 'UCONSOLE', 'use console as X server', 'QUOTA', 'quotas in UFS', 'MFS', 'memory file system (shares memory and swap space)', 'NFSSERVER', 'Sun\'s Network File System - server', 'NFSCLIENT', 'Sun\'s Network File System - client', 'ISOFS', 'ISO 9660 file system, with Rock Ridge [OBSOLETE]', 'CD9660', 'ISO 9660 file system, with Rock Ridge', 'MSDOSFS', 'MS-DOS file system', 'LOFS', 'loopback filesystem [OBSOLETE]', 'NULLFS', 'null filesystem (incorporates lofs)', 'PORTAL', 'portal filesystem', 'PROCFS', 'proc filesystem', 'FDESC', '/dev/fd', 'KERNFS', 'kernel file system', 'IMP', 'XXX: some network protocol', 'INET', 'internet domain sockets', 'NS', 'xerox ns protocol', 'ISO', 'OSI', 'TPIP', 'XXX: some network protocol', 'EON', 'XXX: some network protocol', 'CCITT', 'x.25', 'HDLC', 'x.25 hdlc (needed by CCITT)', 'LLC', 'x.25 llc (needed by CCITT)', 'GATEWAY', 'packet forwarding', 'MULTICAST', 'multicast networking', 'MROUTING', 'multicast routing', 'DDB', 'kernel debugger', 'USER_LDT', 'user creatable i386 LDTs (for Wine Windows wemulator)', 'COMPAT_NOMID', 'NetBSD 0.8 compatibility (executable format?)', 'COMPAT_09', 'NetBSD 0.9 compatibility', 'COMPAT_43', 'BSD 4.3 compatibility', 'TCP_COMPAT_42', 'BSD 4.2 TCP/IP compatibility', 'SBPRO', 'SoundBlaster Pro', 'SETUIDSCRIPTS', 'Allow safe SetUID scripts', 'FDSCRIPTS', 'Allow execute-only scripts', ); # devices (master, controller, device, disk, and tape entries) %devices = ( 'isa0', 'PC clone ISA bus', 'wdc0', 'PC ST506/IDE controller', 'wd0', 'PC ST506/IDE disk 0', 'wd1', 'PC ST506/IDE disk 1', 'fdc0', 'PC floppy controller', 'fd0', 'PC floppy drive 0', 'fd1', 'PC floppy drive 1', 'aha0', 'Adaptec 154x ISA SCSI controller', 'ahb0', 'Adaptec 174x EISA SCSI controller', 'bt0', 'BusLogic 742 SCSI controller', 'uha0', 'UltraStor 14f SCSI controller', 'sea0', 'unknown Seagate SCSI controller', 'aic0', 'Adaptec 6360 EISA SCSI controller???', 'scsibus0', 'SCSI bus 0', 'scsibus1', 'SCSI bus 1', 'scsibus2', 'SCSI bus 2', 'scsibus3', 'SCSI bus 3', 'pc0', 'pccons console driver for PC keyboard & monitor', 'vt0', 'pcvt virtual multi-console driver PC keyboard & monitor', 'ast0', '4 port serial card', 'com0', 'serial port 0', 'com1', 'serial port 1', 'com2', 'serial port 2', 'com3', 'serial port 3', 'com4', 'serial port 4', 'lpt0', 'parallel port 0', 'lpt1', 'parallel port 1', 'lpt2', 'parallel port 2', 'mms0', 'microsoft InPort bus mouse', 'lms0', 'logitech mouse', 'pms0', 'PS/2 auxiliary port', 'wt0', 'non-scsi tape drive', 'mcd0', 'mitsumi non-scsi CDROM', 'sb0', 'sound blaster', 'ed0', 'wd 80x3, 3com 3c503, ne[12]k ethernet', 'ed1', 'wd 80x3, 3com 3c503, ne[12]k ethernet #2', 'ed2', 'wd 80x3, 3com 3c503, ne[12]k ethernet #3', 'hp0', 'hp ISA ethernet', 'is0', 'isolan ethernet', 'ie0', 'intel 82586 ethernet', 'le0', 'lance ethernet', 'ep0', '3com 3c579? ethernet', 'ep1', '3com 3c579? ethernet #2', 'ep2', '3com 3c579? ethernet #3', 'npx0', '80x87 numeric co-processor', 'sd0', 'SCSI disk 0', 'sd1', 'SCSI disk 1', 'sd2', 'SCSI disk 2', 'sd3', 'SCSI disk 3', 'sd4', 'SCSI disk 4', 'sd5', 'SCSI disk 5', 'sd6', 'SCSI disk 6', 'st0', 'SCSI tape 0', 'st1', 'SCSI tape 1', 'st2', 'SCSI tape 2', 'cd0', 'SCSI CDROM 0', 'cd1', 'SCSI CDROM 1', 'ch0', 'SCSI tape changer 0', 'ch1', 'SCSI tape changer 1', ); %pseudo_devices = ( 'pty', 'pseudo terminals', 'loop', 'loopback inet interface', 'ether', 'ethernet; REQUIRED for any ethernet device', 'log', 'kernel gateway into syslogd', 'bpfilter', 'berkeley packet filter', 'sl', 'compressed SLIP', 'ppp', 'point-to-point protocol', 'vn', 'vn virtual filesystem device', 'speaker', 'speaker queue', 'tb', 'tablet line discipline', 'tun', 'XXX: unknown', 'audio', '/dev/audio', ); # # changable entries # %geninfo = (); @cpuinfo = (); %optinfo = (); %devinfo = (); %pdevinfo = (); # # slurp in the file # while (<>) { chop; next if $_ eq ""; # skip blank lines next if /^#/; # skip full comment lines s/#.*//; # remove extra comments local($cmd, $arg, @rest) = split; $arg =~ s/"//g; # remove quotes ENTRY: { $cmd eq "machine" && do { print "machine already specified as $geninfo{'machine'}\n" if defined($geninfo{'machine'}); $geninfo{'machine'} = $machines{$arg} || ($arg . " [UNDEFINED]"); last ENTRY; }; $cmd eq "cpu" && do { push(@cpuinfo, $cpus{$arg} || ($arg . " [UNDEFINED]")); last ENTRY; }; $cmd eq "ident" && do { print "ident already specified as $geninfo{'ident'}\n" if defined($geninfo{'ident'}); $geninfo{'ident'} = $arg; last ENTRY; }; $cmd eq "maxusers" && do { print "maxusers already specified as $geninfo{'maxusers'}\n" if defined($geninfo{'maxusers'}); $geninfo{'maxusers'} = $arg; last ENTRY; }; $cmd eq "maxfdescs" && do { print "maxfdescs already specified as $geninfo{'maxfdescs'}\n" if defined($geninfo{'maxfdescs'}); print "maxfdescs has been obsoleted. Please remove it from your config file.\n"; $geninfo{'maxfdescs'} = $arg; last ENTRY; }; $cmd eq "timezone" && do # XXX: improve { $geninfo{'timezone'} = $arg . ' ' . join(' ',@rest); last ENTRY; }; $cmd eq "options" && do { $arg .= join(' ',@rest); # add in any options that had whitespace $arg =~ s/\s+//g; # remove whitespace local(@opts) = split(',', $arg); foreach $option (@opts) { local($argname, $argval) = split('=', $option); $argval = " = " . $argval if (defined($argval)); $optinfo{$argname} = $argval; } last ENTRY; }; $cmd eq "config" && do # XXX: improve { print "config already specified as $geninfo{'config'}\n" if defined($geninfo{'config'}); $geninfo{'config'} = $arg . ' ' . join(' ',@rest); last ENTRY; }; $cmd =~ /^(master|controller|device|disk|tape)$/ && do { $devinfo{$arg} = join(' ', @rest); last ENTRY; }; $cmd eq "pseudo-device" && do { local($val) = " = " . $rest[0] if (defined($rest[0])); $pdevinfo{$arg} = $val; last ENTRY; }; print "Unknown directive: $cmd\n"; } # ENTRY } # while # # print the config file's innermost secrets :) # grep ((do {$geninfo{$_} = "undefined" unless defined($geninfo{$_})} ), ('machine', 'ident', 'maxusers', 'timezone', 'config')); $cpuinfo = join(' ', @cpuinfo); print < > >Date: Tue, 26 Jul 1994 12:31:36 -0400 > >From: Bill Squier > > >A while ago there was some talk of developing a hardware independant > >audio library. Since my roommate and I are about to embark on a > >driver for the Windows Sound System (retch) I thought it a good idea > >to figure out the status of this (if any). > > I made noises about a WSS and/or PSS (Cardinal, Orchid, &c.) driver, > but I didn't do anything. I may do something when 1.0 arrives, and I > have a stable platform to work with. I have been thinking about a pss driver, and it has left me with more questions than answers. Things like the mcd and midi controllers need to be enabled by the sound card, yet they really exist independently of the sound functionality. So during autoconfig, the pss driver needs to decide what port address an irq lines these things get, then wait for separate drivers, such as the existing mcd driver, to find them. In a way, these devices are children of the pss, yet the device drivers should act as if they are directly connected to the isa bus -- since they are. If you want to use the dsp for number crunching while playing linear samples, the best thing to do is connect the ad1848 to the isa bus in wss mode. If you then decide to generate two channels of audio output on the dsp, you need to leave wss mode. There does not seem to be any support for bringing devices on and off line arbitrarily (as you might want to do with a pss-wss driver). Should there be? Jason From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 28 05:38:18 1994 From: Berend Ozceri To: amiga@sun-lamp.cs.berkeley.edu Subject: First time NetBSD installation... Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hello everyone, I am about to attempt to install NetBSD on my A4000/040/IDE. Are there any installation FAQs lying around? I would appreciate if somebody could at least give me some guidelines as to how to install the beast... Thanks, Berend Ozceri Carnegie Mellon University From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 06:21:21 1994 From: Peter Galbavy Subject: GET THIS BOOK :) To: current-users@sun-lamp.cs.berkeley.edu Cc: people@wonderland.org X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1082 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Just for those amongst you who have the tollerance to satire and the time, get this book: The UNIX Haters Handbook Simson Garfinkel, Daniel Weise & Steven Strassmann Publisher: IDG Books ISBN: 1-56884-203-1 This is a wonderfully caustic look at UNIX and the like, with section titles like "UNIX - The world's first computer virus" and "The Motif Self Abuse Kit". It is based on the UNIX-HATERS mailing list, which I am immediately off to join (anyone got the subscription deatils ?). I hope you can all laugh at *yourselves* (me included), since it is *very* critical, but with humour. I got a pre-press UK copy. I guess it out in the US. I have been ROTFL since I got it, and laughing out loud on the bus home from work is not looked upon well in this country... sigh. (Pls note this is cc'ed to another mailing list so be careful of reply-to addresses). Regards, -- Peter Galbavy work: peter@demon.co.uk Wonderland rest: peter@wonderland.org play: http://www.wonderland.org/ "The 'net interprets censorship as damage and routes around it." - John Gilmore From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 06:43:29 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, peter@alice.wonderland.org Subject: Re: GET THIS BOOK :) Sender: owner-current-users@sun-lamp.cs.berkeley.edu It is based on the UNIX-HATERS mailing list, which I am immediately off to join [...] You have to write a vicious flame about Un*x to get on the list. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 06:50:01 1994 From: Source Librarian Subject: Just upgraded, and... 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: 702 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just upgraded a machine of ours from 0.9 (release) to -current (7/13 + kernel compiled from sources sup'd from last night), and I have a question.... Does -current su work differently than 0.9's su? Right now, I'm having trouble su'ing to root from another account, even if the that user is also in the wheel (gid 0) group. su keeps telling me: su: you are not in the correct group to su root. Example: I have a user named fred, whose default group is staff. I also placed the user fred in the wheel group. -current's su won't let me su to root from fred's account. -Henry (src@bsginc.com) BTW, is it safe for me to update my bootblocks if my root filesystem is still 4.2BSD (level 1)? From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 06:50:10 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: bugs@sun-lamp.cs.berkeley.edu Subject: SLIP/PPP crashes From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu My co-worker and I share a Zenith 386/25 in our office that we use for a SLIP/PPP server. He has an internal 14.4k modem with a built-in 16550 in it, and I have a 16550 board in the machine connected to my 28.8k external modem. The machine had like 73 days uptime when he was using it alone until recently, and was running NetBSD-"current" from the beginning of the year. Once we added my serial board to the machine, we had to build a new kernel, so we upgraded it to current as of a few weeks ago. It seems to work just fine for us when traffic is light. However, it seems like every time I try to sup, I hang the machine hard. I don't know why, but supping current from sun-lamp seems to be what breaks it. Maybe because it's just non-stop heavy TCP traffic in both directions. Anyway, normal traffic doesn't seem to do it, but it seems to happen every single time I try to sup from sun-lamp. He built the kernel that we tried first, and this stuff was happening. So, I build a kernel on my machine, from the source tarballs of the 17th. The exact same thing happens from the kernel I build. My machine at home doesn't crash, but the machine routing the traffic in our office does. It doesn't matter whether I'm using SLIP or PPP, it happens either way, indicating to me it's not actually in the SLIP/PPP code, but is somewhere else. We don't have DDB built into the kernel there, because we wanted the machine to just reboot if it ever crashed. Unfortunately, the nature of these crashes just causes it to hang solid, so I have to go drive to campus to fix it. :-( Here's what I see on the display when it's hung... With the kernel from the beginning of the month built on explorer's box: vm_fault(f818d90c, 0, 1, 0) -> 5 fatal page fault in supervisor mode trap type 6 code f8100000 eip f8100ff9 es f7bf0008 eflags 13292 cr2 f0 cpl ffffffff panic: trap With the kernel from the 17th tarballs, built on my machine: vm_fault(f81cf2c8, 0, 1, 0) -> 5 fatal page fault in supervisor mode trap type 6 code f8100000 eip ... cs ... eflags 13286 cr2 f0 cpl ffffffff (Both times it looked like it had scrolled a ton of these on the display before finally hanging. In the second example, it looked like the previous messages all had eflags 13282 in them, until the final one that hung tight which had the eflags 13286.) Does this make any sense to anyone? I'm going to try to build a new kernel with this weekend's tarballs, but I have a feeling it's not going to make any difference, since I haven't seen any report of anything affecting this lately. Is this enough information to track down any bugs with? Has anyone heard of anything that might affect this? I'd love to kill this bug so I can have a stable net connection. ----------------------------------------------------------------------------- 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 Jul 28 06:50:14 1994 From: Dave Burgess Subject: Re: Find a way for a monthly distribution To: cgd@alpha.bostic.com (Chris G. Demetriou) Cc: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 583 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > [ ... much on monthly releases deleted... ] > What you release today isn't worth a whit if it isn't a viable > platform _tomorrow_, because people are going to run it _then_. > Finally, something that I feel qualified to speak on. I am a Configuration Manager by trade; have been for about 15 years. If one of the programmers at my shop were to come in and tell me that they wanted to do monthly releases on ANY of our systems, regardless of the complexity, I would personally kick them in the head. The SHORTEST time I will consider for a regular release is semi-annual. From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 07:21:59 1994 From: "Charles M. Hannum" To: current-users@sun-lamp.cs.berkeley.edu Subject: UltraStor 24f Sender: owner-current-users@sun-lamp.cs.berkeley.edu So does anyone actually have one of these boards? Could you send me mail? From owner-current-users@sun-lamp.cs.berkeley.edu Thu Jul 28 08:08:49 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: Peter Galbavy Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: GET THIS BOOK :) Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>> Peter Galbavy writes: > It is based on the UNIX-HATERS > mailing list, which I am immediately off to join (anyone got the > subscription deatils ?). as a member of the list since before all this silly talk of the book, i can say by word of the current unix-haters czar, the list is off at the moment, and will be until all the book nonsense dies down. the traditional way of gaining membership is post an almost unspeakable flame to the unix-haters-request list and the czar will decided if you are worthy. -bri From owner-amiga-dev@sun-lamp.cs.berkeley.edu Thu Jul 28 08:30:56 1994 From: William J Coldwell To: zcjc1121@rpool1.rus.uni-stuttgart.de (Tobias Abt) Subject: Re: ADOSFS Cc: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu >Just one little bug that I have encountered: >if you try to mount an ADos partition which has been set to something >else but 512 bytes per block, the filesystem will not be visible. This is not true. I have multiple partitions that are not 512 byte ADOS filesystem format. >So, the setting in the RDB for that partition (not the RDSK but the >PART) has to be looked at. I didn't have the time yet to look into >the sources but I hope this is not too hard to achieve. If I get my own >kernel compiled, I may have a look at it on my own. What I believe is the problem, is that there is a rounding difference between what the ADOS filesystem thinks your DOS root block is, and what ADOSFS thinks it is. I have 2 partitions that will not mount correctly (giving me a checksum error under NBSD), that work perfectly under ADOS. One more! :-) >Why does df say that there are only two blocks on the ADos-partition? Because right now, it's read-only. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Thu Jul 28 11:00:14 1994 From: "Hubert Feyrer" "First time NetBSD installation..." (Jul 27, 10:47pm) X-Mailer: Z-Mail (3.0.1 04apr94) To: Berend Ozceri , amiga@sun-lamp.cs.berkeley.edu Subject: Re: First time NetBSD installation... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 27, 10:47pm, Berend Ozceri wrote: > I am about to attempt to install NetBSD on my A4000/040/IDE. Are there > any installation FAQs lying around? I would appreciate if somebody could > at least give me some guidelines as to how to install the beast... Look into /pub/NetBSD-Amiga/DOCS on ftp.uni-regensburg.de and also read the README-File that comes with the bin-distribution. 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 Jul 29 00:56:38 1994 From: Paul Mackerras To: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: SLIP/PPP crashes Sender: owner-current-users@sun-lamp.cs.berkeley.edu Michael VanLoon wrote: > Does this make any sense to anyone? I'm going to try to build a new > kernel with this weekend's tarballs, but I have a feeling it's not > going to make any difference, since I haven't seen any report of > anything affecting this lately. We did fix a bug in sys/net/if_ppp.c recently, about a week ago (and then we fixed a bug in the fix just a day or so ago, thanks to osymh@gemini.oscs.montana.edu). The bug was that the ppp code was writing past the end of mbufs if it couldn't get cluster mbufs. Try getting a new if_ppp.c from sun-lamp and see if it fixes your problem. Paul Mackerras. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 29 01:09:25 1994 From: Andrew Cherry To: amiga@sun-lamp.cs.berkeley.edu Subject: System lockups with newer kernels Sender: owner-amiga@sun-lamp.cs.berkeley.edu I've been having problems with my system locking up completely at seemingly random times. It seems to be related to disk activity; for example, when emacs autosaves a large file (my mbox :) ), or when any other major disk activity occurs. I have an A2000, GVP G-Force 040. Sync is enabled, but this happens with sync disabled as well. The problem dates back to the 940709 generic kernel; I don't know if it goes back any further than that, since I don't have any earlier kernels. Changes specfic to my system are: gtsc_maxdma = 512 (largest value I can use to get reliable serial transfers) sbic_inhibit_sync = 0 (I've tried 1 too) The more recent kernels were compiled without the new ethernet card entry, because of the problems that caused. Also, the 940709 kernel I tried is from the 940709 binary snapshot (i.e. not compiled by me). I've heard at least one other report of problems with SCSI lockups; has anyone else had these problems or have any insights into them? -Andrew Cherry (cherry@planet.net) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Jul 29 01:29:02 1994 From: "Hubert Feyrer" X-Mailer: Z-Mail (3.0.1 04apr94) To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Bug in adosfs Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I tried mounting ADOS-FS under a given UID using the "-u" switch to mount_ados. This didn't work propperly: I was able to do a "ls -la /amiga" and it showed the right owner & group, but when I cd'd to /amiga and dia a "ls -la", this was no longer possible. After some digging in the source, I found out that the variable "mask" isn't initialized in adosfs_access() (file: ados/advnops.c), which shows only up if you don't access the AmigaOS-partition as root. Maybe someone can check this into the current sources? Thanks! 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 Fri Jul 29 01:35:56 1994 From: "Hubert Feyrer" X-Mailer: Z-Mail (3.0.1 04apr94) To: amiga-x@sun-lamp.cs.berkeley.edu Subject: Request: color servers, XView Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Tonight I tried the two color-servers and found out they still work with 940709, but the 16-color-server is (still ;) broken. Could someone compile them for -current? Would be nice. Besides that, has anyone tried out XView on -current? I didn't, but it would be fine to have this ready for 1.0, too. :-) Hubert P.S.: 940709 & X run very smoothly on a A2k with 6(!)MB RAM, very few paging! Great work!!! :-) -- =============== 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 Fri Jul 29 04:39:21 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: Request: color servers, XView To: c9020@rrzc1.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: 597 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu > Tonight I tried the two color-servers and found out they still work with 940709, > but the 16-color-server is (still ;) broken. Could someone compile them for > -current? Would be nice. I don't think Olivier Lahaye left us with source, so we're kinda stuck with what we've got. > Besides that, has anyone tried out XView on -current? I didn't, but it would be > fine to have this ready for 1.0, too. :-) Oh yeah, you were the other one who wanted XView... Just for you, I put this file on ftp.uni-regensburg.de: -rw-rw-r-- 1 ftp ftpadmin 1732420 Jul 29 01:50 xview32-26Jun94.tar.gz From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Jul 29 06:11:19 1994 From: Greg Oster Subject: Re: Request: color servers, XView To: ahh@netcom.com (Andy Heffernan) 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: 848 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Andy Heffernan writes: > > > Tonight I tried the two color-servers and found out they still work with 940709, > > but the 16-color-server is (still ;) broken. Could someone compile them for > > -current? Would be nice. > > I don't think Olivier Lahaye left us with source, so we're kinda stuck > with what we've got. Actually, the source is ftpable from colombo.telesys-innov.fr: /pub/amiga/NetBSD/X11R5/mit.tar.gz It will probably take a fair bit of work to get the servers running - I think they were developed using the 713/714 or 744 version of the kernel (or perhaps even earlier..), and I'd bet the kernel internals have changed at least a little since then ;-) :-) 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 Fri Jul 29 07:36:55 1994 From: Mark F Willey Subject: Kermit woes - my story To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 575 Sender: owner-current-users@sun-lamp.cs.berkeley.edu All, I've been having similar problems to y'all WRT Kermit. When I try to set line /dev/com0, it waits forever. It will go through if I send it a signal. Then, it will connect as usual, but it will only look like garbage on the screen. I use it with /dev/com2, a hardwired cable, and it works fine. The /dev/com0 is an internal 14400 modem w/ a 16550. The com2 is a 16450. Kermit is suid to uucp, and /dev/tty0? is rw only for uucp. What does everyone else do to get it to work? BTW, my tty00 has the clocal flag appended in /etc/ttys ie "on secure clocal" Mark From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 08:24:56 1994 From: surprenc@jsp.umontreal.ca (Surprenant Colin) Subject: Bootstraping current installation To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 771 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, My drive which was holding current just went dead :( and I have some questions to help me resetup current. I have another drive on which I want to re-install current (1.0-alpha). My latest backup was made using dump on a 4.3 filesystem. Ok, now, my question is, what would be the best way for me to re-install current and restore my backup. Has anybody made bootable floppy images anywhere with current? If no, should I use the 0.9 bootables, and bootstrap from there? Last question: my filesystem was 4.3 when I made the backup using dump, will I be able to do a restore on a 4.4 filesystem? Thanx, -- | Colin Surprenant | colin@connex.interlink.net | | 514-849-0948 | -------------------------- | | Montreal, Quebec | surprenc@jsp.umontreal.ca | From owner-amiga-dev@sun-lamp.cs.berkeley.edu Fri Jul 29 10:52:37 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu (NetBSD-Dev) Subject: Re: ADOSFS Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu Tobias Abt said: >>Just one little bug that I have encountered: >>if you try to mount an ADos partition which has been set to something >>else but 512 bytes per block, the filesystem will not be visible. Like an idiot, I said: >This is not true. I have multiple partitions that are not 512 byte ADOS >filesystem format. I was wrong.. so very wrong. Chris looked through the code tonight, and did indeed find that if you have an ADOS partition that != 512 byte blocks, it will not mount it properly. This will most likely not make it into the 1.0 release either. The good part is that it doesn't affect most people, the bad part is that those who are affected have no solution. >>So, the setting in the RDB for that partition (not the RDSK but the >>PART) has to be looked at. I didn't have the time yet to look into >>the sources but I hope this is not too hard to achieve. If I get my own >>kernel compiled, I may have a look at it on my own. >What I believe is the problem, is that there is a rounding difference >between what the ADOS filesystem thinks your DOS root block is, and what >ADOSFS thinks it is. I have 2 partitions that will not mount correctly >(giving me a checksum error under NBSD), that work perfectly under ADOS. It is hard to acheive, which is why it probably won't make it in the release :-(. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Jul 29 10:56:00 1994 From: "Hubert Feyrer" "Re: Request: color servers, XView" (Jul 28, 6:56pm) X-Mailer: Z-Mail (3.0.1 04apr94) To: ahh@netcom.com (Andy Heffernan), amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Request: color servers, XView Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu I take back everything what I've previously said about XView and state the opposite. :-> Andy just uploaded a new version of XView, I've moved it to contrib/BSD/X11 on ftp.uni-regensburg.de: -rw-rw-r-- 1 bsdadmin ftpadmin 1732420 Jul 29 03:50 xview32-26Jun94.tar.gz Thanks Andy! :) 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 Fri Jul 29 20:45:58 1994 From: Philippe BRAND Subject: Re: Request: color servers, XView To: oster@skdad.usask.ca (Greg Oster) Cc: amiga-x@sun-lamp.cs.berkeley.edu (NetBSD Liste) Organization: Telesystemes Phone: +33-1-46145298 Operating-System: SCO Open Server Enterprise v3.0 X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 631 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Greg Oster writes: > > I don't think Olivier Lahaye left us with source, so we're kinda stuck > > with what we've got. > > Actually, the source is ftpable from colombo.telesys-innov.fr: > /pub/amiga/NetBSD/X11R5/mit.tar.gz Olivier Lahaye made the RETINA part. Olivier Raoul made the ECS colour version. Problem is that both of them are in the army now. In France the army keeps you for one month then after that depending on your "official supports", you can go wherever you want so they should come back pretty soon. I'll keep inform on that. -- Philippe BRAND phb@colombo.telesys-innov.fr RAMSES BBS Co-Sysop 2:320/104.21 From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Jul 29 20:46:45 1994 From: "Hubert Feyrer" "Re: Request: color servers, XView" (Jul 28, 6:56pm) X-Mailer: Z-Mail (3.0.1 04apr94) To: ahh@netcom.com (Andy Heffernan), amiga-x@sun-lamp.cs.berkeley.edu Subject: Re: Request: color servers, XView Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu On Jul 28, 6:56pm, Andy Heffernan wrote: > > Tonight I tried the two color-servers and found out they still work with > > > > 940709, > > but the 16-color-server is (still ;) broken. Could someone compile them for > > -current? Would be nice. > > I don't think Olivier Lahaye left us with source, so we're kinda stuck > with what we've got. No, the source is there! It's in contrib/bsd/X11/mit.tar.gz on ftp.uni-regensburg.de, but I'd like to get this compiled by some competent person. ;-) > > Besides that, has anyone tried out XView on -current? I didn't, but it would be > > fine to have this ready for 1.0, too. :-) > > Oh yeah, you were the other one who wanted XView... Ugh, really??? Can't remember! :-> > Just for you, I put this file on ftp.uni-regensburg.de: > -rw-rw-r-- 1 ftp ftpadmin 1732420 Jul 29 01:50 xview32-26Jun94.tar.gz Yes, but does it still run with 940721? I can't check out right now! :-( Hubert -- =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, D-93053 Regensburg, Tel. 0941/701788 Weekends: Bachstr. 40, D-84066 Mallersdorf, Tel. 08772/6084 Internet: hubert.feyrer@rz.uni-regensburg.de == IRC: hubertf ========================================================================== Click here. From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Jul 29 21:01:53 1994 From: ahh@netcom.com (Andy Heffernan) Subject: Re: Request: color servers, XView To: c9020@rrzc1.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: 693 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu [...] > > I don't think Olivier Lahaye left us with source, so we're kinda stuck > > with what we've got. > > No, the source is there! It's in contrib/bsd/X11/mit.tar.gz on > ftp.uni-regensburg.de, but I'd like to get this compiled by some competent > person. ;-) If I find one I will let you know, but in the mean time, I will see if I can do anything with the code. [...] > > Just for you, I put this file on ftp.uni-regensburg.de: > > -rw-rw-r-- 1 ftp ftpadmin 1732420 Jul 29 01:50 xview32-26Jun94.tar.gz > > Yes, but does it still run with 940721? I can't check out right now! :-( It runs with what I'm running now, which is from source fetched on 22 July, so it should be OK. From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 29 21:03:55 1994 From: William J Coldwell To: amiga@sun-lamp.cs.berkeley.edu Subject: Important information. READ. Sender: owner-amiga@sun-lamp.cs.berkeley.edu As the NetBSD-Amiga 1.0 release loomed ever closer, things were undoubtly going to have to change. Unfortunantly, it's going to require some people to do some more work. Now, before you read any further, I would like for you to understand, that I (any many others) do appreciate everything that _you_ have done. This could be from simply installing a release of NetBSD, to running a mirror FTP site, to writing documentation, to helping someone else get NetBSD running, to actually making changes to the kernel, to just subscribing to the list and giving a vote of confidence in the whole port. Now that I have that out of the way, I'm going to step on your toes. This may piss you off, and it may make you think nasty thoughts about me, (like having my head in a vice, with you tightening it until my brains dribble out of my nose and ears...) BUT, in the long run, this will make lots of things easier.. it will! * Achivers, please take note. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In order to facilitate a clean installation procedure, please move all existing archives that do not work under -current/-release to an OLD directory of some sort. This includes DOCS that have not been updated for -current/-release, as they give WRONG information in some cases. The requirement in mirroring sun-lamp, is that you maintain the same directory structure for consistancy. tools (REQUIRED) snapshot (REQUIRED) [any other directories on sun-lamp/arch/amiga) OLD [NetBSD-Amiga_0.9c?] + contrib + binaries + [possibly a catagory listing, e.g., shells, utils, etc] + sources + X11R5 + binaries + sources + ( + = optional directories for your local archive (a suggestion)) PLEASE PLEASE PLEASE, move all older kernels. We need this done to facilitate the FAQ, so that users don't have to try to guess what stuff they need, and where to find it. If you do not abide by these requirements, I will not have your site listed as a mirror in the Installation FAQ, and it would just be a "bad thing(tm)". * Current Users, please take note. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We can *not* be in a position of supporting any kernels before -release, for a multitude of reasons. The first and foremost, is that we want everyone to upgrade to -release, especially if you have been running -current. # If you are running outdated kernels of .744 and before, you will not be # supported at all. As we move to NetBSD-Amiga 1.0 release, I want to focus on a clean install. This means that it's best (not _required_) to recompile all of your local binaries. It also means that you should back up your important configuration files in /etc, and mail, etc before installing the new binaries/kernel - or you can just upgrade your existing setup.. really, it's up to you. I'm working on the Installation doc, and should have it available shortly (hopefully done this weekend). Now, I will attempt to answer your questions once my mailbox stops smoking ;-). Cheers. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga-x@sun-lamp.cs.berkeley.edu Fri Jul 29 21:08:52 1994 Subject: Xamiga Server for X11R6 To: amiga-x@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit From: erbe0011@fh-karlsruhe.de (Bernd Ernesti) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 103 Sender: owner-amiga-x@sun-lamp.cs.berkeley.edu Hello, does anyone has started to change the source for the Server to compille it with X11R6 ? Bernd From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 29 21:21:47 1994 From: Operator To: amiga@sun-lamp.cs.berkeley.edu Subject: This week's NetBSD/amiga changes Sender: owner-amiga@sun-lamp.cs.berkeley.edu Below is a summary of changes that were committed in the last week. This is an automated message. Please send any comments to tsarna@endicor.com --------------------------------- chopps Tue Jul 26 10:51:21 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/f/users/chopps/cur/amiga/dev Modified Files: if_ed.c Log Message: fix check in edintr(), do not deref NULL pointer. --------------------------------- cgd Tue Jul 26 11:21:48 PDT 1994 Update of /b/source/CVS/src/sys/arch/sparc/sparc In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/sparc/sparc Revision/Branch: netbsd-1-0 Modified Files: swapgeneric.c Log Message: from trunk. cgd Tue Jul 26 11:24:53 PDT 1994 Update of /b/source/CVS/src/sys/arch/amiga/dev In directory sun-lamp.cs.berkeley.edu:/usr/src/sys/arch/amiga/dev Revision/Branch: netbsd-1-0 Modified Files: if_ed.c Log Message: from trunk. cgd Tue Jul 26 11:27:33 PDT 1994 Update of /b/source/CVS/src/etc/etc.pc532 In directory sun-lamp.cs.berkeley.edu:/usr/src/etc/etc.pc532 Revision/Branch: netbsd-1-0 Modified Files: MAKEDEV Log Message: from trunk --------------------------------- From owner-amiga@sun-lamp.cs.berkeley.edu Fri Jul 29 21:36:18 1994 From: Berend Ozceri To: amiga@sun-lamp.cs.berkeley.edu Subject: Problems... Sender: owner-amiga@sun-lamp.cs.berkeley.edu First of all, thanks to everybody who replied to my help-me-I-am-a-first-time-netbsd-installer message. It ended up that I got pretty much everything going in one try... Anyway, I installed the rootfs, untarred all the 940721 distribution binaries. I am running the netbsd.generic-940723 kernel (this is included in the floppy distribution) and have also tried the netbsd-almostgeneric.940721 kernel. My system is an A4000/040/IDE. Under both kernels, when I boot netbsd everything goes fine and I get the shell prompt in single-user mode. At this point most of the binaries work fine (things like ls, cp, cd, mount, mount_ados, etc.) but many other things give me a "Floating exception (core dumped)". For example, "more" will give me that exception. I think I have everything setup right (I have /usr/libexec). What is the problem? Also, isn't fastboot (or the sequence umount -av; sync; reboot) supposed to reboot to the Amiga side? In my case it attempts to reboot, but gets stuck with a gray screen. No matter how many times I do a ctrl-amiga-amiga, I get stuck with the same gray screen, leaving me with no choice but to power-cycle the Amiga. Needless to say, haveing to powercycle the Amiga every ten minutes does not amuse me. Any help? Thanks, Berend Ozceri Carnegie Mellon University From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 21:57:43 1994 From: "J.T. Conklin" To: cgd@alpha.bostic.com ("Chris G. Demetriou") Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Adaptec 1742 Problems with -current 16. July Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > I upgraded my EISA Box from an AHA1542 to an 1742 and > > consequently use now the ahb-driver. Now I cannot use my > > Exabyte anymore. I probes incorrect as drive empty, and read > > or write attempts fail sometimes, often I get 0 bytes with no error > > when there is definitely data on the tape. The same configuraton > > worked with the 1542 with no flaws. > > Hmm. I've never tried the 1742 with an exabyte, but i know it works > fine on, e.g. the DAT on sun-lamp... > > I could believe it doesn't work -- Exabytes are weird... Several people have mentioned problems with Exabytes & 1742's, there was even a PR on it. Unfortunately, I was never able to reproduce the problem with the Exabyte drive I sometimes borrowed from Kaleida. I'm sorry I can't be of more help, --jtc From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 22:11:49 1994 From: Scott Reynolds Subject: Re: Kermit woes - my story To: Mark F Willey Cc: current-users Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Thu, 28 Jul 1994, Mark F Willey wrote: > Kermit is suid to uucp, and /dev/tty0? is rw only for uucp. > > What does everyone else do to get it to work? 1) Get C-Kermit 5A(190) from kermit.columbia.edu:/kermit/test/bin/cku190.tar.gz 2) Apply the appended patch. 3) Compile with "make bsd44 KFLAGS=-DNOCOTFMC" --scott *** ckutio.c.ORIG Wed Jul 27 10:36:32 1994 --- ckutio.c Wed Jul 27 10:36:08 1994 *************** *** 7177,7182 **** --- 7177,7187 ---- * set-UID. */ + #ifndef __NetBSD__ #define switchuid(hidden,active) setuid(active) #define switchgid(hidden,active) setgid(active) + #else + #define switchuid(hidden,active) seteuid(active) + #define switchgid(hidden,active) setegid(active) + #endif #endif /* SETREUID */ From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 22:30:44 1994 From: matthieu@laas.fr (Matthieu Herrb) To: current-users@sun-lamp.cs.berkeley.edu Subject: pcvt keycap entry for french 102 keys keyboard. X-Organization: LAAS-CNRS Toulouse, France X-Phone: (33) 61 33 63 30 Content-Length: 1219 Sender: owner-current-users@sun-lamp.cs.berkeley.edu In order to test pcvt with with my french keyboard, I've put together this keycap entry. I also have a modified pccons.c that selects the french keyboard layout and displays iso 8859-1 8 bits characters in the kernel config file (option FRENCH_KBD) . I'll submit it if there's an interest. It will need to be completed for other national keyboards. ---8<--- Cut Here ---8<--- # From Matthieu Herrb # For 102 keys keyboards, produces 8 bits characters # with ISO Latin-1 encoding f8|france-iso-8859-1|French ISO 8859-1 102 keys keyboard:\ :l1#62:\ :K1=\262:S1=:\ :K2=&:S2=1:\ :K3=\351:S3=2:C3=\211:A3=~:\ :K4=":S4=3:A4=#:\ :K5=':S5=4:A5={:\ :K6=(:S6=5:A6=[:\ :K7=-:S7=6:C7=\036:A7=|:\ :K8=\350:S8=7:C8=\210:A8=`:\ :K9=_:S9=8:C9=\037:A9=\\:\ :K10=\347:S10=9:C10=\207:A10=\136:\ :K11=\340:S11=0:C11=\340:A11=@:\ :K12=):S12=\260:A12=]:\ :A13=}:\ :K17=a:S17=A:C17=\001:\ :K18=z:S18=Z:C18=\032:\ :D27:\ :K28=$:S28=\243:\ :K29=*:S29=\265:\ :K31=q:S31=Q:C31=\021:\ :K40=m:S40=M:C40=\015;\ :K41=\371:C41=\231:S41=%:\ :K42=*:S42=\265:\ :K46=w:S46=W:C46=\027:\ :K52=,:S52=?:\ :K53=;:S53=.:\ :K54=\072:S54=/:C54=\037\ :K55=!:S55=\266: ---8<--- Cut Here ---8<--- Matthieu From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 22:35:37 1994 From: lburns@cats.ucsc.edu (Len Burns) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: Another Serial Port Question Sender: owner-current-users@sun-lamp.cs.berkeley.edu First, I must say i upgraded to current from 0.9b using source supped on Sunday Jul 24 and the upgrade went with nothing more than minor glitches. Very impressive the changes. I am running current on a 66 mhz 486 16 megs ram and 4 16550a serial ports. I have 2 questions for those more leanred than I. First,I am using a ppp line on tty01 set at 38400 baud with crtscts. It is working smoothly, but when the load average on the system begins to rise, anything above around .5 I begin receiving silo overflow messages. The machine recovers fine, no crashes like it used to do but it does hamper through put considerably. I am wondering about possible solutions to this. I have considered a serial addaptor with more buffering and am wondering if anyone has experience with such a device. My second question is asked all to frequently here, but I still seem unable to solve it. On tty02 I have a dial up modem. The ttys line is tty02 "/usr/libexec/getty std.38400" vt100 on rtscts The associated gettytab entry is std.38400|38400-baud:\ :sp#38400:np: The modem answers normally, the login prompt comes up and the moment I hit return after entering a login I get garbage. I have tried playing with the com settings on the communications program I am using for a terminal with no success. It is note worthy perhaps that tty00 is a local line connected via a null modem cable to another machine that acts as a terminal. This line performs admirably. The only differenct is that it is at 57600 baud. Any suggestionws are highly welcomed. I have endeavored to provide the critical information to give the picture and am hoping I have not missed anything essential. Thanks. -Len From owner-current-users@sun-lamp.cs.berkeley.edu Fri Jul 29 22:43:26 1994 From: Mike Long To: willey@ecn.purdue.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: Kermit woes - my story Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >From: Mark F Willey >Date: Thu, 28 Jul 1994 21:39:46 -0500 (EST) > >When I try to set line /dev/com0, it waits forever. It will go through if >I send it a signal. First of all, don't use the /dev/com? devices; use /dev/tty0? instead. If the /dev/com? symlinks still exist, delete them. >Kermit is suid to uucp, and /dev/tty0? is rw only for uucp. > >What does everyone else do to get it to work? Did you replace the calls to setuid() and setgid() to seteuid() and setegid() respectively in ckutio.c? >BTW, my tty00 has the clocal flag appended in /etc/ttys ie "on secure >clocal" Here is the source of your problem. Replace "clocal" with "local". ttydefaults(8) ignores flags that it doesn't recognize. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 00:32:50 1994 To: apana-lists-os-netbsd-general@apana.org.au Path: not-for-mail From: nick@lsupoz.apana.org.au (Nikolas Daglis) Newsgroups: apana.lists.os.netbsd.general Subject: BSD CD-ROM in sydney. Organization: Linux Support OZ +61-2-418-8750 Lines: 6 X-Newsreader: TIN [version 1.2 PL2] Sender: owner-current-users@sun-lamp.cs.berkeley.edu Does anyone know where I can get FreeBSD or NetBSD on CD-ROM in sydney ? Cheers. Nick Daglis. nick@lsupoz.apana.org.au From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 00:45:48 1994 From: Alan Bair Subject: Re: Important information. READ. - Vote of confidence To: billc@icecube.cryogenic.com Cc: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.3 PL11] Sender: owner-amiga@sun-lamp.cs.berkeley.edu As someone that has done a few things to try supporting the Amiga NetBSD effort and has to deal with software support as part of my job, I would like to give Bill a support of confidence in what he is proposing. I believe these changes will help everyone; developers, current users and future users. Besides its a good idea to do a little house cleaning once in awhile :-) > > As the NetBSD-Amiga 1.0 release loomed ever closer, things were undoubtly > going to have to change. Unfortunantly, it's going to require some people to > do some more work. > > Now, before you read any further, I would like for you to understand, that I > (any many others) do appreciate everything that _you_ have done. This could > be from simply installing a release of NetBSD, to running a mirror FTP site, > to writing documentation, to helping someone else get NetBSD running, to > actually making changes to the kernel, to just subscribing to the list and > giving a vote of confidence in the whole port. > ... > > * Achivers, please take note. > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > In order to facilitate a clean installation procedure, please move all > existing archives that do not work under -current/-release to an OLD > directory of some sort. This includes DOCS that have not been updated for > -current/-release, as they give WRONG information in some cases. ... > > I'm working on the Installation doc, and should have it available shortly > (hopefully done this weekend). > > Now, I will attempt to answer your questions once my mailbox stops smoking > ;-). > > Cheers. > > > -- > William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 02:43:54 1994 From: Mark Weaver To: current-users@sun-lamp.cs.berkeley.edu Subject: HELP-- need i386 boot blocks (more) Content-Length: 270 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Of course, mailing me the boot blocks would also be fine. Thanks, 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 Sat Jul 30 02:44:31 1994 From: Mark Weaver To: current-users@sun-lamp.cs.berkeley.edu Subject: HELP-- need i386 boot blocks Content-Length: 1006 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've got a problem. I need some i386 boot blocks that will: 1. Boot a 1.0-ALPHA kernel with DDB 2. Run on an old (level-1) file system Right now I can't boot my system and all I have is the 0.9 floppies (just the kernel-copy, fs1 and fs2). I can't run the new binaries with the 0.9 kernel, and I can't boot the new kernel on an old fs. I also can't compile the new kernel since I can't run the new cc with the old kernel. Furthermore, the kernels in the latest snapshot won't boot on my system, even if I take out every card except my video card (ATI GUP) and scsi card (Ultrastor 34f). If someone could make some appropriate sdboot/bootsd files (either the very latest or ones before the 4.4fs integration) via anon-ftp and let me know where to get them, I'd be eternally grateful. Thanks, 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 Sat Jul 30 02:56:24 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, mhw@cs.brown.edu Subject: Re: HELP-- need i386 boot blocks Sender: owner-current-users@sun-lamp.cs.berkeley.edu [...], and I can't boot the new kernel on an old fs. Um, why not? You need to be a lot more specific. Furthermore, the kernels in the latest snapshot won't boot on my system, [...] Again, why not? You haven't supplied any information which would help someone figure out what's wrong. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 03:38:49 1994 From: Mark Weaver To: current-users@sun-lamp.cs.berkeley.edu, mycroft@gnu.ai.mit.edu Subject: Re: HELP-- need i386 boot blocks Content-Length: 702 Sender: owner-current-users@sun-lamp.cs.berkeley.edu When I said "I can't boot a new kernel on an old fs" I meant to say "with 0.9 bootblocks" (since my new kernel is compiled with DDB). Charles -- This is not a bug report, it is a plea for help. I'm aware of the issues, and I know exactly what I need to get my system back up and running. I need the newest boot blocks. After my system is back up, then I will investigate why the GENERIC kernel won't boot on my system. Right now I can't even properly reply to mail without bending over backwards. 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 Sat Jul 30 04:54:52 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: Re: HELP-- need i386 boot blocks <199407292309.TAA04457@barney> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu Mark Weaver writes: >I've got a problem. I need some i386 boot blocks that will: > > 1. Boot a 1.0-ALPHA kernel with DDB > 2. Run on an old (level-1) file system Are new kernels not supposed to boot on older boot blocks? I've had no problems so far on my oldish 1.18? bootblocks. ----------------------------------------------------------------------------- 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 Jul 30 04:54:54 1994 To: Mark Weaver Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: HELP-- need i386 boot blocks <199407292309.TAA04457@barney> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >I've got a problem. I need some i386 boot blocks that will: [...] >If someone could make some appropriate sdboot/bootsd files (either the >very latest or ones before the 4.4fs integration) via anon-ftp and let >me know where to get them, I'd be eternally grateful. I put a set of the latest boot blocks up for anon ftp on ftp.iastate.edu in /pub/netbsd/misc/. --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 Jul 30 06:03:11 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, michaelv@iastate.edu Subject: Re: HELP-- need i386 boot blocks Sender: owner-current-users@sun-lamp.cs.berkeley.edu Are new kernels not supposed to boot on older boot blocks? New kernels *with DDB* will not work when booted from an old boot block. This is due to a difference in how the symbol table is loaded. New boot blocks should be able to boot either, now. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 07:36:09 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: HELP-- need i386 boot blocks <9407300126.AA07775@ponderous.cc.iastate.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu Thanks to everyone who sent me boot blocks. Thorsten Lockert was the first, for which he has my eternal gratitude. I'm running again! "Michael L. VanLoon -- Iowa State University" writes: > I put a set of the latest boot blocks up for anon ftp on > ftp.iastate.edu in /pub/netbsd/misc/. It might be useful to keep them up there. If anyone else mistakenly overwrites their boot blocks with a bad version, it'll be nice to have them available. 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 Sat Jul 30 08:04:02 1994 From: bdc@ai.mit.edu (Brian D. Carlstrom) To: current-users@sun-lamp.cs.berkeley.edu Subject: VM Question about swapping text segments Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just had a question about the VM system. I assume that it's swapping the text pages of files from the local filesystem by just tossing them, since they don't change. If this is true, what happend when the program is from across NFS. does it work the same, or does it swap local. a pointer to the right code would be appreciated -bri From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 10:08:31 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Charles M. Hannum" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: IRQ and DRQ autoconfiguration <199407271343.JAA18573@duality.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu "Charles M. Hannum" writes: > I've just enabled some old code I had written in the aha, ahb, bt, and > uha drivers, to use the IRQ and DRQ read off the board at boot time, > rather than statically configuring the info into the kernel. Cool, I'll test it tonight on my Ultrastor 34F. > I also fixed some bogons related to how DMA channels were configured, > that have been around since Julian. This reminds me of something I was always curious about. The Ultrastor 14F uses DMA to transfer the data, whereas the 34F is a bus-mastering VLB card that does the transfer on its own. Yet, long ago when I was looking through ultra14f.c, I couldn't find any difference in how the two cards were treated. In fact, the only change that was necessary to get the 34f working way back before NetBSD existed was to increase a couple of timeouts. My question is: where does the uha code call the dma code to get it to transfer the data, and is this code somehow turned off for the 34f? It should be. I'm very unfamiliar with the Intel hardware architecture, so please forgive me if I'm asking a stupid question. 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 Sat Jul 30 11:18:21 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: CVS daily output Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm no longer receiving the "CVS daily output" messages. The last one I got was on July 21st. Any ideas what's wrong? Also, judging from the files I received an hour or so ago, it looks like the last SUP scan was done on Wednesday (July 27th). 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 Sat Jul 30 14:06:44 1994 From: William J Coldwell To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: KERNEL CORE: I NEED YOUR NAMES. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu If you have contributed in any way to the KERNEL source tree or know of anyone who has, I need names to be added to the release installation documentation. I need them *pronto*. These are the ones I have: Marcus Wild Mike Schwartz Michael Hitch Chris Hopps Ken Dyke Bill Coldwell Anyone whose code that was incorporated which made the kernel what it is today, for release. Send along what you or the person did, too (just for verification). Thanks! -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 14:55:06 1994 From: Constantin Gonzalez Subject: 940721 bin-dist Problems To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1501 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Hi! I just installed the 940721 Distribution on top of my 940709 installation. Naturally it didn't work, since there's this Hydra-ethernet-bug, so I tried the almost-generic-kernel from ftp.uni-regensburg.de. After booting (even with the new rootfs) everything seems to work, except such vital commands like 'halt', 'fsck' and even 'rm' (sometimes). They produce Bus errors and coredumps. I was happy that the swap-messages vanished, but now I get other strange 'diskbuf'-messages, mainly while copying or unpacking large files. I just wanted to tell you, in case nothing else did. My configuration is A4000/040, 2 AT-Bus HDs, 8 MB Ram If someone is interested in more information on these bugs, I'll gladly mail them. P.S.: The older kernel (930709) didn't recognize any partition on my second HD. Disklabel said something like 'device not configured'. Is this fixed in the new distribution? Well, anxiously waiting for the next beta-release :) Ciao, Gonz -- -------------------------------------------------------------------------- Constantin Gonzalez | EMAIL: gonzalez@rz.tu-clausthal.de Student at the | SNAIL: Muehlenstrasse 120 Technical University of | 38678 Clausthal-Zellerfeld (Germany) Clausthal | PHONE: +49 5323 1516 -------------------------------------------------------------------------- - PGP-Public-Key: type 'finger incg@sun.rz.tu-clausthal.de' - Check out http://www.rz.tu-clausthal.de/~incg/ for more info on me. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 15:02:58 1994 From: William J Coldwell To: Constantin Gonzalez Subject: Re: 940721 bin-dist Problems Cc: amiga@sun-lamp.cs.berkeley.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu >I just installed the 940721 Distribution on top of my 940709 installation. >Naturally it didn't work, since there's this Hydra-ethernet-bug, so I tried >the almost-generic-kernel from ftp.uni-regensburg.de. After booting (even >with the new rootfs) everything seems to work, except such vital commands >like 'halt', 'fsck' and even 'rm' (sometimes). They produce Bus errors and >coredumps. Get the the kernel off of sun-lamp or one of the mirrors in the "arch/amiga/release" directory.. "netbsd.gz". Try that and see if your problems go away. Others: If you are going to upgrade, PLEASE test the latest RELEASE kernel so that we can get final problems fixed before the 1.0 release. Upgrading to older kernels doesn't do us any good. Thanks. -- William J. Coldwell - billc@iceCuBE.cryogenic.com - Cryogenic Software From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 18:34:35 1994 From: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: patch for csh needed ? To: netbsd-current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Content-Length: 1372 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm currently messing with compiling andrew 6.3 for X11R6, and came accross a patch for NetBSD 0.9 which patched make/str.c The patch or an equivalent seems to have been applied, and csh/dir.c The patch has not been applied. I'm wondering whether it's a) not a bug b) been fixed differently c) still needs fixing. The relevant part is here: Notes on AUIS 6.3a2 on free Net2/386 derived UNIX's NetBSD-0.9, NetBSD-current, FreeBSD Preparation: o Bug in /bin/csh Found in: NetBSD-0.9 Fixed in: NetBSD-current(I hope) FreeBSD-1.1 Free's memory area's when it shouldn't. A patch is below 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); } } Comments ? -- 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-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 30 19:18:08 1994 From: niklas@appli.se (Niklas Hallqvist) To: billc@iceCuBE.cryogenic.com Cc: amiga-dev@sun-lamp.cs.berkeley.edu Subject: Re: KERNEL CORE: I NEED YOUR NAMES. Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I may have some code in there. My name is Niklas Hallqvist, niklas@appli.se. It's just that I do not know if any of my code is still left. I have no opportunity to check it out fast either. Anyway, what may be remnicients of work of mine is the GVP dma interface. As you might remember I made the reverse engineering of their gvpscsi.device way back when AmigaMach was fashionable. I think Markus Wild used my code when doing NetBSD, but I'm unsure of this fact. I know this has since been revised so maybe nothing of my original code is left... Another place where there might be code originating from me is either in machdep.c, amiga_init.c or pmap.c, I don't remember where, but grep for Niklas, I think I'm credited there somewhere. Don't ask me what for, I honestly don't remember. Another thing I did was non-BSD partitions, but I guess Chris has rewritten that entirely when redoing the partitioning scheme. I guess I won't be hurt if I'm left out of the credits list, I just wanted to inform you the facts. I also think Ty Tsarna has contributed some code, but you have to ask him if I've got that right. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 19:56:46 1994 From: "Alan Bair" "Lib problems" (Jul 30, 1:06pm) X-Mailer: Z-Mail Lite (3.2.0 07jul94) To: SULEWSKIJ@delphi.com, amiga@sun-lamp.cs.berkeley.edu Subject: Re: Lib problems Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 30, 1:06pm, SULEWSKIJ@delphi.com wrote: > Subject: Lib problems > I just downloaded the last of the files off the ftp.iastate.edu site. > the path that i received the binaries from is as follows: > > ftp.iastate.edu > pub/netbsd/NetBSD-current/binaries/amiga/snapshot > > when I try to issue a vi or more command I get the following errors, > ld.so : more: libtermcap file not found. > > In fact any command that uses the terminal can't find certain library files. > vi is looking for: > libtermlib Did you pick up the usr.* files too? In particular for the libraries you will need; usr.lib.tar.gz. > > Does anyone know where I can find such files? I really want to get this > unix working and where can I get X-Windows? For the X files look for a contrib/bsd directory. The X files should be in there, but you may have to go to another site like ftp.uni-regensberg.de. There have bben several reports recently that not all the X servers still work. >-- End of excerpt from SULEWSKIJ@delphi.com -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 PH (512) 891-2336 abair@amcu-tx.sps.mot.com FAX (512) 891-3348 From owner-tech-kern@sun-lamp.cs.berkeley.edu Sat Jul 30 19:58:16 1994 From: Chuck Van Tilburg To: tech-kern@sun-lamp.cs.berkeley.edu Subject: question... Cc: ctilburg@cs.oberlin.edu Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu ...due to limited funds, I must attempt to make use of a notebook in a docking station (486DX2/66 8MB RAM) with PCMCIA ethernet (XIRCOM) and modem (HAYES Optima 14.4/14.4 data/fax) and a Future Domain 950 SCSI controller. The scsi controller is fixed at its location and irq. The only other quirck is that the modem and ethernet do not seem to like each other; strange things happen when both are active; at least under dos/windows. I obviously need at least a kernel that supports the 950 to get access to my scsi devices to install NetBSD-current. I have grabbed the PCMCIA stuff at ftp.cs.washington.edu but have no idea if my PCMCIA chip is an intel or not and really would like to use the network to install (copy) the NetBSD-current (1.0-ALPHA) binaries and source I have installed elsewhere on our LAN. The only other snag I can think of is that I have no way of turning off my lpt port if that is necessary (interrupt type). I still lack any 950 support although I have heard that it is there for FreeBSD-current; can I make use of that stuff? Is there anyone out there in a similair (solved) situation or knows of any expedient way to get this done? One of the major problems with notebooks is that you can't reconfigure much of anything. I am referencing the Jul 16 -current. My apologies if any or all of this is solved in the most recent -current. I haven't had the time or really the facilities yet to start up SUP. Any help or pointers will be greatly appreciated. LONG LIVE NetBSD! The tyranny of USL is finally beaten! A glorious future awaits! chuck /****************************************************************************** Charles C. Van Tilburg ctilburg@cs.oberlin.edu Computer Systems Technician Computer Science Program 216-775-8077/8064/0504 --> Oberlin College office(morning)/ 131 Severance Hall office(afternoon)/ Oberlin, Ohio, 44074 home. ******************************************************************************/ From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:35:27 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: PROBLEM WITH 1.0_BETA (IN SERIAL PORTS) Cc: buhrow@cats.ucsc.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm not sure whether this is a bug or a feature. I'm in the process of upgrading from Early February to 1.0_beta. When I boot my newly built kernel, everything is very happy, all of the devices are recognized, and there are no bogons in the filesystems. However, When I try to use the com ports, all processes that open them hang. Thinking that this may have been due to the fact that sun-style com ports had been implemented with the high bit in the minor number determining whether or not it was an outgoing or incoming device, I set a device with the major number for the serial ports with a minor number equal to the original + 128. When I tried to open this device with kermit, I got: "device not configured". When I tried to stty < /dev/com0 so I could see what was going on, the stty process blocked. What behavior should I see upon boot up? What do the flags entries do in the kernel configuration file? Will this all go away when I upgrade to current user binaries? Any words of wisdom, advice, or reminders that I'm doing something stupid will all be welcome. -thanks -Brian From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:35:45 1994 From: ejh@slueas.slu.edu (Eric J. Haug) To: current-users@sun-lamp.cs.berkeley.edu Subject: possible change to src/include/Makefile Sender: owner-current-users@sun-lamp.cs.berkeley.edu How about considering the following diff to the src/include/Makefile file? It's only claim to fame is to keep the file dates correct when copies are installed. (I noticed that everytime i make install in includes and then make in the src directory, that everything was being recompiled rather than that which would be determined by date dependence.) Maybe install needs a timestamp keeping option? eric *** Makefile Thu Jul 21 16:46:11 1994 --- Makefile.ejh Tue Jul 26 14:39:23 1994 *************** *** 36,40 **** @-for i in ${FILES}; do \ cmp -s $$i ${DESTDIR}/usr/include/$$i || \ ! install -c -m 444 $$i ${DESTDIR}/usr/include/$$i; \ done @echo installing ${DIRS} --- 36,40 ---- @-for i in ${FILES}; do \ cmp -s $$i ${DESTDIR}/usr/include/$$i || \ ! pax -rw -pa $$i ${DESTDIR}/usr/include/; \ done @echo installing ${DIRS} *************** *** 43,47 **** (cd $$i; for j in *.[ih]; do \ cmp -s $$j ${DESTDIR}/usr/include/$$i/$$j || \ ! install -c -m 444 $$j ${DESTDIR}/usr/include/$$i/$$j; \ done); \ done --- 43,47 ---- (cd $$i; for j in *.[ih]; do \ cmp -s $$j ${DESTDIR}/usr/include/$$i/$$j || \ ! pax -rw -pa $$j ${DESTDIR}/usr/include/$$i; \ done); \ done From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:36:58 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: more(1) is broken Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu I recently noticed a problem with more(1), here's how to repeat it: 1) Run more on a file that's exactly 32 lines long, while logged in to a pccons console (25 line). The file I was looking at when I noticed the problem was termnet.h from term118pl06. 2) Hit space once; watch the status line change from 68% to END 3) Hit C-u to page up half a screen; the top 8 lines are from the beginning of the file, the rest are from further down. 4) Hit C-l and watch the display change. I don't know yet whether this is a problem with more, curses, pccons, or something else, so I haven't sent in a PR. But I thought core people and others may want to look into this and possibly it would be fixed before 1.0 comes out. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:37:03 1994 From: John Nemeth "Re: Which Release for DEC" (Jul 27, 4:56am) X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: Theo de Raadt , Jan-Hinrich Fessel Subject: Re: Which Release for DEC Cc: cgd@alpha.bostic.com (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu On Jul 27, 4:56am, Theo de Raadt wrote: } Subject: Re: Which Release for DEC } > Which release is going to run on a DEC 5400 Server, aside } > from ultrix;-) } } the next NetBSD release is (pretty much) gauranteed to work on the } decstations. If I remember right, these are R2000 (R3000?) based machines? Are there any ports planned for any other MIPS based machines? Does anybody know what machine the VAX port will support? It would be really nice to get NetBSD for this thing (MicroVAX 2000). }-- End of excerpt from Theo de Raadt From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:37:10 1994 To: peter@alice.wonderland.org Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: GET THIS BOOK :) <199407272315.AAA06029@alice.wonderland.org> 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 >Just for those amongst you who have the tollerance to satire and the >time, get this book: > > The UNIX Haters Handbook > Simson Garfinkel, Daniel Weise & Steven Strassmann > Publisher: IDG Books > ISBN: 1-56884-203-1 You know, I just read that book a few days ago, and I have to say that I was not very impressed with it. Most of the arguments seem rather contrived; it almost seemed that they took every feature of Unix and came up with reasons that they hated it. There's a lot of gross oversimplification ("The only reason Unix was written was because Ken Thompson wanted to play Space Travel"), some re-writing of history ("Remember when e-mail used to work, before Unix?"), and some things that are just plain dumb ("Screen handling functions should be in the kernel, where they belong ... just like VMS"). They make a few valid points, but they don't seem to offer any better alternatives. I get the feeling that these people wouldn't be happy with _any_ computer system. --Ken From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sat Jul 30 20:38:12 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Fix for sync negotiation 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 Here's a little patch that should fix problems with sync negotiation on 33c93 controllers. If anybody has some drives that need sync and some that can't handle it, or have drives that only worked with inhibit_sync set and want some extra speed from synchronous transfers, try this out. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid *** 1.2 1994/07/30 10:02:55 --- sys/arch/amiga/dev/sbic.c 1994/07/30 10:01:02 *************** *** 111,117 **** * was broken before.. now if you want this you get it for all drives * on sbic controllers. */ ! int sbic_inhibit_sync = 1; int sbic_clock_override = 0; int sbic_no_dma = 0; --- 111,117 ---- * was broken before.. now if you want this you get it for all drives * on sbic controllers. */ ! int sbic_inhibit_sync = 0; int sbic_clock_override = 0; int sbic_no_dma = 0; *************** *** 923,929 **** SET_SBIC_cmd(regs, SBIC_CMD_CLR_ACK); WAIT_CIP(regs); phase = CMD_PHASE; /* or whatever */ ! } else if (dev->sc_msg[0] == MSG_CMD_COMPLETE) { /* !! KLUDGE ALERT !! quite a few drives don't seem to * really like the current way of sending the * sync-handshake together with the ident-message, and --- 923,930 ---- SET_SBIC_cmd(regs, SBIC_CMD_CLR_ACK); WAIT_CIP(regs); phase = CMD_PHASE; /* or whatever */ ! } else if ( dev->sc_msg[0] == MSG_CMD_COMPLETE ! || dev->sc_msg[0] == 0xff ) { /* !! KLUDGE ALERT !! quite a few drives don't seem to * really like the current way of sending the * sync-handshake together with the ident-message, and From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:39:11 1994 To: current-users@sun-lamp.cs.berkeley.edu Subject: "cannot fork" errors From: Randy Terbush Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just upgraded to the 7-24 source tar-balls. Kudos to all of the NetBSD team. This is truely the nicest i386 UNIX I have run in the past 8 years. (and I've tried em all) One problem I noticed.... I started an X11R6 compile before hitting the sack last night. It errored out with "cannot fork" errors before even finishing the library compiles. This would probably make the ETD (estimated time of death) right around the time that news expires were running. Are there some system resource limits that are a little bit low? -- Randy From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:39:26 1994 From: mark@aggregate.com (Mark P. Gooderum) To: randy%sierra%dsndata@sterling.com, jconklin@netcom.com Subject: Re: Taylor UUCP 1.05 Cc: scottr@plexus.com, current-users@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 1548 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Has anyone looked at merging the changes from Taylor 1.05 into the > > NetBSD tree? How much "hacking" has been done on the NetBSD version? > > I've looked. I have a script (mostly works) that copies files from a > Taylor UUCP distribution to the NetBSD directory hierarchy. I haven't had > much reason to follow up on it, as 1.04 works fine for me. > > I don't think much hacking was done on the NetBSD version, but that's > something I'd want to check before blindly integrating 1.05. > > --jtc I've ftp'd the 1.04 and 1.05 dist and the diffs between the two. I'll make a pass through comparing the 1.04 dist to the NetBSD tree. If 1.05 is integrated, it's probably easiest to evaluate and apply the 1.04->1.04(NetBSD) fixes to the 1.05 tree, as the diffs from 04 to 05 are significant: ftp> dir uucp* 200 PORT command successful. 150 Opening ASCII mode data connection for /bin/ls. -r--r--r-- 1 mirror 2625 303904 May 6 18:47 uucp-1.04-1.05.diff.gz -r--r--r-- 1 mirror 2625 634624 Feb 15 1993 uucp-1.04.tar.gz -r--r--r-- 1 mirror 2625 726835 May 6 18:45 uucp-1.05.tar.gz -r--r--r-- 1 mirror 2625 383413 Feb 17 1993 uucp-doc-1.04.1.tar.gz -r--r--r-- 1 mirror 2625 339019 May 6 18:46 uucp-doc-1.05.tar.gz 226 Transfer complete. remote: uucp* 381 bytes received in 0.14 seconds (2.6 Kbytes/s) ftp> This matters to me since my mail feed is switching to UUCP this weekend and from looking things over, I may need some 1.05 bits to make it work the way I want. -Mark From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 20:45:48 1994 From: SULEWSKIJ@delphi.com Subject: Lib problems To: amiga@sun-lamp.cs.berkeley.edu X-Vms-To: INTERNET"amiga@sun-lamp.cs.berkeley.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: owner-amiga@sun-lamp.cs.berkeley.edu I just downloaded the last of the files off the ftp.iastate.edu site. the path that i received the binaries from is as follows: ftp.iastate.edu pub/netbsd/NetBSD-current/binaries/amiga/snapshot when I try to issue a vi or more command I get the following errors, ld.so : more: libtermcap file not found. In fact any command that uses the terminal can't find certain library files. vi is looking for: libtermlib Does anyone know where I can find such files? I really want to get this unix working and where can I get X-Windows? From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:49:35 1994 From: mark@aggregate.com (Mark P. Gooderum) To: current-users@sun-lamp.cs.berkeley.edu, michaelv@iastate.edu Subject: Re: SLIP/PPP crashes Cc: bugs@sun-lamp.cs.berkeley.edu X-Sun-Charset: US-ASCII Content-Length: 414 Sender: owner-current-users@sun-lamp.cs.berkeley.edu > vm_fault(f81cf2c8, 0, 1, 0) -> 5 > fatal page fault in supervisor mode > trap type 6 code f8100000 eip ... cs ... eflags 13286 cr2 f0 cpl ffffffff I got a very similar crash when using MSDOSFS and a July 18th and 22nd sup. When I updated to the 26th sup and picked up the new machdep.c and the vm fixes, the problem went away. My random 486DLC SEGV's seem to be gone again too with the Jul 26th sup. -Mark From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:49:42 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: bugs@sun-lamp.cs.berkeley.edu Subject: SLIP/PPP crashes From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu My co-worker and I share a Zenith 386/25 in our office that we use for a SLIP/PPP server. He has an internal 14.4k modem with a built-in 16550 in it, and I have a 16550 board in the machine connected to my 28.8k external modem. The machine had like 73 days uptime when he was using it alone until recently, and was running NetBSD-"current" from the beginning of the year. Once we added my serial board to the machine, we had to build a new kernel, so we upgraded it to current as of a few weeks ago. It seems to work just fine for us when traffic is light. However, it seems like every time I try to sup, I hang the machine hard. I don't know why, but supping current from sun-lamp seems to be what breaks it. Maybe because it's just non-stop heavy TCP traffic in both directions. Anyway, normal traffic doesn't seem to do it, but it seems to happen every single time I try to sup from sun-lamp. He built the kernel that we tried first, and this stuff was happening. So, I build a kernel on my machine, from the source tarballs of the 17th. The exact same thing happens from the kernel I build. My machine at home doesn't crash, but the machine routing the traffic in our office does. It doesn't matter whether I'm using SLIP or PPP, it happens either way, indicating to me it's not actually in the SLIP/PPP code, but is somewhere else. We don't have DDB built into the kernel there, because we wanted the machine to just reboot if it ever crashed. Unfortunately, the nature of these crashes just causes it to hang solid, so I have to go drive to campus to fix it. :-( Here's what I see on the display when it's hung... With the kernel from the beginning of the month built on explorer's box: vm_fault(f818d90c, 0, 1, 0) -> 5 fatal page fault in supervisor mode trap type 6 code f8100000 eip f8100ff9 es f7bf0008 eflags 13292 cr2 f0 cpl ffffffff panic: trap With the kernel from the 17th tarballs, built on my machine: vm_fault(f81cf2c8, 0, 1, 0) -> 5 fatal page fault in supervisor mode trap type 6 code f8100000 eip ... cs ... eflags 13286 cr2 f0 cpl ffffffff (Both times it looked like it had scrolled a ton of these on the display before finally hanging. In the second example, it looked like the previous messages all had eflags 13282 in them, until the final one that hung tight which had the eflags 13286.) Does this make any sense to anyone? I'm going to try to build a new kernel with this weekend's tarballs, but I have a feeling it's not going to make any difference, since I haven't seen any report of anything affecting this lately. Is this enough information to track down any bugs with? Has anyone heard of anything that might affect this? I'd love to kill this bug so I can have a stable net connection. ----------------------------------------------------------------------------- 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 Jul 30 20:54:12 1994 To: current-users@sun-lamp.cs.berkeley.edu Cc: agc@uts.amdahl.com (Alistair G. Crooks) Subject: Re: Snapshot Report - July 24th tar_files From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >3. Michael VanLoon reported problems with the July 23rd (I think) >tar_files. This isn't my experience, although I'm running with old >bootblocks (1.19), and I'm only going to go to 4.4 inodes when I >absolutely have to. In fact, I had absolutely no trouble upgrading >this week. My experience is that you are running on borrowed time if you try to run an old filesystem format under a new kernel. Mine got quite mangled, and I was only able to unmangle it by running an old kernel and old fsck on it. Once I updated it to the new "fsck -c 2" format, though, everything seems to be working just peachy under the new kernel. Remember, though, that the fsck -c 2 step is a never-look- back step, since the old kernel will cease to work once you upgrade the filesystem. My problem with the source tar files (the 17th, actually) wasn't a source problem at all. Rather, I had some old cruft in my kernel build dir and libkern dir that wasn't getting removed by make clean. If you update to kernel sources after being dormant for awhile, make sure to remove all the .o and .depend files from libkern/ or libkern/obj/ (depending on your setup), and remove all the .o, .h, .depend, and genassym files from your kernel compile dir. Doing this made kernel builds finally work for me. Oh, of course, don't forget to install new includes first, and build a new config before attempting a kernel build. >9. Last time I produced one of these reports, this was the i386 >supported SCSI device list. Could someone please update me with >any changes? > >bt742 eisa bt742a.c deraadt@fsa.ca >bt747 eisa bt742a.c michaelv@iastate.edu As far as I know, all the BusLogic cards work with the standard bt driver now. I know that, at least, my bt747s does. >[The Adaptec 2742 is not supported, and may not be in future due to >Adaptec's refusal to release "proprietary information" about the board.] Not only the 2742, but the entire Adaptec 2xxx line. >(There has been some discussion over the best SCSI board to purchase. >General reasoning was that Adaptec support wasn't good for non-DOS >problems, and re the 2742 issue. The Ultrastore has jumpers for >everything, which can be a pain. The Bustek boards have had >favourable reports. Please note that I'm just condensing other >people's opinions here, all you lawyers out there.) For PCI people, the NCR 810 SCSI chip/board is supposed to be the next great thing, and is significantly cheaper than anything else, as well. I haven't used one in a NetBSD system, but I've used one in a 66MHz Pentium Windoze box, and can vouch that they're several times faster than a 1542c in a 90MHz Pentium of the same manufacturer (both machines also had 32MB of RAM). Haven't had a chance to compare one to a bt946c, however. >13. For anyone a trifle nervous, having seen stories of not being >able to boot their root filesystem etc, I'm taking quite a >conservative line on this - I'm still using the 1.19 bootblocks, I've >got 4.3 style inodes, and I'm running on SCSI disks. I repeat that >I've had no problems this week upgrading. The problems that I have >seen over the last few months (and which have all been fixed) are: Be warned that you could see a huge mess next time you reboot. You may not see any problems until then, however. Proceed without upgrading at your own peril. Thanks for posting the snapshots again, Alistair. If nothing else, it gives us a sounding board to rehash the previous week's development. ----------------------------------------------------------------------------- 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 Jul 30 20:54:36 1994 From: Thor Lancelot Simon To: current-users@sun-lamp.cs.berkeley.edu, port-pmax@sun-lamp.cs.berkeley.edu Subject: "pmax" != DS5400! Sender: owner-current-users@sun-lamp.cs.berkeley.edu Someone asked about NetBSD for the DS5400, and TDR (I think) pointed him at the pmax port. Unfortunately, unless I seriously misremember the 5400 series, that won't do it. Unlike its smaller brethren, the 5400 is a QBUS machine, and the pmax port seems to support only TurboChannel and the genuine pmax's obio. On the other hand, there's working QBUS support on my 4.3 tape -- it was written and contributed to CSRG way back when by Mt. Xinu as part of the MicroVAX II port of 4.3. Is it safe to assume that this code is "clean"? If not, who's to ask to find out what code is "safe" and which isn't in abandoned branches of the tree like the VAX and the Qbus and Unibus code that goes with it? Perhaps Mt. Xinu could re-contribute their Qbus code. If I remember right, there were drivers for the DHV11 and the RQDX disk controllers, but you'd need to write a lot of drivers to use it with the DS5400... From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 20:56:16 1994 From: Open Carefully -- Contents Under Pressure X-Disclaimer: No way are these anyone else's opinions but mine. X-Real-Name: James Graham (*NOT* "Jim" -- that's my dad) X-Extension: 4219 X-Room-Number: 3308 X-Window-System: Release 5 X-No-Relation-To: greywolf@netcom.com, greywolf@blkhole.resun.com X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: current-users@sun-lamp.cs.berkeley.edu Subject: su Sender: owner-current-users@sun-lamp.cs.berkeley.edu Okay, I *know* BSD != SunOS, but I think that Sun had a Good Idea (TM) when they wrote the "su" code as follows: - You cannot become super-user unless you are in group 0. (BSD has already done this, obviously.) - The exception to this rule is if the group list for group 0 is empty. (SunOS did this). I can see pros and cons for this, and I see the flame-throwers on already, but for ease of operation, I don't view it as a bad idea. If anyone disagrees, feel free to verbalise, but I would implore that the approach of "Are you {stupid,a moron,a total idiot}? The reasoning is obvious!" not be used in this instance, because the mechanism seems to me to be worth implementing. The reversal to standard BSD behaviour would be to stick only root in group 0. As an alternative to the above, there should be some way to un-restrict super-user access without including everyone in the world in the group list, should it become necessary (large bases of non-technical or non-system-interested users, such as the organization for which I work, come to mind -- when I need to grab a window from the closest available machine in an emergency, I don't really want to have to su to me first). I've gotten spoiled, I guess. I could implement this in my own sources but I guess that kind of misses the point. Comments? Agreement? Dissent? [ DISCLAIMER: I'm no kernel wizard, but I'm no joe q. luser, either ] -- _______Wizardry is dead._____ _____WHO: Greywolf (my nameplate even says so) / ___\ _ \ __\ V / \ / /__ \| | __/WHAT: UNIX System Mangler...er, Admin \ \| | < _| ` ' \ '` / \/ /|_| _/ WHERE: Autodesk, Inc. 3 Harbor Dr. \___|_|\_\__\|_| \/\/ \__/___/_| Sausalito, CA 94965 (415) 332-2344 x4219 see also: gandalf@netcom.com From owner-tech-kern@sun-lamp.cs.berkeley.edu Sat Jul 30 21:54:50 1994 From: mycroft@gnu.ai.mit.edu To: ctilburg@cs.oberlin.edu, tech-kern@sun-lamp.cs.berkeley.edu Subject: Re: question... Sender: owner-tech-kern@sun-lamp.cs.berkeley.edu I still lack any 950 support although I have heard that it is there for FreeBSD-current; [...] Last I knew, that driver (the `seagate' driver) didn't even work. I have a version I ported to NetBSD way back when the person who wrote it for 386BSD first released it, but people I've given it to say it doesn't work, and even the original author seemed to indicate that it was flaky as Hell. Looking at the code from FreeBSD, I don't believe they've made it more reliable. So, at the moment, I'd say you're kind of screwed. I could give you the version I have, if you want to work on it... I have grabbed the PCMCIA stuff at ftp.cs.washington.edu but have no idea if my PCMCIA chip is an intel or not [...] Have you read the documentation which came with the machine? (Note: It probably is.) I'm planning to put this code in our tree, but it may require some changes, and it definitely won't go in before the 1.0 release. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 22:09:45 1994 To: amigabsd@bibliob.slip.netcom.com From: Majordomo@sun-lamp.cs.berkeley.edu Subject: Welcome to amiga Sender: owner-amiga@sun-lamp.cs.berkeley.edu Welcome to the amiga mailing list! If you ever want to remove yourself from this mailing list, send the following command in email to "Majordomo@sun-lamp.cs.berkeley.edu": unsubscribe amiga "Local distribution" Here's the general information for the list you've subscribed to, in case you don't already have it: The NetBSD-Amiga list was the first and largest of the three mailing lists supporting Markus Wild's (et all) port of NetBSD to the Amiga. It is an unmoderated, public mailing list. Warning: This list carries a lot of traffic on it. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 22:47:01 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: "Michael L. VanLoon -- Iowa State University" Cc: current-users@sun-lamp.cs.berkeley.edu, bugs@sun-lamp.cs.berkeley.edu Subject: Re: SLIP/PPP crashes <9407272002.AA05252@ponderous.cc.iastate.edu> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu I think this bug has been reported fixed since the tarballs of the 17th. You might just try grabbing the ppp stuff from the extracted current tree on lamp and dropping them into your kernel of the 17th. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 22:55:14 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: Thor Lancelot Simon Cc: current-users@sun-lamp.cs.berkeley.edu, port-pmax@sun-lamp.cs.berkeley.edu Subject: Re: "pmax" != DS5400! From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > Someone asked about NetBSD for the DS5400, and TDR <(I think) pointed him at > the pmax port. > > Unfortunately, unless I seriously misremember the 5400 series, that won't do > it. Unlike its smaller brethren, the 5400 is a QBUS machine, and the pmax > port seems to support only TurboChannel and the genuine pmax's obio. > Cool. A project to do once the port is self-hosting. The autoconfig scheme will likely be redone in config.new style as well, leveraging work done for the alpha port. later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 22:57:41 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, michaelv@iastate.edu Subject: Re: Snapshot Report - July 24th tar_files Sender: owner-current-users@sun-lamp.cs.berkeley.edu My experience is that you are running on borrowed time if you try to run an old filesystem format under a new kernel. This was due to a bug in the new fsck(8), which has been fixed. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 22:57:55 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: msdosfs Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu Is MSDOSFS ready for prime-time yet? I'm running into problems with it hanging the system (no panic, just Big Red Switch time) when I try to write to a DOS partition (added to the disklabel and mounted from /etc/fstab). It only happens some of the time. I'm running 7/13 binaries with a kernel created from 7/23 tarball sources. It doesn't screw up the MSDOS file system (at least as far as CHKDSK can tell); a 0-length entry for the file written from NetBSD is left behind in the directory, though. The MSDOS file system was created by MSDOS 6.0. If anyone wants more details, please ask. Also, mount_msdos doesn't understand the -o flag, which means that I can't use mount -u on my DOS partition. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 22:58:09 1994 From: mycroft@gnu.ai.mit.edu To: Mike.Long@analog.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: more(1) is broken Sender: owner-current-users@sun-lamp.cs.berkeley.edu I can't reproduce this with either pccons or pcvt. Are you sure you're using a correct termcap entry? From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:00:03 1994 From: mycroft@gnu.ai.mit.edu To: buhrow@cats.ucsc.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: PROBLEM WITH 1.0_BETA (IN SERIAL PORTS) Sender: owner-current-users@sun-lamp.cs.berkeley.edu When I tried to stty < /dev/com0 so I could see what was going on, the stty process blocked. If you use `stty -f /dev/tty00', it will open the tty in non-blocking mode and actually give you some output. Answers to your other problems have already been sent to this mailing list recently. From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 23:16:36 1994 From: "L. Todd Masco" To: amiga@sun-lamp.cs.berkeley.edu Subject: Hydra bug? Organization: Bibliobytes Books on Computer; info@bb.com Sender: owner-amiga@sun-lamp.cs.berkeley.edu Does the kernel in release still have the hydra bug? If so, where can I get the real GENERIC kernel that'll run on my stock A3000? (CD-ROM, ADOS, tape) Thanks, -- L. Todd Masco | Bibliobytes books on computer, on any UNIX host with e-mail cactus@bb.com | "Information wants to be free, but authors want to be paid." From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:20:50 1994 From: mycroft@gnu.ai.mit.edu To: Mike.Long@analog.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: msdosfs Sender: owner-current-users@sun-lamp.cs.berkeley.edu Also, mount_msdos doesn't understand the -o flag, which means that I can't use mount -u on my DOS partition. Sounds like you're using an old version. trinity# mount -rt msdos /dev/fd0a /mnt trinity# ls /mnt scsi.exe scsicntl.exe scsicode.exe setscsi.exe trinity# mount -u -r /dev/fd0a /mnt trinity# mount -u /dev/fd0a /mnt trinity# I'll look at the other problem in a moment. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:29:23 1994 X-Authentication-Warning: sun-lamp.cs.berkeley.edu: Host localhost didn't use HELO protocol To: John Nemeth Cc: Theo de Raadt , Jan-Hinrich Fessel , cgd@alpha.bostic.com (Chris G. Demetriou), current-users@sun-lamp.cs.berkeley.edu Subject: Re: Which Release for DEC <199407272125.OAA01052@cue.bc.ca> From: Adam Glass Sender: owner-current-users@sun-lamp.cs.berkeley.edu > > If I remember right, these are R2000 (R3000?) based machines? > Are there any ports planned for any other MIPS based machines? > Only for MIPS-based machines that show up on the doorstops of people interested in making this code work on them. Possible ports include: MIPS-manufactured mips boxes Sony MIPS boxes (there is actually a 4.4 port to these) pc form factor r4k boxes But none of these ports will happen until people appear with the hardware and a desire to do the work. > Does anybody know what machine the VAX port will support? It > would be really nice to get NetBSD for this thing (MicroVAX 2000). > > }-- End of excerpt from Theo de Raadt No idea. Ask on 'port-vax@sun-lamp.cs.berkeley.edu' (which you can join via majordomo.... later, Adam Glass From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:30:44 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: arch/i386/floppy/sh won't make depend? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I could not get arch/i386/floppy/sh won't to "make depend" today. I'm recent as of yesterday. [I'm trying to do a full rebuild of /usr/src] There is a "sh ... -h ..." in the Makefile, and my sh does not support the '-h' option (although, I notice, my sunos sh does). I checked the man page of the /usr/src/bin/sh and it does not have a '-h' entry either, so I assume that building and installing sh first won't fix this... sorry if I'm doing something dumb; I removed the '-h' in the make file and the 'make depend' worked fine. -brad From owner-amiga@sun-lamp.cs.berkeley.edu Sat Jul 30 23:37:06 1994 From: Andrew Cherry To: amiga@sun-lamp.cs.berkeley.edu Subject: forwarded message from Jukka Forsgren Sender: owner-amiga@sun-lamp.cs.berkeley.edu ------- Start of forwarded message ------- From: Jukka Forsgren To: cherry@crunk.planet.net (Andrew Cherry) Subject: Re: System lockups with newer kernels Date: Sat, 30 Jul 1994 12:20:52 +0300 (EET DST) > > I've heard at least one other report of problems with SCSI lockups; > has anyone else had these problems or have any insights into them? > I'am also having problems with those lockups. I have an A3000/25, 120MB & 105MB Quantum and 6MB of memory.. ------- End of forwarded message ------- From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:51:20 1994 From: Alan Barrett Subject: Re: fsck problems To: Juergen Keil 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 Juergen Keil wrote: > 1. On a filesystem using the old inode format, fsck always > generates new directory entries (i.e. in lost+found) in the > new directory record format! I thought the byte-swapping code looked error prone. I haven't examined the code closely enough to tell how well this would work out in practice, but I wondered why the BYTE_ORDER tests were not put in the definition of struct direct in , rather than scattered around the kernel and various utilities. > I suggest the following patch, which should fix both problems. Thanks! I rearranged your patch slightly and integrated it into my test version of fsck. It cleaned up my disk almost perfectly, leaving only one bad directory entry in lost+found, which I was able to zap with clri. I think that the one entry that the new fsck couldn't fix was one that had been created in a corrupted state by the bad fsck. I append my patch, which incorporates everything from Juergen (in a slightly rearranged form), as well as my fixes to reduce the number of compiler warnings. --apb (Alan Barrett) diff -r -u3 fsck/Makefile TEST-fsck/Makefile --- fsck/Makefile Thu Jun 30 12:31:26 1994 +++ TEST-fsck/Makefile Wed Jul 27 09:21:44 1994 @@ -1,6 +1,7 @@ # from: @(#)Makefile 8.1 (Berkeley) 6/5/93 # $Id: Makefile,v 1.8 1994/06/30 05:33:33 cgd Exp $ +CFLAGS= -g -ansi -pedantic -Wall -Wtraditional -Wshadow -Wpointer-arith -Wcast-qual -Wcast-align -Wconversion -Wredundant-decls PROG= fsck MAN8= fsck.0 SRCS= dir.c inode.c main.c pass1.c pass1b.c pass2.c pass3.c pass4.c \ diff -r -u3 fsck/dir.c TEST-fsck/dir.c --- fsck/dir.c Thu Jun 9 12:10:22 1994 +++ TEST-fsck/dir.c Wed Jul 27 23:49:20 1994 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include "fsck.h" @@ -63,6 +64,7 @@ /* * Propagate connected state through the tree. */ +void propagate() { register struct inoinfo **inpp, *inp; @@ -88,6 +90,7 @@ /* * Scan each entry in a directory block. */ +int dirscan(idesc) register struct inodesc *idesc; { @@ -110,6 +113,9 @@ idesc->id_loc = 0; for (dp = fsck_readdir(idesc); dp != NULL; dp = fsck_readdir(idesc)) { dsize = dp->d_reclen; + /* XXX there is a problem here if (dsize > DIRBLKSIZE) + * but we should be able to rely on fsck_readdir() having + * sanitised it already. */ bcopy((char *)dp, dbuf, (size_t)dsize); # if (BYTE_ORDER == LITTLE_ENDIAN) if (!newinofmt) { @@ -156,6 +162,7 @@ register struct direct *dp, *ndp; register struct bufarea *bp; long size, blksiz, fix, dploc; + long old_reclen; blksiz = idesc->id_numfrags * sblock.fs_fsize; bp = getdirblk(idesc->id_blkno, blksiz); @@ -193,10 +200,11 @@ size = DIRBLKSIZ - (idesc->id_loc % DIRBLKSIZ); idesc->id_loc += size; idesc->id_filesize -= size; + old_reclen = dp->d_reclen; /* dofix() might change d_reclen */ fix = dofix(idesc, "DIRECTORY CORRUPTED"); bp = getdirblk(idesc->id_blkno, blksiz); dp = (struct direct *)(bp->b_un.b_buf + dploc); - dp->d_reclen += size; + dp->d_reclen = old_reclen + size; if (fix) dirty(bp); } @@ -207,6 +215,7 @@ * Verify that a directory entry is valid. * This is a superset of the checks made in the kernel. */ +int dircheck(idesc, dp) struct inodesc *idesc; register struct direct *dp; @@ -249,6 +258,7 @@ return (0); } +void direrror(ino, errmesg) ino_t ino; char *errmesg; @@ -257,6 +267,7 @@ fileerror(ino, ino, errmesg); } +void fileerror(cwd, ino, errmesg) ino_t cwd, ino; char *errmesg; @@ -280,6 +291,7 @@ pfatal("NAME=%s\n", pathbuf); } +void adjust(idesc, lcnt) register struct inodesc *idesc; short lcnt; @@ -310,6 +322,7 @@ } } +int mkentry(idesc) struct inodesc *idesc; { @@ -336,15 +349,29 @@ dirp->d_reclen = newent.d_reclen; dirp->d_namlen = newent.d_namlen; bcopy(idesc->id_name, dirp->d_name, (size_t)dirp->d_namlen + 1); + /* + * 'dirscan' will eventually swap the original dirp back to the + * old inode format. Handle the new dirent here. + */ +# if (BYTE_ORDER == LITTLE_ENDIAN) + if (!newinofmt) { + u_char tmp; + + tmp = dirp->d_namlen; + dirp->d_namlen = dirp->d_type; + dirp->d_type = tmp; + } +# endif return (ALTERED|STOP); } +int chgino(idesc) struct inodesc *idesc; { register struct direct *dirp = idesc->id_dirp; - if (bcmp(dirp->d_name, idesc->id_name, (int)dirp->d_namlen + 1)) + if (bcmp(dirp->d_name, idesc->id_name, (size_t)dirp->d_namlen + 1)) return (KEEPON); dirp->d_ino = idesc->id_parent; if (newinofmt) @@ -354,6 +381,7 @@ return (ALTERED|STOP); } +int linkup(orphan, parentdir) ino_t orphan; ino_t parentdir; @@ -461,6 +489,7 @@ /* * fix an entry in a directory. */ +int changeino(dir, name, newnum) ino_t dir; char *name; @@ -481,6 +510,7 @@ /* * make an entry in a directory */ +int makeentry(parent, ino, name) ino_t parent, ino; char *name; @@ -516,6 +546,7 @@ /* * Attempt to expand the size of a directory */ +int expanddir(dp, name) register struct dinode *dp; char *name; @@ -572,6 +603,7 @@ /* * allocate a new directory */ +int allocdir(parent, request, mode) ino_t parent, request; int mode; @@ -627,6 +659,7 @@ /* * free a directory inode */ +void freedir(ino, parent) ino_t ino, parent; { @@ -643,6 +676,7 @@ /* * generate a temporary name for the lost+found directory. */ +int lftempname(bufp, ino) char *bufp; ino_t ino; diff -r -u3 fsck/fsck.h TEST-fsck/fsck.h --- fsck/fsck.h Thu Jun 9 12:10:23 1994 +++ TEST-fsck/fsck.h Thu Jul 28 00:06:44 1994 @@ -214,3 +214,68 @@ void getblk(); ino_t allocino(); int findino(); + +void addpart(); +void adjust(); +int allocblk(); +int allocdir(); +int argtoi(); +void badsb(); +void blkerror(); +int bread(); +void bufinit(); +void bwrite(); +void cacheino(); +int calcsb(); +int changeino(); +int checkfstab(); +void checkinode(); +int chkrange(); +void ckfini(); +int ckinode(); +void clri(); +int dircheck(); +void direrror(); +int dirscan(); +int dofix(); +int expanddir(); +int ffs_fragacct(); +void fileerror(); +void flush(); +void freeblk(); +void freedir(); +void freeino(); +void freeinodebuf(); +int ftypeok(); +void getpathname(); +int iblock(); +void inocleanup(); +void inodirty(); +int lftempname(); +int linkup(); +int makeentry(); +void panic(); +void pass1(); +void pass1b(); +void pass2(); +void pass3(); +void pass4(); +int pass4check(); +void pass5(); +void pinode(); +void propagate(); +int readsb(); +int reply(); +void resetinodebuf(); +int setup(); +int startdisk(); + +#if __STDC__ +void errexit(const char*, ...); +void pfatal(const char*, ...); +void pwarn(const char*, ...); +#else +void errexit(); +void pfatal(); +void pwarn(); +#endif diff -r -u3 fsck/inode.c TEST-fsck/inode.c --- fsck/inode.c Wed Jun 15 12:21:35 1994 +++ TEST-fsck/inode.c Mon Jul 25 18:16:42 1994 @@ -44,12 +44,14 @@ #ifndef SMALL #include #endif +#include #include #include #include "fsck.h" static ino_t startinum; +int ckinode(dp, idesc) struct dinode *dp; register struct inodesc *idesc; @@ -103,6 +105,7 @@ return (KEEPON); } +int iblock(idesc, ilevel, isize) struct inodesc *idesc; long ilevel; @@ -168,6 +171,7 @@ * Check that a block in a legal block number. * Return 0 if in range, 1 if out of range. */ +int chkrange(blk, cnt) daddr_t blk; int cnt; @@ -257,6 +261,7 @@ return (dp++); } +void resetinodebuf() { @@ -282,6 +287,7 @@ (void)getnextinode(nextino); } +void freeinodebuf() { @@ -297,6 +303,7 @@ * * Enter inodes into the cache. */ +void cacheino(dp, inumber) register struct dinode *dp; ino_t inumber; @@ -353,6 +360,7 @@ /* * Clean up all the inode cache structure. */ +void inocleanup() { register struct inoinfo **inpp; @@ -366,12 +374,14 @@ inphead = inpsort = NULL; } +void inodirty() { dirty(pbp); } +void clri(idesc, type, flag) register struct inodesc *idesc; char *type; @@ -396,6 +406,7 @@ } } +int findname(idesc) struct inodesc *idesc; { @@ -407,6 +418,7 @@ return (STOP|FOUND); } +int findino(idesc) struct inodesc *idesc; { @@ -422,6 +434,7 @@ return (KEEPON); } +void pinode(ino) ino_t ino; { @@ -436,7 +449,7 @@ dp = ginode(ino); printf(" OWNER="); #ifndef SMALL - if ((pw = getpwuid((int)dp->di_uid)) != 0) + if ((pw = getpwuid((uid_t)dp->di_uid)) != 0) printf("%s ", pw->pw_name); else #endif @@ -449,6 +462,7 @@ printf("MTIME=%12.12s %4.4s ", &p[4], &p[20]); } +void blkerror(ino, type, blk) ino_t ino; char *type; @@ -529,6 +543,7 @@ /* * deallocate an inode */ +void freeino(ino) ino_t ino; { diff -r -u3 fsck/main.c TEST-fsck/main.c --- fsck/main.c Thu Jun 9 12:10:24 1994 +++ TEST-fsck/main.c Mon Jul 25 17:19:01 1994 @@ -57,6 +57,7 @@ void catch(), catchquit(), voidquit(); int returntosingle; +int main(argc, argv) int argc; char *argv[]; @@ -131,6 +132,7 @@ exit(ret); } +int argtoi(flag, req, str, base) int flag; char *req, *str; @@ -148,6 +150,7 @@ /* * Determine whether a filesystem should be checked. */ +int docheck(fsp) register struct fstab *fsp; { @@ -164,9 +167,11 @@ * Check the specified filesystem. */ /* ARGSUSED */ +int checkfilesys(filesys, mntpt, auxdata, child) char *filesys, *mntpt; long auxdata; + int child; { daddr_t n_ffree, n_bfree; struct dups *dp; diff -r -u3 fsck/pass1.c TEST-fsck/pass1.c --- fsck/pass1.c Thu Jun 30 12:31:26 1994 +++ TEST-fsck/pass1.c Mon Jul 25 17:29:07 1994 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include "fsck.h" @@ -50,6 +51,7 @@ int pass1check(); struct dinode *getnextinode(); +void pass1() { ino_t inumber; @@ -88,6 +90,7 @@ freeinodebuf(); } +void checkinode(inumber, idesc) ino_t inumber; register struct inodesc *idesc; @@ -149,7 +152,7 @@ if (doinglevel2 && dp->di_size > 0 && dp->di_size < MAXSYMLINKLEN && dp->di_blocks != 0) { - symbuf = alloca(secsize); + symbuf = alloca((size_t)secsize); if (bread(fsreadfd, symbuf, fsbtodb(&sblock, dp->di_db[0]), (long)secsize) != 0) @@ -161,7 +164,7 @@ } dp = ginode(inumber); bcopy(symbuf, (caddr_t)dp->di_shortlink, - (long)dp->di_size); + (size_t)dp->di_size); dp->di_blocks = 0; inodirty(); } @@ -256,6 +259,7 @@ } } +int pass1check(idesc) register struct inodesc *idesc; { diff -r -u3 fsck/pass1b.c TEST-fsck/pass1b.c --- fsck/pass1b.c Thu Jun 9 12:10:24 1994 +++ TEST-fsck/pass1b.c Mon Jul 25 17:04:58 1994 @@ -46,6 +46,7 @@ int pass1bcheck(); static struct dups *duphead; +void pass1b() { register int c, i; @@ -73,6 +74,7 @@ } } +int pass1bcheck(idesc) register struct inodesc *idesc; { diff -r -u3 fsck/pass2.c TEST-fsck/pass2.c --- fsck/pass2.c Thu Jun 9 12:10:25 1994 +++ TEST-fsck/pass2.c Mon Jul 25 17:29:50 1994 @@ -41,6 +41,7 @@ #include #include #include +#include #include #include #include "fsck.h" @@ -49,6 +50,7 @@ int pass2check(), blksort(); +void pass2() { register struct dinode *dp; @@ -190,6 +192,7 @@ propagate(); } +int pass2check(idesc) struct inodesc *idesc; { @@ -423,6 +426,7 @@ /* * Routine to sort disk blocks. */ +int blksort(inpp1, inpp2) struct inoinfo **inpp1, **inpp2; { diff -r -u3 fsck/pass3.c TEST-fsck/pass3.c --- fsck/pass3.c Thu Jun 9 12:10:25 1994 +++ TEST-fsck/pass3.c Mon Jul 25 17:05:38 1994 @@ -42,6 +42,7 @@ #include #include "fsck.h" +void pass3() { register struct inoinfo **inpp, *inp; diff -r -u3 fsck/pass4.c TEST-fsck/pass4.c --- fsck/pass4.c Thu Jun 9 12:10:25 1994 +++ TEST-fsck/pass4.c Mon Jul 25 17:05:50 1994 @@ -46,6 +46,7 @@ int pass4check(); +void pass4() { register ino_t inumber; @@ -104,6 +105,7 @@ } } +int pass4check(idesc) register struct inodesc *idesc; { diff -r -u3 fsck/pass5.c TEST-fsck/pass5.c --- fsck/pass5.c Thu Jun 9 12:10:26 1994 +++ TEST-fsck/pass5.c Mon Jul 25 17:32:17 1994 @@ -43,6 +43,7 @@ #include #include "fsck.h" +void pass5() { int c, blk, frags, basesize, sumsize, mapsize, savednrpos; @@ -292,15 +293,15 @@ continue; } if (bcmp(cg_inosused(newcg), - cg_inosused(cg), mapsize) != 0 && + cg_inosused(cg), (size_t)mapsize) != 0 && dofix(&idesc[1], "BLK(S) MISSING IN BIT MAPS")) { bcopy(cg_inosused(newcg), cg_inosused(cg), (size_t)mapsize); cgdirty(); } - if ((bcmp((char *)newcg, (char *)cg, basesize) != 0 || + if ((bcmp((char *)newcg, (char *)cg, (size_t)basesize) != 0 || bcmp((char *)&cg_blktot(newcg)[0], - (char *)&cg_blktot(cg)[0], sumsize) != 0) && + (char *)&cg_blktot(cg)[0], (size_t)sumsize) != 0) && dofix(&idesc[2], "SUMMARY INFORMATION BAD")) { bcopy((char *)newcg, (char *)cg, (size_t)basesize); bcopy((char *)&cg_blktot(newcg)[0], diff -r -u3 fsck/preen.c TEST-fsck/preen.c --- fsck/preen.c Thu Jun 9 12:10:26 1994 +++ TEST-fsck/preen.c Mon Jul 25 18:13:21 1994 @@ -39,13 +39,17 @@ #include #include #include +#include #include #include #include #include +#include #include char *rawname(), *unrawname(), *blockcheck(); +void addpart(); +int checkfstab(), startdisk(); struct part { struct part *next; /* forward link of partitions on disk */ @@ -64,8 +68,9 @@ int nrun, ndisks; char hotroot; -checkfstab(preen, maxrun, docheck, chkit) - int preen, maxrun; +int +checkfstab(dopreen, maxrun, docheck, chkit) + int dopreen, maxrun; int (*docheck)(), (*chkit)(); { register struct fstab *fsp; @@ -85,12 +90,12 @@ while ((fsp = getfsent()) != 0) { if ((auxdata = (*docheck)(fsp)) == 0) continue; - if (preen == 0 || passno == 1 && fsp->fs_passno == 1) { + if (dopreen == 0 || passno == 1 && fsp->fs_passno == 1) { if (name = blockcheck(fsp->fs_spec)) { if (sumstatus = (*chkit)(name, fsp->fs_file, auxdata, 0)) return (sumstatus); - } else if (preen) + } else if (dopreen) return (8); } else if (passno == 2 && fsp->fs_passno > 1) { if ((name = blockcheck(fsp->fs_spec)) == NULL) { @@ -102,10 +107,10 @@ addpart(name, fsp->fs_file, auxdata); } } - if (preen == 0) + if (dopreen == 0) return (0); } - if (preen) { + if (dopreen) { if (maxrun == 0) maxrun = ndisks; if (maxrun > ndisks) @@ -226,6 +231,7 @@ return (dk); } +void addpart(name, fsname, auxdata) char *name, *fsname; long auxdata; @@ -257,6 +263,7 @@ pt->auxdata = auxdata; } +int startdisk(dk, checkit) register struct disk *dk; int (*checkit)(); diff -r -u3 fsck/setup.c TEST-fsck/setup.c --- fsck/setup.c Thu Jun 30 12:31:27 1994 +++ TEST-fsck/setup.c Mon Jul 25 17:38:10 1994 @@ -46,6 +46,7 @@ #include #include #include +#include #include #include #include @@ -57,6 +58,7 @@ struct disklabel *getdisklabel(); +int setup(dev) char *dev; { @@ -296,6 +298,7 @@ /* * Read in the super block and its summary info. */ +int readsb(listerr) int listerr; { @@ -370,7 +373,7 @@ altsblock.fs_qfmask = sblock.fs_qfmask; altsblock.fs_state = sblock.fs_state; altsblock.fs_maxfilesize = sblock.fs_maxfilesize; - if (bcmp((char *)&sblock, (char *)&altsblock, (int)sblock.fs_sbsize)) { + if (bcmp((char *)&sblock, (char *)&altsblock, (size_t)sblock.fs_sbsize)) { badsb(listerr, "VALUES IN SUPER BLOCK DISAGREE WITH THOSE IN FIRST ALTERNATE"); return (0); @@ -379,6 +382,7 @@ return (1); } +void badsb(listerr, s) int listerr; char *s; @@ -397,6 +401,7 @@ * can be used. Do NOT attempt to use other macros without verifying that * their needed information is available! */ +int calcsb(dev, devfd, fs) char *dev; int devfd; diff -r -u3 fsck/utilities.c TEST-fsck/utilities.c --- fsck/utilities.c Thu Jun 9 12:10:28 1994 +++ TEST-fsck/utilities.c Thu Jul 28 00:02:49 1994 @@ -47,8 +47,15 @@ #include #include "fsck.h" +#if __STDC__ +#include +#else +#include +#endif + long diskreads, totalreads; /* Disk cache statistics */ +int ftypeok(dp) struct dinode *dp; { @@ -70,6 +77,7 @@ } } +int reply(question) char *question; { @@ -105,6 +113,7 @@ /* * Malloc buffers and set up cache. */ +void bufinit() { register struct bufarea *bp; @@ -189,6 +198,7 @@ } } +void flush(fd, bp) int fd; register struct bufarea *bp; @@ -214,6 +224,7 @@ } } +void rwerror(mesg, blk) char *mesg; daddr_t blk; @@ -226,6 +237,7 @@ errexit("Program terminated\n"); } +void ckfini() { register struct bufarea *bp, *nbp; @@ -261,6 +273,7 @@ (void)close(fswritefd); } +int bread(fd, buf, blk, size) int fd; char *buf; @@ -299,6 +312,7 @@ return (errs); } +void bwrite(fd, buf, blk, size) int fd; char *buf; @@ -335,6 +349,7 @@ /* * allocate a data block with the specified number of fragments */ +int allocblk(frags) long frags; { @@ -365,6 +380,7 @@ /* * Free a previously allocated block */ +void freeblk(blkno, frags) daddr_t blkno; long frags; @@ -379,6 +395,7 @@ /* * Find a pathname */ +void getpathname(namebuf, curdir, ino) char *namebuf; ino_t curdir, ino; @@ -474,6 +491,7 @@ /* * determine whether an inode should be fixed. */ +int dofix(idesc, msg) register struct inodesc *idesc; char *msg; @@ -512,10 +530,24 @@ } /* VARARGS1 */ -errexit(s1, s2, s3, s4) - char *s1; -{ - printf(s1, s2, s3, s4); +void +#if __STDC__ +errexit(const char *fmt, ...) +#else +errexit(fmt, va_alist) + char *fmt; + va_dcl +#endif +{ + va_list ap; + +#if __STDC__ + va_start(ap, fmt); +#else + va_start(ap); +#endif + vprintf(fmt, ap); + va_end(ap); exit(8); } @@ -524,19 +556,34 @@ * Die if preening, otherwise just print message and continue. */ /* VARARGS1 */ -pfatal(s, a1, a2, a3) - char *s; -{ +void +#if __STDC__ +pfatal(const char *fmt, ...) +#else +pfatal(fmt, va_alist) + char *fmt; + va_dcl +#endif +{ + va_list ap; + +#if __STDC__ + va_start(ap, fmt); +#else + va_start(ap); +#endif if (preen) { printf("%s: ", cdevname); - printf(s, a1, a2, a3); + vprintf(fmt, ap); printf("\n"); printf("%s: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.\n", cdevname); + va_end(ap); exit(8); } - printf(s, a1, a2, a3); + vprintf(fmt, ap); + va_end(ap); } /* @@ -544,19 +591,34 @@ * or a warning (preceded by filename) when preening. */ /* VARARGS1 */ -pwarn(s, a1, a2, a3, a4, a5, a6) - char *s; -{ +void +#if __STDC__ +pwarn(const char *fmt, ...) +#else +pwarn(fmt, va_alist) + char *fmt; + va_dcl +#endif +{ + va_list ap; + +#if __STDC__ + va_start(ap, fmt); +#else + va_start(ap); +#endif if (preen) printf("%s: ", cdevname); - printf(s, a1, a2, a3, a4, a5, a6); + vprintf(fmt, ap); + va_end(ap); } #ifndef lint /* * Stub for routines from kernel. */ +void panic(s) char *s; { From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:52:54 1994 From: "Charles M. Hannum" To: michaelv@iastate.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: SLIP/PPP crashes Sender: owner-current-users@sun-lamp.cs.berkeley.edu First of all, look at the message you typed in: trap type 6 code f8100000 eip f8100ff9 es f7bf0008 eflags 13292 cr2 f0 cpl ffffffff I'd guess that %eip is near the end of cpu_switch(), but you can `nm /netbsd | sort | more' and see for yourself where it is. If it's the same instructions that's at that address on my machine, then either the kernel's %esp or the page table is corrupted. The second thing to note is that %eflags includes both IOPL bits. This means the process has I/O privileges. Are you running an X server on this machine? A stack trace from DDB and a copy of your kernel would supply more information. From owner-current-users@sun-lamp.cs.berkeley.edu Sat Jul 30 23:53:00 1994 From: Mike Long To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: msdosfs Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Sat, 30 Jul 94 15:55:23 edt >From: mycroft@gnu.ai.mit.edu > > > Also, mount_msdos doesn't understand the -o flag, which means that I > can't use mount -u on my DOS partition. > >Sounds like you're using an old version. You're right, I'm using the 7/13 bindist version, and the fixes from ws were committed on the 16th. Could an out-of-date mount_msdos be the source of the hanging as well? If it helps, my MSDOS partition is 125MB (2K clusters), and it's almost full. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 00:02:31 1994 Subject: Maxoptic Tahiti with NetBSD To: amiga@sun-lamp.cs.berkeley.edu From: "Rullier Pascal" X-Face: #F0"PX*,8kfyAH)]24lp&.qI3Iq,qaGHi,2:,r`{lnr'028~lhk9D/[}pUZ0KwpH~1v-0Uh u:gN}QD12Xa-;;4i0Kv8[ir^G#PPX^RcCYaAx4d37(7h62*z8"y1NB Subject: summary: kermit fix (and kill -STOP) Thanks all who helped! To: current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 3827 Sender: owner-current-users@sun-lamp.cs.berkeley.edu All, Thanks, everyone, who sent help WRT my Kermit problem. Here's a summary of what I've done for anyone still struggling: First off, I deleted my /dev/com? files and only used the /dev/tty0? files. I guess they're a throwback from 0.9? I changed my modem line in /etc/ttys to read: tty00 "/usr/libexec/getty std.9600" unknown off secure local (I added the "local" flag...) I then got C-Kermit 5a(190) from kermit.columbia.edu:/kermit/test/bin/cku190.tar.gz and applied the following patch to ckutio.c: (I know this probably isn't the right way to show a patch, but you can figure out what to do from this. I got this by doing a "diff ckutio.c ckutio.c.dist" or maybe the file order was switched. Anyone have the dirt on how to make a patch file correctly? Someone sent me a patch that failed, but I patched by hand to get this. (Thanks!)) 7179d7178 < #ifndef __NetBSD__ 7182,7185d7180 < #else < #define switchuid(hidden,active) seteuid(active) < #define switchgid(hidden,active) setegid(active) < #endif Then, I did a "make bsd44 KFLAGS=-DNOCOTFMC" on kermit. It produced a binary called "wermit" which I renamed and moved to /usr/local/bin. I chmodded it 4755 and chowned it to uucp. My tty0? files are rw by uucp only. (well, actually, now they're rw by everyone because else I couldn't get "term" to write to the device. I suppose I could patch the source in a similar way as kermit's seteuid, etc... Finally, I needed a way to have kermit be suspended, but not the calling shell script. Under 0.9, I just did a "!kill -STOP kermit_pid" in my kermit script. (Kermit's suspend command would stop the calling /bin/sh script as well. Well, under 1.0-alpha, that kill would stop the calling script as well. Why is this? I've thought of some things that might have changed: 1) behavior of kill(1) (I don't think so - 0.9's kill had same prob...) 2) effect of -STOP signal changed 3) /bin/sh scripts no longer set child's pgrp to a new value 4) voodo magic If anybody, know, please tell why. I'm curious. Anyhow, I wrote (after advice from a fellow user on The List) the following C program, which is probably really crappy because I haven't written anything meaningful in C for quite a while, and I had to make liberal use of the "man" comman, and even "man -k" in order to write this. but, it works. If anyone cleans it up, please send me the new version just for laughs. Here it is: wrapper.c ---CUT HERE--- /* WRAPPER - set PGID to PID and system() a command for you Written by willeyma@sage.cc.purdue.edu (soon to be @expert.cc...) Nah, it ain't copyrighted. What do I care? ;-) This program will set the PGID to the PID and then call a command, so that you can force a PGID change for signalling purposes... It compiles under NetBSD-current (July, 1994), and hopefully on your UNIX of choice. Fri Jul 29 1994 (Okay, so I wrote it on a Friday night... So??? ;-) ) */ #include #include #include #include main (int argc, char *argv[]) { short pgid, pid, ppid, set_failed; int errno, err; char *command[300]; if (argc != 2) { fprintf (stderr, "\nusage:\n\n\twrapper command\ncommand - command to execut e\n\n"); exit (1); } strncpy (command, argv[1], 299); pid = getpid(); set_failed = setpgrp (getpid(), pid); if (set_failed) { err = errno; ppid = getppid(); perror ("wrapper error: "); fprintf (stderr, "wrapper error: setpgrp (%d, %d) failed!\n",err,pid,pgid); fprintf (stderr, "wrapper error: number %d\n",err); exit (2); } system (command); } ---CUT HERE--- --- Ask me about FREE UNIX and X for your PC. http://www.ecn.purdue.edu:8001/data/users/willey/mfw.html willeyma@sage.cc.purdue.edu SOON TO BE @expert.cc... Mark Willey From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 01:03:29 1994 From: der Mouse To: mycroft@gnu.ai.mit.edu Subject: Re: more(1) is broken Cc: Mike.Long@analog.com, current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu > I can't reproduce this with either pccons or pcvt. Are you sure > you're using a correct termcap entry? It actually sounds to me more like what I see when the terminal size determined by more(1) doesn't match the real size. This can happen either by having incorrect nonzero values in the kernel ("stty size") or by having zeroes in the kernel and having a terminal type set whose termcap entry specifies a size different from the actual size. Check "stty size" and perhaps try "stty rows 25 cols 80" (I think you said 80x25, didn't you?) and see if that helps any. der Mouse mouse@collatz.mcrcim.mcgill.edu From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 02:33:47 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: trouble labeling floppies? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm probably out of sync (since I thought I remember someone talking about this already), but using a kernel I built today, I could not label a floppy to save my life. I finally commented out the error return in disklabel.c and then it worked. if (ioctl(f, DIOCSDINFO, lp) < 0 && errno != ENODEV && errno != ENOTTY) { l_perror("ioctl DIOCSDINFO"); /* return (1);*/ } My kernel is from a sup yesterday and I rebuilt the disklabel today. I'll do more homework on this tommorow - just thought I'd say something. -brad From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 03:02:28 1994 From: ozzy@catt.ncsu.edu (Chris Mattingly) Posted-Date: Sat, 30 Jul 1994 20:22:22 -0400 (EDT) Subject: Re: forwarded message from Jukka Forsgren To: cherry@crunk.planet.net (Andrew Cherry) Cc: amiga@sun-lamp.cs.berkeley.edu Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 787 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Previously, Andrew Cherry wrote: > > > > I've heard at least one other report of problems with SCSI lockups; > > has anyone else had these problems or have any insights into them? > > > I'am also having problems with those lockups. I have an A3000/25, 120MB & > 105MB Quantum and 6MB of memory.. I have as well. A3000/25 6 megs, only one drive has netbsd stuff on it... a 325 meg seagate. It usually only happens during major swapping and major moves from one partition to the other. -Chris -- Chris Mattingly | Computer and Technologies Theme Program, NCSU, Raleigh 406-G Wood Hall | Head System Administrator PO Box 21541 | NCSU | Home computer: A3000 - crazytrain.catt.ncsu.edu Raleigh, NC 27607 | (919) 512-0931 | Email: Chris_Mattingly@ncsu.edu From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 03:07:41 1994 Sender: owner-amiga@sun-lamp.cs.berkeley.edu id m0qUOp9-0001fLC; Sat, 30 Jul 94 19:32 CDT Message-Id: From: spcmilo@hydra.spc.uchicago.edu (David Champion) Subject: Re: forwarded message from Jukka Forsgren To: amiga@sun-lamp.cs.berkeley.edu Date: Sat, 30 Jul 1994 19:32:18 -0500 (CDT) In-Reply-To: <199407302057.QAA00313@crunk.planet.net> from "Andrew Cherry" at Jul 30, 94 04:57:49 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 758 Status: OR > > I've heard at least one other report of problems with SCSI lockups; > > has anyone else had these problems or have any insights into them? > > > I'am also having problems with those lockups. I have an A3000/25, 120MB & > 105MB Quantum and 6MB of memory.. My SCSI locks up so often I can't build a new kernel to even try to stop it. (I'm about halfway through a build now, after 6 or 7 reboots and a few filesystem repairs.) I might be the "one other report" that Andrew mentioned -- thanks, but your kernel didn't help me any. A3000/25; Quantum LPS52, Empire 540. HP DAT connected, but not always powered on. This is with any kernel from mid-June to 21 Jul. I'm about to completely reinstall the system based on the -release now at sun-lamp. FYI. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 03:17:41 1994 From: brad@fcr.com (Brad Parker) To: current-users@sun-lamp.cs.berkeley.edu Subject: wd0: wdcontrol: wd command failed: status 0 error 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Now that I got floppies to label ;-) I'm trying to bring up a 2nd machine which was running NetBSD 0.9 just peachy up to several hours ago. Initially I tried just replacing the kernel with a 1.0_Beta kernel, to see if it would boot cleanly. (note that I did update the boot tracks) The wd probe took longer than I expected and after all the probes were done the kernel hung with the message: wd0: wdcontrol: wd command failed: status 0 error 0 So, I built some boot floppies. The script someone posted was great, but it had a few bugs which I fixed. The boot floppy does the same thing. I even tried the exact same kernel I'm running happily with on my primary machine. Both machines a 8mb 486/33's. The working machine has a VL bus IDE controller. The non-working machine has a generic ISA bus IDE controller. The working machine boots off wd1. The non-working machine is partitioned into 2 drives. I tried removing the old netbsd partition and reformatting the parition. This did not help. (I thought maybe the label was corrupted in some weird way). again - I'll do some more homework on this tommorow, but I thought I'd whine first ;-) -brad From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 03:36:06 1994 From: mycroft@gnu.ai.mit.edu To: brad@fcr.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: wd0: wdcontrol: wd command failed: status 0 error 0 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Sigh. In wdcwait(), try changing `wd_altsts' to `wd_status'. If that works, I *guess* I'll change it in our tree, but I'll be rather annoyed about it. So much broken hardware... From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 04:11:10 1994 From: mycroft@gnu.ai.mit.edu To: brad@fcr.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: trouble labeling floppies? Sender: owner-current-users@sun-lamp.cs.berkeley.edu Whoever wrote the original floppy labeling code apparently didn't grok the difference between DIOCSDINFO and DIOCWDINFO. I just fixed this. When I tested this recently, I was only writing new boot blocks, which seems to work with the old code. Anyway, here's my change, which should show up on lamp eventually: =================================================================== RCS file: /b/source/CVS/src/sys/arch/i386/isa/fd.c,v retrieving revision 1.49 diff -c -2 -r1.49 fd.c *** 1.49 1994/07/26 19:36:06 --- fd.c 1994/07/31 00:46:30 *************** *** 1152,1156 **** return 0; - case DIOCSDINFO: case DIOCWDINFO: if ((flag & FWRITE) == 0) --- 1152,1155 ---- *************** *** 1165,1170 **** default: ! return EINVAL; } #ifdef DIAGNOSTIC panic("fdioctl: impossible"); --- 1164,1170 ---- default: ! return ENOTTY; } + #ifdef DIAGNOSTIC panic("fdioctl: impossible"); From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 05:30:29 1994 From: jtkohl@MIT.EDU To: current-users@sun-lamp.cs.berkeley.edu Subject: wddump not working: is there something timing dependent? X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Content-Length: 1031 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I'm trying to get crashdumps on a 486/100 box with a localbus IDE controller. After I increased the delay loop at the end of dumpsys() so that I could read messages, I find that the crash dump is failing with an error wd0: wddump: extra drq: status 0 error 0 If I make the wddump() routine ignore those errors, the dump will appear to complete, but it's garbage--nowhere in the entire dump partition does the dump magic number appear on a longword alignment boundary. Might this be something timing dependent in the wddump loop? I tried putting delays in a few spots, but always got "extra drq" messages and the dump was always garbage. [I need to get a good crashdump to find the bug which is causing a crash when I exit some programs being executed off an AFS filesystem. It only seems to happen with X running, and ddb is thus useless. arg. Or perhaps someone can point me to instructions on remote console debugging and I can bring in another 486 box for testing...?] A rapid reply would be most appreciated. ==John From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 06:22:00 1994 From: Mike Long To: mouse@Collatz.McRCIM.McGill.EDU Cc: mycroft@gnu.ai.mit.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: more(1) is broken Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu >Date: Sat, 30 Jul 1994 17:38:18 -0400 >From: der Mouse >Check "stty size" and perhaps try "stty rows 25 cols 80" (I think you >said 80x25, didn't you?) and see if that helps any. No, that's not it; 'stty size' gives me '25 80' for output, and the problem still occurs. more(1) and/or curses thinks that my screen is 8 rows tall for some other reason. FYI, the only terminal-related code in my .login is 'tset -Q'. -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 07:34:21 1994 From: jtkohl@MIT.EDU To: current-users@sun-lamp.cs.berkeley.edu Subject: well, figured it out anyway...AFS now works! X-Us-Snail: Atria Software Inc., 24 Prime Park Way, Natick, MA 01760 Content-Length: 635 Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, I finally caught one of the kernel vm faults while on the console, and fixed the bug, so I'm glad to say that AFS is now working on NetBSD/i386 1.0_BETA. It's currently compiled directly into the kernel and only using a memory cache. I plan on making it a LKM and making it use FFS for cache storage. If you are a Transarc source code licensee and are interested in being a beta tester for this stuff (particularly if you want to try it on non-i386 ports), please contact me individually. If you aren't a licensee, hold tight for now...MIT and Transarc may be able to make arrangements for a binary LKM distribution. ==John From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 09:21:06 1994 From: Berend Ozceri To: amiga@sun-lamp.cs.berkeley.edu Subject: Sun binary compatibility... Sender: owner-amiga@sun-lamp.cs.berkeley.edu After finally getting my first-ever NetBSD installation to work (hey, I am actually writing this message from my Amiga NetBSD via SLIP), I have a big question: What is the state of NetBSD's compatibility with Sun 3.xx (MC680xx) binaries? I just tried running some binaries and they all seg-faulted. I am running the netbsd-almostgeneric.940721 kernel on an A4000/040. Is this a problem with my setup? Is there a binpatch for Sun compatibility? Do I need to compile a new kernel? (please say no!) Or is it just hopelessly impossible? Thanks and kudos to all the people working on Amiga NetBSD and NetBSD in general. Berend Ozceri Carnegie Mellon University From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 09:51:32 1994 From: John Kohl To: mark@aggregate.com Cc: jconklin@netcom.com, scottr@plexus.com, current-users@sun-lamp.cs.berkeley.edu Subject: Re: Taylor UUCP 1.05 X-Us-Snail: 8 Lorne Road, Arlington, MA 02174 Sender: owner-current-users@sun-lamp.cs.berkeley.edu I've already merged Tuucp 1.04/1.05 changes into a NetBSD-current/1.04 base. It's at work, and I've built it at home, but haven't fully tested it yet. Do the core folks want this for 1.0-final, or is this too much of a change too late in the game ? ==John From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 10:17:01 1994 From: Andrew Cagney X-Andrew-Message-Size: 1151+0 Mime-Version: 1.0 Content-Type: text/richtext; charset=US-ASCII Content-Transfer-Encoding: quoted-printable To: andrew@wipux2.wifo.uni-mannheim.de (Andrew Wheadon) Subject: Re: patch for csh needed ? Cc: netbsd-current-users@sun-lamp.cs.berkeley.edu Sender: owner-current-users@sun-lamp.cs.berkeley.edu Hi, Is it still in there? Excerpts from mail: 30-Jul-94 patch for csh needed ? Andrew Wheadon@wipux2.wi (1373*) I'm wondering whether it's a) not a bug It's a bug. It's also a bl****y obscure bug :-) I found it long ago when trying to build auis-5.1 on NetBSD-0.9. At the time I posted it to comp.os.386bsd.bugs and more recently, for AUIS-6.3 & NetBSD-current, to this mailing list. FreeBSD independantly found and fixed it long ago. b) been fixed differently No. FreeBSD did fix it by using what the SAVE() macro expands to. I like my patch better :-). Maybe, the heap management code is now more robust so your less likely to encounter it. c) still needs fixing. Yes. To be honest, I didn't get tickled by it when building auis-6.3. It is, however, certainly still there. Have a look at the code for `csh/dir.c:dcanon()'. It dos an `xfree()' on its its first argument. With out the SAVE(tcp) on the call to dcanon() in csh/dir.c:dinit(), dcanon() frees the array path (tcp =3D getwd(path) implies tcp =3D=3D path) that was allocated from the stack (char path[MAXPATHLEN]). After this happens, all bets are off. regards, Andrew From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 11:07:19 1994 From: Mike Long To: current-users@sun-lamp.cs.berkeley.edu Subject: some observations Organization: Analog Devices Inc, Norwood MA, USA Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, reinstalling 0.9 to get more reasonable partitions and bringing my system all the way back up to -current wasn't as painful as I originally feared. I did run into some 'gotchas' along the way, though: 1) /dev/vga should be in the set of /dev entries created by 'MAKEDEV std', because /etc/ttys needs it. Bad Things happen when you can't start up a getty on your console because /dev/vga doesn't exist.... 2) MAKEDEV uses chgrp, which now lives under /usr/bin. Is it correct to assume that MAKEDEV will only be used when /usr is mounted? 3) The new /bin/sh message about . in root's path is a profiling aid of a sort; whenever you see it, you know a new copy of /bin/sh has been started. :-) Shouldn't you take your own advice and take . out of the PATH in /.profile, /root/.login, &c.? Time to go to sleep. |-) -- Mike Long Mike.Long@Analog.com VLSI Design Engineer (PGP 2.6 public key available) Analog Devices, CPD Division Norwood, MA 02062 USA assert(*this!=opinionof(Analog)); From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 12:18:52 1994 From: sjg@zen.void.oz.au (Simon J. Gerraty) To: current-users@sun-lamp.cs.berkeley.edu Subject: NetBSD-1.0 looking good, but should old binaries still work? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I finally got a chance to fire up the July 13 i386 binary snapshot this weekend. My main purpose was to check whether the new scsi drivers could read my tape drives correctly. NetBSD-Feb12 and earlier never got the last few blocks off a tape which made restore a bit iffy :-) I re-installed my IDE drive and managed to load the binaries onto it. This would have been easier if I could have booted of sd0a, but the boot loader just kept saying "sd* not found". Since it was the boot blocks on the IDE drive I don't recall how old they are - I haven't had the disk in the system since Feb... Anyway, I got it up and running, and the SCSI drivers worked flawlessly! Why was I worried? Because previously the _only_ drivers that worked 100% were a version Julian did back in August last year for 386bsd, with the next version I could not even get a kernel to boot. NetBSD-Feb12 has been extremely reliable (not a single hang or panic since I removed the IDE drive in Feb), and I'm very happy with it, but with the new scsi drivers NetBSD-1.0 is looking even better. I was very surprised that a ksh binary that had been sitting on the IDE disk since Feb20, ran happily under NetBSD-1.0. Given that much code needed source changes to compile/work correctly after the off_t changes, I assumed that old binaries would almost certainly not work. If I am wrong, then I can update to 1.0 asap, as I can continue to use my BSDi binary version of MHSnet. So the question, after updating to NetBSD-1.0, could I expect a NetBSD-0.9 vinatage BSDi binary to continue to function correctly? If not, I'll have to wait until BSDi update to 64bit off_t's and a new version of MHSnet comes out. MHSnet is the latest ACSnet software that most *.oz.au machines run, I could switch back to UUCP, but MHSnet is much more efficient with data transfers being automagically restarted where they left off etc and 3 multiplexed chanels for hi,med,low/bulk priority traffic. Regardless, NetBSD-1.0 is going to be great! --sjg From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 12:45:26 1994 From: mycroft@gnu.ai.mit.edu To: andrew@wipux2.wifo.uni-mannheim.de, current-users@sun-lamp.cs.berkeley.edu Subject: Re: patch for csh needed ? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I just committed this patch, but I'm inclined to point out that the *only* reason I did is that I found an explanation for it elsewhere. In the future, please include a test case and/or enough of an explanation that it's obvious what's wrong or easy to create a test case. Your bug report did none of the above. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:22:53 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, sjg@zen.void.oz.au Subject: Re: NetBSD-1.0 looking good, but should old binaries still work? Sender: owner-current-users@sun-lamp.cs.berkeley.edu There was a two-week period around the beginning of April, where binaries compiled during that time will no longer run. Other than that any executable ever built under NetBSD should continue to work, modulo differences in the DB library between 0.8 and 0.9, and the existance of the correct shared library versions for dynamically linked executables. I still run a copy of `rc' that was built under 0.8, as my shell on sun-lamp. B-) (Note that you need `COMPAT_09' in your kernel for the above to be true...) From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:39:54 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, michaelv@iastate.edu Subject: Re: problems with source tarballs Sender: owner-current-users@sun-lamp.cs.berkeley.edu What happens on the kernels I build is this: it goes through all the autoconfiguration stuff, and everything looks like it's working ok. Then it finally gets to the part at the end where it prints the ttymask, biomask, etc. stuff. Right there it just sits forever, [...] Are you still having this problem? From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:40:49 1994 From: mycroft@gnu.ai.mit.edu To: XFree86-beta@xfree86.org, current-users@sun-lamp.cs.berkeley.edu, j@julia.tcd-dresden.de Subject: Re: multiple X servers under pcvt? Sender: owner-current-users@sun-lamp.cs.berkeley.edu I never had problems with running multiple servers under pcvt. This is with FreeBSD ~ 1.1. Religious issues aside [Ahem.], I can't reproduce this under NetBSD, and I have tried reasonably hard. This would indicate to me that it's a timing problem, and very hardware-specific. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:41:11 1994 Subject: Confirmation: ppp problems are gone 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: 373 Sender: owner-current-users@sun-lamp.cs.berkeley.edu The recent changes to the kernel fixed all problems I found with ppp. It now works realy stable again. Great work! Martin -- UNIX - An operating system similar to OS-9, but with less functionality and special features designed to soak up excess memory, disk space and CPU time on large, expensive computers. -- OS-9 Glossary From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:41:42 1994 From: mycroft@gnu.ai.mit.edu To: buhrow@cats.ucsc.edu, current-users@sun-lamp.cs.berkeley.edu Subject: Re: I NEED INFORMATION ON THE AST MULTIPORT SERIAL MULTIPLEX DRIVER Sender: owner-current-users@sun-lamp.cs.berkeley.edu The answers to all of the questions you asked is `yes'. The is no significant different between a `com' port attached to an `ast' and any other `com' port, except the way interrupts are handled. The `ast' driver itself is for multiplexing the interrupt. If your card is in `compatible' mode, then it's using one IRQ per serial line, and you shouldn't use the ast driver. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 13:42:08 1994 From: mycroft@gnu.ai.mit.edu To: current-users@sun-lamp.cs.berkeley.edu, surprenc@jsp.umontreal.ca Subject: Re: Bootstraping current installation Sender: owner-current-users@sun-lamp.cs.berkeley.edu Has anybody made bootable floppy images anywhere with current? Finishing the installation tools is the primary thing holding up the release at this point. Last question: my filesystem was 4.3 when I made the backup using dump, will I be able to do a restore on a 4.4 filesystem? You can now. There was a bug relating to this in the original 4.4-Lite code, but it's been fixed. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 14:05:27 1994 To: apana-lists-os-netbsd-general@apana.org.au Path: news From: markd@bushwire.apana.org.au (Mark Delany) Newsgroups: apana.lists.os.netbsd.general Subject: Re: problems with source tarballs Organization: APANA regional feed site - Melbourne, Australia. Lines: 20 Sender: owner-current-users@sun-lamp.cs.berkeley.edu mycroft@gnu.ai.mit.edu writes: > What happens on the kernels I build is this: it goes through all the > autoconfiguration stuff, and everything looks like it's working ok. > Then it finally gets to the part at the end where it prints the > ttymask, biomask, etc. stuff. Right there it just sits forever, > [...] >Are you still having this problem? Not wanting to throw any red herrings into the ring, but I had a similar problem when I upgraded from 0.9a to 0.9B. It turned out to be a config problem which was solved when I added the 'master' config param. In my case that was: master scsibus0 at bt0 M. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 14:20: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: Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun Jul 31 03:48:17 1994 SUP Scan for current completed at Sun Jul 31 03:51:34 1994 SUP Scan for mirror starting at Sun Jul 31 03:51:35 1994 SUP Scan for mirror completed at Sun Jul 31 03:54:10 1994 From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 15:15:17 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: "Charles M. Hannum" Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: IRQ and DRQ autoconfiguration <199407271343.JAA18573@duality.gnu.ai.mit.edu> Sender: owner-current-users@sun-lamp.cs.berkeley.edu "Charles M. Hannum" writes: > I've just enabled some old code I had written in the aha, ahb, bt, and > uha drivers, to use the IRQ and DRQ read off the board at boot time, > rather than statically configuring the info into the kernel. I changed the irq and drq entries in my config, and the driver still works fine, although it prints "irq 0" during autoconfig. >From my config: controller uha0 at isa? port 0x340 irq ? drq ? #controller uha0 at isa? port 0x340 irq 11 drq 5 >From dmesg: uha0 at isa0 port 0x340-0x9a5 irq 0 scsibus0 at uha0 uha0 targ 0 lun 0: SCSI1 direct fixed sd0 at scsibus0: 992MB, 1931 cyl, 15 head, 70 sec, 512 bytes/sec uha0 targ 1 lun 0: SCSI1 sequential removable st0 at scsibus0: rogue, density code 0x0, 1024-byte blocks, write-protected 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 Jul 31 15:27:04 1994 X-Authentication-Warning: cis-ts3-slip4.cis.brown.edu: Host localhost didn't use HELO protocol From: Mark_Weaver@brown.edu To: current-users@sun-lamp.cs.berkeley.edu Subject: References to "vmunix" Sender: owner-current-users@sun-lamp.cs.berkeley.edu I did a: cd /usr/src; find . -type f -name "*.[ch1-8]" | grep -n vmunix Here's the output from July 27th's complete source tree: ./bin/ps/ps.1:101:.Dq Pa /vmunix . ./bin/ps/ps.1:478:.Bl -tag -width /var/run/kvm_vmunix.db -compact ./bin/ps/ps.1:487:.It Pa /var/run/kvm_vmunix.db ./bin/ps/ps.1:489:.It Pa /vmunix ./gnu/usr.bin/gdb/gdb/infptrace.c:188: if (nlist ("/vmunix", names) == 0) ./lib/libc/sys/reboot.2:66:.Dq Em xx Ns No (0,0)vmunix , ./lib/libc/sys/reboot.2:127:rebooted from file ``vmunix'' in the root file system of unit 0 ./lib/libkvm/kvm.c:229: * here so that we don't have to hold on to the vmunix ./lib/libkvm/kvm_nlist.3:74:.Bl -tag -width /var/db/kvm_vmunix.db -compact ./lib/libkvm/kvm_nlist.3:75:.It Pa /var/db/kvm_vmunix.db ./lib/libkvm/kvm_private.h:54: int nlfd; /* namelist file (e.g., /vmunix) */ ./libexec/rpc.rstatd/rstat_proc.c:141: int n = nlist("/vmunix", nl); ./libexec/identd/paths.h:60:# define _PATH_UNIX "/vmunix" ./sbin/dmesg/dmesg.8:55:``/vmunix''. ./sbin/reboot/reboot_sparc.8:133:The rom will normally load the kernel from "sd(0,0,0)vmunix". To change the ./sbin/routed/defs.h:80:int performnlist; /* if 1 check if /vmunix has changed */ ./sbin/savecore/savecore.c:100:char *vmunix; ./sbin/savecore/savecore.c:151: vmunix = optarg; ./sbin/savecore/savecore.c:169: vmunix = argv[1]; ./sbin/savecore/savecore.c:222: dump_sys = vmunix ? vmunix : _PATH_UNIX; ./sbin/savecore/savecore.c:254: if (vmunix) ./sbin/savecore/savecore.c:276: if (strcmp(vers, core_vers) && vmunix == 0) ./sbin/savecore/savecore.c:414: ifd = Open(vmunix ? vmunix : _PATH_UNIX, O_RDONLY); ./sbin/savecore/savecore.c:435: "WARNING: vmunix may be incomplete"); ./sbin/savecore/savecore.c:441: vmunix ? vmunix : _PATH_UNIX, strerror(errno)); ./sbin/savecore/savecore.c:443: "WARNING: vmunix may be incomplete"); ./sbin/savecore/savecore.c:533: char *tvmunix; ./sbin/savecore/savecore.c:534: off_t minfree, spacefree, vmunixsize, needed; ./sbin/savecore/savecore.c:539: tvmunix = vmunix ? vmunix : _PATH_UNIX; ./sbin/savecore/savecore.c:540: if (stat(tvmunix, &st) < 0) { ./sbin/savecore/savecore.c:541: syslog(LOG_ERR, "%s: %m", tvmunix); ./sbin/savecore/savecore.c:544: vmunixsize = st.st_blocks * S_BLKSIZE; ./sbin/savecore/savecore.c:562: needed = (dumpsize + vmunixsize) / 1024; ./sys/arch/i386/netboot/main.c:314: ".vmunix", ./sys/arch/i386/netboot/main.c:315: ".vmunix.old", ./sys/arch/i386/stand/boot.c:64: "vmunix", "ovmunix", "vmunix.old", ./sys/arch/sparc/include/bsd_openprom.h:151: char *ba_kernel; /* kernel to boot, e.g., "vmunix" */ ./sys/arch/sparc/include/bsd_openprom.h:186: char **pv_bootstr; /* Boot command, eg sd(0,0,0)vmunix */ ./sys/arch/sparc/sparc/autoconf.c:163: * "vmunix -s" or whatever. ./sys/arch/sun3/include/mon.h:183: int (*reBoot)(); /* e.g. reBoot("xy()vmunix") */ ./sys/arch/pmax/pmax/autoconf.c:312: * Boot names can be something like 'rz(0,0,0)vmunix' or '5/rz0/vmunix'. ./sys/arch/pmax/stand/libsa/devopen.c:62: /* look for a string like '5/rz0/vmunix' or '5/rz3f/vmunix */ ./sys/arch/pmax/stand/libsa/devopen.c:90: /* expect a string like 'rz(0,0,0)vmunix' */ ./sys/arch/pmax/stand/boot.c:50: * Argv[0] should be something like "rz(0,0,0)vmunix" on a DECstation 3100. ./sys/arch/pmax/stand/boot.c:51: * Argv[0,1] should be something like "boot 5/rz0/vmunix" on a DECstation 5000. ./sys/arch/pmax/stand/boot.c:52: * The argument "-a" means vmunix should do an automatic reboot. ./sys/arch/pmax/stand/mkboottape.c:67: * usage: mkboottape [-b] tapedev vmunix minirootdev size ./sys/arch/pmax/stand/mkboottape.c:236: "usage: %s [-b] tapedev vmunix minirootdev size\n", __progname); ./sys/nfs/swapnfs.c:38: * @(#)nfsswapvmunix.c 7.1 (Berkeley) 3/4/91 ./sys/sys/systm.h:65: * zero as that would allow the vmunix binary to be patched to -1. ./sys/lib/libnetboot/exec.c:57: "vmunix", "ovmunix", "vmunix.old", NULL ./usr.bin/fstat/fstat.1:76:.Pa /vmunix . ./usr.bin/netstat/netstat.1:149:.Pa /vmunix . ./usr.bin/netstat/netstat.1:284:.\" .It Pa /vmunix ./usr.bin/nfsstat/nfsstat.1:62:.Pa /vmunix . ./usr.bin/nfsstat/nfsstat.1:72:.It Pa /vmunix ./usr.bin/w/uptime.1:50:.Bl -tag -width /vmunix ./usr.bin/w/uptime.1:51:.It Pa /vmunix ./usr.bin/w/w.1:75:.Dq /vmunix . ./usr.sbin/sendmail/src/conf.c:656:# define _PATH_UNIX "/vmunix" ./usr.sbin/config.new/config.h:67: const char *cf_name; /* "vmunix" */ Mark -------------------------------------------------------------------- Email: Mark_Weaver@brown.edu | Brown University PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 16:49:29 1994 From: "Hubert Feyrer" "Problems..." (Jul 29, 4:14am) X-Mailer: Z-Mail (3.0.1 04apr94) To: Berend Ozceri , amiga@sun-lamp.cs.berkeley.edu Subject: Re: Problems... Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 29, 4:14am, Berend Ozceri wrote: > Under both kernels, when I boot netbsd everything goes fine and I get > the shell prompt in single-user mode. At this point most of the binaries > work fine (things like ls, cp, cd, mount, mount_ados, etc.) but many > other things give me a "Floating exception (core dumped)". For example, > "more" will give me that exception. I think I have everything setup > right (I have /usr/libexec). What is the problem? I guess that the kernels you've tried don't have the floating-point support for the '040 compiled in (option FPSP). Try the "netbsd-almostgeneric"-kernel, if should work if this is a matter of the '040's FPU. > Also, isn't fastboot (or the sequence umount -av; sync; reboot) supposed > to reboot to the Amiga side? In my case it attempts to reboot, but gets > stuck with a gray screen. No matter how many times I do a > ctrl-amiga-amiga, I get stuck with the same gray screen, leaving me with > no choice but to power-cycle the Amiga. Needless to say, haveing to > powercycle the Amiga every ten minutes does not amuse me. Any help? No help, but just curious: how much RAM do you have? 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 Jul 31 16:51:30 1994 From: Robert Shady Subject: Re: GET THIS BOOK :) To: kenh@wrl.epi.com (Ken Hornstein) Cc: peter@alice.wonderland.org, current-users@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1132 Sender: owner-current-users@sun-lamp.cs.berkeley.edu >>Just for those amongst you who have the tollerance to satire and the >>time, get this book: >> >> The UNIX Haters Handbook >> Simson Garfinkel, Daniel Weise & Steven Strassmann >> Publisher: IDG Books >> ISBN: 1-56884-203-1 > > You know, I just read that book a few days ago, and I have to say that I was > not very impressed with it. Most of the arguments seem rather contrived; it > almost seemed that they took every feature of Unix and came up with reasons > that they hated it. There's a lot of gross oversimplification ("The only > reason Unix was written was because Ken Thompson wanted to play > Space Travel"), some re-writing of history ("Remember when e-mail used > to work, before Unix?"), and some things that are just plain dumb > ("Screen handling functions should be in the kernel, where they belong... > just like VMS"). They make a few valid points, but they don't seem to > offer any better alternatives. I get the feeling that these people > wouldn't be happy with _any_ computer system. We could always start: "The UNIX Haters Haters Handbook" And jot down everything GOOD about UNIX.. ;) From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 31 17:45:35 1994 From: "Stephen J. Roznowski" To: amiga-dev@sun-lamp.cs.berkeley.edu Subject: floppy hangs Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I'm running 1.0-ALPHA from the ~16 Jun sup, and I'm still getting floppy hangs -- when accessing the floppy, the system will lock up and I need to reboot. Has this been fixed, or what can I do to help track this down? -SR From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 18:59:54 1994 From: tjhayko@io.org (Tom Hayko) Subject: Problems with snapshot on net-1.iastate.edu To: amiga@sun-lamp.cs.berkeley.edu X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 527 Sender: owner-amiga@sun-lamp.cs.berkeley.edu I'm trying to upgrade my NetBSD installation on my WarpEngine equipped A4000 to the latest version, so I downloaded the archives from net-1.iastate.edu last night, and when I try to run the new kernel, it starts up (in interlaced mode, yuck), finds my disks, and then starts printing the message 'unexpected trap vector offset 2 from 10080000' repeatedly, and then stops and hangs. Then I have to reboot my machine. I've tried running loadbsd with -S but it never goes into the debugger. Any ideas? Tom Hayko tjhayko@io.org From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 20:17:11 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: tjhayko@io.org (Tom Hayko), amiga@sun-lamp.cs.berkeley.edu Subject: Re: Problems with snapshot on net-1.iastate.edu Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 31, 12:14pm, Tom Hayko wrote: > I'm trying to upgrade my NetBSD installation on my WarpEngine equipped > A4000 to the latest version, so I downloaded the archives from > net-1.iastate.edu last night, and when I try to run the new kernel, it It looks like the kernel that's on iastate is probably the one that has a bug in the hydra Ethernet driver. The fix was made about July 26, but the kernel on iastate looks like it was made on July 21. Sun-lamp should have a newer kernel that includes that fix. > starts up (in interlaced mode, yuck), finds my disks, and then starts > printing the message 'unexpected trap vector offset 2 from 10080000' > repeatedly, and then stops and hangs. Then I have to reboot my machine. I've noticed that there doesn't appear to be any check for kernel stack overflow in the Amiga port. There used to be some kind of check in some profiling code that was never enabled, but that code has been removed. I've run into situations before where the kernel gets into recursive traps until the stack overflows and the kernel locks up. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-amiga-dev@sun-lamp.cs.berkeley.edu Sun Jul 31 21:19:02 1994 Subject: From: chopps@emunix.emich.edu (Chris Hopps) Sender: owner-amiga-dev@sun-lamp.cs.berkeley.edu I just removed the hardcoding of targets to sd unit numbers. I decided I did not want to live with this mistake through release. Basically this means that GENERIC will configure your sd drives like so: say your system has 3 drives, targets 0,3,4 these will now show up as sd0 (target 0), sd1 (target 3) and sd2 (target 4). If you run GENERIC you to change your fstab after upgrading to a newer kernel. These changes haven't yet made it into the release branch though and the kernel on lamp is still using the old way. The next one (hopefully) won't though. Chris. From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 21:34:44 1994 To: mycroft@gnu.ai.mit.edu Cc: current-users@sun-lamp.cs.berkeley.edu Subject: Re: problems with source tarballs <9407311001.AA26992@goldman.gnu.ai.mit.edu> From: "Michael L. VanLoon -- Iowa State University" Sender: owner-current-users@sun-lamp.cs.berkeley.edu >michaelv writes: > What happens on the kernels I build is this: it goes through all the > autoconfiguration stuff, and everything looks like it's working ok. > Then it finally gets to the part at the end where it prints the > ttymask, biomask, etc. stuff. Right there it just sits forever, > [...] mycroft writes: >Are you still having this problem? No. I gave a detailed response on how I fixed this in a followup to Alistair's last snapshot report a couple days ago. To give a short summary, I removed everything but the version files from my kernel compile directory, and removed all the .o and .depend files from my libkern/obj.i386 directory, and rebuilt. It's been running fine since. --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 Sun Jul 31 22:29:54 1994 From: msanders@eng.utah.edu Subject: aaaaaiiiiiiieeee! To: amiga@sun-lamp.cs.berkeley.edu (Amiga) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1235 Sender: owner-amiga@sun-lamp.cs.berkeley.edu Well, after attempting to upgrade to the snapshot/ files from sun-lamp I have managed to completely screw over my system. :( I'm running on an A3000/16, 8M Fast, 2M Chip, Quantum 52M and 240M drives. I used streamtodev to put the rootfs image onto a NBR\7 partition on the 240M drive, and had an NBU\7 partition on the 52M. It loaded into single-user mode fine (a pleasant surprise, for me). I created an /etc/fstab entry for the partition on the 52M drive something like: /dev/sd6d /usr ufs rw 1 1 And then newfs'ed the partition. I then wanted to use bffs to move all the other tar.gz files over, so I synced and rebooted. Then things got bad. One of those nice little requesters popped up, saying something to the effect of 'header corrupt' on my system partition. What did I do wrong? Just not my day, or what? On another note, my system is one of the early 3000's that shipped without the ROM, and I've never bothered to buy one because I like having the kickstart image on HD, BUT, unfortunately that image was lost when the HD got corrupted... So, anyone know where I can get one to replace it? I tried using dcp to copy the kickstart disk to a file, but that didn't work. - Mike Sanders - msanders@eng.utah.edu From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 22:42:11 1994 From: "Eduardo E. Horvath eeh@btr.com" Subject: Re: forwarded message from Jukka Forsgren To: David Champion 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 Sat, 30 Jul 1994, David Champion wrote: > > > I've heard at least one other report of problems with SCSI lockups; > > > has anyone else had these problems or have any insights into them? > > > > > I'am also having problems with those lockups. I have an A3000/25, 120MB & > > 105MB Quantum and 6MB of memory.. > > My SCSI locks up so often I can't build a new kernel to even try to > stop it. (I'm about halfway through a build now, after 6 or 7 reboots > and a few filesystem repairs.) I might be the "one other report" that > Andrew mentioned -- thanks, but your kernel didn't help me any. > A3000/25; Quantum LPS52, Empire 540. HP DAT connected, but not > always powered on. This is with any kernel from mid-June to 21 Jul. > I'm about to completely reinstall the system based on the > -release now at sun-lamp. You might try applying the patch I posted yesterday to amiga-dev. It won't hurt, and there is some slight possibility that it might help. If you apply it and do notice some shange in behavior, please let me know. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 23:07:13 1994 From: osymh@gemini.oscs.montana.edu (Michael L. Hitch) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: msanders@eng.utah.edu, amiga@sun-lamp.cs.berkeley.edu (Amiga) Subject: Re: aaaaaiiiiiiieeee! Sender: owner-amiga@sun-lamp.cs.berkeley.edu On Jul 31, 1:33pm, msanders@eng.utah.edu wrote: > I'm running on an A3000/16, 8M Fast, 2M Chip, Quantum 52M and 240M > drives. I used streamtodev to put the rootfs image onto a NBR\7 > partition on the 240M drive, and had an NBU\7 partition on the 52M. > > It loaded into single-user mode fine (a pleasant surprise, for me). > I created an /etc/fstab entry for the partition on the 52M drive > something like: > > /dev/sd6d /usr ufs rw 1 1 I assume from this that the 52M drive is SCSI id 6? Did you have any AmigaDOS partitions on the same drive? NetBSD is now assigning the sd?[defghijklmnop] partitions in the order they are located on the disk. This includes any non-NetBSD partitions. If you had an AmigaDOS partition on that disk, and the partition was located before the NBU\7 NetBSD partition, /dev/sd6d is going to be that AmigaDOS partition. Doing a newfs would then scramble the AmigaDOS partition. This could be a nasty problem for anyone who hasn't been keeping up with the amiga mailing list, and doesn't carefully read the README included in the snapshot. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant Office of Systems and Computing Services Montana State University Bozeman, MT USA From owner-current-users@sun-lamp.cs.berkeley.edu Sun Jul 31 23:26:18 1994 To: Ken Hornstein Cc: peter@alice.wonderland.org, current-users@sun-lamp.cs.berkeley.edu Subject: Re: GET THIS BOOK :) <9407281516.AA05334@entropic.com> From: Bill & Sender: owner-current-users@sun-lamp.cs.berkeley.edu Well, from what I've heard, unix-haters doesn't require accuracy, merely raw hatred. I get the feeling that these people wouldn't be happy with _any_ computer system. Many of them have nostalgic feelings for ITS. (There *are* structural problems with UNIX, though, especially in the area of the terminal driver, but that's really off-topic for this list. For example, see what happens to your shell when you run a program which sets non-blocking mode on your TTY and then exits...) - Bill From owner-amiga@sun-lamp.cs.berkeley.edu Sun Jul 31 23:54:34 1994 To: amiga@sun-lamp.cs.berkeley.edu Newsgroups: endicor.lists.netbsd.amiga From: tsarna@endicor.com (Ty Sarna) Subject: Re: aaaaaiiiiiiieeee! Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: owner-amiga@sun-lamp.cs.berkeley.edu In article <199407311933.AA15575@cadesm24.eng.utah.edu> msanders@eng.utah.edu writes: > And then newfs'ed the partition. I then wanted to use bffs to move This is your problem. newfs now makes Level 2 BSD-FFS filesystems (by default, I think it can be overridden with -c) and the root image is now probably in Level 2 format. However, BFFS only understands the Level 1 format at the moment. Chris Hooper is looking into what it would take to support Level 2 in BFFS, but it may be quite a while. -- Ty Sarna "If at first you don't succeed... tsarna@endicor.com ...don't try skydiving!!!