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
-----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