DragonFly bugs List (threaded) for 2004-10
Re: panic in bus_dma_tag_destroy()
On Sun, Oct 10, 2004 at 09:10:04PM -0700, Matthew Dillon wrote:
> :No, I'm not refering to the malloc()'s in the driver. I'm refering to
> :the malloc that bus_dma_tag_create() does internally (i.e. the driver
> :has no visibility to this malloc). Take a look at line 158 in
> :That is that malloc at issue. This is involked in the mpt driver on
> :line 504 in
I think mpt(4) and some other drivers are doing wrong things, mpt(4) even
has an example of wrong argument order.
> :with the 4th to the last argument causing the problem. I'm pretty sure
> :that mpt_pci.c will fail in the same way my driver did as I used
> :mpt_pci.c as a template :)
> Hmm. I think you are definitely on to something here. It
> looks like the drivers such as the advansys are creating
> a hierarchical bus dma structure and attempting to specify
> an unlimited number of segments for the 'parent' (e.g. at
> the EISA or PCI bus level), then specifying child tags
> with the actual number of segments. The 'parent' bus_dma_tags
> are never actually used for I/O, the idea is that they
> specify bus-governing restrictions. In reality, however,
> the driver should not be making those decisions at all and
> the busdma architecture is only actually hierarchical when
> figuring out address restrictions.
> FreeBSD-5 moved the malloc from bus_dma_tag_create() to
> bus_dmamap_create() and bus_dmamem_alloc() to retain the
> API structure. They didn't really fix the API issue, though,
> they just avoided mallocing the structures that weren't
> actually being used for DMA.
I'd prefer keeping the malloc in the bus_dma_tag_create. I think we
have two options here. The first is to explicitly specify the overall
number of segments in the parents too. This would waste some kernel memory.
Alternatively we can change the contenders to specify a maximum number of
segments of 0 or special case BUS_SPACE_UNRESTRICTED.
We are talking about the following drivers: