On Wed, 2004-06-02 at 14:26, Roger Larsson wrote: > > We found that a nasty system crash was fixed by turning off preemption. > > The crash would happen fairly reliably by switching between virtual > > terminals a number of times. It locked up the system hard. So hard that > > we can't really find the problem in the kernel; we just found a > > work-around basically by trial and error. > > Do you use a SMP computer? If not then you might have run into something > that could hurt a SMP computer running without preemption... > > (Running SMP and preemption is kind of weird. And you may run into additional > problems - per CPU data has also to be protected by spinlocks, etc... )
Nope. No SMP. > > > > We turned on kernel preemption basically because "everyone was doing > > it". We haven't noticed any obvious, serious problems or differences > > since turning preemption off. > > > > Does anyone have some suggestions about what differences to expect and > > what we might have a closer look at? > > You won't notice much difference unless you run real time processes. But they > will need to be suid root (or some wrapper/helper) to become RT processes, > and many kernels do not ship with multimedia stuff suid... We have a couple of SCHED_RR r/t threads running; and the app does run as root. This is what I guess you would call an embedded Linux system: a vst player on x86 hardware in a rack mount box (called Receptor; sketchy info at http://www.museresearch.com). It's using Linux and Wine and a bunch of our own code. > > > > Also, we are newbies about reporting this kind of crash. Any clues about > > where to report it or ask about it? > > First - you mention virtual terminals > What video driver are you using? Nvidia? > If that is the case retest with xfree86 (nv) Hmmm. It's onboard video. I'll have to look into that. I'll see if there is any xfree86 more specific to our hardware. > Second - try to what is happening (Magic SysRq) Yes. We'll give that go. > Third - 2.4.19 is kind of old now (not that many will be interested...), > upgrade and try to reproduce. We're stuck with it for the time being. It's too close to shipping to switch over. Thanks, Roger! ... mo
