[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201311171745.19339.Emanoil.Kotsev@fincom.at>
Date: Sun, 17 Nov 2013 17:45:18 +0100
From: "MPhil. Emanoil Kotsev" <Emanoil.Kotsev@...com.at>
To: Borislav Petkov <bp@...en8.de>
Cc: intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
Daniel Vetter <daniel@...ll.ch>
Subject: Re: [Intel-gfx] kernel 3.11.6 general protection fault
Hi
On Sunday 17 November 2013 16:06:07 you wrote:
> On Sun, Nov 17, 2013 at 03:45:34PM +0100, MPhil. Emanoil Kotsev wrote:
> > this is also true - which makes me sad as the notebook was working
> > thgreat in e past 7y
>
> Hmm, maybe it is heading slowly for the eternal hunting fields... :-)
may be, but I am a bit of academic so until 100% prove - I doubt, which does
not mean that I can not purchaise a new one :)
>
> > > What kind of upgrade exactly did you do to a laptop?
> >
> > I was using debian squeeze with trinity desktop (KDE 3.5.10) and upgraded
> > to debian wheeze with TDE (3.5.13)
>
> Oh ok, so I thought you were talking about a hw upgrade, like adding
> more RAM, hew hdd, etc.
>
> Ok, can you try this: boot without X and try overloading the machine on
> the console, i.e. do
>
> while true; do make clean && make -j64; done
>
> or similar in your kernel repository. Does it trigger then?
I'll try - I'm also curious what will happen!
>
> Although I can't imagine how a software upgrade would cause the
> overheating... :-\.
How - new libraries - more exhaustive algorythms - higher cpu usage etc. Some
of the things M$ is doing on purpose to force you upgrade your hardware every
2-3years
>
> > > Can you revert the upgrade and see whether it still happens?
> >
> > This would be hard - no impossible as I have a backup but it will be
> > time consuming
>
> You could try booting a distro from a livecd and see any change there...
>
> > $ sensors
> > acpitz-virtual-0
> > Adapter: Virtual device
> > temp1: +47.5°C (crit = +126.0°C)
>
> That's some ACPI timezone thing. So what happens if you do
>
> $ watch -n 1 sensors
>
> and you incur the load? Do you hit the critical temperature?
I wanted to first compile the kernel with the debug option you mentioned, but
while compiling it went to about 75°C.
>
> > grep . -EriIn /sys/devices/system/cpu/cpu0/cpufreq
> > /sys/devices/system/cpu/cpu0/cpufreq/bios_limit:1:2000000
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:1:ondemand
> > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_transition_latency:1:10000
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies:1:2000
> >000 1667000 1333000 1000000
> > /sys/devices/system/cpu/cpu0/cpufreq/freqdomain_cpus:1:0 1
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver:1:acpi-cpufreq
> > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq:1:1000000
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors:1:ondema
> >nd powersave performance conservative userspace
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq:1:1000000
> > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq:1:2000000
> > /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_min_freq:1:1000000
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq:1:2000000
> > /sys/devices/system/cpu/cpu0/cpufreq/affected_cpus:1:0
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq:1:1000000
> > /sys/devices/system/cpu/cpu0/cpufreq/related_cpus:1:0
> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed:1:<unsupported>
>
> Yeah, I don't see anything wrong with that output.
yes looks nice
>
> > I could try this. I guess this assumes I have to have another machine
> > running in paralell, but this can be arranged with a little effort
>
> Yep.
>
> > Thanks for the hints. As I never had to do with overheating or
> > similar issues, your help is very precious to me. Unfortunately we
> > have a little child on board and time is limitted :) to a couple of
> > hours daily, where I can work at home which means even less time for
> > debugging. But I never give up. I just want to be sure that it is not
> > a hardware issue
>
> No worries, take care of the child first - the laptop and everyone else
> can wait :-)
yes - we do load balancing with my wife :)
I'll post back with some data (I hope)
regards
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists