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. >> 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. > This crash does _not_ happen with proprietary firmware. > The only way dev->fw.rev could crash is by dev being NULL. Got it! Many thanks, -Francesco "INFORMATIVA SUL TRATTAMENTO DEI DATI PERSONALI" I dati utilizzati per l'invio del presente messaggio sono trattati dall' Universita' degli studi di Brescia esclusivamente per finalita' istituzionali. Informazioni piu' dettagliate anche in ordine ai diritti dell'interessato sono riposte nell'informativa generale e nelle notizie pubblicate sul sito web dell'Ateneo nella sezione "privacy". Il contenuto di questo messaggio e' rivolto unicamente alle persone cui e' indirizzato e puo' contenere informazioni la cui riservatezza e' tutelata legalmente. Ne sono vietati la riproduzione, la diffusione e l'uso in mancanza di autorizzazione del destinatario. Qualora il messaggio fosse pervenuto per errore, preghiamo di eliminarlo. _______________________________________________ Bcm43xx-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bcm43xx-dev
