On Thursday 07 September 2006 10:43, Bin Zhang wrote: > On 9/5/06, Hendrik Sattler <[EMAIL PROTECTED]> wrote: > > Am Dienstag 05 September 2006 19:58 schrieb Larry Finger: > > > Based on user reports and my own experiences, the current problems with > > > NETDEV WATCHDOG tx timeouts, and the device just falling over do not > > > happen > > > when periodic work is not preemptible. These problems seem to affect > > > BCM4306 rev 2 & 3 chips. Since I changed BADNESS_LIMIT to 20 to disable > > > preemption during periodic work, my device has stayed up continuously for > > > more than 18 hours. Previously, the longest time between failures was less > > > than 6 hours, and sometimes as short as 10 minutes. > > > > I have a BCM4306 rev 3, running with linux-2.6.17.x and have none of these > > problems. > > It seems to me that this problem appears only when you use 2.6.18. > I had already twice this problem after more then 10 hours uptime : > Sep 7 09:39:45 localhost kernel: bcm43xx: Controller restarted > Sep 7 09:43:09 localhost syslogd 1.4.1#18: restart. > > With 2.6.17, I have never seen this problem.
That was not the question. 2.6.17 does not have preemptible work. We need a way to trigger this more quick. It's rather hard to debug something if it only triggers every 10 hours. Especially if we don't know for sure what's going on. The problem is _not_ the BADNESS_LIMIT. So raising this _won't_ help us. The problem is somewhere in the preemptible work card- stopping-code. That is the code path triggered by a high badness. A higher BADNESS_LIMIT _won't_ fix the code. It will only introduce more bugs and make it even harder to debug. So _lowering_ the BADNESS_LIMIT could actually be a way to trigger it in reasonable time. We could also try to fire periodic work more often. Say once per second. -- Greetings Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
