Date: Thu, 28 Aug 2003 09:28:08 +0100 From: Stuart Walsh <stu@ipng.org.uk> To: Duncan Barclay <dmlb@dmlb.org> Cc: dcswest@gmx.net Subject: Re: bcm4400 driver and Dell 8500 Message-ID: <20030828082808.GA5669@icecold.stu> In-Reply-To: <003e01c36d35$94683f20$4bc8a8c0@orac> References: <20030827131039.GA17250@panzer.kdm.org> <XFMail.20030827182757.dmlb@dmlb.org> <20030828033038.GA24315@panzer.kdm.org> <003e01c36d35$94683f20$4bc8a8c0@orac>
next in thread | previous in thread | raw e-mail | index | archive | help
(apologies for the large cc list, im only subbed to -mobile so not sure who is where) On Thu Aug 28, 08:21P +0100, Duncan Barclay wrote: > From: "Kenneth D. Merry" <ken@kdm.org> > > > > This is a little loop that waits for the card to finish DMAing a packet. > There > > > should be a DELAY(1) in there. But it may be commented out. > > > > That's bad...in general the chip should DMA the packet and then update the > > consumer index and generate an interrupt. I don't know how this > particular > > chip works, though. The DELAY is commented out. > > Unfortunately I don't know how the chips works wither. This method comes > from the drivers I used as a reference. I have recoded the loop a little so > it doesn't DELAY and I've never had a timeout from it. > That is how this chip works. It rxes a packet, prepends an rxheader to it, DMAs it and then updates the index and generates an interrupt. If it reaches the last descriptor(marked by an end of table flag) it resets it 0. The chip does have a 'lazy rx' mode which can be set to interrupt after a certain amount of frames or a certain amount of data. These problems may or may not mystically disappear when I finish merging Duncan and I's drivers, but I wouldn't hold your breath. :) Regards, Stuart
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030828082808.GA5669>