On Thursday 25 May 2006 05:52, you wrote: > [EMAIL PROTECTED] said: > > This patch is supposed to heavily increase overall system > > vitality. It reduces the time periodic work in the bcm43xx driver > > is run, with IRQs disabled, from several msecs to a few usecs. > > > > I am not sure, if we still want to have this in 2.6.17, as > > it is not a crash fix or something. But it fixes "lost interrupt" > > problems for some people. > > > > I would like to get this into wireless-2.6, but before that > > happens I would like to have a few regression tests by people. > > Please apply this and run high network traffic for 10-15 minutes. > > Please enable kernel spinlock lockup and recursion detection > > while testing. > > I applied this to 2.6.17-rc5, and compiled with: > > CONFIG_SMP=y > CONFIG_PREEMPT=y > CONFIG_PREEMPT_BKL=y > CONFIG_DETECT_SOFTLOCKUP=y > # CONFIG_SCHEDSTATS is not set > # CONFIG_DEBUG_SLAB is not set > CONFIG_DEBUG_PREEMPT=y > CONFIG_DEBUG_MUTEXES=y > CONFIG_DEBUG_SPINLOCK=y > CONFIG_DEBUG_SPINLOCK_SLEEP=y > > I don't have an smp laptop, but I compiled for smp to get spinlock > debugging. (it's a UP amd64). > > I started up iperf, and ran it without problems for almost at hour. I > triggered all of my interrupt sources. I compiled a couple of kernels. > The bcm43xx counter in /proc/interrupts was over 4 million. > > I was writing up this reply to say everything's OK when it locked up > hard. no sysrq, I think, but it's hard to be sure since I was in X. > > ordinarily this machine only locks up when using suspend2, and even > then only maybe once a month.
Uh, don't let me dangling like this. :) Could you please try to reproduce the lockup and catch an oops? It's important, because it may be caused by bcm43xx. _______________________________________________ Bcm43xx-dev mailing list [email protected] http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
