From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 1 06:19:40 1993 Subject: Re: virtual memory and swapping To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] 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. > Okay, I now understand the difference between a swap filesystem and a "mfs" filesystem. I have entered an entry in /etc/fstab for my swap partition as follows: /dev/sd6b / swap sw 0 0 Now, however, after I do a "mount -av" and enter the command "swapon -a", I get the error: swapon: /dev/sd6b: device not configured I am able to do a newfs on the /dev/sd6b partition, so I know that the system is able to read/write the /dev/sd6b partition. Any ideas? >> 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. I am using kernel #613 directly from ftp.eunet.ch, except that I have used the binpatch command to turn off synchronous transfers and to disable SCSI DMA. I have copied the patched kernel to "/". >-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 Thanks for the 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 Wed Sep 1 16:12:00 1993 Subject: Re: virtual memory and swapping To: madsen@cs.iastate.edu (Dave R. Madsen) 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: 3402 Sender: NetBSD-Admin@cbmuucp.commodore.com > >> 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. > > > > Okay, I now understand the difference between a swap filesystem and a "mfs" > filesystem. I have entered an entry in /etc/fstab for my swap partition as > follows: > > /dev/sd6b / swap sw 0 0 > > Now, however, after I do a "mount -av" and enter the command "swapon -a", > I get the error: > > swapon: /dev/sd6b: device not configured > > I am able to do a newfs on the /dev/sd6b partition, so I know that the > system is able to read/write the /dev/sd6b partition. Any ideas? > >> 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: Let me try to give you a hand. I have not poked around with the NetBSD swap stuff very much, however I am famillar with BSD4.2. First of all, the default swap partition is built into the kernel. You do not need to do the fstab stuff unless you want to use more than one device. If you want more than one swap device, then that must be built into the kernel too. Each swap partition must be entered into the machine description (config script) and the kernel must be recompiled. When the machine boots, only the first swap partition is used. You enable the others using `swapon -a'. The distributed kernels are `generic kernels' and use the generic kernel method to locate both root and swap partitions. This means both root and swap partitions can migrate between disks. If you want to use the /etc/fstab method of specifying your swap partition, I believe you must change to the hard method of specifying swap, which means reconfiguring the kernel. > > > >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. I have found that the distributed swapinfo does not work properly. I re-compiled it from sources from sun-lamp and now it works. However, the values I get for used swap space are suspiciously small. Does NetBSD only allocate swap for thuff that falls out of main memory, or for the whole process image? Does it swap code from swap or from the executable file? (I'm beginning to thing that 32MB swap was outrageous overkill.) To summarize, don't bother to put your swap partition in /etc/fstab. Just try to recompile swapinfo. I would also encourage you to have at least 2x main memory for swap space. ========================================================================= 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 Sep 2 10:54:17 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: trying to get NetBSD up on my A500 with G'Force 030 Sender: NetBSD-Admin@cbmuucp.commodore.com OOOPS ! Sorry, I've send this mail to the wrong address. =========== I have been unable to get netbsd up. All I get is a blank screen or a total hangup. My system is a modified A500, build into the Q Tower case. It has 4 ZORRO II slots, an MMU slot, videoslot and some PC slots. The 68030 board is the G'Force 030 Combo. 68030/68882 both running at 25 MHZ. At the bottom of this mail is the output from showconfig plus some extra info I added. any ideas welcome. Thanx in advance, John Vrolijk e-mail: etmjvro@etmsun.ericsson.se CHIPS: CPU 68030/68882fpu/68030mmu, ECS PAL Agnus, ECS Denise VERS: Kickstart version 37.175, Exec version 37.132, Disk version 37.67 RAM: Node type $a, attribute $205 (FAST), from $200000 to $5fffff Node type $a, attribute $5 (FAST), from $1000000 to $10fffff Node type $a, attribute $5 (FAST), from $800000 to $9fffff Node type $a, attribute $305 (FAST), from $c00000 to $d7ffff Node type $a, attribute $303 (CHIP), from $400 to $fffff BOARDS: RAM (unidentified): Prod=2017/9($7e1/$9) (@$200000 4meg Mem) ============================================================== This is the 4MB 32bit ram from the G'Force 030 Combo Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) ======================================================================== This is the Series II SCSI controller from the G'Force 030 Combo Board (unidentified): Prod=18260/4($4754/$4) (@$ea0000 64K) ============================================================= This is the VLAB framegrabber Board (unidentified): Prod=18260/6($4754/$6) (@$ec0000 128K) ============================================================== This is the RETINA graphics card Diskdrives: =========== Quantum LPS52 at unit 0 Quantum ELS85 at unit 1 Conner (203 MByes) at unit 6 The root partition for BSD is on the Conner drive I have ixemul.library 39.45. Where can I get 39.46 ? loadbsd complains about the revision. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 2 11:33:16 1993 Subject: Re: trying to get NetBSD up on my A500 with G'Force 030 To: etmjvro@etmsun.ericsson.se (John Vrolijk) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 753 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello! [stuff about problems setting up NetBSD deleted] Try to binconfig your kernel to remove synchronous transfert. Sometimes it helps, and especially for me ;-) > I have ixemul.library 39.45. Where can I get 39.46 ? > loadbsd complains about the revision. Don't worry about it. But you can get ixemul.library v39.47 on DaggeX distribution or on GCC-2.4.5 distribution. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 2 17:22:58 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: trying to get NetBSD up on my A500 with G'Force 030 Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 2, 11:32am, Philippe BRAND wrote: > Hello! > > [stuff about problems setting up NetBSD deleted] > > Try to binconfig your kernel to remove synchronous transfert. Sometimes > it helps, and especially for me ;-) It doesn't look like the problem would be the synchronous tranfer - that shouldn't cause any problems until NetBSD is attempting to configure the scsi devices. There should be some screen output prior to that point. 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 Sep 2 20:09:46 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: How to load rootfs on A3000 w/built-in SCSI controller? Sender: NetBSD-Admin@cbmuucp.commodore.com Howdy folks, I am trying to load the rootfs onto a 210MB Quantum on a A3000 tower that has the SCSI controller built into the motherboard; the machine is running AmigaDOS 2.04. I tried to use 'filetodev' as described in the INSTALL file to copy rootfs to the root partition, but, lo and behold, the scsi.device driver doesn't exist on my system because the SCSI controller is built-in. Duh..... Does anyone have a solution for this problem or have hints on alternate ways to load the rootfs? Thanks in advance and have five nice days... Irv Moy Internet: musashi@netcom.com ----------------------------------------------------------- | Insert clever comment -> HERE <- and mail | ----------------------------------------------------------- From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 2 22:22:24 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: How to load rootfs on A3000 w/built-in SCSI controller? Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 2, 11:10am, Irving Moy wrote: > I am trying to load the rootfs onto a 210MB Quantum on a A3000 tower > that has the SCSI controller built into the motherboard; the machine is > running AmigaDOS 2.04. I tried to use 'filetodev' as described in the > INSTALL file to copy rootfs to the root partition, but, lo and behold, > the scsi.device driver doesn't exist on my system because the SCSI > controller is built-in. Duh..... Does anyone have a solution for this The A3000 should have a scsi.device driver - that should be the device driver for the built-in SCSI controller. > problem or have hints on alternate ways to load the rootfs? You could try to use the dcp program (available at ftp.mtu.edu in the directory /pub/cdh). It's much easier to use. I had to set up a MountList entry for the partition and use the bffs file system handler to get dcp to access the partition. 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 Sep 2 22:38:19 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: How to load rootfs on A3000 w/built-in SCSI controller? Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 2, 11:10am, Irving Moy wrote: > running AmigaDOS 2.04. I tried to use 'filetodev' as described in the > INSTALL file to copy rootfs to the root partition, but, lo and behold, > the scsi.device driver doesn't exist on my system because the SCSI > controller is built-in. Duh..... Does anyone have a solution for this filetodev works great on a friends A3000T and on my A3000, which both have the 3091 on-board. filetodev 12345 16448 filename scsi.devive 6 1000 (of course with the correct entries!) does work fine. -- Markus Illenseer Full signature available on request. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 2 22:49:08 1993 Subject: Re: trying to get NetBSD up on my A500 with G'Force 030 To: etmjvro@etmsun.ericsson.se Cc: netbsd-amiga@cbmuucp.commodore.com X-Vms-To: IN%"etmjvro@etmsun.ericsson.se" 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 If your screen goes blank when the disk is accessed after the kernel is loaded, try turning off DMA transfers. Use binpatch on _scsi_no_dma. I think thats the right variable name. I had this problem on my A500 and Derringer030. I recompiled my loadbsd to use my 32-bit ram and didn't realize that my GVPA500HD couldn't DMA into that 32-bit ram. As soon as the kernel tried to start autobooting, after configuring the drives and such, I got a black screen and nothing else happened. I was about to give up until I found a message from Markus about the new #613 and the new debug variables in it. Hope this helps! P.S.: Anyone know how the support for memory zones is coming? I only have 4mb 32-bit ram and 8mb fast but can only use one at a time, and I prefer to have the kernel in 32-bit ram. From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 3 01:04:43 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: whoever's working on '040 FPU stuff... Sender: NetBSD-Admin@cbmuucp.commodore.com when you get the '040 FPU code from motorola, (if possible) please forward it to me as soon as possible... the hp300 port of NetBSD could use it, and i've volunteered to write an FPE for the mac port, so they could use it for '040 support, and i want to look at it, too... thanks much, chris From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 4 01:10:03 1993 Subject: #635 To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 935 Sender: NetBSD-Admin@cbmuucp.commodore.com Just uploaded a new kernel, which is almost exclusively the result of the famous Bielefeld party :-) Things changed: - the console opens with overscan, giving you some more displayable characters. - there is now a driver for the builtin parallel port. The current version only supports writing, not reading, but adding read support should not be that difficult, if someone actually needs that feature at all... - the disk driver sends a "start-unit" command to all units that identify as a "disk-like" drive. This should enable you to conditionally turn on drives only used for BSD. This feature is untested. I hope to upload next week a new set of binaries, as well as current sources, that's why there's no bsdsyssrc.635.gz on ftp.eunet.ch currently. -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 Sep 4 01:52:41 1993 Subject: sheesh.. To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 244 Sender: NetBSD-Admin@cbmuucp.commodore.com Forgot to tell you how to create /dev/par: mknod /dev/par c 11 0 sorry:-) -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 Sep 4 09:07:41 1993 Subject: Overscan on vmunix635. 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: 854 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi I was just wonderint if it was possible to change the overscan feature on the new vmunix. It cuts the Topline of my display completeley and the second line is only visible when I get the border of the screen into the visible field of the monitor, but then I have this awfull flickering of the first half of the top line :(. I do have a lot of space on the bottom of the screen, maybe the whole display could be shifted down by two lines? The mouse pointer needs some adjusting too, it sits somewhere in the middle of the screen (on the old top left hand side of the screen) and goes far to far to the right and to the bottom of the screen. btw. I'm very happy with the parallel port :) now I can print out all my stuff directly without going through Amiga Dos. Thanks a lot. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 4 12:39:56 1993 Subject: Re: Overscan on vmunix635. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1472 Sender: NetBSD-Admin@cbmuucp.commodore.com > I was just wonderint if it was possible to change the overscan > feature on the new vmunix. It cuts the Topline of my > display completeley and the second line is only visible when I > get the border of the screen into the visible field of the > monitor, but then I have this awfull flickering of the first > half of the top line :(. > I do have a lot of space on the bottom of the screen, maybe > the whole display could be shifted down by two lines? Well.. things *are* a little tricky to get those parameters right, the currently used ones have been determined in Bielefeld by a quite a bit of trial and error (ie. reboot after getting gibberish instead of a display...) The Right Thing to do would be to finally support the ioctl to set those values, similar to the one for the Retina console that sets the video-mode. > The mouse pointer needs some adjusting too, it sits somewhere in > the middle of the screen (on the old top left hand side of the screen) > and goes far to far to the right and to > the bottom of the screen. Mike.. care about fixing your pet?:-) > btw. I'm very happy with the parallel port :) now I can print out > all my stuff directly without going through Amiga Dos. Just tell me when/if you find bugs, I just did a ls -l > /dev/par to consider it working :-) -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 Sep 4 15:06:27 1993 Subject: Re: Overscan on vmunix635. To: mw@eunet.ch (Markus Wild) Cc: hoffmann@it.ntu.edu.au, 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: 1514 Sender: NetBSD-Admin@cbmuucp.commodore.com > > I was just wonderint if it was possible to change the overscan > > feature on the new vmunix. It cuts the Topline of my [...] > Well.. things *are* a little tricky to get those parameters right, > the currently used ones have been determined in Bielefeld by a > quite a bit of trial and error (ie. reboot after getting gibberish > instead of a display...) The Right Thing to do would be to finally > support the ioctl to set those values, similar to the one for the > Retina console that sets the video-mode. Could you turn off the overscan on the next kernel release? On my 1080 monitor I lose not only the top line, but the first column on the left and the bottom line. It makes using vi or emacs a nerve wracking experience. > > btw. I'm very happy with the parallel port :) now I can print out > > all my stuff directly without going through Amiga Dos. > Just tell me when/if you find bugs, I just did a ls -l > /dev/par to > consider it working :-) I finished modifying my printcap file when I discovered that there is no lpr. lpr is a directory of the lpr source, which won't compile because it requires some header files that are not present. And while you update the binaries, could you upload an executable dumpfont? I can't compile it because I only have the 1.3 includes. 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 Sat Sep 4 17:54:01 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Overscan on vmunix635. Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 4, 6:03am, Eduardo E. Horvath eeh@btr.com wrote: > > > I was just wonderint if it was possible to change the overscan > > > feature on the new vmunix. It cuts the Topline of my > [...] > > > Well.. things *are* a little tricky to get those parameters right, > > the currently used ones have been determined in Bielefeld by a > > quite a bit of trial and error (ie. reboot after getting gibberish > > instead of a display...) The Right Thing to do would be to finally > > support the ioctl to set those values, similar to the one for the > > Retina console that sets the video-mode. > > Could you turn off the overscan on the next kernel release? On my > 1080 monitor I lose not only the top line, but the first column on the > left and the bottom line. It makes using vi or emacs a nerve wracking > experience. Or maybe a flag that could be patched with binpatch? I haven't looked to closely at the display code to see if that could be done easily or not. 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 Sun Sep 5 01:08:21 1993 Subject: Re: Overscan on vmunix635. To: eeh@public.btr.com (Eduardo E. Horvath eeh@btr.com) Cc: mw@eunet.ch, hoffmann@it.ntu.edu.au, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Just tell me when/if you find bugs, I just did a ls -l > /dev/par to > > consider it working :-) > > I finished modifying my printcap file when I discovered that there is > no lpr. lpr is a directory of the lpr source, which won't compile > because it requires some header files that are not present. The lpr commands were some of the ones I relinked with the new ctime.o, and I don't remember having any particular trouble re-making it from the sources on sun-lamp.cs.berkeley.edu. Make sure /usr/include/sys is updated from your kernel source tree. (While you're at it, you can eliminate most of the headers in /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.3/include). I think you can safely junk the directory lpr in /usr/sbin. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 11:40:50 1993 Subject: Re: Overscan on vmunix635. To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Sep 4, 6:03am, Eduardo E. Horvath eeh@btr.com wrote: > > > > I was just wonderint if it was possible to change the overscan > > > > feature on the new vmunix. It cuts the Topline of my > > [...] > > > > > [...] > > > > Could you turn off the overscan on the next kernel release? On my > > 1080 monitor I lose not only the top line, but the first column on the > > left and the bottom line. It makes using vi or emacs a nerve wracking > > experience. > > Or maybe a flag that could be patched with binpatch? I haven't looked > to closely at the display code to see if that could be done easily or not. > > Michael > I second the motion! I hate having to adjust the monitor when switching between AmigaDOS and NetBSD. Fortunately I can still see the whole screen on my 1084S monito r. However, I am certain it will be unuseable on a 1080. Max Leung From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 11:52:51 1993 Subject: Problems with commands in vmunix635 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com After installing vmunix.635, with the scsi dma disabled (via _scsi_no_dma symbol set to one by binpatch), I encountered the following problems: The vmstat command no longer works, and returns an error, something about "bad time". The 'ps' command reports an 'Inf' in the %MEM column. The verion of ps I'm using was recompiled from the original sources at sun-lamp.cs.berkeley.edu from the NetBSD-0.9 source directory (NOT the NetBSD-current directory). The swapinfo command now displays a header, but no information. Of course, swapinfo never reported anything in the 613 kernel. :) Is there a fix to these problems? vmstat and ps worked fine in 613. Will I have to download and recompile the sources from the NetBSD-current directory at sun-lamp? Also, will I needed to recompile all the library files (and the programs that use them) so that they will work with the new kernel? Max Leung From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 12:06:31 1993 Subject: Recompiling Emacs, GCC, and NetBSD sources To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Seeing that someone has ported GCC2.4.3 and Emacs 19.11 to NetBSD for the Amiga, I would like to port the latest versions of these programs as well as the latest NetBSD sources. Unfortunately, I have no idea how to go about this, as both require amiga-specific headers and/or code, and nobody seems to have uploaded the diffs to an ftp site. :-( The missing headers also make it difficult to port some of the programs in the NetBSD sources, particularly the libraries. For example, how am I suppose to compile crt0.o? I can't use the hp300 code, can I? (I tried it with emacs, but it didn't work). Obviously, someone has gotten them to work, so why should I reinvent the wheel? ;-) Could someone please post the needed files? I'm quite desperate to get a consistent NetBSD system running with the latest UNIX doodads, instead of this hodgepodge system that I have now. :-) Max Leung (enquiring minds want to know!) From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 13:08:00 1993 Subject: Re: Problems with commands in vmunix635 To: max@amisk.cs.ualberta.ca (Leung Max) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 692 Sender: NetBSD-Admin@cbmuucp.commodore.com > The vmstat command no longer works, and returns an error, something > about "bad time". > > The 'ps' command reports an 'Inf' in the %MEM column. The verion of ps > I'm using was recompiled from the original sources at > sun-lamp.cs.berkeley.edu from the NetBSD-0.9 source directory (NOT the > NetBSD-current directory). Huh.. you did update /vmunix when you changed kernels? > Also, will I needed to recompile all the library files (and the > programs that use them) so that they will work with the new kernel? Nope:-) -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 Sep 5 17:27:38 1993 Subject: problems booting with vmunix.635 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 995 Sender: NetBSD-Admin@cbmuucp.commodore.com The overscan looks fine on my A3000 using a Sony CPD-1320 monitor, however I only get to see about 3/4 of the screen fill up before I run into other problems. I have not been able to get 635 to boot on my machine. It starts up, then asks me for my root device (my root partition is sd1a). I responded with sd1, sd1a, sd and just about anything else I could think of. Each time I get something like "invalid device number" or something telling me to enter "sd%d" which I took to mean sd then the scsi device number. vmunix.613 still boots fine, so I don't think anything is wrong with my rootfs. Is sd1 no longer a good choice for my root partition to be on? Is there a way to binpatch it so that it is a good choice? Those jumpers are not in a very convienient place, so I would prefer a software solution. An unrelated piece of info, I bought a used HP35450 tape drive (1.3 Gig DAT drive) which seems to work fine with NetBSD and amigados. I had to binpatch _scsi_no_dma to get it to work. From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 18:50:18 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Recompiling Emacs, GCC, and NetBSD sources Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 5, 4:06am, Leung Max wrote: > Subject: Recompiling Emacs, GCC, and NetBSD sources > Seeing that someone has ported GCC2.4.3 and Emacs 19.11 to NetBSD for > the Amiga, I would like to port the latest versions of these programs > as well as the latest NetBSD sources. $ telnet tiger [...] Copyright (c) 1980,1983,1986,1988,1990,1991 The Regents of the University of California. All rights reserved. - tiger - Amiga 3000 running NetBSD. markus@tiger(1)$ gcc -v hello.c Reading specs from /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.5/specs gcc version 2.4.5 /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.5/cpp -lang-c -v -undef -D__GNUC__=2 -Dmc68000 -Dmc68020 -Damiga -Dunix -DNETBSD -DBSD_NET2 -D__mc68000__ -D__mc68020__ -D__amiga__ -D__unix__ -D__NETBSD__ -D__BSD_NET2__ -D__mc68000 -D__mc68020 -D__amiga -D__unix -D__NETBSD -D__BSD_NET2 -D__HAVE_68881__ -D__HAVE_FPU__ hello.c /var/tmp/cc007205.i GNU CPP version 2.4.5 (68k, MIT syntax) /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.5/cc1 /var/tmp/cc007205.i -quiet -dumpbase hello.c -version -o /var/tmp/cc007205.s GNU C version 2.4.5 (68k, MIT syntax) compiled by GNU C version 2.4.5. as -o /var/tmp/cc0072051.o /var/tmp/cc007205.s ld /usr/lib/crt0.o -L/usr/gnu/lib/gcc-lib/netbsdamiga/2.4.5 -L/usr/gnu/lib /var/tmp/cc0072051.o -lgcc -lc -lgcc markus@tiger(2)$ a.out hello! markus@tiger(3)$ exit Sorry, but gcc 2.4.5 has been ported to NetBSD already :-) Or do you mean port it to AmigaOS ? There are some efforts to do that already. (And as for Emacs: ln -s /usr/gnu/bin/emacs /usr/bin/vi *sorry, couldn't resist :-) -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 5 23:46:15 1993 Subject: Re: Problems with commands in vmunix635 To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > > The vmstat command no longer works, and returns an error, something > > about "bad time". > > > > The 'ps' command reports an 'Inf' in the %MEM column. The verion of ps > > I'm using was recompiled from the original sources at > > sun-lamp.cs.berkeley.edu from the NetBSD-0.9 source directory (NOT the > > NetBSD-current directory). > > Huh.. you did update /vmunix when you changed kernels? Ooops. :-) Should've thought of that. Thanks! > > > Also, will I needed to recompile all the library files (and the > > programs that use them) so that they will work with the new kernel? > > Nope:-) Okeydoke. > > -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 Sep 6 08:36:11 1993 Subject: A3070 tape drive To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga Mailing List) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com It's been tape drive weekend here at hack central. I've had two problems using my A3070 drive with NetBSD -- the first is that I couldn't work with multiple files on a single tape. Every command after doing a 'mt -f /dev/nrst0 fsf 1' resulted in an error. That kinda sucks. The problem appears to be that the SCSI tape driver (.../amiga/dev/st.c) will send a mode-select command to the driver every time you open the device and the Caliper CP150 (what's inside the A3070) doesn't like that very much. It only seems to take mode-select when the tape is fully rewound. (The mode-select chooses between 120M and 150M operation, and probably does some other stuff, too). Here are the patches I used (613 source base). The second problem is described after this: ------------------------------------------------------------------------ *** arch/amiga/dev/st.c-orig Thu Aug 12 14:49:01 1993 --- arch/amiga/dev/st.c Sun Sep 5 21:48:40 1993 *************** *** 111,117 **** extern int sterror (int unit, struct st_softc *sc, int stat); extern int stxsense (int ctlr, int slave, int unit, struct st_softc *sc); extern int prtkey (int unit, struct st_softc *sc); ! extern int dumpxsense (struct st_xsense *sensebuf); extern int prtmodsel (struct mode_select_data *msd, int modlen); extern int prtmodstat (struct mode_sense *mode); --- 111,117 ---- extern int sterror (int unit, struct st_softc *sc, int stat); extern int stxsense (int ctlr, int slave, int unit, struct st_softc *sc); extern int prtkey (int unit, struct st_softc *sc); ! extern int dumpxsense (struct st_xsense *sensebuf, struct st_softc *sc); extern int prtmodsel (struct mode_select_data *msd, int modlen); extern int prtmodstat (struct mode_sense *mode); *************** *** 156,163 **** */ static struct st_xsense { struct scsi_xsense sc_xsense; /* data from sense */ ! struct exb_xsense exb_xsense; /* additional info from exabyte */ } st_xsense[NST]; static struct scsi_fmt_cdb stcmd[NST]; --- 156,168 ---- */ static struct st_xsense { struct scsi_xsense sc_xsense; /* data from sense */ ! union { ! struct exb_xsense uexb_xsense; /* additional info from exabyte */ ! struct cpr_xsense ucpr_xsense; /* additional info from caliper */ ! } u; } st_xsense[NST]; + #define exb_xsense u.uexb_xsense + #define cpr_xsense u.ucpr_xsense static struct scsi_fmt_cdb stcmd[NST]; *************** *** 316,325 **** if (idstr[i] != ' ') break; idstr[i+1] = 0; ! printf("st%d: %s >%s< rev %s\n", ad->amiga_unit, idstr, &idstr[8], &idstr[24]); } else if (inqlen == 5) ! /* great it's a stupid device, doesn't know it's know name */ idstr[0] = idstr[8] = '\0'; else idstr[8] = '\0'; --- 321,330 ---- if (idstr[i] != ' ') break; idstr[i+1] = 0; ! printf("st%d: %s %s rev %s\n", ad->amiga_unit, idstr, &idstr[8], &idstr[24]); } else if (inqlen == 5) ! /* great it's a stupid device, doesn't know it's own name */ idstr[0] = idstr[8] = '\0'; else idstr[8] = '\0'; *************** *** 362,367 **** --- 367,378 ---- sc->sc_datalen[CMD_INQUIRY] = 36; sc->sc_datalen[CMD_MODE_SELECT] = 12; sc->sc_datalen[CMD_MODE_SENSE] = 12; + } else if (bcmp("CP150", &idstr[8], 5) == 0) { + sc->sc_tapeid = MT_ISCALIPER; + sc->sc_datalen[CMD_REQUEST_SENSE] = 14; + sc->sc_datalen[CMD_INQUIRY] = 36; + sc->sc_datalen[CMD_MODE_SELECT] = 12; + sc->sc_datalen[CMD_MODE_SENSE] = 12; } else { if (idstr[8] == '\0') printf("st%d: No ID, assuming Archive\n", ad->amiga_unit); *************** *** 414,419 **** --- 425,431 ---- struct mode_select_data msd; struct mode_sense mode; int modlen; + int skip_modsel = 0; static struct scsi_fmt_cdb modsel = { 6, CMD_MODE_SELECT, 0, 0, 0, sizeof(msd), 0 *************** *** 471,476 **** --- 483,497 ---- sc->sc_blklen = 512; break; #endif + case MT_ISCALIPER: + sc->sc_blklen = 512; + stxsense(ctlr, slave, unit, sc); + /* Calipers can't handle a mode-select if the tape + * isn't rewound. + */ + if (xsense->cpr_xsense.b11) + skip_modsel = 1; + break; case MT_ISWANGTEK: sc->sc_blklen = 512; break; *************** *** 485,490 **** --- 506,514 ---- sc->sc_blklen = 512; } + if (skip_modsel) + goto mode_selected; + /* setup for mode select */ msd.rsvd1 = 0; msd.rsvd2 = 0; *************** *** 513,518 **** --- 537,543 ---- msd.density = 0x4; } break; + case MT_ISCALIPER: case MT_ISWANGTEK: if (minor (dev) & STDEV_HIDENSITY) msd.density = 0x10; *************** *** 586,591 **** --- 611,617 ---- goto retryselect; } + mode_selected: /* drive ready ? */ stat = scsi_test_unit_rdy(ctlr, slave, unit); *************** *** 622,627 **** --- 648,654 ---- case MT_ISHPDAT: case MT_ISVIPER1: case MT_ISPYTHON: + case MT_ISCALIPER: case MT_ISWANGTEK: if (xsense->sc_xsense.key == XSK_UNTATTEN) stat = scsi_test_unit_rdy(ctlr, slave, unit); *************** *** 654,660 **** stxsense(ctlr, slave, unit, sc); #ifdef DEBUG if (st_debug & ST_OPEN) ! dumpxsense(xsense); #endif } if (stat) --- 681,687 ---- stxsense(ctlr, slave, unit, sc); #ifdef DEBUG if (st_debug & ST_OPEN) ! dumpxsense(xsense, sc); #endif } if (stat) *************** *** 1387,1394 **** #ifdef DEBUG ! dumpxsense(sensebuf) struct st_xsense *sensebuf; { struct st_xsense *xp = sensebuf; --- 1414,1422 ---- #ifdef DEBUG ! dumpxsense(sensebuf, sc) struct st_xsense *sensebuf; + struct st_softc *sc; { struct st_xsense *xp = sensebuf; *************** *** 1404,1432 **** (xp->sc_xsense.info3<<8)|(xp->sc_xsense.info4)) ); printf("ASenseL 0x%x\n", xp->sc_xsense.len); ! if (xp->sc_xsense.len != 0x12) /* MT_ISEXB Exabyte only ?? */ ! return; /* What about others */ ! printf("ASenseC 0x%x\n", xp->exb_xsense.addsens); ! printf("AsenseQ 0x%x\n", xp->exb_xsense.addsensq); ! printf("R/W Errors 0x%lx\n", ! (u_long)((xp->exb_xsense.rwerrcnt2<<16)| ! (xp->exb_xsense.rwerrcnt1<<8)| ! (xp->exb_xsense.rwerrcnt1)) ); ! printf("PF 0x%x BPE 0x%x FPE 0x%x ME 0x%x ECO 0x%x TME 0x%x TNP 0x%x BOT 0x%x\n", ! xp->exb_xsense.pf, xp->exb_xsense.bpe, xp->exb_xsense.fpe, ! xp->exb_xsense.me, xp->exb_xsense.eco, xp->exb_xsense.tme, ! xp->exb_xsense.tnp, xp->exb_xsense.bot); ! printf("XFR 0x%x TMD 0x%x WP 0x%x FMKE 0x%x URE 0x%x WE1 0x%x SSE 0x%x FE 0x%x\n", ! xp->exb_xsense.xfr, xp->exb_xsense.tmd, xp->exb_xsense.wp, ! xp->exb_xsense.fmke, xp->exb_xsense.ure, xp->exb_xsense.we1, ! xp->exb_xsense.sse, xp->exb_xsense.fe); ! printf("WSEB 0x%x WSEO 0x%x\n", ! xp->exb_xsense.wseb, xp->exb_xsense.wseo); ! printf("Remaining Tape 0x%lx\n", ! (u_long)((xp->exb_xsense.tplft2<<16)| ! (xp->exb_xsense.tplft1<<8)| ! (xp->exb_xsense.tplft0)) ); } prtmodsel(msd, modlen) --- 1432,1474 ---- (xp->sc_xsense.info3<<8)|(xp->sc_xsense.info4)) ); printf("ASenseL 0x%x\n", xp->sc_xsense.len); ! switch (sc->sc_tapeid) { ! case MT_ISEXABYTE: ! printf("ASenseC 0x%x\n", xp->exb_xsense.addsens); ! printf("AsenseQ 0x%x\n", xp->exb_xsense.addsensq); ! printf("R/W Errors 0x%lx\n", ! (u_long)((xp->exb_xsense.rwerrcnt2<<16)| ! (xp->exb_xsense.rwerrcnt1<<8)| ! (xp->exb_xsense.rwerrcnt1)) ); ! printf("PF 0x%x BPE 0x%x FPE 0x%x ME 0x%x ECO 0x%x TME 0x%x TNP 0x%x BOT 0x%x\n", ! xp->exb_xsense.pf, xp->exb_xsense.bpe, ! xp->exb_xsense.fpe, xp->exb_xsense.me, ! xp->exb_xsense.eco, xp->exb_xsense.tme, ! xp->exb_xsense.tnp, xp->exb_xsense.bot); ! printf("XFR 0x%x TMD 0x%x WP 0x%x FMKE 0x%x URE 0x%x WE1 0x%x SSE 0x%x FE 0x%x\n", ! xp->exb_xsense.xfr, xp->exb_xsense.tmd, ! xp->exb_xsense.wp, xp->exb_xsense.fmke, ! xp->exb_xsense.ure, xp->exb_xsense.we1, ! xp->exb_xsense.sse, xp->exb_xsense.fe); ! printf("WSEB 0x%x WSEO 0x%x\n", ! xp->exb_xsense.wseb, xp->exb_xsense.wseo); ! printf("Remaining Tape 0x%lx\n", ! (u_long)((xp->exb_xsense.tplft2<<16)| ! (xp->exb_xsense.tplft1<<8)| ! (xp->exb_xsense.tplft0)) ); ! break; ! ! case MT_ISCALIPER: ! printf("b8 0x%x (wp 0x%x) b9 0x%x b10 0x%x b11 0x%x b12 0x%x b13 0x%x\n", ! xp->cpr_xsense.b8, xp->cpr_xsense.b8 & CPR_WP, ! xp->cpr_xsense.b9, xp->cpr_xsense.b10, ! xp->cpr_xsense.b11, xp->cpr_xsense.b12, ! xp->cpr_xsense.b13); ! break; ! default: ! break; ! } } prtmodsel(msd, modlen) *** arch/amiga/dev/stvar.h-orig Sat May 15 06:45:00 1993 --- arch/amiga/dev/stvar.h Sun Sep 5 00:05:41 1993 *************** *** 101,106 **** --- 101,116 ---- char venderunique[16]; }; + struct cpr_xsense { + u_char b8; + #define CPR_WP 0x10 + u_char b9; + u_char b10; + u_char b11; + u_char b12; + u_char b13; + }; + struct st_mode { u_char sdl; u_char medtype; *** sys/mtio.h-orig Sat Jun 19 09:45:39 1993 --- sys/mtio.h Sat Sep 4 16:42:02 1993 *************** *** 96,101 **** --- 96,102 ---- #define MT_ISPYTHON 0x0f /* Archive Python (DAT) */ #define MT_ISHPDAT 0x10 /* HP 35450A DAT drive */ #define MT_ISWANGTEK 0x11 /* WANGTEK 5150ES */ + #define MT_ISCALIPER 0x12 /* Caliper CP150 */ /* mag tape io control commands */ #define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */ ------------------------------------------------------------------------ The other problem I had was that a tape error would crash the kernel -- woo hoo! My specific test case was putting a fresh tape in the drive and doing a 'mt -f /dev/rst0 fsf 1'. The problem goes something like this: When an I/O operation is done and hasn't failed early because something like a mode-select failed, the tape driver calls stfinish(), which then calls biodone() on the I/O buffer which was being used for the I/O operation. biodone() wakes up anyone who was waiting on the buffer; someone (probably the tape driver but I haven't checked) is stuck in biowait() sleeping on that buffer. biowait() wakes up, looks at the buffer, sees that its error flag is set, and proceeds to remove it from its hash queue and put it somewhere else. Unfortunately, that buffer was never on a hash queue -- it was an element in an array of buffers defined inside st.c. Wa ha ha ha! What a good joke! The b_back and b_forw pointers are 0! Here's what I did to fix that: ------------------------------------------------------------------------ *** kern/vfs_bio.c-orig Sun Aug 8 05:47:13 1993 --- kern/vfs_bio.c Sun Sep 5 21:48:07 1993 *************** *** 653,660 **** * and i believe it's wrong to let bp->b_error override B_ERROR * but it certainly appears to work OK this way... */ ! bremhash(bp); ! binshash(bp, bfreelist + BQ_AGE); } if (!bp->b_error) bp->b_error = EIO; --- 653,663 ---- * and i believe it's wrong to let bp->b_error override B_ERROR * but it certainly appears to work OK this way... */ ! /* Some bufs aren't in the buffer cache, you fool. */ ! if (bp->b_back && bp->b_forw) { ! bremhash(bp); ! binshash(bp, bfreelist + BQ_AGE); ! } } if (!bp->b_error) bp->b_error = EIO; ------------------------------------------------------------------------ -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 6 11:12:41 1993 Subject: Re: problems booting with vmunix.635 To: netbsd-amiga@cbmuucp.commodore.com Cc: mw@eunet.ch Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: NetBSD-Admin@cbmuucp.commodore.com On Sun, 5 Sep 1993, Howard Dobson wrote: > I have not been able to get 635 to boot on my machine. It starts up, > then asks me for my root device (my root partition is sd1a). I responded > with sd1, sd1a, sd and just about anything else I could think of. > Each time I get something like "invalid device number" or something telling > me to enter "sd%d" which I took to mean sd then the scsi device number. > vmunix.613 still boots fine, so I don't think anything is wrong with my > rootfs. I'm having this same exact problem myself. It comes up asking for a root device. No matter what I give it, it will not boot from it. Eventually, it will just dump and then reboot the system. Kernel 613 works, however. I'm not sure what this problem is related to, however. My HD is a 1.2 gig Toshiba HD. Perhaps something about what kinds of drives it likes and doesn't like has changed? > Is sd1 no longer a good choice for my root partition to be on? > Is there a way to binpatch it so that it is a good choice? Those > jumpers are not in a very convienient place, so I would prefer a > software solution. I don't think it has anything to do with which is the root partition (or where it is). My boot partition is on unit 6, for example. It looks to me like we're missing some vital piece of information for installing this kernel. Has the Identifier for the HD changed? -- Brian Wright /// /// ONLY Amiga wright@merlin.etsu.edu \\\ /// makes it possible! wright%merlin.etsu.edu@ricevm1.rice.edu \\X// ETSU HPUX Systems Administrator From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 6 11:38:46 1993 Subject: Re: problems booting with vmunix.635 To: wright@merlin.etsu.edu (Brian C. Wright) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1294 Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Sun, 5 Sep 1993, Howard Dobson wrote: > > > I have not been able to get 635 to boot on my machine. It starts up, > > then asks me for my root device (my root partition is sd1a). I responded > > with sd1, sd1a, sd and just about anything else I could think of. > > Each time I get something like "invalid device number" or something telling > > me to enter "sd%d" which I took to mean sd then the scsi device number. > > vmunix.613 still boots fine, so I don't think anything is wrong with my > > rootfs. > > I'm having this same exact problem myself. It comes up asking for a root > device. No matter what I give it, it will not boot from it. Eventually, > it will just dump and then reboot the system. Kernel 613 works, however. You're probably using the old loadbsd loader. 635 includes the new autoboot code, which is enabled with the -a flag to the new loadbsd which was posted here a while ago. If you use the old starter, d7 will contain a random value, which might have the ASK bit set, so the kernel asks you for a rootfs (which seems broken, too ;-)). So, use the new loadbsd, and you should be 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 Mon Sep 6 18:42:25 1993 Subject: Re: problems booting with vmunix.635 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 707 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > I have not been able to get 635 to boot on my machine. It starts up, > > > then asks me for my root device (my root partition is sd1a). I responded > > > with sd1, sd1a, sd and just about anything else I could think of. > > You're probably using the old loadbsd loader. 635 includes the new > autoboot code, which is enabled with the -a flag to the new loadbsd > which was posted here a while ago. If you use the old starter, d7 will > contain a random value, which might have the ASK bit set, so the kernel > asks you for a rootfs (which seems broken, too ;-)). So, use the new > loadbsd, and you should be fine. > > -Markus Your right once again Markus, I now have 635 running. thanks Howard From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 7 08:02:23 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: NetBSD still doesn't work on my G'Force 030 Sender: NetBSD-Admin@cbmuucp.commodore.com I have tried to get BSD running with several different kernels ( all versions that I could download ) but so far none of them have worked for me. The latest one I tried is 635. After I type loadbsd vmunux.635, it says "using 4MB FASTRAM at $200000, 1 MB CHIP" and then it hangs. No messages or anything. I patched the debug variables but still it just hangs, and no debug messages or anything. So, I downloaded the source for vmunux.613 (bsdsyssrc.613.tar) and tried to recompile. Config AMIGA works, but the make fails. In the makefile.amiga, the %OBJS is still there. I tried the make that comes with gcc-2.3.3 and another one but both fail. Is there something more I need to recompile the kernel ? My machine is a modified A500 with the G'Force 030 Combo. Does anybody have suggestions/ideas ? I would like to get BSD up and running. CHIPS: CPU 68030/68882fpu/68030mmu, ECS PAL Agnus, ECS Denise VERS: Kickstart version 37.175, Exec version 37.132, Disk version 37.67 RAM: Node type $a, attribute $205 (FAST), from $200000 to $5fffff Node type $a, attribute $5 (FAST), from $1000000 to $10fffff Node type $a, attribute $5 (FAST), from $800000 to $9fffff Node type $a, attribute $305 (FAST), from $c00000 to $d7ffff Node type $a, attribute $303 (CHIP), from $400 to $fffff BOARDS: RAM (unidentified): Prod=2017/9($7e1/$9) (@$200000 4meg Mem) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) Board (unidentified): Prod=18260/4($4754/$4) (@$ea0000 64K) Board (unidentified): Prod=18260/6($4754/$6) (@$ec0000 128K) Diskdrives: Quantum LPS52 at unit 0 Quantum ELS85 at unit 1 Conner (203 MByes) at unit 6 (rootfs is here) Output from showconfig: From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 7 09:19:30 1993 Subject: Re: A3070 tape drive To: ahh@netcom.com (Andy Heffernan) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 904 Sender: NetBSD-Admin@cbmuucp.commodore.com > It's been tape drive weekend here at hack central. > > I've had two problems using my A3070 drive with NetBSD -- the > first is that I couldn't work with multiple files on a single tape. > Every command after doing a 'mt -f /dev/nrst0 fsf 1' resulted in an > error. That kinda sucks. The problem appears to be that the SCSI tape You bet.. *GREAT* you found the bug, I cursed my Wangtek streamer multiple times for giving me I/O errors, where the Archive Phython had no similar problems... About the buffer-cache thing: phew.. finally a good fix for the problem, I once had code in there to test the range of the buffer, whether it was in buffer_map, to perform the rehashing. Testing the link fields is *much* smarter, terrific! -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 Sep 7 17:04:31 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Mousepointer Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, i've been trying to fix the Bugs in the mousepointer-routines in dev/grf_cc.c The problem starts in the SPRITEPTR-structure. Can anybody give me a hint what the 'header' is for ? Intui-Docs are rather useless in this point. I need the Hot-Spot and the size of the sprite. BTW, can we use a colored sprite ? Then the two lines where the horizontal and vertical position of the mousepointer are checked looked false to me: if (ccfb.mouseX < 0) ccfb.mouseX = 0; if (ccfb.mouseX > ccfb.fb_width-1) ccfb.mouseX = ccfb.fb_width-1; I changed them to: if (ccfb.mouseX < -64) ccfb.mouseX = -64; if (ccfb.mouseX > ccfb.disp_width-64) ccfb.mouseX = ccfb.disp_width-64; (I use disp_width, because fb_width is set to 1024 !) But as you might see, the value '-64' is guessed by trial-and-error. Problem: We need a forumla which calculates the Hot-Spot of the Mousepointer (-> needs knowledge of the size, too) and gives the new Zero-Point when Overscan is used. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 8 20:00:09 1993 Subject: loadbsd To: NetBSD-Amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 661 Sender: NetBSD-Admin@cbmuucp.commodore.com Could someone please put the most recent version of loadbsd on an ftp site for me? I do not have the tools to compile it under Amiga Dos and compiling it under Unix wouldn't do me much good.... 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 Wed Sep 8 20:24:18 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Help!!! Sender: NetBSD-Admin@cbmuucp.commodore.com Hello, I was hoping someone could help me with a problem. I have been trying to get the port of NetBSD for the amiga working on my A3000, and am running into a few problems. 1. I can't use newfs on any of the drives on my system. one of the drives is the original Quantum that came with the sys, and the other is a Western Digital Piranha 4200 (on loan from my office). Everytime I do newfs, it gives me the following: newfs: ioctl (WDINFO): Invalid Argument newfs: /dev/rsd0e: can't rewrite disk label I thought I remember reading something that said that the scsi device driver was unable to update the disk label on the disk, and that it had to be done from the amigados side. I was unaware that newfs had to update the disklabel thought. The only thing I could think of was that it as attempting to write out the Super-Block for the filesystem, and failing. I checked the device, and there is no superblock at the front of it. In fact, even though newfs outputs all the locations of the backup super blocks, none of them look like they are super blocks, and fsck agrees with me on this point. 2. My second problem, is that I can't seem to get any version of vmunix after 335 to work at all. I only have 450, and 613, but both of them just hang, the minute they set the scsi device to synchronous mode. If you have time to give me any help, I would very much appreciate it. Also, I would like to set up a development environment for working on the kernel, and the other parts of the os. What i need is pointers on what kind of development environment you are using. I have gcc, and many of the other gnu utils on my amiga already. I guess what i need, is the source for the kernel, and the source for the os utilities. In addition, I would need to know what make facility it uses, and anything else I may need. Also, If it is possible, I have a lot of room at work to play in, and if I could set up a cross development environment, that would be even better. again, any help at all would be VERY APPRECIATED. thankyou, Bill Costello From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 8 21:51:00 1993 Subject: Re: Help!!! To: bill@softint.com Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 822 Sender: NetBSD-Admin@cbmuucp.commodore.com > newfs: ioctl (WDINFO): Invalid Argument > newfs: /dev/rsd0e: can't rewrite disk label This is ok, writing disklabels from the BSD side is not possible at the moment, because those disklabels are synthesized from information gathered from the disk RDB, the labels don't really exist on disk. > 2. My second problem, is that I can't seem to get any version of vmunix > after 335 to work at all. I only have 450, and 613, but both of them > just hang, the minute they set the scsi device to synchronous mode. So set them to non-sync mode, set the respective byte in _inhibit_sync[] as was mentioned various times on this list. -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 Sep 9 04:34:32 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Status Report. Sender: NetBSD-Admin@cbmuucp.commodore.com I'd like a status report from all of the splinter groups working on NetBSD-Amiga. What defines a splinter group? * - Person(s) taking on a specific portion of a currently unsupported function. example: 040, SCSI controllers, video cards, other 3rd party peripherals. * - Anything that is not currently incorporated into the main sources kept by Markus. This will suffice, and can be either emailed, or thrown on the mail list. ----------- Who: Joe Blow and John Doe What: 68060 MMU support When: ~2 months Where: private, not integrated into main source tree yet. ----------- This will help identify areas that are still needing to be worked on, and eliminate as much overlap as possible. THANKS FOR YOUR HELP. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 9 06:35:52 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Help!!! Sender: NetBSD-Admin@cbmuucp.commodore.com > So set them to non-sync mode, set the respective byte in _inhibit_sync[] > as was mentioned various times on this list. sorry to be a bother again, but I just got on the list, I don't have any information on _inhibit_sync[], and I didn't see any info at the ftp site about it. Is there an archive of the mailing list? If not could someone send me a message that contains the necessary info. thankyou. bill. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 9 10:02:37 1993 To: billc@icecube.rain.com Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Status Report. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Bill" == William J. Coldwell writes: Bill> I'd like a status report from all of the splinter groups working Bill> on NetBSD-Amiga. What: Non BSD partitions & prototype readonly AmigaDOS filesystem Who: Niklas Hallqvist When: RSN, ASAP or something like tomorrow, this weekend or next week, all depending on when I find what seems to be a memory leak in my FS. The kernel will run slower and slower and then crash when doing a find . -print on my 10000+ file AmigaDOS disk, after several thousand names have been printed. Where: Private. Next: Major rewrite of the FS code and read/write capabilities. Will probably take another month or two. 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 Sep 9 18:15:09 1993 Subject: Re: Help!!! To: bill@softint.com Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > my office). Everytime I do newfs, it gives me the following: > > newfs: ioctl (WDINFO): Invalid Argument > newfs: /dev/rsd0e: can't rewrite disk label As Markus has already mentioned, if you try and work with the file system, you'll find that it's there and all ready to go. > 2. My second problem, is that I can't seem to get any version of vmunix > after 335 to work at all. I only have 450, and 613, but both of them > just hang, the minute they set the scsi device to synchronous mode. Start with the 613 kernel, get a copy of the binpatch program and the README.binpatch file. Use binpatch to find and initialize the _inhibit_sync array. Its format is like this: device 0 1 2 3 4 5 6 7 SCSI 3000 . . . . . . . . controller other . . . . . . . . other . . . . . . . . Where each '.' is a byte (I forget the names and order of the other 2 SCSI controllers which are supported). These bytes are initialized to 0 in the kernel image; set the right byte to 1 to disable sync negotiation for a particular device. > Also, I would like to set up a development environment for working on the > kernel, and the other parts of the os. What i need is pointers on what I think you will be much happier doing development under BSD. The kernel source, along with the other stuff I mentioned is on ftp.eunet.ch, under software/os/bsd/NetBSD/NetBSD-Amiga. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 9 20:28:25 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Status Report. Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 6, 12:13am, William J. Coldwell wrote: >* - Anything that is not currently incorporated into the main sources kept by >Markus. Which Markus ? :-) I still keep having Mails which are intended to be addressed to Markus Wild, please do always mention his Family-Name or use his nickname 'mtk'. > This will suffice, and can be either emailed, or thrown on the mail list. > ----------- > Who: Markus Illenseer > What: MIT X11 source tree compiling, first tries to write X11 Server for ECS > When: No idea. > Where: private, not integrated into main source tree yet. > ----------- -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 11:15:59 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Compiling vmunix.613 Sender: NetBSD-Admin@cbmuucp.commodore.com I've tried to compile vmunix.613 but didn't succeed. gcc kept complaining about 'no input files specified'. After some time, I found out that the makefile in /sys/arch/amiga/compile/AMIGA was wrong. It had the characters $< in it. After going through the man page for make I found that this should be $>. Is this a problem with config ?? I did the following: cd /sys/arch/amiga/conf edit the AMIGA config file then execute config AMIGA cd /sys/arch/amiga/compile/AMIGA make It seems that the compiling stage went ok now. However, in the makefile /bin/sh is also used. Can I use pdksh for this ??? I was wondering about the config file AMIGA. It has some options for scsi controllers in it. For the gvp controller it says: master gvp11scsi0 at manufacturer 2017 product 11 Is this correct ?? I have no idea what should be in there. Since none of the kernels booted, I decided to compile the source for vmunix.613. Is the above line correct for the G'Force Combo ? Or should it be something like master gvpscsi0 at manufacturer 2017 product 11 All ideas welcome Thanx. John Vrolijk From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 12:13:39 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Yet another tape drive supported... Sender: NetBSD-Admin@cbmuucp.commodore.com I just bought a cheap Wangtek 5099 drive (yes, it's only 60 MB but the price was 700 SEK (~$90) and it was brand new). I got no docs but testing showed that msd.density set to zero would make it work out of the box. How about having a binpatchable default msd.density setting for both normal and STDEV_HIDENSITY uses of unrecognized drives? That way, we would not always need to add specific tape drive support in st.c, yet have the opportunity to use special densities of the drive. Yes, I know certain tape drives *needs* special treatment anyway, but many un- supported tape drives would work with no recompilation. This is just a suggestion, I do not need such funtionality anymore as I've recompiled my kernel with this patch (relative to 613): *** sys/sys/mtio.h.613 Thu Sep 9 22:11:08 1993 --- sys/sys/mtio.h Thu Sep 9 22:10:51 1993 *************** *** 96,101 **** --- 96,102 ---- #define MT_ISPYTHON 0x0f /* Archive Python (DAT) */ #define MT_ISHPDAT 0x10 /* HP 35450A DAT drive */ #define MT_ISWANGTEK 0x11 /* WANGTEK 5150ES */ + #define MT_ISWANGTEK5099 0x12 /* WANGTEK 5099ES */ /* mag tape io control commands */ #define MTIOCTOP _IOW('m', 1, struct mtop) /* do a mag tape op */ *** sys/arch/amiga/dev/st.c.613 Thu Aug 12 21:49:15 1993 --- sys/arch/amiga/dev/st.c Thu Sep 9 22:26:17 1993 *************** *** 362,367 **** --- 362,373 ---- sc->sc_datalen[CMD_INQUIRY] = 36; sc->sc_datalen[CMD_MODE_SELECT] = 12; sc->sc_datalen[CMD_MODE_SENSE] = 12; + } else if (bcmp("5099ES", &idstr[8], 6) == 0) { + sc->sc_tapeid = MT_ISWANGTEK5099; + sc->sc_datalen[CMD_REQUEST_SENSE] = 14; + sc->sc_datalen[CMD_INQUIRY] = 36; + sc->sc_datalen[CMD_MODE_SELECT] = 12; + sc->sc_datalen[CMD_MODE_SENSE] = 12; } else { if (idstr[8] == '\0') printf("st%d: No ID, assuming Archive\n", ad->amiga_unit); *************** *** 451,459 **** /* set record length */ switch (sc->sc_tapeid) { - case MT_ISAR: - sc->sc_blklen = 512; - break; case MT_ISEXABYTE: if (minor(dev) & STDEV_FIXEDBLK) sc->sc_blklen = 0x400; --- 457,462 ---- *************** *** 460,477 **** else sc->sc_blklen = st_exblklen; break; - case MT_ISHPDAT: - sc->sc_blklen = 512; - break; - case MT_ISVIPER1: - sc->sc_blklen = 512; - break; #if 0 case MT_ISPYTHON: sc->sc_blklen = 512; break; #endif case MT_ISWANGTEK: sc->sc_blklen = 512; break; default: --- 463,478 ---- else sc->sc_blklen = st_exblklen; break; #if 0 case MT_ISPYTHON: sc->sc_blklen = 512; break; #endif + case MT_ISAR: + case MT_ISHPDAT: + case MT_ISVIPER1: case MT_ISWANGTEK: + case MT_ISWANGTEK5099: sc->sc_blklen = 512; break; default: *************** *** 532,537 **** --- 533,539 ---- case MT_ISHPDAT: case MT_ISVIPER1: case MT_ISPYTHON: + case MT_ISWANGTEK5099: if (minor(dev) & STDEV_HIDENSITY) uprintf("Only one density supported\n"); break; *************** *** 623,628 **** --- 625,631 ---- case MT_ISVIPER1: case MT_ISPYTHON: case MT_ISWANGTEK: + case MT_ISWANGTEK5099: if (xsense->sc_xsense.key == XSK_UNTATTEN) stat = scsi_test_unit_rdy(ctlr, slave, unit); if (stat == STS_CHECKCOND) { From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 14:59:41 1993 Subject: Status of GDB ? 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: 529 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello, in the recent past of this mailing list there were couple of mails concerning GDB 4.9 development, it appeared to work at least basically. What is the current status of this debugger? My netbsd work has really stopped in lack of a debugger :-( Then one other thing, how about new kernel sources? I have 613, which seems to be quite stable, but there exists pre compiled kernels numbered like 635 or some such (no sources, only 613 sources). Hopefully the GDB diffs will be integrated to recent kernel sources. ++Tero From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 21:05:27 1993 Subject: Re: Status of GDB ? To: nix@stekt.oulu.fi (Tero Manninen) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > in the recent past of this mailing list there were couple > of mails concerning GDB 4.9 development, it appeared to > work at least basically. > > What is the current status of this debugger? > My netbsd work has really stopped in lack of a debugger :-( I have fixed a few configuration errors (although I never saw any bad effect due to these errors) and updated the files on wuarchive.wustl.edu. I seem to have problems uploading stuff to ftp.eunet.ch (keeps creating zero-length files). The files are in systems/amiga/boing/NetBSD/incoming: gdb-4.9-amigabsd-diffs.gz -- source code diffs to GDB for NetBSD-Amiga gdb-4.9.gz -- stripped executable sys613-debug-diffs.gz -- kernel changes for single-step & breakpoints I'd appreciate hearing of any problems with this stuff. It's been working for me just fine. Eventually I'll have to coordinate with Cygnus (or whomever) about integrating my changes with the mainline, but I'd like to make sure it's solid first. "Works for me!" -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 22:29:15 1993 Subject: Re: Status of GDB ? To: ahh@netcom.com (Andy Heffernan) Cc: nix@stekt.oulu.fi, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 200 Sender: NetBSD-Admin@cbmuucp.commodore.com > sys613-debug-diffs.gz -- kernel changes for single-step & breakpoints mtk - Have these kernal mods been folded into the distributed 635 kernel? If not, are you planning to in the future. Howard From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 10 23:41:07 1993 Subject: Re: Status of GDB ? To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: ahh@netcom.com, nix@stekt.oulu.fi, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 466 Sender: NetBSD-Admin@cbmuucp.commodore.com > > sys613-debug-diffs.gz -- kernel changes for single-step & breakpoints > > mtk - > Have these kernal mods been folded into the distributed 635 kernel? > If not, are you planning to in the future. I hope they're in, I think so at least. Ok, I'll put info on 644 into a separate mail I guess :-) -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 Sep 11 16:11:22 1993 Subject: new set of binaries, #644 To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1029 Sender: NetBSD-Admin@cbmuucp.commodore.com I uploaded a new set of binaries to ftp.eunet.ch (filling the disk to 110%..), they're called: bin-bin.tar.gz bin-usr.bin.tar.gz bin-sbin.tar.gz bin-usr.sbin.tar.gz etc just look for bin-*. Also included are new kernel sources for #644, as well as a new #644. Sorry to those with overscan problems in #635, I didn't get around to changing overscan values yet. I did incorporate a last-minute change from Mike Hitch to enable these binaries to later run on kernels supporting the '40, whoever this means you'll need to update your ps and w programs, or they won't work with the new kernel (the size of struct proc changed). Major bug-fix for #644: I hope I got the vt200 into much better state.. scrolling seems to work finally even with vt100 termcaps (they used to not scroll if inserting lines in emacs). Most stuff seems to work with vttest now. -Markus -- CHUUG/EUnet Switzerland Markus Wild Zweierstrasse 35 Tel: +41 1 291 45 80 mw@eunet.ch CH-8004 Zuerich Fax: +41 1 291 46 42 S=mw;P=EUnet;A=EUnet;C=CH From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 11 17:38:25 1993 Subject: loadbsd again. To: netbsd-amiga@cbmuucp.commodore.com Content-Type: text Content-Length: 817 Sender: NetBSD-Admin@cbmuucp.commodore.com I am having trouble with the last two kernels. When I boot either one, it just turns my "hard disk" light on and hangs there... I am still using the old loadbsd because I can't compile my own under amigados, and the one uploaded to wuarchive is "not an executable" so if someone could please help me, with this problem I would surely appreciate it. 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 Sun Sep 12 21:17:24 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: new set of binaries, #644 Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 11, 4:13pm, Markus Wild wrote: ... > changing overscan values yet. I did incorporate a last-minute change > from Mike Hitch to enable these binaries to later run on kernels > supporting the '40, whoever this means you'll need to update your ps > and w programs, or they won't work with the new kernel (the size of > struct proc changed). Thanks, Markus. Ps seems to work fine on my kernel (it didn't take too much effort to merge my 68040 changes into the #644 kernel sources). I did notice that all the updated binaries seem to be somewhat larger. I wanted to check if there was going to be enough room on my root and usr partition (my root partition doesn't have enough room :-(). I looking at the reason for the size increases, I noticed that some had some rather larger text segments - I don't know if this is because the commands have more code in them, if the library code size has increased, if the compiler used for the new binaries didn't do as good a job, or if there was some other reason. There is one thing definately wrong - all the binaries (at least the ones I checked) appear to have some extra garbage at the end of the file. It looks like maybe some of the symbol information didn't get stripped off the binary. 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 Sun Sep 12 23:15:11 1993 Subject: Re: new set of binaries, #644 To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 593 Sender: NetBSD-Admin@cbmuucp.commodore.com > I did notice that all the updated binaries seem to be somewhat larger. Hm, perhaps I didn't strip them all? > other reason. There is one thing definately wrong - all the binaries (at > least the ones I checked) appear to have some extra garbage at the end of > the file. It looks like maybe some of the symbol information didn't get > stripped off the binary. Woops.. that would indicate I f*d up strip.. lets see :-) -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 Sep 13 02:43:49 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: new set of binaries, #644 Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 12, 11:16pm, Markus Wild wrote: > > > other reason. There is one thing definately wrong - all the binaries (at > > least the ones I checked) appear to have some extra garbage at the end of > > the file. It looks like maybe some of the symbol information didn't get > > stripped off the binary. > > Woops.. that would indicate I f*d up strip.. lets see :-) Well, the headers don't indicate any symbol information (in most of the binaries, anyway), but it appears that all the new binaries have 8192 bytes of extra stuff on them. It looks like the strip didn't remove everything it was supposed to. 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 Sep 13 11:24:06 1993 Subject: Problems with new binaries and #644. 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: 1376 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I installed the new binaries, and the 644 kernel, but now I have a problem: Emacs now takes 3 to 5 mintes to start up. ps -ux shows S+ under stat. tar tvzf filename.tar.gz comes up with a segmentation fault. Also the display seems to have a problem. the top line is still missing, and now on the bottom of the screen I keep on getting old stuff. as if the stuff that scrolls off the top reappears on the bottom 2 lines. (Just try using IRC and you see what I mean, or edit a file in emacs that is longer than the screen). Ahh, I had to disable the line sendmail in the /etc/rc file, because the machine hang on that one. accton says something about function not supported. And one more question. I copied the new binaries over the old ones, in order not to loose what I installed myself. I now noticed that /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.3/include contains a subdirectory called amiga but 2.4.5 doesn't have this directory, actually there are a lot more other files and directories in 2.4.3, that are not found in 2.4.5. So now I'm wondering If I can safeley erase the 2.4.3 directory or if I have to copy some of the files over to the 2.4.5 directory. What about the files in the new include archive that are links to /home/usr/src/sys/* wher can those file be found? Thanks for you help. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 13 17:57:37 1993 Sender: dcc@dcs.ed.ac.uk To: netbsd-amiga@cbmuucp.commodore.com Subject: NetBSD and X11, 68040 Sender: NetBSD-Admin@cbmuucp.commodore.com Is anyone working on an X server? What boards are you supporting? The people in c.s.a.graphics are swooning over things like Piccolo and it's be nice to run NetBSD and X with one. Unfortunately, my machine is still down, but I can't wait to try out the latest version of NetBSD, and I'd like to lend a hand somewhere if I can. I am also interested in 68040 support. Dave David Crooke, Department of Computer Science, University of Edinburgh Janet dcc@ed.dcs : Internet dcc@dcs.ed.ac.uk : IP talk dcc@129.215.160.2 Work: JCMB Rm 3310, King's Bldgs, W Mains Rd., Edinburgh EH9 3JZ. 031 650 6013 Home: 12 (GFR) West Savile Tr, Edinburgh, SCOTLAND EH9 3DZ. 031 667 4854 From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 13 19:19:57 1993 Subject: Re: new set of binaries, #644 To: osymh@gemini.oscs.montana.edu (Michael L. Hitch) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 716 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well, the headers don't indicate any symbol information (in most of the > binaries, anyway), but it appears that all the new binaries have 8192 bytes > of extra stuff on them. It looks like the strip didn't remove everything > it was supposed to. Hm.. could you name one or two such binaries explicitly? I just went thru /usr/bin and picked some random executables, and they were all stripped, and according to "strings -a FOO | tail" didn't seem to contain any symbols (there are alot of RCS/SCCS strings in there, but these are not symbols). -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 Sep 13 19:37:49 1993 Subject: Re: some troubles To: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1581 Sender: NetBSD-Admin@cbmuucp.commodore.com This mail got to my mailbox after 20 or so loops.. I don't know whether it was intended for the list, but I think it's generic enough to be answered here: > I have problems with Amiga NetBSD kernel (635, 644): > > with kernel (vmunix) 450 my A3000 works just fine. > My 2500 doesnt work (due to 450 wont use 2091) > > with 635 and 644: > 1. the machine turns on disks synchronous mode, > cannnot find root device, asks for the name of the root device about > 10 times (not accepting the devices that work with the 450), > then continues to mount sl and pp devices and then panics with > "unable to find root device" or similair. > This happens both on 3000 and 2500/2091, although in 2500 the > kernel seems to be able to locate the 2091 controller. Looks like you're using the old loadbsd, since the kernel now supports going to multiuser directly (with -a), it can't be launched by the old loadbsd any longer (safely). This should at least get rid of the questioning, if the kernel still locks up, try disabling sync for your drive(s). > 2. the screen is shifted to left about 3-5 cm making one unable to read > 6 to 8 leftmost columns. I mentioned in the intro to #644 that I didn't have time to work out a good solution to enable/disable overscan. > 3. the mouse pointer will not move. Hm, then the machine has locked up.. (hey mykes, finally some use for the mouse driver :-))) -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 Sep 13 19:58:54 1993 Subject: Re: Problems with new binaries and #644. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2746 Sender: NetBSD-Admin@cbmuucp.commodore.com > Emacs now takes 3 to 5 mintes to start up. ps -ux shows S+ under stat. > > Ahh, I had to disable the line sendmail in the /etc/rc file, because > the machine hang on that one. These symtoms both sound like you're running a named, but that named can't reach the other world (i.e. the internet). Fix: comment out the starting of named in /etc/rc. > tar tvzf filename.tar.gz comes up with a segmentation fault. Also the display seems Hm.. old tar? strange.. any programs that all of a sudden segfault are usually victims of the old ctime-bug. Oh, lots of you probably didn't set up their local timezone yet: make a symlink /etc/localtime into /usr/share/zoneinfo/YOUR-TIMEZONE, on my system, I have: ls -l /etc/localtime lrwxrwxr-x 1 root 23 Aug 23 16:57 /etc/localtime -> /usr/share/zoneinfo/CET > to have a problem. the top line is still missing, and now on the > bottom of the screen I keep on getting old stuff. as if the stuff that > scrolls off the top reappears on the bottom 2 lines. (Just try using > IRC and you see what I mean, or edit a file in emacs that is longer than the screen). Weird.. well, overscan support was added for people that have to use the custom chips console, that wanted to get as much data on screen as possible. I don't use that console myself, so I didn't notice any problems, the retina-console doesn't show such a behavior. It could be that the copper scrolling code isn't prepared to handle overscan right, or I'd have to tweak it somewhat to work right.. I just tried some editing on /dev/ttye0, and things seemed to work fine. Could it be that it's your monitor tricking you out? > accton says something about function not supported. I didn't yet look into this, didn't need accounting so far. > And one more question. I copied the new binaries over the old ones, in order > not to loose what I installed myself. I now noticed that > /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.3/include contains a subdirectory called amiga > but 2.4.5 doesn't have this directory, actually there are a lot more other files > and directories in 2.4.3, that are not found in 2.4.5. So now I'm wondering If > I can safeley erase the 2.4.3 directory or if I have to copy some of the files over > to the 2.4.5 directory. installing gcc tends to install a LOT of dubious so called "fixed" headers in that directory. I disagree with most of those "fixes", so I didn't install them in 2.4.5. > What about the files in the new include archive that are links to > /home/usr/src/sys/* wher can those file be found? Oops.. bsdsyssrc.644.tar.gz... -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 Sep 14 02:52:11 1993 Subject: New binaries..Internal error in GCC ???. 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: 1517 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, Yesterday I wanted to compile kermit on my NetBSD machine but ran into a problem. (I do have the new binaries and $644) The first couple of files compile fine, but when the compiler gets to a file called ckuus5.c I get the following: trapsignal (1626, 11, 8, 8, 10c18) cc: Sep 14 00:08:34 atze /netbsd: trapsignal (1626, 11, 8 ,8, 10c18) Internal compiler error: program cpp got fatal signal 11) Sep 14 00:08:34 atze /netbsd: trapsignal (1626, 11, 8, 8, 10c18). gdb then doesn't recon the core as a core file?? (actually gdb doesn't recognize any coredump as a core file, it did unter #613. Also when I tried to compile TCL I got some wierd error in /var/tmp: First it complains a lot about limits.h which is in /usr/gnu/lib/gcc-lib/netbsdamiga/2.4.3/include. How does it get to those in the first place. Anyway I copied the limits.H from the 2.4.5/include file over instead and all those errors went away. But the strange ones still come up: /var/tmp/cc002038.s:1800:Ignoring junk after expression same :1802:Ignoring junk after expression same :2289:Ignoring junk after expression same :2291:Ignoring junk after expression same :2711:Bignum assumed to be binary bit-pattern same :2868:Bignum assumed to be binary bit-pattern same :2908:Bignum assumed to be binary bit-pattern Here the compilation stops. Ist this something wron with GCC or is this related to the stuff I'm compiling? Thanks for your help. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 14 16:21:29 1993 Subject: Changing colors and screen resolution? To: netbsd-amiga@cbmuucp.commodore.com Return-Receipt-To: Abeech@splat.aarnet.edu.au Sender: NetBSD-Admin@cbmuucp.commodore.com HELP... I am wondering if it is possible to use the binpatch programme to change the console screen colors? I would also like to change the console resolution to something a little less harder on the eyes. Can this be done? -- Adrian V. Beech E-Mail: adrianb@spectrum.adsp.sub.org abeech@gucis.sct.gu.edu.au Abeech@splat.aarnet.edu.au From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 14 18:05:09 1993 Subject: Re: Changing colors and screen resolution? To: Abeech@splat.aarnet.edu.au Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1314 Sender: NetBSD-Admin@cbmuucp.commodore.com > I am wondering if it is possible to use the binpatch programme to change the > console screen colors? I would also like to change the console resolution to > something a little less harder on the eyes. Can this be done? There should be a program to set these parameters.. I made a start with the "videomode" tool, that lets you select different resolutions for the Retina console, there should be something equivalent (it should be the same program, really!) for the custom chips console, to change things like resolution, video mode, colors, etc. This needs support in the kernel though, lets see if I some day feel like writing it, or perhaps someone else out there is annoyed enough to do it? The tool should be independant of the used console, ie. it should propagate identical "meta"-ioctls to the active console, and have the console-dependant driver interprete the data. That way, we should, for example, be able to pass one (possibly large) sprite image to the console driver, and have the individual drivers do whatever they have to do with it to display it (for example, scale to lores, copy into chipmem, for custom chips display). -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 Sep 15 02:05:16 1993 Subject: dump question To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1184 Sender: NetBSD-Admin@cbmuucp.commodore.com I tried to use dump to backup a filesystem, and I got the following error message when it gets to the phase where it says it is dumping the files. (warning: the error messages may be garbled a bit, since I scribbled them down by hand on a little piece of paper, for instance the word start on the second line may have been stat or something else) scsi0: abort icmd: csr=0xff asr = 0x20 st0: stintr unknown start 0xff sbic_wait TIMEO @640 with asr = x20 csr = xff sbic_wait TIMEO @640 with asr = x20 csr = xff sbic_wait TIMEO @640 with asr = x20 csr = xff sbic_wait TIMEO @640 with asr = x20 csr = xff At which time I use the old 3 finger reboot 'cause nothing else seems to work. configuration - kernel = 644 A3000 sd1 = maxtor 213 sd2 = HP something 316Mb st0 = (scsi addr 4) HP 1.3 gig dat drive sd6 = maxtor 120 Ados only Other info - I had to binpatch kernel with _scsi_no_dma when I added the tape drive in order to get the system to boot. The tape drive works fine with tar. Is dump known to work or not work, or is everyone using tar? Anyone else had problems with dump? Do I need to binpatch something else? Any help/ideas would be appreciated. Later Howard From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 02:42:39 1993 Subject: Re: dump question (correction) To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1152 Sender: NetBSD-Admin@cbmuucp.commodore.com > > I tried to use dump to backup a filesystem, and I got the following > error message when it gets to the phase where it says it is dumping the > files. > > (warning: the error messages may be garbled a bit, since I scribbled > them down by hand on a little piece of paper, for instance the word start > on the second line may have been stat or something else) > > scsi0: abort icmd: csr=0xff asr = 0x20 > st0: stintr unknown start 0xff it was stat not start > sbic_wait TIMEO @640 with asr = x20 csr = xff > sbic_wait TIMEO @640 with asr = x20 csr = xff > sbic_wait TIMEO @640 with asr = x20 csr = xff > sbic_wait TIMEO @640 with asr = x20 csr = xff > > The tape drive works fine with tar. oops, I guess I never tried to write on the unix side before. The unix side reads tar files I wrote under amigados (using BTNtape and gnutar) just fine. However when I try to write from the unix side, I get the same errors. So the problem is obviously just one of writing to the tape, and not a problem with dump. So any ideas about what is wrong? Any suggested binpatches? Sorry about the dis-information in my original message. Thanks Howard From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 02:53:44 1993 Subject: GVP Installation 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: 253 Sender: NetBSD-Admin@cbmuucp.commodore.com Apparently there is support for the GVP Series II controller for BSD, etc... How ever, I'm at a loss to work out how to install the beastie with the correct masks, etc... Faaastprep (v1.98m) has no provision for this kind of thing.. Any ideas ? -- From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 03:05:39 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: A2065 work with vmunix.613? Sender: NetBSD-Admin@cbmuucp.commodore.com Hello again folks, Thanks for the help with putting the rootfs on the BSDR partition earlier this month. I found the problem - I had HDToolBox running in the background so filetodev gave me "can't open scsi.device" error message. I ASSUMED it meant no scsi.device rather than that the scsi.device was busy. Wap! Wap! (sound of me banging head against the wall in shame and embarrassment). The system is running and I am trying to attach the A3000 to an thin-wire TCP/IP network using the A2065 Ethernet card. I am using the vmunix.613 kernel and the older binaries - I haven't had time to download the newest ones yet. The A3000 runs Amiga TCP/IP under AmigaDOS just fine - I can ping, ftp and telnet the Unix workstations on the network so I know that the hardware is OK. Under NetBSD, I have edited the /etc/netstart file so that ifconfig has my machine's hostname and I have set the netmask appropriately, etc. The A3000 can ping itself but can't ping any other machine on the network. Also, the netstat -i command comes back with only the header - no information about the network interfaces. When I boot NetBSD, I see the a line about le0 appear on the console which appears to contain the hardware Ethernet address of the A2065 so I assume the kernel found the Ethernet board. I looked at the kernel configuration files AMIGA & GODZILLA and they both have the inet option specified so it would appear that the kernel has Ethernet support compiled in. I am at a loss right now on what to do next. First, is the A2065 supported by NetBSD-Amiga? I didn't see it in the list of supported hardware. Second, did I miss something in the network configuration? Any suggestions are welcome (besides soaking my head in a bucket of water - probably would feel good after beating it against a wall). Irv Moy Internet: musashi@netcom.com ----------------------------------------------------------- | Insert clever comment -> HERE <- and mail | ----------------------------------------------------------- From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 05:46:45 1993 Subject: Re: A2065 work with vmunix.613? To: musashi@netcom.com (Irving Moy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > Also, the netstat -i command comes back with only the > header - no information about the network interfaces. netstat reads /vmunix to find the addresses of variables in /dev/kmem. If /vmunix doesn't match the kernel you're running, you lose! Whenever you get a new kernel, update /vmunix. Unfortunately, I haven't figured out how to get my X-terminal to talk on ethernet yet, so I don't know how well the networking works. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 09:02:16 1993 To: thecure@mullian.ee.mu.OZ.AU Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: GVP Installation Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Matthew" == matthew aldous writes: Matthew> Apparently there is support for the GVP Series II controller Matthew> for BSD, etc... How ever, I'm at a loss to work out how to Matthew> install the beastie with the correct masks, etc... Just use the ordinary A3000 installation instructions, except when they mention scsi.device, use gvpscsi.device. Matthew> Faaastprep (v1.98m) has no provision for this kind of Matthew> thing.. Use HDToolBox instead... (Don't use faaastprep to update the RDB on disks where you have BSD partitions, at least my version screws up, and alters some info it shouldn't). 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 Sep 15 11:49:10 1993 Subject: Re: A2065 work with vmunix.613? To: musashi@netcom.com (Irving Moy) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 523 Sender: NetBSD-Admin@cbmuucp.commodore.com > The system is running and I am trying to attach the A3000 to an > thin-wire TCP/IP network using the A2065 Ethernet card. I am > using the vmunix.613 kernel and the older binaries - I haven't had Eh.. Ethernet is working starting with version #622.. don't try this with #613, you'll just lock up the kernel on the first bit that passes thru the wire... -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 Sep 15 11:49:29 1993 Subject: Re: dump question To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 985 Sender: NetBSD-Admin@cbmuucp.commodore.com > I tried to use dump to backup a filesystem, and I got the following > error message when it gets to the phase where it says it is dumping the > files. Hm.. this looks like your streamer freaked out.. I'd suggest you try disabling sync-handshake for it (my Archive Python supports sync, but I had to disable it for the Wantek QIC streamer). > Other info - > I had to binpatch kernel with _scsi_no_dma when I added the tape > drive in order to get the system to boot. Oh... you definitely should NOT have to do that on the A3000, ever. I suspect it's sync, set _inhibit_sync[2] to 1. (2 == unit of your HP-DAT). > Is dump known to work or not work, or is everyone using tar? I'm using both, no problems, works great with the Python. > Anyone else had problems with dump? > Do I need to binpatch something else? -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 Sep 15 11:50:19 1993 Subject: Re: GVP Installation To: thecure@mullian.ee.mu.OZ.AU (matthew aldous) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 488 Sender: NetBSD-Admin@cbmuucp.commodore.com > Apparently there is support for the GVP Series II controller > for BSD, etc... How ever, I'm at a loss to work out how to > install the beastie with the correct masks, etc... You don't have to fiddle with the mask, it's not (yet) used in BSD anyway. What you should make sure is that the "Reserved" entry is 0 though. -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 Sep 15 14:56:39 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Which Amiga to Buy Sender: NetBSD-Admin@cbmuucp.commodore.com After deciding that I need an Amiga of some appropriate configuration to run NetBSD, from the pseudo FAQ assuming that this would be an A3000 with a 2091 SCSI controller, I ring up my local dealer who promptly tells me that no more Amigas are to be made with MMU's and I cannot get an A3000 unless I get in the queue to pick one up second hand! If true, does this not kill off the line a little, and NetBSD on these machines, an awful lot. Am I being led astray by the uninformed and if so, what is the best Amiga to purchase for NetBSD and with what optional bit? Thanks - Damian From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 15:47:28 1993 Subject: Re: dump question To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 760 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Other info - > > I had to binpatch kernel with _scsi_no_dma when I added the tape > > drive in order to get the system to boot. > > Oh... you definitely should NOT have to do that on the A3000, ever. > I suspect it's sync, set _inhibit_sync[2] to 1. (2 == unit of your > HP-DAT). > Well, my DAT is scsi address 4, so the inhibit_sync[4] was already set to 1. So I tried setting it at 0 and still get the same problem. As far as the _scsi_no_dma here is the error messages I get if I don't do that. bpf: lo0 attached < normal dmanext at end!!! trap type 1, code = a24d, v = 426748e7 pid = 1310, pc = 0005A9FC, ps = 2200, sfc = 0001, dfc = 0001 registers [blah blah blah] kernel stack [blah blah blah] Any other Ideas? Thanks Howard From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 16:39:29 1993 Subject: Re: Which Amiga to Buy 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: 999 Sender: NetBSD-Admin@cbmuucp.commodore.com > tells me that no more Amigas are to be made with MMU's and I cannot get > an A3000 unless I get in the queue to pick one up second hand! I believe Creative Computers is advertising an A3000/105/25/5 for $999 and towers for $1199. Their order number is 1-800-872-8882. It doesn't say if they are new or used. I've never ordered from them so I can't vouch for them. Check out the back of (gag) Amiga World. OTOH, a used 3000 may be a great deal. You can probably get one for a quarter of what they cost when introduced. Guess when I got mine... > If true, does this not kill off the line a little, and NetBSD on these > machines, an awful lot. Until someone does a port for the 040 MMU. > Am I being led astray by the uninformed and if so, what is the > best Amiga to purchase for NetBSD and with what optional bit? An A3000 is the only way to go, as far as I know. You don't need the 2091 controller as the 3000 has the SCSI controller on the motherboard. > > Thanks - Damian > -- Bill From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 20:04:45 1993 Subject: Re: Which Amiga to Buy To: damianm@eram.esi.com.au (Damian McGuckin) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1893 Sender: NetBSD-Admin@cbmuucp.commodore.com > After deciding that I need an Amiga of some appropriate configuration > to run NetBSD, from the pseudo FAQ assuming that this would be an A3000 > with a 2091 SCSI controller, I ring up my local dealer who promptly Yuck.. an A3000 has a (superb) builtin SCSI-controller, you don't need any external controller board like the A2091. > tells me that no more Amigas are to be made with MMU's and I cannot get > an A3000 unless I get in the queue to pick one up second hand! Huh.. your dealer is slightly confused as it seems.. The A1200 and the A4000/30 are MMU-less, the A4000/40 comes with a complete '40, not a crippled one, so this cpu is perfectly capable of running NetBSD (once the '40 support is finished). As far as I know, A3000 are no longer produced, I don't know the state of the A3000T, I've heard they're now sold as A3000/40T, that is with a '40 board, I don't know whether this is limited to certain countries though. > Am I being led astray by the uninformed and if so, what is the > best Amiga to purchase for NetBSD and with what optional bit? I'd say (hey I *am* biased, I appologize:-)) the A3000 is still the nicest existing and available Amiga around. So if you can manage to find an A3000T, that would be a very cool NetBSD machine. Depending on your preferences (I myself don't need a color-box that doesn't reliably work on my 31kHz monitor) you could also go A4000/40, but keep in mind that this machine is not yet supported, and that there will be some time until the 4000T/A4091 scsi-controller is supported. You'd have to go with a 24bit controller like the 2091 or the gvpII, and thus you wouldn't be able to DMA into 32bit memory. Hey, I said I'm biased, you noticed I own an A3000? :-) -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 Sep 15 20:09:00 1993 Subject: Re: dump question To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1212 Sender: NetBSD-Admin@cbmuucp.commodore.com > Well, my DAT is scsi address 4, so the inhibit_sync[4] was already > set to 1. So I tried setting it at 0 and still get the same problem. > > As far as the _scsi_no_dma here is the error messages I get if I > don't do that. > > bpf: lo0 attached < normal > dmanext at end!!! > trap type 1, code = a24d, v = 426748e7 > pid = 1310, pc = 0005A9FC, ps = 2200, sfc = 0001, dfc = 0001 > registers > [blah blah blah] > kernel stack > [blah blah blah] > > Any other Ideas? "dmanext at end!!!" is an error message, that should never ever be printed.. What happend, if it is printed, is that the chip has been walked thru the whole data transfer of a running scsi command, and, after having transmitted everything there is to transmit, is interrupted again to continue the transmission. Since there's no data left to transmit, this is an illegal condition. Now, please don't ask me WHY the @#$@ this ever happens... Is your HP-DAT explicitly recognized by the kernel, or does it use the default parameters ("unsupported tape 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 Wed Sep 15 20:25:13 1993 Subject: Re: dump question To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com [...] >> As far as the _scsi_no_dma here is the error messages I get if I >> don't do that. >> >> bpf: lo0 attached < normal >> dmanext at end!!! >> trap type 1, code = a24d, v = 426748e7 >> pid = 1310, pc = 0005A9FC, ps = 2200, sfc = 0001, dfc = 0001 >> registers >> [blah blah blah] >> kernel stack >> [blah blah blah] >> >> Any other Ideas? > >"dmanext at end!!!" is an error message, that should never ever be >printed.. What happend, if it is printed, is that the chip has been >walked thru the whole data transfer of a running scsi command, and, >after having transmitted everything there is to transmit, is interrupted >again to continue the transmission. Since there's no data left to >transmit, this is an illegal condition. Now, please don't ask me >WHY the @#$@ this ever happens... Just to let you know that he is not alone, I also get the same "dmanext at end!!!" message if I have SCSI dma enabled in the kernel. I also get a ton of "DMAINTR should never be entered" (or something to that effect) messages also. My machine is an A3000T. Could this be something linked to a proto chip? By the way, thanks to everyones for their help in getting my swap partition going. It turns out that the kernel would not recognize the swap partition unless it was on the same drive as the root partition. I have since moved them both onto the same drive, and rebuilt the "swapinfo" command, and everything seems to mount and work just great.. 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 Wed Sep 15 22:08:48 1993 Subject: Re: dump question To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 2441 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Is your HP-DAT explicitly recognized by the kernel, or does it use the > > default parameters ("unsupported tape drive") ? > > Yes it seems to be recognized as an HP35450A. I looked at some of the > kernel code, and see that there is specific code in there to support it. Hm, I know we used exactly this drive in Bielefeld at the IRC/Usenet party, and it worked like a charm, on both A2000/A2091 and A3000 systems. > A few other things I have tried. > With _sync_debug 1, and _scsi_debug 1 when I try to boot with out > sync inhibited, it says it's sending the sync signal which is denied, > and so it says it is going asynch. That sounds like the handshake works fine. > When I actually try to tar a file off to the drive I get the following > (as a result of setting _scsi_debug) > ixfer_out fail: l2040 i20 w-1 Hm, where did you write that tape? DAT drives usually support variable length records, and you can only read such tapes back using the same blocking. I had right this problem when I was creating tapes under SunOS, until I explicitly piped the tar to dd bs=512 of=/dev/rst0. The above error message tells you that 2040 bytes off the last write command were not transmitted, and that the write was aborted due to a timeout (w being -1). You can try upping the timeout by poking a larger value into scsi_wait_data (or was it scsi_data_wait..). > Some stuff is actually getting onto the tape. Because when I do a tar tvf > of the tape, I get a listing of the file name, and then later I > get an error about the file being short. Hm, how to do you write to the tape, if I may ask? > Someone else asked if this could be a problem with the PROTO scsi chip. Not very likely. As I said, we used this DAT drive on at least 3 different amigas (A3000, A3000T and A2000/2091 (or gvp, don't remember)), and I think at least one of those should have a PROTO too. > I seriously doubt that I have a PROTO chip since I have one of later > 3000s made (I noticed the HD was made in the later half of '92). I > have not checked the scsi chip to make sure though. Hm, even my A3000/UX had a proto chip, and UX were definitly not among the first sold A3000. I guess Commo once bought a gazillion of those chips and is still trying to get rid of them that way .. :-) -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 Sep 15 22:14:45 1993 Subject: How to unsubscribe? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com How do you unsubscribe from this group? I sent a message with subject line "unsub aa457@freenet.carleton.ca", and that same text in the body. It didn't work, although another message to subscribe my new address did work. So now I'm getting a lot of mail in duplicate. :-) From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 22:17:27 1993 Subject: GVP IO Extender hardware info? To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL11] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Content-Length: 480 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello, Has anyone attempted to get the hardware information for the GVP IO Extender so a driver can be written? If so, did you get anywhere? What was GVP's response? (Yes, I know the probable answer, but I thought I'd check.) -- Stephen W. Thomas UUCP: swt@affinity.mn.org Affinity Computer Applications, Inc. VOICE: (612) 484-2905 4740 Hodgson Road FAX: (612) 483-4069 Shoreview, MN 55126-6042 USA BIX: affinity From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 22:17:53 1993 Subject: Re: /vmunix? To: pt@crl.com (paul theodoropoulos) 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: 561 Sender: NetBSD-Admin@cbmuucp.commodore.com > i guess i need to ask a really bonehead question: how do i update > /vmunix? am i correct in assuming that "updating" it involves copying > the memory image of the kernel to the root partition? and if that's > correct, what's the sysadmin magic i must perform to do so? No, you just copy over the file from AmigaDOS, same thing you do to get the other archives over to BSD (to install /usr). -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 Sep 15 23:25:34 1993 Subject: /vmunix? To: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 674 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Also, the netstat -i command comes back with only the > > header - no information about the network interfaces. > > netstat reads /vmunix to find the addresses of variables > in /dev/kmem. If /vmunix doesn't match the kernel you're running, > you lose! Whenever you get a new kernel, update /vmunix. i guess i need to ask a really bonehead question: how do i update /vmunix? am i correct in assuming that "updating" it involves copying the memory image of the kernel to the root partition? and if that's correct, what's the sysadmin magic i must perform to do so? signed, a bonehead -- paul theodoropoulos pt@crl.com diogenes@well.sf.ca.us From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 23:27:31 1993 Subject: Re: dump question To: mw@eunet.ch (Markus Wild) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1052 Sender: NetBSD-Admin@cbmuucp.commodore.com > Is your HP-DAT explicitly recognized by the kernel, or does it use the > default parameters ("unsupported tape drive") ? Yes it seems to be recognized as an HP35450A. I looked at some of the kernel code, and see that there is specific code in there to support it. A few other things I have tried. With _sync_debug 1, and _scsi_debug 1 when I try to boot with out sync inhibited, it says it's sending the sync signal which is denied, and so it says it is going asynch. When I actually try to tar a file off to the drive I get the following (as a result of setting _scsi_debug) ixfer_out fail: l2040 i20 w-1 Some stuff is actually getting onto the tape. Because when I do a tar tvf of the tape, I get a listing of the file name, and then later I get an error about the file being short. Someone else asked if this could be a problem with the PROTO scsi chip. I seriously doubt that I have a PROTO chip since I have one of later 3000s made (I noticed the HD was made in the later half of '92). I have not checked the scsi chip to make sure though. From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 15 23:39:36 1993 Subject: Re: Booting from / To: leland@wacky.acet.org (Robert Leland - PSI) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 706 Sender: NetBSD-Admin@cbmuucp.commodore.com > Now, how about the command from AmigaDOS ? > loadbsd BFFSa:vmunix.644 You can't.. :-( The problem is, that both, bffs and ixemul try to be "smart" about unix file-syntax, and this results in one mapping too much, loadbsd can't access vmunix.644 that way. You have to do this: copy bffsa:vmunix.644 ram:vmunix.644 loadbsd ram:vmunix.644 This works fine, and is what I do to boot (actually I copy a new kernel to an amigados partition, and boot from there. That way I don't have to mount the bsd filesystem just to boot from it). -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 Sep 15 23:45:19 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Booting from / Sender: NetBSD-Admin@cbmuucp.commodore.com A bit of trivia... In case you haven't tried this yet. I tried mounting my NetBSD / from AmigaDOS, and all worked great, It was nice seeing Icons for my unix stuff .... This was done using the BFFSFileSystem ----------------------------------------------------------- WARNING: I haven't tried the below command yet, but do plan to tonight. I don't see why it wouldn't work though, since the entire vmunix should be read into memory though before the OS is taken over. Now, how about the command from AmigaDOS ? loadbsd BFFSa:vmunix.644 ---------------------------------------------------------- Where BFFSa: is the NetBSD root partition that was AutoMounted by AmigaDos This is booting directly from your unix / partition. So there is no need to transfer a newly built kernel back to AmigaDOS so you can boot. One warning though .... The BFFSFileSystem 1.25 still seems to become confused by softlinks sometimes. /netbsd and /386bsd show up as drawer icons but are really not, and are soft links to /vmunix. Once my system crashed when I clicked on the 386BSD softlink. I then rebooted and tried again and the systemworked fine and didn't crash again, even after repeated clicks on 386bsd. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 00:07:03 1993 Subject: Re: dump question To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1888 Sender: NetBSD-Admin@cbmuucp.commodore.com > > When I actually try to tar a file off to the drive I get the following > > (as a result of setting _scsi_debug) > > ixfer_out fail: l2040 i20 w-1 > > Hm, where did you write that tape? DAT drives usually support variable > length records, and you can only read such tapes back using the same > blocking. I had right this problem when I was creating tapes under SunOS, > until I explicitly piped the tar to dd bs=512 of=/dev/rst0. This was writing from netbsd (tar cvf /dev/rst0 file) Here is the line in my Mountlist under amigados for BTN-handler Startup = "scsi.device/UN-4/BS-512/NB-128/BT-4" As I said, I can read and write under ados, and can read tapes written under ados. > The above > error message tells you that 2040 bytes off the last write command > were not transmitted, and that the write was aborted due to a timeout > (w being -1). You can try upping the timeout by poking a larger value > into scsi_wait_data (or was it scsi_data_wait..). Ok, I'll see if that does anything. > > > Some stuff is actually getting onto the tape. Because when I do a tar tvf > > of the tape, I get a listing of the file name, and then later I > > get an error about the file being short. > > Hm, how to do you write to the tape, if I may ask? tar cvf /dev/rst0 file When I thought only dump had a problem, I tried specifing densities and number of feet in the tape (using numbers recommended in comp.sys.hp), but I still got the error messages. > Hm, even my A3000/UX had a proto chip, and UX were definitly not among > the first sold A3000. I guess Commo once bought a gazillion of those > chips and is still trying to get rid of them that way .. :-) Well I think mine was one of the last 3000s. That could mean they were out of PROTOs already, or were desparate to get rid of them. I guess I'll have to take a look and see what it is next time I have her open. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 00:38:53 1993 Subject: Re: Booting from / To: leland@wacky.acet.org (Robert Leland - PSI) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > This is booting directly from your unix / partition. > So there is no need to transfer a newly built kernel > back to AmigaDOS so you can boot. If you're building kernels under BSD, you can also copy the image to /dev/reboot (aka /dev/reload) to boot the new kernel. I don't have the major and minor numbers handy right now, but I'm sure somebody does (hint hint). -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 01:11:22 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: creating /dev/log Sender: NetBSD-Admin@cbmuucp.commodore.com I have a new 16M root partition built all except /dev/log which will not tar or copy over to the new partition. How do I or the system create this. Did I miss it in MAKEDEV ? -Thanks -Rob From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 01:44:14 1993 Subject: Re: dump question To: hwdobso@afterlife.ncsc.mil (Howard Dobson) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1118 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hm, where did you write that tape? DAT drives usually support variable > > length records, and you can only read such tapes back using the same > > blocking. I had right this problem when I was creating tapes under SunOS, > > until I explicitly piped the tar to dd bs=512 of=/dev/rst0. > > This was writing from netbsd (tar cvf /dev/rst0 file) > Your comment about dd made me decide to give it a try. I tar'ed some files into a file called x.tar. Then did dd if=x.tar of=/dev/rst0 And what do you know, it worked. I untarred them back off and diffed them with the original files and all was well. So then I tried tar again only this time I did tar cvbf 1 /dev/rst0 * And that worked too. The default for b in tar is 20. (b is the number of 512byte blocks to do at a time) The only other value I tried so far was 5 which caused the same problem as before. So I conclude that for some reason the drive does not like it when you write big blocks too it, but is ok with small blocks. (Does this hypotheses seem resonable) I upped the timeout number from 50000 to 80000 which didn't seem to make a difference. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 02:01:45 1993 Subject: Booting 644? To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com What are you supposed to do in response to the "Boot device?" question in 644? If I answer "sd6", I get "bsd/missing unit number". If I answer "6", I get "use sd%d" which implies sd6 is correct. If I answer "sd0" or "sd8" I get a kernel panic. I have a Quantum at SCSI ID 6. I have used binpatch to inhibit sync negotiation and the kernel does see the drive (it reports the size correctly). From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 02:04:50 1993 Subject: Floppy driver To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I recently read in comp.unix.amiga that a floppy driver is working in Amiga Linux. Is it possible to work this driver into BSD? I once implied that I would be willing to attempt a driver (after fixing the other bugs first) but it's going to be a while (>1 month?) before my system gets to the point where I can do serious development on it. (I need a bigger hard drive) If anybody's really hurting for a floppy driver, I'd suggest they check the Linux sources. Ick, hmmm... does the GPL shag us up here? Do we want GPLed code in the kernel? From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 02:28:17 1993 Subject: Re: Booting 644? To: dej@eecg.toronto.edu (David Jones) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > What are you supposed to do in response to the "Boot device?" question in 644? Get the new loadbsd executable (prob'ly from ftp.eunet.ch). -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 02:37:12 1993 Subject: Re: /vmunix? To: netbsd-amiga@cbmuucp.commodore.com Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 527 Sender: NetBSD-Admin@cbmuucp.commodore.com > > i guess i need to ask a really bonehead question: how do i update > > /vmunix? am i correct in assuming that "updating" it involves copying > > the memory image of the kernel to the root partition? and if that's > > correct, what's the sysadmin magic i must perform to do so? > > No, you just copy over the file from AmigaDOS, same thing you do to > get the other archives over to BSD (to install /usr). see?! i knew it was a bonehead question. thanks. -- paul theodoropoulos pt@crl.com diogenes@well.sf.ca.us From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 13:29:22 1993 Subject: Re: How to unsubscribe? To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga mailing list) X-Mailer: ELM [version 2.3 PL0] Sender: NetBSD-Admin@cbmuucp.commodore.com David Jones: > > How do you unsubscribe from this group? > > I sent a message with subject line "unsub aa457@freenet.carleton.ca", and > that same text in the body. It didn't work, although another message to > subscribe my new address did work. So now I'm getting a lot of mail in > duplicate. :-) I sent mail to netbsd-admin@cbmuucp.commodore.com and asked to unsubscribe me from the list, but I'm still getting these mails. I'm getting duplicates too, as there seems to be some broken news-mail gateway (news@senga.ka.sub.org) dumping old mails to this list, argh. -- / / most stupid ayrjola@hut.fi / / dinosaurs ___________________/ / ought to starve --------------------' From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 14:59:04 1993 X400-Originator: /DD.ID=1619692/G=Hamish/I=HI/S=Macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.134:16.08.93.12.58.22] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: dump ques... Sender: "Hamish (H.I.) Macdonald" To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: dump question Sender: NetBSD-Admin@cbmuucp.commodore.com Markus> Hm, even my A3000/UX had a proto chip, and UX were definitly Markus> not among the first sold A3000. I guess Commo once bought a Markus> gazillion of those chips and is still trying to get rid of Markus> them that way .. :-) hwdobso> Well I think mine was one of the last 3000s. That could mean hwdobso> they were out of PROTOs already, or were desparate to get rid hwdobso> of them. I guess I'll have to take a look and see what it is hwdobso> next time I have her open. Mine is a fairly late A3000 also (bought new in summer 1992; dealer had to get it shipped from C= Canada). The 33C93 in it says something like "WD33C93A-04 PL". No "PROTO" anywhere on it. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 14:59:22 1993 X400-Originator: /DD.ID=1619692/G=Hamish/I=HI/S=Macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.240:16.08.93.12.58.47] X400-Content-Type: P2-1984 (2) Content-Identifier: re:Floppy dri... Sender: "Hamish (H.I.) Macdonald" To: NetBSD-Amiga@cbmuucp.commodore.com Subject: re:Floppy driver Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> On Wed Sep 15 20:10:00 1993, >>>>> dej@eecg.toronto.edu wrote: dej> I recently read in comp.unix.amiga that a floppy driver is dej> working in Amiga Linux. Mostly working. There still appear to be some problems when writing to the higher numbered tracks. I think there are some timing problems. Unfortunately, the sub-10ms timing facilities in linux/68k right now leave something to be desired. dej> Is it possible to work this driver into BSD? The existing driver is derived from the PC-clone floppy driver, and thus falls under the GPL. I gather it is desired that the NetBSD kernel remain GPL-free. I'm planning to do a complete rewrite of the floppy driver sometime, and I intend to release it under the Berkeley copyright, which will allow the NetBSD effort to incorporate it in their kernel. I have at least one other major change I intend to complete before working on this though, so the NetBSDers might get a little impatient and write their own driver before then. Hamish. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 17:48:19 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: RE: /dev/log Sender: NetBSD-Admin@cbmuucp.commodore.com Never mind /dev/log -> unixdomain socket created by syslogd So its created when syslogd starts up. I am little brain dead after using 74 Floppies to transfer over the os to my computer, just gotta get a tape drive! -Rob From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 19:38:17 1993 Subject: Re: creating /dev/log To: leland@wacky.acet.org (Robert Leland - PSI) 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: 424 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have a new 16M root partition built all except /dev/log > which will not tar or copy over to the new partition. /dev/log is a socket, created by syslogd. You can't copy sockets with tar, but this doesn't hurt, it's recreated anyway upon your next 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 Sep 16 19:49:52 1993 Subject: Re: Floppy driver To: dej@eecg.toronto.edu (David Jones) 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: 468 Sender: NetBSD-Admin@cbmuucp.commodore.com > If anybody's really hurting for a floppy driver, I'd suggest they check the > Linux sources. Ick, hmmm... does the GPL shag us up here? Do we want GPLed > code in the kernel? We definitely *don't* want GPL code in the kernel, so this renders the Linux floppy code completely useless to us, sorry. -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 mw@eunet.ch Thu Sep 16 19:52:03 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA08379; Thu, 16 Sep 93 13:51:41 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA10337; Thu, 16 Sep 93 13:51:22 EDT Received: from chsun.eunet.ch (chsun.chuug.ch) by cbmmail.commodore.com (4.1/SMI-4.1) id AA08369; Thu, 16 Sep 93 13:51:13 EDT Received: by chsun.eunet.ch (5.65c8/1.34) id AA18213; Thu, 16 Sep 1993 19:52:26 +0200 From: mw@eunet.ch (Markus Wild) Message-Id: <199309161752.AA18213@chsun.eunet.ch> Subject: Re: dump question To: NetBSD-Admin@cbmuucp.commodore.com Date: Thu, 16 Sep 1993 19:52:22 +0200 (MET DST) Cc: netbsd@cbmuucp.commodore.com In-Reply-To: <9309151825.AA05380@cbmmail.commodore.com> from "NetBSD-Admin@cbmuucp.commodore.com" at Sep 16, 93 09:13:54 am X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1058 Status: RO > Just to let you know that he is not alone, I also get the same > "dmanext at end!!!" message if I have SCSI dma enabled in the > kernel. I also get a ton of "DMAINTR should never be entered" > (or something to that effect) messages also. My machine is an > A3000T. Could this be something linked to a proto chip? I refuse to believe this is the proto.. Could someone that suffers from this problem investigate into it a bit? Ie. build some more debugging outputs into the driver, and try to find out what's going on exactly? I can't really debug this, because I don't suffer the problem.. > partition going. It turns out that the kernel would not recognize > the swap partition unless it was on the same drive as the root The *generic* kernel doesn't, if you specify explicit root and swap partition(s) in your config file and build your own kernel, there's no such constraint. -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 Sep 16 20:09:46 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: A2065 work with vmunix.613? Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 14, 6:06pm, Irving Moy wrote: > When I boot NetBSD, I see the a line about le0 appear on the console > which appears to contain the hardware Ethernet address of the A2065 > so I assume the kernel found the Ethernet board. I looked at the The kernel does find the board, but it is not supported under #613. Please use #622 or above to have fulL ethernet support. The network access does work flawlessly. I had my A3000 with A2065 running for several days directly hooked up to the internet without any problems. It is really nice to run trn, elm and so forth on your Amiga :-) -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 20:36:34 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: dump question Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 15, 10:08pm, Markus Wild wrote: > Subject: Re: dump question > > > Is your HP-DAT explicitly recognized by the kernel, or does it use the > > > default parameters ("unsupported tape drive") ? > > > > Yes it seems to be recognized as an HP35450A. I looked at some of the > > kernel code, and see that there is specific code in there to support it. > > Hm, I know we used exactly this drive in Bielefeld at the IRC/Usenet party, > and it worked like a charm, on both A2000/A2091 and A3000 systems. You sure ? We had the DAT-drive from Martin Horneffer, which had no compression modes (the one in the DEC-Box). [...] > Not very likely. As I said, we used this DAT drive on at least 3 different > amigas (A3000, A3000T and A2000/2091 (or gvp, don't remember)), and I > think at least one of those should have a PROTO too. My A3000 has a PROTO and it did work fine. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 20:41:06 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: Howard Dobson , mw@eunet.ch (Markus Wild) Subject: Re: dump question Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 15, 6:06pm, Howard Dobson wrote: > Well I think mine was one of the last 3000s. That could mean they > were out of PROTOs already, or were desparate to get rid of them. > I guess I'll have to take a look and see what it is next time I have > her open. One of the last ? You sure ? There aren't more than abot 30,000 A3000 sold at all. I have serial number 425 though :-) -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 20:47:40 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: David Jones , NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Floppy driver Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 15, 8:05pm, David Jones wrote: > Subject: Floppy driver > I recently read in comp.unix.amiga that a floppy driver is working in Amiga > Linux. Is it possible to work this driver into BSD? He have had this dicussion yet... If you have read my review on c.s.a.r you would have known it, too :-) No, we can't use any of the Linux-Stuff, as it is CopyLeft by GNU. Anyway, there is a floppy-driver in work. As we like to have proper code in C, and not Euro-demo-code, this took a while, thanks in advance to Mykes at this place. Reminds me, we have SCSI-Floppies in our DEC-stations, how much is a SCSI-Floppy (ED) ? :-) -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 21:14:54 1993 Subject: Re: Floppy driver To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Sep 15, 8:05pm, David Jones wrote: > > Subject: Floppy driver > > I recently read in comp.unix.amiga that a floppy driver is working in Amiga > > Linux. Is it possible to work this driver into BSD? > > He have had this dicussion yet... If you have read my review on c.s.a.r > you would have known it, too :-) > > No, we can't use any of the Linux-Stuff, as it is CopyLeft by GNU. Hmmm... I thought I just read today (not sure if it was the BSD or Linux mailing list) that Hamish said the floppy code would be under BSD, not GPL so NetBSD could make use of it... --Ed > -- > Markus Illenseer > -- Edward Savage DG/UX Development Data General Corporation savage@dg-rtp.dg.com 62 T. W. Alexander Drive {backbone}!mcnc!rti!dg-rtp!savage Research Triangle Park, NC 27709 (919) 248-6207 From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 21:35:23 1993 X400-Originator: /DD.ID=1619692/G=Hamish/I=HI/S=Macdonald/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars735.b.224:16.08.93.19.34.29] X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Floppy dr... Sender: "Hamish (H.I.) Macdonald" To: savage@dg-rtp.dg.com Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Floppy driver (fwd) Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> On Thu Sep 16 15:18:00 1993, >>>>> savage@dg-rtp.dg.com wrote: savage> Please clarify the situation below... Didn't you say today(?) savage> that the floppy code would be under the BSD not GPL savage> copyrights? So NetBSD code make use of it? I said that the COMPLETE REWRITE that I plan to do would be released under the BSD copyright. From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 16 23:59:53 1993 Subject: Re: dump question To: markus@techfak.uni-bielefeld.de (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 747 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > Yes it seems to be recognized as an HP35450A. I looked at some of the > > > kernel code, and see that there is specific code in there to support it. > > > > Hm, I know we used exactly this drive in Bielefeld at the IRC/Usenet party, > > and it worked like a charm, on both A2000/A2091 and A3000 systems. > > You sure ? We had the DAT-drive from Martin Horneffer, which had no > compression modes (the one in the DEC-Box). Exactly, because I *know* the BSD kernel recognized his drive, and since it only recognizes ONE HP-DAT right now, it must have been the same thing. -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 Sep 17 02:53:16 1993 Subject: Re: dump question To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL22] Content-Type: text Content-Length: 1014 Sender: NetBSD-Admin@cbmuucp.commodore.com > > On Sep 15, 6:06pm, Howard Dobson wrote: > > Well I think mine was one of the last 3000s. That could mean they > > were out of PROTOs already, or were desparate to get rid of them. > > I guess I'll have to take a look and see what it is next time I have > > her open. > > One of the last ? You sure ? There aren't more than abot 30,000 > A3000 sold at all. I have serial number 425 though :-) > Well I bought it as a closeout at my local C= dealer a couple months ago (for $999). I speculate that it was not an early 3000's based on the date on the Hard drive (Aug 27, 1992). When did they stop makeing the 3000 anyway? Also it is a 120M maxtor instead of the 105M quantums they put in the earlier 3000s. I would have suspected anyway since the 4Meg of fast ram were 1x4 SC zips. I doubt C= would give me a larger hard drive and better memory chips than necessary unless they were tring to get rid of them. I checked the SCSI chip, and it is not a PROTO, it is the -08 version. Later Howard From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 17 04:14:07 1993 X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: Not an Organization Content-Length: 1046 To: netbsd-amiga@cbmuucp.commodore.com Subject: how to test NetBSD on 040 Sender: NetBSD-Admin@cbmuucp.commodore.com I heard that some preliminary 040 support was added to NetBSD. I don't have the disk space right now to run a full blown Unix setup on my Amiga, but I would like to see if it would "boot up" properly on my machine (i.e. if there is any point at all in getting a new hard drive to run NetBSD on). I have absolute zip knowledge of NetBSD... maybe I should't even ask this question here (I assume there are some FAQs, too), but could somebody tell me how (if at all) I can test-run NetBSD without using a dedicated partition? I just added myself to this mailing list... it seems that there is quite a lot being said here. Has anybody ever thought of creating a newsgroup for netbsd? (i.e. comp.sys.amiga.netbsd or comp.os.netbsd.amiga) Thanks, Stefan ,-------------------------------------------------------, |Usenet sgberg@charon.bloomington.in.us Stefan G. Berg| |Internet sgberg@ucs.indiana.edu // AMIGA | |Bitnet sgberg@iubacs GE Mail s.berg5 \X/ w/ bms | `-------------------------------------------------------' From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 17 04:47:00 1993 Subject: Bug in GCC linker? To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL21] Content-Type: text Content-Length: 1655 Sender: NetBSD-Admin@cbmuucp.commodore.com I am having great difficulty compiling Objective-C programs using the GNU Objective-C Library classes under NetBSD. (Anonymous ftp at iesd.auc.dk:pub/ObjC/libcoll-930531.tar.z) The libcoll.a library compiles fine (after fixing two bugs in the file Time.m and making sure the Objective-C includes are in the proper include paths for cpp), but when I try to compile and link the test programs, I get an error message similar to: ld: bad magic number in libcoll.a (#1) It will compile, link, and run fine under AmigaDOS. It doesn't work under NetBSD. After a bit of snooping around, I believe the ld program is screwed up and needs to be fixed. To verify that ld is the culprit, I copied the libcoll.a and libobjc.a (which I had to compile manually, as mtw forgot to include it...oops. :-) ) libraries from the NetBSD filesystem and LINKED them under AmigaDOS. No errors, the test programs worked perfectly! My guess is that Markus forgot to update ld (and as...) when he ported gcc 2.4.5. gcc, after test1.o is generated, is invoked under AmigaDOS as: >gcc -v -g -I. test1.o -o test1 -L.. -lcoll -lobjc Reading specs from gcc:compilers/amigados/2.4.5/specs gcc version 2.4.5 gcc:compilers/amigados/2.4.5/ld -amiga-debug-hunk -o test1 gcc:lib/crt0.o -L.. -Lgcc:compilers/amigados/2.4.5 -Lgcc:lib test1.o -lcoll -lobjc -lgcc -lc -lgcc Under NetBSD, the output is similar, yet the bad magic number error shows up. Does anyone have a solution? I REALLY need to get this working for my UNIX project at school. It can't be done under AmigaDOS. :-( Thanks. --------------------------------------------- Max Leung mleung@eigen.ee.ualberta.ca From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 17 08:05:14 1993 To: mw@eunet.ch Cc: dej@eecg.toronto.edu, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Floppy driver Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Markus W" == Markus Wild writes: Markus W> We definitely *don't* want GPL code in the kernel, so this Markus W> renders the Linux floppy code completely useless to us, Markus W> sorry. Sad to say it but the AmigaDOS filesystem version 1 is based on code which is GPLed. I have had a discussion with the original author, Frank "Crash" Edwards, about his conditions (because I anticipated the GPL reluctance) which resulted in this: Crash> Okay, then; link the AmigaDOS filesystem code into the kernel Crash> and provide the binary. Also provide object files, if that's Crash> the way the other pieces of the kernel are distributed. And Crash> wherever there's a pointer to the source for the kernel, put a Crash> similar mention of the AmigaDOS vfs being available there Crash> also. Crash> On the ftp site, put the AmiVFS filesystem source code into Crash> whatever files contain the source code for the other Crash> filesystems; or put it into the same directory as the other Crash> filesystems on the ftp site. Crash> Basically, I want people to be able to find and use the code as Crash> easily as they could find and use the rest of the NetBSD Crash> package. The VFS code Crash talks about is an AmigaDOS FS implementation for Amiga Unix, which is the implementation I used as a starting point. Are the intent of his last paragraph in any way compatible with any type of copyright we're willing to include into the NetBSD kernel? I suspect we could come to some solution if the involved parties just want to. Maybe it would be best if Markus W. and Crash spoke directly? I'm going to write a version 2 of my FS which will be from scratch, now that I know a bit more of FS writing in general and NetBSD FSs in particular. There's also need for some design changes in order to accomodate for write capabilities. This version will be BSD copyrighted, but it won't be finished in quite some time. Today, version 1 is half-stable, meaning a find . -print of a 10000+ file partition works OK and no memory will have leaked after unmounting the partition after such a walk. The problem is that the caching strategy used is quite memory consumptive when one is dealing with large files in large directories. I have a directory with all my archive files, several of which are larger than 2MB and when tarring this to tape, the kernel will run out of memory resulting in a panic in pmap_enter_ptpage (the STE address won't be mapped resulting in a address fault). This happens for me regularily when doing memory intensive tasks, i.e. not just when using the AmigaDOS FS module. For example, make depend of perl were really hard to get through. Well, I just have 4MB of RAM, tough luck! I will get 4 more MB soon, I suspect. 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 Fri Sep 17 17:12:52 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: sgberg@charon.bloomington.in.us, netbsd-amiga@cbmuucp.commodore.com Subject: Re: how to test NetBSD on 040 Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 16, 9:13pm, Stefan G. Berg wrote: > Subject: how to test NetBSD on 040 > I heard that some preliminary 040 support was added to NetBSD. I don't > have the disk space right now to run a full blown Unix setup on my > Amiga, but I would like to see if it would "boot up" properly on my > machine (i.e. if there is any point at all in getting a new hard drive > to run NetBSD on). I have absolute zip knowledge of NetBSD... maybe I > should't even ask this question here (I assume there are some FAQs, > too), but could somebody tell me how (if at all) I can test-run NetBSD > without using a dedicated partition? You have yet to wait. The FPU code is missing for the complete 040 support. > I just added myself to this mailing list... it seems that there is > quite a lot being said here. Has anybody ever thought of creating a > newsgroup for netbsd? (i.e. comp.sys.amiga.netbsd or > comp.os.netbsd.amiga) Forget about an own group. comp.unix.amiga is the right place. The traffic is not worth an own group. -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 17 23:16:44 1993 To: niklas@appli.se (Niklas Hallqvist) Cc: mw@eunet.ch, dej@eecg.toronto.edu, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Floppy driver <9309170557.AA03113@della.appli.se> X-Phone: (510) 549-3563 X-Mts: smtp Sender: NetBSD-Admin@cbmuucp.commodore.com > Crash> Basically, I want people to be able to find and use the code as > Crash> easily as they could find and use the rest of the NetBSD > Crash> package. if it's under the GPL, then it will not reside in the NetBSD CVS source tree. which means that by it being under the GPL, it becomes *harder* for people to find and use the code than the rest of the NetBSD package. so in other words, the author is screwing himself, in this case, by putting a GPL on it. cgd From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 18 23:11:46 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com Subject: Installation Sender: NetBSD-Admin@cbmuucp.commodore.com Hi. Recently we had a discussion about Amiga NetBSD on the german usenet. The question about the insallation occured, and, more important, the question where to get NetBSD. I would like to discuss if we try to set up a basic installation-tool, something like the 'Installer' for pure AmigaDOS programms. This install-tool should make it easy for the newbie to install Amiga NetBSD on his system. This leads to two major problems: No access from Amiga-DOS to UFS-partitions (not directly) and no floppy-driver. Comments ? Should we wait for the Floppy-Driver first ? As for the 'where to get NetBSD'. I heard Amiga NetBSD is now available on BBS now. Is that true ? I can't believe this, as they have to store more than 20MB (barely) and the download process would take ages. Should we set up a 'Basic NetBSD distribution', something like 'this is all you need to run it' , 'this is what you need to run network' 'this is what you need to be able to compile stuff'. Small files, distinguishable (sp?) and reliable to download, at least for basic tests. Markus Wild also mentioned that he is willing to send Fred Fish (gee FF900 is out, hurry up :-) NetBSD and settle it upon a Fish-CD ? As one can use this CD on both sides, AmigaDOS and AmigaBSD, this solution looks like the best and even fastest to me. (You have but to find someone with a CD-ROM-drive). -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 19 00:51:51 1993 Subject: Re: Installation To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 793 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello Markus! > As for the 'where to get NetBSD'. I heard Amiga NetBSD is now available > on BBS now. Is that true ? I can't believe this, as they have to store > more than 20MB (barely) and the download process would take ages. I maintain some kind of mirror sites on both my FTP Unix system and on my BBS. I know NetBSD is quite large but with Zmodem resume... It doesn't take ages, just a question of hours ;-) -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 20 12:26:27 1993 To: netbsd-amiga@cbmuucp.commodore.com Cc: etmjvro@etmsun.ericsson.se Subject: anyone running netbsd on A2000 with GVP hardware ?? Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I was just wondering if I'm the only one not being able to run netbsd on my GVP equipped Amiga. Are there people who have the GForce cards installed in their A2000's and have netbsd up and running ? Did somebody succeed in re-compiling the kernel for their specific machine ? If so, could I get a copy of the config file and/or the compiled kernel ? I'm still not able to run bsd. recompiling the kernel is a nightmare for me. I tried it, but the linker complains about undefined symbols etc. Pleas, anybody who has got bsd running on their A2000, reply ... Thanx, John Vrolijk From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 20 16:07:28 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: anyone running netbsd on A2000 with GVP hardware ?? Sender: NetBSD-Admin@cbmuucp.commodore.com > From: John Vrolijk > Hi, > I was just wondering if I'm the only one not being able to run netbsd on my GVP equipped > Amiga. > Are there people who have the GForce cards installed in their A2000's and have > netbsd up and running ? Yep, G-Force 030 @ 25 MHz (not the 68EC030 version of course) > Did somebody succeed in re-compiling the kernel for their specific machine ? Yep, but I compiled it on NetBSD itself. I've cross-compiled NetBSD on HP-UX, but I had to do the linking on AmigaOS, and that didn't seem to work quite right (that kernel booted, but did panic strangely during the boot). > If so, could I get a copy of the config file and/or the compiled kernel ? > I'm still not able to run bsd. recompiling the kernel is a nightmare for me. > I tried it, but the linker complains about undefined symbols etc. I can't get my config file easily to the net right now, as I've moved and my Amiga is connected only via Adidas-net (eg. carrying floppies around ;) but I'd say from my experience that don't try to remove those A3000 and A2091 SCSI controller entries from the config file. From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 20 19:57:13 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? To: etmjvro@etmsun.ericsson.se (John Vrolijk) Cc: netbsd-amiga@cbmuucp.commodore.com, etmjvro@etmsun.ericsson.se X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 526 Sender: NetBSD-Admin@cbmuucp.commodore.com > I was just wondering if I'm the only one not being able to run netbsd on my GVP equipped > Amiga. > Are there people who have the GForce cards installed in their A2000's and have > netbsd up and running ? There certainly are. However, perhaps you have another problem, the kernel is currently too large to be loaded with 512k chipmem, is that your problem? -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 Sep 21 09:16:04 1993 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? <199309201758.AA01644@chsun.eunet.ch> Sender: NetBSD-Admin@cbmuucp.commodore.com Hello Markus, I have 1Mbyte chipram, so that shouldn't be the problem. Here is a printout from my configuration: CHIPS: CPU 68030/68882fpu/68030mmu, ECS PAL Agnus, ECS Denise VERS: Kickstart version 37.175, Exec version 37.132, Disk version 37.67 RAM: Node type $a, attribute $205 (FAST), from $200000 to $5fffff Node type $a, attribute $5 (FAST), from $1000000 to $10fffff Node type $a, attribute $5 (FAST), from $800000 to $9fffff Node type $a, attribute $305 (FAST), from $c00000 to $d7ffff Node type $a, attribute $303 (CHIP), from $400 to $fffff BOARDS: RAM (unidentified): Prod=2017/9($7e1/$9) (@$200000 4meg Mem) Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) Board (unidentified): Prod=18260/4($4754/$4) (@$ea0000 64K) Board (unidentified): Prod=18260/6($4754/$6) (@$ec0000 128K) loadbsd just hangs my system. The latest kernel I've tried is 644. Any ideas ?? John From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 21 09:19:41 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? To: etmjvro@etmsun.ericsson.se (John Vrolijk) Cc: mw@eunet.ch, 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: 1727 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hello Markus, > I have 1Mbyte chipram, so that shouldn't be the problem. > Here is a printout from my configuration: > > > CHIPS: CPU 68030/68882fpu/68030mmu, ECS PAL Agnus, ECS Denise > VERS: Kickstart version 37.175, Exec version 37.132, Disk version 37.67 > RAM: Node type $a, attribute $205 (FAST), from $200000 to $5fffff > Node type $a, attribute $5 (FAST), from $1000000 to $10fffff > Node type $a, attribute $5 (FAST), from $800000 to $9fffff > Node type $a, attribute $305 (FAST), from $c00000 to $d7ffff > Node type $a, attribute $303 (CHIP), from $400 to $fffff > BOARDS: > RAM (unidentified): Prod=2017/9($7e1/$9) (@$200000 4meg Mem) > Board + ROM (HD?) (unidentified): Prod=2017/11($7e1/$b) (@$e90000 64K) > Board (unidentified): Prod=18260/4($4754/$4) (@$ea0000 64K) > Board (unidentified): Prod=18260/6($4754/$6) (@$ec0000 128K) > > loadbsd just hangs my system. The latest kernel I've tried is 644. > Any ideas ?? I have the same... PROCESSOR: CPU 68030/68882fpu/68030mmu CUSTOM CHIPS: ECS PAL Agnus (id=$0020), ECS Denise (id=$00FC) VERS: Kickstart version 39.115, Exec version 39.52, Disk version 39.29 RAM: Node type $A, Attributes $605 (FAST), at $280000-$9FFFFF (7.5 meg) Node type $A, Attributes $703 (CHIP), at $400-$FFFFF (~1.0 meg) BOARDS: Initial RAM-containing board configured by KickIt (?) CBM A2630 68030/RAM card: Prod=514/81($202/$51) (@$200000 4meg Mem) CBM A2232 serial production: Prod=514/70($202/$46) (@$E90000 64K) Board + ROM (HD?) (unidentified): Prod=2017/11($7E1/$B) (@$EA0000 64K) RAM (unidentified): Prod=2017/10($7E1/$A) (@$600000 4meg Mem) and mine hangs as well ( only ever tried 644) From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 21 18:12:07 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? (fwd) To: mykes@shell.portal.com (Mike Schwartz) Cc: netbsd-amiga@cbmuucp.commodore.com (nba) X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1286 Sender: NetBSD-Admin@cbmuucp.commodore.com > Forwarded message: > >From jdresser@antares.Tymnet.COM Mon Sep 20 17:32:03 1993 > Date: Mon, 20 Sep 93 17:29:52 PDT > From: jdresser@antares.Tymnet.COM (Jay Dresser) > Message-Id: <9309210029.AA05317@antares.Tymnet.com> > To: mykes@shell.portal.com > Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? (fwd) > > > > There certainly are. However, perhaps you have another problem, the kernel is > > currently too large to be loaded with 512k chipmem, is that your problem? > > I still don't see why they need to move the os to chipmem. Just a poor > programmer I assume? Thank you so much... The reason for the chipmem move is to make loading simple. The kernel is loaded into chipmem, so PA==KVA, then it's copied into the part of available fastmem, and the MMU is turned on to map it back to KVA=0. The approach makes relocating kernels unnecessary (the Amix way), you don't have to play mean games with the MMU when booting BSD until you have the final tables installed, and you don't have to fiddle with manual relocation in the loader either. Looks like clear benefits for the current solution. -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 Sep 21 18:32:31 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? To: thecure@mullian.ee.mu.OZ.AU (matthew aldous) Cc: etmjvro@etmsun.ericsson.se, mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 610 Sender: NetBSD-Admin@cbmuucp.commodore.com > > > > > Hello Markus, > > I have 1Mbyte chipram, so that shouldn't be the problem. > > Here is a printout from my configuration: > > > I have the same... > Ok.. how does "hanging" the system show? Do you get an initial console screen, does it lock up with a gray, a black screen? What message do you get from loadbsd, does it correctly identify your memory (keeping in mind that currently only one, largest bank of fast memory is used)? -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 Sep 22 01:03:46 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: IVS Vector SUpport X-Sun-Charset: US-ASCII Content-Length: 743 Sender: NetBSD-Admin@cbmuucp.commodore.com To all interested parties: NOTE: I am no hardware hacker, flame retardant suit on... I have started a possible dialog with IVS regarding adding support for the IVS Vector card. What I have been asked for is the required technical details that will be needed to add support to the kernel for NetBSD. I currently don't understand how the kernel is actually laid out, but I will look at the source when I get it all unpacked tonight. For example, I suppose we need access to the "raw" SCSI commands that this device supports? Correct? What else? I would love to be able to run NetBSD with my IVS Vector card. :-) :-) I am wandering in the dark, and was hoping that someone else might be able to help. Anyone have any comments? -dvb- From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 22 06:54:47 1993 Subject: Re: New binaries..Internal error in GCC ???. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) Cc: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > Hi, Yesterday I wanted to compile kermit on my > NetBSD machine but ran into a problem. (I do have the new binaries and $644) > The first couple of files compile fine, but when the compiler > gets to a file called ckuus5.c I get the following: > > trapsignal (1626, 11, 8, 8, 10c18) > cc: Sep 14 00:08:34 atze /netbsd: trapsignal (1626, 11, 8 ,8, 10c18) > Internal compiler error: program cpp got fatal signal 11) > Sep 14 00:08:34 atze /netbsd: trapsignal (1626, 11, 8, 8, 10c18). > > gdb then doesn't recon the core as a core file?? (actually gdb doesn't > recognize any coredump as a core file, it did unter #613. I finally had a chance to look at Arthur's core file, and the problem with gdb is that a pointer was added to the pmap structure for 68040 support (yet to come, I guess). gdb does a sanity check on the core file, but because of the added bytes, it wasn't looking at what it thought it was looking at, so it thinks that the core file is much much larger than it ought to be. Oh well. When I get a new kernel built and the new includes installed, I'll make a new gdb and upload it to wuarchive. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 22 08:06:27 1993 To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? <199309211632.AA16790@chsun.eunet.ch> Sender: NetBSD-Admin@cbmuucp.commodore.com Hello Markus, When I run loadbsd vmunix.644, the mouse pointer freezes. loadbsd says "using 4MB FASTRAM at $200000, 1MB chipmem" after that, nothing happens anymore,no hd activity or anything. When I'm running the workbench on my Retina card, the screen stays as it is, that means the workbench screen. When I startup without the retina software, ( holding both mouse buttons during boot etc.), the systems reboots (sometimes) and the screen stays gray, no initial console. I put in some printf statements in loadbsd.c, and the last one that got printed was just before the call to "startit". No hardisk activity anymore after that. I have to reboot manually and then the system starts amigados again. -John From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 22 09:52:35 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? To: etmjvro@etmsun.ericsson.se (John Vrolijk) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > Hello Markus, > When I run loadbsd vmunix.644, the mouse pointer freezes. > loadbsd says "using 4MB FASTRAM at $200000, 1MB chipmem" > after that, nothing happens anymore,no hd activity or anything. > When I'm running the workbench on my Retina card, the screen stays as it is, that > means the workbench screen. When I startup without the retina software, > ( holding both mouse buttons during boot etc.), the systems reboots (sometimes) and the screen > stays gray, no initial console. > I put in some printf statements in loadbsd.c, and the last one that got printed > was just before the call to "startit". No hardisk activity anymore after that. > I have to reboot manually and then the system starts amigados again. > > -John > You have two choices, either: 1. binpatch the kernel so that the display mode is appropriate for the monitor you are using, OR 2. unplug the retina and use the native display. Problem is that turning off the retina emulation isn't enough, the kernel is still able to realise that you have a retina and so sends console output to the retina. Meanwhile you've turned retinaemu off and watching chip mem so nothing appears to be happening, but it is!! (I had _exactly_ the same problem at first). Hope this helps. -Trevor. +----------------------------+----------------------------------------+ | 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 Wed Sep 22 17:45:50 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: New binaries..Internal error in GCC ???. Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 21, 9:54pm, Andy Heffernan wrote: > I finally had a chance to look at Arthur's core file, and the > problem with gdb is that a pointer was added to the pmap structure for > 68040 support (yet to come, I guess). gdb does a sanity check on the I think it may ready sooner than I think. I've finally gotten the FPSP code and have it integrated into the kernel. 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 Wed Sep 22 21:22:21 1993 Subject: Re: IVS Vector SUpport To: dvb@ssd.kodak.com (Dave Blaszyk) Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1901 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have started a possible dialog with IVS regarding adding support for > the IVS Vector card. What I have been asked for is the required > technical details that will be needed to add support to the kernel for > NetBSD. You want to know answers to the following questions: - what controller chip does the board use. Where in the autoconfig'd space of the board are the registers to access that chip. - what kind of DMA controller does the board use (does it use DMA at all). Again, where are the registers of the chip, and (if it's a custom controller chip) how is it programmed. - DMA again: are there limits to the address range the DMA controller can access, i.e. can it DMA into full 32bit address space, or perhaps just into 24bit space (like the 2091 and the GVP-II)? - the best and nicest thing to get would probably be example sources, however, this is also the most unlikely thing you'll get :-) > I currently don't understand how the kernel is actually laid out, but I will > look at the source when I get it all unpacked tonight. For example, > I suppose we need access to the "raw" SCSI commands that this device > supports? Correct? What else? Oops.. just trying to make that clear: we're NOT talking about an (Exec) device here, we're talking at banging at hardware registers... The current scsi driver is HEAVILY 33C93 dependant, we'll have to change to a different layout to support other controller chips. I've seen some interesting work done by Chris Torek for the BSD4.4 scsi driver, but the code is terse, I'll have to look deeper into it... Right now, to support different scsi controllers, you'd have to clone the sd and st drivers, to call functions in your scsi code, not nice, really.. -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 Sep 22 21:50:59 1993 Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? To: etmjvro@etmsun.ericsson.se (John Vrolijk) Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1578 Sender: NetBSD-Admin@cbmuucp.commodore.com > When I run loadbsd vmunix.644, the mouse pointer freezes. > loadbsd says "using 4MB FASTRAM at $200000, 1MB chipmem" Ok, at least it seems to get the amount of chipmem right.. > after that, nothing happens anymore,no hd activity or anything. > When I'm running the workbench on my Retina card, the screen stays as it is, that > means the workbench screen. When I startup without the retina software, > ( holding both mouse buttons during boot etc.), the systems reboots (sometimes) and the screen > stays gray, no initial console. Eh, I think I never mentioned this.. you *HAVE* to run loadbsd from a running RetinaEmu, or the kernel will hang.. It must have something to do with the Retina autoconfig logic, I guess, as ShowConfig says the board is not yet configured as long as you don't start the emulation. I'd probably have to do some BindDrivers-magic in BSD, I don't particularly like this idea... > I put in some printf statements in loadbsd.c, and the last one that got printed > was just before the call to "startit". No hardisk activity anymore after that. > I have to reboot manually and then the system starts amigados again. Ok, then it could have crashed anywhere in the kernel init... Do you have an external terminal you can hook to the RS232? Perhaps running the console there temporarily could help you trace down the problem? To do this, do: binpatch -s _which_console -r 2 vmunix -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 Sep 23 00:15:07 1993 Subject: scheme to NetBSD 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 I just compiled scm4c4, a scheme compiler to on NetBSD. The compilation was a piece of cake - only had to uncomment DISABLE-FTIME in time.c. Those who want it: The original package is available in: altdorf.ai.mit.edu:archive/scm/scm4c4.tar.gz prep.ai.mit.edu:pub/gnu/jacal/scm4c4.tar.gz nexus.yorku.ca:pub/scheme/new/scm4c4.tar.gz There are makefiles even for non-unix-Amigas :-) I'll try to port MIT-scheme too and if it succeeds, I'll upload the binaries. MIT-scheme is written in... scheme. I don't know yet, how difficult it will be to compile 10 Megs of scheme code :-) Anyway, scm4c4 was stable and fast. /robin -- Jarto Tarpio robin@vipunen.hut.fi IRC: rbn From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 23 00:44:21 1993 Subject: Re: scheme to NetBSD To: robin@vinkku.hut.fi Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.4 PL20] Content-Type: text Content-Length: 1222 Sender: NetBSD-Admin@cbmuucp.commodore.com > I just compiled scm4c4, a scheme compiler to on NetBSD. The compilation > was a piece of cake - only had to uncomment DISABLE-FTIME in time.c. I don't know what the alternatives to ftime are in that program, if they support gettimeofday() don't hesitate to nuke ftime, but if they resort to rather SV-ish sillyness with global variables, reenable ftime and link with -lcompat. > I'll try to port MIT-scheme too and if it succeeds, I'll upload the > binaries. MIT-scheme is written in... scheme. I don't know yet, how > difficult it will be to compile 10 Megs of scheme code :-) Nah.. MIT-scheme is C.. at least that version 7.x I tried to compile ages ago for Amiga Unix was C. You should have a far easier life with NetBSD anyway, as I had programs such as MIT-scheme and GNU emacs in mind when deciding where to put the per process user address space.. (contrary to the @#$#@ location of that space in Amiga Unix...). Try to configure for sun3 and sit back :-) (Oh, I never tried this adventure, that would just be the road I'd try my luck on...). -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 Sep 23 06:41:00 1993 Subject: Boot hangs with new /sbin To: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I decided I wanted to start building NetBSD under NetBSD and have room to install more of the system, so I reconfigured my disks. Then I loaded the rootfs, which as far as I can tell has not been updated since the first one that Markus W. uploaded. Let me know if there is a newer one. After the normal setup changes, the system would boot just fine. It even booted fine after loading the bin-usr.sbin and bin-usr.bin archives. The booting to multi-user also works. After loading bin-bin, it still worked. However, after I loaded bin-sbin the boot would hang after detecting all the SCSI devices. There were no messages other than those in a normal boot and the SCSI bus was not hung, no solid disk activity light. Fortunately, I used devtofile to save the root partition before loading the bin-sbin archive, so I can use filetodev to get back to where I was. System setup: A3000 2M chip 8M fast Qunatum 105M ID=6 Syquest 88M ID=5 WangTek ID=2 NetBSD is on the SyQuest and I have patched the 644 kernel to turn off Synchronous on ID 2 & 5. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 23 07:10:54 1993 Subject: 644 debug support To: netbsd-amiga@cbmuucp.commodore.com (NetBSD-Amiga Mailing List) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com This is probably old news (just got around to building 644), but the diffs for single-step and breakpoints aren't there (all the other ones I had a vested interest were there, though -- wheeeeee!). *** sys/kern/sys_process.c-orig Tue Jul 13 15:13:19 1993 --- sys/kern/sys_process.c Tue Sep 21 23:00:43 1993 *************** *** 337,342 **** --- 337,345 ---- #ifdef i386 p->p_regs[(curpcb->pcb_flags&FM_TRAP)?tEIP:sEIP] = (int)ipc.addr; #endif + #ifdef mc68020 + p->p_regs[PC] = (int)ipc.addr; + #endif } p->p_flag &= ~SSTRC; /* Only set by PT_SYSCALL */ if ((unsigned)ipc.data >= NSIG) { *************** *** 359,364 **** --- 362,373 ---- } p->p_regs[(curpcb->pcb_flags&FM_TRAP)?tEFLAGS:sEFLAGS] |= PSL_T; #endif + #ifdef mc68020 + if (ipc.addr != (int *)1) { + p->p_regs[PC] = (int)ipc.addr; + } + p->p_regs[PS] |= PSL_T; + #endif p->p_flag &= ~SSTRC; /* Only set by PT_SYSCALL */ p->p_xstat = 0; rv = 1; *************** *** 369,374 **** --- 378,386 ---- if (ipc.addr != (int *)1) { #ifdef i386 p->p_regs[(curpcb->pcb_flags&FM_TRAP)?tEIP:sEIP] = (int)ipc.addr; + #endif + #ifdef mc68020 + p->p_regs[PC] = (int)ipc.addr; #endif } p->p_flag |= SSTRC; -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 23 07:51:18 1993 To: Trevor Elbourne Cc: mw@eunet.ch, netbsd-amiga@cbmuucp.commodore.com Subject: Re: anyone running netbsd on A2000 with GVP hardware ?? <199309220752.AA24512@moule.vast.unsw.edu.au> Sender: NetBSD-Admin@cbmuucp.commodore.com >>You have two choices, either: >> 1. binpatch the kernel so that the display mode is appropriate >>for the monitor you are using, OR >> 2. unplug the retina and use the native display. >>Problem is that turning off the retina emulation isn't enough, the >>kernel is still able to realise that you have a retina and so sends >>console output to the retina. Meanwhile you've turned retinaemu off >>and watching chip mem so nothing appears to be happening, but it is!! >>(I had _exactly_ the same problem at first). >>Hope this helps. Alas, it didn't. I opened my system last night, removed the retina card and my vlab frame grabber and then tried to startup netbsd. Result: the same. the system reboots and then hangs with a gray screen, no disk activity. -John From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 11:07:19 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: ppp0 down, not running Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I have still got problems with ppp. I recompiled the kernel 644 with one ppp interface ppp0. When NetBSD comes up, ppp0 has only the flag POINTTOPOINT. As I know from the kernel sources, the flag RUNNING will be set, when the routine pppopen is called. The pppd calls this routine, but terminates with a syslog 'pppd: write'. Is the pppd buggy, or is it my fault ? Please help. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 15:44:34 1993 To: netbsd-amiga@cbmuucp.commodore.com Organization: H”gskolan i J”nk”ping Subject: Installation X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v2.3 (R5). Sender: NetBSD-Admin@cbmuucp.commodore.com I give up! I have tried to successfully install the Amiga-NetBSD for over a week now, and the furthest I've got is as far as the "FAQ" goes i.e. I have managed to install the rootfs and startup the NetBSD but then, I can only start the NetBSD again randomly (i.e. I get "no suitable root" 9 times out of 10). I have tried to start both from wshell on a booted system and from shell on a "no startup-sequence" system. When I eventually get into the NetBSD, I can't make anything useful since the transfer of the .tgz files doesn't seem to work either! :( My system looks like this: A3000T 16Mb FAST 2Mb CHIP 1 Quantum LPS240 HD SCSI-ID 6 1 Seagate 3283N HD SCSI-ID 5 (This is dedicated to NetBSD) 1 SyQuest 5110C HD SCSI-ID 4 This is what I usually get from the bootup: realmem=16777216 availmem=14655488 using 204 buffers containing 1671168 bytes of memory dms0: A3000 32bit DMA scsi0: scsi id 7 a3000scsi0 [1/1] sd4: SyQuestSq5110 rev D2B, 173456 512 byte blocks sd4 at a3000scsi0, slave 4 scsi0: target 5 now synchronus, period=208ns, offset=6 sd5: Seagate ST3283N rev 9303, 485601 512 byte blocks sd5: at a3000scsi0, slave 5 scsi0: target 6 now synchronus, period=208ns, offset=8 sbic_wait TIMEO @ 1179 with asr=x0 csr=x41 Realtime clock A3000 rtclock0 [1/4] par0 [1/6] grf0: 704x464 monochrome customchips display grf0 [1/7] ser0 [1/3] no suitable root My HD setup look like this: BSD_ROOT start 2 BSDR end 50 BSD_SWAP start 52 BSDS end 239 BSD_USR start 240 BSDD end 533 BSD_PROJ start 534 BSDE end 828 BSD_OPT start 829 BSDF end 1127 BSD_HOME start 1128 BSDG end 1250 BSD_HOME2 start 1251 BSDH end 1390 Blocks/track: 349 Startblock = BPT * starcylinder = 349 * 2 = 698 Size = BPT * (Endcylinder - Startcylinder) = 349 * (50 - 2) = 16752 I do have the newest version of LoadBSD (since the coder didn't incorporate any $VER info it's really hard to tell, but I have FTP'd it (along with all the other files) from ftp.eunet.ch. I read that the D7 register sometimes could be a non-zero value and therefore interfer with the boot, asking for the boot drive (sd%d). This has occured to mee too, but not very often. I have re installed the rootfs about 5-6 times by now.... and tried on vmunix.613 635 and 644. I would REALLY like some help with this, as I'm eager to get the system up and running (now that I have got a new HD just for that!) So please, if you have any suggestions or hints, I'd really appreciate it. Thanks in advance, Anders Ahl (Also, fixing the bug that makes 16Mb machines hang on reboot would be nice, as it's quite annoying having to powercycle the machine! :) ) ---------------------------------------------------------- | Anders Ahl | Tel:+46-36-164732 | | Brahegatan 19, II | e-Mail:d92-aha@tekn.hj.se | | S-553 34 J|nk|ping | | | SWEDEN | | ---------------------------------------------------------- | Running on: A3000T/480/18, SyQuest 5110C, USR DS 16.8k | | ONLY AMIGA MAKES IT POSSIBLE! | ---------------------------------------------------------- From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 17:15:30 1993 Subject: Re: Installation To: D92-aha@tekn.hj.se 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: 1262 Sender: NetBSD-Admin@cbmuucp.commodore.com > I would REALLY like some help with this, as I'm eager to get the > system up and running (now that I have got a new HD just for that!) > So please, if you have any suggestions or hints, I'd really > appreciate it. Try setting all your harddisks to inhibit sync handshake at startup. Your syquest already managed to come "magically" inhibited, because #4 has set the inhibit flag by default. Now, inhibit #5 and #6 too. You do this by using binpatch, which you can get from ftp.eunet.ch (also get the binpatch.README file, please). Then, do binpatch -s _inhibit_sync vmunix note the address which is printed (ADDR), then calculate NADDR=ADDR+5, and do binpatch -b -a NADDR -r 1 vmunix and increment NADDR once (for unit 6), and repeat the above command. > (Also, fixing the bug that makes 16Mb machines hang on reboot would be > nice, as it's quite annoying having to powercycle the machine! :) ) Grr.. I hoped this bug was fixed in the meantime.. if it's not, somebody tell me please what to do to reboot a 16M machine safely.. (I *do* use the official Commodore reboot sequence..). -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 Sep 24 17:40:03 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Sender: NetBSD-Admin@cbmuucp.commodore.com > sbic_wait TIMEO @ 1179 with asr=x0 csr=x41 > Realtime clock A3000 > rtclock0 [1/4] > par0 [1/6] > grf0: 704x464 monochrome customchips display > grf0 [1/7] > ser0 [1/3] > no suitable root I noted this problem after playing with the BFFS system and marking my Unix partitions as AutoBoot YES in HDToolBox because I wanted to see the unix partitions from AmigaDos. Markus, warned us that someone could get confused. Restoring my rootfs didn't seem to help. And I don't believe you have to get that drastic. You want to force HDToolBox to write your drive information to the disk. What I did was go the the rootfs partition, made sure AutoBoot No was set and then changed my filesystem type to something other than the legal value like 0x44, I then saved the configuration from the top menu keeping my fingers crossed after the requestor appeared that information on BSD_ROOT would be destroyed, I said continue. I then went back to the rootfs partition and changed the file system type back to the proper value. If this doesn't work..................... There is a correction that needs to be made to the FAQ, actually several. The starting block = Blocks/Cylinder*starting cylinder and --not-- Blocks/Track*starting cylinder Also to be nit picky, the size = Blocks/Cylinder(end cyl - start cyl + 1) since the size is inclusive. As always I have performed all the above operations, and they work for me. I am not accountable for any damage that could be done by using the above information. -Rob From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 18:12:20 1993 Subject: Re: Installation To: D92-aha@tekn.hj.se Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I give up! BSD builds stronger bodies 12 different ways -- never give up! [...] > no suitable root > > My HD setup look like this: > > BSD_ROOT start 2 BSDR > end 50 Don't reserve 2 blocks at the start of your root partition. In hdtoolbox, go to that partition and change the reserved blocks value from 2 to 0. Rewrite the root partition from root.tgz for safety's sake, and then try the loadbsd again. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 18:41:38 1993 Subject: Re: Installation To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com > There is a correction that needs to be made to the FAQ, actually several. are you sure? do we think of the same faq? the faq on ftp.eunet.ch in blablablub/incoming? ciao From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 19:34:34 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Sender: NetBSD-Admin@cbmuucp.commodore.com I was referring to the FAQ dated on or about July 1993 taken from software/os/bsd/NetBSD/NetBSD-Amiga/FAQ I wasn't aware the FAQ was in incoming....holdon .... That FAQ is correct, but since I didn't have AmigaGuide when I installed at the time it took me an iteration to figure out the info in : software/os/bsd/NetBSD/NetBSD-Amiga/FAQ is incorrect and should still be corrected! -Rob From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 19:41:22 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Installation Sender: NetBSD-Admin@cbmuucp.commodore.com I take that back that FAQ in incoming still needs to be corrected from: Blocks per Cylinder * (End Cylinder - Start Cylinder) = size to: Blocks per Cylinder * (End Cylinder - Start Cylinder + 1) = size Since the size is inclusive example: If start and end cylinder were equal and Blocks per cylinder = 98 Then 98 *(1425 -1425) = 0 which is silly. It should be 1. -Rob From NetBSD-Admin@cbmuucp.commodore.com Fri Sep 24 22:59:31 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: localtime / process struct size Sender: NetBSD-Admin@cbmuucp.commodore.com NetBSD happily installed on my GVP/A2000 and came up first try (!). Couple of problems: 1) I have to `export TZ=' to avoid segfaults in anything that uses the date. I was under the impression that if /usr/share/zoneinfo/localtime was linked to the appropriate timezone file, then all would be well. I then skimmed the tzset(3) man page which mentioned that if TZ wasn't there, it would use /etc/locatime, so I linked one there too. Still segfaults unless I tell it to use straight GMT (TZ=). 2) `ps' complains that the process struct isn't the size it thinks it should be. Am I overlooking something, or was the supplied `ps' compiled for a different kernel? If so, where can I get the sources? 3) The permissions on a couple of files/dirs in the rootfs were slightly off. I think I nailed the obvious ones, anyone have a complete list? Nice work Markus (and contrib people). Hat's off. -wps From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 00:06:29 1993 Subject: Re: Installation To: leland@wacky.acet.org (Robert Leland - PSI) 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: 506 Sender: NetBSD-Admin@cbmuucp.commodore.com > > I was referring to the FAQ dated on or about July 1993 > taken from software/os/bsd/NetBSD/NetBSD-Amiga/FAQ > I wasn't aware the FAQ was in incoming....holdon .... > > That FAQ is correct, but since I didn't have AmigaGuide Oops.. didn't see there was an update in incoming. I moved it out of incoming into the main directory again. -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 Sep 25 00:24:37 1993 Subject: Re: localtime / process struct size To: groo@menger.eecs.stevens-tech.edu (Bill Squier) 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: 1867 Sender: NetBSD-Admin@cbmuucp.commodore.com > NetBSD happily installed on my GVP/A2000 and came up first try (!). You must have done something wrong, that's unusual :-)) > 1) I have to `export TZ=' to avoid segfaults in anything that uses the date. > I was under the impression that if /usr/share/zoneinfo/localtime was linked You were there almost.. the localtime symlink must go into /etc, and should point to - in my case - /usr/share/zoneinfo/CET (replace by your own timezone). > to the appropriate timezone file, then all would be well. I then skimmed the > tzset(3) man page which mentioned that if TZ wasn't there, it would use > /etc/locatime, so I linked one there too. Still segfaults unless I tell it > to use straight GMT (TZ=). You HAVE to use the new binaries, the old ones (and of course, binaries you linked yourself with the old libraries) include the old, buggy ctime.o object file, which core dumps if there is a /usr/share/zoneinfo directory. The new binaries shouldn't core dump!? > 2) `ps' complains that the process struct isn't the size it thinks it should be. > Am I overlooking something, or was the supplied `ps' compiled for a different > kernel? If so, where can I get the sources? Hm... you *are* using the new binaries, are you? The rootfs distributed is still very old, so it should be updated one day too. It serves to bootstrap the system, nothing more. You should then replace the bin and sbin directories with the new distribution. > 3) The permissions on a couple of files/dirs in the rootfs were slightly off. > I think I nailed the obvious ones, anyone have a complete list? Yep, same thing here. rootfs is old, the permissions in the new bin-* distribs should be ok. -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 Sep 25 01:30:21 1993 Subject: Replacing binaries in rootfs To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Markus Wild commented on Bill Squier's posting: > > 2) `ps' complains that the process struct isn't the size it thinks it should be. > > Am I overlooking something, or was the supplied `ps' compiled for a different > > kernel? If so, where can I get the sources? > > Hm... you *are* using the new binaries, are you? The rootfs distributed is still > very old, so it should be updated one day too. It serves to bootstrap the system, > nothing more. You should then replace the bin and sbin directories with the new > distribution. > > > 3) The permissions on a couple of files/dirs in the rootfs were slightly off. > > I think I nailed the obvious ones, anyone have a complete list? > > Yep, same thing here. rootfs is old, the permissions in the new bin-* distribs > should be ok. > This is what I recently posted about doing, updating rootfs with the new binaries, and it made the system hang during the booting process. It seems that the new sbins are the ones that caused the system to hang. If I could get a working rootfs with the new binaries, I would be willing to make a new rootfs to replace the current old one. Any comments on which kernel and binpatches it should contain? -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 02:37:28 1993 Subject: Re: localtime / process struct size To: mw@eunet.ch (Markus Wild) Cc: groo@menger.eecs.stevens-tech.edu, netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > 2) `ps' complains that the process struct isn't the size it thinks it should be. > > Am I overlooking something, or was the supplied `ps' compiled for a different > > kernel? If so, where can I get the sources? > > Hm... you *are* using the new binaries, are you? The rootfs distributed is still > very old, so it should be updated one day too. It serves to bootstrap the system, > nothing more. You should then replace the bin and sbin directories with the new > distribution. Aauuuughh!! Update /vmunix!!! Aaauughhhh!!! [...collapses in a heap on the floor -- it's been a tough week...] -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 02:47:39 1993 Subject: Re: Replacing binaries in rootfs To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: mw@eunet.ch, 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: 1635 Sender: NetBSD-Admin@cbmuucp.commodore.com > This is what I recently posted about doing, updating rootfs with the new > binaries, and it made the system hang during the booting process. It seems > that the new sbins are the ones that caused the system to hang. If I could I think the problem is that the new binaries now include named, the old rootfs didn't. So, on going multiuser, named is started, and unless you changed them, it's configured for *my* place.. Net effect: named can't reach any root domain servers, and is thus unable to answer any queries. The first client to suffer from this is probably sendmail, which is started in /etc/rc, and thus your booting seems to hang (it isn't really, but it takes a centory for all clients to time out..). The fix is easy: don't start named in /etc/rc unless you have an internet connection, and root domain servers are reachable. > get a working rootfs with the new binaries, I would be willing to make a > new rootfs to replace the current old one. Any comments on which kernel and > binpatches it should contain? I'd suggest you go for #644. Binpatches shouldn't probably be needed, as any inhibit_sync[] set for device XY might work on one system, and would be deadly on another system. These things really have to be done on a per- installation basis. Anyway, it doesn't matter whether the kernel installed as /vmunix differs from the one used to boot BSD just by some changed bytes, as long as they have data at the same address, kvm.c will be happy. -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 groo@menger.eecs.stevens-tech.edu Sat Sep 25 04:08:48 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA27725; Fri, 24 Sep 93 22:08:20 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA13963; Fri, 24 Sep 93 22:08:01 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA27710; Fri, 24 Sep 93 22:07:58 EDT Received: by menger.eecs.stevens-tech.edu id <5257>; Fri, 24 Sep 1993 22:07:50 -0400 From: Bill Squier To: netbsd@cbmuucp.commodore.com Subject: grumble grumble grumble Message-Id: <93Sep24.220750edt.5257@menger.eecs.stevens-tech.edu> Date: Fri, 24 Sep 1993 22:07:50 -0400 Status: RO There should be some INDEX file on ftp.eunet.ch which details what files are what. All the docs are from around June/July (not that I want _Markus_ working on that, better we have him chained to the editor/compiler :) ) and half the files those docs reference don't even exist anymore. Still and all, nice work. Any estimate on when we'll get non-contiguous memory support working? My time for development is limited (I'm chained to a PC writing C++ apps for non-computer dweebs to pay the bills, while going to school full time) but I'd be willing to kick in some effort. Maybe I'll peruse the memory related source this evening... -wps From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 09:05:55 1993 Subject: Re: Replacing binaries in rootfs To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > I think the problem is that the new binaries now include named, the old rootfs > didn't. So, on going multiuser, named is started, and unless you changed them, > it's configured for *my* place.. Net effect: named can't reach any root domain > servers, and is thus unable to answer any queries. The first client to suffer > from this is probably sendmail, which is started in /etc/rc, and thus your > booting seems to hang (it isn't really, but it takes a centory for all > clients to time out..). The fix is easy: don't start named in /etc/rc unless > you have an internet connection, and root domain servers are reachable. Yep, that was the problem. Commenting out named allowed the booting to multi user complete. There are some errors with timed and routed about not being able to bind, should these also be commented out since they are also related to networking? The next problem I ran into was that init could not find getty. It turns out to boot multi-user you need to not only install the old rootfs and update the /bin & /sbin, but also load at least /usr/bin, /usr/sbin and /usr/libexec. It looks like /usr/share may also be needed, at least to get termcap entries. (The FAQ needs an update on this, since you released the new binaries.) > > > get a working rootfs with the new binaries, I would be willing to make a > > new rootfs to replace the current old one. Any comments on which kernel and > > binpatches it should contain? > > I'd suggest you go for #644. Binpatches shouldn't probably be needed, as > any inhibit_sync[] set for device XY might work on one system, and would be > deadly on another system. These things really have to be done on a per- > installation basis. Anyway, it doesn't matter whether the kernel installed > as /vmunix differs from the one used to boot BSD just by some changed > bytes, as long as they have data at the same address, kvm.c will be happy. OK, that sounds reasonable now that I think about it. I start working on as generic a rootfs as I can manage. Turning off things like named will be #1 on the list. > > -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 > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 16:51:51 1993 Subject: Re: Replacing binaries in rootfs To: abair@amcu-tx.sps.mot.com (Alan Bair) Cc: mw@eunet.ch, 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: 915 Sender: NetBSD-Admin@cbmuucp.commodore.com > Yep, that was the problem. Commenting out named allowed the booting to multi > user complete. There are some errors with timed and routed about not being > able to bind, should these also be commented out since they are also related > to networking? You can if you want, although those don't disturb the rest of the system, they may just fail, but so what :-) > (The FAQ needs an update on this, since you released the new binaries.) Ok, FAQ writers out there, heared this? > OK, that sounds reasonable now that I think about it. I start working on as > generic a rootfs as I can manage. Turning off things like named will be #1 > on the list. Great! I didn't because my current rootfs would need major cleanup to make it "generic" again... -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 Sep 25 17:13:18 1993 To: netbsd-amiga@cbmuucp.commodore.com Organization: H”gskolan i J”nk”ping Subject: Re: Installation X-Pmrqc: 1 Priority: normal X-Mailer: Pegasus Mail v2.3 (R5). Sender: NetBSD-Admin@cbmuucp.commodore.com > > My HD setup look like this: > > > > BSD_ROOT start 2 BSDR > > end 50 > > Don't reserve 2 blocks at the start of your root partition. In > hdtoolbox, go to that partition and change the reserved blocks value > from 2 to 0. Rewrite the root partition from root.tgz for safety's > sake, and then try the loadbsd again. Believe me, I have tried that! :) But HDToolBox "beeps" and replaces the 0 with a 2 again! Maybe I have to change someother things first? Or is that something that Seagate Drives "do" ? /AA ---------------------------------------------------------- | Anders Ahl | Tel:+46-36-164732 | | Brahegatan 19, II | e-Mail:d92-aha@tekn.hj.se | | S-553 34 J|nk|ping | | | SWEDEN | | ---------------------------------------------------------- | Running on: A3000T/480/18, SyQuest 5110C, USR DS 16.8k | | ONLY AMIGA MAKES IT POSSIBLE! | ---------------------------------------------------------- From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 17:39:51 1993 Subject: Re: Installation To: D92-aha@tekn.hj.se Cc: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Maybe you are both talking about the same thing, but just to make sure... > > > > My HD setup look like this: > > > > > > BSD_ROOT start 2 BSDR > > > end 50 > > > > Don't reserve 2 blocks at the start of your root partition. In > > hdtoolbox, go to that partition and change the reserved blocks value > > from 2 to 0. Rewrite the root partition from root.tgz for safety's > > sake, and then try the loadbsd again. It is true you don't want any space reserved, which is defined in the second level screen, "File System Characteristices", the same place you set "Custom File System". Both fields under reserved blocks, beginning and end, should be set to 0. > > Believe me, I have tried that! :) But HDToolBox "beeps" and replaces > the 0 with a 2 again! Maybe I have to change someother things first? If it is the reserved blocks I described above, make sure you have clicked on the "Custom File System" first. However, on the "Partitioning" screen, the very first partition in the fuel gauge will always start at cylinder 2. The first two cylinders are where the RDB and filesystem code is stored. HDToolBox will set this to at least 2 if you try to change it and it may beep at you too. > Or is that something that Seagate Drives "do" ? > > /AA > > ---------------------------------------------------------- > | Anders Ahl | Tel:+46-36-164732 | > | Brahegatan 19, II | e-Mail:d92-aha@tekn.hj.se | > | S-553 34 J|nk|ping | | > | SWEDEN | | > ---------------------------------------------------------- > | Running on: A3000T/480/18, SyQuest 5110C, USR DS 16.8k | > | ONLY AMIGA MAKES IT POSSIBLE! | > ---------------------------------------------------------- > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Sat Sep 25 20:19:34 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: process wierdness Sender: NetBSD-Admin@cbmuucp.commodore.com I updated /vmunix (duh, slap slap slap, whap) and ps seemed to work fine, but now `root' can't ps, and "regular" users can only `ps' their own stuff (ie, `ps -alx' hangs). I think I might have missed a `-b' once when I was binpatch'ing /vmunix for sync. scsi, so I'll reinstall the kernel and see if that clears it up. Also, anyone note this behaviour: log in as a regular user (something not in the "root" GID/PID). While you're their, do a "login root", and exit that process. When you return, finger, w, etc. all think root is still logged in, and I think a few other things from the root process may be infilitrating the user environment, I'll have to do some more experiments. Oh yeah, almost forgot: where's `cron'? Doesn't seem to be in any of the distribution files... -wps From NetBSD-Admin@cbmuucp.commodore.com Sun Sep 26 12:26:19 1993 Subject: Re: process wierdness To: groo@menger.eecs.stevens-tech.edu (Bill Squier) 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: 1490 Sender: NetBSD-Admin@cbmuucp.commodore.com > I updated /vmunix (duh, slap slap slap, whap) and ps seemed to work fine, > but now `root' can't ps, and "regular" users can only `ps' their own There's a bug in the kvm module that shows as soon as u-areas of processes are paged out. I didn't look into thus any deeper, because there were rumours that a non-machdep replacement was ready very soon... > stuff (ie, `ps -alx' hangs). I think I might have missed a `-b' once when > I was binpatch'ing /vmunix for sync. scsi, so I'll reinstall the kernel > and see if that clears it up. Nah, the problem is different :-) > Also, anyone note this behaviour: log in as a regular user (something not > in the "root" GID/PID). While you're their, do a "login root", and exit > that process. When you return, finger, w, etc. all think root is still > logged in, and I think a few other things from the root process may be > infilitrating the user environment, I'll have to do some more experiments. Hm.. login should not be called as sub-session, only as overlay. I think login just scribbles over the utmp entry for the respective tty, and expects getty to clean up after it. So, if you return to a previous session, you're using a doomed entry... > Oh yeah, almost forgot: where's `cron'? Doesn't seem to be in any of the > distribution files... /usr/libexec/crond. -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 Sep 26 23:44:48 1993 Subject: direct addressing causes timing violations? To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com Hi Netbsders, I wonder if the problems with sync and other of the A3000 scsi-driver could be caused by the direct addressing of this driver. I tested the WD33C93B in my A3000T and it seems to work most of the time. Booting under ADOS needs several reboots until it works and i have sometimes read-errors but these are not repeatable. Netbsd seems to work too. Only sometimes "dmanext at end" errors while fscking or so. The A3000T has A0 pin connected to A1 and not to ground as it "should" be as it is stated for the WD33C93B in the manual for direct addressing (multiplexed address/data busses). By tying Ale to ground indirect addressing is enabled what is the case in my amiga. perhaps the netbsd-scsidriver uses indirect addressing? then forget what i said... ciao From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 00:25:48 1993 Subject: Re: direct addressing causes timing violations? To: chammer@hrz.uni-bielefeld.de 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: 436 Sender: NetBSD-Admin@cbmuucp.commodore.com > perhaps the netbsd-scsidriver uses indirect addressing? then forget what > i said... Huh.. all controllers incl. A3000 use indirect addressing, they provide the addr and data registers, that's all. That's no software option, btw, so it's not at all a NetBSD issue.. -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 groo@menger.eecs.stevens-tech.edu Mon Sep 27 00:29:11 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA29704; Sun, 26 Sep 93 19:28:23 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA14783; Sun, 26 Sep 93 19:28:05 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA29695; Sun, 26 Sep 93 19:27:58 EDT Received: by menger.eecs.stevens-tech.edu id <5250>; Sun, 26 Sep 1993 19:27:49 -0400 From: Bill Squier To: netbsd@cbmuucp.commodore.com Subject: /etc/ttys Message-Id: <93Sep26.192749edt.5250@menger.eecs.stevens-tech.edu> Date: Sun, 26 Sep 1993 19:27:36 -0400 Status: RO Just one quick question: I don't suppose that NetBSD supports both incoming and out going communication on the same tty (obviously not at the same time). I know that SunOS (and maybe AIX) get around it by allowing two entries for the same terminal in the /etc/ttys file, with different /dev names, and depending on which one you address, you get one way or the other. (ie, right now to use the internal serial port for the modem and a terminal, I'm constantly changing /etc/ttys and `kill -HUP 1' to make `init' stop or start a getty on the line. -wps (full of questions today) From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 04:29:11 1993 Subject: Problems with time and Syncronous transfers. 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: 966 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, Ever since I installed the new binaries I had problems with some old programs core dumping. I then read that I should create a link "localtime" in /etc to my own time zone, which I did. I linked it to /usr/share/......./Australia/North. Now my time is wrong. Date shows a value which is exactly 9.5 hours too far. I thought it might have to do with the timezone used when compiling the kernel, so I changed the value in the src/sys/....../conf/AMIGA file and recompiled, but it didn't help. The only thing it changed was that now my disk drive doesn't work in syncronous mode anymore, which it did before. I had to binpatch the new kernel. Does anyone know what might be wrong here? Actually I noticed it before that when I compile kernels myself that most of them make NetBSD hang when the disks are set to syncronous. (even I didn't change anything on the source for the kernel). Thanks. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From groo@menger.eecs.stevens-tech.edu Mon Sep 27 04:40:44 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA29961; Sun, 26 Sep 93 23:41:25 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA14851; Sun, 26 Sep 93 23:41:07 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA29952; Sun, 26 Sep 93 23:41:02 EDT Received: by menger.eecs.stevens-tech.edu id <5250>; Sun, 26 Sep 1993 23:40:46 -0400 From: Bill Squier To: netbsd@cbmuucp.commodore.com Subject: network hassles Message-Id: <93Sep26.234046edt.5250@menger.eecs.stevens-tech.edu> Date: Sun, 26 Sep 1993 23:40:34 -0400 Status: RO Just to keep my sanity, what parts of the network stuff should we be starting (if any) in /etc/rc if we AREN'T on any network? I'm from the time when if someone said "hey, are you on the network?" I'd say "Well, let's see, I call out every 4 hours at 15 past the hour to 'dweyr', and on demand to 'castle', and I haven't checked uucppublic to see if we have any new files today." ..and all my TCP/IP experience has been on machines that really _are_ on a network! -wps From groo@menger.eecs.stevens-tech.edu Mon Sep 27 04:47:20 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA29982; Sun, 26 Sep 93 23:47:53 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA14854; Sun, 26 Sep 93 23:47:34 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA29973; Sun, 26 Sep 93 23:47:28 EDT Received: by menger.eecs.stevens-tech.edu id <5250>; Sun, 26 Sep 1993 23:47:22 -0400 From: Bill Squier To: netbsd@cbmuucp.commodore.com Subject: re: Problems with time and Syncronous transfers. Message-Id: <93Sep26.234722edt.5250@menger.eecs.stevens-tech.edu> Date: Sun, 26 Sep 1993 23:47:21 -0400 Status: RO Sounds to me like you had set the date before installing the new binaries and the symlink from /etc/localtime. Unless I'm mistaken, you're dealing with raw GMT time at that point, so when zoneinfo/Australia/North kicked in, it took what it thought was GMT time in your system clock (which was actually Australia time) and offset it to what it thought should be Australia time (which is now too much of an offset). Re-set your clock. :) -wps From abair@amcu-tx.sps.mot.com Mon Sep 27 05:35:07 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA00150; Mon, 27 Sep 93 00:35:47 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA14871; Mon, 27 Sep 93 00:35:28 EDT Received: from spsgate.sps.mot.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA00135; Mon, 27 Sep 93 00:35:25 EDT Received: by spsgate.sps.mot.com (4.1/SMI-4.1 / Email 2.0 4/21/93) id AA16437; Sun, 26 Sep 93 21:35:19 MST Received: from emailchd (email.sps.mot.com) by motsps (4.1/SMI-4.0/Email 1.1) id AA08215; Sun, 26 Sep 93 21:34:16 MST Received: from parsons by sol-tx.sps.mot.com (4.1/SMI-4.1) id AA21990; Sun, 26 Sep 93 23:34:09 CDT Message-Id: <9309270434.AA21990@sol-tx.sps.mot.com> Received: by parsons (1.37.109.5/16.2) id AA05804; Sun, 26 Sep 93 23:34:11 -0500 From: Alan Bair Subject: Re: network hassles To: groo@menger.eecs.stevens-tech.edu (Bill Squier) Date: Sun, 26 Sep 93 23:34:11 CDT Cc: netbsd@cbmuucp.commodore.com In-Reply-To: <93Sep26.234046edt.5250@menger.eecs.stevens-tech.edu>; from "Bill Squier" at Sep 26, 93 11:40 pm X-Mailer: ELM [version 2.3 PL11] Status: RO > > Just to keep my sanity, what parts of the network stuff should we be starting > (if any) in /etc/rc if we AREN'T on any network? I'm from the time when if > someone said "hey, are you on the network?" I'd say "Well, let's see, I call > out every 4 hours at 15 past the hour to 'dweyr', and on demand to 'castle', > and I haven't checked uucppublic to see if we have any new files today." > > ..and all my TCP/IP experience has been on machines that really _are_ on a network! > > -wps > I ran into similar problems and Markus W. said to turn off named in /etc/rc. This fixed several things. I also set flags in /etc/netstart to turn off the starting to timed. I am working on a new rootfs with this and other things setup properly (I at least hope so) for a generic non-networked system. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 09:54:41 1993 Subject: Re: direct addressing causes timing violations? To: chammer@HRZ.Uni-Bielefeld.DE Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1068 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello! > I wonder if the problems with sync and other of the A3000 scsi-driver could be > caused by the direct addressing of this driver. > Netbsd seems to work too. Only sometimes "dmanext at end" errors while fscking I just got similar problem yesterday as i was adding another hard drive to NetBSD. It seeme that some hard drives don't speak correctly with sync negociation. At least my Seagate doesn't. All I had to do is turn off sync negociation for this drive, which was at id 2 so I've made a: binpatch -b -s _inhibit_sync -r 1 vmunix for my drive at SCSI id 0 and another binpatch -b -a 0x725c2 -r 1 vmunix for the one at SCSI id 2. It throwed away the anooying "dmanext at end". -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From markus@TechFak.Uni-Bielefeld.DE Mon Sep 27 12:18:18 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA00534; Mon, 27 Sep 93 07:18:25 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA14987; Mon, 27 Sep 93 07:18:05 EDT Received: from techfac.TechFak.Uni-Bielefeld.DE by cbmmail.commodore.com (4.1/SMI-4.1) id AA00525; Mon, 27 Sep 93 07:17:05 EDT Received: from elster.TechFak.Uni-Bielefeld.DE by techfac.TechFak.Uni-Bielefeld.DE id AA20690; Mon, 27 Sep 1993 12:16:40 +0100 Received: by elster.techfak.uni-bielefeld.de (4.1/tp.29.0890) id AA04987; Mon, 27 Sep 93 12:16:39 +0100 Message-Id: <9309271116.AA04987@elster.techfak.uni-bielefeld.de> From: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Date: Mon, 27 Sep 1993 12:16:38 MET In-Reply-To: Alan Bair "Re: network hassles" (Sep 26, 11:34pm) X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd@cbmuucp.commodore.com Subject: Re: network hassles Status: RO On Sep 26, 11:34pm, Alan Bair wrote: > I am working on a new rootfs with this and other things setup properly (I at > least hope so) for a generic non-networked system. [back from holiday] How about _two_ generic rootfs ? One for the networked and the other for the non-networked systems ? Or would this confuse the people ? -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 12:26:39 1993 Subject: Re: network hassles To: markus@TechFak.Uni-Bielefeld.DE (Markus Illenseer) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 803 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello! > > I am working on a new rootfs with this and other things setup properly (I at > > least hope so) for a generic non-networked system. > > How about _two_ generic rootfs ? One for the networked and the other for > the non-networked systems ? And what about modifying /etc/rc in order to ask if network support should be launched ? It would be quicker as we'd only have to update rc file instead of a 8MB file :-) -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 15:24:32 1993 To: netbsd-amiga@cbmuucp.uucp.commodore.com Subject: Latest GNU tool set Cc: mw@eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com Hello there(Yeah, it"s me again!) Where is the lastest version of the GNU tool set (gcc, make, etc)?? thanks again donnie@verdix.com From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 15:24:43 1993 To: netbsd-amiga@cbmuucp.uucp.commodore.com Subject: What & Where is the latest netbsd? Cc: mw@eunet.ch Sender: NetBSD-Admin@cbmuucp.commodore.com Hello there, What version and where is the latest incarnation of netbsd? Is there a site in the US what contains the latest updates? donnie donnie@verdix.com From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 15:32:46 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: streamio Sender: NetBSD-Admin@cbmuucp.commodore.com As i know from the readme file in /usr/share/lkm, there is no streamio support in NetBSD, yet. Is that right ? Is somebody doing the port ? If not, I will volunteer to do it. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 15:43:10 1993 Subject: Re: What & Where is the latest netbsd? To: donnie%verdix.com@cbmvax.uucp.commodore.com (Donnie Lewis) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD on Amiga) X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hello there, > > What version and where is the latest incarnation of netbsd? Is there a > site in the US what contains the latest updates? > > donnie > donnie@verdix.com The only site in the US is at ftp.wustl.edu in systems/amiga/boing/netbsd or something very close to that. However, it does not have the latest versions and I have had little success in getting mirroring going for that directory area. Though we did get the permissions on the sub-directories fixed. I just go to the main site in Europe that Markus W. updates. -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From groo@menger.eecs.stevens-tech.edu Mon Sep 27 16:09:59 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA01012; Mon, 27 Sep 93 11:06:38 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA15088; Mon, 27 Sep 93 11:06:20 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA01003; Mon, 27 Sep 93 11:06:15 EDT Received: by menger.eecs.stevens-tech.edu id <5257>; Mon, 27 Sep 1993 11:06:05 -0400 From: Bill Squier To: donnie%verdix.com@cbmvax.uucp.commodore.com Subject: Re: Latest GNU tool set Cc: netbsd@cbmuucp.commodore.com Message-Id: <93Sep27.110605edt.5257@menger.eecs.stevens-tech.edu> Date: Mon, 27 Sep 1993 11:05:52 -0400 Status: RO That depends... :) If you mean for AmigaDOS, then look on aminet (dev/gnu(?) last time I checked.) Last one there by Markus (and the one I trust) is 2.3.3. I believe a 2.4.5 port came out recently, but I don't know who did it. If you mean for netbsd, it's on ftp.eunet.ch in usr-bin.gnu.tar.gz with a whole bunch of other large, lumbering, interesting programs. -wps From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 18:24:08 1993 Subject: Re: network hassles To: mykes@shell.portal.com (Mike Schwartz) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 954 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello! > > And what about modifying /etc/rc in order to ask if network support should > > be launched ? It would be quicker as we'd only have to update rc file instead > > of a 8MB file :-) > Markus W. won't like this, but :-) [excellent stuff about sysv init style deleted] Yeah! Now this is exactly what I meant: modifying /etc/rc to implement different level of startup. So if we keep original rc in /etc/rc.orig and new one in /etc/rc, those who wants real bsd behavior copy back /etc/rc.orig to /etc/rc. The rest of us will keep going with nez /etc/rc. I like that. -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 18:47:15 1993 Subject: Debugger? To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com OK, I've just upgraded my hard disk, loaded up BSD and built a kernel. Now it's time for me to whack the bugs that I've reported, but that do not happen on other machines. However, there's no kernel debugger. I'm used to adb or sdb for this. Can gdb do kernel debugging via /dev/kmem? Is ddb a crash debugger (useful only for examining the entrails after a panic, and not for live kernel debugging)? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 18:55:11 1993 Subject: Status of things To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com What's everybody working on? I would like to see, and am willing to work on the following: 1. Support for removeable SCSI media - allow multi-volume tar and re-read disk label upon media change at re-mount time. 2. Amiga/880K and PC/720K floppy support. Who is working on the floppy driver? -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 20:20:47 1993 To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: Debugger? Sender: NetBSD-Admin@cbmuucp.commodore.com I general you need two machines to do kernel debugging. The machine being debugged is connected to via a serial port. The controlling machine which is running 'gdb -k' will attach to the serial port of the machine being debugged. If you compile the entire kernel with the -g option you could end up with about a 4MB kernel or so so make sure you have the disk space. Also in your config file I believe you need the 'option KGDB'. This is the extent of my knowledge the info -f gdb.info command should tell you what you need to know. I believe you need to do a 'set target' command or some such. Also I recall reading that the full KGDB support is not yet in the kernel yet, or more likely some things are now mismatched. You'll probably need a newer gdb binary. I have never done kernel debugging on a NetBSD kernel, only the BSD386 aka BSDI's kernel. That was a while back. Good Luck. -Rob From NetBSD-Admin@cbmuucp.commodore.com Mon Sep 27 21:35:10 1993 Subject: Re: network hassles To: phb@telesys-innov.fr (Philippe BRAND) Cc: mykes@shell.portal.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: 742 Sender: NetBSD-Admin@cbmuucp.commodore.com > [excellent stuff about sysv init style deleted] Huh.. seem to have missed that one.. > Yeah! Now this is exactly what I meant: modifying /etc/rc to implement > different level of startup. I'd suggest you add a new variable to netstart, and if set, named, sendmail etc are enabled. If it's not set, no such daemons are enabled. This makes sense, as anyone trying to get the network up will have to edit netstart to insert his own addresses and names, so enabling one variable there shouldn't be that much trouble. I'd really not like to have multiple rc's, REALLY 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 Sep 27 21:38:17 1993 Subject: Re: Status of things To: dej@eecg.toronto.edu (David Jones) 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: 823 Sender: NetBSD-Admin@cbmuucp.commodore.com > 1. Support for removeable SCSI media - allow multi-volume tar and re-read > disk label upon media change at re-mount time. Hm, aren't these two different cases? Multivolume tar's would usually go to the raw devices, thus there's no "re-mount". Remounting "real" volumes would require reading new disklabel. Anyway, you should try to inhibit volume changes while the medium is mounted. > 2. Amiga/880K and PC/720K floppy support. Who is working on the floppy > driver? HEY! If that's ok with Mykes, I'd happily pass you along his floppy-accessing code, for you make a NetBSD driver out of it. I really don't feel terribly motivated to do this... -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 groo@menger.eecs.stevens-tech.edu Tue Sep 28 06:50:52 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA00672; Tue, 28 Sep 93 01:51:15 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA00280; Tue, 28 Sep 93 01:50:56 EDT Received: from menger.eecs.stevens-tech.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA00663; Tue, 28 Sep 93 01:50:53 EDT Received: by menger.eecs.stevens-tech.edu id <5277>; Tue, 28 Sep 1993 01:50:45 -0400 From: Bill Squier To: dej@eecg.toronto.edu Subject: Re: Status of things Cc: netbsd@cbmuucp.commodore.com Message-Id: <93Sep28.015045edt.5277@menger.eecs.stevens-tech.edu> Date: Tue, 28 Sep 1993 01:50:32 -0400 Status: RO >From: David Jones > >What's everybody working on? I would like to see, and am willing to work on >the following: > > 1. Support for removeable SCSI media - allow multi-volume tar and re-read > disk label upon media change at re-mount time. > 2. Amiga/880K and PC/720K floppy support. Who is working on the floppy > driver? > Well, as much as time permits, I'm looking into implementing non-contiguous memory configs. It looks to me like I can slap the memory list right on the end of the kernel like Markus does with the ConfigDev stuff so I have the benefit of Expansion.library to walk the mem-list. So getting the info in is the easy part (assuming the kernel doesn't grow to be 1MB in size... :) ). The tough part is finding the time to wade through the vm source and write the newly required routines... sigh. >-- >David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto >email: dej@eecg.utoronto.ca, finger for more info > -wps From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 28 10:19:08 1993 Subject: Re: network hassles To: mw@eunet.ch (Markus Wild) Cc: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1162 Sender: NetBSD-Admin@cbmuucp.commodore.com Hello! > > [excellent stuff about sysv init style deleted] > Huh.. seem to have missed that one.. It was about a way of going into multiuser state without starting network. > > Yeah! Now this is exactly what I meant: modifying /etc/rc to implement > > different level of startup. > > I'd suggest you add a new variable to netstart, and if set, named, sendmail > etc are enabled. If it's not set, no such daemons are enabled. This > makes sense, as anyone trying to get the network up will have to edit > netstart to insert his own addresses and names, so enabling one variable > there shouldn't be that much trouble. I'd really not like to have multiple > rc's, REALLY not... We didn't mean that master ;-) Seems to be right to add a new variable into netstart. Let's go for it! -- Keep Cool |_x__x_x_| Philippe Brand |x x x x|\ Email: PhB@telesys-innov.fr Fido: 2:320/104.21 Have a | o o o | | ___ ___ ___ __ __ __ _ _ __ Nice Beer | o . o | | ( (___)( | )(_ (_ (_ /_) /_)(_ |. . . .|/ \ \ / \ / __) (__ __) /__)/__)__) Co-SysOp `--------' * To avoid headaches stay drunk * From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 28 10:56:52 1993 Subject: Re: network hassles To: phb@telesys-innov.fr (Philippe BRAND) Cc: mw@eunet.ch, 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: 1104 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hello! > > > > [excellent stuff about sysv init style deleted] > > Huh.. seem to have missed that one.. > > It was about a way of going into multiuser state without starting network. > > > > Yeah! Now this is exactly what I meant: modifying /etc/rc to implement > > > different level of startup. > > > > I'd suggest you add a new variable to netstart, and if set, named, sendmail > > etc are enabled. If it's not set, no such daemons are enabled. This > > makes sense, as anyone trying to get the network up will have to edit > > netstart to insert his own addresses and names, so enabling one variable > > there shouldn't be that much trouble. I'd really not like to have multiple > > rc's, REALLY not... > > We didn't mean that master ;-) Seems to be right to add a new variable into > netstart. Let's go for it! Umm, has someone considered the way linux does it ? (in rc) if [-x /etc/NETWORK];then cd /etc/rc.d rc.inet1 rc.inet2 fi ie, if a file "NETWORK" exists, then start the networking stuff... Isn't that a little more sensible? Or have I missed the plot totally... :-p~~~ From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 28 12:19:14 1993 Subject: Re: network hassles To: netbsd-amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com > > We didn't mean that master ;-) Seems to be right to add a new variable into > > netstart. Let's go for it! > > Umm, has someone considered the way linux does it ? Or Apollo. There is a directory /etc/daemons, and the /etc/rc script basically does if [ -f /etc/food -a -f /etc/daemons/food ]; then (echo " food\c" >/dev/console) (/etc/food >/dev/console) fi BTW, this is pronounced "foo-dee", and has nothing to do with food :) On the other hand, there is the way DEC osf/1 handles it. There is a rc.config script that set lots of shell variables, and the rc script checks for the existence and values of those variable. Not bad either, that way you can change command arguments without fiddling with the rc file. mjl From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 28 19:14:01 1993 X-Mailer: Mail User's Shell (7.1.0 4/25/90) To: netbsd-amiga@cbmuucp.commodore.com (NetBSD Liste) Subject: Re: network hassles Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 27, 12:25pm, Philippe BRAND wrote: > And what about modifying /etc/rc in order to ask if network support should > be launched ? It would be quicker as we'd only have to update rc file instead > of a 8MB file :-) Well, a rootfs which has no network stuff is by far shorter than 8MB, i was thinking about the distributed rootfs.gz archive which is quite large with 5MB. I suppose the original NetBSD /etc/rc (and rc.local) should be left intact, as for showing how a real /etc/rc looks like. Uncomenting some commands is the all we should do, everything else would be to confusing, no ? -- Markus Illenseer From NetBSD-Admin@cbmuucp.commodore.com Tue Sep 28 21:25:16 1993 Subject: Re: streamio To: landgraf@crunch.ikp.physik.th-darmstadt.de (Markus Landgraf) 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: 601 Sender: NetBSD-Admin@cbmuucp.commodore.com > As i know from the readme file in /usr/share/lkm, there is no > streamio support in NetBSD, yet. Is that right ? Is somebody > doing the port ? If not, I will volunteer to do it. I think the author of the lkm package (Terrence R. Lambert) said he's working on it (see /usr/share/lkm/README). However, I didn't even yet provide machdep support for lkm's in NetBSD. If you're interested into filling this gap, that would be cool too! -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 Sep 28 21:41:16 1993 Subject: Re: Debugger? To: dej@eecg.toronto.edu (David Jones) 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: 1138 Sender: NetBSD-Admin@cbmuucp.commodore.com > Now it's time for me to whack the bugs that I've reported, but that do not > happen on other machines. However, there's no kernel debugger. I'm used > to adb or sdb for this. Can gdb do kernel debugging via /dev/kmem? Is ddb > a crash debugger (useful only for examining the entrails after a panic, > and not for live kernel debugging)? I'm not used to any kernel debuggers, so you're more experienced in these things anyway. However, to really play with kernel dumps, we'd first need to be able to generate them RIGHT.. Currently, dumping a kernel locks up the machine at the end of the dump, so I think the dump doesn't dump what it should at all (looks like it's dumping the custom chip area in the end, causing the lockup on reading write-only registers). In addition, testing for cores on the dump device on startup doesn't find any cores, no matter whether there was a dump before. Could you first look into this problem please, if you have some spare time? -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 Sep 28 22:27:13 1993 Subject: Re: network hassles To: thecure@mullian.ee.mu.OZ.AU (matthew aldous) Cc: phb@telesys-innov.fr, mw@eunet.ch, 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: 1065 Sender: NetBSD-Admin@cbmuucp.commodore.com > Umm, has someone considered the way linux does it ? > > (in rc) > > if [-x /etc/NETWORK];then > cd /etc/rc.d > rc.inet1 > rc.inet2 > fi Eh, why do you want an additional file influencing totally unrelated files? To repeat my argument: /etc/netstart already contains flag variables that control starting/not-starting of certain daemons. It would be very easy (and consistent) to add other flags to control other daemons, you might even add a master "no_net" variable that turns all the others off. If you make the default "no_net", everyone should be able to use the system, as to make it usable for network access, you *have* to edit some files anyway. For example, in netstart, you have to set your hostname, domainname, you have to enable the interfaces available in your system. It comes natural, that doing that, you also enable the network. No need for a separate file, really. -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 Sep 28 22:30:48 1993 Subject: Re: network hassles To: mjl@auto.tuwien.ac.at (Martin J. Laubach) 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: 571 Sender: NetBSD-Admin@cbmuucp.commodore.com > On the other hand, there is the way DEC osf/1 handles it. There is > a rc.config script that set lots of shell variables, and the rc script > checks for the existence and values of those variable. Not bad either, > that way you can change command arguments without fiddling with the > rc file. Hey, I like this approach, having all the configurable options in one place looks like a useful strategy! -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 Sep 29 02:18:26 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: netbsd-amiga@cbmuucp.commodore.com Subject: Re: IVS Vector SUpport Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 22, 9:17pm, Markus Wild wrote: > The current scsi driver is HEAVILY 33C93 dependant, we'll have to change > to a different layout to support other controller chips. I've seen some > interesting work done by Chris Torek for the BSD4.4 scsi driver, but the > code is terse, I'll have to look deeper into it... > > Right now, to support different scsi controllers, you'd have to clone > the sd and st drivers, to call functions in your scsi code, not nice, > really.. I found this out the hard way - I tried to make a driver for the 53C710 on my Zeus card and wanted to be able to use it along with the GVP controller. After looking over the sd and st drivers, I decided the easiest thing to do was to remove the A3000/A2091/GVP11 entries from the configuration file and cloned the scsi.c code, changing it to work with the 53C710. 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 imorm@speedway.net Wed Sep 29 05:01:00 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA02877; Tue, 28 Sep 93 23:59:07 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA00696; Tue, 28 Sep 93 23:58:46 EDT Received: from access1.speedway.net by cbmmail.commodore.com (4.1/SMI-4.1) id AA02861; Tue, 28 Sep 93 23:58:44 EDT Received: by access1.speedway.net (Smail3.1.28.1 #4) id m0ohsgZ-000TG2C; Tue, 28 Sep 93 23:58 PDT Date: Tue, 28 Sep 1993 23:55:26 -0400 (EDT) From: Michael Imor Subject: Re: network hassles To: Markus Illenseer Cc: netbsd@cbmuucp.commodore.com In-Reply-To: <9309271116.AA04987@elster.techfak.uni-bielefeld.de> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Status: RO On Mon, 27 Sep 1993, Markus Illenseer wrote: > How about _two_ generic rootfs ? One for the networked and the other for > the non-networked systems ? > > Or would this confuse the people ? Or how about creating a directory like /etc/daemons and in that directory create dummy files for /etc/rc to check for existance. If there is say, a file called /etc/daemons/named than the /etc/rc can start the named daemon. Michael Imor Internet: imorm@access1.speedway.net From zap%indic.se@ida.liu.se Wed Sep 29 09:57:27 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA03247; Wed, 29 Sep 93 04:57:30 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA00790; Wed, 29 Sep 93 04:57:11 EDT Received: from ida.liu.se (curofix.ida.liu.se) by cbmmail.commodore.com (4.1/SMI-4.1) id AA03238; Wed, 29 Sep 93 04:57:10 EDT Received: from indic.se by ida.liu.se (5.65b/ida.minimaster-V1.0b6d5) id AA15344; Wed, 29 Sep 93 09:58:10 +0100 Message-Id: <9309290858.AA15344@ida.liu.se> Received: by indic (16.6/16.2) id AA12685; Wed, 29 Sep 93 09:55:51 +0100 Date: Wed, 29 Sep 93 09:55:51 +0100 From: Jonas Petersson To: netbsd@cbmuucp.commodore.com Subject: Re: network hassles Status: RO >On Mon, 27 Sep 1993, Markus Illenseer wrote: >Or how about creating a directory like /etc/daemons and in that directory >create dummy files for /etc/rc to check for existance. If there is say, >a file called /etc/daemons/named than the /etc/rc can start the named daemon. Sounds very Domain OS to me and also bit messy. I think the HP-UX approach of removong the execute bit on daemons that shouldn't run is slightly better (most definitely a fool proof way of turning them off ;-), but the rc.config file approach is by far the best. Just my 1 SEK worth (likey to be < $0.02 soon) / Jonas From NetBSD-Admin@cbmuucp.commodore.com Wed Sep 29 12:16:12 1993 To: mw@eunet.ch Cc: netbsd-amiga@cbmuucp.commodore.com Subject: Re: streamio Sender: NetBSD-Admin@cbmuucp.commodore.com > > As i know from the readme file in /usr/share/lkm, there is no > > streamio support in NetBSD, yet. Is that right ? Is somebody > > doing the port ? If not, I will volunteer to do it. > > I think the author of the lkm package (Terrence R. Lambert) said > he's working on it (see /usr/share/lkm/README). However, I didn't > even yet provide machdep support for lkm's in NetBSD. If you're > interested into filling this gap, that would be cool too! > Sorry, if this sounds silly. I don't know what the lkm package is. What I refered to was the streamio functions getmsg and putmsg which normally are included in libc.a. Furthermore the include files stream.h and stropts.h are missing. So, what is lkm and, if I want to port the streamio stuff, where can I get the sources ? I looked into the archie, but wasn't able to find something, yet ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From sauron%dweyr%wisdom@fdurt1.fdu.edu Thu Sep 30 01:28:41 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA04751; Wed, 29 Sep 93 20:28:40 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA01034; Wed, 29 Sep 93 20:28:21 EDT Received: from fdurt1.fdu.edu by cbmmail.commodore.com (4.1/SMI-4.1) id AA04742; Wed, 29 Sep 93 20:28:14 EDT Received: by fdurt1.fdu.edu (5.57/Ultrix3.0-C) id AA13644; Wed, 29 Sep 93 20:28:10 -0400 Received: from dweyr by wisdom.bubble.org; Wed, 29 Sep 1993 20:13 EDT Received: by dweyr.wisdom.bubble.ORG (V1.16/Amiga) id AA006bz; Wed, 29 Sep 93 17:38:02 EST Date: Wed, 29 Sep 93 17:38:02 EST Message-Id: <9309292238.AA006by@dweyr.wisdom.bubble.ORG> X-Mailer: //\\miga Electronic Mail (AmiElm 2.253) Organization: DragonSoft Development Reply-To: sauron@dweyr.wisdom.bubble.org From: sauron@dweyr.wisdom.bubble.org (Ronald A Stanions) (Ron Stanions) To: netbsd@cbmuucp.commodore.com Subject: newcomer problems Content-Type: text Content-Length: 1981 Status: RO I'm new to the list here, so it stands to reason I'm asking questions that are probably old news, but... 1) I want to move the root filesystem over to another partition and make it larger. (the 8 meg distributed rootfs fills up instantly with logs and such.) My method was to: create a new partition, newfs it, copy everything off the root fs into the new partition, relabel the new partition as the rootfs, and everything's fine, except that the /dev/log device (apparently a socket?) didn't copy, and syslogd keeps complaining about it. I can disable syslogd for now, but I'd like to try to get the fs fully functional. Is there another way for me to have done this that would have worked better? or how would I go about recreating the /dev/log device? 2) df always reports wrong information, whether it's on the original rootfs, my new root fs, or any partitions I attach. It invariably ends up giving me negative blocks free, with over 100% usage results. (and if I delete enough files to make it positive again, the numbers still don't total up by a long shot. Is this a bug in df? or in the filesystem? and is there a fix for it? 3) I was told by a friend of one patch to stop the sync check on the drives during bootup, which stopped it from missing the boot about three out of four times quite nicely. Is there any other patches that I should be aware of? 4) 'cron' seems to be missing entirely from the distribution. What's the availability (or replacement) for this? 5) Since I'm new to all this, is there some file I can request from some place that will explain things more than the existing FAQ does? (which is considerably outdated methinks). Everything I have here I got directly from ftp.eunet.ch, so I think it's a safe bet to say I got the latest stuff, no? Any help would be appreciated greatly. Ron Stanions -- DragonSoft Development sauron@dweyr.wisdom.bubble.org The Dragon's Weyr BBS -- Livingston, NJ sauron@wisdom.bubble.org From abair@amcu-tx.sps.mot.com Thu Sep 30 02:16:39 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA04834; Wed, 29 Sep 93 21:16:13 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA01051; Wed, 29 Sep 93 21:15:53 EDT Received: from spsgate.sps.mot.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA04819; Wed, 29 Sep 93 21:15:48 EDT Received: by spsgate.sps.mot.com (4.1/SMI-4.1 / Email 2.0 4/21/93) id AA04714; Wed, 29 Sep 93 18:15:39 MST Received: from emailchd (email.sps.mot.com) by motsps (4.1/SMI-4.0/Email 1.1) id AA17064; Wed, 29 Sep 93 18:14:11 MST Received: from parsons by sol-tx.sps.mot.com (4.1/SMI-4.1) id AA05386; Wed, 29 Sep 93 20:14:01 CDT Message-Id: <9309300114.AA05386@sol-tx.sps.mot.com> Received: by parsons (1.37.109.5/16.2) id AA13416; Wed, 29 Sep 93 20:14:03 -0500 From: Alan Bair Subject: Re: newcomer problems To: sauron@dweyr.wisdom.bubble.org Date: Wed, 29 Sep 93 20:14:03 CDT Cc: netbsd@cbmuucp.commodore.com In-Reply-To: <9309292238.AA006by@dweyr.wisdom.bubble.ORG>; from "Ron Stanions" at Sep 29, 93 5:38 pm X-Mailer: ELM [version 2.3 PL11] Status: RO I'll try to answer some of your questions. > > I'm new to the list here, so it stands to reason I'm asking questions that > are probably old news, but... > > 1) I want to move the root filesystem over to another partition and make > it larger. (the 8 meg distributed rootfs fills up instantly with logs and > such.) My method was to: create a new partition, newfs it, copy everything > off the root fs into the new partition, relabel the new partition as the > rootfs, and everything's fine, except that the /dev/log device (apparently > a socket?) didn't copy, and syslogd keeps complaining about it. I can > disable syslogd for now, but I'd like to try to get the fs fully functional. > > Is there another way for me to have done this that would have worked > better? or how would I go about recreating the /dev/log device? I just did what you described and it is correct, except you did not say what you used to "copy" the files. You need to use tar to make sure you preserve the date, owner, permissions, etc. Tar will also copy devices, like log, correctly. SIDE NOTE: As I have mentioned before, I am working on a new rootfs. Ron's statement about root filling up immediately is especially true after the latest binaries, 644, are installed. So for the new rootfs, I was planning on making it larger, say 10MB. Does anyone have a problems with this? Also, after you'll decide how to handle the network setup, I can put that in the new rootfs. Just let me know the final out come, I don't really care how it is done. Just consider that there are people that have little knowledge about networking, so they need a no-net setup to start with. Those that understand it, can probably look around in /etc and figure out what needs to be changed to get thigs going, especially if we add a few comments. END NOTE > > 2) df always reports wrong information, whether it's on the original rootfs, > my new root fs, or any partitions I attach. It invariably ends up giving > me negative blocks free, with over 100% usage results. (and if I delete > enough files to make it positive again, the numbers still don't total up > by a long shot. Is this a bug in df? or in the filesystem? and is there > a fix for it? Sounds like a filesystem bug, since I have never seen any strange values. > > 3) I was told by a friend of one patch to stop the sync check on the drives > during bootup, which stopped it from missing the boot about three out of > four times quite nicely. Is there any other patches that I should be aware > of? Yes, there are others, but I don't have a list. Sounds like a good topic for an FAQ section. > > 4) 'cron' seems to be missing entirely from the distribution. What's the > availability (or replacement) for this? It is actually called crond and I think it is in /usr/libexec. > > 5) Since I'm new to all this, is there some file I can request from > some place that will explain things more than the existing FAQ does? > (which is considerably outdated methinks). Everything I have here I got > directly from ftp.eunet.ch, so I think it's a safe bet to say I got the > latest stuff, no? Any help would be appreciated greatly. That site is the best place. Yes, the FAQ can use some updating. What you really need is to read back copies of the netbsd postings. Are these being archived anywhere? > > > Ron Stanions -- DragonSoft Development sauron@dweyr.wisdom.bubble.org > The Dragon's Weyr BBS -- Livingston, NJ sauron@wisdom.bubble.org > -- Alan Bair MCTG AMCU DSCS Motorola, Inc. (Design Software & Mail Stop OE-320 Computer Services) 6501 William Cannon Dr. West (512) 891-2336 Austin, TX 78735-8598 abair@amcu-tx.sps.mot.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 04:18:01 1993 Subject: Re: newcomer problems To: netbsd-amiga@cbmuucp.commodore.com Mailer: Elm [revision: 70.85] Sender: NetBSD-Admin@cbmuucp.commodore.com >> >> 2) df always reports wrong information, whether it's on the original rootfs, >> my new root fs, or any partitions I attach. It invariably ends up giving >> me negative blocks free, with over 100% usage results. (and if I delete >> enough files to make it positive again, the numbers still don't total up >> by a long shot. Is this a bug in df? or in the filesystem? and is there >> a fix for it? > >Sounds like a filesystem bug, since I have never seen any strange values. > Remember that only "root" can write the last 10% of a disk. This is to prevent wild, gluttenous users from filling up important disks that may result in a system crash. So, your disks can be at a maximum of 110% full, including the "reserved space". Having negative blocks free means you are that many blocks into your "reserved space". Going above 100% full is not usually a good idea.. ;) 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 Thu Sep 30 09:33:35 1993 Subject: PS & kernel panics. 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: 994 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, recently I started getting kernel panics when doin ps -ux. It happended threee times quite randomly. I'm using vmunix644 the only change is that I compiled it without support for scsi devices at addresses 0, 1, 2, 3 and 4, and I patched it with the changes for gdb that were posted here a couple of days ago. And I set transfer to non syncronous for my drives at address 5 and 6. I also installed the new binaries. the crashes always happended when when /tmp was about half full, screen was running and term was running, in fact I used kermit to log out of the remote machine and then wanted to kill term, so I typed ps -ux to find the process number, but ps just responded with a panic, giving me a table of the registers and some other info, which I wrote down once (if it is of any help). Unfortunateley I couldn't reproduce the error on purpose, it just happens every now and then, 2 times yesterday and once last week. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 09:40:07 1993 Subject: wrong links in /usr/lib. 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: 434 Sender: NetBSD-Admin@cbmuucp.commodore.com I was just compiling Icon on NetBSD and had some problems, so I went through the system searching for things till I found 2 circular links in /usr/lib. There are lib++.a which was linked to itself and also libiberty.a pointed to itselfs, I just fixed that so they point to /usr/gnu/lib/libname. Unfortunateley that wasn't my problem :( But I thought I'd let you know. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From mw@eunet.ch Thu Sep 30 09:41:45 1993 Received: from cbmuucp.commodore.com by cbmmail.commodore.com (4.1/SMI-4.1) id AA05370; Thu, 30 Sep 93 04:41:37 EDT Received: from cbmmail.commodore.com by cbmuucp.commodore.com (4.1/SMI-4.1) id AA01213; Thu, 30 Sep 93 04:41:18 EDT Received: from chsun.eunet.ch (chsun.chuug.ch) by cbmmail.commodore.com (4.1/SMI-4.1) id AA05361; Thu, 30 Sep 93 04:41:14 EDT Received: from ds.eunet.ch by chsun.eunet.ch (5.65c8/1.34) id AA01902; Thu, 30 Sep 1993 09:42:19 +0100 From: mw@eunet.ch (Markus Wild) Message-Id: <199309300842.AA01902@chsun.eunet.ch> Subject: Re: newcomer problems To: sauron@dweyr.wisdom.bubble.org Date: Thu, 30 Sep 1993 09:41:33 +0100 (MET) Cc: netbsd@cbmuucp.commodore.com In-Reply-To: <9309292238.AA006by@dweyr.wisdom.bubble.ORG> from "Ron Stanions" at Sep 29, 93 05:38:02 pm X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1685 Status: RO > such.) My method was to: create a new partition, newfs it, copy everything > off the root fs into the new partition, relabel the new partition as the How did you do the copy? Something that should work (assume new partition on /mnt): (cd /; tar clf - . )|(cd /mnt; tar xvpSf -) > rootfs, and everything's fine, except that the /dev/log device (apparently > a socket?) didn't copy, and syslogd keeps complaining about it. I can Huh? syslogd should recreate this socket.. did you perhaps generate a bogous /dev/log when copying over the fs? If so, remove it and retry syslogd. > 2) df always reports wrong information, whether it's on the original rootfs, > my new root fs, or any partitions I attach. It invariably ends up giving > me negative blocks free, with over 100% usage results. (and if I delete A filesystem which is completely full will give you about 112% full in df. This is normal, not a bug, and is explained by the nature of the used filesystem. > 3) I was told by a friend of one patch to stop the sync check on the drives > during bootup, which stopped it from missing the boot about three out of > four times quite nicely. Is there any other patches that I should be aware > of? If you use a 2091/GVP controller, and have memory outside the 24bit address space, you should disable DMA. In that case, do "binpatch -s _scsi_no_dma -r 1 vmunix". > 4) 'cron' seems to be missing entirely from the distribution. What's the > availability (or replacement) for this? /usr/libexec/crond. -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 Sep 30 09:49:30 1993 Subject: Re: PS & kernel panics. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) 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: 909 Sender: NetBSD-Admin@cbmuucp.commodore.com > ps -ux to find the process number, but ps just responded with a panic, > giving me a table of the registers and some other info, which I wrote > down once (if it is of any help). > Unfortunateley I couldn't reproduce the error on purpose, it just > happens every now and then, 2 times yesterday and once last week. If you get a register dump, the interesting thing to write down is the pc value. Then, after rebooting, do "nm -n /vmunix | less" and look in which function the pc value you wrote down lies. You then know, in which function the panic occured. Knowing this would be useful. There is a known problem in fill_eproc() (which is used by ps). Something seems to be fishy in there in certain circumstances. I'm looking into it. -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 Sep 30 10:04:01 1993 Subject: Display Problems with kernel 644. 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: 1029 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, vmunix 644 has some problems with the new overscan features on ECS machines. using IRC for example the last two lines get scrambled, the same is for Emacs. Actually they are not really scrambled, but the stuff that scrolls out of the screen on the top comes back on the bottom and scrolls up for another 2 lines. Now I found that when I use kermit to log into my account at Uni I can log in without problems, but as soon as I entered my password the prompt appears in about the middle of the screen, and the same behaviour as with IRC and Emacs occurs, just that the middle of the screen seems to be seen as the bottom, and the stuff that scrolls out of the top of the screen comes back at the bottom and scrolls to the middle where it then disappears. I have no Idea to get the bottom of the display back to the bottom of the physical screen, what I do is I start screen which brings it back down, but procedes in the same way as described for IRC and Emacs. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 10:33:04 1993 To: hoffmann@it.ntu.edu.au Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Display Problems with kernel 644. Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, vmunix 644 has some problems with the new overscan features on ECS machines. using IRC for example the last two lines get scrambled, the same is for Emacs. Actually they are not really scrambled, but the stuff that scrolls out of the screen on the top comes back on the bottom and scrolls up for another 2 lines. Now I found that when I use kermit to log into my account at Uni I can log in without problems, but as soon as I entered my password the prompt appears in about the middle of the screen, and the same behaviour as with IRC and Emacs occurs, just that the middle of the screen seems to be seen as the bottom, and the stuff that scrolls out of the top of the screen comes back at the bottom and scrolls to the middle where it then disappears. I have no Idea to get the bottom of the display back to the bottom of the physical screen, what I do is I start screen which brings it back down, but procedes in the same way as described for IRC and Emacs. Good, I'm not the only one with this problem. I reconfigured /etc/termcap and exhibited the tty settings with stty. But the problem with my emacs was still there: all is ok until it has to scroll the buffer, then emacs tries to put the status line in the middle of the screen. The correct design can restored using ^l. I tried some combinations of /etc/termcap entry for a while then gave up. I think this is related to the overscan stuff, because I have recompiled my kernel 644 with option BORING_DEFAULTS. This has to be done, because I have an A2024 which isn't able to display any overscan. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 10:44:06 1993 To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Mysterious error. Sender: NetBSD-Admin@cbmuucp.commodore.com Can anyone explain to me what 'error 5 blkno 27280 sz 8192 swap_pager_finish: clean of page 4ee000 failed' means? Regards, Hubert =============== Hubert Feyrer ============================================ Weekdays: Rennerstr. 19, 93053 Regensburg, Tel. 0941 / 701788 Weekends: Bachstr. 40, 84066 Mallersdorf, Tel. 08772 / 6084 Internet: feyrer@rrzc1.rz.uni-regensburg.de === IRC: hubertf ========================================================================== From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 10:56:19 1993 To: hoffmann@it.ntu.edu.au Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Display Problems with kernel 644. Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, vmunix 644 has some problems with the new overscan features on ECS machines. using IRC for example the last two lines get scrambled, the same is for Emacs. Actually they are not really scrambled, but the stuff that scrolls out of the screen on the top comes back on the bottom and scrolls up for another 2 lines. Now I found that when I use kermit to log into my account at Uni I can log in without problems, but as soon as I entered my password the prompt appears in about the middle of the screen, and the same behaviour as with IRC and Emacs occurs, just that the middle of the screen seems to be seen as the bottom, and the stuff that scrolls out of the top of the screen comes back at the bottom and scrolls to the middle where it then disappears. I have no Idea to get the bottom of the display back to the bottom of the physical screen, what I do is I start screen which brings it back down, but procedes in the same way as described for IRC and Emacs. Good, I'm not the only one with this problem. I reconfigured /etc/termcap and exhibited the tty settings with stty. But the problem with my emacs was still there: all is ok until it has to scroll the buffer, then emacs tries to put the status line in the middle of the screen. The correct design can restored using ^l. I tried some combinations of /etc/termcap entry for a while then gave up. I think this is related to the overscan stuff, because I have recompiled my kernel 644 with option BORING_DEFAULTS. This has to be done, because I have an A2024 which isn't able to display any overscan. ------------------------------------------------------------------------------ Landi#2 landgraf@crunch.ikp.physik.th-darmstadt.de "The only time when I'm easy is when I'm killed by death" "If You got the power, that don't mean You got the right" I. Kilmister ------------------------------------------------------------------------------ From mw@eunet.ch Thu Sep 30 11:28:22 1993 Received: from ds.eunet.ch by chsun.eunet.ch (5.65c8/1.34) id AA09940; Thu, 30 Sep 1993 11:31:26 +0100 From: mw@eunet.ch (Markus Wild) Message-Id: <199309301031.AA09940@chsun.eunet.ch> Subject: Re: Mysterious error. To: hubert.feyrer@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) Date: Thu, 30 Sep 1993 11:30:40 +0100 (MET) Cc: NetBSD-Amiga@cbmuucp.commodore.com In-Reply-To: <9309300942.AA19454@rrzc1.rz.uni-regensburg.de> from "Hubert Feyrer" at Sep 30, 93 10:42:29 am X-Mailer: ELM [version 2.4 PL23alpha] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 947 Status: RO > Can anyone explain to me what 'error 5 blkno 27280 sz 8192 swap_pager_finish: > clean of page 4ee000 failed' means? It looks like a read or write error on that (logical) block. Since it's the swap_pager barking, it means the blkno is on your swap partition. Note that the current SCSI driver doesn't initiate any automatic block reallocation (I didn't dare...), so you'd have to do that explicitly. You can verify whether the block is indeed bogous by trying to read it directly, ie. dd if=/dev/rsd1b of=/dev/null bs=512 skip=27280 count=16 assuming your swap is on scsi unit 1. Anybody feeling like writing a "format" tool like found on SunOS for NetBSD? The driver knows a so called "format" mode, that allows you to execute certain SCSI commands from a user program... -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 Sep 30 11:33:29 1993 To: mw@eunet.ch Cc: hoffmann@it.ntu.edu.au, NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: PS & kernel panics. Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "MTK" == Markus Wild writes: Arthur> ps -ux to find the process number, but ps just responded with a Arthur> panic, giving me a table of the registers and some other info, which Arthur> I wrote down once (if it is of any help). Unfortunateley I couldn't Arthur> reproduce the error on purpose, it just happens every now and then, Arthur> 2 times yesterday and once last week. MTK> If you get a register dump, the interesting thing to write down MTK> is the pc value. Then, after rebooting, do "nm -n /vmunix | less" MTK> and look in which function the pc value you wrote down lies. You MTK> then know, in which function the panic occured. Knowing this MTK> would be useful. I usually try to do a manual backtrace as well. look at the framepointer (A6) and find that adress in the stack. There you should find the next framepointer link and the callers address, note this and repeat the procedure, three or four times is usually enough. Then use "nm -n /vmunix" and look up all the addresses you got. Then you have a backtrace. You can even find the exact location in the code if you use gdb to disassemble the faulting procedure and look at the offset you get by subtracting the PC value you got from the dump from the "nm -n" reported address of the enclosing function. By a little reverse engineering you can often find the exact spot in the source quite fast (if the function is small, that is). If you're really into this you can also get the argument values from the stack dump, but I leave that as a trivial exercise for the reader :-) MTK> There is a known problem in fill_eproc() (which is used by MTK> ps). Something seems to be fishy in there in certain MTK> circumstances. I'm looking into it. On low memory-systems (4M) the vm code (spec. pmap_enter_ptpage) tends to panic trap. The STE seems not to be mapped (I don't know what I'm talking about here, I've never seen a MMU manual). But that isn't specific to ps, I get traps in all sorts of locations, when I'm using a lot of memory. Niklas From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 11:33:30 1993 Subject: Re: Mysterious error. To: hubert.feyrer@rrzc1.rz.uni-regensburg.de (Hubert Feyrer) 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: 947 Sender: NetBSD-Admin@cbmuucp.commodore.com > Can anyone explain to me what 'error 5 blkno 27280 sz 8192 swap_pager_finish: > clean of page 4ee000 failed' means? It looks like a read or write error on that (logical) block. Since it's the swap_pager barking, it means the blkno is on your swap partition. Note that the current SCSI driver doesn't initiate any automatic block reallocation (I didn't dare...), so you'd have to do that explicitly. You can verify whether the block is indeed bogous by trying to read it directly, ie. dd if=/dev/rsd1b of=/dev/null bs=512 skip=27280 count=16 assuming your swap is on scsi unit 1. Anybody feeling like writing a "format" tool like found on SunOS for NetBSD? The driver knows a so called "format" mode, that allows you to execute certain SCSI commands from a user program... -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 Sep 30 15:59:42 1993 Subject: Debuggers, etc. To: NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com Perhaps some of you are confused over what I am calling a "kernel debugger". I have only one Amiga. It's unlikely that I can get another one just for debugging. There should be no need, for I do not want to breakpoint or trace a running kernel. What I am looking for is a program that opens /dev/kmem and reads/writes it, based on symbols from /vmunix. adb on a Sun will do this. I have used adb to patch a running SunOS kernel. What happens if I do gdb /vmunix /dev/kmem If this works, then gdb is all I need. I don't need ptrace functionality for this, just read/write through /dev/kmem. I need this functionality before I can do any other development on NetBSD. Markus, I will take a look at the dump subsystem. However, don't expect miracles :-) Once I've patched up the small bugs, I will start work on removeable media. -- David Jones, M.A.Sc student, Electronics Group (VLSI), University of Toronto email: dej@eecg.utoronto.ca, finger for more info From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 16:11:28 1993 Subject: SUBSCRIBE To: netbsd-amiga@cbmuucp.commodore.com X-Envelope-To: netbsd-amiga@cbmuucp.commodore.COM X-Vms-To: ALBANY::IN%"netbsd-amiga@cbmuucp.commodore.com" Mime-Version: 1.0 Content-Transfer-Encoding: 7BIT Sender: NetBSD-Admin@cbmuucp.commodore.com Please add my address to your mailing list for NetBSD. Than You Thank You Michael Imor From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 16:54:25 1993 Subject: Re: PS & kernel panics. To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) 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: 1433 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hi, recently I started getting kernel panics when doin ps -ux. > It happended threee times quite randomly. > I'm using vmunix644 the only change is that I compiled it without > support for scsi devices at addresses 0, 1, 2, 3 and 4, and I patched > it with the changes for gdb that were posted here a couple of days > ago. And I set transfer to non syncronous for my drives at address 5 > and 6. I also installed the new binaries. > the crashes always happended when when /tmp was about half full, ^^^^^^^^^^^^^^^^^^^^^^^^^^ > screen was running and term was running, in fact I used kermit to log > out of the remote machine and then wanted to kill term, so I typed > ps -ux to find the process number, but ps just responded with a panic, > giving me a table of the registers and some other info, which I wrote > down once (if it is of any help). > Unfortunateley I couldn't reproduce the error on purpose, it just > happens every now and then, 2 times yesterday and once last week. If you are using mfs, which uses swap, and have enough processes running to have your swap 1/2 full, you may have run out of space in your swap partition. Try increasing swap, using less /tmp, or moving /tmp to a ufs partition. ========================================================================= 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 Sep 30 16:58:07 1993 Subject: Re: Debuggers, etc. To: dej@eecg.toronto.edu (David Jones) Cc: 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: 291 Sender: NetBSD-Admin@cbmuucp.commodore.com > I have only one Amiga. It's unlikely that I can get another one just for > debugging. Why buy an Amiga? A terminal works as well. Try ask around some institutions, used computer equipment places or whatever. A used terminal shouldn't be hard to find for free or very cheap. /Peter From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 17:34:39 1993 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: Debuggers, etc. Sender: NetBSD-Admin@cbmuucp.commodore.com On Sep 30, 10:58am, David Jones wrote: > What I am looking for is a program that opens /dev/kmem and reads/writes it, > based on symbols from /vmunix. adb on a Sun will do this. I have used > adb to patch a running SunOS kernel. What happens if I do > > gdb /vmunix /dev/kmem > > If this works, then gdb is all I need. I don't need ptrace functionality > for this, just read/write through /dev/kmem. I don't think this will work. I tried it once and gdb complained that /dev/kmem was not a valid core file. I assume it is looking for some header information in the core file. I've been thinking about getting the gdb sources (plus the Amiga NetBSD diffs) and seeing if I can get it to work. I would like to be able to at least examine the running kernel memory and it would be nice to be able to make minor patches to it as well. 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 Sep 30 18:48:10 1993 Subject: Includes missing? 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: 539 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I was just compiling Icon under NetBSD and I got stuck. The compilation requires functions called gcvt and ecvt, but I cant find them anywhere. I checked on our Sun at Uni, and the man pages mentioned that they were outdated and replaced by econvert and gconvert, but I can't find those either. On the sun they are in a file called floatingpoint.h; we don't have that either, we have float.h, but that doesn't contain the desired functions either. Any suggestions? Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 19:03:26 1993 Subject: Re PS & kernel panics 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: 270 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I did what Markus Wild told me: nm -n /vmunix. The PC at the register dump was 00007818. nm -n shows From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 19:51:39 1993 Subject: ftp using term. possible? 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: 572 Sender: NetBSD-Admin@cbmuucp.commodore.com Hi, I am using NetBSD with term to connect to the university, which is on the internet. I found this option called tredir which redirects things to my local machine. It works great with telnet, but what do I need to do in order for others at the uni machine to ftp to my NetBSD machine and transfer files. And what do I need to do to download files from an ftp server directly onto my machine, without having to first store my files on the university system? Is this at all possible? Thanks for you help. Arthur. Arthur Hoffmann hoffmann@nutmeg.ntu.edu.au From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 20:30:52 1993 Subject: Re: Display Problems with kernel 644. To: landgraf@crunch.ikp.physik.th-darmstadt.de (Markus Landgraf) Cc: hoffmann@it.ntu.edu.au, NetBSD-Amiga@cbmuucp.commodore.com X-Mailer: ELM [version 2.3 PL11] Sender: NetBSD-Admin@cbmuucp.commodore.com I'm pretty sure these display problems are due to the changes in ite.c, not due to overscan. I got them both with and without the BORING_DEFAULTS, but things reverted to normal once I went back to the old ite.c. > vmunix 644 has some problems with the new overscan features on ECS > machines. using IRC for example the last two lines get scrambled, the > same is for Emacs. Actually they are not really scrambled, but the > stuff that scrolls out of the screen on the top comes back on the > bottom and scrolls up for another 2 lines. -- ------------------------------------------------------------------------ Andy Heffernan ahh@netcom.com From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 20:58:39 1993 To: hoffmann@it.ntu.edu.au Cc: NetBSD-Amiga@cbmuucp.commodore.com Subject: Re: ftp using term. possible? Sender: NetBSD-Admin@cbmuucp.commodore.com >>>>> "Arthur" == Arthur Hoffmann writes: Arthur> Hi, I am using NetBSD with term to connect to the university, Arthur> which is on the internet. I found this option called tredir Arthur> which redirects things to my local machine. It works great Arthur> with telnet, but what do I need to do in order for others at Arthur> the uni machine to ftp to my NetBSD machine and transfer Arthur> files. And what do I need to do to download files from an ftp Arthur> server directly onto my machine, without having to first store Arthur> my files on the university system? Is this at all possible? Hardly, as ftp dynamically creates TCP ports for data connections. You have to write a specific tredirftp or something that peeks at the ftp commands, when it sees a PORT command it has to create a TCP port and substitute the PORT command parameters with its own ports address. Not really hard, but tedious, I think. 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 Sep 30 22:01:13 1993 Subject: Re: Display Problems with kernel 644. To: ahh@netcom.com (Andy Heffernan) Cc: landgraf@crunch.ikp.physik.th-darmstadt.de, hoffmann@it.ntu.edu.au, 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: 958 Sender: NetBSD-Admin@cbmuucp.commodore.com > I'm pretty sure these display problems are due to the changes > in ite.c, not due to overscan. I got them both with and without the > BORING_DEFAULTS, but things reverted to normal once I went back to the > old ite.c. You're sure about this?? I find the new ite *much* better than the old one, specially if you work with the non GNU termcap, the vt100 emulator is much more stable. As well, try vttest, ite now passes almost any test that can be reasonably implemented in an ASCII console. Besides, if it were ite.c, I would see such problems on the Retina console as well, which I really don't, I'd much rather think that the custom chips scrolling code doesn't play well with the new overscan sized display. I didn't look into this, as I don't claim I understand that copper magic :-) -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 Sep 30 22:41:19 1993 To: hoffmann@it.ntu.edu.au Subject: Re: ftp using term. possible? Cc: netbsd-amiga@cbmuucp.commodore.com Sender: NetBSD-Admin@cbmuucp.commodore.com > > >Hi, >I am using NetBSD with term to connect to the university, which is on >the internet. I found this option called tredir which redirects things >to my local machine. It works great with telnet, but what do I need to >do in order for others at the uni machine to ftp to my NetBSD machine >and transfer files. And what do I need to do to download files from an >ftp server directly onto my machine, without having to first store my >files on the university system? >Is this at all possible? > Yes term is very great for that. tredir is used like this: tredir 6666 23 (Where 6666 is the port u want 2 use & 23 is the telnet pt) you can run it from trsh or after login in w/ trsh run remotely. Then for someone to login in just have'em telnet to the addr + port # Ex: telnet netbsd.amiga.com 6666 The remote machine catches that port and redirects the output to term which takes it from there. It works great... As for ftping, you need term+ncftp.tar.Z It's a new type of ftp & it's made for term also. Once running just ftp like normal (tho ncftp is better than normal) and all files go thru term directly to your machine. One note is that it's slower than regular transfers. Esp if you use a 2400. I don't use it much, cept for small file cu of that. I can't speak for 9600+ users. I need the diffs for term for ircII. If you or someone else gets it crackin, I'd appreciate it much! L8r - TC -- Techno Caster - ah360@yfn.ysu.edu From NetBSD-Admin@cbmuucp.commodore.com Thu Sep 30 23:36:30 1993 Subject: Re: ftp using term. possible? To: hoffmann@it.ntu.edu.au (Arthur Hoffmann) 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: 731 Sender: NetBSD-Admin@cbmuucp.commodore.com > > Hi, > I am using NetBSD with term to connect to the university, which is on > the internet. I found this option called tredir which redirects things > to my local machine. It works great with telnet, but what do I need to > do in order for others at the uni machine to ftp to my NetBSD machine > and transfer files. And what do I need to do to download files from an > ftp server directly onto my machine, without having to first store my > files on the university system? > Is this at all possible? The following programmes have been ported to work with term termtelnet termftp termfinger termirc termftpd termrlogin All/most are available on either of the main linux archives. (sunsite.unc.edu or tsx-11.mit.edu)