Messages in this thread |  | | Date | Mon, 21 May 2001 10:59:44 +0200 | From | Andrea Arcangeli <> | Subject | Re: alpha iommu fixes |
| |
On Mon, May 21, 2001 at 12:05:40AM -0700, David S. Miller wrote: > together. And it was agreed upon that the routines will not allow > failure in 2.4.x and we would work on resolving this in 2.5.x and no > sooner.
I'm glad you at least just considered to fix all those bugs for 2.5 but that won't change that if somebody runs out of entries now with sparc64 the only thing I can do in a short term is to use HIGHMEM, so that the serialization to limit the amount of max simultaneous pci32 DMA will happen in the code that allocates the bounce buffers. Tell me a best way to get rid of those bugs all together if you can.
Furthmore some arch for the legacy pci32 cards may not provide an huge amount of entries and so you could more easily trigger those bugs without the need of uncommon hardware, those bugs renders the iommu unusable for those archs in 2.4 because it would trigger the device drivers bugs far too easily.
Please tell Andrew to worry about that, if somebody ever worried about that we would have all network drivers correct just now and the needed panics in the lowlevel scsi layer.
This without considering bttv and friends are not even trying to use the pci_map_* yet, I hope you don't watch TV on your sparc64 if you have enough ram.
I hate those kind of broken compromises between something that works almost all the time and that breaks when you are not only using a few harddisk and a few nic, and that is unfixable in the right way in a short term after it triggers (bttv is fixable in a short term of course, I'm only talking about when you run out of pci mappings).
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |