On Thursday 12 November 2009 22:59:26 William Bourque wrote: > Michael Buesch wrote: > > On Thursday 12 November 2009 22:34:00 William Bourque wrote: > >> Michael Buesch wrote: > >>> On Thursday 12 November 2009 20:32:32 William Bourque wrote: > >>>> Sorry for the late reply... I seem to have the exact same bug here. Do > >>>> you need more people to run the diagnostic patch? > >>> Well, it doesn't hurt. > >>> > >> Here we go. > >> > >> I think we can observe the same problem : > >> [ 109.273027] b43: Descr. 0: 0x10000000 0x930 0x26296020 0x80000000 > >> [ 109.273038] b43: Descr. 1: 0x0 0x930 0x26295020 0x80000000 > >> [ 109.273047] b43: Descr. 2: 0x0 0x930 0x26294020 0x80000000 > >> ... > >> This Decr. 0 seems weird to me. > > > > No it looks OK to me. > > descr0 most likely is the last descriptor in your RX ring, so it has > > the descriptor-table-end bit set. > > > >> Note : I'm using 4kb kernel stack and SLAB (just saying, if I read > >> correctly the last few mails, you were suspecting something about this). > > > > No this has nothing to do with the stack. > > > >> I will try with Michael's patch and see what it does. > > > > Yeah, please do so. > > > > It just finished compiling. Note that I applied the new patch over the > previous diagnostic patch, not sure if it can cause a problem somehow.
That should be fine. > Here is the output of dmesg. Look like it didn't has any effect in my case : Ok, thanks for testing. I'd still like larry to test the patch, because AFAIR he was the one who added the always-GFP_DMA-on-64bit workaround. This patch removes it. The always-GFP_DMA doesn't make any sense, however it did help in the past to get a device working (I hope Larry remembers which one that was). -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list Bcm43xx-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
