Robin Gareus said :
> All right, that was too much of a good thing to escape Murphy's notice -
> after ~45 mins the system froze.
actually, I am glad to hear that, silly it sounds, as I was getting paranoid something was wrong with my machine. :)
Karsten had the same problem
the only one he tried on his machine that was not eventually freezing was
the current p:d kernel
http://code.goto10.org/projects/puredyne/browser/live/kernel/config-2.6.23-rt14
using the same config moved to a more recent kernel + rt patches = freeze
but it's hard to tell what is the problem, Karsten and I have both very
similar machines and on mine one of his "problem" config was not freezing
at all. Maybe I should have waited longer ...?
His machine was freezing when running sc + iceweasel, and mine was fine
with Pd + iceweasel. We used the same limits.conf but he was using
rtirq.sh, not me.
I got rid of rtirq and das-watchdog entirely. after that, the machine didn't lock up for at least as long as Robins session, ~45 mins, but the in the middle of some session I would have liked to keep the recording of, dang..
Maybe we could try to see how to reproduce the freeze?
it seems for me to be related to audio, as it only froze when doing some more tough processing/synthsis with SC.
> any ideas on how to trace this if it happens again? - I can not switch
> to the console or use SysRQ! - nothing in kern.log either - most
> probably it isn't flushed to disk when the system gets stuck.
If it's the same type of freezes he had so far for different type of
kernel/config, then it's a complete system lock.
yes, one can't do anything about this. I'm too lazy to do the kernel debugging thing, so I'll rather hunt for a combination of patches & kernel sources that work well. I have another kernel I'm testing, although there are problems alsa there. will report back there is time!