*BSD News Article 8522


Return to BSD News archive

Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!sun-barr!cs.utexas.edu!uunet!mcsun!Germany.EU.net!tools!ws
From: ws@tools.de (Wolfgang Solfrank)
Newsgroups: comp.unix.bsd
Subject: Re: [386BSD] Help with strange trap and WD card.
Date: 3 Dec 92 14:49:09
Organization: TooLs GmbH, Bonn, Germany
Lines: 34
Message-ID: <WS.92Dec3144909@kurt.tools.de>
References: <9211301230.AA02341@icm.msk.su>
	<1992Dec2.213718.20253@news.tu-graz.ac.at>
NNTP-Posting-Host: kurt.tools.de
In-reply-to: chmr@fstgds01.tu-graz.ac.at's message of Wed, 2 Dec 92 21:37:18 GMT

In article <1992Dec2.213718.20253@news.tu-graz.ac.at> chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) writes:

   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 ?

As far as I understand this the problem doesn't have anything to do with
the hardware. It's more simple than that.

The pointer, as you say, "points inside the ring buffer" and the first
statement tries to reference a 16-bit value from there. But since it is
a ring buffer the pointer may point just to the boundary of the ring
and thus get only one byte from the address and fail (or read a bogus
value) for the other byte. This probably results in bogus behavior
of the remaining code.

I'm not sure if this fully describes the problem, but this needs a fix
anyway. Since your substitute code reads the two bytes separately it
should solve the problem.
--
ws@tools.de     (Wolfgang Solfrank, TooLs GmbH) +49-228-985800