[lkml]   [2003]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered
    On Sunday 14 December 2003 14:27, Jamie Lokier wrote:
    > Ross Dickson wrote:
    > > The v1 patch ((cpu_khz >> 12)+200) gave 700ns additional delay to
    > > your existing code path so I think I was being too optimistic in the
    > > initial v2 timing. I made the initial timing CPU freq dependent on
    > > the assumption that a faster cpu would get to the delay point
    > > quicker.
    > Maybe it scales with bus speed, not CPU internal speed?

    Very good point.

    Hmmm It may well be the settling time of the cpu PLL (phase lock
    loop) changing from low power disconnect speed up to bus speed -
    higher speed bus on the same type of silicon may take longer? as
    also it may take more power to run faster so the internal bus bit
    drivers may also take more time to settle? These sorts of things are
    mentioned in earlier model athlon errata. Especially if there is perhaps
    a marginal northbridge timing in the area Ian has thought about?

    The nforce2 ram controller is also unique and kind of predicts and caches
    reads so maybe the apic timer irq code is ready to run a lot sooner than
    other chipsets so the normal delays wrt loading from memory are not there?
    Are we compensating for that? We don't really know unfortunately.

    > -- Jamie

    Josh - Thanks very much for the patches.

    The v2 io-apic mods seems OK so far.

    I am not yet sure the v2 apic patch is going to be stable enough for everyone.
    I suspect it is the apic reads.

    Ian had problems at 600ns so now has been trying 800ns. I have yet to hear how
    his machine is.

    I have also gone from 600ns to 800ns and had my first hard lockup
    after about 6 hrs on 800ns delay timeout.

    I am using a heavily patched 2.4.23 kern so it could be a coincidence
    but I am suspicious that it may not be that safe to be reading the apic
    registers at all during the delay timeout as the v2 apic patch does.

    I am now going to try increasing the wait loop delay from 100ns to 400ns
    in case the apic does not like being hammered repetitively during the delay
    time. - It could be that the bus between the cpu core and the local apic is
    marginal on either timing (PLL) or current and if we hammer it we may
    be asking for incorrect reads?

    I am about to recompile with the following values that differ from my
    original v2 posting.
    ( 800UL and the ndelay(400) )

    * on AMDXP & nforce2 chipset we need about 800ns?
    * from timer irq start to apic irq ack to prevent
    * hard lockups, use apic timer itself.
    * C1 disconnect bit related. Ross Dickson.
    static unsigned int passno, safecnt;
    if(!passno) { /* calculate timing */
    safecnt = apic_read(APIC_TMICT) -
    ( (800UL * apic_read(APIC_TMICT) ) /
    (1000000000UL/HZ) );
    printk("..APIC TIMER ack delay, reload:%u, safe:%u\n",
    apic_read(APIC_TMICT), safecnt);
    #if APIC_DEBUG
    if(passno<12) {
    unsigned int at1 = apic_read(APIC_TMCCT);
    if( passno > 1 )
    Dprintk("..APIC TIMER ack delay, predelay count:%u \n", at1 );
    # endif
    /* delay only if required */
    while( apic_read(APIC_TMCCT) > safecnt )

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:59    [W:0.024 / U:29.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site