Am Freitag, 7. April 2006 17:44 schrieb Blue Swirl: Hi! > Thank you for the excellent analysis of the problem! Looks like Qemu > doesn't handle the case where DMA length and SCSI length are not equal.
Exact. > So Linux splits the transfer into two parts to use two separate pieces of > buffers. Funny, I thought this situation was exactly the one which > virtually addressed DMA would prevent from happening. I read somewhere, that Solaris and Linux unfortunately do not try to allocate subsequent virtual addresses. > Yes, there will be an interrupt. I didn't find this situation in the > NCR53C9X.txt file documenting the ESP, though. Me too. I tried to understand what's going wrong, but it is not that easy to understand the Linux source, if you don't know much about the hardware and the esp/iommu/dma/sbus architecture. > There are two cases: > 1 - DMA length shorter than SCSI (your case) > 2 - SCSI length shorter (could happen in command replies etc.) > > Maybe this patch helps? Unfortunately not. I tried a similar approach, but it didn't work. Here is the dump: First the mapping, similar to the one described in the last mail: IOMMU: page flush f0039000 IOMMU: page flush f003a000 IOMMU: page flush f003b000 IOMMU: page flush f003c000 IOMMU: page flush f003d000 IOMMU: page flush f003e000 IOMMU: page flush f003f000 IOMMU: page flush f0040000 IOMMU: page flush f0041000 IOMMU: page flush f0042000 IOMMU: page flush f0043000 IOMMU: page flush f0044000 IOMMU: page flush f0045000 IOMMU: page flush f000e000 Then the transfer, which stops after three pages, since the Transfer information len is 12288: ESP: Transfer Information len 12288 ESP: DMA Direction: r, addr 0x0bdea000 0000e000 ESP: DMA address p 0bdea000 v f0039000 ESP: DMA address p 0bdeb000 v f003a000 ESP: DMA address p 0bdec000 v f003b000 ESP: Write callback (offset 224 len 112 size 57344 trans_size 12288) Now I would expect, that "somebody" (maybe the esp inerrupt handler) updates the dma registers to map the remaining pages. But this does not happen. Linux simply unmaps the old mapping: IOMMU: page flush f0039000 IOMMU: page flush f003a000 IOMMU: page flush f003b000 IOMMU: page flush f003c000 IOMMU: page flush f003d000 IOMMU: page flush f003e000 IOMMU: page flush f003f000 IOMMU: page flush f0040000 IOMMU: page flush f0041000 IOMMU: page flush f0042000 IOMMU: page flush f0043000 IOMMU: page flush f0044000 IOMMU: page flush f0045000 IOMMU: page flush f000e000 and configures a new one: IOMMU: page flush f000f000 IOMMU: page flush f0010000 IOMMU: page flush f0011000 IOMMU: page flush f0012000 IOMMU: page flush f0013000 IOMMU: page flush f0014000 IOMMU: page flush f0015000 IOMMU: page flush f0016000 IOMMU: page flush f0017000 IOMMU: page flush f0018000 IOMMU: page flush f0019000 IOMMU: page flush f001a000 IOMMU: page flush f001b000 IOMMU: page flush f001c000 Then, a few pages of the new mapping are written to disk: ESP: Transfer Information len 36864 ESP: DMA Direction: r, addr 0x0bdfa000 0000e000 ESP: DMA address p 0bdfa000 v f000f000 ESP: DMA address p 0bdfb000 v f0010000 ESP: DMA address p 0bdfc000 v f0011000 ESP: DMA address p 0bdfd000 v f0012000 ESP: DMA address p 0bdfe000 v f0013000 ESP: DMA address p 0bdff000 v f0014000 ESP: DMA address p 0be00000 v f0015000 ESP: DMA address p 0be01000 v f0016000 ESP: DMA address p 0be02000 v f0017000 ESP: Write callback (offset 336 len 112 size 57344 trans_size 36864) Then this ara is unmapped, and Linux continues with the next area. Hence, your patch avoids the zero mapping, but it does not provide the required information which should result in a new dma addressing to write the remaining mapped data. Tomorrow, I'll try to enable more debbugging in the Linux driver to try to find out what's going wrong. But with a real hardware it's more difficult to get an idea of the internal functions :( regards, Jörg _______________________________________________ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
