Re: Au1500 hardware cache coherency

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Pete,

Pete Popov wrote:

> On Mon, 2003-03-31 at 11:24, Hartvig Ekner wrote:
> > Hi Eric,
> >
> > I did a quick check of a complete kernel disassembly, and there are
> > tons of direct or indirect RMW's to config, which do not explicitly
> > insure that Config[0D] is set.
> > Pete - are you aware of this?
>
> Config[OD] is set in setup.c and should not be cleared afterward.
>

Due to errata #4, it is cleared whenever macroes like set_c0_config or change_c0_config is
called. This happens in several places:

    au1000_restart (probably doesn't matter?)
    cache parity error exception (doesn't matter, we're probably dying anyway)
    ld_mmu_mips32 (in c-mips32.c)

I'm not quite sure whether ld_mmu_mips32 is called after au1x00 setup, but if it is,
the bit is cleared, never to be set again. Maybe the c0_config macroes should be changed
due to errata #4?


> > So, to summarize: The first set of problems in my email below seem to
> > be fully explained by errata #14. Note that any kernel compiled from
> > the current CVS exhibits this problem:
> > Because although NONCOHEHENT_IO is set, the NC bit in PCI_CFG is not
> > set.
>
> Hmm, ok, I'll check that out.

>
>
> > I have verified that the problem occurs when NC is cleared, regardless
> > of the .config option. So some code needs to be changed in
> > au1000/xxx/setup.c... (set NC if NONCOHERENT_IO
> > is enabled).
>
> > But - much wore worrisome: I did this modification, and with the NC
> > bit set, and NONCOHERENT_IO set, I get the second set of errors,
> > although it takes much longer time. The wback_inv calls are made
> > through the generic code  in the subroutine
> > pci_alloc_consistent() (in arch/mips/kernel/pci-dma.c).
>
> > So something is wrong.... Anybody at AMD who would care to continue
> > the debug?
>
> Can you send me your test and exact instructions on how you're
> duplicating the error? I won't have time to look at it until after 4/20
> though.
>

Sure. However, I will first try to make sure that the kernel does not have the same problem on another
non AU1500 platform.

BTW, are you using the HPT onboard IDE controller? Last time I tried, it wasn't functional, the kernel crashed
during boot when kudzu was doing some HW probing on the IDE stuff. I'm using a plug-in promise card
(20268 based).

/Hartvig




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux