Larry Finger <[EMAIL PROTECTED]> writes:
> Peter Osterlund wrote:
> > Larry Finger <[EMAIL PROTECTED]> writes:
> >
> >> Peter - does the interface work for a while, or does this transmit
> >> timeout happen immediately?
> >
> > It works perfectly for a few hours, then it stops working. Stressing
> > the network doesn't seem to make a difference. The only workaround
> > I've found so far is to increase BADNESS_LIMIT to 20 in
> > bcm43xx_main.c. With that change I have never seen this problem.
>
> That helps a lot. Making periodic work preemptible seems to be the cause of
> the difficulty. There
> must be some circumstance where a transmit cannot complete because interrupts
> are disabled, which
> triggers the watchdog. In addition, the reset routine must have a problem as
> well, which keeps the
> system from recovering. You can set BADNESS_LIMIT to 20 while we try to
> figure what is happening.
> Once we have a trial fix, we will let you know.
Thanks.
I could do some trial-and-error debugging myself, but it's quite
annoying when I have to wait several hours to know if the kernel is
good or bad. I was thinking of changing this line
schedule_delayed_work(&bcm->periodic_work, HZ * 15);
in do_periodic_work so that the function runs more often, in the hope
that the bug would then trigger faster. Do you think changing the time
to say 1 second would cause other problems which would invalidate my
tests?
> Of course, if a failure still occurs with the new BADNESS_LIMIT,
> please let me know.
Yes, will do. However, I've used that workaround since the end of
July, and since it hasn't failed a single time yet, I don't expect it
will in the future either.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
_______________________________________________
Bcm43xx-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
