lkml.org 
[lkml]   [2007]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRepost: NMI error and Intel S5000PSL Motherboards
    This is a slightly edited repost of a note sent on Friday September 28, 
    as we haven't heard back from anyone yet. (I know it was the weekend!)
    Sorry to post again but this issue caused great problems for us and I
    want to be sure we're choosing a decent solution.

    Perhaps one of the people who so helpfully commented on this issue
    earlier last week can now give their opinion on the what should be
    concluded from our discovery that "CONFIG_PCIEAER=y" -- introduced in
    the 2.6.19 kernel and set as the default -- leads to NMI errors on the
    Intel S5000PSL motherboard.

    I'm told Intel people were closely involved in the development of this
    PCIEAER feature -- so it seems even weirder that it causes problems for
    this Intel motherboard. But we have confirmed the problem with multiple
    Linux distributions.

    We are hoping to get some insights into the real cause. Please see below
    where I outlined what seem to be the 3 possibilities.
    > rdunlap@xenotime.net wrote:
    >> On Wed, 26 Sep 2007 19:48:14 -0400 Jim Paris wrote:
    >>
    >>
    >>> Hello,
    >>>
    >>>
    >>>> We have about 100 servers based on Intel S5000PSL-SATA
    >>>> motherboards. They have been running for anywhere between 1 and 10
    >>>> months. For the past few months, after updating them all to the
    >>>> 2.6.20.15 kernel (because of a bug in the 2.6.18 kernel), we are
    >>>> seeing some strange NMI errors. For example:
    >>>>
    >>>> Aug 29 09:02:10 master kernel: Uhhuh. NMI received for unknown
    >>>> reason 30.
    >>>> Aug 29 09:02:10 master kernel: Do you have a strange power saving
    >>>> mode enabled?
    >>>> Aug 29 09:02:10 master kernel: Dazed and confused, but trying to
    >>>> continue
    >>>>
    >>> I'm also working with Andrew and Samson. It seems that the cause of
    >>> the problem is CONFIG_PCIEAER, which was introduced after 2.6.18 and
    >>> defaults to y.
    >>>
    >>> With CONFIG_PCIEAER=n, scanpci works fine with no errors. This is the
    >>> workaround that they'll likely use for now.
    >>>
    >>
    >> Glad that you found it.
    >>
    >>
    >>> With CONFIG_PCIEAER=y, scanpci always triggers the NMI error. The
    >>> option aerdriver.forceload=1 has no effect.
    >>>
    Although running "scanpci" provoked the NMI errors 100 percent on
    demand, the NMI errors would also occur randomly every few weeks on a
    given system without doing anything special. I don't want anybody to
    think we are just trying to prevent a problem from occurring because we
    like running "scanpci". "Scanpci" just turned out to be a reliable way
    to reproduce an otherwise random problem.
    >>
    >> The 'forceload' option only forces the driver to load even when the
    >> ACPI hardware initialization routine fails.
    >>
    >> It would be nice to be able to disable PCIEAER at boot time though.
    >> Shouldn't be difficult.
    >>
    >>


    So, looking for some closure here, what do you think is the "root
    cause"? Is it:

    1) a defect with Intel's S5000PSL motherboards that is not seen when
    running 2.6.18 and earlier kernels but that is exposed by this feature
    added in 2.6.19? In which case, shouldn't we work to get Intel to
    investigate?

    2) a problem with the PCIEAER feature? And maybe "CONFIG_PCIEAER=y"
    should NOT be the default setting?

    3) just a bad interaction between a good motherboard and a good Linux
    feature that don't play well together? (in which case isn't this a
    "feature" that anybody compiling a kernel to run on the Intel S5000PSL
    motherboard should know not to enable?/

    And in general is it a bad idea to set "CONFIG_PCIEAER to "no"". Or is
    it something that we can really live without?




    Andrew
    -
    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: 2007-10-01 06:13    [W:0.026 / U:1.664 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site