As Ralf pointed out,
On Tue, 2003-04-01 at 10:22, Pete Popov wrote:
> > > 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)
> Thanks for bringing this to my attention. I'll take a look at it, but
> I'm leaving this Thursday for two weeks and won't be able to get to it
> until after 4/21.
> > 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?
> I doubt Ralf is going to change common macros to fix a specific bug.
> > > 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).
> The Pb1500 HPT370 driver works fine for me, and now the Db1500 HPT371
> seems to work as well. However, with the 2.4.20-pre4 kernel, both boards
> crash with a kernel panic when doing a very large 'cp -a'. I don't know
> at this point what the problem is. The MV 2.4.18 based kernel passes the
> same stress tests repeatedly on the Pb1500. So either something got
> broken between 2.4.18 and 2.4.20-pre4, or the 2.4.18 kernel is getting
> lucky. The boards are still 'usable' with a 2.4.20-pre4 and a hard disk
> cause I can boot with a disk based root fs and run lmbench of the disk.
> But it's quite possible that the problem you observed is caused by the
> same bug I'm encountering.
> I think I have a Promise IDE card at home and I'll run a test with it
> when I get back. It would be interesting to see if that driver causes
> the same problems.