System freezing?

[pmam]

After half a year working OK with my machine, I am facing with freezing issue:
It occurs after one to few hours of regular working - suddenly the machine totally freezing -
The screen is freeze and nothing is active: nor the mouse, keyboard etc, neither Hard Disk activity.
Is there a log file contains relevant info?
_________________
“You can take our property, our sweet homes, even our cloths...
But don't touch the streets, Ah, That's NO, NO, NO!
The streets are our @world's compilable kernel ...”

[i92guboj]

Most probably candidates for a hard-freeze are always 3rd party drivers and extraneous kernel patchsets. Other than that, hardware issues.

The first thing you should find out is whether it is a real hard-freeze. Try to connect via ssh using another computer or a smartphone, maybe it's just X which freezes. If that fails, try to see if the alt-sysrq combos work (ie. can you reboot safely using alt-sysrq-u to umount and then alt-sysrq-b to reboot?).

See your emerge log, in case some 3rd party driver (nvidia, wifi stuff...) has been updated recently, and try a vanilla kernel as from kernel.org with no patches. Keep an eye on the cpu temperature, and try a boot cd with memtest86 on it, just to be reasonably sure that it's not a hardware problem. Also, try a long SMART test on your HD.

All of this, while keeping an eye on the system log (/var/log/messages, usually) which can also be viewed using the dmesg tool. If you see something strange in there, a driver segfaulting or something like that ask here.

If you can't narrow it that way, the only thing you can do is to try to get a core dump (you should be able to easily find how-to do so) to be able to see what's really happening.

[pmam]

i92guboj,

[i92guboj]

I haven't much idea about what kde ships these days. I guess there should be some suitable tool in there, but it might depend on a couple use flags (acpi and lm_sensors surely). If you can't find any easy way to check it in kde and you have gtk+ installed the easiest thing would be to emerge gkrellm which has almost no dependencies other than gtk+ and use that. If not, emerge lm_sensors which can be used in command line. If you use lm_sensors, please, read the emerge output since you will need to follow the instructions to configure it before you are able to get any lectures from it.

Anyway, nowadays motherboards should really shut down by themselves before the temperature comes to a point where the hardware will fail (unless you configured otherwise in your BIOS setup), so I really doubt that's the problem, but it doesn't harm to check it of course.

[pmam]

i92guboj,

[i92guboj]

[pmam]

Here is hardware info:

[i92guboj]

Intel hardware is said not to be problematic, though I can't tell myself since I never owned an Intel video chip. I would still try using vesa instead, for that, all you should need is to change

[pmam]

[i92guboj]

That's one possibility, yes. Specially if both machines share the same wifi chip.

Another thing I was thinking of (but I forgot to tell you in my last post) is that this kind of issue often triggered by ACPI.

I saw this in your dmesg output:

[pmam]

i92guboj,

[i92guboj]

It's not sctrictly necesary. That variable controls what X video drivers will be built (I think it's used in several other packages but can't remember right now). You can check by doing "emerge -pv xorg-drivers", you will then see the VIDEO_DRIVERS var in action, along with another one called INPUT_DEVICES. If you don't set these in your make.conf, then all the drivers will be built. Since you have both "intel" and "vesa", X will choose whatever it thinks it is best (which obviously is the accelerated intel driver).

You could force a given video driver by using your xorg.conf file/directory. To force the vesa driver just create the directory /etc/X11/xorg.conf.d/ (if it doesn't exist yet), and then drop a file like this with this content into it:

[pmam]

i92guboj,

[Navar]

Assuming we haven't ruled out hardware causes, power problems can be quite the house of cards. Faulted power supplies, power to location (any power conditioning such as UPS?), brown outs, surges, lightning storms, ESD, etc. Are these units from same vendor?

Eliminate your live filesystem as a regression for now and see if the systems are stable off a live bootable distro if you have one handy. Memtest+ for several hours would help stress, along with app-benchmarks/stress. You can stress test with shell scripts. If you cannot hard fault crash those systems in those scenarios, then I would try reverting back to one of your prior successful kernel builds, remove the wifi, etc. I'd leave testing video causation last staying at a basic console, wouldn't even run X. SMART tests and logs are a bit hit and miss as far as pre-determining drive failure (but can't hurt to check).

If the WIFI drivers were module built you could blacklist them autoloading by modprobe.

[i92guboj]

[pmam]

i92guboj,

[i92guboj]

I mean you wrote "menudonfig" in the things you posted. Just try "make menuconfig" and it should work. But, please, first check the kernel version as I told you. It won't do any good if you are randomly testing unconfigured kernels which don't realate to your real setup.

[Navar]

[pmam]

i92guboj,

[i92guboj]

Since I am a big fan of the "fix one thing at a time" technique, what I would do first is to sort that mismatch out.

Check whether you have a /proc/config.gz file. If you have one, then do this AS ROOT:

[Navar]

pmam,

So I don't confuse matters more, this just an explanation only:

What you ran into before was similar to a non-specialized menu option of config choices, such as you would get with doing make oldconfig target. Your prior kernel was apparently removed, but portage should have kept your modified files and respective directory, so in this case, /usr/src/linux-3.12.21-gentoo-r1/.config should still exist unless you manually deleted. If it does or you have /proc/config.gz available, either could be used as a continuation of a pre-existing .config file to use in your 3.14.14 version using the make oldconfig option above where you will be prompted only with newer options in that version versus what you set in 3.12.21-r1's config. This is commonly done and most new options are usually newer hardware support that you can answer N (usually the default) to.

Also keep in mind, compiling another kernel will certainly stress test a system.

[pmam]

[i92guboj]

Forget about the typo, it's not important. Then you need to cd /usr/src/linux, and then do

[pmam]

There were no questions - It was very fast so I do not know if it is ok?

[i92guboj]

I suggest you clean your sources a bit and try again: