[eepro100] RE: card reports no resources / RX buffers

Krawl, Roeland RKrawl@microtest.com
Tue, 25 Jul 2000 13:13:50 -0700


This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFF674.DF100D60
Content-Type: text/plain

Andrey,

Since our solution to this problem has been rock solid, I have not examined
the eepro100 driver or read the chip documentation since March. However I
clearly recollect that the "wait_for_cmd_done()" routine actually waits for
command acceptance, not command completion. Are you absolutely sure that the
contents of the System Control Block General Pointer can be harmlessly
overwritten after the chip has accepted the command but not yet executed it?
I saw evidence to the contrary. The driver does not "wait for command done"
before overwriting the System Control Block General Pointer in preparation
for issuing the next command.

I have heard that you already have a fix for this problem. That is great. No
more dialog is necessary. The Linux community should be grateful to be rid
of this difficult and elusive problem.


Roeland Krawl



> -----Original Message-----
> From:	Andrey Savochkin [SMTP:saw@saw.sw.com.sg]
> Sent:	Monday, July 24, 2000 7:39 PM
> To:	Krawl, Roeland; 'eepro100@scyld.com'
> Subject:	Re: card reports no resources / RX buffers
> 
> Hello,
> 
> On Mon, Jul 24, 2000 at 11:33:12AM -0700, Krawl, Roeland wrote:
> > The "wait_for_cmd_done()" routine (in the eepro100 driver) falsely gives
> the
> > impression that the
> >  routine waits for command completion. After each call to
> > "wait_for_cmd_done()" 
> > we added an additional delay to ensure that the command has been
> completed
> > before
> > changing the contents of the System Control Block General Pointer in
> > preparation for the next command.
> 
> You permanently repeat that "wait_for_cmd_done falsely gives the
> impression
> that the routine waits for command completion".
> I don't understand your point.
> It waits for the chip to decode the command and be ready to accept new
> one.
> Linux driver does the wait as any other driver (Intel, BSD).
> 
> If you think that something is done wrong, could you point it out?
> I definitely don't believe that arbitrary delays inserted in different
> places
> in the driver fix any problem.  Any delay must be properly justified by
> the
> statements from documentation and/or examples from other existing drivers.
> 
> Best regards
> 					Andrey V.
> 					Savochkin

------_=_NextPart_001_01BFF674.DF100D60
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">



RE: card reports no resources / RX buffers



Andrey,

Since our solution = to this problem has been rock solid, I have not examined the eepro100 = driver or read the chip documentation since March. However I clearly = recollect that the "wait_for_cmd_done()" routine actually = waits for command acceptance, not command completion. Are you = absolutely sure that the contents of the System Control Block General Pointer can be harmlessly = overwritten after the chip has accepted the command but not yet = executed it? I saw evidence to the contrary. The driver does not = "wait for command done" before overwriting the System Control = Block General Pointer in preparation for issuing the next = command.

I have heard that you already have a = fix for this problem. That is great. No more dialog is necessary. The = Linux community should be grateful to be rid of this difficult and = elusive problem.


Roeland Krawl



------_=_NextPart_001_01BFF674.DF100D60--