Bug#445987: Found a patch [was: Oops reproducable with iSCSI]

[weinholt@csbnet.se, @liszt.debian.org (Göran Weinholt)]

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>