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

Reply via email to