This is a discussion on Re: Proposed #ifdef change to em - FreeBSD ; 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 ...
Jack Vogel wrote:
> 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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "email@example.com"