Hello Ken, thank you for the answer!
> On uncommon hardware, anything is possible. I don't actually know > if that hardware is "uncommon", only that I do not have it. Before i start to debug the kernel versions i tried to find other problem reportings for this mainboard. And i found them! http://napalmpiri.info/tag/freeze/ Yes - this is uncommon hardware! It seems that this mainboard type is a slip from normal Asrock quality. Specially the BIOS seems to be buggy and have never been fixed complete. :-( > LOL. I have a phenom x4 : from time to time (fairly frequently) it > loses its lunch during compiles if I use make -j4. On less-frequent > occasions it does the same even with make -j1. And always > memtest86+-5.01 is happy [ well, if I use the "run all CPUs [F2] > option it locks up, but it does that on at least two other mobos > too: one of those is an intel SandyBridge so that issue is not > AMD-specific ]. The solution seems to be: never change a running system when you have one. :-) But after a couple of years you must change it, specially when parts are broken. > If nobody else has better suggestions, I think you will have to > build upstream kernels to find when it broke. I suggest that you > begin with standard 3.2.latest (just in case you turned out to rely > on something in the debian kernel but not upstream). Then try > 3.9.latest : if that runs ok, continue with 3.16.latest. If not, > try e.g. 3.4.latest. The aim is to first find which minor release > broke, and then which update in that series broke it. What you > *might* need to do is also try .0 versions of each of these. Maybe i will try this. But currently i think it is not a bug of the used chipset. This mainboard has a bad BIOS and the last update is from 2011. There is no hope that the problems will be fixed. :-( > Good Luck, and I hope you get a better suggestion. I could reactivate an old backup with Debian wheezy and kernel 3.2. This i running stable on this mainboard and i think it will be the latest release that is usable there. Karsten
