On Friday 24 July 2009 02:13:38 Francesco Gringoli wrote: > > On Jul 23, 2009, at 11:29 PM, Michael Buesch wrote: > > > On Thursday 23 July 2009 17:18:24 Francesco Gringoli wrote: > >> On Jul 23, 2009, at 11:18 AM, Michael Buesch wrote: > >> > >>> On Thursday 23 July 2009 04:05:17 Larry Finger wrote: > >>>> Francesco Gringoli wrote: > >>>>> Larry, I think this could be one of the causes of the > >>>>> malfunctioning you > >>>>> reported before. If you have some time (and indeed if you feel > >>>>> like > >>>>> doing it :-) ) please test this firmware, it will be great. > >>>> > >>>> Francesco, > >>>> > >>>> The system ran about 30 minutes, then crashed. I missed the first > >>>> oops, but caught a kernel panic with formal traceback on my i386 > >>>> system: > >>>> > >>>> b43_dma_handle_txstatus + 0x1ee/0x2fa > >>>> b43_handle_txstatus + 0x45/0x52 > >>>> > >>>> The call in b43_dma_handle_status is at line 1405: > >>>> > >>>> unmap_descbuffer(ring, meta->dmaaddr, meta->skb->len, > >>>> 1); > >>>> > >>>> The oops was in drivers/net/wireless/b43/xmit.h:171 in the call to > >>>> b43_is_old_txhdr_format(). It appears that dev->fw.rev causes the > >>>> oops. > >>> > >>> How is that possible? Is the firmware clobbering random memory? > >> > >> I don't think that the value was modified by the firmware. It cannot > >> poke values into host memory ;-) > > > > Oh yes it can. It has a DMA engine. > Hello Michael, > > yes, you are right. I was referring to something like mov 0x0000, > HOST_MEM[random]. > > Jokes apart, I really didn't think about this possibility but I > believe your idea is correct. I originally thought, reading the specs, > that the dma controller can be configured not only with the base > address but also with a "Descriptor Stop Index", and I thought this > was an upper limit to the memory it can use, beyond that the > controller would have turned down to the beginning of the ring. > Instead I see from the kernel code that there is not such kind of > limit, is it right? Is it the kernel responsible of taking down the > controller to the first slot when the dma reserved memory is exhausted > (by writing zero in B43_DMA64_RXINDEX)? Sorry for these questions but > I'm missing some details.
Well it depends on the architecture to which places the DMA controller can write. On i386 it can write pretty much anywhere. On x86_64 it can probably only write to mapped areas due to the IOMMU. The engine is supposed to wrap reading/writing at the descriptor table end marker and should stop at the index marker. > >> I suppose that the issue on pccard32 > >> hardware is not yet solved. > > > > Which issue? > The one we are talking about, reported by Larry for some pccard32 > boards where the opensource firmware crashes. We did several testing > with a few 4306 pccard32s the first time Larry reported the problem > but unfortunately that hardware has different problems and crashes > also with the original firmware. Ok. I'd like to see some oopses with proprietary firmware. > > This crash does _not_ happen with proprietary firmware. > > The only way dev->fw.rev could crash is by dev being NULL. > Got it! Ok, NULL was a typo. I meant "invalid" instead. -- Greetings, Michael. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
