From: Andrey Savochkin <saw@saw.sw.com.sg>
To: Colin Walters <walters@cis.ohio-state.edu>, linux-kernel@vger.kernel.org
Subject: Re: eepro100 (PCI ID 82820) lockups/failure
Date: Tue, 7 Aug 2001 03:46:20 -0700 [thread overview]
Message-ID: <20010807034620.B10193@saw.sw.com.sg> (raw)
In-Reply-To: <87elqs2wbx.church.of.emacs@space-ghost.verbum.org> <20010806022727.A25793@saw.sw.com.sg> <873d75janh.church.of.emacs@space-ghost.verbum.org>
In-Reply-To: <873d75janh.church.of.emacs@space-ghost.verbum.org>; from "Colin Walters" on Mon, Aug 06, 2001 at 02:39:14PM
On Mon, Aug 06, 2001 at 02:39:14PM -0400, Colin Walters wrote:
>
> > In short, that patch isn't a real solution. If someone provides me
> > with the information which commands times-out and how much time they
> > really need, we could have a real solution.
>
> How can I help? Instrument the code by hand with printk statements?
> Or is there a better way?
I would do it by just printk.
The first round is to check how many `udelay(1)' loops are necessary to get
an ack for longest commands (and what that commands are).
Then it's interesting to know how long the wait_for_cmd_done loop has been
executed when it times out.
Not in loop counter, of course, but in clock time.
It can be measured by CPU cycle counter.
This way we check how much time a command may need and whether the timeout in
the loop works as expected.
Another possibility is that the new chip revisions have some unknown timing
constraints, like requirements for delays between certain commands or register
accesses. Those `udelay(1)', executed after every command, may provide such
delays as a side effect.
It's not clear what the easiest way to check it is.
Best regards
Andrey
prev parent reply other threads:[~2001-08-07 10:51 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-08-04 6:06 eepro100 (PCI ID 82820) lockups/failure Colin Walters
2001-08-06 9:27 ` Andrey Savochkin
2001-08-06 15:48 ` Joseph Cheek
2001-08-07 10:48 ` Andrey Savochkin
2001-08-07 16:35 ` Joseph Cheek
2001-08-06 18:39 ` Colin Walters
2001-08-06 19:00 ` Richard B. Johnson
2001-08-07 10:24 ` Andrey Savochkin
2001-08-07 12:11 ` Richard B. Johnson
2001-08-06 19:14 ` Alan Cox
2001-08-07 10:46 ` Andrey Savochkin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010807034620.B10193@saw.sw.com.sg \
--to=saw@saw.sw.com.sg \
--cc=linux-kernel@vger.kernel.org \
--cc=walters@cis.ohio-state.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.