答复: Tyan Changes for 1.1.6

[YhLu]

Eric,

In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c. Is
there any way to disable it for fast booting?

Regards

YH

-----邮件原件-----
发件人: YhLu 
发送时间: 2004年3月11日 21:10
收件人: ron minnich
抄送: [e-mail]
主题: Tyan Changes for 1.1.6

1. AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
except arima --because it connects all apic to 8111.
2. Some correction in AMD8151.
3. Add superio/Winbond/w83627hf.
4. other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
    (Config.lb changes for option_table.h building and superio ...)
    (Increase the heap size to make elfboot work).

YH

-----邮件原件-----
发件人: ron minnich [mailto:[e-mail]] 
发送时间: 2004年3月11日 20:49
收件人: YhLu
抄送: [e-mail]
主题: Re: (no subject)

ok, we will get this tomorrow morning and test it here as well.

It would also be helpful if you add a comment for such changes but we will 
try to understand what you have done.

ron
_______________________________________________
Linuxbios mailing list
[e-mail]
http://www.clustermatic.org/mailman/listinfo/linuxbios

YhLu  writes:
> Eric,
>
> In the 1.1.6, you have move clearing memory from auto.c to k8/cpufixup.c. Is
> there any way to disable it for fast booting?

Don't enable ECC.

Memory clearing is only done for correctness.  ECC memory does not
work properly unless initialized.

I think the Opteron setup now is down to the minimal needed for
things to work.  You only observe one reset correct?
> AMD 8131: ioapic : PCI master mem/io enable. The segment I have added in
>
> old version, in 1.1.6 Eric remove that. --- It is needed for other MBs
> except arima --because it connects all apic to 8111.

As Ron mentioned later this needs a comment.  In the general case we should
not be enabling bus master DMA by default.  I tend to remove bus master
enables before remembering any special circumstances of the chip.
> Some correction in AMD8151.
> Add superio/Winbond/w83627hf.

Thanks that looks correct.  And it was nice to see my changes were
that simple to follow.
> other changs in tyan dir.  (auto.c failover.c cmos.layout from arima dir)
> (Config.lb changes for option_table.h building and superio ...)
> (Increase the heap size to make elfboot work).

Hmm.  Can we throw in a sanity check to ensure we don't run out of heap?
I assume that is what was happening.

Does the 4-way s4880 work?  I'm not quite certain how my changes would
affect it.

Eric

[ron minnich]

On 12 Mar 2004, Eric W. Biederman wrote:
> Don't enable ECC.

Or, one thing I'd like to try:
    - make sure ECC interrupts are disabled
    - enable cache
    - clear memory with cache enabled
    - cld to make sure it's all flushed

I am assuming you are writing with cache disabled to avoid ecc errors on 
loading cache lines. It's a shame we can't do the 'zero-filled cache line' 
trick that some architectures allow, as you can ZFOD a cache line and 
blast it out to memory -- or can we do that trick? But I wonder if this 
other hack would work. Anyone tried it?
> I think the Opteron setup now is down to the minimal needed for
> things to work.  You only observe one reset correct?

we only see one I think.
> As Ron mentioned later this needs a comment.  In the general case we should
> not be enabling bus master DMA by default.  I tend to remove bus master
> enables before remembering any special circumstances of the chip.

Or dynamically figuring it out would be best. What are the rules here? I 
have not checked. How would you know to enable this dynamically?
> > Add superio/Winbond/w83627hf.
>
> Thanks that looks correct.  And it was nice to see my changes were
> that simple to follow.

Your new pnp stuff looks very well done.

ron

ron minnich  writes:
> On 12 Mar 2004, Eric W. Biederman wrote:
> > Don't enable ECC.
>
> Or, one thing I'd like to try:
> make sure ECC interrupts are disabled
> enable cache
> clear memory with cache enabled
> cld to make sure it's all flushed
>
> I am assuming you are writing with cache disabled to avoid ecc errors on 
> loading cache lines. It's a shame we can't do the 'zero-filled cache line' 
> trick that some architectures allow, as you can ZFOD a cache line and 
> blast it out to memory -- or can we do that trick? But I wonder if this 
> other hack would work. Anyone tried it?

I am setting the caching attributes on the memory I am clearing to
Write-Combining in the MTRRs which is better than ZFOD because it
bypasses the cache.  This runs at nearly the theoretical speed of
memory and has done so for years.  This is the way I have always coded
this on x86.  I guess you have not needed to look at that section
of code?
> > I think the Opteron setup now is down to the minimal needed for
> > things to work.  You only observe one reset correct?
>
> we only see one I think.

The strategy is I setup HT and everything very early with what should
work.  And then in the generic code I come back and redo the
calculations but I don't trigger a reset unless things are incorrect.
So if the early code is complete there should only be a single reset
very early on in the boot process.  If not you will see additional
resets.
> > As Ron mentioned later this needs a comment.  In the general case we should
> > not be enabling bus master DMA by default.  I tend to remove bus master
> > enables before remembering any special circumstances of the chip.
>
> Or dynamically figuring it out would be best. What are the rules here? I 
> have not checked. How would you know to enable this dynamically?

The rules are unless something is a legacy device the device driver
has enough information to enable bus mastering.  Generating interrupts
is part of what bus mastering enables.  The ioapic on the 8131 is
a legacy ISA type device so we need to enable bus mastering in
LinuxBIOS.  The linux kernel does not have enough information to do
that.
> > > Add superio/Winbond/w83627hf.
> >
> > Thanks that looks correct.  And it was nice to see my changes were
> > that simple to follow.
>
> Your new pnp stuff looks very well done.

Thanks :)

Eric

[ron minnich]

On 12 Mar 2004, Eric W. Biederman wrote:
> I am setting the caching attributes on the memory I am clearing to
> Write-Combining in the MTRRs which is better than ZFOD because it
> bypasses the cache.  This runs at nearly the theoretical speed of
> memory and has done so for years.  This is the way I have always coded
> this on x86.  I guess you have not needed to look at that section
> of code?

That's how I remember it working, but I thought maybe something special 
had been done on K8 as it is just not running fast.

We may be talking a different ZFOD. In MIPS you could create a ZFOD cache 
line in one instruction and blast it to memory when invalidate happened. I 
don't see the K8 beating this but I will have to look more at the code.

I just noticed that clearing a Gbyte takes several tens of seconds.  I
don't see how this could be theoretical memory speed. Something's not
working right. We'll look some more. Overall it's still quite nice, so 
don't take my comments as anything but observations.

ron