[lkml]   [2004]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.6.3 oops ia64 Itanium1 with Silicon Image IDE
>>>>> On Fri, 20 Feb 2004 11:56:23 +1100, Darren Williams <> 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:


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

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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 14:01    [W:0.026 / U:11.396 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site