Hi,
Jack Vogel wrote:
Vladimir,
Your one phrase "more or less patched" invalidated the whole
data point. We are talking about code thats checked in and bound
for 6.3 :)
Oops. I've got it. Maybe we talk about different kinds of watchdog. I
have meant TX queue watchdogs.
Yes, there is a problem with system watchdog in mainstream driver.
Sometimes system stops to respond due to kernel activity for a one
minute or less. Hardware watchdog can reset system this time.
This issue is specific to taskq (fastintr) version of driver
The fix is very simple: we've to schedule less priority to RX thread. We
use PRI_MAX_KERN instead of PI_NET in Yandex' revision of driver.
I have hundreds of machines here at Intel that DON'T have the
problem, that's why in early 20th century philosophy they realized
that verification as scientific method was ineffective, falsification
on the other hand is powerful. So if any users out there have
a problem I am trying to understand why. The only way that I
have so far reproduced something like their failure is when
FAST interrupts are enabled, THEN when I disable them on that
same machine the problem disappears. Right now I have still
not figured out why this is, I'm trying to do that as I write this.
I am also not saying that nothing ever caused a watchdog
before FAST handling, only that as best that I can tell right now
the one repro I have on STABLE, October Snapshot, is related to it.
Regards,
Jack
WBR,Vladimir
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
