*BSD News Article 8508


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