crwdns2894164:0crwdne2894164:0

crwdns2890822:0crwdne2890822:0

crwdns2890844:0crwdne2890844:0

crwdns2861143:0crwdne2861143:0

crwdns2894186:0crwdne2894186:0

crwdns2893794:0crwdne2893794:0 Dan ,

crwdns2893800:0crwdne2893800:0:

I have a more cynical and conspiratorial answer to this. I have exactly the same problem with my 2012 Macbook Pro. However, this only happened after my machine would not switch on at all.
 
I was told that maybe taking the back off and disconnecting the battery for 60 seconds would solve the problem, which it did. My Macbook started up with the power button for the first time in weeks, and I was very grateful.....
 
That is until I realised the computer no longer recognised the battery, the fans uddenlysuddenly started doing 6200rpm, and something called kernel.task was using 300% CPU time, resulting in my machine now being mega-slow.
That is until I realised the computer no longer recognised the battery, the fans uddenlysuddenly started doing 6200rpm, and something called kernel.task was using 300% CPU time, resulting in my machine now being mega-slow.
 
Apparently this is a panic reaction to temperature sensors reaching 100C or thereabouts and designed to prevent the user from commencing any activity which might push the temperatures any higher.
 
All very logical you might reply, but I do not believe this was just coincidence. After all, I paid for my laptop years ago, and it is well out of warranty. If I choose to fry my CPU, or disconnect the battery, or interfere with any component on the motherboard, that should be my right without any built in codes by the manufacturer to prevent me from doing this.
 
If we could prove that this is a deliberate ploy by Apple to encourage the purchase of replacement parts, or expensive and un-necessary repairs, then in my view that is a deliberate fraudulent activity in order to increase profits; and needs to be tested in the courts; as millions may have spent money they didn't need to.
 
There must be a file somewhere in the system folder, which kernel.task is using in order for it to continually access a simple routine (review date/time for example) repeatedly; and if this was moved to the trash the process ought to cease on a re-start. However, I would not care to beging trashing systems files, and I might not have enough access privileges to do so anyway.
 
If anyone has any idea of the likely name(s) of anything which could be the culprit, I would love to know.

crwdns2892198:0crwdne2892198:0:

open

crwdns2893792:0crwdne2893792:0 sirbrianrobertson ,

crwdns2893800:0crwdne2893800:0:

I have a more cynical and conspiratorial answer to this. I have exactly the same problem with my 2012 Macbook Pro. However, this only happened after my machine would not switch on at all.

I was told that maybe taking the back off and disconnecting the battery for 60 seconds would solve the problem, which it did. My Macbook started up with the power button for the first time in weeks, and I was very grateful.....

That is until I realised the computer no longer recognised the battery, the fans uddenly started doing 6200rpm, and something called kernel.task was using 300% CPU time, resulting in my machine now being mega-slow.

Apparently this is a panic reaction to temperature sensors reaching 100C or thereabouts and designed to prevent the user from commencing any activity which might push the temperatures any higher.

All very logical you might reply, but I do not believe this was just coincidence. After all, I paid for my laptop years ago, and it is well out of warranty. If I choose to fry my CPU, or disconnect the battery, or interfere with any component on the motherboard, that should be my right without any built in codes by the manufacturer to prevent me from doing this.

If we could prove that this is a deliberate ploy by Apple to encourage the purchase of replacement parts, or expensive and un-necessary repairs, then in my view that is a deliberate fraudulent activity  in order to increase profits; and needs to be tested in the courts; as millions may have spent money they didn't need to.

There must be a file somewhere in the system folder, which kernel.task is using in order for it to continually access a simple routine (review date/time for example) repeatedly; and if this was moved to the trash the process ought to cease on a re-start. However, I would not care to beging trashing systems files, and I might not have enough access privileges to do so anyway.

If anyone has any idea of the likely name(s) of anything which could be the culprit, I would love to know.

crwdns2892198:0crwdne2892198:0:

open