Return to BSD News archive
Xref: sserve comp.unix.bsd:4668 comp.protocols.tcp-ip.ibmpc:11405 Newsgroups: comp.unix.bsd,comp.protocols.tcp-ip.ibmpc Path: sserve!manuel!munnari.oz.au!uunet!cs.utexas.edu!torn!cunews!revcan!latour!mcr From: mcr@Sandelman.OCUnix.on.ca (Michael Richardson) Subject: Re: [386bsd] NS8390 ethernet evaluation board Message-ID: <1992Sep7.004547.4479@Sandelman.OCUnix.on.ca> Followup-To: comp.unix.bsd Summary: first byte isn't transmitted Keywords: 8390, NE2000, 386bsd Organization: Sandelman Software Works, Debugging Department, Ottawa, ON References: <1992Aug31.015413.18294@Sandelman.OCUnix.on.ca> Date: Mon, 7 Sep 1992 00:45:47 GMT Lines: 126 [ I'm going to followup to my own article with a number more details. I sat and studied my /usr/lib/newsgroups wondering where NS8390 gurus would hangout, and considered cross-posting to sci.electronics, but since I don't have it here right now, and it has been over a year since I last read it, I'll refrain. Since the 8390 chip seems to show up on nearly every ISA ethernet card I've seen recently, I'm hoping tcp-ip.ibmpc will snag a couple more people who've written drivers for it. ] In article <1992Aug31.015413.18294@Sandelman.OCUnix.on.ca> mcr@Sandelman.OCUnix.on.ca (Michael Richardson) writes: > I have two National Semiconductor (Nominal Semidestructor? cute comment) >network evaluation boards. These are 8 bit cards with 8k of ram, an 8390 and >associated logic. I have placed one in my 386 running 386bsd 0.0 >(I will be going to 0.1 when my network starts working) The other is >sitting in my Amiga 2000 (via GoldenGate). > The 386bsd's hostname is bud. (as in _Married With Children_) > Further data: > 3/60 (latour): 192.139.46.129, 08:00:20:06:22:c6 > Jolix (bud): 192.139.46.130, 08:00:17:40:0b:d4 (latour runs SunOS 4.1.0. I have made sure it has the right broadcast address. I also swapped ethernet cards, and the new one is 8:0:17:40:c:ab) > There are no other machines on the thinnet segment which is all of >two feet long (although six inches would do the trick) One person suggested that my segment should be at least 6 feet long, and that I was setting up standing waves. The ethernet guru at work suggested that was only true for thicknet, but lent me some more cable anyway. I have been monitoring the cable with etherfind on the 3/60. I invoke it as: etherfind -i le0 -x -v -d greater 1 to get all the packets dumped. Invoking `ping latour' on the 386BSD machine. I see: ip arp request from bud.sandelman.ocunix.on.ca(8:0:17:40:c:ab) for latour.sandel man.ocunix.on.ca 00 ff ff ff ff ff 08 00 17 40 0c ab 08 06 00 01 08 00 06 04 00 01 08 00 17 40 0c ab c0 8b 2e 82 00 00 00 00 00 00 c0 8b 2e 81 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 30 20 Oops, what is that 0x00 doing at the beginning? I have been dumping the packets that I am writing into the 8390 memory, and checking that what I wrote is properly there. It is in fact an 0xff. I am starting this on a 256 byte page properly. If I start one byte further, I get the whole packet (offset by a byte, therefore nonsense) I can get a different packet transmitted by ping the 386bsd machine from the 3/60, therefore priming the 386bsd's arp cache with the 3/60's hardware address. latour% ping bud bud% ping latour and I see: ip arp request from latour.sandelman.ocunix.on.ca(8:0:20:6:22:c6) for bud.sandel man.ocunix.on.ca ff ff ff ff ff ff 37 20 31 61 20 30 08 06 00 01 08 00 06 04 00 01 08 00 20 06 22 c6 c0 8b 2e 81 00 00 00 00 00 00 c0 8b 2e 82 0a 0a 00 00 ip arp reply from bud.sandelman.ocunix.on.ca(8:0:17:40:c:ab) for latour.sandelma n.ocunix.on.ca(8:0:20:6:22:c6) 00 00 20 06 22 c6 08 00 17 40 0c ab 08 06 00 01 08 00 06 04 00 02 08 00 17 40 0c ab c0 8b 2e 82 08 00 20 06 22 c6 c0 8b 2e 81 34 20 30 30 20 30 32 20 30 38 20 30 30 20 31 37 20 34 00 00 00 00 61 fc 00 00 ICMP from bud.sandelman.ocunix.on.ca to latour.sandelman.ocunix.on.ca echo 64 da ta bytes 45 00 20 06 22 c6 08 00 17 40 0c ab 08 00 45 00 00 54 00 3b 00 00 ff 01 dd 53 c0 8b 2e 82 c0 8b 2e 81 08 00 ad c7 38 00 05 00 45 24 aa 2a 30 e6 02 00 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 36 37 33 31 30 30 In otherwords, a) the two machines can both transmit on the wire. b) the 386bsd machine can recieve, recognize its address, and respond to the arp request. c) the 386bsd machine can send onto the wire. I also assume that that the CRCs are correct, or the packets would have been dropped, (although I see nothing that says that /dev/nit and etherfind can't also see dropped packets, I don't see anything that says they can receive it. In fact the warning to the -d flag suggests that they can't) Notice that the first byte is always == the 14 th byte. I did an experiment. On the 386bsd machine I set the 14th byte to the first byte. Lo, and behold, the first byte is now correct. I swapped them outright --- nope. The 14th byte is transmitted anyway. I note that the 14th is the first byte of the actual data (as far as the ethernet is concerned. It is not data for the higher level protocols unless trailers are on). i) Do I have a bad (or rather two) 8390? Could these be part of a bad run? ii) do I perhaps have some kind of debugging or diagnostic mode on? (Nothing I can find in my 1992 edition of the NS lan data book suggests anything) iii) I don't think that it is bad memory since I can receive things okay, and having byte #14 bad would sort of mess everything up. I have tried moving the transmit buffer around in memory (which is from 0x2000 -> 0x3fff) to no avail. iv) I going to call my local NS rep on Tuesday and I'll report back then. -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 SCHOOL: 192228@physics.carleton.ca