Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel.anu.edu.au!munnari.oz.au!hp9000.csc.cuhk.hk!saimiri.primate.wisc.edu!caen!uunet!news.univie.ac.at!news.tu-graz.ac.at!fstgds01!chmr From: chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) Subject: Re: [386BSD] Help with strange trap and WD card. Message-ID: <1992Dec2.213718.20253@news.tu-graz.ac.at> Sender: news@news.tu-graz.ac.at (USENET News System) Nntp-Posting-Host: fstgds01 Organization: Technical University of Graz, Austria References: <9211301230.AA02341@icm.msk.su> Date: Wed, 2 Dec 92 21:37:18 GMT Lines: 82 In article <9211301230.AA02341@icm.msk.su> flash@icm.msk.su writes: > Hello, >We got a very strange problem (really). >We have a Western Digital ethernet card which is >configured ok and 386BSD works with it pretty well >except one exact case: > >1) When it works well: > Two or more incoming or outgoing telnet > sessions are pretty nice and fast. > >2) When it doesn't : > When we try to use ftp it connects ok, > but while opening a data connection 386BSD > writes on screen something like this: > >trap type = 12 code = 2 eip = fe000806 cs = 8 eflags = 10686 >cr2 fe5a6ffc cpl 212 >panic trap > > And reboots the machine. > >So why it don't like ftp over WD so much. (BTW, slip is ok). >(FTP from 386BSD (putting) works ok, but receiving leads to crash). >Also rcp to the 386BSD crashes the machine, why ? > >Our configuration for Western Digital is: >device we0 at isa? port 0x2a0 net irq 2 iomem 0xd0000 iosiz 8192 vector weintr > >Any ideas, suggestions ? > > Regards, Alexander. > Yes, some ideas. In fact, this problem bothers me for some days. You will notice that this problem only arises when talking to hosts which have trailers enabled; this is also the reason why it happens with ftp and rcp and not with telnet, because trailers are only used with longer packets. The problem (as it currently appears to me) is that the ethernet driver cannot read the length of the trailer (variable resid in the fully patched if_we.c, line 746) and sets it to zero. This causes the offset from the start of the packet to the start of the headers (which are on the end of the packet) to be greater that the length of the packet (length of data + resid). This further causes weget to call bcopy() with a negative length parameter, which of course causes a memory fault. It seems that reads from the ethernet-card memory fail for 16-bit values (take only the high byte ?) but are OK for 8-bit values. That is, if I set resid = *(u_short *)pointer; I always get only the high byte (which in the case of resid is always zero), but if I set resid = *(u_char *)pointer + 256* *(u_char *)(pointer+1); I get the right value. (pointer points inside the ring buffer on the ethernet card and is really calculated by the macro wedataaddr() ). This happens with a WD8013 in 8-bit mode and 16-bit mode. I don't quite understand this. Maybe someone who is more knoledgeable about PC hardware could shed some light on this ? However, there seem to be two workarounds to this problem: 1) don't use trailers (ie. ifconfig we0 -trailers) 2) put a line like if (resid <= 0) return; after the resid= line in if_we.c . BTW, there is another bug in the WD ethernet driver: For the softconfig cards, it checks in the probe routine whether the card is really on the configured interrupt line or not. For IRQs > 7 (WD8013), it always fails this test, because only three bits are checked. Maybe someone who known about the softconfig registers on these cards could post a patch so that the fourth bit is also included in this computation. Christoph -- ..signature: Socket operation on non-socket