As Ralf pointed out, s/2.4.20-pre4/2.4.21-pre4 :) Pete 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. > > Pete
