On Thu, Dec 19, 2002 at 09:10:40AM +0000, Colin.Helliwell@Zarlink.Com wrote: > > Thanks for the patch, but unfortunately the problem is still the same. If the problem happens very soon after you boot up, there is something *obviously* wrong. The most common problem is that you have an interupt handling path not going through standard do_IRQ(). Then you need to do similar treatment like those in ll_timer_interrupt(). The second thing is to look for any *new* global variables you may introduce in your kernel. Most of current global variables are either safe or taken care of (Although another update patch will come out today or tomorrow to really close the final hole we have). > I'm > not sure whether it occurs as a result of interrupts, or just after a > certain amount of scheduler 'activity' as it sits there copying the initrd > into ram disk. A few interrupts are enabled, but its only the MIPS timer > which should be generating any interrupts at that point (I'll check that, > in case its relevant). FYI, I have mips kernel with initrd running just fine with preemptible kernel. In fact, it has passed some very stressful tests with initrd. > I presume the change from "sti()" to "__sti()" was a semantic (or SMP) > thing, since the former is #defined to the latter anyway? Please note also > the following modification which was required to 2.4.19: > This is true. Since our kernel had synchronize_irq() added long time ago, I probably forgot about it when I created the pre-k patch. Jun
