XBR4D75G%DDATHD21.BITNET@cunyvm.cuny.edu (08/02/90)
After upgrading my MINIX-system to version 1.5.10, I finally found some time to generate the corresponding AMOEBA-version. The generation of my new boot-floppy was done with the included Makefiles without any problems and my system came up immediately. The included examples server1/client1 and server2/client2 are running local on one PC successfully but I could not run them between two different PC's. Ethernet-cards are installed on both PC's and when booting, the hardware-address is shown on the screen by the minix system. When I started the examples server1/client1 on one machine, I used the other PC to monitor the the ethernet with "NETWATCH", here are the 4 broadcast messages I observed on the net: 0040 FFFF FFFF FFFF 0000 C0CD A517 8145 FF00 E 0050 0000 0000 1E00 0001 7879 7A00 0000 7624 xyz v$ 0060 0F0F 0F0F 2F1F 0F0F 4949 4949 4959 4B49 / IIIIIYKI 0070 71F0 E0E8 F890 F8E0 DCB7 B6B3 3D00 3C00 q = < 0080 FFFF FFFF FFFF 0000 C0CD A517 8145 FF00 E 0090 0000 0000 1E00 0001 7879 7A00 0000 7624 xyz v$ 00A0 0F0F 0F0F 2F1F 0F0F 4949 4949 4959 4B49 / IIIIIYKI 00B0 71F0 E0E8 F890 F8E0 DCB7 B6B3 3C00 3C00 q < < 00C0 FFFF FFFF FFFF 0000 C0CD A517 8145 FF00 E 00D0 0000 0000 1E00 0001 7879 7A00 0000 7624 xyz v$ 00E0 0F0F 0F0F 2F1F 0F0F 4949 4949 4959 4B49 / IIIIIYKI 00F0 71F0 E0E8 F890 F8E0 DCB7 B6B3 3C00 3C00 q < < When running only client1 on a machine, I had exspected to see at least one broadcast message on the net, but nothing appeared. Has anyone similar problems or any idea to fix this network problem? Does the amoeba software find all hardware attributes of my ethernet-card automatically? When using network software under MS-DOS, all programs require data about interrupt level (0x3), io-address (0x280) and memory-address (0xd000), have I forgotten something during system generation? Any help and hints are appreciated. Hans-Juergen Knobloch, (TH Darmstadt, Germany)
ast@cs.vu.nl (Andy Tanenbaum) (08/03/90)
In article <26461@nigel.udel.EDU> XBR4D75G%DDATHD21.BITNET@cunyvm.cuny.edu writes: >Any help and hints are appreciated. It works fine here. My first suspicion is that you have a different Ethernet board than the one MINIX expects, or it is starpped or configured differently somehow. Has anyone else tried the Amoeba networking with 1.5.10? If so, please post your findings. Andy Tanenbaum (ast@cs.vu.nl)
ajm@monu6.cc.monash.edu.au (Tony McGregor) (08/08/90)
In article <7230@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: >Has anyone else tried the Amoeba networking with 1.5.10? If so, please >post your findings. I have used Amoeba networking with 1.5.10. I needed to change the interrupt vector and base memory address for the way the WD Ethernet cards are configured here. I also had to make the same changes when I used 1.3 amoeba. I changed the ETHER_IRQ in src/kernel/const.h (from 3 to 5 im my case) the base address of the cards memory also in src/kernel/const.h (from C4000 to D8000 in my case) the misplaced bracked in src/amoeba/examples/client3.c from if ((n=read(fd1, b, 1024) < 0)) { to if ((n=read(fd1, b, 1024)) < 0) { Apart from that everything seems to work well. Hope this helps Tony -- Tony McGregor ( ajm@monu6.cc.monash.edu.au ) Department of Robotics and Digital Tech., Monash University PO Box 197, Caulfield East, Vic 3145, Australia Phone: +61 3 5732014 Fax: +61 3 5732748
yip@ztivax.UUCP (Dr Yeung-Cho Ip) (08/16/90)
In article <7230@star.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: > >Has anyone else tried the Amoeba networking with 1.5.10? If so, please >post your findings. > >Andy Tanenbaum (ast@cs.vu.nl) Although I havn't the 1.5.10 Amoeba kernel running yet, a quick look into the Amoeba user programs showed me, that the 1.3 bugs are still in there. What follows is a repost of my old bug report. Hope that helps. -------------- Hello everyone, in the last two weeks I was adapting the MINIX amoeba stuff to our FDDI interfaces (AMD FAST boards). According to the differences between this interface and the WD Etherplus card (i/o mapped 32-bit-wide frame memory vs. a memory mapped 8-bit-wide one), I had to rewrite the lowlevel driver routines (dp8390.c) and had to make minor changes in the amoeba task (amoeba.c). During the test, I had several difficulties mostly with my own programs but some with the original amoeba examples and utilities as they are delivered with the 1.3 PH distribution. (It cost me several hours of thinking, because in the first place I assumed faults in my own software.) a) The program "client3" in amoeba/examples has a bug near it's end, which causes the failing of every file tranfer. wrong place for closing paranthesis | | do { if ((n=read(fd1, b, 1024) < 0)) { printf("Cannot read %s\n", argv[1]); exit(1); } if (write(1, b, n) < 0) { printf("Cannot write stdout\n"); exit(1); } } while (n > 0); } To solve this problem correct the faulty line to: if ((n=read(fd1, b, 1024)) < 0) { b) Due to the makefile in amoeba/util, the program "master" has not enough stack space (only 500 Bytes). This results in an "Unexpected Trap" or something like this. To achieve proper operation I increased the stack space to 800 bytes. c) The macro "BUFFERSIZE" in sherver.c is set to 8K bytes. While transfering large files (for example via "rcp") the sherver on the receiving machine tries to put a buffer of "BUFFERSIZE" bytes into a pipe. Due to the pipe size of 7K max. this attempt failes and the whole file transfer results in a file of 0K length on the receiving machine. To avoid this situation, you simply have to adjust "BUFFERSIZE" below 7K. (Curiously enough, the "BUFFERSIZE" in sherver.c is allready a redefinition of a much larger "BUFFERSIZE" somewhere in the headerfiles with the somewhat sarcastic remark "/* isn't minix wonderful */". So I guess the author was aware of the situation. Heaven knows why he used too large a value.) I hope this posting isn't completely uninteressting to the rest of the net. Michael Franzen Michael Franzen, c/o yip@ztivax, Munich
nhc@cbnewsj.att.com (n.h.chandler) (02/04/91)
In Article <XBR4D75G%DDATHD21.BITNET> Hans-Juergen Knobloch, (TH Darmstadt, Germany ) writes >Subject: Problems with Minix Amoeba System >Message-ID: <26461@nigel.udel.EDU> >Date: 2 Aug 90 15:26:06 GMT >After upgrading my MINIX-system to version 1.5.10, I finally found some time >to generate the corresponding AMOEBA-version. The generation of my new -other stuff >The included examples server1/client1 and server2/client2 are running >local on one PC successfully but I could not run them between two >different PC's. >Ethernet-cards are installed on both PC's and when booting, the >hardware-address is shown on the screen by the minix system. >When I started the examples server1/client1 on one machine, I used >the other PC to monitor the the ethernet with "NETWATCH", here are the 4 >broadcast messages I observed on the net: >0040 FFFF FFFF FFFF 0000 C0CD A517 8145 FF00 E >0050 0000 0000 1E00 0001 7879 7A00 0000 7624 xyz v$ >0060 0F0F 0F0F 2F1F 0F0F 4949 4949 4959 4B49 / IIIIIYKI >0070 71F0 E0E8 F890 F8E0 DCB7 B6B3 3D00 3C00 q = < > -other stuff > >When running only client1 on a machine, I had exspected to see at least >one broadcast message on the net, but nothing appeared. > >Has anyone similar problems or any idea to fix this network problem? > >about interrupt level (0x3), io-address (0x280) and memory-address (0xd000), >have I forgotten something during system generation? > >Any help and hints are appreciated. > I am using Minix 1.5 (PH 1991) and have the same problem with Amoeba (exactly). Can anyone suggest a solution? For both machines int-level (0x03), io-address (0x280) and mem-address (0xd400). Both systems execute server[n]/client[n] locally but fail the remote tests. With client1 running on either machine, and NETWATCH on the other, traffic on the ethernet line is displayed. The hardware passes all diagnostic tests under MS-DOS. Any help or hints will be appreciated. Neville H. Chandler nhc@cbnewsj.att.com nhc@mtdcc.att.com