On Sun, Feb 18, 2007 at 04:20:18PM +0100, Max Laier wrote: > On Friday 16 February 2007 17:51, Luigi Rizzo wrote: > > On Fri, Feb 16, 2007 at 05:38:28PM +0100, Max Laier wrote: > > ... > > > > > I'm under the impression that this is more a problem of increasing > > > fragmentation until we can't get a big enough unfragmented chunk. I > > > don't have any proof of this assumption yet. > > > > makes sense. > > As a matter of fact i wonder whether it wouldn't be smarter > > to allocate the dma-ble memory on the first request and > > keep it around until the driver is unloaded. > > > > If i read the code in iwi_load_firmware() correctly, > > the contiguous chunks cannot be longer than 8191 bytes, > > so a single contiguous buffer is not mandatory. > > I just don't know if we can write the firmware to the adapter > > with multiple operations (lists of command blocks) or > > it needs to be just a single list ? > > The linux driver uses one continuous buffer as well. I tried to hand in > separate buffers, but it failed to initialize the firmware. Attached is > a diff (for HEAD and RELENG_6) to allocate the DMA buffer once and keep > it around. As I said earlier: As long as the firmware is as (un)stable > as it is now, this might be the only sensible way. All in all it's not > that bad, as we "only" throw away 212966 bytes. > > Could you please confirm that this works for you? >
Should do, that's what my patch did too :-) Mine tried to re-allocate memory only if the new firmware size was > the old one, not sure it's useful. Olivier _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
