lkml.org 
[lkml]   [2004]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: 2.6.3 oops ia64 Itanium1 with Silicon Image IDE
    >>>>> On Fri, 20 Feb 2004 11:56:23 +1100, Darren Williams <dsw@gelato.unsw.edu.au> 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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:01    [W:0.034 / U:32.568 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site