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/lis...freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"