lkml.org 
[lkml]   [2003]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Catching NForce2 lockup with NMI watchdog
    Craig Bradney wrote:

    >What do the IDE ones[patches] claim to fix? I have had no real issue with IDE at
    >all.. being able to burn CDs, DVDs, use my ATA133 drive for hdparm,
    >greps, compilation, and general use.....
    >
    >Craig
    >

    These patches belong together because the same
    necessity is the mother of their invention.

    You may not have an offboard promise or sis hd
    controller.

    Alan Cox looked at "nforce2 irq storm" and the
    offboard promise and sis controllers exposing
    that dma operations might be running out of
    time(time? timing..."timer"? a timer is a given
    so "timer" was unthinkable!) waiting for irq
    availability. That was months ago. It was only
    evident that giving a "bight of slack(1)" to those
    ops could help slightly, but we have a timer in
    any case, don't we?

    One person with a timer patch may backed into
    the nforce2 solution while just trying to get
    nmi_watchdog to work, right?

    Ian Kumlien looks most likely to reason the problem
    all the way through(2).

    -Bob D

    (1) "give me a bight of slack"
    "ah, for a bitty byte of pre-unicode slack loop"
    http://www.bartleby.com/61/13/B0241300.html

    *bight*


    PRONUNCIATION <http://www.bartleby.com/61/12.html>:
    <http://www.bartleby.com/61/wavs/13/B0241300.wav> bt
    NOUN: *1**a.* A loop in a rope. *b.* The middle or slack part of an
    extended rope. *2**a.* A bend or curve, especially in a shoreline. *b.*
    A wide bay formed by such a bend or curve.
    ETYMOLOGY: Middle English, bend, angle, from Old English /byht/. See
    *bheug- <http://www.bartleby.com/61/roots/IE63.html>* in Appendix I.


    (2) voted most likely to finesse through on a level above monkeys

    From Ian Kumlien:

    I did some reading on amd's site, and if the disconnect + apic fixed the
    same problem as the ~500ns delay, then it could be as i suspect...

    I suspect that something goes wrong with apic ack when the cpu is
    disconnected and according to the amd docs we could check the
    Northbridge's CLKFWDRST or isn't that avail on the outside?
    (It would be interesting to see if that fixes the problem as well.)

    http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/26237.PDF

    I don't really have the knowledge but it would sure be nicer to fix this
    by checking this than to just disable it. I dunno if there is something
    we could do from within the kernel aswell with the sending of HLT but i
    doubt it.

    Anyways, we need a generalized patch that does better checking on the
    NMI bit (like Ross' patch).

    PS. Anyone that can point me to northbridge tech docks? and CC

    -- Ian Kumlien <pomac () vapor ! com> -- http://pomac.netswarm.net


    -
    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 13:59    [W:0.022 / U:31.072 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site