linux-kernel - Re: Freezing system after kernel 3.2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <56B9C29A.9010506@home.decotrain.de>
Date:	Tue, 09 Feb 2016 11:42:34 +0100
From:	Karsten Malcher <debian@...e.decotrain.de>
To:	Ken Moffat <zarniwhoop@...world.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: Freezing system after kernel 3.2

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