Re: eepro100 (PCI ID 82820) lockups/failure

Andrey Savochkin (saw@saw.sw.com.sg)
Tue, 7 Aug 2001 03:46:20 -0700


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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/