From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964804AbcBIKoI (ORCPT ); Tue, 9 Feb 2016 05:44:08 -0500 Received: from smtprelay05.ispgateway.de ([80.67.31.98]:52032 "EHLO smtprelay05.ispgateway.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756305AbcBIKmj (ORCPT ); Tue, 9 Feb 2016 05:42:39 -0500 X-Greylist: delayed 59665 seconds by postgrey-1.27 at vger.kernel.org; Tue, 09 Feb 2016 05:42:39 EST Message-ID: <56B9C29A.9010506@home.decotrain.de> Date: Tue, 09 Feb 2016 11:42:34 +0100 From: Karsten Malcher Reply-To: debian@km.hopto.org User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Ken Moffat CC: linux-kernel@vger.kernel.org Subject: Re: Freezing system after kernel 3.2 References: <56B8D989.7090709@home.decotrain.de> <20160209035104.GA23082@milliways> In-Reply-To: <20160209035104.GA23082@milliways> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Authenticated-User: karsten@home.decotrain.de X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Spam-Score: -8.1 X-Spam-Score-Int: -80 X-Exim-Version: 4.80 (build at 24-Jul-2014 03:28:02) X-Date: 2016-02-09 11:42:35 X-Connected-IP: 192.168.1.10:37453 X-Message-Linecount: 62 X-Body-Linecount: 48 X-Message-Size: 2666 X-Body-Size: 2069 X-Received-Count: 1 X-Recipient-Count: 2 X-Local-Recipient-Count: 2 X-Local-Recipient-Defer-Count: 0 X-Local-Recipient-Fail-Count: 0 X-Df-Sender: NjQ1MzMy Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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