On Jul 24, 2009, at 11:43 AM, Michael Buesch wrote: > On Friday 24 July 2009 02:13:38 Francesco Gringoli wrote: >> >> 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. As I wrote to Larry I decided to buy that kind of card. When I get it I will try to reproduce that problem and catch the bug. Thanks for clarifying the DMA.
>>>> 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. I will have to send you the laptop and the cards (happens with both cards I have of that kind) because there is nothing written on display, it simply gets freeze. I also tried to enable the debug features such as magic system request keys to print something but they do not work. However the board is different than the one Larry reported the problem and in my case it can be something due to some hardware incompatibility. >>> 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. > > -- Cheers, -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
