lkml.org 
[lkml]   [2014]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: Info: mapping multiple BARs. Your kernel is fine.
    On Thu, Apr 17, 2014 at 1:48 PM, Borislav Petkov <bp@alien8.de> wrote:
    > On Thu, Apr 17, 2014 at 12:26:37PM -0600, Bjorn Helgaas wrote:
    >> Thanks a lot for testing this out and debugging my issues.
    >>
    >> Here's a new version that looks for both device IDs I know about.
    >>
    >> I'm still nervous about the modeset problem Dave is seeing. Since the
    >> original patch wouldn't find an 8086:0c00 device on Dave's system, it
    >> should have done nothing. But since it caused a modesetting problem,
    >> there's something else doing on that I don't understand.
    >
    > Yeah, this is strange, to put it mildly. This quirk wouldnt've done
    > anything besides the iteration over the pci devices with pci_get_device.
    > Which wouldn't do anything (refcount increment or so) if it didn't find
    > the device, right?

    Right.

    > Bah, today is the day of the strange bugs. :-\
    >
    >> PNP: Work around BIOS defects in Intel MCH area reporting
    >>
    >> From: Bjorn Helgaas <bhelgaas@google.com>
    >>
    >> Work around BIOSes that don't report the entire Intel MCH area.
    >>
    >> MCHBAR is not an architected PCI BAR, so MCH space is usually reported as a
    >> PNP0C02 resource. The MCH space was once 16KB, but is 32KB in newer parts.
    >> Some BIOSes still report a PNP0C02 resource that is only 16KB, which means
    >> the rest of the MCH space is consumed but unreported.
    >>
    >> This can cause resource map sanity check warnings or (theoretically) a
    >> device conflict if we assigned the unreported space to another device.
    >>
    >> The Intel perf event uncore driver tripped over this when it claimed the
    >> MCH region:
    >>
    >> resource map sanity check conflict: 0xfed10000 0xfed15fff 0xfed10000 0xfed13fff pnp 00:01
    >> Info: mapping multiple BARs. Your kernel is fine.
    >>
    >> To prevent this, if we find a PNP0C02 resource that covers part of the MCH
    >> space, extend it to cover the entire space.
    >>
    >> Link: http://lkml.kernel.org/r/20140224162400.GE16457@pd.tnic
    >> Reported-by: Borislav Petkov <bp@alien8.de>
    >
    > Yep, this one works fine:
    >
    > [ 0.403855] pnp 00:01: [Firmware Bug]: PNP resource [mem 0xfed10000-0xfed13fff] covers only part of 0000:00:00.0 Intel MCH; extending to [mem 0xfed10000-0xfed17fff]
    >
    > Acked-by: Borislav Petkov <bp@suse.de>
    > Tested-by: Borislav Petkov <bp@suse.de>

    >> + region.end = region.start + 32*1024 - 1 ;

    > checkpatch complains about a trailing space before the semicolon.

    Thanks! I hate typos like that.

    I'll fix this, add your tested-by and ack, and send to Rafael.

    Bjorn


    \
     
     \ /
      Last update: 2014-04-17 22:41    [W:3.463 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site