On Sat, Aug 04, 2001 at 02:06:10AM -0400, Colin Walters wrote:
> I have an ia32 motherboard (MSI 815EM Pro) with an integrated Intel
> ethernet controller, about which lspci -v has to say:
[snip]
> I'm using the 2.4.7 eepro100 driver, and the machine consistently
> locks up under any kind of heavy network load. I've tried
> 2.4.8-pre{1,2,3} with the same results. A message sometimes printed
> to syslog before the machine locks completely is:
>
> Aug 3 20:56:17 debian kernel: eepro100: wait_for_cmd_done timeout!
> Aug 3 21:01:22 debian kernel: eepro100: wait_for_cmd_done timeout!
> Aug 3 21:01:29 debian kernel: eepro100: wait_for_cmd_done timeout!
>
> Sometimes it's just the network that goes down, but usually the
> machine will lock not long thereafter.
>
> I noticed a patch posted to this mailing list:
>
> <URL:http://mailman.real-time.com/pipermail/linux-kernel/Week-of-Mon-20010618/041187.html>
>
> But it doesn't seem to have been applied.
Someone who experiences such timeouts needs to figure out how much time it
really can take before a command is accepted.
Some time ago the timeout was increased by the factor of 10, and now the
current timeout looks being insufficient.
It might be a problem with the time of specific commands or specific chip
revisions.
Or some hardware is too clever and somehow optimizes those repeated read
operations, so that they no longer take a fixed number of bus cycles.
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.
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/