weinholt@csbnet.se (Göran Weinholt) writes:

> Code: 83 78 78 00 75 0c 48 8b 05 59 fa 39 f8 48 c1 e0 0c c3 48 8b
> RIP [<ffffffff881ae3a2>] :scsi_mod:scsi_calculate_bounce_limit+0x15/0x49
> RSP <ffff880004d2dc30>
> CR2: 0000000000000078

I suspect this is where the above function goes wrong:

/*
* Platforms with virtual-DMA translation
* hardware have no practical limit.
*/
if (!PCI_DMA_BUS_IS_PHYS)
return BLK_BOUNCE_ANY;

PCI_DMA_BUS_IS_PHYS is defined in fedora-2.6.18-36186.patch:

+#define PCI_DMA_BUS_IS_PHYS (0)
[...]
+#define PCI_DMA_BUS_IS_PHYS (1)
[...]
+#define PCI_DMA_BUS_IS_PHYS (dma_ops->is_phys)

My guess is that the last definition is the one being used. If dma_ops
is NULL, then &dma_ops->is_phys should be exactly 0x78 (which is also
the bad address) if I counted right (struct dma_mapping_ops in
asm-x86_64/dma-mapping.h).

So dma_ops is currently NULL inside domU. Maybe nommu_dma_ops should
be used?

Googling for "xen domu no_iommu_init", this shows up:

http://www.redhat.com/archives/fedora-cvs-commits/2007-January/msg01476.html

Looks like that patch shows where the problem is. no_iommu_init() is
not being called in pci_iommu_alloc() in fedora-2.6.18-36186.patch.

Please fix this problem in etch.

Regards,

--
Göran Weinholt <weinholt@csbnet.se>



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org