Booting Imac G5
J. Mayer
l_indien at magic.fr
Mon Nov 22 17:23:00 EST 2004
On Mon, 2004-11-22 at 04:42, Benjamin Herrenschmidt wrote:
> > I think I found the problem.
> > While testing my RTC driver, I had some problems which seemed to be
> > cache related.
> > I made a try:
> > in arch/ppc64/kernel/misc.S, in flush_dcache_range and
> > flush_dcache_phys_range, I added a
> > dcbf 0,r6 just after the dcbst 0,r6.
> > This fixed the problems I had in the RTC driver and I can notice that I
> > got no more segfault using this patch (I even can now update my Gentoo
> > under X11 using Gnome !).
> > I guess I could remove the dcbst, as dcbz does the same plus L1 cache
> > invalidation.
> > I'm not completly sure of what the problem is, but I think it can be
> > either the dbcst is not appropriate, as it does not invalidate the L1
> > cache in 970FX, or HID registers are not well programmed.
>
> Hrm... that's bad ... dcbf will actually invalidate the line from the
> cache, not only flush it, which is not what we want (it's correct still,
> but not optimal) and there may well be existing code using dcbst....
> I'll investigate, but that is definitely not normal. What is your exact
> PVR value ? (cpu rev.) and can you send me the values in HID0, HID1,
> HID4 and HID5 ? (just add some printk("HIDx: %lx\n", mfspr(SPRN_HIDx));
> somewhere in the kernel)
OK, my mistake...
I forgot one point: I was using 2.6.10-rc2 while my previous tests were
with 2.6.10-rc1.
So it seems the bug was corrected between those two pre-release. Great !
For your information, here are some registers dumps:
PVR: 003c0300 MSR: 9000000000009032 PIR: 00000000
HID0: 0051108100000000 HID1: fd3c200000000000
HID4: 0000001000000000 HID5: 0000000000000000
For the SMU driver I need a function that uses dcbf, because we send a
buffer address to the SMU and the chip may modify this buffer. So I now
added another helper, like flush_dcache_phys_range but using dcbf
instead of dcbst.
> In addition, the L1 D cache of the 970 is write-through, so it should
> never contain dirty data anyway... so neither dcbf nor dcbst is strictly
> necessary, provided we have a sync before the icbi afaik ...
Well, don't we still need dcbst to flush the L2 cache ?
Furthermore, in flush_dcache_range & flush_dcache_phys_range, I can see
no icbi and I don't see why we should have one, as the thing is to flush
data cache, not icache.
--
J. Mayer <l_indien at magic.fr>
Never organized
More information about the Linuxppc64-dev
mailing list