Re: 2.6.3 oops ia64 Itanium1 with Silicon Image IDE

[David Mosberger]

>>>>> On Fri, 20 Feb 2004 11:56:23 +1100, Darren Williams <dsw@xxxxxxxxxxxxxxxxxx> said:

  Darren> We have an Itainum 1 that oopses on boot with a Silicon
  Darren> Imagae IDE pci controller. I can boot the same image on a
  Darren> machine with the same setup except for RAM, which is
  Darren> 1GB. Looking through the archives it seems to be related to
  Darren> the following:

  Darren> http://www.ussg.iu.edu/hypermail/linux/kernel/0306.0/1098.html

Hmmh, trying to remember how this all works...

PCI_DMA_BUS_IS_PHYS currently returns its value based on
ia64_max_iommu_merge_mask.  This variable is primarily used to tell
the block-layer (via BIO_VMERGE_BOUNDARY and then
BIOVEC_VIRT_MERGEABLE) whether two physically discontiguous buffers
can be merged via an I/O MMU, such that they appear contiguous from
the perspective of device DMA.

Your machine doesn't have a hardware I/O MMU so it's using swiotlb,
which simulates the effect of a hardware I/O MMU but of course it
cannot do virtual merging, so it has to leave
ia64_max_iommu_merge_mask at its default value (~0).  This in turn has
the effect that PCI_DMA_BUS_IS_PHYS returns 1, which then leads to the
panic you observed in this fashion:

 (1) ide_toggle_bounce() finds that there is no hardware I/O MMU
     (PCI_DMA_BUS_IS_PHYS is 1) and sets the controller's DMA limit to
     its true physical limit
 (2) blk_queue_bounce_limit() finds that the controller can't
     address all physical memory (bounce_pfn < blk_max_low_pfn), and
 (3) controller can't address up to BLK_BOUNCE_ISA (which is ~0UL on ia64)

and so it throws up its hands and gives up.

You could define PCI_DMA_BUS_IS_PHYS as 0, but then you'd get a
needless amount of bounce-buffering, since memory won't be allocated
with GFP_DMA.

Actually, I can't find any uses for ISA_DMA_THRESHOLD anymore, except
for aha1542.c (which probably doesn't work on ia64 anyhow) and for its
use in defining BLK_BOUNCE_ISA.  Perhaps we can define
ISA_DMA_THRESHOLD as 0xffffffff so it matches the 4GB limit implied by
GFP_DMA.  If the controller can do full 32-bit addressing, this should
take avoid the BUG_ON() without any ill effects.

Perhaps someone who understands the disk/block layers better can also
comment.

In summary:

 - You can force PCI_DMA_BUS_IS_PHYS to 0, which is probably the
   safest since it should work even if there is heavy pressure
   on memory <= 4GB.

 - You can try setting ISA_DMA_THRESHOLD to 0xffffffff which should
   work fine as long as there is free memory <= 4GB.

 - You could get a controller that can address all physical memory
   or a machine that has a hardware I/O MMU.

	--david
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/