On Saturday 23 September 2006 22:05, Larry Finger wrote:
> Michael Buesch wrote:
> >
> > Well, even _if_ mac_suspend takes a few milliseconds (which it
> > does not), it would not trigger the watchdog.
> > I measured the time it takes to execute the various works
> > and based the badness selectio
Michael Buesch wrote:
Well, even _if_ mac_suspend takes a few milliseconds (which it
does not), it would not trigger the watchdog.
I measured the time it takes to execute the various works
and based the badness selection on the results.
If the 15 or 30 second work is really able to trigger a wa
On Saturday 23 September 2006 21:06, Larry Finger wrote:
> Michael Buesch wrote:
> > On Saturday 23 September 2006 06:08, Larry Finger wrote:
> >> Recent changes in the setup for preemptible periodic work fixed most
> >> of the problems with NETDEV watchdog timeouts; however, some variants
> >> of
Michael Buesch wrote:
On Saturday 23 September 2006 06:08, Larry Finger wrote:
Recent changes in the setup for preemptible periodic work fixed most
of the problems with NETDEV watchdog timeouts; however, some variants
of the bcm43xx device still had the problem. These were fixed by setting
the p
On Saturday 23 September 2006 06:08, Larry Finger wrote:
> Recent changes in the setup for preemptible periodic work fixed most
> of the problems with NETDEV watchdog timeouts; however, some variants
> of the bcm43xx device still had the problem. These were fixed by setting
> the parameter MAXIMUM_
Recent changes in the setup for preemptible periodic work fixed most
of the problems with NETDEV watchdog timeouts; however, some variants
of the bcm43xx device still had the problem. These were fixed by setting
the parameter MAXIMUM_BADNESS to 0. By doing so, all the functionality
associated with
