lkml.org 
[lkml]   [2008]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: ohci1394 problem (MMIO broken) (was 2.6.25-rc6-git6: Reported regressions from 2.6.24)
    On Tue, Mar 25, 2008 at 02:47:35PM -0700, Linus Torvalds wrote:
    > On Tue, 25 Mar 2008, Thomas Meyer wrote:
    > >
    > > and compare lspci -vv from 2.6.25 and 2.6.24:
    > >
    > > 2.6.25:
    > >
    > > Region 0: [virtual] Memory at 100000000 (32-bit, non-prefetchable) [size=4K]
    > >
    > > 2.6.24:
    > >
    > > Region 0: Memory at 8c000000 (32-bit, non-prefetchable) [size=4K]
    >
    > Ok, so it didn't use to be at the 4GB mark.

    Note that 'Memory at 100000000' is totally bogus as this is 32-bit BAR
    and respective PCI bridge is 32-bit either.

    Most interesting thing is that under 2.6.24 Tomas had

    PCI: Bridge: 0000:00:1e.0
    IO window: disabled.
    MEM window: 8c000000-8c0fffff
    PREFETCH window: disabled.

    but with 2.6.25

    PCI: Bridge: 0000:00:1e.0
    IO window: disabled.
    MEM window: 0x00000000-0x000fffff
    PREFETCH window: disabled.

    I'm sure that MEM window was actually 0x100000000-0x1000fffff as that
    printk shows only 8 hex digits.

    > This seems to be a PCI and resource alloc issue. It would be really
    > interesting to see where the 4GB allocation started. Ie ignore anything
    > else (warnings, driver loadings etc), and _just_ look at lspci -vv output
    > for where the memory got allocated.

    Yeah, it's resource issue for sure. The 00:1e.0 is a transparent bridge,
    so I blame commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f
    (PCI: remove transparent bridge sizing). It's wrong for two reasons:
    - we cannot ignore standard windows of a transparent bridge as they
    always positive decode, so they are potential source of address conflicts;
    - that patch just broke whole bridge setup logic in unpredictable way.

    What confused me a lot initially is that the patch was already there
    in 2.6.24. But I think that issue was somehow masked by 'unsigned
    longs' used in setup-bus.c all over the place instead of resource_size_t,
    which has been fixed by Ben in 2.6.25...
    I think that's why Thomas has everything working again without
    CONFIG_RESOURCES_64BIT.

    Thomas, can you put CONFIG_RESOURCES_64BIT=y back and either
    revert commit 8fa5913d54f3b1e09948e6a0db34da887e05ff1f, or
    just comment out these two lines in drivers/pci/setup-bus.c:

    if (bus->self->transparent)
    break;

    and check if it helps?

    Ivan.


    \
     
     \ /
      Last update: 2008-03-26 11:17    [W:0.024 / U:61.612 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site