On Monday 29 May 2006 23:25, Jason Lunz wrote: > On Mon, May 29, 2006 at 10:40:14PM +0200, Michael Buesch wrote: > > Whoah, that's damn weird. I have no idea what's going on. > > I'm sorry. Does someone else have an idea? Otherwise I think > > we must drop that patch and live with the high periodic work latency. > > > > I really don't see how this is still possible to race. Even on UP(!). > > Jason, I added an assertion that should be able to catch > > periodic work vs IRQ handler races. You did not see it trigger by chance? > > Everything that looked slightly suspicious was in my email. Do you have > a string for me to grep for?
Every "assertion failed" string is interresting. > > Besides that, this seems like a race of periodic work against > > the tasklet. But I really don't see how this is possible. > > I really don't know. It's definitely your patch though. Just to > double-check, I compiled a 2.6.17-rc5-git5 kernel with an identical > .config (SMP/PREEMPT + kernel debugging), but neither of your > experimental patches. I set it up under the same iperf + disk activity > load. It's up to 37 million bcm43xx interrupts right now with no trouble > at all. > > Maybe there's something about preempt that violates one of your > assumptions? I know that it's supposed to be good at triggering races. yes, I think it is preemption and the softmac workqueues. So, current bcm43xx locking can't really handle that correctly. I am currently thinking about how to redesign it. Yes, we could disable bh processing and preemtion throughout the periodic work handler, but I don't think we want that, as we wanted to reduce latency. Well. bh disabling might still be needed. -- Greetings Michael. [2007: Knorkator (Germany) - 12 points] _______________________________________________ Bcm43xx-dev mailing list [email protected] http://lists.berlios.de/mailman/listinfo/bcm43xx-dev
