From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 01:14:38 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Content-Length: 824 To: netbsd-amiga@cbmuucp.commodore.com Subject: Trouble w/vmunix.516 (fwd) Sender: NetBSD-Admin@cbmuucp.commodore.com Just wanted to let you know, that #516 works with syncronous mode, while I only got #508 to work asynchronous. Great thing! Does synchronous mode speed up things a lot, or where are the advantages? In the manual of the new Gigdrives we got for our Suns at work they say, "if you add more drives you should recompile the kernel and use asynchronous mode". I wonder why? Anyways, we did not try - we just had to spread the drives all over our suns, because as soon as you put the dattape and one of those drives together - or an old gig drive (synchronous also) with one of them, nothing worked any more. The thing does not boot anymore and kills your superblock ;( Rudy --- Rudolf Neuhaus home: ->rudy@dorn.ruhr.de 44137 Dortmund (FRG) work: rudy@iml.fhg.de Tel. +49(0) 231/134404 uni : uphd02@zx1.hrz.uni-dortmund.de From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 13:35:40 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: vmunix.516 works for me too Sender: NetBSD-Admin@cbmuucp.commodore.com Just wanted to report that vmunix.516 has fixed the sync problem for me too. 508 stopped with "no suitable root found" but 516 boots fine. Much quicker, too, I'm impressed! I did get some errors I didn't get before, however -- when I go into multiuser mode, I get something like "error in fstab, wrong fs type" (can't remember exactly). This pops up around 6-10 times during the boot sequence, but my filesystems are mounted properly when I login. My fstab file is basically: /dev/sd1a ufs / /dev/sd1b mfs /tmp /dev/sd1d ufs /usr /dev/sd1e ufs /home I've got a 240MB LPS Quantum on unit 1, and a 52MB LPS Quantum on unit 6, but I don't use the 52MB for BSD. All in an A3000, 4 MB fast RAM, nothing else special. I'll check out the errors in more detail when I get home. While I'm thinking about it, two questions: 1. How do you set up NetBSD to boot into multiuser mode? 2. Does NetBSD enable processor bursting to fast RAM? I've got static column RAM, and use 'cpu burst' under AmigaDos. I don't know how much of a speed improvement you actually get, but I was just curious. Thanks! Nathan From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 17:04:43 1993 Subject: Kernels failing To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I just tried the latest kernel 526 and it failed by locking the SCSI bus in a manner similar to 508. Here are the details at failure. Normal startup messages.... HD activity light solid scsi0 : scsi id 7 a3000scsi0 [1/1] trap: bad kernel access at 0 trap type 8, code = 200072d, v = 0 pid = 0, pc = 00012192, ps = 2200, sfc = 0001, dfc = 0001 Register dump.... Stack dump.... panic: MMU fault keyboard locked System setup: A3000/25 2M chip 8M fast Quantum 105 - ID 6 SyQuest 88 - ID 5 WangTek 5150ES - ID 2 -- Alan Bair AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 21:27:42 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Funny error Sender: NetBSD-Admin@cbmuucp.commodore.com Although i checked that with Markus Wild already, i mail my last experience to the outa space :) Since yesterday, i own a brand new Fujitsu M2023F (hey, i have 2 LPS105 for sale :-) and wanted to copy all the stuff i had on my Quantums to the Fujitsu. So i also copied the rootfs from one drive to the other. Stupid me. I should have known what's on here :) You can't copy /dev/* that easy, not using a filesystem. So, what i got was that: sd0: FUJITSU M2023F-512 rev 0405, 830340 512 byte blocks changing root device ti sd0a : : panic: init died hit any key to boot/dump >trap: bad kernel access at 0 trap type 8, code cc02072d, v=0 pid=1, pc=00012192, ps=2200, sfc=0001, dfc=0001 : : panic: MMU fault : : ------ Init died... Something new :-) The trick seems to be that init wanted to open /dev/console, which is a file, not a device, as i copied it with cp. For instance, when expanding or copying to a new rootfs, you should do that here: (cd /; tar clf - .) | ( cd /mnt; tar xvf -) Whereas /mnt is a mounted entry to the new root-partition. This trick is also the best and fastest way to copy large directory- trees. Ok, going home and check #526... -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 21:54:21 1993 Subject: Re: Kernels failing To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1211 Sender: NetBSD-Admin@cbmuucp.commodore.com > I just tried the latest kernel 526 and it failed by locking the SCSI bus in > a manner similar to 508. Here are the details at failure. > ... > SyQuest 88 - ID 5 > ... SyQuests are very evil brands.. they pretend to grok sync-handshake, and after that they crash.. So, in your case, you'd do (assuming ID5 on first controller): # binpatch -s _inhibit_sync vmunix (get address of _inhibit_sync) _inhibit_sync(0x12345): 0 (0x0) (replace 0x12345 by real value from now on) {Addr=0x12345+Unit (==5)==0x1234a} # binpatch -b -a 0x1234a -r 1 (replace 0x1234a with calculated value) This inhibits sync-handshake on unit 5. Remark to Retina-owners with monitors that don't grok the default video-mode opened by BSD, you're now able to binpatch this to an inferior mode: binpatch -s _retina_default_mon -r 1 will give you 640x512 with 31.5kHz and binpatch -s _retina_default_mon -r 2 will give you 768x600 with 38kHz -r 3 is the default at 64kHz. Oh, and check out stand/videomode in the #531 diffs I just uploaded :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 1 23:14:59 1993 Subject: Re: Kernels failing To: mw@eunet.ch (Markus Wild) Cc: abair@sol.sps.mot.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > SyQuests are very evil brands.. they pretend to grok sync-handshake, and after > that they crash.. So, in your case, you'd do (assuming ID5 on first controller): > > # binpatch -s _inhibit_sync vmunix (get address of _inhibit_sync) > _inhibit_sync(0x12345): 0 (0x0) (replace 0x12345 by real value from now on) > {Addr=0x12345+Unit (==5)==0x1234a} > # binpatch -b -a 0x1234a -r 1 (replace 0x1234a with calculated value) > > This inhibits sync-handshake on unit 5. > Well, Markus W. that was almost the answer. It turns out, since my tape drive is at ID 2, which is out of your 4 & 5 standard IDs, I guess it was not being setup properly. I first turned off SYNC on the Syquest at ID 5, but the kernel still locked the SCSI BUS. Then I turned off the tape at ID 2 and it worked OK. Just to check, I then turned off the SyQuest at ID 5, which got past the tape, put a message saying ID 5 was now synchronous and then hung. So I have to disable SYNC on both of them. -- Alan Bair AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 01:18:00 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: vi and /etc/termcap Sender: NetBSD-Admin@cbmuucp.commodore.com I've got vmunix.531 running, the one, which knows how to handle an A2000 RTC, with usrsbin.tgz and usrbin.tgz installed. Quite nice, but I cannot use vi nor more. I do not like vi, but it's beautiful compared to ed and sed for editing /etc/passwd. The bad thing is: vi can't read /etc/termcap :-( which means, that vi does not edit anything. Actually it quits as soon as it find's out, that it can't read /etc/termcap. I found out, that /etc/termcap usually is a symbolic link to /usr/share/.../termcap.src which I did not install. "Ok" I thought "let me copy a real termcap from a real UN*X machine." That's what I did and afterwards I had a long termcap file and no symbolic link any more. A 'ls -l /etc/termcap' yields -rw-rw-r-- 1 root 133439 Aug 1 22:00 /etc/termcap which seems to be ok. At least that's ok to me. But 'vi' does'n agree. Neither does 'more'. 'cat' does. And all other programs do. Weird. I'd like to edit /etc/fstab, /etc/passwd, /etc/group etc., but I cannot use ed. And as Emacs uses /etc/termcap, I guess emacs won't work either. Why does vi not work? What is wrong with /etc/termcap? Bye, Harald (who would like to use Lucid-emacs on his Amiga) From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 06:37:42 1993 To: netbsd-amiga@cbmuucp.commodore.com Cc: amigaman@esu.edu Subject: 531, GVP, and _sync_debug X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, Sorry, I didn't know about _sync_debug... I turned that and _scsi_debug on and here goes... as usual, I think the stuff I'm omitting at the top is not important: [...some omitted...] issue_select 0 wait_for_select: 11 8e Sending sync request to target 0 ... ixfer_start 6, 6, 50 ixfer_out {6} 80 01 03 01 40 0c ixfer_out done sent [1f]csr_result of last msgout: 0x1f >CSR:1fCSR:8aCSR:1aCSR:19< At this point, the activity light goes on solid, and everything freezes. )Russ From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 06:56:24 1993 Subject: Re: Funny error To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 600 Sender: NetBSD-Admin@cbmuucp.commodore.com [...] > > For instance, when expanding or copying to a new rootfs, you should > do that here: > > (cd /; tar clf - .) | ( cd /mnt; tar xvf -) > > Whereas /mnt is a mounted entry to the new root-partition. > This trick is also the best and fastest way to copy large directory- > trees. Try this out: % dump 0f - /dev/ | (cd /mnt; restore rf -) (Having done this on a number of Suns recently :) Use "restore rvf -" if you're feeling masochistic :) I'm not sure about NetBSD, but with SunOS, you have to run an "installboot" program to fix up check summing in the boot block. Darren From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 12:31:15 1993 To: gcc2@cygnus.com Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Lost mail Sender: NetBSD-Admin@cbmuucp.commodore.com OK, finally back from vacation. The first thing that happened to me when I started my workstation was that my root disk got thrashed, not much, but enough to have lost at least one personal e-mail. If someone has sent me personal mail during July, which you still want me to read, please resend. This is specifically aimed at Brendan, as I *know* I've seen a message concerning the new class scoping in the spool dir of our mail-server, which never got around to my mailbox. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 15:01:23 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Back from vacation Sender: NetBSD-Admin@cbmuucp.commodore.com OK, I'm back listening here. I thought I should comment on some of the messages seen on the netbsd-amiga list >>>>> "Ari" == Ari Yrj|l{ writes: Ari> So is somebody really running NetBSD already on GVP accelerated Ari> A2000, or is this just some goof from Mach-FAQ? 8-) >>>>> "Markus W" == Markus Wild writes: Markus W> I think yes.. Niklas? :-) Well, yes I am/was... My own compilation based on bsdsyssrc.394 works fine. However I'm trying Markus' 531 compilation with which I'm having problems. >>>>> "Markus I" == Markus Illenseer writes: Markus I> On Jul 20, 5:27pm, Hubert Feyrer wrote: Markus I> 'To your info, the 490-kernel boots upto the shell, after i Markus I> beated up with hdtoolbox and the rootfs. It looks like i am Markus I> first running netbsd on an A2000. :-) Skal, Konfetti :)' Markus I> Hubert: You are wrong: I was the first :) But it did not Markus I> work for me :-> Well, and Bodo was second, and it did work Markus I> (most part). Looks like you are the first running it stable Markus I> on an A2000. Ahem... A2000/GVP series II has worked for me since bsdsyssrc.360 or something like that... Ari> My machine finds now the root (thanks to mtk's frantic debugging Ari> yesterday :) and starts booting but hangs after it says 'bpf: lo0 Ari> attached'. This behaviour is what I get with vmunix.531 on my A2000/GVPII. Well, I had to inhibit sync on a small SEAGATE disk I've borrowed since I get sbic_wait TIMEO with csr=x48 (from memory, exact wordings available on request) with sync negotiation enabled. I have a 4M fast RAM system, are they still supported? I saw Markus W ramble about some extra couple of 100 Ks in ringbuffers which might disturb small machines. Markus I> On Jul 20, 9:12pm, William J. Coldwell wrote: Bill> A2000 rev 4.5 motherboard - *Kickstart 1.3*, full ECS Markus I> KS 2.0 for me. Bill> Q: A blue screen is probably not a good sign, right? ;-) I get this Bill> right after the 8M FAST at 0x200000 and 1M CHIP banner. Then the Bill> lovely 1.3 blue (actually, it looks like video DMA is being shut Bill> off and never coming back up), no harddrive bopping or anything. Markus I> Funny, exactly the same happens to me. See the slightly Markus I> different config. All i have to add is, that i have 2MB Markus I> Chip. I get this behaviour when booting from 1.3, but *not* from zkicked 2.0, odd, no? Well, my beloved ZyXEL modem got struck by the lightning this summer so all I have to communicate with is a 2400 Baud modem, so I guess I'll wait a week before getting full sources again. Now, I have to catch up with "real" work, and some GCC C++ issues which have been waiting for me. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 15:39:15 1993 Subject: Re: 531, async, GVP To: amigaman@esu.edu (Russ Miranda - Amiga Specialist) Cc: netbsd-amiga@cbmuucp.commodore.com (Amiga NetBSD mailing list) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > To: netbsd-amiga@cbmuucp.commodore.com > Cc: amigaman@esu.edu > Subject: 531, async, GVP > Date: Mon, 02 Aug 93 00:57:21 -0400 > From: "Russ Miranda - Amiga Specialist" > X-Mts: smtp > Sender: NetBSD-Admin@cbmuucp.commodore.com > > After trying the synchronous route, which I just posted the results of, > I decided to try the asynchronous route. I set 0-6 to inhibit the sync > mode, and booted 531. With _scsi_debug still set to 2, it scrolled by > tons of debugging output as it found all 7 devices attached. It then > gave me the following output: > > Changing root device to sd0a > bpf: sl0 attached > bpf: sl1 attached > bpf: sl2 attached > bpf: sl3 attached > bpf: lo0 attached > > issue_select 0 > wait_for_select: 11 83 [1a] > ixfer_start 10, 2, 20000 > ixfer_out {10} 28 00 00 00 00 d4 > ixfer_out done > >CSR:19< > > At this point, the activity light goes on solid, and everything freezes. > > )Russ Hiya Russ, Have you overcome this problem? I get _exactly_ the same output when I tried to load vmunix.531 with sync inhibited on both my 120MEG Quantum (LP120s) and my 240MEG Seagate (ST3283N). My setup: A2000 (2.05 ROMS) 1 MEG CHIP GVP COMBO '030 with 5 MEGS FAST RAM 2 MEG RETINA 120 MEG Quantum at scsi ID0 240 MEG Seagate at scsi ID4 A couple of questions: (sorry Russ) loadbsd reports that I have 4 MEGS FAST RAM, when in fact I really have 5. Also couldn't get _retina_default_mon to work. Tried values 1, 2 and 3 but to no avail (1 should work as I have a monitor that does 31.5 KHz - 35 KHz). Anyway I had to pull the Retina out in order to read the boot messages NetBSD was spitting at me :( Thanks in advance, Trevor. -- +---------------------------------------------------------------------+ | "Let me be the first to offer you my sincerest contrafibularities" | | - E. Blackadder | +----------------------------+----------------------------------------+ | Trevor Elbourne | Computer and Systems Technology (CaST) | | trevore@vast.unsw.edu.au | Dept of Computer Science & Engineering | | trevore@cse.unsw.edu.au | University of New South Wales | +----------------------------+----------------------------------------+ From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 16:49:37 1993 To: markus@TechFak.Uni-Bielefeld.DE, netbsd-amiga@cbmuucp.commodore.com Subject: Re: Funny error Sender: NetBSD-Admin@cbmuucp.commodore.com Just a brief comment... >For instance, when expanding or copying to a new rootfs, you should >do that here: > > (cd /; tar clf - .) | ( cd /mnt; tar xvf -) xvpf Remember the 'p', or all your protection bits will get screwed up (probably not important at this stage, since I doubt too many of us are running NetBSD-Amiga as a public-access system at this point, but... :-) ). Bryan From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 17:03:26 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Funny error Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 2, 8:49am, bryan ford wrote: > Subject: Re: Funny error > Just a brief comment... > > >For instance, when expanding or copying to a new rootfs, you should > >do that here: > > > > (cd /; tar clf - .) | ( cd /mnt; tar xvf -) > > xvpf > > Remember the 'p', or all your protection bits will get screwed up > (probably not important at this stage, since I doubt too many of us > are running NetBSD-Amiga as a public-access system at this point, but... :-) ). Oh well :-) And then there is the 'S' flag ... BTW, i am unable to find the man-page for 'dd' ? ObWhine: I want my Cursor back. -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 17:13:42 1993 To: mw@eunet.ch Subject: Re: Kernels failing Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > >> I just tried the latest kernel 526 and it failed by locking the SCSI bus in >> a manner similar to 508. Here are the details at failure. >> ... >> SyQuest 88 - ID 5 >> ... > >SyQuests are very evil brands.. they pretend to grok sync-handshake, and after >that they crash.. So, in your case, you'd do (assuming ID5 on first controller): >-Markus > Well I had a nice pre-typed msg, but this msg answered some Qs. Please disregard those parts. But to comment on above... So all SyQuest users will be doomed to binpatch kernel for awhile? Here's orig msg: Well, it looks like vmunix.516 won't work w/ my setup. Here's the error: blah, blah scsi0: target 0 now sync.. period: 208ns, offset=8 (then that's it, it sits w/ the light stuck on, so I hit enter, then...) trap: bad kernel access at 0 trap: type=8 code 200072d v=0 registers... panic MMU fault (then ask to hit a key to dump core, but that doesn't happen?) So, I think it's the drive (SyQuest 5110c) that doesn't like to sync. Since most everyone else seems to work and I don't have to capicity to change it. Would that binpatch prog work? If so what exact command I need to enter. (The README seemed a bit cryptic...) Any other SyQuest users having same prob? On another note. It was stated to recompile stty if it's been dumping. It has s atleast 450 for me. So I did, it compiled fine, but still dumped. Anyone got term working with tredir? I got term going but the telnet doesn't seem to connect. Now I assume it's cuz telnetd isn't working? So, what needs to be done to get it to work? What's with this socket stuff anyway? Could someone explain the it's there for and what does it do? I'm trying to learn here... Thanx - TC -- Techno Caster - ah360@yfn.ysu.edu From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 18:54:22 1993 Subject: Re: 531, async, GVP To: trevore@vast.unsw.edu.au (Trevor Elbourne) Cc: amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1121 Sender: NetBSD-Admin@cbmuucp.commodore.com > > >CSR:19< > > > > At this point, the activity light goes on solid, and everything freezes. > > > > )Russ I think it's possible that I somehow goofed up GVP-DMA, the CSR=0x19 indicates that data-in/phase is next, thus causing some DMA action. Since you disabled sync, there's not much left but wrong DMA handling. > A couple of questions: (sorry Russ) loadbsd reports that I have 4 MEGS > FAST RAM, when in fact I really have 5. Also couldn't get You have 5M *contiguous* memory? There will probably be support for scattered memory configuration somewhere in the future, but right now BSD just uses the largest chunk of fast-mem it can get. > _retina_default_mon to work. Tried values 1, 2 and 3 but to no avail > (1 should work as I have a monitor that does 31.5 KHz - 35 KHz). Oh.. try 0, sorry, numbering when patching is one off than when using the videomode command.. The first mode is so messy on my monitor if *must* work with yours :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 19:07:11 1993 Subject: Re: Kernels failing To: ah360@yfn.ysu.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2610 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well I had a nice pre-typed msg, but this msg answered some Qs. Please > disregard those parts. But to comment on above... So all SyQuest users > will be doomed to binpatch kernel for awhile? Here's orig msg: Well... Yep, I can't help that, sorry. I just can't make the default not to send sync-requests, as then drives that had arranged sync-requests with the AmigaOS scsi.device will lock up just like your Syquest is now. Since these SCSI-2 drives are getting more and more frequent, defaulting to sync seems the right thing to me. Note: it is *not* possible to pull the RESET line on the scsi bus (at least on the A3000) without resetting the machine (by a RESET instruction). The WD/AMD chip has no command to reset the bus, just to reset itself (which doesn't reset the bus), and resetting the machine would mean I'd have to do AutoConfig(tm) myself, which is something I'd like to avoid. So.. we'll have to live with this problem .. (FAQ-author(s): that would be worth a FAQ- section I guess:-)). > Would that binpatch prog work? If so what exact command I need to enter. > (The README seemed a bit cryptic...) Any other SyQuest users having same > prob? Ok.. there's a byte array called "inhibit_sync", and it's used like that: if (inhibit_sync[UNIT]) don't do sync handshake to UNIT, go async to set the apropriate byte, first get the address of the first byte: binpatch -s _inhibit_sync vmunix.531 this outputs a line containing the address of _inhibit_sync in parenthesis. Call that number ADDR. You then add the unit number of your drive you want to disable sync on to ADDR, thus if disabling unit 3, you'd calculate ADDR=ADDR+3. Then, set the byte: binpatch -b -a ADDR -r 1 vmunix.531 where you replace ADDR with the value you just calculated, specify either as a decimal number, or as hex like: 0x12345, don't use $12345. That's it. The "-b" tells binpatch to change a byte value, "-w" changes a word (16bit) value, "-l" is the default and changes a long (32bit) value. Replace vmunix.531 by the kernel you want to patch of course:-) > On another note. It was stated to recompile stty if it's been dumping. > It has s atleast 450 for me. So I did, it compiled fine, but still > dumped. Hm, I think it stopped dumping when I relinked it with a freshly complied libc.a, the problem was the first libc.a was compiled in a rather hacky way "cross" from amigados, by using the amigados gcc :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 2 19:44:31 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: A2000 :- NetBSD works Sender: NetBSD-Admin@cbmuucp.commodore.com SSIA. #526 (and i hope #531) does work fine on my A2000 with A2630, A2091 and 2MB Chip RAM. Now, don't ask me where the problem was. I still don't understand why i had no console before #526. The A2091 detects my QP80S and Syquest DunnoWhat (40MB) and boots of a Syquest media just fine (and slow :). -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 3 02:38:44 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Fun with 351 and a WangDAT. Cc: luiten@trantor.nmsd.oz.au Sender: NetBSD-Admin@cbmuucp.commodore.com Well fun is probably not quite the word for it... :-) Anyway I have a few weird problems with kernel version 531 [and previously a few earlier versions] System Config: Amiga 3000, 8 Meg Fast, 2 Chip Quantum LPS240, Quantum 52, Digital RZ55 [300 Meg] WangDAT SCSI Tape drive model 1300 1. I currently cannot see the console at all unless I run loadbsd after IPrefs has been run in my startup. ? Some Hardware display problem ? ? Where abouts in source is this setup as I have written several hardware bashing :-) display hacks and demo type thingies for my personal amusement. Maybe I'll have a look. 2. If I have the DAT drive connected I get a kernel jump to zero. The following debug output came from setting _scsi_debug to 1. [For some reason my LPS240 hangs right after being recognised if I set _scsi_debug to 2 ??? go figure ???. It looks like it hangs trying to get the SCSI ID from the LPS240] [left out the lead up where it picks up my LPS240 and the RZ55] ixfer_out fail: l1 i80 w49946 ixfer_in fail: l6 i80 w49936 ixfer_in: fail: l102 i80 w49984 [ Then it just twiddles its thumbs :-) ] The WangDAT is at SCSI addr 4. I have tried cycling the power on it but it did nothing. 3. I unpacked the source tree for 500 on my amiga side to look for the inhibit_sync data struc because I'd left the note at home about how to patch it. Anyway I can't find anywhere in the source the header files a3000scsi.h and the one for the 2091 ??? Did I do something wrong unpacking or are they elsewhere ? 4. Dumb question time :-) Ok I got the patches to update the source to 531 but what do I need to apply them on the Amiga side ? Since this is my first post I'd like to express thanks to Markus Wild for yet another huge effort. Robin _-_|\ r.luiten@nmsd.oz.au /Disclaimer: / * <-- Systems Development (AOTC), / \_.-._/ Telecom East Tower Roma St, / C references are NULL && void* v Brisbane, Australia. / WORK: (07) 837 3030 / HOME: (07) 366 1242 / From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 3 17:59:32 1993 Subject: Re: Fun with 351 and a WangDAT. To: luiten@trantor.nmsd.oz.au (Robin Luiten) Cc: netbsd-amiga@cbmuucp.commodore.com, luiten@trantor.nmsd.oz.au X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1835 Sender: NetBSD-Admin@cbmuucp.commodore.com > 1. I currently cannot see the console at all unless I run loadbsd > after IPrefs has been run in my startup. > ? Some Hardware display problem ? > ? Where abouts in source is this setup as I have written several > hardware bashing :-) display hacks and demo type thingies for my > personal amusement. Maybe I'll have a look. *could* be hardware display problem, could also be an earlier lockup so your system doesn't even get to initializing the console. So, isolated console code is grf_cc.c and ite_cc.c in sys/arch/amiga/dev. Setting up the mmu is done in amiga/locore.s and amiga/amiga_init.c, rumors go something might be fishy already there... > [For some reason my LPS240 hangs right after being recognised > if I set _scsi_debug to 2 ??? go figure ???. It looks like it > hangs trying to get the SCSI ID from the LPS240] I think there might be some race conditions (code not protected by raising spl)... > [left out the lead up where it picks up my LPS240 and the RZ55] > ixfer_out fail: l1 i80 w49946 > ixfer_in fail: l6 i80 w49936 > ixfer_in: fail: l102 i80 w49984 > [ Then it just twiddles its thumbs :-) ] Hm, enable _sync_debug please.. perhaps it's telling then WHAT it got there... > patch it. Anyway I can't find anywhere in the source the header files > a3000scsi.h and the one for the 2091 ??? They're generated when you cd into sys/arch/amiga/conf and do "config AMIGA". Make sure to either compile a new config, or get the new version from via ftp (in the bin/ directory). > Ok I got the patches to update the source to 531 but what do I need to > apply them on the Amiga side ? May I suggest "patch" :-) ? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 4 00:39:15 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: vmunix.547 status quo Sender: NetBSD-Admin@cbmuucp.commodore.com I just wanted to say that 547 didn't change the behaviour of the boot process on my GVP-equipped A2000. The last thing to happen is the attachment of lo0 as a Berkeley Packet Filter (or whatever bpf stands for). I'm not sure 547 aimed at this problem, but if so, it failed. Details available on request. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 4 01:44:40 1993 Subject: Building on AmigaDOS To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Hello folks -- I am going bananas trying to build a kernel on AmigaDOS. I have gotten as far as running the config program, so now it's time to make something. There are a number of Makefiles around, one at the top sys directory, and one built by config in the compile directory. The question "what make do you use with these makefiles" has been answered here already, so my question is "How the hell do you use gcc's Berkeley make or gnumake with these makefiles??" Both makes act identically for me. On the top-level makefile, they choke on the generated "for entry in blah" stuff, on the compile makefile, they claim not to be able to find the gcc command. Some experimentation shows that they appear to be having problems with the length of the generated command line. I have pdksh, both as part of the gcc233 distribution and separately, but its presence doesn't seem to affect anything. What's the trick? Thanks. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 4 07:34:19 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Fun with 351 and a WangDAT. Sender: NetBSD-Admin@cbmuucp.commodore.com > > > [left out the lead up where it picks up my LPS240 and the RZ55] > > ixfer_out fail: l1 i80 w49946 > > ixfer_in fail: l6 i80 w49936 > > ixfer_in: fail: l102 i80 w49984 > > [ Then it just twiddles its thumbs :-) ] > > Hm, enable _sync_debug please.. perhaps it's telling then WHAT it got > there... I will do that tonight again, I think I did that last night though and couldn't get something else to work anymore so never got far enough to reach the WangDAT. I'll also try the new 547 kernel... to see if anything different happens. ? Is there some array that can be patched to make it totally ignore scsi devices , something like inhibit_sync but for inhibiting device ? > > patch it. Anyway I can't find anywhere in the source the header files > > a3000scsi.h and the one for the 2091 ??? > > They're generated when you cd into sys/arch/amiga/conf and do "config AMIGA". > Make sure to either compile a new config, or get the new version from via ftp > (in the bin/ directory). Doh!!! :-) Ok thanks... > > Ok I got the patches to update the source to 531 but what do I need to > > apply them on the Amiga side ? > > May I suggest "patch" :-) ? Yeh thats what I thought... I've got patch because I applied the fixes to gcc222 awhile ago but if i re-direct the diff files into it patch prompts me for file names... I didn't think that was necessary. The command lines I used was "patch 390 boots with my machine. They all show grey screens, they never came to the booting screen, the machine hangs. I don't know, if it's a problem with the proto-chip or something else. 390 works fine with my Syquest 88MB, but no greater number. My config: A3000, 2MB Chip, 4MB Fast, Quantum 105 LPS at id 0 (only Amiga), Syquest 88MB at id 6 (only BSD). Any hints ??? Everytime I see that a new kernel is out, I get a bit more fustrated, because it too isn't working. Thanks in advance, bye ************************************************************ * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ************************************************************ * Send your E-Mail to: ghost@cs.tu-berlin.de, * * kuehn@DB0TUI11.BITNET, kuehaaaf@w250zrz.zrz.tu-berlin.de * ************************************************************ * " There are two ways of writing error-free programs. * * Only the third one works. " * ************************************************************ From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 01:40:51 1993 Subject: Re: failing kernels To: ghost@cs.tu-berlin.de (Hartmut Kuehn) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1432 Sender: NetBSD-Admin@cbmuucp.commodore.com Hartmut Kuehn wrote: > I don't know what I can further try, no kernel > 390 boots with > my machine. They all show grey screens, they never came to the > booting screen, the machine hangs. > I don't know, if it's a problem with the proto-chip or something > else. 390 works fine with my Syquest 88MB, but no greater number. > > My config: > A3000, 2MB Chip, 4MB Fast, Quantum 105 LPS at id 0 (only Amiga), > Syquest 88MB at id 6 (only BSD). > > Any hints ??? Everytime I see that a new kernel is out, I > get a bit more fustrated, because it too isn't working. I have had exactly the same problem. My configuration: A2500/30, 1MB Chip, 4MB Fast, and a Fujitsu M2624SA at id 0 with bsd on it. The problem apparently has something to do with enabling the MMU. But I don't know what. I originally thought there was some problem with the new ZORROII memory map on A2000 class machines. That does not appear to be the problem. Then I thought that there was some problem copying the 900+KB kernels in and out of Chip RAM, so I customized the kernel down by ~100K. That didn't work either. Now for theory #3: Has anyone sucessfully booted a kernel later than #390 on a machine with 4MB or less of *contiguous* fast RAM? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 02:40:16 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: WangDAT and Kernel Panic (again) Cc: luiten@trantor.nmsd.oz.au Sender: NetBSD-Admin@cbmuucp.commodore.com Im back with WangDAT problem... :-) CONFIGURATION: A3000, 8Meg/2Meg 25 Mhz SCSI0: LP240S SCSI2: DEC RZ55 (300 Meg full height 5 1/3") SCSI4: WangDAT SCSI6: Quantum 50 Also got an old Hydra Systems Ethernet card in one of my slots if it matters. The card does work... If that matters. Also I tried the 547 kernel and the only difference seems to be that some of the 'w' numbers are slightly different. This is with sync_debug 1 and scsi_debug 1 NOTE: scsi_debug 2 still hangs before display the ID for my LP240S ############################################################################## NetBSD 0.8a {etc} real mem = 8388608 avail mem = 6070272 using 102 buffers containing 835584 dma0: A3000 32bit DMA scsi-: scsi id 7 a3000scsi0[1/1] send sync reqeuset to 0... sent csr_result of last msgout: 0x1f ixfer_in fail: l2 i80 w49964 msgin finished with csr 0x4a scsi0: target 0 now sync period=208ms, offset=8 ixfer_in fail: l6 i80 w49990 msgin finished with csr 0x41 GOT CMD COMPLETE! 0 acting weird... waiting for disconnect... ok. Retrying selection. sd0: QUANTUM LPL240S GM240S01X rev , 479350 512 byte blocks sd0 at a3000scsi0, slave 0 Sending sync req to 2 csr_result of last msgout: 0x1f ixfer_in fail: l2 i80 w49972 msgin finished with csr 0x4a scsi0: target 2 now sync period=256ns, offset=12 sd2: DEC RZ55 (C) DEC rev , 649040 512 byte blocks sd2 at a3000scsi0, slave 2 Sending sync req to 4 ixfer_out fail: l1 i80 w49945 sent csr_result of last msgout: 0x4e Sending REJECT message to last received message ixfer_in fail: l6 i80 w49937 msgin finished with csr 0x4a target 4 rejected sync, going async ixfer_in fail: l102 i80 w49984 ixfer_in fail: l102 i80 w49984 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49984 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49985 ixfer_in fail: l102 i80 w49984 st0: WangDAT >Model 1300< rev02.5 st0: Unsupported tape device panic: kernel jump to zero hit key {etc} ############################################################################## If i inhibit sync on the WangDAT the sync negotiating messages don't appear and I just get a message "forcing asynch" but it still hangs in the same way. Hope this is enough to help with finding fault. Robin _-_|\ r.luiten@nmsd.oz.au /Disclaimer: / * <-- Systems Development (AOTC), / \_.-._/ Telecom East Tower Roma St, / C references are NULL && void* v Brisbane, Australia. / WORK: +61 7 837 3030 / HOME: +61 7 366 1242 / From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 07:33:48 1993 To: eeh@public.btr.com Cc: ghost@cs.tu-berlin.de, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: failing kernels Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Eduardo" == Eduardo E. Horvath eeh@btr.com writes: Eduardo> Hartmut Kuehn wrote: Hartmut> I don't know what I can further try, no kernel > 390 boots with my Hartmut> machine. They all show grey screens, they never came to the booting Hartmut> screen, the machine hangs. I don't know, if it's a problem with the Hartmut> proto-chip or something else. 390 works fine with my Syquest 88MB, Hartmut> but no greater number. Eduardo> The problem apparently has something to do with enabling the Eduardo> MMU. But I don't know what. I originally thought there was Eduardo> some problem with the new ZORROII memory map on A2000 class Eduardo> machines. That does not appear to be the problem. Then I Eduardo> thought that there was some problem copying the 900+KB Eduardo> kernels in and out of Chip RAM, so I customized the kernel Eduardo> down by ~100K. That didn't work either. Eduardo> Now for theory #3: Has anyone sucessfully booted a kernel Eduardo> later than #390 on a machine with 4MB or less of *contiguous* Eduardo> fast RAM? I spent last night compiling 531 beneath ADOS and since I only got 4M FastRAM + 1M ChipRam I usually turn off all extra daemons as well as the interlaced 640x1000 virtual screen in order to save memory. To my surprise I got the steady grey screen. I thought I'd messed up the compilation at first, but that wasn't the case. It was the fact that I wasn't using *interlace* when booting BSD! When I found out this an old messsage seen here came to my mind: "I can't seem to boot NetBSD before IPrefs has run" or someting of the kind. So all of you having steady coloured screens when booting, try to go into interlace mode first. I have yet to find out why BSD won't get any further than attaching the SLIP and loopback interfaces on my machine. Maybe tonight. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 09:41:26 1993 Subject: Re: uploaded kernel #500 To: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: abair@amcu-tx.sps.mot.com, billc@icecube.rain.com, baford@schirf.cs.utah.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1114 Sender: NetBSD-Admin@cbmuucp.commodore.com > I think I've found where netbsd crashes on my machine. the line: > > tc = 0x82d08b00; > > consistantly crashes my machine. I have tried moving it before the > first pmove, I have tried making it static data, and I have even tried > initializing it in the declaration. So far nothing has worked. I > don't understand why storing a value in a variable should cause this > problem, but it does, and it does consistantly. Any ideas? I don't either... There must be a different *reason*, and the bug just manifests itself in this behavior... do you have a non-standard extension that might be generating nmi's? Exception-vectoring isn't working until the mmu is turned on, which it isn't at that point.. Some nasty effectes resulted - as another, onrelated problem - from the vbl-interrupts doing some stuff to modem control lines on the internal serial port. Now, if the first vbl happened a bit too early, scsibus-scanning locked up... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 09:43:17 1993 Subject: Re: Markus' amiga setup ? To: ryan@chaos.mcs.mu.edu (Ryan K. Brooks) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 688 Sender: NetBSD-Admin@cbmuucp.commodore.com > Could you post a copy of your configuration dir tree > for building kernels on the Amiga side? (dir opt a) Having > some problems getting my setup just like yours... thanks I doubt this will help you much.. as a guideline, you need gcc installed in the way the README explains, and you also better go and compile (ie. not port :-)) the GNU text-, shell- and filetools/utils. Sed is also required. This should already get your pretty far. For make to find gcc, is should be reachable as either bin:gcc or usr:bin/gcc. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 10:36:50 1993 Subject: Re: vmunix.516 works for me too To: dohm%nicmad%astroatc.UUCP@cs.wisc.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 792 Sender: NetBSD-Admin@cbmuucp.commodore.com > I did get some errors I didn't get before, however -- when I go into > multiuser mode, I get something like "error in fstab, wrong fs type" (can't > remember exactly). This pops up around 6-10 times during the boot > sequence, but my filesystems are mounted properly when I login. My fstab > file is basically: You got excess newlines in fstab? Remove them:-) > 1. How do you set up NetBSD to boot into multiuser mode? Should really be possible to set, I know.. I'll make a patchable variable:-) > 2. Does NetBSD enable processor bursting to fast RAM? I've got Don't know offhand.. how would you?:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 10:39:38 1993 Subject: Re: vi and /etc/termcap To: harald.backert@rrzc1.rz.uni-regensburg.de (Harald Backert) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 409 Sender: NetBSD-Admin@cbmuucp.commodore.com > But 'vi' does'n agree. Neither does 'more'. > 'cat' does. And all other programs do. > Weird. You did export TERM=vt220 ?? > Bye, Harald (who would like to use Lucid-emacs on his Amiga) 19.x should incorporate the Lucid features, not? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 11:09:49 1993 Subject: Re: Back from vacation To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 667 Sender: NetBSD-Admin@cbmuucp.commodore.com > available on request) with sync negotiation enabled. I have a 4M > fast RAM system, are they still supported? I saw Markus W ramble > about some extra couple of 100 Ks in ringbuffers which might disturb > small machines. Should be a thing of the past now.. I'll upload new sources as soon as I'm more confident the new kernel is really stable. The tty subsystem now uses clists again (although implemented with ring-buffers), and memory requirements of the kernel dropped by about 300 to 400k... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 11:27:35 1993 Subject: Re: 531, async, GVP To: amigaman@esu.edu (Russ Miranda - Amiga Specialist) Cc: netbsd-amiga@cbmuucp.commodore.com, amigaman@esu.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: 672 Sender: NetBSD-Admin@cbmuucp.commodore.com > bpf: lo0 attached > > issue_select 0 > wait_for_select: 11 83 [1a] > ixfer_start 10, 2, 20000 > ixfer_out {10} 28 00 00 00 00 d4 > ixfer_out done > >CSR:19< > > At this point, the activity light goes on solid, and everything freezes. That's one of the most stupid bugs I made recently.. the gvp interrupt handler is plain not invoked... check out - if you compile your own kernel - machdep.c, in the intrhandler where it calls a3000 and a2091 interrupt handlers, if should of course also call gvp ... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 11:41:35 1993 Subject: Re: vmunix.547 status quo To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 523 Sender: NetBSD-Admin@cbmuucp.commodore.com > I just wanted to say that 547 didn't change the behaviour of the boot > process on my GVP-equipped A2000. The last thing to happen is the > attachment of lo0 as a Berkeley Packet Filter (or whatever bpf stands > for). I'm not sure 547 aimed at this problem, but if so, it failed. @#$@#$#@ It was -among other things- aimed at fixing this problem yet.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 11:51:25 1993 Subject: Re: Building on AmigaDOS To: ahh@netcom.com (Andy Heffernan) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 772 Sender: NetBSD-Admin@cbmuucp.commodore.com > Both makes act identically for me. On the top-level makefile, > they choke on the generated "for entry in blah" stuff, on the compile > makefile, they claim not to be able to find the gcc command. Some You should only try to compile the kernel from the compile/AMIGA/Makefile. Gcc should be accessible as bin:gcc or usr:bin/gcc. No problems with extra-long argument lines are known, but you might have problems with the standard AmigaShell, WShell doesn't know these problems. (BSD-make shouldn't have the problem anyway, as it starts gcc thru ixemul's private execve call not going thru System()). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 11:58:54 1993 Subject: Re: Fun with 351 and a WangDAT. To: luiten@trantor.nmsd.oz.au (Robin Luiten) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 634 Sender: NetBSD-Admin@cbmuucp.commodore.com > I've got patch because I applied the fixes to gcc222 awhile ago but if i re-direct > the diff files into it patch prompts me for file names... I didn't think that was > necessary. > > The command lines I used was "patch in every filename to be patched. But if its the only way I will... :-| The -p option strips as many directories from the from of the file paths as you specify. -p1 is usually the way to go. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 15:33:06 1993 Subject: Re: failing kernels To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 666 Sender: NetBSD-Admin@cbmuucp.commodore.com Here's what I've done to be able to boot NetBSD-kernels >390: I've made a special startup disk that boots my amiga with a NTSC-lace screen, us-keymap, and don't run any other programs then those in the orginal startup-sequence. NetBSD doesn't seem to like the productivity screen-mode, the software needed to use the A2065 card, and at least one more thing I got in my usual startup-sequence. I don't think it got anything to do with having only 4MB fastram, I still get the grey screen if I try to use my usual startup-sequence, even after upgrading from 4 to 12 MB fastram /Magnus Gr|nlund d91-mgd@ludd.luth.se A3000/12 MB fast/brainwashed 300Mb harddrive :-) From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 16:18:23 1993 Subject: Re: vmunix.516 works for me too To: mw@eunet.ch (Markus Wild) Cc: dohm%nicmad%astroatc.UUCP@cs.wisc.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 422 Sender: NetBSD-Admin@cbmuucp.commodore.com > > 1. How do you set up NetBSD to boot into multiuser mode? > > Should really be possible to set, I know.. I'll make a patchable variable:-) > The proper approach is to have this passed in from loadbsd. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 16:26:49 1993 Subject: Re: uploaded kernel #500 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1965 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I think I've found where netbsd crashes on my machine. the line: > > > > tc = 0x82d08b00; > > > > consistantly crashes my machine. I have tried moving it before the > > first pmove, I have tried making it static data, and I have even tried > > initializing it in the declaration. So far nothing has worked. I > > don't understand why storing a value in a variable should cause this > > problem, but it does, and it does consistantly. Any ideas? > I don't either... There must be a different *reason*, and the bug just > manifests itself in this behavior... do you have a non-standard extension > that might be generating nmi's? Exception-vectoring isn't working until > the mmu is turned on, which it isn't at that point.. I may be wrong about the exact location of the lockup (within 5 about instructions), but I am certain that it is happenning when the MMU is being re-enabled. The only strange thing I do is run SetCPU and ask so I can boot AmigaDOS 1.3 from disk if I want to. I usually kill the ask and try to load my kernel there, before IPrefs or any of the other 2.04 stuff is run. The hacked up #340 kernel I'm using boots just fine both at that point and later when I have 2.04 fully configured. I am not running mungwall or any other MP programs, other than SetCPU. > Some nasty effectes resulted - as another, onrelated problem - from the > vbl-interrupts doing some stuff to modem control lines on the internal > serial port. Now, if the first vbl happened a bit too early, scsibus-scanning > locked up... I have set an instruction at the end of amiga_init() that should change my screen background to white. It is never executed. The only thing I can see happening inside amiga_init() is mucking around with the MMU. ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 18:28:24 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: panic! Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, since this sunday I have NetBSD running...well, almost running. I regulary get paning kernels. Sometimes after two minutes, sometimes after half an hour. I usually get 'panic: pmat_enter_ptpage: PTpage not entered' while I try to load a program. This happened right after I typed 'make', 'cat' and 'tar'. Today I got another panic-error: 'panic: ialloc: dup alloc' while I was exiting emacs. I installed NetBSD from scratch again, and the panic's did not go :-( Why? What is wrong with my configuration, since other NetBSD-users don't seem to have this problem? Bye, Harald (who still likes NetBSD, although it make a lot of trouble) From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 19:56:20 1993 To: mw@eunet.ch Cc: amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com, amigaman@esu.edu Subject: Re: 531, async, GVP Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: > bpf: lo0 attached > > issue_select 0 wait_for_select: 11 83 [1a] ixfer_start 10, 2, 20000 > ixfer_out {10} 28 00 00 00 00 d4 ixfer_out done >CSR:19< > > At this point, the activity light goes on solid, and everything freezes. Markus W> That's one of the most stupid bugs I made recently.. the gvp Markus W> interrupt handler is plain not invoked... check out - if you Markus W> compile your own kernel - machdep.c, in the intrhandler Markus W> where it calls a3000 and a2091 interrupt handlers, if should Markus W> of course also call gvp ... Thanks!!! I'm now running NetBSD as I'm typing this message. I compiled 531 with the necessary change as well as a possibly unneeded init of the GVP DMAC which I've got from gvpscsi.device (you know, the regs i call secret1, secret2 and secret3), and got it running straight away on a 4MB A2000. I also established that it is non-interlace that is the culprit when you get a steady grey or blue screen. I put interlace in my system-configuration of my 1.3 ADOS boot disk and now NetBSD boots off that as well as off zkicked 2.0. There is no cursor, but that's the only problem so far, maybe 547 has solved that? Well, if so I need a diff.531-547... BTW Markus, why don't you regularly create a diff file when you decide to upload a new vmunix. At least I am always eager to be synchronized with you. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 21:11:46 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Do you miss your cursor? Sender: NetBSD-Admin@cbmuucp.commodore.com If you're missing your cursor and using the custom chipset, try adding this statement early in cc_le32_cursor of ite_cc.c: if (flag == START_CURSOROPT || flag == END_CURSOROPT) return; It worked for me 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 mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 21:21:19 1993 Subject: Re: Building on AmigaDOS To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Both makes act identically for me. On the top-level makefile, > > they choke on the generated "for entry in blah" stuff, on the compile > > makefile, they claim not to be able to find the gcc command. Some > > You should only try to compile the kernel from the compile/AMIGA/Makefile. > Gcc should be accessible as bin:gcc or usr:bin/gcc. > > No problems with extra-long argument lines are known, but you might have > problems with the standard AmigaShell, WShell doesn't know these problems. > (BSD-make shouldn't have the problem anyway, as it starts gcc thru ixemul's > private execve call not going thru System()). Thanks. I'll have to try it again. The reason I surmised that there was a command-line length problem was because I changed the compile/AMIGA/Makefile to compile a bogus file for the first target (added a line right before the $(CC) for the first target). That started gcc ok, but of course cpp complained about the bogus file. I added the make macros (-I../../whatever -Dthis -Dthat) to the bogus compile line, and then make failed to find gcc. The message was "gcc: not found" if I recall correctly. The problem seems largely moot, however, since I was able to boot vmunix.531 successfully from my big Maxtor after patching the kernel not to put it into synchronous transfer mode. Neato! After bouncing the source files over, I can start compiling on BSD. Thanks for your good work. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 21:36:53 1993 To: harald.backert@rrzc1.rz.uni-regensburg.de Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: panic! Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Harald" == Harald Backert writes: Harald> Why? What is wrong with my configuration, since other NetBSD-users Harald> don't seem to have this problem? What is yor configuration? Do you have a 68EC030? Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 21:57:53 1993 To: niklas@appli.se Cc: harald.backert@rrzc1.rz.uni-regensburg.de, netbsd-amiga@cbmuucp.commodore.com Subject: Re: panic! Sender: NetBSD-Admin@cbmuucp.commodore.com Niklas wrote: > What is yor configuration? Do you have a 68EC030? *grin* nice joke :-) A2000/A2630 (with 4 MB)/A2091 (with 2 MB)/A2232 (gee, lot of Commodore stuff), Retina (with 4 MB). Harddisks: ST1162N, SQ5110 and Fujitsu M2623FA (405MB). So, I do have a real MMU. I hope it's not broken, although it _should_ work. Bye, Harald (who got another panic-PTpage fault in the meantime) From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 5 22:33:40 1993 Subject: oh my god .... To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 891 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all ! Just wanna say, that the only reason no kernel > 390 booted with my machine was that I boot in Hires not Hires Interlace. Thanks to all who gave me hints what has to be done. It was as simple as frustating: After I loadwb and changed the screenmode to ntsc:hires-interlace, the 531 kernel booted into the beloved BSD :-))))) Bye ************************************************************ * Hartmut Kuehn Phone: +49 (0)30 814 13 78 * ************************************************************ * Send your E-Mail to: ghost@cs.tu-berlin.de, * * kuehn@DB0TUI11.BITNET, kuehaaaf@w250zrz.zrz.tu-berlin.de * ************************************************************ * " There are two ways of writing error-free programs. * * Only the third one works. " * ************************************************************ From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 03:33:38 1993 Subject: Berkeley gets some of its own back :-) To: amiga-mach@nic.funet.fi (The AmigaMach mailing list), netbsd-amiga@cbmuucp.commodore.com, machm68k@yoyo.cc.monash.edu.au (The machm68k mailing list) X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 20088 Sender: NetBSD-Admin@cbmuucp.commodore.com I thought this might be of interest to people working for free UNIX - > Date: Wed, 4 Aug 1993 16:45:58 -0700 > From: "Chris G. Demetriou" > To: merge@sun-lamp.cs.berkeley.edu > Subject: and the wheel turns 'round... > > [available from bsdi.com:/bsdi-info/usl/930610.ucb_complaint] > > JOEL LINZNER > CARLA J. SHAPREAU > CROSBY, HEAFEY, ROACH & MAY > Professional Corporation > 1999 Harrison Street > Oakland, California 94612 > Telephone (510) 763-2000 > > JAMES E. HOLST > JOHN F. LUNDBERG > MARY E. MacDONALD > University of California > 300 Lakeside Drive, 7th Floor > Oakland, California 94612-3565 > Telephone: (510) 987-9800 > > Attorneys for Plaintiff > The Regents of the University of California > > > SUPERIOR COURT OF CALIFORNIA - COUNTY OF ALAMEDA > > > THE REGENTS OF THE UNIVERSITY OF CALIFORNIA > > Plaintiff, > > v. > > UNIX SYSTEM LABORATORIES, INC., > > Defendant. > > > > > > No. 717864-3 > > COMPLAINT > > Plaintiff The Regents of the University of California > ("the University") alleges as follows: > > 1. Defendant Unix Systems Laboratories, Inc. ("USL") > is a Delaware corporation with its principal place of business in > Summit, New Jersey. USL is a majority-owned subsidiary of AT&T engaged > in the development, manufacture, licensing and sale of computer > software operating systems and related products and services. The > University of California is a public trust created under Article IX, > Section 9 of the California Constitution that is administered by The > Regents of the University of California. > > FACTUAL BACKGROUND > > 2. Commencing in the 1970s, the University began > developing software named the Berkeley Software Distribution ("BSD"). > The BSD releases are a series of Unix-compatible software distributions > that incorporate leading edge technology and are developed by the > University of California Berkeley Computer Systems Research Group > ("CSRG"). > > 3. On or about March 4, 1986, the University and AT&T > entered into a written license agreement for the use of the > University's 4.2 BSD and 4.3 BSD computer programs and documentation, a > copy of the agreement is attached here to as Exhibit A. > > 4. On or about May 4, 1989, the University and AT&T > entered into a written license agreement for the use of the > University's 4.3 BSD-Tahoe computer programs and documentation, a copy > of which is attached hereto as Exhibit B. The University's 4.3 > BSD-Tahoe computer programs and documentation were made available to > USL under the same terms and conditions set forth in the March 4, 1986 > agreement. (The 4.2 BSD, 4.3 BSD, and 4.3 BSD-Tahoe agreements will > hereinafter be collectively referred to as the "BSD Agreements.") > > 5. AT&T licensed, for itself and its subsidiaries, > the right to use and sublicense the University's BSD software for, > among other purposes, the development of AT&T's (and subsequently > USL's) commercial Unix Operating System. The price charged by the > University for a license to use its BSD software and documentation was, > and is, a nominal fee to cover the cost of production and shipping of > the software and related documentation. The University has never > licensed its BSD software for profit. > > 6. The BSD Agreements require that USL give the > University proper credit and recognition for its use of any part of 4.2 > BSD, 4.3 BSD, and 4.3 BSD-Tahoe in Paragraph 8 as follows: > > Proper Credit and Recognition. In the use of any part of 4.2 > BSD and 4.3 BSD, AT&T will give appropriate credit to the > University and the Electrical Engineering and Computer > Sciences Department at the Berkeley Campus of the University > of California and Other Contributors for their roles in its > development and will require sublicensees to give such > credit. > > If AT&T is providing documentation similar to that which is > provided with 4.2 BSD and 4.3 BSD, notices similar to those > included in that documentation suffice to satisfy this > requirement. If AT&T is providing new documentation, this > requirement will be satisfied if each document includes the > following statement: 'This software and documentation is > based in part on the Fourth Berkeley Software distribution > under license from The Regents of the University of > California. We acknowledge the following individuals and > institutions for their role in its development: [insert > names of individuals and institutions which appear in the > documentation provided to AT&T as part of 4.2 BSD and 4.3 BSD > for those portions of said Distribution used by AT&T.]' > > 7. In addition, in Paragraph 7 of the BSD Agreements, > the University granted to AT&T and its subsidiaries the right to > sublicense 4.2 BSD, 4.3 BSD, and 4.3 BSD-Tahoe to third parties as long > as AT&T and its subsidiaries required its sublicensees to comply with > the "Proper Credit and Recognition" obligations contained in Paragraph > 8, referenced above. The University is informed and believes that USL > has sublicensed 4.2 BSD, 4.3 BSD, and/or 4.3 BSD-Tahoe to sublicensees, > including, but not limited to Silicon Graphics, Inc., the Santa Cruz > Operation, Inc., and Intel Corporation, who have failed to give the > University proper credit and recognition in the following documentation > as required under Paragraph 8 of the BSD Agreements: Silicon Graphics' > IRIX User's Reference Manual," Santa Cruz Operation's "Open Desktop > Administrator's Guide," and Intel's "IBCS2." > > 8. On or about November 1, 1989, AT&T assigned and > transferred its rights to, among other things, System V, Release 4 of > the Unix Operating System to USL. The University is informed and > believes that AT&T assigned and transferred its rights under the BSD > Agreements to USL. > > 9. The 4.3 BSD-Tahoe software expressly provides as > follows: > > > Copyright (c) 1982, 1986 Regents of the University of > California. All rights reserved. > > Redistribution and use in source and binary forms are > permitted provided that the above copyright notice and > this paragraph are duplicated in all such forms and that > any documentation, advertising materials, and other > materials related to such distribution and use > acknowledge that the software was developed by the > University of California, Berkeley. > > > USL failed to include the University's copyright notice in its Unix > System V, Release 4. > > 10. Substantial portions (perhaps as much as 50%) of > the current version of USL's Unix Operating System, "System V, Release > 4," is comprised of the University's BSD code. USL has paid no > royalties for its use of the University's BSD software, although USL > currently licenses its Unix Operating System for approximately > $200,000. Although USL itself states, the Unix Operating System has > become "one of the most highly regarded computer systems in the world," > this is largely the result of BSD software developed by the University > and its contributors which has been incorporated into USL's Unix > Operating System. The only form of compensation the University > required USL to provide (other than the nominal license fee) was credit > and recognition to the University for its valuable software and related > documentation. USL failed to provide the University with its due > credit and recognition under the applicable license agreements. > > FIRST CAUSE OF ACTION > (Specific Performance Cal. Civ. Code 3384) > > > 11. The University incorporates by reference the > allegations set forth in Paragraphs 1 through 10 above, as if set forth > in full herein. > > 12. The consideration given by USL for the > University's grant of the right to use and sublicense the University's > BSD software and documentation was, among other things, payment to the > University of a nominal license fee and the provision by USL of proper > credit, recognition, and notice to the University whenever USL used the > University's BSD software and documentation. > > 13. The University has performed all conditions, > covenants, and promises required of it on its part to be performed in > accordance with the terms and conditions of the BSD Agreements. > > 14. USL has failed, and continues to fail, to perform > the conditions of the BSD Agreements in that USL has failed to give the > proper credit, recognition, and notice to the University for its use of > BSD software and related documentation in USL's products as required > under the BSD Agreements. > > 15. USL's widely distributed documentation contains > portions of 4.2 BSD and/or 4.3 BSD code and documentation but these > publications fail to provide the University with proper credit, > recognition, and notice. The following documentation are but a few > examples of USL's failure to perform its obligations under the BSD > Agreements: > > a. Advanced System Administration, UNIX SVR4.2; > attached hereto as Exhibit C are copies of the title page and > acknowledgement portion of this documentation; > > b. User's Guide, UNIX SVR4.2; attached hereto as > Exhibit D are copies of the title page and acknowledgement portion of > this documentation; > > c. System Files and Devices Reference Manual for > Motorola Processor (for Unix System V Release 4), attached hereto as > Exhibit E are copies of the title page and acknowledgement portions of > this documentation; > > d. System V Application Binary Interface, Intel > i860 Processor Supplement; attached hereto as Exhibit F are copies of > the title page and acknowledgement portions of this documentation; and > > e. System V Interface Definition, 3rd Edition; > attached hereto as Exhibit G are copies of the title page and > acknowledgment portion of this documentation. Exhibit G indicates that > USL has failed to give the University the credit and recognition it is > required to provide under the BSD Agreements because the only reference > to the University are the words "(c) 1985 Regents of the University of > California." > > 16. USL has failed to include the University's > copyright notice in System V, Release 4 and related documentation. > > 17. USL's failure to give the University proper > credit, recognition, notice for its use and reproduction of BSD > software and documentation in the development of System V, Release 4 > and related documentation has caused, and continues to cause, > irreparable injury to the University. USL has caused harm to the > University's reputation by failing to give the University recognition > for its academic, cutting-edge developments that have greatly > contributed to the Unix community's evolution and vitality. The harm > caused by USL to the University cannot be quantified in monetary > terms. Moreover, an accurate assessment of damages is far too > difficult and speculative. If USL fails to provide proper credit and > recognition to the University, the University seeks an Order > terminating the BSD Agreements which will require USL to "immediately > destroy 4.2 BSD, 4.3 BSD, and 4.3 BSD-Tahoe and all copies thereof. . > .and [USL] shall cease use and sublicensing thereof" as provided in > Paragraph 2 of the BSD Agreements. For the reasons stated above, the > University has no adequate legal remedy for its injuries and it, > therefore, seeks specific performance of USL's obligations under the > BSD Agreements. > > SECOND CAUSE OF ACTION > (California Unfair Competition) > (Cal. Bus. & Prof. Code 17200 and 17203) > > 18. The University incorporates by reference the > allegations set forth in Paragraph 1 through 17 above, as if set forth > in full herein. > > 19. USL's continuing distribution and sale of System > V, Release 4 of the Unix Operating System (in source and object code > form), and related documentation, without proper credit, recognition, > and notice of the University's original work constitutes unlawful, > unfair, and fraudulent business acts and practices, and unfair, > deceptive, and misleading advertising within the meaning of California > Business and Professions Code Section 17200. The acts and practices of > USL have caused, and are likely to continue to cause, the public to be > confused and misled as to the origin of the code contained in System V, > Release 4 and related documentation. > > 20. Without injunctive relief, the University has no > means by which to control USL's dissemination of software and > documentation which unfairly deprives the University of its due credit > and which passes off portions of USL's System V, Release 4 and related > documentation as its own. The University has been, and continues to be > irreparably harmed by USL's unfair competition. No amount of money > damages can adequately compensate the University if it is without the > ability to prevent USL's continued wrongful acts. The University is > entitled to injunctive relief prohibiting USL from such acts of unfair > competition. In addition, the University is entitled to an Order > requiring that USL disseminate corrective notice to USL's licensees and > the public. > > 21. In addition, the University is engaged to recover > its costs of suit and its attorneys' fees. > > THIRD CAUSE OF ACTION > (False or Misleading Statements) > (Cal. Bus. & Prof. Code 17500 and 17535) > > 22. The University incorporates by reference the > allegations set forth in Paragraph 1 through 18 above, as if set forth > in full herein. > > 23. USL's continuing distribution and sale of software > and documentation that fails to notify USL's licensees, sublicensees, > and the public that portions of USL's software and documentation > contain, use, or are based in part on, the Fourth Berkeley Software > Distribution under license from the University, constitutes false and > misleading statements within the meaning of California Business and > Professions Code Section 17500. > > 24. USL's false and misleading statements have caused, > and are likely to cause, the public to be confused, misled, and > deceived. > > 25. USL knew, or in the exercise of reasonable care, > should have known, that the acknowledgements, notice, and credit > contained in its System V, Release 4 software and related documentation > was, is, and continues to be, false and misleading. Notwithstanding > USL's knowledge of its misleading statements, USL continues to > distribute and sell the offending software and documentation. > > 26. Without injunctive relief, the University has no > means by which to control USL's false and misleading statements to its > licensees and the public and has been and will continue to be > irreparably harmed. No amount of money damages can adequately > compensate the University if it is without the ability to prevent such > continued false and misleading statements. The University is entitled > to injunctive relief prohibiting USL from continuing to make false and > misleading statements to its licensees and the public. In addition, > the University is entitled to an Order requiring USL to disseminate > corrective notice to its licensees and the public. > > 27. In addition, the University is engaged to recover > costs and attorneys' fees. > > FOURTH CAUSE OF ACTION > (Declaratory Relief) > > 28. The University incorporates by reference the > allegations set forth in Paragraphs 1 and 2 above, as if set forth in > full herein. > > 29. The University seeks a judicial determination that > it is not in breach of its license agreements with USL for that version > of the Unix Operating System identified as "UNIX 32V." > > 30. UNIX 32V was released by AT&T on or about 1978. > AT&T granted the University the right to enhance, modify, and improve > 32V and granted the University all ownership rights to such > enhancements, modifications, and improvements. The University had the > option to release to the public those enhancements, modifications, and > improvements to UNIX 32V that did not contain AT&T code or disclose > AT&T's trade secrets to non-AT&T licensees. > > 31. USL contends that the University materially > breached the UNIX 32V license agreement when the University released > software called "Net 2" to the public in July 1991. The University > contends that its release of Net 2 did not materially breach the > University's license agreement with USL. > > 32. There exists a substantial, present, justiciable > controversy between the University and USL with respect to the parties' > contractual rights and obligations under the UNIX 32V license > agreements and related documents. > > 33. A judicial declaration is necessary and > appropriate at this time so that the University and USL may ascertain > their rights and duties under the applicable license agreements and > related documents. > > PRAYER FOR RELIEF > > WHEREFORE, the University prays for judgment as > follows: > > (a) For an Order requiring USL, its agents, > employees, successors, and assigns and all others in concert and > privity with it to print corrective advertising, giving the University > proper credit, recognition, and copyright notice, in all newspapers, > periodicals, and other publications, in which USL regularly advertises > the Unix Operating System and related products; > > (b) For an Order requiring USL, its agents, > employees, successors, and assigns and all others in concert and > privity with it to distribute corrective notices, giving the University > proper credit, recognition, and copyright notice, to all of its > international and national licensees and sublicensees; > > (c) For an Order requiring USL, its agents, > employees, successors, and assigns and all others in concert and > privity with it to give the University proper credit, recognition, and > copyright notice in all future releases of the Unix Operating System > and related documentation which contain, use, or are based on, 4.2 BSD, > 4.3 BSD, or 4.3 BSD-Tahoe software and related documentation. > > (d) For an Order permanently enjoining USL, its > agents, employees, successors, and assigns and all others in concert > and privity with it from making false and misleading statements > regarding the origin of those portions of System V, Release 4 and > related documentation that contain, use, or are based on, BSD software > or documentation and from engaging in unfair and deceptive business > acts and practices. > > (e) For an Order that the BSD Agreements will > terminate and USL will be requited to immediately destroy 4.2 BSD, 4.3 > BSD, and 4.3 BSD-Tahoe and all copies thereof and USL shall cease use > and sublicensing thereof as provided in Paragraph 2 of the BSD > Agreements if USL fails to provide proper credit and recognition to the > University. > > (f) For a declaration that the University did not > breach the UNIX 32V license agreements when the University released Net > 2 to the public. > > (g) For an Order awarding the University costs of > suit herein incurred; > > (h) For an Order awarding the University > reasonable attorneys' fees pursuant to contract and statute; and > > (i) For such other further relief as the court > may deem just and equitable. > > > DATED: June ___, 1993 CROSBY, HEAFEY, ROACH & MAY > Professional Corporation > > > > > By: > Joel Linzner > Attorneys for Plaintiff > The Regents of the University > of California From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 09:13:42 1993 Subject: Re: panic! To: harald.backert@rrzc1.rz.uni-regensburg.de (Harald Backert) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1438 Sender: NetBSD-Admin@cbmuucp.commodore.com > I usually get 'panic: pmat_enter_ptpage: PTpage not entered' while I > try to load a program. This happened right after I typed 'make', > 'cat' and 'tar'. Never seen this one.. > Today I got another panic-error: 'panic: ialloc: dup alloc' while I was > exiting emacs. Oh.. this is usually due to a corrupt filesystem. After you have an "abnormal shutdown" of BSD (like your crashes above:-)), you should *always* do the following: fsck -p If the command runs thru just reporting a per-partition statistic of used blocks etc, everything's fine. Should the command however need to correct *any* information on the root filesystem, reboot the machine (three-finger-salute) right after fsck finishes (fsck -p won't check further partitions if it had to temper with the root fs). Don't use "reboot" or "halt", to be sure none of the old bogous information (no longer valid) is written back to the fixed partition. After booting again, redo the "fsck -p", which should now proceed without errors over root, and then possibly fix inconsistencies on the other partitions, which is ok, and no need to reboot afterwards. > I installed NetBSD from scratch again, and the panic's did not go :-( Each time you crash, you HAVE to do fsck, or face really weird problems... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 09:19:47 1993 Subject: Re: 531, async, GVP To: niklas@appli.se (Niklas Hallqvist) Cc: amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1668 Sender: NetBSD-Admin@cbmuucp.commodore.com > Thanks!!! I'm now running NetBSD as I'm typing this message. I compiled Phew.. I really cursed this controller ... > 531 with the necessary change as well as a possibly unneeded init of the > GVP DMAC which I've got from gvpscsi.device (you know, the regs i call > secret1, secret2 and secret3), and got it running straight away on a 4MB Yeah.. Mr. Discover-the-unpublished-magic-features-of-GVP-controllers :-)) > A2000. I also established that it is non-interlace that is the culprit > when you get a steady grey or blue screen. I put interlace in my This is awefully strange.. Although I do install an interlaced copperlist, I thought I set up anything to have this working from any possible previous screen mode. Hmm.. perhaps some custom chip register not initialized that makes the machine lockup if an interlaced display is installed without updating that register? > only problem so far, maybe 547 has solved that? Well, if so I need a No, I mainly tried to fix the GVP with 547. Obviously, I'll need your changes to make it really work.. > diff.531-547... BTW Markus, why don't you regularly create a diff file > when you decide to upload a new vmunix. At least I am always eager to > be synchronized with you. I usually do.. But I'm wasn't really happy with 547 for several reasons (it's using quite a lot of new code I updated from sunlamp, with in parts rather radical changes), and I really wanted to test that new code some more before declaring it a full new version. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 09:24:30 1993 Subject: Re: Do you miss your cursor? To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 855 Sender: NetBSD-Admin@cbmuucp.commodore.com > If you're missing your cursor and using the custom chipset, try adding > this statement early in cc_le32_cursor of ite_cc.c: > > if (flag == START_CURSOROPT || flag == END_CURSOROPT) > return; Ouch! Silly me.. of course.. that was an addition I made when Bryan was working on a parallel branch of the ite code, then, in the merge, I used almost all of his cc-dependant parts, and of course forgot to add support for the above changes. The intent was to disable cursor-updates while drawing long text, and reenabling it afterwards. However, it showed to have some problems (probably with cursor-move sequences), so I didn't use it any longer. The above will work fine. Thanks!!! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 09:31:41 1993 Subject: Re: oh my god .... To: ghost@cs.tu-berlin.de (Hartmut Kuehn) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 615 Sender: NetBSD-Admin@cbmuucp.commodore.com > It was as simple as frustating: After I loadwb and changed > the screenmode to ntsc:hires-interlace, the 531 kernel booted > into the beloved BSD :-))))) Although that's nice to hear, I don't want to let this go unnoticed: THIS IS A BUG! Booting from an interlaced workbench is a hack to get around the bug, it is no fix! So.. any demo-coders or other hardware-bangers, have a look at grf_cc.c and tell me which register I forget to setup right? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 12:32:08 1993 To: mw@eunet.ch Cc: amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com Subject: Re: 531, async, GVP Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: Me> Thanks!!! I'm now running NetBSD as I'm typing this message. I Me> compiled Markus W> Phew.. I really cursed this controller ... Well, it *is* kind of unfriendly, requiring the *programmer* to call an interrupt handler :-) :-) :-) Me> A2000. I also established that it is non-interlace that is the Me> culprit when you get a steady grey or blue screen. I put interlace Me> in my Markus W> This is awefully strange.. Although I do install an Markus W> interlaced copperlist, I thought I set up anything to have Markus W> this working from any possible previous screen Markus W> mode. Hmm.. perhaps some custom chip register not Markus W> initialized that makes the machine lockup if an interlaced Markus W> display is installed without updating that register? Your first display driver did not have this problem (you know the one that thrashed the font for some of us). Maybe that fact helps. Me> only problem so far, maybe 547 has solved that? Well, if so I need Me> a Markus W> No, I mainly tried to fix the GVP with 547. Obviously, I'll Markus W> need your changes to make it really work.. I have sent a cursor fix, although not in diff-format, earlier. Other than that, only the interrupt handler call ought to be necessary. Even though I (re)initialize the GVP DMAC, it really should not have to be there unless ADOS AutoConfig goes away. If you really want the init code in there, drop me a message. What else did you touch in the GVP specific sections for 547? I needed nothing more than what I've already stated, and your code looked *very* correct when I checked it. Too bad I didn't check machdep.c at the time. Niklas From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 15:49:55 1993 Subject: Re: 531, async, GVP To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga mailing list) X-Mailer: ELM [version 2.3 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com Niklas Hallqvist: > Markus W> That's one of the most stupid bugs I made recently.. the gvp > Markus W> interrupt handler is plain not invoked... check out - if you > Markus W> compile your own kernel - machdep.c, in the intrhandler > Markus W> where it calls a3000 and a2091 interrupt handlers, if should > Markus W> of course also call gvp ... > > Thanks!!! I'm now running NetBSD as I'm typing this message. I compiled > 531 with the necessary change as well as a possibly unneeded init of the > GVP DMAC which I've got from gvpscsi.device (you know, the regs i call > secret1, secret2 and secret3), and got it running straight away on a 4MB > A2000. Did you compile that kernel with all the SCSI drivers inluded? I compiled a kernel (based on 531) with only GVP driver which got past that usual hanging point (bfp: lo0 etc) but now it gets a MMU fault, asks to press a key to boot/dump, then get a trap (something about bad kernel access at 0) and then it dumps to dev 421 (??) and reboots. Both #547 and that even more new kernel I got from Markus (PPP seems to work fine on his machine :) still lock the SCSI bus. -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 16:18:50 1993 Subject: Re: 531, async, GVP To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1451 Sender: NetBSD-Admin@cbmuucp.commodore.com Niklas Hallqvist wrote: > >>>>> "Markus W" == Markus Wild writes: > Niklas> A2000. I also established that it is non-interlace that is the > Niklas> culprit when you get a steady grey or blue screen. I put interlace > Niklas> in my > Markus W> This is awefully strange.. Although I do install an > Markus W> interlaced copperlist, I thought I set up anything to have > Markus W> this working from any possible previous screen > Markus W> mode. Hmm.. perhaps some custom chip register not > Markus W> initialized that makes the machine lockup if an interlaced > Markus W> display is installed without updating that register? > Your first display driver did not have this problem (you know the one > that thrashed the font for some of us). Maybe that fact helps. I finally tried booting netbsd in interlace mode and it works. I still have problems trying to explain why none of the background color changesI attempted after enabling the MMU worked. Markus, reading through the code, the custom chip registers are mapped pa==va, aren't they? I'm just poking a value into 0xdff180. Maybe you should take a look into this. BTW, how do you create /dev/reboot? What are the major and minor device numbers? ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 16:42:49 1993 Subject: Tape drive question... To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I have a chance to buy a used (refurbished) tape drive, and was wondering if anybody has used this particular drive with amiga bsd. The drive is a Cipher ST150S-II 1/4" 150MB QIC-150 SCSI cartridge tape drive. Thanks for any information. -- Steven Caranci caranci@ecf.utoronto.ca From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 18:12:03 1993 Subject: Re: 531, async, GVP To: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: niklas@appli.se, amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 807 Sender: NetBSD-Admin@cbmuucp.commodore.com > I finally tried booting netbsd in interlace mode and it works. I Hah, another one :-) > still have problems trying to explain why none of the background color > changesI attempted after enabling the MMU worked. Markus, reading > through the code, the custom chip registers are mapped pa==va, aren't > they? I'm just poking a value into 0xdff180. Maybe you should take a > look into this. Bad boy:-) They are NOT:-) In fact, nothing is mapped 1:1 at all. Check out grf_cc.c for reference how to access various hardware. > BTW, how do you create /dev/reboot? What are the major and minor > device numbers? mknod /dev/reboot c 2 20 -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 19:46:07 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: failing kernels Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 4, 4:35pm, Eduardo E. Horvath eeh@btr.com wrote: [...] > I have had exactly the same problem. My configuration: > > A2500/30, 1MB Chip, 4MB Fast, and a Fujitsu M2624SA at id 0 with bsd > on it. Means A2091 as SCSI-Adaptor, no ? I have that config, too, and since vmunix.531, everything works fine for me. Between #350 and #487, i was not able to see the console. -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 20:18:51 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: oh my god .... Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 5, 10:18pm, Hartmut Kuehn wrote: [...] > It was as simple as frustating: After I loadwb and changed > the screenmode to ntsc:hires-interlace, the 531 kernel booted > into the beloved BSD :-))))) Huh ? Really ? Why is that so ? This could explain why i coundln't boot into BSD with my A2000 lately, because in the meantime i connected an A2024 Monitor and do run Interlace, before i had unsupportable 1084 ... -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 6 21:50:52 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: panic! Sender: NetBSD-Admin@cbmuucp.commodore.com > I installed NetBSD from scratch again, and the panic's did not go :-( Each time you crash, you HAVE to do fsck, or face really weird problems... That's what I did (after another PTpage-panic), and to my surprise, fsck found nothing to fix. This happened right after I installed a new rootfs and newfs'ing my other NetBSD-partitions. SO I decided to move back to 531. I used 531 for about 4 hours compiling, installing, copying, moving and emacsing a lot, and not a single crash. Actually everything works flawlessly. Perfect :-) That's the way I like vmunix to behave :-) I think that there is something wrong with 547. Somewhere, where the MMU is used. Markus, did you change the MMU code in 547? Bye, Harald (using 531 and being happy again) From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 03:54:42 1993 Subject: vmunix.nh - thanks To: niklas@appli.se Cc: netbsd-amiga@cbmuucp.commodore.com (Amiga NetBSD mailing list) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Niklas, Thanks for sending me the kernel, I booted into single user mode no problem. I encountered problems though when trying to boot into multiuser mode. It went through starting all the daemons and got to the point where it says "Starting local daemons:." and displays the date. At this point it hangs and continually displays the message "init FATAL error: console: Interrupted system call". Any ideas? Thanks again Niklas. Cheers, Trevor. -- +---------------------------------------------------------------------+ | "Let me be the first to offer you my sincerest contrafibularities" | | - E. Blackadder | +----------------------------+----------------------------------------+ | Trevor Elbourne | Computer and Systems Technology (CaST) | | trevore@vast.unsw.edu.au | Dept of Computer Science & Engineering | | trevore@cse.unsw.edu.au | University of New South Wales | +----------------------------+----------------------------------------+ From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 16:31:00 1993 Subject: Re: vmunix.nh - thanks To: trevore@vast.unsw.edu.au (Trevor Elbourne) Cc: niklas@appli.se, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 351 Sender: NetBSD-Admin@cbmuucp.commodore.com > date. At this point it hangs and continually displays the message > "init FATAL error: console: Interrupted system call". Any ideas? You didn't seem to install libexec/getty, right? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 17:17:55 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Ameristar/A2065 Ethernet card Sender: NetBSD-Admin@cbmuucp.commodore.com I just recently connected my A3000 to a Linux PC with an ethernet, using the old Ameristar card on the Amiga. Naturally I'd like to get NetBSD to use it. So, is anyone working at the moment on an Ameristar/A2065 driver? (I understand these two boards are pretty much the same as far as software goes.) If not, does anyone know where I could get programming info for it? (Commodore, you there? ;-) ) Thanks! Bryan From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 19:35:25 1993 Subject: Re: Ameristar/A2065 Ethernet card To: baford@schirf.cs.utah.edu (bryan ford) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 786 Sender: NetBSD-Admin@cbmuucp.commodore.com > I just recently connected my A3000 to a Linux PC with an ethernet, > using the old Ameristar card on the Amiga. Naturally I'd like to > get NetBSD to use it. So, is anyone working at the moment on > an Ameristar/A2065 driver? (I understand these two boards are > pretty much the same as far as software goes.) If not, does > anyone know where I could get programming info for it? > (Commodore, you there? ;-) ) Oh.. cool someone to care for the ethernet driver:-) Check out if_le.c, this is alread a LANCE driver, it just needs more work to feel at home on the amiga boards. both ameristar and 2065 vector there. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 21:36:54 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Ameristar/A2065 Ethernet card Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 7, 7:32pm, Markus Wild wrote: > Subject: Re: Ameristar/A2065 Ethernet card > > I just recently connected my A3000 to a Linux PC with an ethernet, > > using the old Ameristar card on the Amiga. Naturally I'd like to > > get NetBSD to use it. So, is anyone working at the moment on > > an Ameristar/A2065 driver? (I understand these two boards are > > pretty much the same as far as software goes.) If not, does > > anyone know where I could get programming info for it? > > (Commodore, you there? ;-) ) > > Oh.. cool someone to care for the ethernet driver:-) Check out if_le.c, > this is alread a LANCE driver, it just needs more work to feel at home > on the amiga boards. both ameristar and 2065 vector there. Well, i was able to test the A2065 while my A2000 was on Internet, as this possibility is gone... *sniff* We _need_ *grin* Ethernet, Slip, PPP or Arcnet support for the upcoming meetings :-) As PPP is almost done, does anybody know if there is a PPP-driver for Amiga-DOS or PC-Linux ? -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 7 23:39:23 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Are your shakes made Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 7, 5:24pm, local account wrote: > Subject: Are your shakes made > > with real milk, or a reconstituted shake mix? With milk. Not cheese or any other sort of rotten milk. -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 8 00:09:31 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Test Sender: NetBSD-Admin@cbmuucp.commodore.com Please ignore. From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 8 00:10:17 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: NTSC:Interlaced issue & more Sender: NetBSD-Admin@cbmuucp.commodore.com Sure enough, changing my 1.3 workbench to interlaced fixed my booting problem. Now I am faced with another problem: the locking SCSI bus after sync negotiation... So, I binpatched 547 to supposedly not enable sync negotiation for devices 6 (my Quantum L105PS) and 4 (my "unsupported" Cipher SCSI-II tape drive). It still locked up. Both the sync and nosync kernels returned: (note tape) scsi0: target 4 now syncronous, period=0ns offset=0. sbic_wait TIMEO @1174 with asr=x0 csr=x4a st0: Cipher >ST150S-2< Rev 5.4 st0: Unsupported tape device st0 at a2091scsi0, slave 4 scsi0: target 6 now syncronous, period=256ns offset=8. sbic_wait TIMEO @1174 with asr=x0 csr=x4a [SCSI BUS HANG] From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 8 05:44:53 1993 Subject: Re: vmunix.nh - thanks To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (Amiga NetBSD mailing list) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > date. At this point it hangs and continually displays the message > > "init FATAL error: console: Interrupted system call". Any ideas? > > You didn't seem to install libexec/getty, right? > > -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 > Yeah sorry. I didn't realise it at the time but I had some errors installing the /usr/include distribution. All is OK now :) Thanks, Trevor. -- +---------------------------------------------------------------------+ | "Let me be the first to offer you my sincerest contrafibularities" | | - E. Blackadder | +----------------------------+----------------------------------------+ | Trevor Elbourne | Computer and Systems Technology (CaST) | | trevore@vast.unsw.edu.au | Dept of Computer Science & Engineering | | trevore@cse.unsw.edu.au | University of New South Wales | +----------------------------+----------------------------------------+ From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 8 19:12:06 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Organization: Request BBS X-Charset: iso-8859-1 To: netbsd-amiga@cbmuucp.commodore.com Subject: A2000/2091 still not working Sender: NetBSD-Admin@cbmuucp.commodore.com I am still having problems running netbsd with my A2000/2630 and a 2091. Right now, I am trying to get vmunix 531 and 547 to boot, but nothing... I've installed netbsd on my new Maxtor 345, with a 6M ados partition, a 9M root partition(just in case), a 12M swap, and then 3 100M partitions, usr, home, and opt...all in that order. The maxtor is id6 and nothing is at id4. I've got a Syquest88 at id5, a Q52 at id3, and a Q105 at id2. I have 4M on my 2630 and 2M on my 2091, with 1M chip...loadbsd tells me using 1M chip and 6M fast. I did a new install of ADos 2.1 into the ados partition, and only stuck a shell into wbstartup. I put loadbsd and the vmunix files onto that sys: partition and boot into that. loadbsd works, and now that I run an INTERLACED wb screen I get into bsd. Both versions look pretty much the same, although I get avail mem = 4358144 for v547 and 3981312 for v531, and the rest goes like: using 76 buffers containing 622592 bytes of memory Realtime Clock A2000 rtclock0 [1/9] grf0: 640 x 400 monocrome custom chips display grf0: [1/7] ser0: [1/3] dma0: GVPII DMA scsi0: scsi id 7 GVPIIscsi0: [2017/11] at which point both version just hang there...and only under v531, when I hit a key I get: trap: bad kernek access at 0 trap type 8, code = 200072d, v = 0 pid = 0, pc = 000012192, ps = 2200, sfc = 0001, dfc = 0001 then dreg/areg/kernel stack/registers(I also wrote down) then: panic: MMU fault hit any key to boot/dump > at which point v531 gets stuck also. So, any suggestions, and more importantly, why does it think I have a GVP controller? It's a 2091 v6.6. I've installed the rootfs off of eunet, which is a different size then the rootfs-0611 I got off of wuarchive, several times making sure it is reading and writing by watching the lights, since I don't think filetodev breaks if it can't open 'rootfs' Thanks, Erik Karlin -- Coming to you live and direct Erik_Karlin@erixami.linet.org Request BBS // - OR - (516) 471-4818 v32.bis \X/ root@erixami.linet.org Amiga/Adult And the rest is left as an exercise From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 04:19:50 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: vmunix.570 vs. A2091/33c93-PL Sender: NetBSD-Admin@cbmuucp.commodore.com Tell me if I'm doing this wrong: > binpatch -s _inhibit_sync vmunix.570 _inhibit_sync(0x72bdc): 0 (0x0) So I want to inhibit sync for device 6, which is my Quantum 105, which locks up after identify, and on what I guess is the first data_in phase from media. 0x72bdc + 6 (id 6) = 0x72be2 >binpatch -b -a 0x72be2 -r 1 vmunix.570 0x72be2: 0 (0x0) I then copy it to tape, unload it on the BSD slave, then it still comes back with a sync negotiation of 256ms with an offset of 8, rather than an sync neg of 0ms and an offset of 0. So, my 33c93-PL, says "Hey, forget this stuff." Crap, I get bit by the NTSC:Hires-Interlaced problem, and now this.. Someday ;-). I hope to at least get to a prompt. Thanks Markus for losing a little sleep and putting the source and kernal (kernel, however you want to spell it) up on ftp.eunet.ch. From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 08:27:28 1993 Subject: Re: vmunix.570 vs. A2091/33c93-PL To: billc@icecube.rain.com (William J. Coldwell) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Tell me if I'm doing this wrong: > > > binpatch -s _inhibit_sync vmunix.570 > _inhibit_sync(0x72bdc): 0 (0x0) > > So I want to inhibit sync for device 6, which is my Quantum 105, > which locks up after identify, and on what I guess is the first > data_in phase from media. > > 0x72bdc + 6 (id 6) = 0x72be2 > > >binpatch -b -a 0x72be2 -r 1 vmunix.570 > 0x72be2: 0 (0x0) This looks right to me, assuming that you have a 3000. I had to go through the same thing myself to get booted from my external Maxtor. I don't have access to the sources right now, but if you have some other controller, try setting 0x72bea and 0x72bf2 to 1 as well (just going down the column for device 6). If you're really desperate you may want to try setting the whole 24-byte array to 1's. > I then copy it to tape, unload it on the BSD slave, then it still You did a loadbsd of the patched kernel, right? Worry about updating /vmunix when you get booted succesfully! -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 09:16:17 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: vmunix.570 vs. A2091/33c93-PL Sender: NetBSD-Admin@cbmuucp.commodore.com >From: ahh@netcom.com (Andy Heffernan) > >binpatch -b -a 0x72be2 -r 1 vmunix.570 > 0x72be2: 0 (0x0) >I don't have access to the sources right now, but if you >have >some other controller, try setting 0x72bea and 0x72bf2 to 1 as well >(just going down the column for device 6). If you're really desperate >you may want to try setting the whole 24-byte array to 1's. I did, it didn't. I tried changing ALL of the array to 1s, to no avail. It _still_ gives me the sync negotiation messages and pukes with a 0x4a. During the identify's I get a TIMEO with a 0x4e right before it displays the Archive Viper Tape drive as ST0. (I pulled the Cipher tape drive off in favor of one that is known to work under the kernal). >> I then copy it to tape, unload it on the BSD slave, then it still > You did a loadbsd of the patched kernel, right? Worry about >updating /vmunix when you get booted succesfully! Yeh, I don't have that problem, because I can't GET to a command prompt under BSD ;-). I've noticed that when I do the binpatch, the returned value is always 0, which according to the binpatch doc is wrong.. any ideas? This would explain why nothing is changing in the kernel. From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 09:56:34 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: How should we handle non BSD partitions? Sender: NetBSD-Admin@cbmuucp.commodore.com I'm sure more people than me have thought about adding the Amiga filesystems to NetBSD. This implies that Amiga partitions must get their own device nodes in /dev, which they don't today. Now, how should we arrange for them to get this? The easiest thing would be a straight mapping of the PARTs as specified by the RDB, but that would be backward incompatible. Another way would be to tag all non-BSD partitions with a dedicated bit in the minor number, aren't bit 6 & 7 available? If we just decide on a convention, I can/will implement it. Is anyone else working on an Amiga filesystems implementation? Anyone working on a floppy driver? parallel driver? What are people really working on? Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 17:38:20 1993 Subject: Re: vmunix.570 vs. A2091/33c93-PL To: billc@icecube.rain.com (William J. Coldwell) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com billc laments: > >From: ahh@netcom.com (Andy Heffernan) > > >binpatch -b -a 0x72be2 -r 1 vmunix.570 > > 0x72be2: 0 (0x0) > > >I don't have access to the sources right now, but if you >have > >some other controller, try setting 0x72bea and 0x72bf2 to 1 as well > >(just going down the column for device 6). If you're really desperate > >you may want to try setting the whole 24-byte array to 1's. > > I did, it didn't. I tried changing ALL of the array to 1s, to no avail. > It _still_ gives me the sync negotiation messages and pukes with a 0x4a. > During the identify's I get a TIMEO with a 0x4e right before it displays > the Archive Viper Tape drive as ST0. (I pulled the Cipher tape drive off > in favor of one that is known to work under the kernal). > > >> I then copy it to tape, unload it on the BSD slave, then it still > > > > You did a loadbsd of the patched kernel, right? Worry about > >updating /vmunix when you get booted succesfully! > > Yeh, I don't have that problem, because I can't GET to a command prompt > under BSD ;-). Yeah, that's obvious to me now -- I got confused by your statement about copying the kernel to your BSD slave (at least that's the cover story I'm using!) > I've noticed that when I do the binpatch, the returned value is always 0, > which according to the binpatch doc is wrong.. any ideas? This would > explain why nothing is changing in the kernel. Do you mean that if you run the same "binpatch -r 1" command twice in a row, it still says something like: 0x72be2: 0 (0x0) It shouldn't, the line that's printed out shows what's there now, so it should change to: 0x72be2: 1 (0x1) A couple more things to try would be to try working with longs instead of bytes (this is what I did because I forgot about the -b switch), so you would do "binpatch -l -a 0x72be0 -r 512 vmunix.570"; or, as a test of binpatch, try setting scsi_debug (a long) to 1, and see if you notice any change in output while booting (maybe you're already doing this). -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 18:39:22 1993 Subject: Re: A2000/2091 still not working To: Erik_Karlin@erixami.linet.org Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 933 Sender: NetBSD-Admin@cbmuucp.commodore.com > dma0: GVPII DMA > scsi0: scsi id 7 > GVPIIscsi0: [2017/11] > > at which point both version just hang there...and only under v531, when I > hit a key I get: > > trap: bad kernek access at 0 > trap type 8, code = 200072d, v = 0 > pid = 0, pc = 000012192, ps = 2200, sfc = 0001, dfc = 0001 > > then dreg/areg/kernel stack/registers(I also wrote down) then: > > panic: MMU fault > hit any key to boot/dump > > > > at which point v531 gets stuck also. > > > So, any suggestions, and more importantly, why does it think I have a GVP > controller? It's a 2091 v6.6. I've installed the rootfs off of eunet, which *VERY* strange.. it even shows the GVP manufacturer/product code, could you do a "showconfig" to verify that your 2091 values are really 2091 values? -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 18:58:09 1993 Subject: Re: vmunix.570 vs. A2091/33c93-PL To: billc@icecube.rain.com (William J. Coldwell) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1499 Sender: NetBSD-Admin@cbmuucp.commodore.com > I then copy it to tape, unload it on the BSD slave, then it still > comes back with a sync negotiation of 256ms with an offset of 8, > rather than an sync neg of 0ms and an offset of 0. So, my 33c93-PL, > says "Hey, forget this stuff." Hmm.. might your drive initiate sync handshake itself? Inhibit_sync just inhibits the controller to initiate sync itself (and I don't think it currently handles sync-init from the target, since it assumes it's always WE that initiate sync..). > Someday ;-). I hope to at least get to a prompt. Modest:-) > Thanks Markus for losing a little sleep and putting the source and > kernal (kernel, however you want to spell it) up on ftp.eunet.ch. No problem.. I was in PPP-fever anyway:-) BTW: for those that didn't notice, there's a new kernel with source, #570, up on eunet. Featuring: - *much* faster RS232 handling (should now deal with 38400 without problems, perhaps even faster, although I couldn't test that). - an attempt to fix the cursor bug, apparently didn't work - includes working(!) PPP line discipline, get ppp-1.3.tar.Z and compile pppd if you want to use it. - perhaps (:-)) working ioctl's to load and get keymaps (I'll have to retry that feature, last time I had to reboot because my keymap was hosed..) - support one (my:-)) addition flavor of Python drive -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 19:00:39 1993 Subject: Re: How should we handle non BSD partitions? To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 967 Sender: NetBSD-Admin@cbmuucp.commodore.com > I'm sure more people than me have thought about adding the Amiga > filesystems to NetBSD. This implies that Amiga partitions must get > their own device nodes in /dev, which they don't today. Now, how > should we arrange for them to get this? The easiest thing would be > a straight mapping of the PARTs as specified by the RDB, but that would > be backward incompatible. Another way would be to tag all non-BSD Not only, we'd lose the nice flexibility to reorder partitions without BSD knowing, ie. mount from another root, have another usr, etc. > partitions with a dedicated bit in the minor number, aren't bit 6 & 7 > available? If we just decide on a convention, I can/will implement it. Hm, some bits are used for LUNs, could be 6&7.. But we could use them.. who needs luns anyway:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 19:29:25 1993 Subject: Re: A2000/2091 still not working To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga mailing list) X-Mailer: ELM [version 2.3 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com Markus Wild: > > > dma0: GVPII DMA > > scsi0: scsi id 7 > > GVPIIscsi0: [2017/11] > > > > at which point both version just hang there...and only under v531, when I > > hit a key I get: > > > > trap: bad kernek access at 0 > > trap type 8, code = 200072d, v = 0 > > pid = 0, pc = 000012192, ps = 2200, sfc = 0001, dfc = 0001 This looks familiar, I got this from my own-compiled 531 kernel (all other SCSI controllers disabled besides GVP): ... bpf: lo0 attached vm_fault(f2000, 40000000, 1, 0) -> 1 type 8, code [mmu, ssw]: 2000755 trap type 8, code = 2000755, v = 40000001 pid = 0, pc = 00000D94 etc register and kernel stack dump follow. Previously I saw only the kernel stack, as I used that BIG mach font (it isn't *that* ugly, just too big :) #570 kernel still stops after that lo0-line, and SCSI bus light stays on... -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 20:57:01 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Networking Status Sender: NetBSD-Admin@cbmuucp.commodore.com What is the current networking status for NetBSD? Next week I will be moving my computer back to school, where I have a permanent fast SLIP connection to the Internet. (I also have an ethernet hookup, unfortunately I've decided I'd rather buy food than an ethernet card...) SLIP seems to be supported, has anyone had success with this? I don't want to waste a lot of time trying to get it to work if it's impossible. :) I'm new at Unix administration, but from my understanding, the following should do it: Add my hostname and IP address to /etc/hosts Get the netmask right in /etc/something Set up the default route in /etc/wherever ifconfig... (Or let rc do it) How do I get the correct baud rate for sl0? DNS should come naturally if it can find a route out, I think. (Assuming NetBSD supports DNS) Anything else I need to do to get on the network? Thanks, Nathan From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 21:28:31 1993 Subject: New GVP behavior in 570. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 557 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all, Under 547, my GVP system died at the 'lo0' point. Now, under 570 I get the following message, right after my HD is found: scsi0: abort icmb: csd=0x48, asr=0x00. Then, every 15 secs or so: sbic_wait TIMEO @636 with asr =x0 csr =x40 This appears before the 4 attachment lines appear. ----------------------------------------------------------------------------- Ryan K. Brooks ryan@chaos.mcs.mu.edu (NeXTmail happy) BIX:rbrooks "Is is and isn't isn't." IRC:RB From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 9 22:42:39 1993 Subject: Re: vmunix.570 vs. A2091/33c93-PL To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Markus writes: [...] > BTW: for those that didn't notice, there's a new kernel with source, #570, > up on eunet. Featuring: Diffs? -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 01:15:51 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: 570 prblems... Sender: NetBSD-Admin@cbmuucp.commodore.com vmunix.570 does not work on my GVP although the interrupt handler is now called. I will investigate this tomorrow if only I can get a full 570 arcive. bsdsyssrc.570.tar.gz lacks at least these files: sys/netiso/iso_rrip.h sys/isofs/isofs_rrip.[ch] kern/tty_subr.c Maybe more files is missing too, I'll let you know tomorrow when my 570 compilation is ready. Markus, can you supply a complementary tar file with the missing files? My guess is that the GVP somehow needs the secret init, if so, I will post my patch here ASAP (it should be 5 lines or so).Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 04:13:05 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: What are we working on? (was: How should we handle non BSD partitions?) Sender: NetBSD-Admin@cbmuucp.commodore.com >From: niklas@appli.se (Niklas Hallqvist) >What are people really working on? My 1st goal (besides getting a good compile under AmigaDOS, and getting up to a command line prompt under BSD) is to get a 5380 driver written. This will have the most effect of getting accelerated A2000s up and running, since the 33c93 (already done) and 5380 are the majority of controllers in use on those Amigas. My 2nd goal is to get an IDE driver working, affecting the rest of our NetBSD brethren on A4000/40 (once the MMU code is working) and accelerated A1200s. My 3rd goal is to get a 53c710 driver working. This is mainly for my own benefit for my CSA 40/4 Magnum, but it will also affect 4091 users. Since I have written these drivers on the Amiga before, I believe that within a short period of time of understanding how drivers work under BSD, we can have these distributed. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 04:50:05 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: What are we working on? (was: How should we handle non BSD partitions?) Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 9, 2:35am William J. Coldwell writes: > >From: niklas@appli.se (Niklas Hallqvist) > >What are people really working on? > My 2nd goal is to get an IDE driver working, affecting the rest of > our NetBSD brethren on A4000/40 (once the MMU code is working) and > accelerated A1200s. I'm starting to look at getting NetBSD to run on my Zeus accelerator which uses the 68040. It looks to be more effort than it took to get Amiga Mach (Kludgemach) to run on the Zeus. > My 3rd goal is to get a 53c710 driver working. This is mainly for my > own benefit for my CSA 40/4 Magnum, but it will also affect 4091 > users. The Zeus card uses the 53c710, so I will be interested in this. I've disassembled the Zeus driver and figured out how it works well enough to get a Minix driver running. I was thinking about tackling the Mach version, but I would rather have a NetBSD version. If I can get NetBSD to run on my 68040, I will probably be looking at a 53c710 driver. (I've also got a GVP Series II controller, although it won't do DMA to the 32 bit memory.) > Since I have written these drivers on the Amiga before, I believe > that within a short period of time of understanding how drivers work > under BSD, we can have these distributed. I've has some experience with the SCSI drivers on Kludgemach and had written a driver for my homemade SCSI board that uses the 5380. I was able to get the driver to read my disk and tape drivers, even though the board is non-DMA and non-interrupt. Michael -- -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 04:58:19 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Amiga NetBSD on 68040 Sender: NetBSD-Admin@cbmuucp.commodore.com I finally decided to take a look at getting NetBSD to run on my PPI Zeus accelerator. It's going to take more effort than it did to get the Amiga Mach kernel to run on the 68040. So I was wondering if anyone has thought about/looked at/done anything about adding the 68040 support to NetBSD? I've got an environment on AmigaDOS to compile the kernel and have gotten a clean compile of the current kernel. I'm now trying to figure out how the MMU is set up and used for the 68030 and see how much work it will be to get the MMU code to work for the 68040. Michael -- -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 07:13:25 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: me vs. binpatch vs. vmunix.570 Sender: NetBSD-Admin@cbmuucp.commodore.com Me: 0 binpatch: 1 vmunix: 1 duh duh duh.. when I copied the file over from the NeXT, it was read only. Since binpatch didn't care to printout something, I figured something was funky with it. In any case, I have binpatch working, I have the sync disabled, and my system boots up to just after where lo0: is added, then dies with a bad kernel access in d4. sigh.. still trying for that prompt. ;-). At least I'm little further. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 13:11:29 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Organization: Request BBS X-Charset: iso-8859-1 To: mw%eunet.ch%imageek@src4src.uucp.commodore.com Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A2000/2091 still not working Sender: NetBSD-Admin@cbmuucp.commodore.com In <199308091635.AA21613@chsun.eunet.ch> on Aug 9, Markus (Markus Wild) wrote: > > dma0: GVPII DMA > > scsi0: scsi id 7 > > GVPIIscsi0: [2017/11] > > > > at which point both version just hang there...and only under v531, when I > > hit a key I get: > > > > trap: bad kernek access at 0 > > trap type 8, code = 200072d, v = 0 > > pid = 0, pc = 000012192, ps = 2200, sfc = 0001, dfc = 0001 > > > > then dreg/areg/kernel stack/registers(I also wrote down) then: > > > > panic: MMU fault > > hit any key to boot/dump > > > > > > > at which point v531 gets stuck also. > > > > > > So, any suggestions, and more importantly, why does it think I have a GVP > > controller? It's a 2091 v6.6. I've installed the rootfs off of eunet, which > > *VERY* strange.. it even shows the GVP manufacturer/product code, could you > do a "showconfig" to verify that your 2091 values are really 2091 values? > Oh yea, did I forget to mention my GVP I/O Extender?...It hit me as soon as you said showconfig...oops. I just grabbed v570, and the exact same thing happens, it thinks I've got a GVP controller. Anyway, here is my showconfig, and hopefully someone will recognize a difference between detecting my I/O Extender and a controller...and perhaps even recognize the extender. PROCESSOR: CPU 68030/68882fpu/68030mmu CUSTOM CHIPS: ECS NTSC Agnus (id=$0030), ECS Denise (id=$00fc) VERS: Kickstart version 37.175, Exec version 37.132, Disk version 38.35 RAM: Node type $a, Attributes $205 (FAST), at $200000-$7fffff (6.0 meg) Node type $a, Attributes $303 (CHIP), at $400-$fffff (~1.0 meg) BOARDS: CBM A2630 68030/RAM card: Prod=514/81($202/$51) (@$200000 4meg Mem) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) CBM A590/A2091 HD controller: Prod=514/3($202/$3) (@$ea0000 64K) CBM A2052/58.RAM | 590/2091.RAM: Prod=514/10($202/$a) (@$600000 2meg Mem) Obviously, the unidentified board is the GVP I/O Extender...and the prod codes, not suprisingly, match what bsd reports. So, any suggestions now, short of removing my i/o extender, which isn't an option, since I'm trying to run a BBS while I attempt to get bsd to run. Thanks for the help! -Erik -- Coming to you live and direct Erik_Karlin@erixami.linet.org Request BBS // - OR - (516) 471-4818 v32.bis \X/ root@erixami.linet.org Amiga/Adult And the rest is left as an exercise From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 13:40:51 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: NetBSD and Hardware Compatibility List Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all, I thought it would be a good idea to gather the information about all the hardware that is known to work with NetBSD-Amiga or know NOT to work with NetBSD-Amiga. Maybe it is even possible to maintain who is working on a driver for what to see what is being implemented at the moment. Format of each entry could be as follows: Class: {Computer, harddisk, Floppy, Mouse, Tapedrive, ...} Name: {name of the device; if you're reporting, please be as specific as possible} Capacity: {Maximum size of the device, if sensible for that device} Approx Cost: {Roughly what you paid, maybe interesting} Interface: {How it talks to the machine - SCSI, PC bus, etc} Controllers: {What controller you're using - Adaptec 1542B, etc} Informant: {Who says it does or doesn't work} Comments: {Anything good or bad you feel like saying. If the device does not work with NetBSD, maybe you can tell us why.} If you are a kernel-hacker and you are working on a driver for this device, please let us also know. Feel free to send any comments on this to the mailing-list. If you want to send information about your working configurations, please send this information to s_grau@ira.uka.de I will maintain the list. If it doesn't get to long, I will incorporate this list into the FAQ. Otherwise it will be remain a seperate list. Guenther From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 14:35:53 1993 To: Erik_Karlin@erixami.linet.org Cc: mw%eunet.ch@src4src.uucp.commodore.com, netbsd-amiga@cbmuucp.commodore.com Subject: Re: A2000/2091 still not working Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Erik" == Erik Karlin writes: Erik> Obviously, the unidentified board is the GVP I/O Extender...and Erik> the prod codes, not suprisingly, match what bsd reports. So, Erik> any suggestions now, short of removing my i/o extender, which Erik> isn't an option, since I'm trying to run a BBS while I attempt Erik> to get bsd to run. If you can recompile NetBSD, remove the GVP lines in sys/arch/amiga/conf/AMIGA. If not, wait until those of us who cares (I do, and I suspect Markus does as well) solves the problem. It's really a BAD manner to reuse product ID's this way, shame on GVP, although they make some nice HW. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 15:25:37 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: 570 problems... Sender: NetBSD-Admin@cbmuucp.commodore.com Hi again. I got those missing files from sun-lamp and compiled 570... and it did not work on a GVP controller!!! Markus, you have probably not got enough sleep the last weeks, as your fixes to the GVP bug AND to the cursor bug are faulty although they were sooo trivial :-) First, in order to successfully test NGVP11SCSI in machdep.c, you have to include a certain file... Yep! gvp11scsi.h, and it would be nice to have the CURSOROPT check be in the *right* cursor routine (cc_le32_cursor!). Well, I guess that is the only time I get to correct this divine programmer *twice* in a single day :-). What's worse, is that the new beautifully designed serial driver, somehow messes modem up dialin ports. I suspect it has something to do with the modem control interrupt simulation. Now I can only once login on my NetBSD A2000 when calling home from the office. The second time the serial port just hangs, that's why I cannot provide the patch file I made for the above fixes in this mail. Otherwise 570 works OK on a GVP combo equipped A2000 with 4MB fastRAM. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 17:06:54 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: billc@iceCuBE.commodore.com (William J. Coldwell), netbsd-amiga@cbmuucp.commodore.com Subject: Re: What are we working on? (was: How should we handle non BSD partitions?) Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 9, 2:35am, William J. Coldwell wrote: [...] > My 2nd goal is to get an IDE driver working, affecting the rest of > our NetBSD brethren on A4000/40 (once the MMU code is working) and > accelerated A1200s. Last thing i heard was, that Stefan Boberg is interested in supporting both, the 040 MMU and the IDE of the A4000. But he won't start before two month from now (military service). As he is certified develloper, he should have the right manuals, too (IDE). > My 3rd goal is to get a 53c710 driver working. This is mainly for my > own benefit for my CSA 40/4 Magnum, but it will also affect 4091 > users. A4091 has NCR Chip ? Interesting. -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 17:46:00 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Meeting Sender: NetBSD-Admin@cbmuucp.commodore.com Allthough it may be a bit late and possibly not for interest for non-europeans, i would like to invite the Amiga-NetBSD community to my (mostly) Amiga-Meeting/Gathering the 28.8 and 29.8 in Bielefeld/Germany (If you look it up in a map: It's between Hannover and Dortmund, northern part of Germany). As Markus Wild himself is coming, and most of the german NetBSD users are attempting the meeting, too, this meeting might be both: interesting and important for the NetBSD-future. Over 100 peoples, mostly german Amiga-Freaks (the upper 10,000 :-), with Internet or Usenet access are coming, and also bring along their computers and other hardware. About 36 hours of fun granted. Unfortunately no Commodore official (ie. Peter Kittel) is interested into joining, though lot's of certified devellopers are coming. If you are interested, please mail me (private). -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 17:50:42 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: binpatch help + misc... Sender: NetBSD-Admin@cbmuucp.commodore.com OK, I originally thought the kernel releases were bad for my standard 3000. (490> kernels worked fine) But then someone mention- ed something that wasn't what I got w/ binpatch. I do the search, then apply the patch with: binpatch -b -a 0x12345 -r 1 vmunix. But instead of getting 1 (0x1) I get 168848 (0x1) -not exact same numbers... When I boot 570 it goes down to lo0 then locks. So, I think it's binpatch. Does anyone else have this prob? And what do I need to do to fix it? For the one who has a GVP I/O Extender, I have one too and it hasn't caused any problems w/ NetBSD. That's the correct board address and all. Fact is I pray someone will write a driver for it someday... Anyone succesfully ported irc2 for term? I've had no luck. But term works quit nicely. TTFN - TC -- Techno Caster - ah360@yfn.ysu.edu From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 19:10:59 1993 Subject: Re: binpatch help + misc... To: ah360@yfn.ysu.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 982 Sender: NetBSD-Admin@cbmuucp.commodore.com > then apply the patch with: binpatch -b -a 0x12345 -r 1 vmunix. Just to make sure.. you did NOT use 0x12345 really?? > But instead of getting 1 (0x1) I get 168848 (0x1) -not exact same Ugh.. > numbers... When I boot 570 it goes down to lo0 then locks. So, I > think it's binpatch. Does anyone else have this prob? And what do > I need to do to fix it? Well if you really patched location 0x12345... > For the one who has a GVP I/O Extender, I have one too and > it hasn't caused any problems w/ NetBSD. That's the correct board > address and all. Fact is I pray someone will write a driver for > it someday... Hm.. but it is confirmed that both the Extender and the SCSI boards have the same product number?? I really start thinking about not supporting such manufacturers at all.. *THIS SUCKS* ! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 19:25:04 1993 Subject: Re: 570 problems... To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1848 Sender: NetBSD-Admin@cbmuucp.commodore.com > work on a GVP controller!!! Markus, you have probably not got enough > sleep the last weeks, as your fixes to the GVP bug AND to the cursor bug > are faulty although they were sooo trivial :-) First, in order to *GRIN* Well, they're both territory I once said I won't support at all (myself), since I don't have a GVP controller and I don't use the cc display, this is a weak excuse I know.. :-) I almost never have enough sleep, somehow these irc sessions won't stop before morning of the following day.. > successfully test NGVP11SCSI in machdep.c, you have to include a certain > file... Yep! gvp11scsi.h, and it would be nice to have the CURSOROPT Well ahem... :-) > check be in the *right* cursor routine (cc_le32_cursor!). Well, I guess Hey I even thought about adding it to both, but somehow I forgot about it.. > that is the only time I get to correct this divine programmer *twice* in > a single day :-). What's worse, is that the new beautifully designed Hm.. I'd vote for kernel hacker:-) > serial driver, somehow messes modem up dialin ports. I suspect it has > something to do with the modem control interrupt simulation. Now I can > only once login on my NetBSD A2000 when calling home from the office. > The second time the serial port just hangs, that's why I cannot provide > the patch file I made for the above fixes in this mail. Otherwise 570 > works OK on a GVP combo equipped A2000 with 4MB fastRAM. Hmm.. what's happening exactly?? You do know about the two "switch" tty's /dev/tty01 and /dev/tty02? Doing I got those missing files from sun-lamp and compiled 570... and it did not > work on a GVP controller!!! Markus, you have probably not got enough sys/isofs/*rrip* and sys/kern/tty_subr.c > the patch file I made for the above fixes in this mail. Otherwise 570 > works OK on a GVP combo equipped A2000 with 4MB fastRAM. But doesn't work on my G-Force 030, *sigh* :-( I added that #include to machdep.c and compiled with original 570 settings, but I still get vm_fault after lo0 is attached, same as with my own-compiled 531. The gvp driver itself seems to work, as the kernel is dumped succesfully to swap, but there's someting fishy going on somewhere else... -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 21:27:34 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: mw@eunet.ch (Markus Wild), ah360@yfn.ysu.edu Subject: Re: binpatch help + misc... Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 10, 6:51pm, Markus Wild wrote: > Hm.. but it is confirmed that both the Extender and the SCSI boards > have the same product number?? I really start thinking about not > supporting such manufacturers at all.. *THIS SUCKS* ! Well, you have seen how many problems the original HP NetBSD has with the floppies ? :-) (see rd.c) I still tend to support any manufacturer, but not the automagic way you do it, a nice 'table' supplied as parameter to loadbsd could be one alternative, the other is LKM... *hint hint :-)* -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 23:19:32 1993 Subject: Re: binpatch help + misc... To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: ah360@yfn.ysu.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 767 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well, you have seen how many problems the original HP NetBSD has > with the floppies ? :-) (see rd.c) Didn't look at that code... > I still tend to support any manufacturer, but not the automagic way > you do it, a nice 'table' supplied as parameter to loadbsd could be > one alternative, the other is LKM... *hint hint :-)* It *has* to autoconfig, anything else is a BIIIG kludge and should be avoided at all costs. As an idea to distinguish an Extender from a GForce: how much Ram does the g-force announce in the configdev? 64k too? If it's not 64k, this could be a detection criterium. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 10 23:34:18 1993 Subject: 570 & a3000 sync scsi problems (still) To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 868 Sender: NetBSD-Admin@cbmuucp.commodore.com Ok, back from holidays (from Switzerland) and now a new try on the synchronous scsi (508 didn't work on my a3000 proto scsi & Quantum LP105S and PD425S). After the cursor patch to the sources and fetching the missing files from sun-lamp I got bootable kernel. But at boot time system didn't find root partition :-( Disks were recognised (the identification strings were print to console) and output claimed that disks were at that point synchronous. But apparently not, since no suitable root were found. I had to binpatch the _inhibit_sync for my drives and after that boot proceeded and all works fine. I'll enable the _scsi_debug (and what was the other) after this session and report what it dumps. It is a bit tough process, since at that point nothing is written to system logs (as there is no disk yet ;-) and you have to write down all that mess :-( ++Tero From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 08:28:41 1993 Subject: Re: 570 & a3000 sync scsi problems (still) To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1314 Sender: NetBSD-Admin@cbmuucp.commodore.com Ok, here it is: A3000, PROTO scsi chip, Archive Viper (id2, tape) Quantum LP105S (id4) Quantum PD425S (id6) ... Sending sync request to target 4 ... sent csr_result of last msgout: 0x1f ixfer_in fail: l2 i80 w49997 msgin finished with csr 0x4a scsi0: target 4 now synchronous, period=248ns, offset=8. ixfer_in fail: l7 i80 w49994 msgin finished with csr 0x41 Rejecting message 0xff sbic_wait TIMEO@1174 with asr=x0 csr=0x41 Sending sync request to target 6 ... sent csr_result of last msgout: 0x1f ixfer_in fail: l2 i80 w49989 msgin finished with csr 0x4a scsi0: target 4 now synchronous, period=208ns, offset=8. ixfer_in fail: l7 i80 w49994 msgin finished with csr 0x41 Rejecting message 0xff sbic_wait TIMEO@1174 with asr=x0 csr=0x41 ... no suitable root Some times I get: GOT CMD-COMPLETE! 6 acting weird ... waiting for disconnect... ok. Retrying selection. sd6: QUANTUM PD425S ... Looks like my system never gets to synchronous transfers, and when it proceeds over the sync (Retrying selection) it is set to async. Quite randomly one or both of my quantums get over the init and boot continues ok, and no problems after that. It is also happened that the other has set succesfully and the other has been left to unknown state (vmunix thinks that it is sync?) or both drives succeed (to async?). ++Tero From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 09:30:23 1993 To: mw@eunet.ch Cc: markus@TechFak.Uni-Bielefeld.DE, ah360@yfn.ysu.edu, netbsd-amiga@cbmuucp.commodore.com Subject: Re: binpatch help + misc... Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus I" == Markus Illenseer writes: Markus I> I still tend to support any manufacturer, but not the automagic way Markus I> you do it, a nice 'table' supplied as parameter to loadbsd could be Markus I> one alternative, the other is LKM... *hint hint :-)* >>>>> "Markus W" == Markus Wild writes: Markus W> It *has* to autoconfig, anything else is a BIIIG kludge and Markus W> should be avoided at all costs. As an idea to distinguish an Markus W> Extender from a GForce: how much Ram does the g-force announce Markus W> in the configdev? 64k too? If it's not 64k, this could be a Markus W> detection criterium. But it is... I can probably resolve this problem by looking at what gvpscsi.device does, and I will look at it tonight. However, it would be nice if all of you with any kind of GVP product could send me the ConfigDev info they present as complete as possible. If you have the GVPInfo program, use it's board menu selection and write down all the info you get and send to me. That way I can probably provide a hook function that synthesizes new Product IDs for GVP hardware and patch the AutoConfig info before NetBSD starts using it. Comments? Niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 09:57:17 1993 To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: 570 problems... Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: Me> serial driver, somehow messes modem up dialin ports. I suspect it Me> has something to do with the modem control interrupt simulation. Me> Now I can only once login on my NetBSD A2000 when calling home from Me> the office. The second time the serial port just hangs, that's why Me> I cannot provide the patch file I made for the above fixes in this Me> mail. Otherwise 570 works OK on a GVP combo equipped A2000 with 4MB Me> fastRAM. Markus W> Hmm.. what's happening exactly?? You do know about the two Markus W> "switch" tty's /dev/tty01 and /dev/tty02? Doing switches the tty into non-modem control mode, will have it open only on CD up. Perhaps this was the Markus W> problem? Yes, I know about them, but I don't think they are the problem. The dialin port worked reliably with the old serial driver. When I call my NetBSD system from the office, first time after a boot, I get a nice login probpt, and I'm able to login (although I get parenb set, which I don't know why, I have :np: in the default gettytab setting!). Everything is just great at this point, and the modem even hangs up when I do exit. If I call again, the getty doesn't seem to be running. Nothing happens, not even after BREAKs are sent. I have to reboot to get it working again! The modem answers though so the the DTR line should be set, indicating the line has been opened but I'm only 95% sure about this fact. A side note: my "ps" is behaving bad from time to time. Not as bad as in the early days, but still. Sometimes it hangs indefinitely and other times certain processes are not displayed. Of course my /vmunix is the booted version. Are there known problems in this area? Yet a bug I think I've never presented is that sometimes when I'm typing fast, NetBSD misses that a key has been released and repeats the last key until the next key is pressed. Has noone else seen this? While I'm on the line, I'm intending to write Amiga filesystems support (and in some way, probably using minor dev bit 6&7, non-BSD partition support in sd.c). If you have any pieces of good advice or other comments, please speak up NOW. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 11:49:15 1993 To: NetBSD-Amiga@cbmuucp.commodore.com X-Gateway: Endicor News-to-Mail Gateway Newsgroups: endicor.lists.netbsd-amiga Subject: Re: binpatch help + misc... Organization: Endicor Technologies, Inc., San Antonio, Texas Sender: NetBSD-Admin@cbmuucp.commodore.com In article <9308110710.AA10539@della.appli.se> niklas@appli.se (Niklas Hallqvist) writes: > I can probably resolve this problem by looking at what gvpscsi.device does, > and I will look at it tonight. However, it would be nice if all of you > with any kind of GVP product could send me the ConfigDev info they present > as complete as possible. If you have the GVPInfo program, use it's board > menu selection and write down all the info you get and send to me. That way > I can probably provide a hook function that synthesizes new Product IDs for > GVP hardware and patch the AutoConfig info before NetBSD starts using it. Here's the info for a GVP Series II '030 SCSI controller and the PhonePak, two boards that identify themselves as 2017/11: (much of this is irrelevent, of course, but I'm including everything) GVPInfo refers to board boards as "GVP DPRC", whateverthat means. Field SCSI PhonePak ------------------------------------------------------------------------ cd_BoardAddress $00E90000 $00EB0000 cd_BoardSize $00010000 $00010000 cd_SlotAddress 233 235 cd_SlotSize 1 1 cd_Driver $0028F414 $00000000 cd_Flags %00000000 %00000010 Board shut up? No No Board needs driver? No Yes Board has bad memory? No No er_Flags %00000000 %00000000 Put board into 8M space? No No Board can be shut up? Yes Yes er_Manufacturer 2017 2017 er_Product 11 11 er_SerialNumber $EEEEEEEE $EEEEEEEE DiagArea ROM $00E98000 $00EB8000 er_Reserved c-f $00280088 $00000000 er_Type %11010001 %11010001 BoardType %11 (Zorro II) %11 (Zorro II) Link into memory list No No Diag Vector valid Yes Yes Chained config request? No No MemorySize 64KB 64KB da_Config %00010000 \ BusWidth %00 nibblewide \ BootTime %01 config time \ da_Flags $00 }- not listed da_Size 910 bytes / da_DiagPoint $0028029C / da_BootPoint $00280302 / However, I bet there is a register on the board somewhere that distingusishes between the different product 11 products. ASDG does this with their Product 255 boards. -- Ty Sarna "A datagram can therefore be up to 4294967295 bytes in overall length. Particular networks will tsarna@endicor.com normally impose lower limits." -- RFC 1475, IP v7 From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 14:26:27 1993 To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, markus@techfak.uni-bielefeld.de, ah360@YFN.YSU.EDU, netbsd-amiga@cbmuucp.commodore.com Subject: Re: binpatch help + misc... <9308110710.AA10539@della.appli.se> X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Niklas, You asked for the GVPInfo data, and here it is. I guess you can choose how useful it is. Initially, I get three items to choose from, they are: GVP DPRC GVP Impact Series-II SCSI DMA GVP DPRC In this machine, I have a GVP Combo accelerator, which I think is the first item, perhaps. I also have a Series-II controller, the second item. The last is the I/O Extender. Manufacturer and product codes are identical for all three. I don't know what exactly it does, but er_Reserved c-f changes, and a host of new information (Diag area) appears when viewing the two SCSI controller boards (Combo & Impact). Of course, the addresses change, but that's not very useful. I'm using GVPInfo v1.22, there might be a newer one. ShowConfig shows: Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$ea0000 64K) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$eb0000 64K) which is pretty useless. )Russ From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 19:08:35 1993 Mmdf-Warning: Unable to confirm address in preceding line at ncrhub1.NCR.COM Subject: How do I unsubscribe? To: netbsd-amiga%cbmuucp.commodore.com@ncr-mpd.ftcollinsco.NCR.COM Organization: NCR Microelectronics, Ft. Collins, CO X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Sorry to send this out to the list, but I can't find my copy of original announcement of the mailing list which has subscription information. Basically, what I want to know is: how do I unsubscribe from this mailing list? -- /**************************************************************************/ /* Kent Dalton * EMail: Kent.Dalton@FtCollinsCO.NCR.COM */ /* NCR Microelectronics * Phone: (303) 223-5100 X-319 */ /* 2001 Danfield Ct. MS470A * FAX: (303) 226-9556 */ /* Fort Collins, Colorado 80525 * */ /**************************************************************************/ .. Once upon a time, four AMPHIBIOUS HOG CALLERS attacked a family of DEFENSELESS, SENSITIVE COIN COLLECTORS and brought DOWN their PROPERTY VALUES!! From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 20:33:23 1993 Subject: GVP SCSI kernel needed To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Could someone please compile a working GVP SCSI kernel and post it to wuarchive or somewhere like that. I have a GVP Series II controller and can't boot. I have extracted the source code into a partition and edited the AMIGA config file. I then did a config AMIGA, and then a make. Well, the make said something like MISSING SEPARATOR. I looked at the makefile and it seems like config didn't work. %OBJS, %LOAD, etc were not replaced by the proper symbols. I think my directory structure is not set up right so config can't find the right files. Could someone please describe the CURRENT way to compile under AMIGADOS. The RECOMPILE file in the source is not very helpful anymore. I would recompile on my moms 3000 under BSD, but then I have the problem of getting the compiled kernel over to the Amiga side to boot it! I could copy the file to my temporary raw device, but then how do I get it off of the partition. Is there a devtofile program?? Thanks. From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 21:01:19 1993 Subject: Re: GVP SCSI kernel needed To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com [...] > I would recompile on my moms 3000 under BSD, but then I have the problem of > getting the compiled kernel over to the Amiga side to boot it! > I could copy the file to my temporary raw device, but then how do > I get it off of the partition. Is there a devtofile program?? Yes! Go to your bffs11.lzh file and extract devtofile. To be on the safe side, I tar the vmunix onto the partition to guarantee that the file size will be a multiple of 512 bytes. Then, in AmigaDOS, devtofile, untar and I'm ready to go! -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 21:36:17 1993 To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com Subject: GVP SCSI kernel needed Sender: NetBSD-Admin@cbmuucp.commodore.com Is there a devtofile program?? ^^^^^^^^^ Yes. Same place you found the filetodev program, bffs11.lzh It works, just be sure the blocksize you specify is larger than the tar file on the raw device Robert W. Slawson Dept. of Astronomy, Univ. of Western Ontario, London, Ontario N6A 3K7 CANADA From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 22:05:45 1993 To: DCG9367@tntech.edu, ahh@netcom.com, bslawson@phobos.astro.uwo.ca Subject: Re: GVP SCSI kernel needed Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com Bob Slawson wrote: > Is there a devtofile program?? > ^^^^^^^^^ > > Yes. Same place you found the filetodev program, bffs11.lzh > > It works, just be sure the blocksize you specify > is larger than the tar file on the raw device ahh@netcom.com (Andy Heffernan) wrote: > > I would recompile on my moms 3000 under BSD, but then I have the problem of > > getting the compiled kernel over to the Amiga side to boot it! > > I could copy the file to my temporary raw device, but then how do > > I get it off of the partition. Is there a devtofile program?? > > Yes! Go to your bffs11.lzh file and extract devtofile. To be > on the safe side, I tar the vmunix onto the partition to guarantee that > the file size will be a multiple of 512 bytes. Then, in AmigaDOS, > devtofile, untar and I'm ready to go! Ok, for everyone who has heard this one before, sorry... Please check out dcp, which may be found at ftp.mtu.edu:/pub/cdh It is a replacement for filetodev and devtofile, but should be much easier to use (and hopefully a little safer) as it eliminates the calculations which were required for the former programs. For what it's worth, full source is included in the distribution. p.s. For those that may be excited by this (but please don't get too excited), I've been able to write files using bffs. The bad news is the filesystem won't yet check clean afterward, however, it will not be corrupt. (You can say I'm being a bit conservative on the summary information still) - Chris Hooper Programmer, MTU Networking (906) 487-2800=voice cdh@mtu.edu Michigan Technological University 2787=fax From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 11 22:12:15 1993 Subject: Re: GVP SCSI kernel needed To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 944 Sender: NetBSD-Admin@cbmuucp.commodore.com > Could someone please compile a working GVP SCSI kernel and post it to Chances are #580 will work on GVP, I just included Nik's changes. > a make. Well, the make said something like MISSING SEPARATOR. I looked > at the makefile and it seems like config didn't work. %OBJS, %LOAD, Looks like make didn't find a sed. > I would recompile on my moms 3000 under BSD, but then I have the problem of > getting the compiled kernel over to the Amiga side to boot it! > I could copy the file to my temporary raw device, but then how do > I get it off of the partition. Is there a devtofile program?? Use bffs, works real fine to read BSD files, that's how I boot BSD, btw. Oh, use 1.25, previous versions just crash (1.25 has still an enforcer hit, but otherwise works fine). -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 01:46:46 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Organization: Request BBS X-Charset: iso-8859-1 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: GvpInfo for 2091 and IO Extender Sender: NetBSD-Admin@cbmuucp.commodore.com In on Aug 11, Ty (Ty Sarna) wrote: > In article <9308110710.AA10539@della.appli.se> niklas@appli.se (Niklas Hallqvist) writes: > > Here's the info for a GVP Series II '030 SCSI controller and the > PhonePak, two boards that identify themselves as 2017/11: > (much of this is irrelevent, of course, but I'm including everything) > GVPInfo refers to board boards as "GVP DPRC", whateverthat means. > My config, from GvpInfo v1.39: Field SCSI(2091) IO Extender ---------------------------------------------------------------------------- cd_BoardAddress $00EA0000 $00E90000 cd_BoardSize $00010000 $00010000 cd_SlotAddress 234 233 cd_SlotSize 1 1 cd_Driver $00000000 $002437E8 cd_Flags %00000000 %00000000 Board shut up? No No Board needs driver? No No Board has bad memory? No No er_Flags %00000000 %00000000 Put board into 8M space? No No Board can be shut up? Yes Yes er_Manufacturer 514 2017 er_Product 3 11 er_SerialNumber $00000000 $EEEEEEEE DiagArea ROM $00EA2000 $00E98000 er_Reserved c-f $00200088 $00000000 er_Type %11010001 %11010001 BoardType %11 (Zorro II) %11 (Zorro II) Link into memory list No No Diag Vector valid Yes Yes Chained config request? No No MemorySize 64KB 64KB da_Config %10010000 \ BusWidth %10 worldwide \ BootTime %01 config time \ da_Flags $00 }- not listed da_Size 138 bytes / da_DiagPoint $002000C8 / da_BootPoint $00200096 / Well, there is my gvpinfo on my 2091 and I/O Extender. I'm using v1.39 of GvpInfo that came with my patches for 1.8 of the software. I've got 2 megs on the 2091 if that helps any... I hope this helps someone!...Thanks... -Erik -- Coming to you live and direct Erik_Karlin@erixami.linet.org Request BBS // - OR - (516) 471-4818 v32.bis \X/ root@erixami.linet.org Amiga/Adult And the rest is left as an exercise From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 02:25:22 1993 Subject: vmunix.580 works with GVP :-) To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga mailing list) X-Mailer: ELM [version 2.3 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com Now mtk has done it: NetBSD reached the prompt on my A2000 with GVP G-Force! Earlier today I tried vmunix.580 without success, but just minutes ago I decided to try once more before going to bed, and without my 16 bit RAM card it booted successfully. I thought it was another failure with just a different _cryo_debug :) blurb, but after hitting enter I wondered for a while why I didn't get that usual kernel stack dump but something else... eek, it was THE PROMPT! :-) Now after some beer and kippis, back to the usual whining :-) Somebody else mentioned that sometimes keyboard driver seems to left unnoticed the key-up message. On my old Cherry keyboard it's even worse, as I can't type anything without kbd driver thinking it should repeat the last key pressed for 30 seconds. If I try to type 'mount' it turns to 'moooooooooo' or 'mouuuuuuu' and hitting DEL takes usually the whole line away :-/ PS. no cursor whining, it works fine ;.) -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 03:59:16 1993 Subject: Re: 570 prblems... To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1291 Sender: NetBSD-Admin@cbmuucp.commodore.com > vmunix.570 does not work on my GVP although the interrupt handler is now > called. I will investigate this tomorrow if only I can get a full 570 > arcive. bsdsyssrc.570.tar.gz lacks at least these files: > > sys/netiso/iso_rrip.h > sys/isofs/isofs_rrip.[ch] > kern/tty_subr.c > > Maybe more files is missing too, I'll let you know tomorrow when my 570 > compilation is ready. Markus, can you supply a complementary tar > file with the missing files? Since sun-lamp seems to be temporarily off the air, where could we find the necessary missing files to compile #570? Also, Markus, what version of NetBSD are we based upon? 0.8, or the 0.9 Alpha? Where could we find the sources for the /bin, /sbin, /etc, /usr, etc files? Oh, BTW, I have achieved CVS-1.3, but to do so I needed to install GNU diff (for diff3) and rcs-5.6.0.1. If I get an overwhelming responce, I suppose I could upload the whole mess somewhere, but it may be simpler to compile and install it on your own systems your selves. Installation was very straight-forward, if a little time consuming. Eduardo ========================================================================= Eduardo Horvath eeh@btr.com ..!{decwrl,mips,fernwood}!btr!eeh "Trust me, I am cognizant of what I am doing." - Hammeroid From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 06:11:47 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: oh my god .... Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 6, 9:28am, Markus Wild wrote: > > It was as simple as frustating: After I loadwb and changed > > the screenmode to ntsc:hires-interlace, the 531 kernel booted > > into the beloved BSD :-))))) > > Although that's nice to hear, I don't want to let this go unnoticed: THIS > IS A BUG! Booting from an interlaced workbench is a hack to get around the > bug, it is no fix! So.. any demo-coders or other hardware-bangers, have > a look at grf_cc.c and tell me which register I forget to setup right? Since I was getting tired of having to switch to interlace mode every time I booted NetBSD (which meant exiting the CLI process to get the screen mode to change and having to startup another cli process), I looked at this problem a while tonight. I found something that seems to work for me; I've boot NetBSD three times in a row from a non-interlaced screen without any problems (related to the non-interlaced screen that is - I've got much bigger problems than that). The change I made was to set the custom.bplcon0 before the first copperlist is started in cc_init. I just set it to 0xa204: s = splhigh (); custom.bplcon0 = 0xa204; ^^^^^^^^^^^^^^^^^^^^^^^^^^ /* install dummy, to get display going (for vposr to count.. ) */ custom.cop1lc = (void *) ((unsigned long)fb->cop1 - (unsigned long) CHIPMEMADDR); custom.copjmp1 = 0; /* this is real simple: wait for LOF bit of vposr to go high - then start the copper list! :-) */ while (custom.vposr & 0x8000); while (!(custom.vposr & 0x8000)); My reasoning was that I had determined that it hung waiting for the LOF bit to go low. I though that maybe LOF was always high if the display was not interlaced, so I decided to set bplcon0 to set the interlace bit. I would have thought the copperlist would set it, but I suspect that the copper DMA is off at that point, so the copper won't be running. Anyway, it seems to work for me. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 08:04:16 1993 To: ayrjola@hila.hut.fi Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: vmunix.580 works with GVP :-) Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Ari" == Ari Yrj writes: Ari> Earlier today I tried vmunix.580 without success, but just Ari> minutes ago I decided to try once more before going to bed, and Ari> without my 16 bit RAM card it booted successfully. I thought it Ari> was another failure with just a different _cryo_debug :) blurb, Ari> but after hitting enter I wondered for a while why I didn't get Ari> that usual kernel stack dump but something else... eek, it was Ari> THE PROMPT! :-) Coincidentally, this 16bit-mem-problem thought popped up in my head yesterday, but I never got to think it through. Maybe the GVP can't DMA there, but need a dedicated DMA buffer and a copy. Michael, you did such support for KludgeMach, and I guess you are interested in doing it again :-) Niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 09:31:02 1993 Subject: Re: oh my god .... To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1094 Sender: NetBSD-Admin@cbmuucp.commodore.com > Since I was getting tired of having to switch to interlace mode every > time I booted NetBSD (which meant exiting the CLI process to get the screen > mode to change and having to startup another cli process), I looked at this > problem a while tonight. I found something that seems to work for me; I've > boot NetBSD three times in a row from a non-interlaced screen without any > problems (related to the non-interlaced screen that is - I've got much bigger > problems than that). > > The change I made was to set the custom.bplcon0 before the first copperlist > is started in cc_init. I just set it to 0xa204: Could you retry with #580 please? I moved start up of DMA to after the first dummy initialization of the copper, the problem was (thanks Hamish!) that the copper list was never executed before testing for short/long frame, so bplcon0 could never be changed before that test... It *should* work with 580.. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 16:05:18 1993 Subject: 580 doesn't boot on A3000T To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL0] Content-Type: text Content-Length: 427 Sender: NetBSD-Admin@cbmuucp.commodore.com The last kernel I tried was #450, which worked fine. I downloaded #580 and it hung after sync was set up (from memory): sbic_wait TIMEO @11?? ... csr=0x41 Anyway, I'd seen it on this list many times. So I did a binpatch: binpatch -l -s _inhibit_sync -r 1 vmunix.580 It still tried to go syncronous and hung. And I remember feeling smug when the A2000 users were SOL and I was running fine ;-). Sigh. - Kyle From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 17:00:28 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: vmunix.580 works with GVP :-) Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 12, 7:52am, Niklas Hallqvist wrote: > Coincidentally, this 16bit-mem-problem thought popped up in my head > yesterday, but I never got to think it through. Maybe the GVP can't > DMA there, but need a dedicated DMA buffer and a copy. Michael, you > did such support for KludgeMach, and I guess you are interested in doing > it again :-) When I get that far, I probably will: my bigger disk that has room for the BSD partitions is on my GVP controller and my other controller is the 53c710-based Zeus controller. If the GVP controller can DMA to 32 bit memory, I would think it should be able to DMA to 16 bit memory. My problem is the reverse: the GVP controller is a 16 bit card and can only DMA to 16 bit memory. I need the DMA buffer in 16 bit memory. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 17:13:52 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: oh my god .... Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 12, 9:25am, Markus Wild wrote: > Could you retry with #580 please? I moved start up of DMA to after the first > dummy initialization of the copper, the problem was (thanks Hamish!) that > the copper list was never executed before testing for short/long frame, so > bplcon0 could never be changed before that test... It *should* work with 580.. You're making changes too fast! I'm still working with #531. I've been trying to get the kernel to the point of printing on the screen and didn't want to have to keep adding all my 68040 hacks to all the updates. Since I can now get screen output, I guess it's time to get up to the current version. Whoops - I just looked on eunet and you only have the #580 kernel. That won't even be able to start on my machine - I'll have to wait until you upload the diffs or source. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 20:55:24 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: _cryo_debug output. Sender: NetBSD-Admin@cbmuucp.commodore.com Markus, Thanks for putting the extra debug stuff in, here are the results. ... bpf: lo0 attached net-init roundrobin schedcpu enablertclock mountroot trap: bad kernal access at4 trap type: 8 code = 4010105 v = d4 pid = 0, pc = 000011d8, ps = 2004, sfc = 0001, dfc = 0001 Registers ... Looks like a privilege violation :-( System: A2500/20 (020/851) - 2M 32bit @ 0x200000 A2091 (33c93) - 2M 16bit @ 0x400000 Nexus (5380) - 4M 16bit @ 0x600000 Kickstart 1.3 with mergemem executed to merge all hunks into 1 8M hunk. From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 21:09:09 1993 Subject: GVP, #580, and 32-bit ram To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com First off, am I the first A500 user for BSD!?!? I finally got BSD to work with kernel #580. I got everything installed and running. But, I had a couple of questions/problems: First my setup: A500, 1mb chip, 2.04 ROM. GVP Series II SCSI, 105MB hd, 8MB 16-bit ram. CSA Derringer 25mhz 030/882, 4MB 32-bit ram. Also a 312mb hd and an Irwin 5040 tape drive. First question/problem: When I booted with my tape drive turned on, the SCSI bus locked up and STOPPED BSD dead in its tracks! I tried with sync turned on and off with no difference. The tape drive is at SCSI ID 4. I haven't had any problems with it before. It seems as if it doesn't like being inquiried by BSD. My other software inquiries just fine. I'll look at it more tonight. Second question/problem: When I first played with BSD on my moms 3000, I was surprised by the speed. It kicked butt! Wehn I ran it on my 500, which usually beats a 3000 in AIBB, it was SLOW. The reason is simple. BSD is only using my 8MB 16-bit ram and not my 4-mb 32-bit ram. I changed the loadbsd source so that fastmem_start=0x08c00000 and fastmem_size=0x00400000. I then booted BSD. The kernel was started and WHAM! I was hit with a barage of DMAINTR should not longer be called! What's up? BTW, the ram is NOT autoconfig! Do I have to make a ConfigDev structure and link it into the system before loadbsd? I would gladly give up 4mb to get the speed increase. Even better would be to put the kernel into 32-bit ram and its data space, and put everything else into 16-bit ram. Is this gonna be impossible? Thanks. From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 21:11:47 1993 Subject: top v3.2 To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 236 Sender: NetBSD-Admin@cbmuucp.commodore.com If anyone hasn't yet got 'top' to his/her machine then try to Configure it to 386bsd and compile. You will be pleasantly surprised :-) I guess the newes top (3.2) just appeared in comp.sources.unix newsgroup (or was it .misc). ++Tero From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 22:03:59 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: GVP, #580, and 32-bit ram Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 12, 2:05pm, DCG9367@tntech.edu wrote: > Second question/problem: When I first played with BSD on my moms 3000, ... > I changed the loadbsd source so that fastmem_start=0x08c00000 and > fastmem_size=0x00400000. I then booted BSD. The kernel was started > and WHAM! I was hit with a barage of DMAINTR should not longer be called! > What's up? BTW, the ram is NOT autoconfig! Do I have to make a I think it may be due to the "dirty kludge" in autoconf.c - the routine is_a3000 checks to see if the fastram starts at or above 0x07000000. If it does, then it assumes that it's an A3000. [I caught this because my 32 bit memory on my Zeus card starts at 0x08000000.] > ConfigDev structure and link it into the system before loadbsd? > I would gladly give up 4mb to get the speed increase. Even better would be The loadbsd program only accepts one fast memory space and picks the largest fast memory segment, which is why your kernel runs in 16 bit memory. You could modify loadbsd to pick the fast memory segment that has the highest address, assuming that the 32 bit memory is above the 68000 address space. Since your memory is at 0x08c00000, you will need to fix the is_a3000() routine [I just fixed it to return a 0 when I'm compiling for the 68040]. > to put the kernel into 32-bit ram and its data space, and put everything > else into 16-bit ram. Is this gonna be impossible? I doubt it would be impossible. Loadbsd would need to changed to pass all memory segments to vmunix. This could be done in a similar fashion to the ConfigDev data. Then the amiga_init routine and pmap routines would have to be modified to allow multiple memory areas. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 22:43:54 1993 Subject: Re: GVP, #580, and 32-bit ram To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1873 Sender: NetBSD-Admin@cbmuucp.commodore.com > First off, am I the first A500 user for BSD!?!? Anybody confirm/deny this? > is simple. BSD is only using my 8MB 16-bit ram and not my 4-mb 32-bit ram. There will be support for different memory zones, ie. physical address space with "holes". > I changed the loadbsd source so that fastmem_start=0x08c00000 and > fastmem_size=0x00400000. I then booted BSD. The kernel was started HUH? Can your controller handle 32bit DMA? I'd be suprised, but.. Currently, no provision for DMA into not-reachable physical RAM is provided, might change in the future if there are enough users faced with the situation that are willing to take the challenge to implement it:-) Note: easy but very nasty "fix" is to force the scsi driver to do PIO for all requests. I wouldn't recommend this, but if it's the only chance for you to get BSD up at all, you might consider it. > What's up? BTW, the ram is NOT autoconfig! Do I have to make a > ConfigDev structure and link it into the system before loadbsd? The kernel completely relies on the ConfigDev structures known to ExpansionBase on startup, it doesn't do its own autoconfig, nor does it try to guess where not registered devices might live... Memory configuration is not done thru ConfigDev structures, but by walking the Exec memory list (loadbsd is in charge of that). > I would gladly give up 4mb to get the speed increase. Even better would be > to put the kernel into 32-bit ram and its data space, and put everything > else into 16-bit ram. Is this gonna be impossible? I don't think having such a high degree of configurability will be available within the near future, unless of course you come up with a cool implementation yourself:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 22:49:16 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: 580 doesn't boot on A3000T Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 12, 10:01am, K.X. Saunders wrote: > > The last kernel I tried was #450, which worked fine. I downloaded > #580 and it hung after sync was set up (from memory): > sbic_wait TIMEO @11?? ... csr=0x41 > > Anyway, I'd seen it on this list many times. So I did a binpatch: > binpatch -l -s _inhibit_sync -r 1 vmunix.580 ^^ > > It still tried to go syncronous and hung. > > And I remember feeling smug when the A2000 users were SOL and I was > running fine ;-). Sigh. Inhibit_sync is a byte array - if you patch the longword to 1, you will be inhibiting synchronous transfer on unit 3 (which is fine if that's what you wanted - but I suspect your device id is 0, in which case you either want to replace a byte or use a longword value of 0x01000000). Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 23:04:01 1993 Subject: Re: GVP, #580, and 32-bit ram (fwd) To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1224 Sender: NetBSD-Admin@cbmuucp.commodore.com Forwarded message: Date: Thu, 12 Aug 1993 15:53:25 -0500 (CDT) From: DCG9367%TNTECH.BITNET@CEARN.BITNET Subject: Re: GVP, #580, and 32-bit ram To: mw@chsun Message-Id: <01H1NW2NWJUQ9EDE24@tntech.edu> X-Envelope-To: mw@eunet.ch X-Vms-To: IN%"mw@eunet.ch" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT My GVP controller is 32-bit DMA capable (Im pretty sure about that. If I change the MASK on AmigaDOS parts to 0xffffff(the default) I get about 150-200 K/sec off my HD where a mask of 0xfffffff(includes the 32-bit ram) I get about 1.0-1.2MB/sec! A big improvement. I'll put an option into loadbsd to specify a different fastmem segment and fix the is_a3000() to not bomb out and see what happens! P.S: Could you post this to NetBSD-Amiga for me. Im using a stupid VAX/VMS mail program that doesn't prompt for CC and Im typing this from work over a 9600 internet line with response time of the US Congress! (Can't fix mistakes in 5 minutes) -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 12 23:39:07 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: GVP, #580, and 32-bit ram (fwd) Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 12, 11:00pm, Markus Wild wrote: > Forwarded message: > My GVP controller is 32-bit DMA capable (Im pretty sure about that. > If I change the MASK on AmigaDOS parts to 0xffffff(the default) I get about > 150-200 K/sec off my HD where a mask of 0xfffffff(includes the 32-bit ram) > I get about 1.0-1.2MB/sec! A big improvement. I think the GVP driver will use PIO to do transfers to 32 bit memory, so the 0xfffffffe mask will work. If you use a mask of 0x00ffffff, I think the filesystem will do all the transfers through a 512 byte buffer in chip ram. [I think I remember seeing that mentioned somewhere before, but it's been a while.] I've got a little program I run to check disk transfer speed and added the ability to specify the memory type (chip, 24-bit DMA, or any) and can see that if I use 24-bit DMA (16 bit) memory, the GVP driver doesn't use much CPU time. However, when I default to any memory, the program will use 32 bit memory and I can see that the GVP driver utilizes more CPU. > P.S: Could you post this to NetBSD-Amiga for me. Im using a stupid > VAX/VMS mail program that doesn't prompt for CC and Im typing > this from work over a 9600 internet line with response time > of the US Congress! (Can't fix mistakes in 5 minutes) Type SET CC_PROMPT at the MAIL> prompt, then VMS will prompt you for the CC. Isn't VMS MAIL fun? [That's one problem with a mailing list that uses the sender's address for the reply - you either have to remember to cc to the list or edit the To: header, which you can't do in VMS.] [Which I just forgot to do, so the message goes off to Markus - sorry about that. ARGHH!] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 05:21:18 1993 To: DCG9367@tntech.edu Subject: Re: GVP, #580, and 32-bit ram Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com DCG9367@tntech.edu said: >First off, am I the first A500 user for BSD!?!? First who has announced it. >I finally got BSD to work with kernel #580. I got everything installed >and running. But, I had a couple of questions/problems: >First my setup: >A500, 1mb chip, 2.04 ROM. >GVP Series II SCSI, 105MB hd, 8MB 16-bit ram. >CSA Derringer 25mhz 030/882, 4MB 32-bit ram. ^^^^ nice to know this works. >Also a 312mb hd and an Irwin 5040 tape drive. Hmm. >First question/problem: [deleted, nothing I can help with] >Second question/problem: [...] >BSD is only using my 8MB 16-bit ram and not my 4-mb 32-bit ram. >I changed the loadbsd source so that fastmem_start=0x08c00000 and >fastmem_size=0x00400000. This is handy to know.. perhaps some command line parameters are needed for systems that have this problem. >I then booted BSD. The kernel was started >and WHAM! I was hit with a barage of DMAINTR should not longer be called! >What's up? BTW, the ram is NOT autoconfig! Right, there's no way to make it autoconfig without A) having it ZorroII memory space, which would limit you to 8M, and/or B) having an EPROM on the board. >Do I have to make a >ConfigDev structure and link it into the system before loadbsd? No. What you are doing is fine... >I would gladly give up 4mb to get the speed increase. Even better would be >to put the kernel into 32-bit ram and its data space, and put everything >else into 16-bit ram. Is this gonna be impossible? I would suspect that Markus will eventually be able to support non-contiguious memory areas eventually, since it's just a memory mapping issue. What you are running into is the fact that the GVP can't DMA into 32bit memory areas. It's only able to DMA into normal 24bit Amiga addressing space. Since the Derringer memory is at 0x08000000 (the same address as on the 12 Gauge, the Magnum, and the 3000) AmigaDOS' filesystem will allocate a 1 block buffer in CHIP to DMA into, then use the CPU to copy it up to where it needs to be. Unfortunantly, BSD can't do that yet... once this is added, you will function normally. Hang in there! Bill From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 16:00:56 1993 Subject: Re: 570 prblems... To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL17] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 374 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Oh, BTW, I have achieved CVS-1.3, but to do so I needed to install GNU > diff (for diff3) and rcs-5.6.0.1. If I get an overwhelming responce, > I suppose I could upload the whole mess somewhere, but it may be I already uploaded diff and rcs to ftp.eunet.ch and it's available on mirrors too. And yes, I did it to later compile CVS so please upload it :). /Peter From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 17:01:27 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Same prob w/ binpatch & 580 Sender: NetBSD-Admin@cbmuucp.commodore.com I'm having the same prob as that other guy w/ an a3000T. That is, 580 doesn't boot w/o modifying. Again I binpatched the kernel. I made around a dozen different mods the it. (Incl: 1 drive off, both off all off, useing -b & -l) Nothing worked except for on which I turned off both drives. This booted fine. But after doing various amounts of disk activity it would lock up and drive stay on. That's the closest I go to booting. I agree with the other guy. I feel like a 2000 user in the early days! Here's the cmd I use to show I'm not messin' up: binpatch -b -a 0x72be4 -r 1 vmunix But I still get: 16488848 (0x1) vice 1(0x1) (the 16m # is made up) On another note... Anyone care to port the irc2.term program for me? I didn't have any luck. But I'm only a C weenie... - TC -- Techno Caster - ah360@yfn.ysu.edu From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 19:59:02 1993 Subject: Config problems To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I was trying to recompile the kernel under BSD to chuck the is_a3000(), but I ran into a problem. First, I didn't have a BSD executable of config, only the source code. Well, I found my source code and started to make it. I found out that GNU make won't handle the .include stuff and had to use /usr/bin/make. Everthong went fine until it hit lang.l. So now I had to find lex which wasn't included in BSD. Luckily I had downloaded the entire source for BSD4.3 and had the source laying around. I compiled lex, installed it, and proceeded to finish compiling config. COnfig finished and I installed it. Here's the kicker: I went to the /usr/src/sys/arch/amiga/conf dir, edited AMIGA to change CPU and IDENT, then did a config AMIGA. I got syntax errors on lines 45,46,47 which contains the lines like: master gvp11scsi0 at manufacturer 2017 product 11 Then I got a barage of lines saying that "a 3000 scsi 0 not defined" and also for gvp and a2091. Has anybody else gotten anything like this? What did I do wrong? Are there supposed to be a define when compiling config like -DAMIGA or something like that. I looked in the source and MACHINE_AMIGA is already defined in config.h which is included in lang.l. Maybe someone could put the BSDexe of config somewhere? If it's already there, I couldn't find it! Thanks. P.S.: Compiling config took about 10 minutes on my machine! If I can get this to work and compile the kernel( a few days) I just might be able to use my 32-bit ram! Also, does anyone know if instruction and data caches and bursts are turned on by default or is there a way to check/do it? I have a feeling that they are not. From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 20:49:07 1993 Subject: Re: Config problems To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 852 Sender: NetBSD-Admin@cbmuucp.commodore.com > Here's the kicker: I went to the /usr/src/sys/arch/amiga/conf dir, > edited AMIGA to change CPU and IDENT, then did a config AMIGA. > I got syntax errors on lines 45,46,47 which contains the lines > like: master gvp11scsi0 at manufacturer 2017 product 11 You *did* use newest sources for config? I distributed them I think with some of the bsdsyssrc archives. The trick is to tell config that it's ok to have digits within driver names, normally it doesn't like such names. > Also, does anyone know if instruction and data caches and bursts > are turned on by default or is there a way to check/do it? > I have a feeling that they are not. They should be... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 21:46:53 1993 Subject: Re: Config problems To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"mw@eunet.ch" X-Vms-Cc: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com My config problem is that I was using the source in the contrib/bsd/config.tgz file and NOT the source in bsdsyssrc500.tgz in usr.sbin/config. I diffed the source code and the one in the bsd500 allows WORD to have numbers where the one in contrib only allows letters. That's what I get for deleeing old archives! Thanks. From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 13 22:43:01 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: New user of BSD Sender: NetBSD-Admin@cbmuucp.commodore.com ----- Begin Included Message ----- To: NetBSD-Admin@cbmuucp.commodore.com Subject: New user of BSD Cc: donnie@verdix.com Hello there, I am in the process of perhaps installing Net-BSD on my Amiga. Here is my setup: a3000, 25Mhz, 10Meg RAM PhonePak 1.0 Commodore Memory Card 2 Meg RAM Quantum 105Meg SCSI ??? 1.2 Gig SCSI Archive Viper 60e SCSI Tape Drive Kickstart/AmigaDos 2.04 (booting from Harddisk not ROM. Do I need the ROM?) Questions: 1. Is there a local (in U.S.) site that has the latest Net-BSD? 2. Is there a utility that will allow me to read/write tar tapes under AmigaDOS? (I can ftp Net-BSD to a SUN -4 but I have no other way to get the info to my Amiga) 3. Is there a UNIX filesystem that works under AmigaDOS and vice versa? 4. I need to get the various UNIX-like tools to will allow me to compile/rebuilt the kernel if needed (Mach distrubution??) 5. Does Net-BSD has Motif or X-term support? 6. What did I miss?? Any input/help would be welcomed. Donnie Lewis ----- End Included Message ----- From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 14 04:09:00 1993 Subject: config? To: netbsd-amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 907 Sender: NetBSD-Admin@cbmuucp.commodore.com Could someone please upload the most recent config (NetBSD version) to ftp.eunet.ch? I am trying to compile under BSD for the first time, and I don't have the recent config sources... Just the old ones. They don't seem to be included in 580, and 500's source is not online anymore... I'll take either the source or a binary. I would just like to be able to config the source under BSD without all those "a 3000 is not defined" errors! Thanks -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 14 10:54:47 1993 Subject: no subject (file transmission) To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL5] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2799 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I am just wondering why I can never get a kernel compiled? Everytime I try I get the following: Any ideas? Thanks Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au Script started on Sat Aug 14 17:40:51 1993 bash# make gcc -c -O -mc68020 -m68881 -I. -I../../../../arch -I../../../.. -I../../../../sys -DGODZILLA -DA3000 -DGENERIC -DNKMEMCLUSTERS=256 -DKTRACE -DFPCOPROC -DDIAGNOSTIC -DDEBUG -DPANICWAIT -DHAVE_USL_UFS -DCOMPAT_NOMID -DTCP_COMPAT_42 -DCOMPAT_43 -DFDESC -DKERNFS -DMSDOSFS -DFIFO -DISOFS -DMFS -DNFSCLIENT -DNFSSERVER -DNFS -DINET -DKERNEL -Dmc68020 -Damiga -DREFBIT ../../../../arch/amiga/dev/a3000dma.c ../../../../arch/amiga/dev/a3000dma.c:72: warning: `NDMA' redefined ../../../../arch/amiga/dev/a3000dmareg.h:106: warning: this is the location of the previous definition ../../../../arch/amiga/dev/a3000dma.c:94: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:98: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:98: size of array `dmachan' has non-integer type ../../../../arch/amiga/dev/a3000dma.c:104: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:112: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:114: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:115: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:116: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:117: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c:118: `NA3000SCSI' undeclared here (not in a function) ../../../../arch/amiga/dev/a3000dma.c: In function `a3000dmainit': ../../../../arch/amiga/dev/a3000dma.c:146: `NA3000SCSI' undeclared (first use this function) ../../../../arch/amiga/dev/a3000dma.c:146: (Each undeclared identifier is reported only once ../../../../arch/amiga/dev/a3000dma.c:146: for each function it appears in.) ../../../../arch/amiga/dev/a3000dma.c: In function `dmareq': ../../../../arch/amiga/dev/a3000dma.c:177: `NA3000SCSI' undeclared (first use this function) ../../../../arch/amiga/dev/a3000dma.c: In function `dmafree': ../../../../arch/amiga/dev/a3000dma.c:211: `NA3000SCSI' undeclared (first use this function) ../../../../arch/amiga/dev/a3000dma.c: In function `a3000dmaintr': ../../../../arch/amiga/dev/a3000dma.c:358: `NA3000SCSI' undeclared (first use this function) ../../../../arch/amiga/dev/a3000dma.c: In function `a3000dmatimeout': ../../../../arch/amiga/dev/a3000dma.c:478: `NA3000SCSI' undeclared (first use this function) *** Error code 1 Stop. bash# exit exit Script done on Sat Aug 14 17:41:22 1993 From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 14 22:41:52 1993 Subject: Latest Config Sources Posted To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, To all of you who need them, I put the latest config sources from the bsdsyssrc500.tgz file on wuarchive.wustl.edu in the incoming dir, I think this is the path: /systems/amiga/boing/NetBSD/incoming The file is called config_new_src_good.tgz. The other file was a messed up ASCII transfer that I aborted and can't delete. BTW, the bsdsyssrc500.tgz file is on nic.funet.fi in their NetBSD dir. I think they keep everything. David. From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 05:00:44 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 1.19) Organization: Request BBS X-Charset: iso-8859-1 To: netbsd-amiga@cbmuucp.commodore.com Subject: Any progress with GVP IO and 2091 Sender: NetBSD-Admin@cbmuucp.commodore.com I just downloaded vmunix.613, hoping that perhaps the gvp board identification problem might have been fixed, but bsd is still seeing my gvp io extender as the controller and not seeing my 2091...and this one now locks the mouse cursor, whereas v580 didn't. Any progress yet....and while I'm at it...what exactly do I need to compile my own stuff? Like the kernel for starters, then, if I ever get it to run, what and where is the bsd compiler? I've got SAS/C, but I don't think that'll do it. BTW - I've got an A2000/2630 + GVP I/O Extender + 2091 Thanks -Erik -- Coming to you live and direct Erik_Karlin@erixami.linet.org Request BBS // - OR - (516) 471-4818 v32.bis \X/ root@erixami.linet.org Amiga/Adult And the rest is left as an exercise From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 05:23:32 1993 Subject: Problem with pow.o in libm.a To: netbsd-amiga@cbmuucp.commodore.com Cc: hwdobso@afterlife.ncsc.mil (Howard Dobson) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 916 Sender: NetBSD-Admin@cbmuucp.commodore.com There seems to be a problem with libm.a (or at least pow.o in libm.a) Test program (testpow.c): double pow(); main() { double a,b,c; b=1.23456; c=2.0; a = pow(b,c); } cc testpow.c -lm pow.o: Undefined symbol _log__D referenced from text segment pow.o: Undefined symbol _exp__D referenced from text segment Any ideas? This is the only obstacle to getting perl-4.036 working (compiles as distributed except for this problem). Right now I have just commented out the calls to pow in the source. A few other FYI's while I am writing (on other things I have ported) zsh-2.3.1 - The Z shell ksh like with some csh stuff compiles right out of the box. pcomm-2.0.2 - MSDOS Pro-comm cloan for unix, features phone # directory/autodaialer, scripting, etc. available from comp.sources.unix archives volume26 apply patch found on 386BSD sites, and modify config.h/Makefile to suit NetBSD-Amiga Howard Dobson From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 11:56:06 1993 Subject: Re: Problem with pow.o in libm.a To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: netbsd-amiga@cbmuucp.commodore.com, hwdobso@afterlife.ncsc.mil X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 551 Sender: NetBSD-Admin@cbmuucp.commodore.com > > There seems to be a problem with libm.a (or at least pow.o in libm.a) > > Test program (testpow.c): > > double pow(); > main() > { > double a,b,c; > b=1.23456; > c=2.0; > a = pow(b,c); > } > > cc testpow.c -lm > pow.o: Undefined symbol _log__D referenced from text segment > pow.o: Undefined symbol _exp__D referenced from text segment Sheesh.. include please... -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 20:48:16 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: gdb and netbsd-current Sender: NetBSD-Admin@cbmuucp.commodore.com I found this thread while following the 386bsd news group: comp.os.386bsd.apps I am not aware of who is working on gdb for netBSD-Amiga so: News Thread 1: In article , sef@kithrup.com (Sean Eric Fagan) writes: > In article jdolter@eecs.umich.edu (James W. Dolter) writes: > >I have started playing with it but other deadlines keep interfering. > > I've done an initial port of gdb to the current netbsd. It seems to work. > I've asked other people to take a look at it, to clean it up and whatnot. > (In particular, I'd *really* like to get the people doing non-x86 ports of > NetBSD to play with it :).) > > Anyway, assuming it all works, the changes will be folded into the mainstream > BFD tree, and all of the binutils should "just work." > News Thread 2: In article , jdolter@eecs.umich.edu (James W. Dolter) writes: > >>>>> Regarding Re: recent version (4.x) of gdb; mckim@dinah.lerc.nasa.gov (Jim McKim) adds: > mckim> NNTP-Posting-Host: dinah.lerc.nasa.gov > > > mckim> I'm using NetBSD-current. I didn't see the problem with NetBSD 0.8 or > mckim> 386BSD so I'm assuming the problem has something to do with the a.out > mckim> changes. None of the GNU binutils work either - the problem is in how > mckim> the libbfd routines read in a.out files. GNU probably needs to > mckim> recognize NetBSD (0.9+) as a unique configuration type in its > mckim> configure scripts. > mckim> -- > mckim> Mci aigh vojs > mckim> Jim McKim / Internet: mckim@lerc.nasa.gov gcashvwbu pshhsf hc > mckim> Phone: +1 216 891 2283 / Packet: kb8dcr@kb8dcr.ampr.org rc hvob rsqfmdhwbu > mckim> fchhsr gwubohifsg.. > > > Not only does the configuration scripts need to identify NetBSD-0.9 but a > new variant on the a.out format is needed to properly read the a_midmag > field into the generic bfd internal format and write it out when the bfd > file is closed. This centers around defining SET_MACH_ARCH macro/routine > appropriately and providing a couple of other support routines. > > A good start at figuring this out is looking at how the HP a.out format > differs from the standard 32 bit a.out or the SUNOS a.out formats. > Hope I haven't insulted anyone by repeating this info here. ______________________________________________________________________________________ Robert Leland | Views expressed are my own.| _ _ _ PSI - W302 | OO-What a beautiful mornin'| \_!_/ PSI 7525 Colshire Drive| (703)883-7129 (Voice) USA | | in support of McLean, VA 22102 | (703)883-6308 (Fax) USA | _|_ MITRE From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 22:48:41 1993 Subject: #613 To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1238 Sender: NetBSD-Admin@cbmuucp.commodore.com Uploaded #613 bin/src, features: - improved (even more:-)) serial driver, should no longer disturb the keybord (note: if you have other interrupt sources that block #1 ints for too long, repeating keys might still be a problem) - some more debugging variables.. : _cryo_debug: print what's going on on startup, usually crashes after printing mount-root on systems that suffer the bug _scsi_no_dma: disable DMA. Try this if DMA could be the source of your problem. _dma3000debug _dma2091debug _dmagvp11debug: enable DMA-debugging. Set to 255 if you want to see everything there. - slightly changed ppp driver, nothing important here - NOTE: local change which may influence your system: SCSI-U4 is now defaulted to inhibit-sync. My wantek streamer hung the system far too many times... You may want to binpatch this out to suit your needs. Just heard there might be compilation problems, tty.h and tty_conf.c both declaring ppp-functions. If so, remove the declarations in tty_conf.c. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 15 23:15:42 1993 Subject: #613, forgot about.. To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 274 Sender: NetBSD-Admin@cbmuucp.commodore.com I fixed the isofs, so CDs with and without Rockridge Extensions should now mount correctly. Have fun:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 09:05:59 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Easier problem? X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com Hi all! Let me start by saying that I'm now running NetBSD-Amiga on my A2000 with GVP Combo accelerator, and I'm very very happy to be my own sys-admin. It's amazing how liberal I am, I don't even apply disk-quotas! ;) Add the following system to the "working" list: A2000 w/ GVP 50 MHz Combo accelerator, 8MB 32-bit RAM I have additional GVP products (Series II HD controller, and IO Extender) and it doesn't get confused by them, however, they configure later than the controller on the accelerator, so that could help. That is the good news. Now for my difficulty. I would like to use the vt101 hooked up to my serial port as an additional terminal. It is a vt101 (Yes, DEC equipment, age yellowed plastic, the works) and it is attached to the serial port, with a null-modem. In /etc/ttys, I uncommented the line: #tty00 "/usr/libexec/getty std.9600" unknown on secure and modified it to read: tty00 "/usr/libexec/getty std.19200" vt100 on secure I get the normal banner or whatever it's called, and a login: prompt, and I can enter an account name, but I never get a password: prompt. Characters continue to echo back to the terminal, but from that point on, the terminal does nothing useful. I tried killing the getty process, hoping that when it respawned, I'd see another login:, but it didn't happen. I also tried echoing things to /dev/tty00, and it hung there until I interrupted it. A) The terminal DOES work, despite being 12 yrs old. ;) B) I did try 9600 also. I'd prefer it to be 19200, since that's what I use it at under AmigaDOS, and that's what I saved on the vt101 settings. Regardless, if I could get it to work, I'd switch. C) Sorry if this is a sys-admin question, not a NetBSD question, I tried asking in #unix on irc, no help. D) vmunix.580 and vmunix.613, same thing. )Russ From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 09:25:12 1993 Subject: Re: Easier problem? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > I get the normal banner or whatever it's called, and a login: prompt, and I can > enter an account name, but I never get a password: prompt. Same here. Or at least similar. I got a first login: prompt, and I think, a password: too, but then the tty was dead. mjl From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 11:36:09 1993 To: amigaman@esu.edu Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Easier problem? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Russ" == Russ Miranda <- Amiga Specialist" > writes: Russ> I get the normal banner or whatever it's called, and a login: Russ> prompt, and I can enter an account name, but I never get a Russ> password: prompt. Characters continue to echo back to the Russ> terminal, but from that point on, the terminal does nothing Russ> useful. I tried killing the getty process, hoping that when it Russ> respawned, I'd see another login:, but it didn't happen. I also Russ> tried echoing things to /dev/tty00, and it hung there until I Russ> interrupted it. I found out yesterday that this problem is solved (until the next reboot) if you can get a serparam call through to the serial driver. What I do at this point is to issue the following commands (as root of course): tty00 "/usr/libexec/getty std.19200" vt100 on secure > > I get the normal banner or whatever it's called, and a login: prompt, and I can > enter an account name, but I never get a password: prompt. Characters continue If it's a parity problem, try adding "np" to the std.19200 line in /etc/gettytab. If its modem-control problem, my vt100 won't exhibit the problem, as I already hard-soldered 8 to forced1 since amix wouldn't open the port otherwise... If you're building your own kernel, you can try specifying a "flags" variable in your config file for ser0, this one specifies whether modem-control should be on my default or not. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 20:04:35 1993 Subject: config problems again... To: netbsd-amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 775 Sender: NetBSD-Admin@cbmuucp.commodore.com I am having problems compiling config under NetBSD. It keeps complaining about not finding "y.tabs.h"... Could someone tell me where to get this file? Or even better upload the binary for config... (This is Driving me nuts... I want to start work on slip, but I can't even get the damn thing to compile! ;) Thanks. -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 20:21:02 1993 Subject: My 32-bit ram works! To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, A few days ago, I had a problem that I could not use my 32-bit ram with BSD for several reasons: 1) loadbsd would only pick the first segment of ram, the 8mb 16-bit 2) my GVP11 controller could not do 32-bit DMA ( I realized this when I thought about the controller being plugged into my A500 external bus which only has 24-bit addr lines! :) ) 3) my 32-bit ram at 0x08c00000 made BSD think I was a 3000 because of the is_a3000() routine, which would result in a crash. Well, I am very happy to report that all is fine and dandy now. I changed the loadbsd prog to set fastmem_start=0x8c00000 and fastmem_size=0x400000 after the getmem() routine. Prob#1 solved. Thanks to Markus for putting in the _scsi_no_dma switch. I had to use this to prevent my GVP from DMA'ing into the 32-bit ram, which would result in a black screen and a crash. Prob#2 solved. To fix the is_a3000() thing, I did not have to recompile the kernel, that would have taken 3 hours in my 16-bit ram ( I already did this). I simply did this: binpatch -s _is_a3000 vmunix.613 (finds the address of the function) used resource to look at vmunix and the code for is_a3000() binpatch -b -a 0x548c8 -r 0x42 vmunix.613 That last line changes a line in the assembly from NEG.L D0 to CLR.L D0 Basically changing is_a3000() to return 0 always. Sorry about the jabber, i just thought someone else might have a similar problem. Please add this setup to the working list! A500, GVP11 Impact HD+ 105/8MB, CSA Derringer 030/882 4MB Next is to get my tape drive working! (Irwin 5040, anyone else got one?) From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 16 20:26:38 1993 Subject: Re: config problems again... To: signals@krypton.mankato.msus.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"signals@krypton.mankato.msus.edu" X-Vms-Cc: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com You should need to get that file. I think it is created by yacc when it is parsing one of the .y files. Are you using /usr/bin/make? Do you have yacc? You should if you installed everything. I compiled it fine. If you still have rpoblems, the soonest I can get a binary to you is tomorrow :( From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 17 01:08:11 1993 To: mw@eunet.ch Cc: amigaman@esu.edu, netbsd-amiga@cbmuucp.commodore.com Subject: Re: Easier problem? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: Markus W> If it's a parity problem, try adding "np" to the std.19200 Markus W> line in /etc/gettytab. If its modem-control problem, my Markus W> vt100 won't exhibit the problem, as I already hard-soldered Markus W> 8 to forced1 since amix wouldn't open the port otherwise... Markus W> If you're building your own kernel, you can try specifying a Markus W> "flags" variable in your config file for ser0, this one Markus W> specifies whether modem-control should be on my default or Markus W> not. I now run with the following lines in rc.local (kludgey, but does the work): > You should need to get that file. I think it is created by yacc when > it is parsing one of the .y files. Are you using /usr/bin/make? Do you have yacc? You should if you installed everything. I compiled it fine. If you > still have rpoblems, the soonest I can get a binary to you is tomorrow :( > Thanks, I may not have yacc... I will look for it of*n my system... (I only have a 100 meg Hard Disk (for now) so I don't have MUCH room left with the source for the kernel and all the .tgz files from ftp.eunet.ch.) BTW, for anyone who cares... I downloaded pcomm 2.0.1 from ftp.luth.se in the 386BSD directory, and it compiled clean without modifications. I like it when that happens! (Now if I could only get config to compile, so I could get the source to compile...) -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 17 20:38:01 1993 Subject: Windowing system to NetBSD, MGR? To: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 568 Sender: NetBSD-Admin@cbmuucp.commodore.com In the mean time that X11 will be ported, has anyone looked into MGR? I remembered that from early days of Linux, when that (MGR) was a prelim GUI before X11 was ported. The sources were still at ftp.funet.fi:/pub/OS/Linux/util/graphics/MGR There appears to be Linux and SunOS ports of that software, but without debugger the task to compile a workable binary to NetBSD could be too big :-( In the MGR directory seems to be a screen shot of that windowing system (screen.gif) if I guess right... I don't have possibilities to check it now (running NetBSD). ++Tero From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 17 22:33:32 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Problem with pow.o in libm.a Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 14, 11:16pm, Howard Dobson wrote: > pow.o: Undefined symbol _log__D referenced from text segment > pow.o: Undefined symbol _exp__D referenced from text segment I had the same problem with the games-archive (arithmetik). Can't remember exactly how i solved the problem, but i remember that we had a fixed libm anyway, no ? -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 17 23:06:18 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Easier problem? Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 16, 3:02am, "Russ Miranda - Amiga Specialist" wrote: > A2000 w/ GVP 50 MHz Combo accelerator, 8MB 32-bit RAM Congrats to the fastest Amiga-NetBSD-machine so far :-) >I get the normal banner or whatever it's called, and a login: prompt, and I can >enter an account name, but I never get a password: prompt. Characters continue >to echo back to the terminal, but from that point on, the terminal does >nothing useful. I tried killing the getty process, hoping that when it respawned, >I'd see another login:, but it didn't happen. I also tried echoing things to >/dev/tty00, and it hung there until I interrupted it. Same here, but i can't even type the password, the tty hangs. As 'ps' does not work (#580), i can't kill or HUP getty. > A) The terminal DOES work, despite being 12 yrs old. ;) My Wyse-Terminal is not that old (3 yrs), but does work fine under ADos with AUX-Shell. I _know_ that mtk had done his very first work on a console, so it did work once in a netbsd-time. I have no clue what actually happens here, and where to look. Is it the serial-device ? (Can't be, several dudes doing PPP already and working with Term). Is it the getty ? Some config missing ? Does it need 7Wire ? -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 18 17:53:47 1993 To: NetBSD-Admin@Cbmuucp.commodore.com Cc: hwdobso@afterlife.ncsc.mil, netbsd-amiga@cbmuucp.commodore.com, hwdobso@afterlife.ncsc.mil Subject: Re: Problem with pow.o in libm.a Sender: NetBSD-Admin@cbmuucp.commodore.com > > > > There seems to be a problem with libm.a (or at least pow.o in libm.a) Seems to be libm.a ... > > > > cc testpow.c -lm > > pow.o: Undefined symbol _log__D referenced from text segment > > pow.o: Undefined symbol _exp__D referenced from text segment > > Sheesh.. include please... I don't think this helps as perl includes math.h and bombs nevertheless. I've got another workaround instead of modifying the perl-source: # cd /usr/lib # cat >explog.c #include double exp__D(double d){ return exp(d); } double log__D(double d){ return log(d); } ^D # gcc -c explog.c # ar vr libm.a explog.o # ranlib libm.a # rm explog.* For me this workes fine... From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 18 23:07:09 1993 To: hubert.feyrer@rrzc1.rz.uni-regensburg.de, mw@eunet.ch Subject: Re: Problem with pow.o in libm.a Cc: netbsd-amiga@Cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Sheesh.. include please... > > > > I don't think this helps as perl includes math.h and bombs > > nevertheless. I've got another workaround instead of modifying the > > perl-source: > > It bombs because it does *not* include math.h, at least not in expr.c > and consarg.c, which both use extensively stuff out of -lm. > Programs using math library functions HAVE to include math.h, since > only then can gcc know whether functions like sin() are save to be > subject to common subexpression elimination (because sin() is declared > as const), or even better, to use fpu inline-functions to avoid function > cals alltogether. Markus is correct, I simply added #include in consarg.c and expr.c and now have perl running. math.h includes math-68881.h which has inline fpu function definitions for many (if not all) of the libm functions. So including math.h effectively eliminates the function calls to libm, and so the pow in libm is never called. Do you think we should send larry wall (the author of Perl) a patch so that future versions of perl will not have this problem? If so, what is the best #ifdef to use to indicate an amiga running netbsd? (I have not had a chance to investigate what gcc defines for you. #ifdef amiga is probably not sufficient since there are amigados ports of perl) Later Howard From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 06:49:57 1993 Subject: Autoboot, anyone? To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 9245 Sender: NetBSD-Admin@cbmuucp.commodore.com Here is a little patch I put together to enable proper autobooting of the kernel from loadbsd. Simply replace your old loadbsd with the new, improved model provided (fully backward compatible), apply the autoboot patch to bsdsyssrc.613, recompile, and voila, you have autobooting. Now for the technical stuff. The boot parameter is passed to the kernel in d7 (the way the HP seems to have done it.) The new loadbsd will default to single user booting. If you specify the -a flag (ala DECstations), loadbsd will tell the kernel to autoboot. Older kernels simply ignore this parameter. new loadbsd usage: loadbsd some-vmunix [-a] [-k] Here's the patch: ======================================================================== diff -c sys/arch/amiga/amiga/amiga_init.c:1.1 sys/arch/amiga/amiga/amiga_init.c:1.2 *** sys/arch/amiga/amiga/amiga_init.c:1.1 Tue Aug 17 20:23:29 1993 --- sys/arch/amiga/amiga/amiga_init.c Tue Aug 17 20:23:29 1993 *************** *** 136,146 **** --- 136,148 ---- ConfigDev = (struct ConfigDev *) ((int)end + 4); end_loaded = (u_int)end + 4 + num_ConfigDev * sizeof(struct ConfigDev); + #if 0 /* XXX */ { extern int boothowto; boothowto = RB_SINGLE; } + #endif /* printf ("numCD=%d, end=0x%x, end_loaded=0x%x\n", num_ConfigDev, end, end_loaded);*/ diff -c sys/arch/amiga/amiga/locore.s:1.1 sys/arch/amiga/amiga/locore.s:1.2 *** sys/arch/amiga/amiga/locore.s:1.1 Tue Aug 17 20:23:52 1993 --- sys/arch/amiga/amiga/locore.s Tue Aug 17 20:23:53 1993 *************** *** 790,797 **** movw #PSL_LOWIPL,sr | lower SPL ! /* movl d7,_boothowto | save reboot flags movl d6,_bootdev | and boot device */ jbsr _main | call main() --- 790,798 ---- movw #PSL_LOWIPL,sr | lower SPL ! movl d7,_boothowto | save reboot flags + /* movl d6,_bootdev | and boot device */ jbsr _main | call main() *************** *** 2197,2202 **** --- 2198,2204 ---- movc d0,cacr | disable on-chip cache(s) movw #0x2700,sr | cut off any interrupts + movel _boothowto,d7 | save boothowto movel sp@(16),a0 | load memory parameters movel sp@(20),d0 diff -c sys/arch/amiga/stand/loadbsd/loadbsd.c:1.1 sys/arch/amiga/stand/loadbsd/loadbsd.c:1.2 *** sys/arch/amiga/stand/loadbsd/loadbsd.c:1.1 Tue Aug 17 20:26:05 1993 --- sys/arch/amiga/stand/loadbsd/loadbsd.c Tue Aug 17 20:26:05 1993 *************** *** 11,16 **** --- 11,19 ---- #include #include + /* Get definitions for boothowto */ + #include "reboot.h" + struct ExpansionBase *ExpansionBase; #undef __LDPGSZ *************** *** 23,28 **** --- 26,32 ---- { struct exec e; int fd; + int boothowto = RB_SINGLE; if (argc >= 2) { *************** *** 58,69 **** get_mem_config (&fastmem_start, &fastmem_size, &chipmem_size); ! if (argc == 3 && !strcmp (argv[2], "-k")) { fastmem_start += 4*1024*1024; fastmem_size -= 4*1024*1024; } printf ("Using %dM FASTMEM at 0x%x, %dM CHIPMEM\n", fastmem_size>>20, fastmem_start, chipmem_size>>20); /* give them a chance to read the information... */ --- 62,81 ---- get_mem_config (&fastmem_start, &fastmem_size, &chipmem_size); ! if (argc >= 3 && (!strcmp (argv[2], "-k") ! || !strcmp (argv[3], "-k")) ) { fastmem_start += 4*1024*1024; fastmem_size -= 4*1024*1024; } + if (argc >= 3 && (!strcmp (argv[2], "-a") + || !strcmp (argv[3], "-a")) ) + { + printf("Autobooting..."); + boothowto = RB_AUTOBOOT; + } + printf ("Using %dM FASTMEM at 0x%x, %dM CHIPMEM\n", fastmem_size>>20, fastmem_start, chipmem_size>>20); /* give them a chance to read the information... */ *************** *** 79,85 **** startit (kernel, text_size + e.a_data + e.a_bss + num_cd*sizeof(*cd) + 4, e.a_entry, fastmem_start, ! fastmem_size, chipmem_size); } else fprintf (stderr, "Executable corrupt!\n"); --- 91,98 ---- startit (kernel, text_size + e.a_data + e.a_bss + num_cd*sizeof(*cd) + 4, e.a_entry, fastmem_start, ! fastmem_size, chipmem_size, ! boothowto ); } else fprintf (stderr, "Executable corrupt!\n"); *************** *** 100,106 **** perror ("open"); } else ! fprintf (stderr, "%0 some-vmunix\n", argv[0]); } --- 113,119 ---- perror ("open"); } else ! fprintf (stderr, "%s some-vmunix [-a] [-k]\n", argv[0]); } *************** *** 177,182 **** --- 190,196 ---- | a0: fastmem-start | d0: fastmem-size | d1: chipmem-size + | d7: boothowto movel a3@(4),a1 | loaded kernel movel a3@(8),d2 | length of loaded kernel *************** *** 184,189 **** --- 198,204 ---- movel a3@(16),a0 | fastmem-start movel a3@(20),d0 | fastmem-size movel a3@(24),d1 | chipmem-size + movel a3@(28),d7 | boothowto subl a4,a4 | target, load to 0 lea pc@(zero-.+2),a3 ===================================== Here's an AmigaDOS gzipped uuencoded loadbsd. ===================================== begin 644 loadbsd.gz M'XL( /-!03\" X58?VP3UQW_GAW,Y;!:KUC(?UCT:@RX31QG*:MHA;K$!&K< MU,X(3!EK=W'LL^-A^]SS.20=ZA(V]8\*=5FT56RJIJE#JU81%DVH2B6$LJG: MHHI-695.;*I*%%$5.FBM#G49VN"$6$B"/Q)I%T^OTZ>8/W)ZKY,;58+704\L-Z2A^G MO5K)R)>J*MU.EX^E]%*^E'M,+JEJ1LW(NCJ:K^2UDMSU:+NUNL=WWWSV MUL !/MH0]<1[/II1?E*.0F&(7W3G)]W>B]4/;V7>YM251C'^ZF$#*Z QE% M=GU<(]ML?&+$^DV6U_8-RPVAEI811G %:'^BZ3/U%-5-6Q MHIVIHPYJ&;9#KZ.B@PQ5TY.V9I^3]/0.'GMKW%,MHY]CV ML79.W!L[T ^B1/O&U'352 T75#FMZ7JU;#P@4;)JL&07U:*FCS\@A[9G'I3H M<*E2+9>Q0; [U#6IQ^3MFD1[4Z6=;".E,O((&E5GXMLK$FEEM43;*W)%*ZKA MT6*UE!^3OQU./8/FZ#,2/I7#YCEK;[=.&XZVJ'G)$,[-D%@@YYGH:W*1W(.Q MB(?'9:D_&:"V'O.]^&21G,\C7G+/#7,Y(D;"YGN<8Q5Q*Z"YR_P_UQ$1#O'V_,1,46.5WD4'#R*<>YYEL6QWX[C)@_V M]$1.MF8"F.FYAF^D:2[K'<*4:X:ZBR2C5,NSL8!QA,BW]1O MR,NTS$ZE.]DOHP?9_(/DFWX=^[TBRV^+)6SCK/S97]M=W4N H[IXV$H-'R2T?1170 M1MY &_DZVLC_LXM/W*+':YN[";]=M1<= MHW?HD .XFP7WJ/G&9-:O$S^//;G[V-TO> Y.RL('$_%9D;(W@T+.NX]1W;(# M^U\7*3$U<"+[:=^-EN:5),[CBT_G1/E(8BH^G>754ZN7[\*18-/J;"UJR4IE M@=T%U)*ZP&;R):.:-YKOU??KYA+BUM6H;5K/E(GY&:)L2]D<,J(1:K__.&(< MYFU']+>T"]ACM"_]Z(E/R"=' T^6O9"8^OIQU(5^M$[:BO9>ZD2[@;HB&L5H M-]H^"K;W_G@A$/WIVV72*;@'OG2/QE!3G+9JJT"O5:OT7>[SXXMJ3U3Y]Q+J MN6JN)!;7^F\W]<\T]7_9Z"_6S8/K_7]_M-Y?/=74GU[O?WZIJ?]*4_](4S_1 MI//%)OK6]7[]L::^)[&(L^(ZHO\UNPQ&;4Q[K-J9:BR3P$/ "# *G 1^!\P! M%[#1NH!>Z "/,PX4@!>!TTBH&V@'^H$? M/ +X"SP-^ *P#6V,#*3 ^PA96; M0 SX)J #[Z.P[ >![X+/ >\!$"/"W:X4*.YX(/K'\ R 'TH\ZEU G@!N&B_ M!? %"L>!$[ 7]8X#]7_K*>!5S'58[P9Z!,#Z] 6K#*TW@C ,E(%7P (;';#1 M@3>$(P"$X.?+ .9Z6/@%FY?^+7I/OOY4V,^ MLG*0?4F,H+"!@G>%/MYXYSB4?8E#![_%!58X3\5(Z0;:3%YCU3KC*::U:LG@ M3ZF#G*>HE=)XUNA:H4%S*,54OF2M&V#K*3G54%"E*F#,YG%3T,8MG(_KST.; MR.QTVLM5RRI2B^.9V5S2##;/U#E*U4)!+S.]XO-L[CE5AUWB";[&_GPILY?K M[U5'.<\+?(W]FCZ>LTMTE1=/79JEJ!]Y4L MIK7&ACK&UY=&^'@XK95Y6B3#&EN>LJJ)C],%K:+R\4D^SI9UG(M9=H_S=?-C M=Z17.MV@LU2,IO1*%\^/-,MC CJ/?94%5SIOY[!0T-AVD1;XF#\1N,P2'R-) MNL;R)"U;8]L$U(!\S%X9%O^JE>N"JO+<;6JQI>?5<(=M)J5"Q9B)5,M%L=A6[;Q]P!%J6121JK! MC!B5<+VD"OGGU$S'(Q;-RGN3?$9-%RQ^D,RMK^ET;RNL9!Z;7\;=OBL^36S?$W^_]/^NT7-VA?5;$?G MFJ/6^*N\[^)V[6L\0J,I:[\(HKTO>P\E#RI]!P8.*0JGNVWZWCOHEFT#XQ5+ M@^"WSH7QBE)"_JWPRYRG-SE@\P3M/<7^!#%L+2R$+!_3QGA95=@[VOY>*OLM B'9V6S[I>XOM X-Phone: (510) 549-3563 X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com i'm likely missing some historical context here, but... it would seem to me that loadbsd should default to multiuser startup... basically all other "real bsd" systems do this... (ultrix is the only exception i can think of, but it's twisted...) why doesn't it? serious debugging still necessary? 8-) chris *not* an amiga person... 8-) From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 10:49:01 1993 Subject: Re: Autoboot, anyone? To: cgd@postgres.Berkeley.EDU Cc: eeh@public.btr.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 708 Sender: NetBSD-Admin@cbmuucp.commodore.com > it would seem to me that loadbsd should default to multiuser > startup... basically all other "real bsd" systems do this... > (ultrix is the only exception i can think of, but it's twisted...) Well.. it *is* of course a historic relict, and .. I got used to it:-) Autobooting by default can be considered ok for the A3000 I guess, I don't know if the DMA engine on the two A2000 controllers can be trusted that much though.. However, with the patches Eduardo uploaded (thanks!) anybody can decide to which runlevel he/she wants to boot. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 12:17:45 1993 Subject: Re: Problem with pow.o in libm.a To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: hubert.feyrer@rrzc1.rz.uni-regensburg.de, netbsd-amiga@Cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 503 Sender: NetBSD-Admin@cbmuucp.commodore.com > Do you think we should send larry wall (the author of Perl) a patch so > that future versions of perl will not have this problem? If so, what > is the best #ifdef to use to indicate an amiga running netbsd? (I Just have him include math.h in those two files, this is not really os/system specific, it is a plain omission, in my eyes. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 16:11:22 1993 To: mw@eunet.ch Cc: cgd@postgres.Berkeley.EDU, eeh@public.btr.com, netbsd-amiga@cbmuucp.commodore.com Subject: Re: Autoboot, anyone? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: Markus W> Well.. it *is* of course a historic relict, and .. I got Markus W> used to it:-) Autobooting by default can be considered ok Markus W> for the A3000 I guess, I don't know if the DMA engine on the Markus W> two A2000 controllers can be trusted that much though.. Grin :-) I've been autobooting for the last week *although* I'm running a GVP equipped A2000 :-) My boothowto is binpatchable, so it isn't as flexible as Eduardos patch. What about /dev/reload rebooting, will it remember the last boothowto flag, or will it go into single user mode? I use this boot method a lot, and if it isn't going into multi-user mode I will get annoyed. Niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 16:15:02 1993 Subject: Re: Autoboot, anyone? To: cgd@postgres.Berkeley.EDU Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1103 Sender: NetBSD-Admin@cbmuucp.commodore.com > i'm likely missing some historical context here, but... > it would seem to me that loadbsd should default to multiuser > startup... basically all other "real bsd" systems do this... > (ultrix is the only exception i can think of, but it's twisted...) > why doesn't it? serious debugging still necessary? 8-) Single user mode is for restoring filesystems, recovering from crashes, etc. When NetBSD boots from RDB, it should go fully into multi-user mode. I forsee loadbsd eventually being used only for system administration. There are three reasons I chose to make single user mode the default: 1) I don't want to confuse new users more than necessary. Try to autoboot with only a root partition mounted and see what happens. 2) Backward compatibility. This is what NetBSD does (did?) now. 3) Forward compatibility. I see loadbsd being phased out and replaced by RDB booting. How do you plan to specify single user mode from RDB? If you really don't like to default to single user mode and don't want to specify the -a flag, you have the sources, and my patch. Change it. Eduardo From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 16:31:00 1993 Subject: Re: Autoboot, anyone? To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, cgd@postgres.Berkeley.EDU, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 965 Sender: NetBSD-Admin@cbmuucp.commodore.com > I've been autobooting for the last week *although* I'm running a GVP Me too. > equipped A2000 :-) My boothowto is binpatchable, so it isn't as flexible > as Eduardos patch. What about /dev/reload rebooting, will it remember > the last boothowto flag, or will it go into single user mode? I use > this boot method a lot, and if it isn't going into multi-user mode I will > get annoyed. The patch I sent out will remember the previous boot mode when using /dev/reload (or in my case /dev/reboot). However, since older versions of the kernel do not load d7 with the proper value, you may get random results booting from an old kernel to a newer one. When switching from an older kernel to one that supports d7=boothowto, it is best to shut the machine down and reboot from AmigaDOS using the new loadbsd. I have noticed some inconsistant behavior recently with /dev/reload, but I had noticed that before I made this autoboot modification as well. Eduardo From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 20:23:08 1993 Subject: How do you set up /dev/reload? To: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com I remember a while back, someone posted how to set up /dev/reload so that a fresh kernel could be loaded and booted. Could someone please explain this again, I deleted the message before i realized what is was (and kicked myself in the buut a few times, ... "He said butt, huh ... huh...hmm, huh"). Sorry about the Beavis & Buthead joke above, couldn't help myself! :) From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 21:01:27 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: failed to compile #613 Sender: NetBSD-Admin@cbmuucp.commodore.com Today i tried to compile #613 on the BSD-side. Alas, it failed: The file tty_conf.c couldn't be compiled when the define in ppp.h is set >0. If this one is set to 0, the file does compile fine, but the linker means that _pppattach() is undefined. What is missing ? Then again, i miss a README.613, and, why is there still this RECOMPILE-Readme, which is apperantly for Amiga-DOS ? :-) -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 21:48:53 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: failed to compile #613 Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 19, 7:56pm, Markus Illenseer wrote: > Today i tried to compile #613 on the BSD-side. > Alas, it failed: > > The file tty_conf.c couldn't be compiled when the define in ppp.h > is set >0. If this one is set to 0, the file does compile fine, but > the linker means that _pppattach() is undefined. > > What is missing ? I ran into what may be the same problem on AmigaDOS. I think there was a conflict between how some routines were declared. I just commented out the psuedo-device ppp (since I am not at the point of needing it yet). > Then again, i miss a README.613, and, why is there still this > RECOMPILE-Readme, which is apperantly for Amiga-DOS ? :-) Some of us still have to compile on AmigaDOS! :-) (But hopefully not for long.) Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 21:50:58 1993 Subject: Re: How do you set up /dev/reload? To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 509 Sender: NetBSD-Admin@cbmuucp.commodore.com > I remember a while back, someone posted how to set up /dev/reload > so that a fresh kernel could be loaded and booted. As a root: # cd /dev # mknod reboot c 2 20 (or change the "reboot" to "reload" if you want that name) And as you are ready, you might do the /dev/zero too at the same time (at least I didn't have it after the initial rootfs setup) # mknod zero c 2 12 Now, if you want to reload new kernel, first shutdown to singleuser, sync disks, unmount and copy the kernel to /dev/reboot ++Tero From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 19 22:33:14 1993 Subject: Re: How do you set up /dev/reload? To: DCG9367@tntech.edu Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 437 Sender: NetBSD-Admin@cbmuucp.commodore.com > I remember a while back, someone posted how to set up /dev/reload > so that a fresh kernel could be loaded and booted. > > Could someone please explain this again, I deleted the message before mknod /dev/reboot c 2 20 and while you're at it: mknod /dev/zero c 2 12 -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 20 04:00:55 1993 Subject: vmstat output To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] X-Charset: ASCII X-Char-Esc: 29 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, mtk asked once me to run vmstat to possibly see what kind of interrupts are running wild :) on my A2000. I finally had enough patience with that annoying keyboooard repeating and set NetBSD more or less up and running in multi-user mode, and here's what vmstat said (loadbsd'd 613 and I had 614 in /vmunix): interrupt total rate tbe 130895 10 kbd/scsi 51386 4 vbl 633770 50 rbf 8122053 646 clock 1256359 100 nmi 130 0 Total 10194593 811 I grepped the sources, and rbf seems to be serial interrupt, right? While I was in multi-user mode, I didn't use serial port at all, although I had used it before that in single-user mode. From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 20 09:18:14 1993 Subject: gdb and inferior registers To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I'm trying to get gdb working here on my 613-based kernel, but am currently hung up in u-area stuff. I'm hoping there are some kernel gurus out there who help me understand this. At various points, gdb needs to get CPU register values from the process being debugged; it uses ptrace() for this. What the amiga-specific code (based on the hp300 code) in gdb does first when it wants a register value is use ptrace() to get the u.u_kproc.kp_proc.p_regs pointer from the inferior process. This is supposed to point to a frame structure which contains a copy of the inferior's exception stack frame (at least it contains the same kind of stuff -- cpu context). The gdb code then uses this address (appropriately indexed) in another ptrace() call to actually get the register value. OK, sounds good. The problem is that u.u_kproc.kp_proc.p_regs is set up by the CPU trap code to point into the frame structure that is passed to it by value. In other words, p_regs points somewhere on the interrupt stack. Oops. ptrace EFAULTs on these addresses, but even if it didn't, how can the pointer still point to something valid? This has really got me stumped. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 20 09:52:54 1993 Subject: Re: vmstat output To: ayrjola@vinkku.hut.fi Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 627 Sender: NetBSD-Admin@cbmuucp.commodore.com > rbf 8122053 646 This one is *unusually* high.. unless you transferred files before in single user mode, that is. There should be one RBF for each character received. > clock 1256359 100 This looks ok, exactly 100Hz. > nmi 130 0 *Interesting* ! So you have one of those Amigas generating spurious NMI interrupts! This isn't the cause of the problem though, just interesting to know that those rumors seem to be true :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 20 13:24:07 1993 Subject: Re: vmstat output To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga mailing list) X-Mailer: ELM [version 2.3 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com Markus Wild: > > > rbf 8122053 646 > > This one is *unusually* high.. unless you transferred files before in > single user mode, that is. There should be one RBF for each character > received. Yes, I had used serial port in single-user mode. I transferred more files after that under amigados (as 38400 bps didn't seem to work under NetBSD) and vmstat results were totally different, rbf wasn't even the highest. > > nmi 130 0 > > *Interesting* ! So you have one of those Amigas generating spurious > NMI interrupts! This isn't the cause of the problem though, just > interesting to know that those rumors seem to be true :-) It is not so interesting to have spurious key repeats :) :( I bought this A2000 in December '87, and it is rev4.1 with Cherry keyboard (I understand it's the first B-model). I have added some resistors to the motherboard after I got GVP G-Force and serial ports in ISA-slots behind GoldenGate stopped working, so my motherboard is somewhere between rev4.1 and rev4.5. -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 20 15:36:11 1993 Subject: SCSI problems. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 763 Sender: NetBSD-Admin@cbmuucp.commodore.com I happened to get one more hard drive the other day, installed it and then decided to take a look at #614. Before, w/ versions 580-613 my machine didn't boot (couldn't find root), dumped that funky debugging stuff on both drives to the console. This time it still did this, but not with the new drive (which was on scsi6), ok, it still didna boot, bsd was on the old drives. But my littke (if not obvious) point is that there are some problems with the scsi-controlling code, now if I'll just get time to get the kernel sources again... The drives that I didn't get to work btw, were Quantum LPS102 and LPS52. --------------------------- --------------------------- FreakedOutBeyondAllReality laurit@mits.mdata.fi IfICan'tBreakItItAintFixed From NetBSD-Admin@cbmuucp.commodore.com Sat Aug 21 08:00:41 1993 Subject: 68040 NetBSD To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 291 Sender: NetBSD-Admin@cbmuucp.commodore.com I was having a brief chat to Charles Hannum (on IRC as Mycroft, from GNU) about NetBSD and he said he has just finished porting it to the HP 370 and that it is working on 68040 machines. Anyone care to follow this up and see if any of that work can be applied to the Amiga ? Darren From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 22 18:46:58 1993 Subject: GDB 4.9 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I got my mental problems worked out and have got gdb 4.9 running. Since ftp.eunet.ch's NetBSD-Amiga/incoming directory is broken, I have uploaded three files to wuarchive.wustl.edu under systems/amiga/boing/NetBSD/incoming. They are: sys613-debug-diffs.gz Changes to the 613 tree for kernel support of single-step. A glance at the size of this file should indicate how extensive the changes were! (Not very.) gdb-4.9-amigabsd-diffs.gz Diffs to the 4.9 distribution of GDB. gdb-4.9.gz GDB binary. A few warnings and tips: 1) The gdb binary hasn't been tested extensively. It ought to work just fine with the possible exception of system-dependent things like reading and writing the debugged process's registers, memory, and so forth. I have done some simple testing with single-stepping, querying the value of variables, and debugging a core dump. It's possible that more complex stuff will hit areas that I've overlooked. I have no idea if floating point is handled or not. Consider this a beta test. 2) The kernel diffs are relative to sys; make sure to use the -p option to patch. 3) Apply the GDB diffs relative to the gdb-4.9 and again make sure to use the -p option to patch. 4) Building gdb naively (letting the configure script figure out what machine you're on) requires a uname that returns proper error codes. The uname binary in usrbin.tgz on ftp.eunet.ch always returns 10. Get a new copy from sun-lamp.cs.berkeley.edu. If you don't want to do that (or can't) you should be able to configure the gdb source tree with: ./configure amigabsd 5) Lastly, whenever header files are updated in your source tree, make sure you update the copies in /usr/include/sys, /usr/include/machine, /usr/gnu/some-ridiculously-long-pathname/sys, etc. The point is to keep your applications and your kernel in sync with one another. 6) OK, just one more -- you can get mkdep on sun-lamp; it's definitely worthwhile for building the kernel. Just cd to .../compile/AMIGA, make depend, and away you go! Please let me know if there are any problems. Have fun! -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 23 00:47:30 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: 68040 NetBSD Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 21, 3:51pm, Darren Reed wrote: > > I was having a brief chat to Charles Hannum (on IRC as Mycroft, from > GNU) about NetBSD and he said he has just finished porting it to the HP 370 > and that it is working on 68040 machines. > > Anyone care to follow this up and see if any of that work can be applied > to the Amiga ? I would be interested in this port, although it comes a little late: I am just getting the point where NetBSD is running on my PPI Zeus board. The MMU code isn't very pretty and the unimplemented floating point emulation is just the bare minimum to let the basic system programs run (i.e. df, fsck, and newfs in particular). I also don't have it working with copyback cache enabled yet. Do you have an email address for Charles? I would like to find out if I can see what he's done and what parts could be applicable to the Amiga. (My changes shouldn't affect compiling to run on a 68020/68030 machine.) Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 23 14:06:41 1993 Subject: Re: GDB 4.9 To: ahh@netcom.com (Andy Heffernan) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 777 Sender: NetBSD-Admin@cbmuucp.commodore.com > sys613-debug-diffs.gz > Changes to the 613 tree for kernel support > of single-step. A glance at the size of > this file should indicate how extensive the > changes were! (Not very.) Looks oky! > gdb-4.9-amigabsd-diffs.gz > Diffs to the 4.9 distribution of GDB. I just browsed thru them, and they look mostly okay. However, I saw two things that are obviously wrong. 1/ we *do* have N_HEADER_IN_TEXT and TEXT_START is 8192+0x20. 2/ NetBSD no longer keeps the signal trampoline code in the u-area, so that code is certainly wrong. Other than that, I'll give it a try, thanks for the work! -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 23 19:40:12 1993 Subject: Re: GDB 4.9 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > gdb-4.9-amigabsd-diffs.gz > > Diffs to the 4.9 distribution of GDB. > > I just browsed thru them, and they look mostly okay. However, > I saw two things that are obviously wrong. > 1/ we *do* have N_HEADER_IN_TEXT and TEXT_START is 8192+0x20. > 2/ NetBSD no longer keeps the signal trampoline code in the > u-area, so that code is certainly wrong. Okay, I'll have to fix that. There's probably a bunch of this sort of stuff that's not quite right. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 24 01:18:56 1993 Subject: Re: gdb and netbsd-current To: netbsd-amiga@cbmuucp.commodore.com >From: Fred Fish Content-Length: 262 Content-Type: text X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > I am not aware of who is working on gdb for netBSD-Amiga so: Anyone doing serious work on gdb should be coordinating with the gdb maintainers here at cygnus. I can supply details of what the advantages are to both sides for those that are interested. -Fred From NetBSD-Admin@cbmuucp.commodore.com Tue Aug 24 04:29:16 1993 Subject: sync lockups? To: netbsd-amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 1146 Sender: NetBSD-Admin@cbmuucp.commodore.com I seem to have solved my booting problem. With the distributed kernel, I can boot about once every 10 tries. Otherwise I get "no suitable root". I played with scsi.c until I found a solution... (Ya see, I was too dumb to figure out how to dis-able sync trnasfer...) If I enable sync_debug, it boots perfectly every time... Well it still always says "UNIT 6 ACING WEIRD DISCONNECTING..." or some such thing... But then it says that it is forcing unit 6 sync, and works fine. But I am not complaining. Anyway, it might be something to look in to Markus... My setup is an A3000 with 2 megs chip/4 megs fast. And a Quantum LP105S... (I don't know if I have the PROTO scsi chip or not...) -- Kevin McCarthy signals@krypton.mankato.msus.edu ------------------------------------------------------------------------------- "If I were a carpenter, I'd hammer on my piglet, I'd collect the $7 and I'd buy a big prosthetic forehead and wear it on my real head." -They Might Be Giants ------------------------------------------------------------------------------- HELLO! I'm a .signature virus! Join in and copy me into yours! From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 25 21:07:57 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com The adosfs code for NetBSD is almost working for me in read-only mode. I really hope to get the kit out before the weekend so the party people in Germany have something to tear apart and laugh at :-) Since I have no real docs on the Ados filesystems (just some code & header files), there are certain questions I must have the answer to in order to complete the code: A. What's the hashing function for directory entries? Now I'm doing lookups sequentially, and that is bad. I tried summing/xoring the name bytes but that wasn't it. The functionality is needed for write capabilities as well. B. How is the bitmap organized? I can guess, but the empirical test procedure would be far too painful for my heart. This is of course needed for things like write capability and used/free block count reports. C What is the differences between the newer filesystems (DCFS, etc) and FFS? D Are there any PD docs or source for writing into Ados FS online somewhere. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 25 21:08:01 1993 Subject: My first POLL To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1355 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello out there, this is a poll to get more information about the members of this mailing list. Please do not send the answer to the mailing list, send it to me directly. The evaluation will be posted to the list. 1. Which Amiga do you own? [ ] A500 [ ] A600 [ ] A1000 [ ] A1200 [ ] A2000 [ ] A2500 [ ] A3000 [ ] A4000 [ ] ..... 2. Describe your equipment? Graphics/Moitor : CPU : HD/Controller : LAN : 3. How many memory is available? ... MB CHIP ... MB FAST ... MB FAST/32 3.a Where is the memory located? ... Motherboard ... HD-Controller ... CPU-Card ... Memory-Card 4. Do you have NetBSD-Amiga working on your machine? [ ] YES [ ] no Comments: 5. Are you experienced in ( 1 - godly, ..., 6 - idiot ;) [ ] UNIX [ ] UNIX-Programming [ ] UNIX Kernel-programming [ ] UNIX-Administration [ ] C-Programming [ ] Amiga-OS [ ] Amiga-HW 6. What Hardware would you like to have supported on NetBSD-Amiga? 7. Feel free to give more information that is relevant, you think. (it's my first poll) 8. How old are you? Thanks in advance, Matthias Kirschnick ------------------------------------------------------------------------------ Matthias Kirschnick kirschnick@immd4.informatik.uni-erlangen.de Phone: 49 9131 85 8027 "Es geht auch anders, aber so geht es auch!" (Lotti Huber) From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 25 21:09:08 1993 Subject: Timezones and core dumps To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I don't know if anyone else has tried setting their timezone stuff up or not, and if so, if you ran into the same problem I did, but there appears to be a bug in the gcc that is distributed with the rest of the stuff in usrgnu.tgz. Here's the story. Some weeks ago, I cd'd to /usr/share/zoneinfo and did a make, then a make install. This creates a little tool (zic -- for zoneinfo compile, I guess) and then generates all the little databases that describe the time-change rules for the various time zones. Most of the way through the make install, just after the GMT database is made, the make bombed out with a segmentation fault. Other simple commands like 'ls -l' and date would die, too. Eventually, I stopped panicking and found that removing (or moving) the GMT file made everything work again. How the hell do you figure out what's going on without any debugger?! Hence, gdb. Anyway, I traced the problem back to the routine tzload() in ctime.o in libc.a. This is the routine that reads the zoneinfo for your chosen timezone. Like all the rest of the modules in libc.a, ctime.c gets compiled with the -O2 optimization option, and here is where gcc seemed to get confused with its register allocation. It appeared to be using an address register as in index value, and using immediately using that same register as an address, barfing somewhere in page 0. Compiling with -O produces a functional subroutine, fortunately. I have uploaded a gzipped tar file of new ctime.o and ctime.po objects to ftp.eunet.ch's incoming directory (now unbroken, thanks Markus) -- these can replace the versions in /usr/libc.a and /usr/libc_p.a, respectively. The file is ctime.obj.tgz. Do: # cd /usr/lib # ar r libc.a ctime.o # ranlib libc.a # ar r libc_p.a ctime.po # ranlib libc_p.a if you want to replace the old objects with the new ones. For safety's sake, you may want to back up the libraries before you monkey with them. The bad news is that since we don't have shared libraries, everything that pulls in ctime.o potentially has to be relinked. This is a lot of stuff. If you don't have the source to begin with, you've got to get it all and recompile it before you can get your timezone stuff set up. Gak. I'm in the process of replacing my binaries now, and will post a list of the affected programs at some point in the future. I have about 8 left out of around 120 or so, and man, does my brain hurt. Do a strings on a program and fgrep for localtime to see if it might seg-fault on you. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Aug 25 22:24:58 1993 To: Matthias.Kirschnick@informatik.uni-erlangen.de Cc: netbsd-amiga@cbmuucp.commodore.com Subject: My first POLL Sender: NetBSD-Admin@cbmuucp.commodore.com Return-Path: From: Matthias Kirschnick Subject: My first POLL To: netbsd-amiga@cbmuucp.commodore.com Date: Wed, 25 Aug 1993 13:54:14 +0100 (METDST) X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1355 Sender: NetBSD-Admin@cbmuucp.commodore.com NetBSD-Amiga poll: 1. Which Amiga do you own? [ ] A500 [ ] A600 [ ] A1000 [ ] A1200 [ ] A2000 [ ] A2500 [x] A3000 [ ] A4000 [ ] ..... 2. Describe your equipment? Graphics/Moitor : 1850 CPU : 68030/16Mhz (pushed to 24Mhz) HD/Controller : LP52S+LP240S / SCSI "proto" chip LAN : (none) 3. How many memory is available? .2. MB CHIP ... MB FAST .8. MB FAST/32 3.a Where is the memory located? .x. Motherboard ... HD-Controller ... CPU-Card ... Memory-Card 4. Do you have NetBSD-Amiga working on your machine? [x] YES [ ] no Comments: Not really useful (yet). 5. Are you experienced in ( 1 - godly, ..., 6 - idiot ;) [3] UNIX [5] UNIX-Programming [5] UNIX Kernel-programming [5] UNIX-Administration [1] C-Programming [2] Amiga-OS [4] Amiga-HW 6. What Hardware would you like to have supported on NetBSD-Amiga? Needs parallel port and 2232 (serial port board) neither were working last time I checked. 7. Feel free to give more information that is relevant, you think. (it's my first poll) More good questions (?): How do you expect to use Net-BSD on your Amiga? Stand-alone? Server or Client? What do you expect to get out of it? UNIX SA experience? A really useful UNIX box? Do you have a direct feed to INTERNET? uucp feed? whatever? 8. How old are you? 36 From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 01:31:37 1993 Subject: Re: Timezones and core dumps To: ahh@netcom.com (Andy Heffernan) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 742 Sender: mw@eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com > I don't know if anyone else has tried setting their timezone > stuff up or not, and if so, if you ran into the same problem I did, but > there appears to be a bug in the gcc that is distributed with the rest > of the stuff in usrgnu.tgz. This could be the problem, I just found out that on the freshly compiled new system I made, the timezone problem had magically gone.. I'll upload a new set of binaries (bin, usr.bin, etc) next week probably, so if you want to wait, getting the new binaries might be easier for a lot of people then recompile the system themselves. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 09:05:50 1993 To: niklas@appli.se (Niklas Hallqvist) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. <9308251506.AA02795@della.appli.se> X-Phone: (510) 549-3563 X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com you'll hate me for saying this, but... > The adosfs code for NetBSD is almost working for me in read-only mode. could you please make sure that this thing, after reading e.g. shorts and longs off the disk, does the right thing in terms of using the long- and short- reordering macros (i.e. ntohl() and ntohl(), and the vice versa when writing back to the disk?)? it'd be nice to be able to use ados floppies on e.g. a pc... 8-) chris From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 09:29:57 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com cgd@postgres.berkeley.edu said: >it'd be nice to be able to use ados floppies on e.g. a pc... 8-) Can't. The problem is that the PC's controller can't put enough data on the track in low-density mode, so 720k vs 880k wouldn't cut it. It would be better in this case to make Paula (the Amiga disk controller, among other things) drive in/out PC formatted disks (as the OS now supports). Bill From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 09:36:46 1993 To: billc@icecube.rain.com (William J. Coldwell) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. <9308260728.AA00225@ iceCuBE.rain.com > X-Phone: (510) 549-3563 X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com > cgd@postgres.berkeley.edu said: > > >it'd be nice to be able to use ados floppies on e.g. a pc... 8-) > > Can't. The problem is that the PC's controller can't put enough data on the track in > low-density mode, how about high density mode? e.g. you can't use mac/pc low density floppies back and forth, but you can share high density floppies... and, needless to say, ix86 boxes aren't the only little-endian boxes in the world with floppies... some decstations come to mind, and surely there are more, some of which probably would work... 8-) additionally, lack of current hardware shouldn't prevent good style! 8-) chris From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 09:48:12 1993 To: cgd@postgres.berkeley.edu Subject: Re: AmigaDOS FS questions.. Cc: billc@icecube.rain.com (William J. Coldwell), netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com >> cgd@postgres.berkeley.edu said: >> >> >it'd be nice to be able to use ados floppies on e.g. a pc... 8-) >> >> Can't. The problem is that the PC's controller can't put enough data on the track in >> low-density mode, >how about high density mode? Nope. 99% of Amigas don't have the high-density drives that Commodore produced for such a short while, and obviously, you can't read the high-density disks in low-density drives. >e.g. you can't use mac/pc low density floppies back and forth, but >you can share high density floppies... The Mac has a PC file system for the Superdrive floppy. >and, needless to say, ix86 boxes aren't the only little-endian >boxes in the world with floppies... some decstations come to mind, >and surely there are more, some of which probably would work... 8-) It might be possible to have a 720k sized Amiga filesystem, but it would require a funky mountlist to be able to read it under AmigaDOS. >additionally, lack of current hardware shouldn't prevent good style! 8-) Oh yeh, right.. did I tell you I work for Intel? ;-)) Current hardware, and good style.. hehe. From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 13:17:11 1993 Subject: Re: AmigaDOS FS questions.. To: cgd@postgres.Berkeley.EDU Cc: niklas@appli.se, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 914 Sender: NetBSD-Admin@cbmuucp.commodore.com > you'll hate me for saying this, but... > > > The adosfs code for NetBSD is almost working for me in read-only mode. > > could you please make sure that this thing, after reading e.g. shorts > and longs off the disk, does the right thing in terms of using the > long- and short- reordering macros (i.e. ntohl() and ntohl(), and the > vice versa when writing back to the disk?)? > > it'd be nice to be able to use ados floppies on e.g. a pc... 8-) Oh... if you didn't know Chris, ados floppies use 11 sectors per track, I don't think *any* pc floppy controller could handle this. As a side-effect, ados does not use the index-hole to synchronize tracks, they can start anywhere on the track.. Still thinking pc's could read such floppies?:-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 13:23:15 1993 Subject: Re: AmigaDOS FS questions.. To: cgd@postgres.Berkeley.EDU Cc: billc@icecube.rain.com, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 986 Sender: NetBSD-Admin@cbmuucp.commodore.com > how about high density mode? > > e.g. you can't use mac/pc low density floppies back and forth, but > you can share high density floppies... Same problem again here.. unless the amiga is explicitly told to write in reduced density (720/1440k), normal floppies end up in 880/1760k. The problem isn't lo/hi-density, the problem is #sectors/track. > and, needless to say, ix86 boxes aren't the only little-endian > boxes in the world with floppies... some decstations come to mind, > and surely there are more, some of which probably would work... 8-) Oky, which other box doesn't use a dedicated controller chip to do MFM encoding, but uses - like the amiga - software to do the trick? > additionally, lack of current hardware shouldn't prevent good style! 8-) Oh, I won't say anything against this argument :-) -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 13:55:19 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com Christ, are you lucky! I'm in the process of moving. I've already packed the RKM's in a box, but the AmigaDOS manual is one of the few I haven't got around to packing yet. ISBN 0-553-35403-5, published by Bantam books. Get a copy :-) >A. What's the hashing function for directory entries? Now I'm doing > lookups sequentially, and that is bad. I tried summing/xoring the > name bytes but that wasn't it. The functionality is needed for > write capabilities as well. Page 342... Hash(name) unsigned char *name; { int val, len, i; val = len = (int)*name++; /* name is a BCPL string: len in 1st byte */ for (i = 0; i < len; i++) val = ((val * 13) + (int)toupper(*name++))&0x7ff; return val % 72; } >B. How is the bitmap organized? I can guess, but the empirical test > procedure would be far too painful for my heart. This is of course > needed for things like write capability and used/free block count > reports. Page 337-338. It doesn't go into enough detail for you but here's a start: On the FFS root block, where SIZE is the block size in longwords (default 128), the bitmap keys are at SIZE-49 to SIZE-25. I think these point to blocks that contain the bitmap. If needed, SIZE-24 points to another bitmap key pointer block. SIZE-24 is just another key pointer in OFS (i.e. there is a limit to the size of the OFS bitmap) >C What is the differences between the newer filesystems (DCFS, etc) > and FFS? The international filesystems "know" how to convert accented characters from upper to lower case. It's not a simple boolean op any more. This will affect the implementation of toupper() in the hash function. DCFS "caches" directory information at the end of a directory header block (?) because FFS's one file per block gronks the shit out of your hard disk, as we all know. Format of DCFS cache unknown to me. > >D Are there any PD docs or source for writing into Ados FS online > somewhere. Can't think of any, but I'm sure there are. As for non-PD, see above, plus get back issues (Hah!) of the Amiga Transactor, issues 2-2 to 2-5. They re-implement FFS as an exercise in writing filesystems. This magazine has gone bankrupt :-( so you can't get these issues from the publisher. They are collector's items ($$$). Don't bother asking me any more. I think I'm gonna pack that ADOS manual today :-) -- David Jones FreeNet: (preferred) aa457@freenet.carleton.ca 6730 Tooney Drive NotSoFreeNet: dej@qpoint.ocunix.on.ca Orleans, Ontario Fidonet: 1:163/109.8 K1C 6R4, Canada Phone: 1-613-830-1437 From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 13:55:39 1993 To: cgd@postgres.Berkeley.EDU Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Chris" == cgd writes: Me> The adosfs code for NetBSD is almost working for me in read-only Me> mode. Chris> could you please make sure that this thing, after reading Chris> e.g. shorts and longs off the disk, does the right thing in Chris> terms of using the long- and short- reordering macros Chris> (i.e. ntohl() and ntohl(), and the vice versa when writing back Chris> to the disk?)? I will. I'd like to have some machine independent virtual partitioning code as well, which could handle all the usual partitioning standards there is. Then we could really move HDs around. Ya see, I have tons of sources lying around (X11R5, almost all GNU software and many PD sources). Often they're just needed at compile time. After installing a program, I could unmount the sources disk and move it to other platforms, instead of using up diskspace I don't have (at home, that is) and writing/ reading sloooooow tapes. Hmm, does the pcfs code use host-to-network bytereordering? If not we'll have to fix it. Not all of us have fast modems/tapes so I guess pcfs will be popular when we have a floppy driver (Well, raw tar 720K floppies is an option of course). I guess floptical users would like this as well... And please.... The AmigaDOS FS hashing function, someone? Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 15:22:09 1993 To: aa457@freenet.carleton.ca Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "David" == David Jones writes: David> Christ, are you lucky! I'm in the process of moving. I've David> already packed the RKM's in a box, but the AmigaDOS manual is David> one of the few I haven't got around to packing yet. ISBN David> 0-553-35403-5, published by Bantam books. Get a copy :-) Thanks! It will be a big help for me. BTW, does anybody have those Amiga transactor issues (2-2 to 2-5)? If you do and have a FAX available somewhere, would it be to much to ask for a FAX copy of the pages that covers the FFS reimplementation? I'm in Sweden if you want to check up the rates first. As the magazine obviously has gone down the sink, the Copyright issues would not be a problem, would they? FAX number provided in the signature. Of course snail-mail copies would be appreciated as well. Niklas Niklas Hallqvist Phone: +46-(0)31-40 75 00 Applitron Datasystem Fax: +46-(0)31-83 39 50 Molndalsvagen 95 Email: niklas@appli.se S-412 63 GOTEBORG, Sweden mcsun!seunet!appli!niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 16:42:37 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 26, 7:55am, David Jones wrote: > > > >D Are there any PD docs or source for writing into Ados FS online > > somewhere. > > Can't think of any, but I'm sure there are. As for non-PD, see above, plus > get back issues (Hah!) of the Amiga Transactor, issues 2-2 to 2-5. They > re-implement FFS as an exercise in writing filesystems. This magazine has > gone bankrupt :-( so you can't get these issues from the publisher. They > are collector's items ($$$). I think the Transactor articles are about the DiskHandler program from the Software Distillary and the code is on Fred Fish disk #236. [I've also got most of the Transactor magazines - one issue I either never received or misplaced :-(.] Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 17:03:19 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com On Aug 26, 3:17pm, Niklas Hallqvist wrote: > BTW, does anybody have those Amiga transactor issues (2-2 to 2-5)? > If you do and have a FAX available somewhere, would it be to much to > ask for a FAX copy of the pages that covers the FFS reimplementation? > I'm in Sweden if you want to check up the rates first. As the magazine > obviously has gone down the sink, the Copyright issues would not be > a problem, would they? FAX number provided in the signature. Of course > snail-mail copies would be appreciated as well. If I remember correctly, the Transactor article covers the SFS. I don't think the FFS was available at the time or was very new. It's been quite a while, so I may be incorrect. Michael -- Michael L. Hitch INTERNET: osymh@montana.edu Computer Consultant BITNET: OSYMH@MTSUNIX1.BITNET Office of Systems and Computing Services Montana State University Bozeman, MT USA From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 20:07:03 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com > >> >it'd be nice to be able to use ados floppies on e.g. a pc... 8-) Nice maybe, but too much work for too little gain. Why not just use the DOS filesystem on the Amiga? Yes, DOS FS sucks, but do you really want to spend your time programming an Amiga FS for a DOS system? You would most likely run into DOS limitations and have to braindamage it anyway. For example in PC NFS, can use NFS mounted filesystems that have > 8 char names, but it has to translate them into 8 char names before giving them to DOS. You end up typing even more cryptic filenames because of the uniqueness algorithm used to turn >8 into 8 char names. So even if the AmigaDOS filesystem is better, running it on a DOS system doesn't mean you can escape DOS's limitations. Although we hate to admit it the MSDOS file system is the most standard filesystem around. Almost everyone supports mounting MSDOS floppies. Just to name a few: AmigaDos, AppleDos, Atari's TOS, any many versions of Unix. > It might be possible to have a 720k sized Amiga filesystem, but it would require a funky > mountlist to be able to read it under AmigaDOS. So what does this buy you - a new Amiga filesystem, one that isn't used by your floppy collection (it doesn't help you move the floppies you already have), requires someone write MSDOS code to implement - and install on all the PC's you use, then you can create some new floppies on your amiga that can be used on the MSDOS system. Note the size of the floppies would be different, so you couldn't just copy a 880K AmigaDos Floppy to the 720K NewAmigaDos Floppy - you have to break up the files. Why bother, you have access to a MSDOS filesystem for AmigaDOS, just use it to create MSDOS disks in the first place - it a lot easier. What does this have to do with NetBSD anyway? Does it support MSDOS floppies - Any Floppies? Greg Jones From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 21:09:08 1993 Subject: Re: AmigaDOS FS questions.. To: jonesjg@dg-rtp.dg.com (Greg Jones) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD mailing list) X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 537 Sender: NetBSD-Admin@cbmuucp.commodore.com > Why bother, you have access to a MSDOS filesystem for AmigaDOS, > just use it to create MSDOS disks in the first place - it a lot easier. > > What does this have to do with NetBSD anyway? > Does it support MSDOS floppies - Any Floppies? I don't see much in using the amiga ffs formatted floppies otherways than that 880kB is more than 720kB, but there is much need for this file system if you happen to have amiga ffs formatted partitions on your hard disk and would like to access those from NetBSD. Now, is this useless? ++Tero From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 22:38:29 1993 To: jonesjg@dg-rtp.dg.com Subject: Re: AmigaDOS FS questions.. Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com Greg Jones wrote: > > >> >it'd be nice to be able to use ados floppies on e.g. a pc... 8-) > > Nice maybe, but too much work for too little gain. > Why not just use the DOS filesystem on the Amiga? > > Yes, DOS FS sucks, but do you really want to spend your time programming > an Amiga FS for a DOS system? You would most likely run into DOS limitations > and have to braindamage it anyway. [ ... much discussion deleted ... ] > Why bother, you have access to a MSDOS filesystem for AmigaDOS, > just use it to create MSDOS disks in the first place - it a lot easier. > > What does this have to do with NetBSD anyway? > Does it support MSDOS floppies - Any Floppies? I think you're missing the point here. This is the netbsd-amiga list. We (well, excluding me currently) are working on porting NetBSD to the Amiga. Most of us still use AmigaDOS and have filesystems written in the Amiga FFS format. We want to be able to read files from FFS filesystems under NetBSD (NOT MS-DOS). The discussion I believe led you astray was when they started talking about making the code portable - that followed by the fact PC controllers write sectors at a time as opposed to a whole track (requiring slop between the sectors), and eliminating the hope that those controllers could read Amiga-written tracks. Your suggestion that we just use the MS-DOS filesystem as an intermediate is a good one. I believe, though, a better solution would allow access to the "native" filesystem of the machine. - Chris Hooper Programmer, MTU Networking (906) 487-2800=voice cdh@mtu.edu Michigan Technological University 2787=fax From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 22:44:05 1993 To: nix@stekt.oulu.fi Subject: Re: AmigaDOS FS questions.. Cc: netBSD-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Why bother, you have access to a MSDOS filesystem for AmigaDOS, > > just use it to create MSDOS disks in the first place - it a lot easier. > > > > What does this have to do with NetBSD anyway? > > Does it support MSDOS floppies - Any Floppies? > > I don't see much in using the amiga ffs formatted floppies > otherways than that 880kB is more than 720kB, but there is > much need for this file system if you happen to have amiga > ffs formatted partitions on your hard disk and would like > to access those from NetBSD. > > Now, is this useless? > > ++Tero > I never said that having an Amiga filesystem on NetBSD was useless, in fact it would be nice to cross mount partitions between AmigaDOS and NetBSD. I said writing an Amiga filesystem for MSDOS was useless. Greg Jones From NetBSD-Admin@cbmuucp.commodore.com Thu Aug 26 23:26:52 1993 To: cdh@mtu.edu Subject: Re: AmigaDOS FS questions.. Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > I think you're missing the point here. >I believe, though, a better solution > would allow access to the "native" filesystem of the machine. You are correct, I got lead astray by the MSDOS discussion. I agree that an Amiga filesystem on NetBSD would be great. MS-DOS floppy support would be nice for transportability. Greg Jones From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 27 13:30:55 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com >BTW, does anybody have those Amiga transactor issues (2-2 to 2-5)? >If you do and have a FAX available somewhere, would it be to much to >ask for a FAX copy of the pages that covers the FFS reimplementation? >I'm in Sweden if you want to check up the rates first. As the magazine >obviously has gone down the sink, the Copyright issues would not be >a problem, would they? FAX number provided in the signature. Of course >snail-mail copies would be appreciated as well. FAX from North America is ~$1.00/min (3 SEK/min?) Snail could be cheaper. Copyright is still an issue. If the author retained the copyright (many Transactor authors did that) then the copyright lasts as long as the author is still alive, plus 50 years (under Canadian law). Even if not, the magazine probably has a 50 year period or something. -- David Jones FreeNet: (preferred) aa457@freenet.carleton.ca 6730 Tooney Drive NotSoFreeNet: dej@qpoint.ocunix.on.ca Orleans, Ontario Fidonet: 1:163/109.8 K1C 6R4, Canada Phone: 1-613-830-1437 From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 27 13:44:26 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: AmigaDOS FS questions.. Sender: NetBSD-Admin@cbmuucp.commodore.com >I will. I'd like to have some machine independent virtual partitioning >code as well, which could handle all the usual partitioning standards >there is. Then we could really move HDs around. Ya see, I have tons What is the "recommended" behavior wrt removeable partitionable media? I think that NetBSD/386 tries to grok partition tables (BSD style) on floppies (/dev/rfd0d). One of the first things I want to do to NetBSD/Amiga once qpoint has a big enough disk is to add removable media support to the SCSI driver so that I can insert/remove flopticals w/o those annoying sense messages. Is it possible to re-read the partition table on an insert? Is there any way that I can determine if a device is in use when it is removed? i.e. popping a disk out when tar asks you to is OK but popping the disk while it is still mounted as a filesystem is NOT!!! Methinks the removal/re-read code should be combined with the non-machdep virtual partition code proposed above. While I'm on the topic, once I've got the floptical working, I may be mad enough to attempt a floppy driver that reads/writes both 880K and 720K disks. I'd need docs on the 720K format for this, though. (In case anybody's wondering why I'm so crazy about flopticals, it's because they make a great backup/transfer medium when you have nothing else.) >Hmm, does the pcfs code use host-to-network bytereordering? If not >we'll have to fix it. Not all of us have fast modems/tapes so I guess >pcfs will be popular when we have a floppy driver (Well, raw tar 720K >floppies is an option of course). I guess floptical users would like >this as well... Be careful. Htons/ntohs/etc only work if your filesystem is in Motorola byte order. There is no portable way (w/o conditional code) that I know of to work with Intel byte order regardless of the ordering on your machine. -- David Jones FreeNet: (preferred) aa457@freenet.carleton.ca 6730 Tooney Drive NotSoFreeNet: dej@qpoint.ocunix.on.ca Orleans, Ontario Fidonet: 1:163/109.8 K1C 6R4, Canada Phone: 1-613-830-1437 From NetBSD-Admin@cbmuucp.commodore.com Fri Aug 27 13:48:24 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Forgot to mention... Sender: NetBSD-Admin@cbmuucp.commodore.com One thing I forgot to mention: if you are replying to any of my previous messages, I won't be able to get back to you for mayble a couple of weeks. I pack my computer today, and will not have net access until I finalize my thesis supervisor at U of T. -- David Jones FreeNet: (preferred) aa457@freenet.carleton.ca 6730 Tooney Drive NotSoFreeNet: dej@qpoint.ocunix.on.ca Orleans, Ontario Fidonet: 1:163/109.8 K1C 6R4, Canada Phone: 1-613-830-1437 From NetBSD-Admin@cbmuucp.commodore.com Sun Aug 29 19:35:18 1993 Subject: virtual memory and swapping To: netbsd-amiga@cbmuucp.commodore.com Cc: madsen@cs.iastate.edu Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com Hello. I am wondering what the current state is with virtual memory and swapping with NetBSD-Amiga. First, however, my setup: A3000T, 25Mhz, 4 megabytes of fast RAM 8 meg root partition (a) on device 0 42 meg usr partition (d) on device 0 5 meg swap partition (b) on device 6 kernel version #613 SCSI DMA disabled According to the FAQ, I should have an entry for the swap partion in my "/etc/fstab" file that looks like the following: /dev/sd6b /tmp mfs rw 1 1 However, according to the manual entry for fstab, all swap partitions should be entered in the fstab with a filesystem type of "swap". If I try to make an entry with a filesystem type of "swap", I receive an error when doing a "mount -av" that the executable "mount_swap" can not be found. I also see that the mount_mfs command is simply a symbolic link to "newfs" in "/sbin". After doing a "mount -av" with the swap parition mounted with a filesystem type of "mfs" and executing the command "swapon -a", the "swapinfo" command reports: Device 512-blks Used Available Capacity /dev/sd0b 0 -1 1 -Inf% Does this mean that I don't actually have *any* swap? When trying to run some fairly memory-intensive programs, like the makewhatis script, I often get a kernel panic: vm_fault(c2000, 1690000, 3, 0) -> 1 type 8, code[mmu, ssw]:401070d trap type 8, code = 401070d, v = 1690000 pid = 274, pc = 000591DA, ps = 2300, sfc = 0001, dfc = 0001 Am I doing something wrong and have something not configured correctly, or is virtual memory not fully implemented yet for NetBSD-Amiga? Thanks for any help, Dave -- Dave R. Madsen | Computer Science Department | Office: 107 Atanasoff Systems Support Group | Iowa State University | twisted@iastate.edu Project Vincent WGA | Ames, Iowa | madsen@cs.iastate.edu From NetBSD-Admin@cbmuucp.commodore.com Mon Aug 30 12:14:30 1993 Subject: Re: virtual memory and swapping To: madsen@cs.iastate.edu (Dave R. Madsen) Cc: netbsd-amiga@cbmuucp.commodore.com, madsen@cs.iastate.edu X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2298 Sender: NetBSD-Admin@cbmuucp.commodore.com > According to the FAQ, I should have an entry for the swap partion in my > "/etc/fstab" file that looks like the following: > > /dev/sd6b /tmp mfs rw 1 1 Uhm, *slight* confusion alert here.. /tmp is a memory filesystem, call it ram disk, and it only needs "/dev/sd6b", ie. the swap partition, as a template how to build the ramdisk to be optimally backed by the swap partition (which is used to back the virtual memory used up by the ram disk). So, /tmp is a ram disk, no the swap partition. > However, according to the manual entry for fstab, all swap partitions should > be entered in the fstab with a filesystem type of "swap". If I try to make > an entry with a filesystem type of "swap", I receive an error when doing a > "mount -av" that the executable "mount_swap" can not be found. I also see > that the mount_mfs command is simply a symbolic link to "newfs" in "/sbin". "mfs" is used to mount a new ramdisk, e.g. you can use: mfs /dev/sd6b /var/tmp to mount an additional ramdisk at /var/tmp, given your swap partition is on /dev/sd6b. > After doing a "mount -av" with the swap parition mounted with a filesystem > type of "mfs" and executing the command "swapon -a", the "swapinfo" command > reports: This rather sounds like you're not using an uptodate /vmunix. Remember, programs like ps, w, swapinfo, need to be able to look up the location of symbols in the currently running kernel, to be able to read them from the right spot in /dev/kmem. If you're using an outdated /vmunix, those locations will come out wrong. > vm_fault(c2000, 1690000, 3, 0) -> 1 > type 8, code[mmu, ssw]:401070d > trap type 8, code = 401070d, v = 1690000 > pid = 274, pc = 000591DA, ps = 2300, sfc = 0001, dfc = 0001 Hm, which kernel were you using exactly? You can do "nm -n vmunix" to look in which function that pc above lies. > Am I doing something wrong and have something not configured correctly, or > is virtual memory not fully implemented yet for NetBSD-Amiga? Vm works fine on my system, I once tried out running 50 emacses, which worked, and this task surely needed quite a bit of vm... -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