On Mon, 14 Jul 2008 17:26:38 -0400 (EDT) Mikulas Patocka <mpatocka@xxxxxxxxxx> wrote: > On Tue, 15 Jul 2008, FUJITA Tomonori wrote: > > > On Sun, 13 Jul 2008 20:20:35 -0700 (PDT) > > David Miller <davem@xxxxxxxxxxxxx> wrote: > > > >> From: FUJITA Tomonori <fujita.tomonori@xxxxxxxxxxxxx> > >> Date: Mon, 14 Jul 2008 11:19:02 +0900 > >> > >>> Now IOMMUs don't ignore the max_segment_size. We hit this problem. > >> > >> It seems simply that max_segment_size needs to propagate > >> down into the block layer VMERGE code so that it can > >> act accordingly. > > > > Yeah, I think so. I'll take care of that. > > > > But I think that even with the fix, SPARC64 IOMMU still hits the > > problem. > > > > With the VMERGE accounting enabled, > > > > - an IOMMU must merge segments that the block layer expects the IOMMU > > to merge. > > > > - an IOMMU must return an error if it can't merge such segments. > > > > But the current SPARC64 IOMMU code doesn't return an error if it can't > > merge such segments (as POWER's IOMMU does, as you know). > > BTW. what should the block device driver do when it receives a mapping > error? (if it aborts the request and it was write request, there will be > data corruption). I'm not sure how a aborted request can corrupt data on disk. > Is it even legal to return IOMMU error in case where no > real hardware error or overflow happened? Of course, it's legal. It's a common event like kinda OOM. It's very possible with old IOMMUs that have the small I/O space. A SCSI driver retries a failed request later. But note that some drivers are still not able to handle that. http://marc.info/?l=linux-kernel&m=121300637114672&w=2 -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
