Return to BSD News archive
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.hawaii.edu!ames!olivea!uunet!news.univie.ac.at!news.tu-graz.ac.at!fstgds01!chmr From: chmr@fstgds01.tu-graz.ac.at (Christoph Robitschko) Newsgroups: comp.unix.bsd Subject: Re: [386BSD] Help with strange trap and WD card. Message-ID: <1992Dec4.202703.10782@news.tu-graz.ac.at> Date: 4 Dec 92 20:27:03 GMT References: <9211301230.AA02341@icm.msk.su> <1992Dec2.213718.20253@news.tu-graz.ac.at> <WS.92Dec3144909@kurt.tools.de> Sender: news@news.tu-graz.ac.at (USENET News System) Organization: Technical University of Graz, Austria Lines: 44 Nntp-Posting-Host: fstgds01 In article <WS.92Dec3144909@kurt.tools.de> ws@tools.de (Wolfgang Solfrank) writes: >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() ). > >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. This is a good tip, but does not apply here (because the ring buffer consists of 256-byte pages, and the value that should be read into resid is always on offset 16 in such a 256-byte page). So, any other answers ? >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. I hope so. (although I must admit to my shame that I did not try if this relly solves the original problem. I just found this and was more interested in the real cause) Christoph -- ..signature: Address family not supported by protocol family