Re: Fixes for nforce2 hard lockup, apic, io-apic, udma133 covered

[Jamie Lokier]

Ross Dickson wrote:
> 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?

If you're waiting for a PLL to settle, it could vary tremendously.

Is there some way to sense the disconnect state and put in a proper
delay e.g. 10 microseconds when it is sensed?  I'd guess the
disconnect state isn't encounted much under system load, which is the
only time you really care about fast timer interrupts.

> 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?

It's possible that hammering it will consume more bus power and push
a stabilising PLL and/or power supply a bit far.

If it's purely marginal timing, then doing fewer reads just means
you'll hit the marginal state less often, not avoid it completely.

-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/